- Dillo-dev - lists.mailman3.com

hypenator.cc errors

by csoren＠isd.net

> On Mo, Sep 02, 2013, Chris Sorenson wrote: > > Greets all, > > > > Another sequence of bads that cropped up using the > > Silicon Graphics MIPSpro compiler, any thoughts? To wit: > > > > cc-1028 CC: ERROR File = hyphenator.cc, Line = 147 > > The expression used must have a constant value. > > > > char chars [l + 1]; > > ^ > > [more similar cases] > > It seems that your compiler does not support arrays with > variable length, which are standard since C99, as far as I > see. It could be fixed by replacing this line (as an > example) by: > > char *chars = new char [l + 1]; > > and later > > delete[] chars; > > However, I'd like to check other possibilities. A short > search lead me to > <http://www.sgi.com/products/software/irix/tools/c.html>, > according to which newer versions support C99. Which > version do you use? > I'm using MIPSpro 7.4.3 (the most current version is 7.4.4) but in C99 mode it can't compile C++ code. Not to worry I'll #ifdef my way around the variable length arrays, I guess I didn't look closely enough to realize that was what those were, thanks!

Sept. 2, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

On Sun, Sep 01, 2013 at 02:58:02PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 01, 2013 at 08:49:06PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > [...] > > Works fine on DragonFlyBSD with the #include <wait.h> line removed. > > Good! > > I'll patch and commit soon. Committed. -- Cheers Jorge.-

Sept. 2, 2013

hypenator.cc errors

by sgeerken＠dillo.org

On Mo, Sep 02, 2013, Chris Sorenson wrote: > Greets all, > > Another sequence of bads that cropped up using the Silicon > Graphics MIPSpro compiler, any thoughts? To wit: > > cc-1028 CC: ERROR File = hyphenator.cc, Line = 147 > The expression used must have a constant value. > > char chars [l + 1]; > ^ > [more similar cases] It seems that your compiler does not support arrays with variable length, which are standard since C99, as far as I see. It could be fixed by replacing this line (as an example) by: char *chars = new char [l + 1]; and later delete[] chars; However, I'd like to check other possibilities. A short search lead me to <http://www.sgi.com/products/software/irix/tools/c.html>, according to which newer versions support C99. Which version do you use? Sebastian

Sept. 2, 2013

hypenator.cc errors

by csoren＠isd.net

Greets all, Another sequence of bads that cropped up using the Silicon Graphics MIPSpro compiler, any thoughts? To wit: cc-1028 CC: ERROR File = hyphenator.cc, Line = 147 The expression used must have a constant value. char chars [l + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 185 The expression used must have a constant value. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 185 The expression used must have a constant value. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1060 CC: ERROR File = hyphenator.cc, Line = 185 The indicated operator is not allowed in an integral constant expression. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1059 CC: ERROR File = hyphenator.cc, Line = 185 A function call is not allowed in a constant expression. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 316 The expression used must have a constant value. char work[strlen (wordLc) + 3]; ^ cc-1059 CC: ERROR File = hyphenator.cc, Line = 316 A function call is not allowed in a constant expression. char work[strlen (wordLc) + 3]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 316 The expression used must have a constant value. char work[strlen (wordLc) + 3]; ^ 8 errors detected in the compilation of "hyphenator.cc". make: *** [hyphenator.o] Error 2

Sept. 2, 2013

compilation error in fltkflatview.cc

by csoren＠isd.net

> > > > 2 errors detected in the compilation of > > "fltkflatview.cc". ---------- > > > > I suspect it needs a 'using namespace' or somesuch here, > > thoughts? > > > > I thought this sounded a little familiar, and I was able > to find > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2013-January/009809.html > that we'd been through this before. > > I think last time I was waiting to see whether anyone > reported that it didn't work for them, or that dw > originally had that for a deep reason, and then I > eventually forgot about it. This time I'll commit it, and > we'll find out. > Sorry I didn't realize this was the same question I posted about before since I assumed that that fix had been committed and back then I was working with pre-3.0 sources, anyway thanks!

Sept. 2, 2013

compilation error in fltkflatview.cc

by corvid＠dillo.org

Chris Sorenson wrote: > As I've mentioned previously I'm trying to compile > dillo-3.0.3 on Silicon Graphics using the SGI MIPSpro > compiler. I'm doing this for a large group of SGI users who > reside at nekochan.net. The compilation fails in line 884 in > fltkflatview.cc: > > ---------- > cc-3168 CC: ERROR File = fltkui.cc, Line = 884 > A name followed by "::" must be a class or namespace name. > > bool > FltkToggleButtonResource::FltkToggleButtonResource::isActivated > () > ^ > > cc-1443 CC: ERROR File = fltkui.cc, Line = 884 > > "dw::fltk::ui::FltkToggleButtonResource::FltkToggleButtonResource" > is not a > class template. > > bool > FltkToggleButtonResource::FltkToggleButtonResource::isActivated > () > ^ > > 2 errors detected in the compilation of "fltkflatview.cc". > ---------- > > I suspect it needs a 'using namespace' or somesuch here, > thoughts? I thought this sounded a little familiar, and I was able to find http://lists.auriga.wearlab.de/pipermail/dillo-dev/2013-January/009809.html that we'd been through this before. I think last time I was waiting to see whether anyone reported that it didn't work for them, or that dw originally had that for a deep reason, and then I eventually forgot about it. This time I'll commit it, and we'll find out.

Sept. 2, 2013

compilation error in fltkflatview.cc

by csoren＠isd.net

Greets all, As I've mentioned previously I'm trying to compile dillo-3.0.3 on Silicon Graphics using the SGI MIPSpro compiler. I'm doing this for a large group of SGI users who reside at nekochan.net. The compilation fails in line 884 in fltkflatview.cc: ---------- cc-3168 CC: ERROR File = fltkui.cc, Line = 884 A name followed by "::" must be a class or namespace name. bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 884 "dw::fltk::ui::FltkToggleButtonResource::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () ^ 2 errors detected in the compilation of "fltkflatview.cc". ---------- I suspect it needs a 'using namespace' or somesuch here, thoughts? Thanks a bunch!

Sept. 2, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

On Sun, Sep 01, 2013 at 08:49:06PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Aug 30, 2013 at 12:41:41PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, JG: > > > > On Thu, Aug 29, 2013 at 09:13:49AM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > > > > Hi JG, > > > > > > > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > > > > are not reaped when they terminate themselves after a period of > > > > > > inactivity while the parent dillo process is still running. The patch > > > > > > below is simply to reap these zombies. The SIGCHLD handler should > > > > > > probably do more, but I am not yet familiar enough with Dillo to know > > > > > > what. > > > > > > > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > > > > am new to the list and a novice at Dillo patching. And hence also > > > > > > apologies to Jorge for this duplication of a previous communication by > > > > > > private email (although with one small change to get the patch to > > > > > > compile under OpenBSD as well as Linux). > > > > > > > > > > I can reproduce the issue here by killing dpid manually. > > > > > For me the following also fixes it: > > > > > > > > > > diff -r 659dc205c377 src/dillo.cc > > > > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > > > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > > > > @@ -329,6 +329,7 @@ > > > > > > > > > > // Some OSes exit dillo without this (not GNU/Linux). > > > > > signal(SIGPIPE, SIG_IGN); > > > > > + signal(SIGCHLD, SIG_IGN); > > > > > > > > > > /* Handle command line options */ > > > > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > > > > > > > Can you please check whether it works for you too? It would have the > > > > > advantage that we have all signal related stuff in one place. > > > > > > > > Oh, I'm looking at it now too! > > > > For me this is an old TODO: with subtle issues lurking. > > > > > > > > > > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > > > > > > > > > > After some digging (Manual page sigaction(2)): > > > > > > > > ... > > > > > > > > "A child created via fork(2) inherits a copy of its parent's > > > > signal dispositions. During an execve(2), the dispositions of > > > > handled signals are reset to the default; the dispositions of > > > > ignored signals are left unchanged." > > > > > > I guess this is no problem, as dpid explicitely adds a signal > > > handler for SIGCHLD again, but I'm happy if you take care of the > > > whole issue :-) > > > > The attached program is a stress test for SIGCHLD. The idea is to > > find a formula that works well even in such cases. IIRC both of you > > have access to BSD machines so please test it there. > > > > The program spawns 255 children which sleep 5 seconds and > > terminate generating a SIGCHLD avalanche, which should be handled > > cleanly. It works OK in Debian. > > > > $gcc -W -Wall sigcld.c -o sigcld > > $./sigcld > > > > in another terminal (during the 5 secs. sleep window): > > > > $ps aux|grep sigcld > > > > (shows the long list) > > > > then while main is Sleeping 10 seconds: > > > > $ps aux|grep sigcld > > > > (shows only one sigcld process) > > > > after it exits: > > > > $ps aux|grep sigcld > > > > (no process left) > > Works fine on DragonFlyBSD with the #include <wait.h> line removed. Good! I'll patch and commit soon. -- Cheers Jorge.-

Sept. 1, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Aug 30, 2013 at 12:41:41PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, JG: > > On Thu, Aug 29, 2013 at 09:13:49AM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > > > Hi JG, > > > > > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > > > are not reaped when they terminate themselves after a period of > > > > > inactivity while the parent dillo process is still running. The patch > > > > > below is simply to reap these zombies. The SIGCHLD handler should > > > > > probably do more, but I am not yet familiar enough with Dillo to know > > > > > what. > > > > > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > > > am new to the list and a novice at Dillo patching. And hence also > > > > > apologies to Jorge for this duplication of a previous communication by > > > > > private email (although with one small change to get the patch to > > > > > compile under OpenBSD as well as Linux). > > > > > > > > I can reproduce the issue here by killing dpid manually. > > > > For me the following also fixes it: > > > > > > > > diff -r 659dc205c377 src/dillo.cc > > > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > > > @@ -329,6 +329,7 @@ > > > > > > > > // Some OSes exit dillo without this (not GNU/Linux). > > > > signal(SIGPIPE, SIG_IGN); > > > > + signal(SIGCHLD, SIG_IGN); > > > > > > > > /* Handle command line options */ > > > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > > > > > Can you please check whether it works for you too? It would have the > > > > advantage that we have all signal related stuff in one place. > > > > > > Oh, I'm looking at it now too! > > > For me this is an old TODO: with subtle issues lurking. > > > > > > > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > > > > > > > After some digging (Manual page sigaction(2)): > > > > > > ... > > > > > > "A child created via fork(2) inherits a copy of its parent's > > > signal dispositions. During an execve(2), the dispositions of > > > handled signals are reset to the default; the dispositions of > > > ignored signals are left unchanged." > > > > I guess this is no problem, as dpid explicitely adds a signal > > handler for SIGCHLD again, but I'm happy if you take care of the > > whole issue :-) > > The attached program is a stress test for SIGCHLD. The idea is to > find a formula that works well even in such cases. IIRC both of you > have access to BSD machines so please test it there. > > The program spawns 255 children which sleep 5 seconds and > terminate generating a SIGCHLD avalanche, which should be handled > cleanly. It works OK in Debian. > > $gcc -W -Wall sigcld.c -o sigcld > $./sigcld > > in another terminal (during the 5 secs. sleep window): > > $ps aux|grep sigcld > > (shows the long list) > > then while main is Sleeping 10 seconds: > > $ps aux|grep sigcld > > (shows only one sigcld process) > > after it exits: > > $ps aux|grep sigcld > > (no process left) Works fine on DragonFlyBSD with the #include <wait.h> line removed. Cheers, Johannes

Sept. 1, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

On Fri, Aug 30, 2013 at 08:44:47PM -0400, John Gaffney wrote: > Jorge Arellano Cid <jcid at dillo.org> writes: > > > Hi Johannes, JG: > > > [...] > > The attached program is a stress test for SIGCHLD. The idea is to > > find a formula that works well even in such cases. IIRC both of you > > have access to BSD machines so please test it there. > > > > The program spawns 255 children which sleep 5 seconds and > > terminate generating a SIGCHLD avalanche, which should be handled > > cleanly. It works OK in Debian. > [...] > > 1) OpenBSD is very strict about compliance with standards, so that, > whereas on my (and I believe most if not all) Linux systems wait.h > occurs redundantly in /usr/include/ and /usr/include/sys, on > OpenBSD wait.h is solely in /usr/include/sys and your code will not > compile unless the `#include<wait.h>' line is removed. Then `gcc > -W -Wall' compiles it without complaint. > > 2) OpenSBD is not so extravagant with the resources allocated to > unprivileged users (max 128 processes). But spawning 64 rather > than 256 children the test is passed with the expected behavior on > OpenBSD 5.2 GENERIC.MP#368 amd64. > > The OpenBSD 5.2 ports include Dillo 2.2 and FLTK2, but I just recently > compiled FLTK 1.3.2 and Dillo 3.0.3 from their unmodified source on > that machine without (IIRC) any errors. If you were curious more > generally to see how they are modifying the Dillo source, the OpenBSD > patches for Dillo 3.0.3 (the version currently in ports for OpenBSD > 5.3) may be found at > > http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/ Thanks a lot, very informative. -- Cheers Jorge.-

Aug. 31, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jgaffney＠lawrenceville.org

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi Johannes, JG: > [...] > The attached program is a stress test for SIGCHLD. The idea is to > find a formula that works well even in such cases. IIRC both of you > have access to BSD machines so please test it there. > > The program spawns 255 children which sleep 5 seconds and > terminate generating a SIGCHLD avalanche, which should be handled > cleanly. It works OK in Debian. [...] 1) OpenBSD is very strict about compliance with standards, so that, whereas on my (and I believe most if not all) Linux systems wait.h occurs redundantly in /usr/include/ and /usr/include/sys, on OpenBSD wait.h is solely in /usr/include/sys and your code will not compile unless the `#include<wait.h>' line is removed. Then `gcc -W -Wall' compiles it without complaint. 2) OpenSBD is not so extravagant with the resources allocated to unprivileged users (max 128 processes). But spawning 64 rather than 256 children the test is passed with the expected behavior on OpenBSD 5.2 GENERIC.MP#368 amd64. The OpenBSD 5.2 ports include Dillo 2.2 and FLTK2, but I just recently compiled FLTK 1.3.2 and Dillo 3.0.3 from their unmodified source on that machine without (IIRC) any errors. If you were curious more generally to see how they are modifying the Dillo source, the OpenBSD patches for Dillo 3.0.3 (the version currently in ports for OpenBSD 5.3) may be found at http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/

Aug. 31, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

Hi Johannes, JG: On Thu, Aug 29, 2013 at 09:13:49AM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > > Hi JG, > > > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > > are not reaped when they terminate themselves after a period of > > > > inactivity while the parent dillo process is still running. The patch > > > > below is simply to reap these zombies. The SIGCHLD handler should > > > > probably do more, but I am not yet familiar enough with Dillo to know > > > > what. > > > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > > am new to the list and a novice at Dillo patching. And hence also > > > > apologies to Jorge for this duplication of a previous communication by > > > > private email (although with one small change to get the patch to > > > > compile under OpenBSD as well as Linux). > > > > > > I can reproduce the issue here by killing dpid manually. > > > For me the following also fixes it: > > > > > > diff -r 659dc205c377 src/dillo.cc > > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > > @@ -329,6 +329,7 @@ > > > > > > // Some OSes exit dillo without this (not GNU/Linux). > > > signal(SIGPIPE, SIG_IGN); > > > + signal(SIGCHLD, SIG_IGN); > > > > > > /* Handle command line options */ > > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > > > Can you please check whether it works for you too? It would have the > > > advantage that we have all signal related stuff in one place. > > > > Oh, I'm looking at it now too! > > For me this is an old TODO: with subtle issues lurking. > > > > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > > > > After some digging (Manual page sigaction(2)): > > > > ... > > > > "A child created via fork(2) inherits a copy of its parent's > > signal dispositions. During an execve(2), the dispositions of > > handled signals are reset to the default; the dispositions of > > ignored signals are left unchanged." > > I guess this is no problem, as dpid explicitely adds a signal > handler for SIGCHLD again, but I'm happy if you take care of the > whole issue :-) The attached program is a stress test for SIGCHLD. The idea is to find a formula that works well even in such cases. IIRC both of you have access to BSD machines so please test it there. The program spawns 255 children which sleep 5 seconds and terminate generating a SIGCHLD avalanche, which should be handled cleanly. It works OK in Debian. $gcc -W -Wall sigcld.c -o sigcld $./sigcld in another terminal (during the 5 secs. sleep window): $ps aux|grep sigcld (shows the long list) then while main is Sleeping 10 seconds: $ps aux|grep sigcld (shows only one sigcld process) after it exits: $ps aux|grep sigcld (no process left) TIA. -- Cheers Jorge.-

Aug. 30, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by johannes.hofmann＠gmx.de

Hi Jorge, On Wed, Aug 28, 2013 at 08:48:35PM -0400, Jorge Arellano Cid wrote: > Hi, > > On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > > Hi JG, > > > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > > are not reaped when they terminate themselves after a period of > > > inactivity while the parent dillo process is still running. The patch > > > below is simply to reap these zombies. The SIGCHLD handler should > > > probably do more, but I am not yet familiar enough with Dillo to know > > > what. > > > > > > I believe this patch adheres to the Dillo rules of coding style, but > > > am new to the list and a novice at Dillo patching. And hence also > > > apologies to Jorge for this duplication of a previous communication by > > > private email (although with one small change to get the patch to > > > compile under OpenBSD as well as Linux). > > > > I can reproduce the issue here by killing dpid manually. > > For me the following also fixes it: > > > > diff -r 659dc205c377 src/dillo.cc > > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > > @@ -329,6 +329,7 @@ > > > > // Some OSes exit dillo without this (not GNU/Linux). > > signal(SIGPIPE, SIG_IGN); > > + signal(SIGCHLD, SIG_IGN); > > > > /* Handle command line options */ > > opt_argv = dNew0(char*, numOptions(Options) + 1); > > > > Can you please check whether it works for you too? It would have the > > advantage that we have all signal related stuff in one place. > > Oh, I'm looking at it now too! > For me this is an old TODO: with subtle issues lurking. > > > Somehow, setting SIG_IGN to a child rings me wrong... :-) > > > After some digging (Manual page sigaction(2)): > > ... > > "A child created via fork(2) inherits a copy of its parent's > signal dispositions. During an execve(2), the dispositions of > handled signals are reset to the default; the dispositions of > ignored signals are left unchanged." I guess this is no problem, as dpid explicitely adds a signal handler for SIGCHLD again, but I'm happy if you take care of the whole issue :-) Cheers, Johannes

Aug. 29, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jcid＠dillo.org

Hi, On Wed, Aug 28, 2013 at 07:51:34PM +0200, Johannes Hofmann wrote: > Hi JG, > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > > are not reaped when they terminate themselves after a period of > > inactivity while the parent dillo process is still running. The patch > > below is simply to reap these zombies. The SIGCHLD handler should > > probably do more, but I am not yet familiar enough with Dillo to know > > what. > > > > I believe this patch adheres to the Dillo rules of coding style, but > > am new to the list and a novice at Dillo patching. And hence also > > apologies to Jorge for this duplication of a previous communication by > > private email (although with one small change to get the patch to > > compile under OpenBSD as well as Linux). > > I can reproduce the issue here by killing dpid manually. > For me the following also fixes it: > > diff -r 659dc205c377 src/dillo.cc > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > @@ -329,6 +329,7 @@ > > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > + signal(SIGCHLD, SIG_IGN); > > /* Handle command line options */ > opt_argv = dNew0(char*, numOptions(Options) + 1); > > Can you please check whether it works for you too? It would have the > advantage that we have all signal related stuff in one place. Oh, I'm looking at it now too! For me this is an old TODO: with subtle issues lurking. Somehow, setting SIG_IGN to a child rings me wrong... :-) After some digging (Manual page sigaction(2)): ... "A child created via fork(2) inherits a copy of its parent's signal dispositions. During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged." ... " POSIX.1-1990 disallowed setting the action for SIGCHLD to SIG_IGN. POSIX.1-2001 allows this possibility, so that ignoring SIGCHLD can be used to prevent the creation of zombies (see wait(2)). Nevertheless, the historical BSD and System V behaviors for ignoring SIGCHLD differ, so that the only completely portable method of ensuring that terminated children do not become zombies is to catch the SIGCHLD signal and perform a wait(2) or similar." So, I'm more inclined to using the same method as in dpid and downloads.dpi ... -- Cheers Jorge.-

Aug. 29, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jgaffney＠lawrenceville.org

Johannes Hofmann <Johannes.Hofmann at gmx.de> writes: > Hi JG, > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: >> It seems that the dpid children forked by Dpi_start_dpid() in dpi.c >> are not reaped when they terminate themselves after a period of >> inactivity while the parent dillo process is still running. The patch >> below is simply to reap these zombies. The SIGCHLD handler should >> probably do more, but I am not yet familiar enough with Dillo to know >> what. >> >> I believe this patch adheres to the Dillo rules of coding style, but >> am new to the list and a novice at Dillo patching. And hence also >> apologies to Jorge for this duplication of a previous communication by >> private email (although with one small change to get the patch to >> compile under OpenBSD as well as Linux). > > I can reproduce the issue here by killing dpid manually. > For me the following also fixes it: > > diff -r 659dc205c377 src/dillo.cc > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > @@ -329,6 +329,7 @@ > > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > + signal(SIGCHLD, SIG_IGN); > > /* Handle command line options */ > opt_argv = dNew0(char*, numOptions(Options) + 1); > > Can you please check whether it works for you too? It would have the > advantage that we have all signal related stuff in one place. > > Cheers, > Johannes Thank you: your solution is of course not only correct but far simpler and better. (Though I thought that in general sigaction() is to be preferred to signal()?)

Aug. 29, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by Johannes.Hofmann＠gmx.de

Hi JG, On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: > It seems that the dpid children forked by Dpi_start_dpid() in dpi.c > are not reaped when they terminate themselves after a period of > inactivity while the parent dillo process is still running. The patch > below is simply to reap these zombies. The SIGCHLD handler should > probably do more, but I am not yet familiar enough with Dillo to know > what. > > I believe this patch adheres to the Dillo rules of coding style, but > am new to the list and a novice at Dillo patching. And hence also > apologies to Jorge for this duplication of a previous communication by > private email (although with one small change to get the patch to > compile under OpenBSD as well as Linux). I can reproduce the issue here by killing dpid manually. For me the following also fixes it: diff -r 659dc205c377 src/dillo.cc --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 @@ -329,6 +329,7 @@ // Some OSes exit dillo without this (not GNU/Linux). signal(SIGPIPE, SIG_IGN); + signal(SIGCHLD, SIG_IGN); /* Handle command line options */ opt_argv = dNew0(char*, numOptions(Options) + 1); Can you please check whether it works for you too? It would have the advantage that we have all signal related stuff in one place. Cheers, Johannes

Aug. 28, 2013

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c

by jgaffney＠lawrenceville.org

It seems that the dpid children forked by Dpi_start_dpid() in dpi.c are not reaped when they terminate themselves after a period of inactivity while the parent dillo process is still running. The patch below is simply to reap these zombies. The SIGCHLD handler should probably do more, but I am not yet familiar enough with Dillo to know what. I believe this patch adheres to the Dillo rules of coding style, but am new to the list and a novice at Dillo patching. And hence also apologies to Jorge for this duplication of a previous communication by private email (although with one small change to get the patch to compile under OpenBSD as well as Linux). ######## BEGIN PATCH ######## --- a/src/IO/dpi.c 2013-01-27 12:26:38.000000000 -0500 +++ b/src/IO/dpi.c 2013-08-27 14:58:07.995235867 -0400 @@ -33,6 +33,8 @@ #include <netinet/tcp.h> #include <arpa/inet.h> #include <netdb.h> +#include <sys/wait.h> +#include <signal.h> #include "../msg.h" #include "../klist.h" @@ -331,16 +333,33 @@ } } +static void Sigchld_handler (int signum) { + int status; + waitpid (-1, &status, WNOHANG); + } + /* * Start dpid. * Return: 0 starting now, 1 Error. */ static int Dpi_start_dpid(void) { + static int install_sigchld_handler_flag = TRUE; pid_t pid; int st_pipe[2], ret = 1; char *answer; + if ( install_sigchld_handler_flag ) { + /* Install SIGCHLD handler. */ + struct sigaction sa; + sa.sa_handler = Sigchld_handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_RESTART | SA_NOCLDSTOP; + if (sigaction(SIGCHLD, &sa, 0)) + MSG ("Unable to install SIGCHLD handler.\n"); + install_sigchld_handler_flag = FALSE; + } + /* create a pipe to track our child's status */ if (pipe(st_pipe)) return 1; ######## END PATCH ########

Aug. 27, 2013

allow_white_bg

by sgeerken＠dillo.org

On Mo, Aug 19, 2013, Sebastian Geerken wrote: > On Mo, Aug 19, 2013, Johannes Hofmann wrote: > > > It seems that I'm getting old that I tried to set the option > > > "allow_white_bg" to "false"; to find out that the replacement color is > > > hardcoded! If I haven't missed something, and noone objets, I'll add a > > > prefs variable "white_bg_replacement". > > > > Sounds good. white_bg_replacement would replace allow_white_bg, right? > > Currently, I've added another option, so you must specify something > like: > > allow_white_bg=NO > white_bg_replacement=0xf0f0d0 > > The standard for white_bg_replacement is 0xe0e0a3, the value > hard-coded before. > > Your suggestion sounds good to[o], only to specify white_bg_replacement, > which has a standard value of "undefined". I'm open to both. I've pushed my variant (two variables); feel free to change. Back to floats ... Sebastian

Aug. 21, 2013

allow_white_bg

by sgeerken＠dillo.org

On Mo, Aug 19, 2013, Johannes Hofmann wrote: > > It seems that I'm getting old that I tried to set the option > > "allow_white_bg" to "false"; to find out that the replacement color is > > hardcoded! If I haven't missed something, and noone objets, I'll add a > > prefs variable "white_bg_replacement". > > Sounds good. white_bg_replacement would replace allow_white_bg, right? Currently, I've added another option, so you must specify something like: allow_white_bg=NO white_bg_replacement=0xf0f0d0 The standard for white_bg_replacement is 0xe0e0a3, the value hard-coded before. Your suggestion sounds good to, only to specify white_bg_replacement, which has a standard value of "undefined". I'm open to both. Sebastian

Aug. 19, 2013

allow_white_bg

by Johannes.Hofmann＠gmx.de

Hi Sebastian, > Gesendet: Montag, 19. August 2013 um 10:32 Uhr > Von: "Sebastian Geerken" <sgeerken at dillo.org> > An: dillo-dev at dillo.org > Betreff: [Dillo-dev] allow_white_bg > > Hi! > > It seems that I'm getting old that I tried to set the option > "allow_white_bg" to "false"; to find out that the replacement color is > hardcoded! If I haven't missed something, and noone objets, I'll add a > prefs variable "white_bg_replacement". Sounds good. white_bg_replacement would replace allow_white_bg, right? > > BTW: is there a reason that there is still a prefs variable > "bg_color", while fonts (the actual fonts, not the font classes) are > now defined by CSS? There are some differences in behavior between setting bg_color option and having body {background-color: <something>} in style.css. I'm not sure whether they justify the existence of the bg_color option. But I can't really decide, as I don't use bg_color normally. Cheers, Johannes

Aug. 19, 2013

allow_white_bg

by sgeerken＠dillo.org

Hi! It seems that I'm getting old that I tried to set the option "allow_white_bg" to "false"; to find out that the replacement color is hardcoded! If I haven't missed something, and noone objets, I'll add a prefs variable "white_bg_replacement". BTW: is there a reason that there is still a prefs variable "bg_color", while fonts (the actual fonts, not the font classes) are now defined by CSS? Sebastian

Aug. 19, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

On Tue, Jul 23, 2013 at 12:39:30PM -0400, Jorge Arellano Cid wrote: > On Sun, Jul 21, 2013 at 07:19:16PM +0200, Johannes Hofmann wrote: > > yOn Fri, Jul 19, 2013 at 11:22:36AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Jul 18, 2013 at 11:06:36PM +0200, Johannes Hofmann wrote: > > > > On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote: > > > > > On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > > > > > > Hi Johannes, > > > > > > > > > > > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > > > > > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > > > > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > > > > > > Johannes wrote: > > > > > > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > > > > > > would be to interpret url strings which start with the name of a search > > > > > > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > > > > > > else find this feature useful. > > > > > > > > > > > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > > > > > > as in the slightly modified patch below. > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > This is good, although there's a leading space in the search text that > > > > > > > > > some of my search sites don't like. > > > > > > > > > > > > > > > > The leading space should of course not be part of the search term. > > > > > > > > > > > > > > If nobody objects I will commit this tomorrow. > > > > > > > > > > > > The current format for search_url in a_Misc_parse_search_url() is: > > > > > > > > > > > > "[<label> ]<url>" > > > > > > > > > > > > IMHO, it'd be much better to have it this way in the patch: > > > > > > > > > > > > "[<label[:abbr]> ]<url>" > > > > > > > > > > > > where "abbr" means abbreviation. e.g. > > > > > > > > > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > > > > > > > > > > that way I could search "slick" from the location box like this: > > > > > > > > > > > > fd slick > > > > > > > > > > > > and keep the descriptive names for the GUI interface. > > > > > > > > > > The idea of the proposed patch is to allow arbitrary prefixes of the > > > > > descriptive names as shortcuts, so > > > > > > > > > > goo dillo > > > > > duck dillo > > > > > > > > > > but also > > > > > > > > > > g dillo > > > > > d dillo > > > > > > > > > > would work without further configuration work. In case there is more > > > > > than one match, the first wins. > > > > > > > > Does this make sense or should do you prefer explicit configurable > > > > shortcuts? > > > > > > It makes sense, but I prefer the configurable shortcuts. > > > > > > For instance, I have: > > > > > > search_url="Free Dictionary http://www.thefreedictionary.com/%s" > > > search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s" > > > > > > and would like to be able to set it this way: > > > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > search_url="Free Dictionary (es):fde http://es.thefreedictionary.com/%s" > > > > > > > Ok, it makes sense to be able to optionally specify a shortcut, but > > I'm a bit worried that the syntax of the search_url field get's more > > and more complicated. We already have the ' ' as separator between > > title and url, now we add a ':'. > > I see two options: > > > > * We stick with title and url only and for your example one would > > use: > > search_url="fd Free Dictionary http://www.thefreedictionary.com/%s" > > search_url="fde Free Dictionary (es) http://es.thefreedictionary.com/%s" > > and live with the "fd" and "fde" shortcurts beeing displayed as > > part of the title. > > I like this idea. It's simple and allows us to feel-test the solution. > > > * Or we enhance the prefs parser and somehow have separate fields > > for url, title, and shortcut, i.e. something like that: > > search_url="http://www.thefreedictionary.com/%s" > > search_title="Free Dictionary" > > search_shortcut="fd" > > where these three fields would have to be grouped together > > in some way. > > This is more complicated and may not be worth the effort. Committed! Cheers, Johannes

July 23, 2013

Search from address bar

by jcid＠dillo.org

On Sun, Jul 21, 2013 at 07:19:16PM +0200, Johannes Hofmann wrote: > yOn Fri, Jul 19, 2013 at 11:22:36AM -0400, Jorge Arellano Cid wrote: > > On Thu, Jul 18, 2013 at 11:06:36PM +0200, Johannes Hofmann wrote: > > > On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote: > > > > On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > > > > > Hi Johannes, > > > > > > > > > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > > > > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > > > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > > > > > Johannes wrote: > > > > > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > > > > > would be to interpret url strings which start with the name of a search > > > > > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > > > > > else find this feature useful. > > > > > > > > > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > > > > > as in the slightly modified patch below. > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > This is good, although there's a leading space in the search text that > > > > > > > > some of my search sites don't like. > > > > > > > > > > > > > > The leading space should of course not be part of the search term. > > > > > > > > > > > > If nobody objects I will commit this tomorrow. > > > > > > > > > > The current format for search_url in a_Misc_parse_search_url() is: > > > > > > > > > > "[<label> ]<url>" > > > > > > > > > > IMHO, it'd be much better to have it this way in the patch: > > > > > > > > > > "[<label[:abbr]> ]<url>" > > > > > > > > > > where "abbr" means abbreviation. e.g. > > > > > > > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > > > > > > > > that way I could search "slick" from the location box like this: > > > > > > > > > > fd slick > > > > > > > > > > and keep the descriptive names for the GUI interface. > > > > > > > > The idea of the proposed patch is to allow arbitrary prefixes of the > > > > descriptive names as shortcuts, so > > > > > > > > goo dillo > > > > duck dillo > > > > > > > > but also > > > > > > > > g dillo > > > > d dillo > > > > > > > > would work without further configuration work. In case there is more > > > > than one match, the first wins. > > > > > > Does this make sense or should do you prefer explicit configurable > > > shortcuts? > > > > It makes sense, but I prefer the configurable shortcuts. > > > > For instance, I have: > > > > search_url="Free Dictionary http://www.thefreedictionary.com/%s" > > search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s" > > > > and would like to be able to set it this way: > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > search_url="Free Dictionary (es):fde http://es.thefreedictionary.com/%s" > > > > Ok, it makes sense to be able to optionally specify a shortcut, but > I'm a bit worried that the syntax of the search_url field get's more > and more complicated. We already have the ' ' as separator between > title and url, now we add a ':'. > I see two options: > > * We stick with title and url only and for your example one would > use: > search_url="fd Free Dictionary http://www.thefreedictionary.com/%s" > search_url="fde Free Dictionary (es) http://es.thefreedictionary.com/%s" > and live with the "fd" and "fde" shortcurts beeing displayed as > part of the title. I like this idea. It's simple and allows us to feel-test the solution. > * Or we enhance the prefs parser and somehow have separate fields > for url, title, and shortcut, i.e. something like that: > search_url="http://www.thefreedictionary.com/%s" > search_title="Free Dictionary" > search_shortcut="fd" > where these three fields would have to be grouped together > in some way. This is more complicated and may not be worth the effort. -- Cheers Jorge.-

July 23, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

yOn Fri, Jul 19, 2013 at 11:22:36AM -0400, Jorge Arellano Cid wrote: > On Thu, Jul 18, 2013 at 11:06:36PM +0200, Johannes Hofmann wrote: > > On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote: > > > On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > > > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > > > > would be to interpret url strings which start with the name of a search > > > > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > > > > else find this feature useful. > > > > > > > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > > > > as in the slightly modified patch below. > > > > > > > > What do you think? > > > > > > > > > > > > > > This is good, although there's a leading space in the search text that > > > > > > > some of my search sites don't like. > > > > > > > > > > > > The leading space should of course not be part of the search term. > > > > > > > > > > If nobody objects I will commit this tomorrow. > > > > > > > > The current format for search_url in a_Misc_parse_search_url() is: > > > > > > > > "[<label> ]<url>" > > > > > > > > IMHO, it'd be much better to have it this way in the patch: > > > > > > > > "[<label[:abbr]> ]<url>" > > > > > > > > where "abbr" means abbreviation. e.g. > > > > > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > > > > > > that way I could search "slick" from the location box like this: > > > > > > > > fd slick > > > > > > > > and keep the descriptive names for the GUI interface. > > > > > > The idea of the proposed patch is to allow arbitrary prefixes of the > > > descriptive names as shortcuts, so > > > > > > goo dillo > > > duck dillo > > > > > > but also > > > > > > g dillo > > > d dillo > > > > > > would work without further configuration work. In case there is more > > > than one match, the first wins. > > > > Does this make sense or should do you prefer explicit configurable > > shortcuts? > > It makes sense, but I prefer the configurable shortcuts. > > For instance, I have: > > search_url="Free Dictionary http://www.thefreedictionary.com/%s" > search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s" > > and would like to be able to set it this way: > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > search_url="Free Dictionary (es):fde http://es.thefreedictionary.com/%s" > Ok, it makes sense to be able to optionally specify a shortcut, but I'm a bit worried that the syntax of the search_url field get's more and more complicated. We already have the ' ' as separator between title and url, now we add a ':'. I see two options: * We stick with title and url only and for your example one would use: search_url="fd Free Dictionary http://www.thefreedictionary.com/%s" search_url="fde Free Dictionary (es) http://es.thefreedictionary.com/%s" and live with the "fd" and "fde" shortcurts beeing displayed as part of the title. * Or we enhance the prefs parser and somehow have separate fields for url, title, and shortcut, i.e. something like that: search_url="http://www.thefreedictionary.com/%s" search_title="Free Dictionary" search_shortcut="fd" where these three fields would have to be grouped together in some way. Cheers, Johannes

July 21, 2013

Search from address bar

by jcid＠dillo.org

On Thu, Jul 18, 2013 at 11:06:36PM +0200, Johannes Hofmann wrote: > On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote: > > On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > > > would be to interpret url strings which start with the name of a search > > > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > > > else find this feature useful. > > > > > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > > > as in the slightly modified patch below. > > > > > > > What do you think? > > > > > > > > > > > > This is good, although there's a leading space in the search text that > > > > > > some of my search sites don't like. > > > > > > > > > > The leading space should of course not be part of the search term. > > > > > > > > If nobody objects I will commit this tomorrow. > > > > > > The current format for search_url in a_Misc_parse_search_url() is: > > > > > > "[<label> ]<url>" > > > > > > IMHO, it'd be much better to have it this way in the patch: > > > > > > "[<label[:abbr]> ]<url>" > > > > > > where "abbr" means abbreviation. e.g. > > > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > > > > that way I could search "slick" from the location box like this: > > > > > > fd slick > > > > > > and keep the descriptive names for the GUI interface. > > > > The idea of the proposed patch is to allow arbitrary prefixes of the > > descriptive names as shortcuts, so > > > > goo dillo > > duck dillo > > > > but also > > > > g dillo > > d dillo > > > > would work without further configuration work. In case there is more > > than one match, the first wins. > > Does this make sense or should do you prefer explicit configurable > shortcuts? It makes sense, but I prefer the configurable shortcuts. For instance, I have: search_url="Free Dictionary http://www.thefreedictionary.com/%s" search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s" and would like to be able to set it this way: search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" search_url="Free Dictionary (es):fde http://es.thefreedictionary.com/%s" -- Cheers Jorge.-

July 19, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote: > On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > > would be to interpret url strings which start with the name of a search > > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > > else find this feature useful. > > > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > > as in the slightly modified patch below. > > > > > > What do you think? > > > > > > > > > > This is good, although there's a leading space in the search text that > > > > > some of my search sites don't like. > > > > > > > > The leading space should of course not be part of the search term. > > > > > > If nobody objects I will commit this tomorrow. > > > > The current format for search_url in a_Misc_parse_search_url() is: > > > > "[<label> ]<url>" > > > > IMHO, it'd be much better to have it this way in the patch: > > > > "[<label[:abbr]> ]<url>" > > > > where "abbr" means abbreviation. e.g. > > > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > > > that way I could search "slick" from the location box like this: > > > > fd slick > > > > and keep the descriptive names for the GUI interface. > > The idea of the proposed patch is to allow arbitrary prefixes of the > descriptive names as shortcuts, so > > goo dillo > duck dillo > > but also > > g dillo > d dillo > > would work without further configuration work. In case there is more > than one match, the first wins. Does this make sense or should do you prefer explicit configurable shortcuts? Cheers, Johannes

July 18, 2013

Search from address bar

by johannes.hofmann＠gmx.de

On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > > Hi, > > > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > > would be to interpret url strings which start with the name of a search > > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > > else find this feature useful. > > > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > > your idea to reuse the search engine name to derive the shortcut. > > > > > However, I would allow arbitrary prefixes of the search engine name > > > > > as in the slightly modified patch below. > > > > > What do you think? > > > > > > > > This is good, although there's a leading space in the search text that > > > > some of my search sites don't like. > > > > > > The leading space should of course not be part of the search term. > > > > If nobody objects I will commit this tomorrow. > > The current format for search_url in a_Misc_parse_search_url() is: > > "[<label> ]<url>" > > IMHO, it'd be much better to have it this way in the patch: > > "[<label[:abbr]> ]<url>" > > where "abbr" means abbreviation. e.g. > > search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" > > that way I could search "slick" from the location box like this: > > fd slick > > and keep the descriptive names for the GUI interface. The idea of the proposed patch is to allow arbitrary prefixes of the descriptive names as shortcuts, so goo dillo duck dillo but also g dillo d dillo would work without further configuration work. In case there is more than one match, the first wins. Cheers, Johannes

July 10, 2013

Search from address bar

by jcid＠dillo.org

Hi Johannes, On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > Hi, > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > would be to interpret url strings which start with the name of a search > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > else find this feature useful. > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > your idea to reuse the search engine name to derive the shortcut. > > > > However, I would allow arbitrary prefixes of the search engine name > > > > as in the slightly modified patch below. > > > > What do you think? > > > > > > This is good, although there's a leading space in the search text that > > > some of my search sites don't like. > > > > The leading space should of course not be part of the search term. > > If nobody objects I will commit this tomorrow. The current format for search_url in a_Misc_parse_search_url() is: "[<label> ]<url>" IMHO, it'd be much better to have it this way in the patch: "[<label[:abbr]> ]<url>" where "abbr" means abbreviation. e.g. search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" that way I could search "slick" from the location box like this: fd slick and keep the descriptive names for the GUI interface. -- Cheers Jorge.-

July 9, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > Johannes wrote: > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > Hi, > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > has a customizable list of engines in preferences, so one natural solution > > > > would be to interpret url strings which start with the name of a search > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > else find this feature useful. > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > your idea to reuse the search engine name to derive the shortcut. > > > However, I would allow arbitrary prefixes of the search engine name > > > as in the slightly modified patch below. > > > What do you think? > > > > This is good, although there's a leading space in the search text that > > some of my search sites don't like. > > The leading space should of course not be part of the search term. If nobody objects I will commit this tomorrow. Johannes

July 9, 2013

line wrapping

by sgeerken＠dillo.org

On Sa, Jun 29, 2013, Johannes Hofmann wrote: > On Fri, Jun 28, 2013 at 05:08:13PM +0200, Sebastian Geerken wrote: > > On Do, Jun 27, 2013, Johannes Hofmann wrote: > > > On Thu, Jun 27, 2013 at 07:20:23PM +0200, Sebastian Geerken wrote: > > > > On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > > > > > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > > > > > On Mi, Jun 19, 2013, corvid wrote: > > > > > > > I noticed that lines aren't wrapping for me with > > > > > > > http://www.dillo.org/FAQ.html . > > > > > > > hg bisect says that it started with: > > > > > > > > > > > > > > changeset: 2838:b2b239eb45b9 > > > > > > > summary: Fixed problem with hyphenation. > > > > > > > > > > > > Fixed. I didn't fully understand the problem, but the latest change > > > > > > makes sense and solves the problem. > > > > > > > > > > After updating to hg tip, the problem persists for me... > > > > > > > > With revision 2861:686f563e96d4? How does it look like? (Perhaps send > > > > a screenshot, or scp it to dillo.org.) > > > > > > > > How does the attached page look like? What experiences do other users > > > > make? > > > > > > The only difference I noticed compared to firefox is that dillo > > > doesn't seem to line-break stuff in the inner boxes (e.g. > > > "body {background-color: purple}") > > > I can't really say whether it should though. > > > > What do you mean with "inner boxes"? BTW, I do not see any difference > > between Firefox (Iceweasel 10.0.12) and dillo revision 2861. > > > > What about <http://www.dillo.org/FAQ.html>? > > I meant the "inner boxes" on http://www.dillo.org/FAQ.html. E.g the > one containing "body {background-color: purple}". > > That one doesn't line break for me in dillo, but does so in firefox. > But I don't know whether this is the thing Jorge was talking about > in his initial post. As far as I see, this is because the maximal width of these "inner boxes" is larger than the minimal width of the "outer box", which is defined by a wider "pre" section. The differences should depend on fonts etc. Anyway, Jorge has confirmed that his problem has been fixed by my latest change. I hope that also some other glitches (which can be seen but are hard to define precisely) have gone. Sebastian

July 2, 2013

line wrapping

by jcid＠dillo.org

On Sat, Jun 29, 2013 at 06:30:09PM +0200, Johannes Hofmann wrote: > On Fri, Jun 28, 2013 at 05:08:13PM +0200, Sebastian Geerken wrote: > > On Do, Jun 27, 2013, Johannes Hofmann wrote: > > > On Thu, Jun 27, 2013 at 07:20:23PM +0200, Sebastian Geerken wrote: > > > > On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > > > > > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > > > > > On Mi, Jun 19, 2013, corvid wrote: > > > > > > > I noticed that lines aren't wrapping for me with > > > > > > > http://www.dillo.org/FAQ.html . > > > > > > > hg bisect says that it started with: > > > > > > > > > > > > > > changeset: 2838:b2b239eb45b9 > > > > > > > summary: Fixed problem with hyphenation. > > > > > > > > > > > > Fixed. I didn't fully understand the problem, but the latest change > > > > > > makes sense and solves the problem. > > > > > > > > > > After updating to hg tip, the problem persists for me... > > > > > > > > With revision 2861:686f563e96d4? How does it look like? (Perhaps send > > > > a screenshot, or scp it to dillo.org.) > > > > > > > > How does the attached page look like? What experiences do other users > > > > make? > > > > > > The only difference I noticed compared to firefox is that dillo > > > doesn't seem to line-break stuff in the inner boxes (e.g. > > > "body {background-color: purple}") > > > I can't really say whether it should though. > > > > What do you mean with "inner boxes"? BTW, I do not see any difference > > between Firefox (Iceweasel 10.0.12) and dillo revision 2861. > > > > What about <http://www.dillo.org/FAQ.html>? > > I meant the "inner boxes" on http://www.dillo.org/FAQ.html. E.g the > one containing "body {background-color: purple}". > > That one doesn't line break for me in dillo, but does so in firefox. > But I don't know whether this is the thing Jorge was talking about > in his initial post. FYI, I managed to reduce the test page to under 1KB, sent it to Sebastian along with some debug info, and two interesting facts that pinpoint much better what's going on. For instance, I had: pre {white-space: pre-wrap} in my .dillo/style.css, commenting it avoids the bug. There's also a DIV element in the test page with lang=en, setting lang to "de", but keeping my style.css, also avoids the bug. Setting lang to "es" also shows the bug. -- Cheers Jorge.-

June 29, 2013

line wrapping

by Johannes.Hofmann＠gmx.de

On Fri, Jun 28, 2013 at 05:08:13PM +0200, Sebastian Geerken wrote: > On Do, Jun 27, 2013, Johannes Hofmann wrote: > > On Thu, Jun 27, 2013 at 07:20:23PM +0200, Sebastian Geerken wrote: > > > On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > > > > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > > > > On Mi, Jun 19, 2013, corvid wrote: > > > > > > I noticed that lines aren't wrapping for me with > > > > > > http://www.dillo.org/FAQ.html . > > > > > > hg bisect says that it started with: > > > > > > > > > > > > changeset: 2838:b2b239eb45b9 > > > > > > summary: Fixed problem with hyphenation. > > > > > > > > > > Fixed. I didn't fully understand the problem, but the latest change > > > > > makes sense and solves the problem. > > > > > > > > After updating to hg tip, the problem persists for me... > > > > > > With revision 2861:686f563e96d4? How does it look like? (Perhaps send > > > a screenshot, or scp it to dillo.org.) > > > > > > How does the attached page look like? What experiences do other users > > > make? > > > > The only difference I noticed compared to firefox is that dillo > > doesn't seem to line-break stuff in the inner boxes (e.g. > > "body {background-color: purple}") > > I can't really say whether it should though. > > What do you mean with "inner boxes"? BTW, I do not see any difference > between Firefox (Iceweasel 10.0.12) and dillo revision 2861. > > What about <http://www.dillo.org/FAQ.html>? I meant the "inner boxes" on http://www.dillo.org/FAQ.html. E.g the one containing "body {background-color: purple}". That one doesn't line break for me in dillo, but does so in firefox. But I don't know whether this is the thing Jorge was talking about in his initial post. Johannes

June 29, 2013

line wrapping

by sgeerken＠dillo.org

On Do, Jun 27, 2013, Johannes Hofmann wrote: > On Thu, Jun 27, 2013 at 07:20:23PM +0200, Sebastian Geerken wrote: > > On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > > > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > > > On Mi, Jun 19, 2013, corvid wrote: > > > > > I noticed that lines aren't wrapping for me with > > > > > http://www.dillo.org/FAQ.html . > > > > > hg bisect says that it started with: > > > > > > > > > > changeset: 2838:b2b239eb45b9 > > > > > summary: Fixed problem with hyphenation. > > > > > > > > Fixed. I didn't fully understand the problem, but the latest change > > > > makes sense and solves the problem. > > > > > > After updating to hg tip, the problem persists for me... > > > > With revision 2861:686f563e96d4? How does it look like? (Perhaps send > > a screenshot, or scp it to dillo.org.) > > > > How does the attached page look like? What experiences do other users > > make? > > The only difference I noticed compared to firefox is that dillo > doesn't seem to line-break stuff in the inner boxes (e.g. > "body {background-color: purple}") > I can't really say whether it should though. What do you mean with "inner boxes"? BTW, I do not see any difference between Firefox (Iceweasel 10.0.12) and dillo revision 2861. What about <http://www.dillo.org/FAQ.html>? Sebastian

June 28, 2013

line wrapping

by Johannes.Hofmann＠gmx.de

On Thu, Jun 27, 2013 at 07:20:23PM +0200, Sebastian Geerken wrote: > On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > > On Mi, Jun 19, 2013, corvid wrote: > > > > I noticed that lines aren't wrapping for me with > > > > http://www.dillo.org/FAQ.html . > > > > hg bisect says that it started with: > > > > > > > > changeset: 2838:b2b239eb45b9 > > > > summary: Fixed problem with hyphenation. > > > > > > Fixed. I didn't fully understand the problem, but the latest change > > > makes sense and solves the problem. > > > > After updating to hg tip, the problem persists for me... > > With revision 2861:686f563e96d4? How does it look like? (Perhaps send > a screenshot, or scp it to dillo.org.) > > How does the attached page look like? What experiences do other users > make? The only difference I noticed compared to firefox is that dillo doesn't seem to line-break stuff in the inner boxes (e.g. "body {background-color: purple}") I can't really say whether it should though. Johannes

June 27, 2013

line wrapping

by sgeerken＠dillo.org

On Mi, Jun 26, 2013, Jorge Arellano Cid wrote: > On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > > On Mi, Jun 19, 2013, corvid wrote: > > > I noticed that lines aren't wrapping for me with > > > http://www.dillo.org/FAQ.html . > > > hg bisect says that it started with: > > > > > > changeset: 2838:b2b239eb45b9 > > > summary: Fixed problem with hyphenation. > > > > Fixed. I didn't fully understand the problem, but the latest change > > makes sense and solves the problem. > > After updating to hg tip, the problem persists for me... With revision 2861:686f563e96d4? How does it look like? (Perhaps send a screenshot, or scp it to dillo.org.) How does the attached page look like? What experiences do other users make? Sebastian

June 27, 2013

line wrapping

by jcid＠dillo.org

On Wed, Jun 26, 2013 at 05:17:41PM +0200, Sebastian Geerken wrote: > On Mi, Jun 19, 2013, corvid wrote: > > I noticed that lines aren't wrapping for me with > > http://www.dillo.org/FAQ.html . > > hg bisect says that it started with: > > > > changeset: 2838:b2b239eb45b9 > > summary: Fixed problem with hyphenation. > > Fixed. I didn't fully understand the problem, but the latest change > makes sense and solves the problem. After updating to hg tip, the problem persists for me... -- Cheers Jorge.-

June 26, 2013

line wrapping

by sgeerken＠dillo.org

On Mi, Jun 19, 2013, corvid wrote: > I noticed that lines aren't wrapping for me with > http://www.dillo.org/FAQ.html . > hg bisect says that it started with: > > changeset: 2838:b2b239eb45b9 > summary: Fixed problem with hyphenation. Fixed. I didn't fully understand the problem, but the latest change makes sense and solves the problem. Sebastian

June 26, 2013

Rendering problem?

by jcid＠dillo.org

Hi there, James Gholston wrote this: As I dig around unsuccessfully for a type of information, I look at your FAQ and realize the next person might be helped by it being available there. Q: I am trying to develop a web site to be highly compatible with Dillo. Where can I find information on optimization? In my specific case I'm directing Dillo to my HTML 3.2 theme, and Dillo has the highest market share of what I'm sending to it. Complete with a <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> declaration. I have a graphical 'bookmark' in a <TD> element defined both as background="" and as a CSS1 background (nested table layout similar to what I'm using for MSIE 5.5 through 8). Neither works with my copy of Dillo 3 (I just get the solid black fallback color), so I'm assuming it's not working for any other Dillo user. If there are additional Dillo tweaks listed somewhere I didn't think to hunt for I could also try to apply them. Unless I'm testing to see what one of my nine other themes looks like in Dillo at the time, you can gawk at what I'm doing at http://test.moonsociety.org if you want to. Other browsers I'm sending to HTML 3.2 are Netscape 3 and 4, MSIE 3 through 5, and any otherwise unidentifiable browser claiming to be Mozilla 4.0. My other themes look significantly different than the HTML 3.2 theme. Thank you for your time and work on the most available small graphical browser. James Gholston -- Cheers Jorge.-

June 24, 2013

[jamesg@dimensionality.com: I have an addition to the Dillo FAQ]

by jcid＠dillo.org

-- Cheers Jorge.-

June 24, 2013

Can't compile Dillo 3.0.3

by abe＠deuxchevaux.org

Hi, On Mon, Jun 24, 2013 at 09:02:44PM +0900, furaisanjin wrote: > 2013/6/24 Axel Beckert <abe at deuxchevaux.org> > > On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert 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. > > > > On non-linux architectures, there's more than -lX11 necessary. I > > suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not > > sure: > > I got this output from fltk-config --ldflags on FreeBSD 8.2. > > -L/usr/local/lib -R/usr/local/lib -lfltk -lXext -lXft -lfontconfig > -lXinerama -lpthread -lm -lX11 Ah, ok. Thanks for checking! This looks fine, indeed. On Debian GNU/kFreeBSD I just get "-L/usr/lib/i386-kfreebsd-gnu -lfltk". The missing -lX11 seems to be an issue with the libfltk1.3-dev package in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713933 I just checked the minimal example from that bug report. It doesn't seem to need pthreads on kfreebsd despite the string "pthreads" appears in libfltk.a and libfltk.so. I suspect the remaining libs (-lXext -lXft -lfontconfig -lXinerama -lpthread -lm) are not strictly necessary for every program either. (Or there's something else different on FreeBSD.) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

June 24, 2013

Can't compile Dillo 3.0.3

by furaisanjin＠gmail.com

2013/6/24 Axel Beckert <abe at deuxchevaux.org> > Hi, > > On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert 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. > > On non-linux architectures, there's more than -lX11 necessary. I > suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not > sure: > I got this output from fltk-config --ldflags on FreeBSD 8.2. -L/usr/local/lib -R/usr/local/lib -lfltk -lXext -lXft -lfontconfig -lXinerama -lpthread -lm -lX11 Regards, furaisanjin

June 24, 2013

Can't compile Dillo 3.0.3

by abe＠deuxchevaux.org

Hi, On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert 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. On non-linux architectures, there's more than -lX11 necessary. I suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not sure: https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=hurd-i386&ver=3.0… https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=kfreebsd-amd64&ve… https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=kfreebsd-i386&ver… For Hurd, the fix looks obvious, for kfreebsd, I'll have to test first, if that suffices. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

June 24, 2013

Can't compile Dillo 3.0.3

by abe＠deuxchevaux.org

Hi, 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. It's rather "on newer systems" than "on others". And "most systems" is rather "on older systems". > Should we add it generally? It does not harm; we have only to care > about other systems than X11. Definitely. On Sat, May 11, 2013 at 03:38:19PM -0400, Jorge Arellano Cid wrote: > I'm using Debian on amd64 and -lX11 doesn't appear in the options, > though it compiles OK, but libX11.so.6 gets linked anyway! Which release of Debian? Because for Debian Unstable, this is no more the case: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713557 On Sat, May 11, 2013 at 11:44:52PM +0200, August Karlstrom wrote: > > What OS are you using? > > Lubuntu 13.04 with Blackbox window manager. It's possible that Ubuntu already uses the same toolchain in 13.04 which in Debian only was available in the Experimental branch until recently[1]. [1] e.g. https://lists.debian.org/debian-sparc/2013/06/msg00016.html Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

June 23, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-06-14 11:26, Sebastian Geerken wrote: > Hi! > > Is there anything new on this topic? > > On Sat, May 25, 2013, August Karlstrom wrote: >> 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. > > The config.log looks OK, the value of LIBX11_LIBS is set. Is it also > set in Makefile, Makefile.in, src/Makefile, src/Makefile.in? In all > files, there should be the line > > LIBX11_LIBS = @LIBX11_LIBS@ (Makefile.in) > > LIBX11_LIBS = -lX11 (Makefile) Yes, it is set in all files you mention: $ grep LIBX11_LIBS Makefile LIBX11_LIBS = -lX11 $ grep LIBX11_LIBS Makefile.in LIBX11_LIBS = @LIBX11_LIBS@ $ grep LIBX11_LIBS src/Makefile LIBX11_LIBS = -lX11 $ grep LIBX11_LIBS src/Makefile.in LIBX11_LIBS = @LIBX11_LIBS@ @LIBICONV_LIBS@ @LIBPTHREAD_LIBS@ @LIBX11_LIBS@ > Futhermore, part of "dillo_LDADD" should be "@LIBX11_LIBS@" in > src/Makefile.in, and "-lX11" in src/Makefile. Please check this. Yes, these strings are also present: $ grep -m1 -A9 dillo_LDADD src/Makefile.in dillo_LDADD = \ $(top_builddir)/dlib/libDlib.a \ $(top_builddir)/dpip/libDpip.a \ IO/libDiof.a \ $(top_builddir)/dw/libDw-widgets.a \ $(top_builddir)/dw/libDw-fltk.a \ $(top_builddir)/dw/libDw-core.a \ $(top_builddir)/lout/liblout.a \ @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ \ @LIBICONV_LIBS@ @LIBPTHREAD_LIBS@ @LIBX11_LIBS@ $ grep -m1 -A9 dillo_LDADD src/Makefile dillo_LDADD = \ $(top_builddir)/dlib/libDlib.a \ $(top_builddir)/dpip/libDpip.a \ IO/libDiof.a \ $(top_builddir)/dw/libDw-widgets.a \ $(top_builddir)/dw/libDw-fltk.a \ $(top_builddir)/dw/libDw-core.a \ $(top_builddir)/lout/liblout.a \ -ljpeg -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz \ -lpthread -lX11 > What version of automake do you use? According to config.log, your > autoconf version is 2.69. I use automake 1.11.6 Thanks for your help Sebastian. Regards, August

June 23, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > Johannes wrote: > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > Hi, > > > > > > Currently when using a window manager where focus follows mouse, making a > > > search usually requires you to reach for the mouse. One way to avoid this > > > would be to allow using search engine(s) directly from the address bar. > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > has a customizable list of engines in preferences, so one natural solution > > > would be to interpret url strings which start with the name of a search > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > else find this feature useful. > > > > This has been discussed before, but somehow wasn't completed. I like > > your idea to reuse the search engine name to derive the shortcut. > > However, I would allow arbitrary prefixes of the search engine name > > as in the slightly modified patch below. > > What do you think? > > This is good, although there's a leading space in the search text that > some of my search sites don't like. The leading space should of course not be part of the search term. Johannes

June 20, 2013

Search from address bar

by corvid＠lavabit.com

Johannes wrote: > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > Hi, > > > > Currently when using a window manager where focus follows mouse, making a > > search usually requires you to reach for the mouse. One way to avoid this > > would be to allow using search engine(s) directly from the address bar. > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > has a customizable list of engines in preferences, so one natural solution > > would be to interpret url strings which start with the name of a search > > engine as searches to be performed using it, so that e.g. 'wikipedia > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > Below is a quick patch I've used to do this for a while, should anyone > > else find this feature useful. > > This has been discussed before, but somehow wasn't completed. I like > your idea to reuse the search engine name to derive the shortcut. > However, I would allow arbitrary prefixes of the search engine name > as in the slightly modified patch below. > What do you think? This is good, although there's a leading space in the search text that some of my search sites don't like.

June 19, 2013

line wrapping

by corvid＠lavabit.com

I noticed that lines aren't wrapping for me with http://www.dillo.org/FAQ.html . hg bisect says that it started with: changeset: 2838:b2b239eb45b9 summary: Fixed problem with hyphenation.

June 19, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

On Tue, Jun 18, 2013 at 08:18:46PM +0300, Aki Helin wrote: > "Sebastian Geerken" <sgeerken at dillo.org> wrote: > > > On Mo, Jun 17, 2013, Aki Helin wrote: > > > Currently when using a window manager where focus follows mouse, making a > > > search usually requires you to reach for the mouse. One way to avoid this > > > would be to allow using search engine(s) directly from the address bar. > > > > What if the "search" dialog follows the "find text" dialog, by being > > integrated into the browser window? This would also solve some other > > problems with the current search dialog, which is currently > > application-modal. > > That would be good in the sense that it is also how you search from pages, > but the ability to construct queries from address bar could also be > (ab)used to do other kinds of things, like "toread <currenturl>" -> dpi > url to save bookmark under "toread", "feed <url>" -> send url to rss/atom > reader dpi and add to feed source list if found, "bookmark <prefix>" -> > open bookmark with given prefix in name, etc. I also think "search the web" is about going to a certain web location, so in my opinion it's nice to be able do it from the location bar. In addition we could of course move the current search dialog, which would not go away with Aki's shortcut feature into some in-window thing like the "search in page" dialog. Cheers, Johannes

June 18, 2013

Search from address bar

by aki.helin＠iki.fi

"Sebastian Geerken" <sgeerken at dillo.org> wrote: > On Mo, Jun 17, 2013, Aki Helin wrote: > > Currently when using a window manager where focus follows mouse, making a > > search usually requires you to reach for the mouse. One way to avoid this > > would be to allow using search engine(s) directly from the address bar. > > What if the "search" dialog follows the "find text" dialog, by being > integrated into the browser window? This would also solve some other > problems with the current search dialog, which is currently > application-modal. That would be good in the sense that it is also how you search from pages, but the ability to construct queries from address bar could also be (ab)used to do other kinds of things, like "toread <currenturl>" -> dpi url to save bookmark under "toread", "feed <url>" -> send url to rss/atom reader dpi and add to feed source list if found, "bookmark <prefix>" -> open bookmark with given prefix in name, etc. (Obviously I don't mind if you decide to go for something completely different. Dillo is so compact it's easier to patch to your liking than it is to find configuration options in some browsers :) -- Aki Helin

June 18, 2013

Search from address bar

by sgeerken＠dillo.org

On Mo, Jun 17, 2013, Aki Helin wrote: > Currently when using a window manager where focus follows mouse, making a > search usually requires you to reach for the mouse. One way to avoid this > would be to allow using search engine(s) directly from the address bar. What if the "search" dialog follows the "find text" dialog, by being integrated into the browser window? This would also solve some other problems with the current search dialog, which is currently application-modal. Sebastian

June 18, 2013