- Dillo-dev - lists.mailman3.com

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