May 2013 - Dillo-dev - lists.mailman3.com

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

Can't compile Dillo 3.0.3

by johannes.hofmann＠gmx.de

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 Cheers, Johannes

May 22, 2013

dillo bug#1127

by Johannes.Hofmann＠gmx.de

Hi, On Mon, May 20, 2013 at 02:07:54PM +0200, Urban Lundin wrote: > Hi Johannes, > > That sounds great if you could attempt to solve this issue! > We have made a small example in TCL/TK (which you have to install > first, available through http://www.tcl.tk/) > > We did not try to embed suckless as we could not find a simple > example inside it. > > > Then the example is below. Thanks for the example. For me it works with the following patch for dillo: diff -r ace33e3969af src/xembed.cc --- a/src/xembed.cc Sun Apr 28 15:11:03 2013 +0200 +++ b/src/xembed.cc Mon May 20 19:38:06 2013 +0200 @@ -108,6 +108,7 @@ createInternal(xid); setXembedInfo(1); Fl::event_dispatch(event_handler); + Fl_Window::show(); } void Xembed::createInternal(uint32_t parent) { Before pushing it to the main repo I need to read http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html a bit more, but to me it seems a reasonable thing to do. It would be cool, if anyone using the claws mail dillo plugin could verify that the above patch doesn't break embedding in claws mail. Cheers, Johannes

May 20, 2013

Can't compile Dillo 3.0.3

by Johannes.Hofmann＠gmx.de

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. Sorry, it's not in the fltk headers, but via fltk headers. It's defined in X11/X.h. > > > 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". > > Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. > Perhaps, something with AC_COMPILE_IFELSE could also work. > > Sebastian > > diff -r 2a024fd43fe8 configure.ac > --- a/configure.ac Sat May 18 21:27:59 2013 +0200 > +++ b/configure.ac Sat May 18 21:58:45 2013 +0200 > @@ -124,6 +124,28 @@ > AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) > esac > > +dnl ----------------------------------- > +dnl Test for X11 (only on some systems) > +dnl ----------------------------------- > +AC_MSG_CHECKING([whether to link to X11]) > +AC_LANG_PUSH([C++]) > +old_libs=$LIBS > +old_cxxflags=$CXXFLAGS > +LIBS=$LIBFLTK_LIBS > +CXXFLAGS=$LIBFLTK_CXXFLAGS > +AC_RUN_IFELSE([AC_LANG_PROGRAM([[ > +#define FL_INTERNALS > +#include <FL/x.H> > +]],[[ > +#ifdef X_PROTOCOL > + return 0; > +#else > + return 1; > +#endif > +]])], [AC_MSG_RESULT(yes)] ,[AC_MSG_RESULT(no)]) > +CXXFLAGS=$old_cxxflags > +LIBS=$old_libs > +AC_LANG_POP([C++]) > > dnl ---------------- > dnl Test for libjpeg Ah that's cool. It's good to base the decision for linking and the ifdef in the code on the same thing. I can test it on OSX on tuesday. Johannes

May 18, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

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". Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. Perhaps, something with AC_COMPILE_IFELSE could also work. Sebastian

May 18, 2013