- Dillo-dev - lists.mailman3.com

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