- Dillo-dev - lists.mailman3.com

do not truncate long filenames beginning with dot

by Johannes.Hofmann＠gmx.de

On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > Sometimes, when trying to save a document with long filenames, the > truncated default save-as filename will start with a dot. (Ie. a hidden > file.) This behaviour should change. Perhaps truncate the end of the > filename instead (and preserve the file extension)? Do you have an example where this happens? I see that it can happen with URLs like http://dillo.org/bla/.blub Is this the case where you are seeing the issue or do you get it with other types of URLs as well? Cheers, Johannes

June 10, 2013

Preventing page caching

by Johannes.Hofmann＠gmx.de

On Sun, Jun 09, 2013 at 05:14:15PM +0200, August Karlstrom wrote: > How do I prevent page caching in Dillo? I have tried adding > > <meta http-equiv="cache-control" content="no-cache" /> > > but it has no effect in Dillo. In Firefox it works as expected. I'm > using Dillo 3.0.3. Any clues? This is not implemented in Dillo, but there had been patches floating around to add support for it. Regards, Johannes

June 9, 2013

Preventing page caching

by fusionfile＠gmail.com

How do I prevent page caching in Dillo? I have tried adding <meta http-equiv="cache-control" content="no-cache" /> but it has no effect in Dillo. In Firefox it works as expected. I'm using Dillo 3.0.3. Any clues? Regards, August

June 9, 2013

dillo bug#1127

by Johannes.Hofmann＠gmx.de

On Mon, Jun 03, 2013 at 02:09:46PM +0200, Urban Lundin wrote: > Dear Johannes, > > We tried your patch for the xembed structure and recompiled it, it > works fine in our main application. > Thanks a lot for solving this issue! Ok, I committed the fix. Cheers, Johannes

June 3, 2013

do not truncate long filenames beginning with dot

by jcid＠dillo.org

On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > Sometimes, when trying to save a document with long filenames, the > truncated default save-as filename will start with a dot. (Ie. a hidden > file.) This behaviour should change. Perhaps truncate the end of the > filename instead (and preserve the file extension)? Yes. This should not happen. -- Cheers Jorge.-

May 29, 2013

do not truncate long filenames beginning with dot

by dennisn＠dennisn.dyndns.org

Sometimes, when trying to save a document with long filenames, the truncated default save-as filename will start with a dot. (Ie. a hidden file.) This behaviour should change. Perhaps truncate the end of the filename instead (and preserve the file extension)?

May 29, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-23 22:02, Sebastian Geerken wrote: > Did you call "autogen.sh" again before "configure"? Yes, I followed the instructions at http://www.dillo.org/source.html. > To get more > informations: what is the output of "configure"? Or, better, send the > your "config.log". OK, I have attached config.log. /August

May 25, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Thu, May 23, August Karlstrom wrote: > On 2013-05-22 15:33, Sebastian Geerken wrote: > [...] > >August: Please test whether the version from the repository works for > >you. > > I still get an error when compiling Dillo (version 2013-05-22, > changeset 2843:60a7bb6ca06b): > > $ make > ... > g++ -I/usr/include/cairo -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > -I/usr/include/freetype2 -I/usr/include/cairo > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -I/usr/include/pixman-1 -I/usr/include/freetype2 > -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter > -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test > dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a > ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu > -Wl,-Bsymbolic-functions -lfltk > /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): > undefined reference to symbol 'XCreatePixmap' > /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO > /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker > command line > /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: > Invalid operation > collect2: error: ld returned 1 exit status > make[2]: *** [dw-anchors-test] Error 1 > make[2]: Leaving directory `/tmp/dillo3/test' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/dillo3' > make: *** [all] Error 2 > > Apparently -lX11 has not been added. Although I don't see how that > would make a difference I can also mention that I start X Windows > (Blackbox WM) from the console with the startx command without using > a display manager. Startx instead of xdm should not make a difference. Did you call "autogen.sh" again before "configure"? To get more informations: what is the output of "configure"? Or, better, send the your "config.log". Sebastian

May 23, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-22 15:33, Sebastian Geerken wrote: [...] > August: Please test whether the version from the repository works for > you. I still get an error when compiling Dillo (version 2013-05-22, changeset 2843:60a7bb6ca06b): $ make ... g++ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/tmp/dillo3/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/dillo3' make: *** [all] Error 2 Apparently -lX11 has not been added. Although I don't see how that would make a difference I can also mention that I start X Windows (Blackbox WM) from the console with the startx command without using a display manager. Regards, August

May 23, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Wed, May 22, Johannes Hofmann wrote: > On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote: > > On Sat, May 18, Johannes Hofmann wrote: > > > On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > > > > On Sat, May 18, Johannes Hofmann wrote: > > > > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > > > > [...] > > > > > > > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > > > > not, so that an additional "-lX11" is necessary. Should we add it > > > > > > generally? It does not harm; we have only to care about other systems > > > > > > than X11. > > > > > > > > > > Could we check for libX11 in configure and link explicitely against > > > > > it if available but not fail otherwise? > > > > > That way dillo should still compile on OSX. > > > > > > > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > > > > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > > > > not found where X_PROTOCOL is defined. > > > > > > That comes from the fltk headers depending on whether fltk was built > > > with X11 backend or not. > > > > Do not find it, strange. > > > > > I don't see how we could get that information at configure time. > > > Maybe some fltk-config option? > > > > See attached patch for an incomplete implementation. On my system, it > > says "checking whether to link to X11... yes", on OSX it should say > > "... no". > > Yes, works ok on OSX: > > checking for socklen_t... socklen_t > checking FLTK 1.3... yes > checking whether to link to X11... no Good. I've extended it and it is now in the repository. When cross-compiling (has anyone tested this?), nothing should change. August: Please test whether the version from the repository works for you. Sebastian

May 22, 2013