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. diff -r 91fdbc0feb68 src/uicmd.cc --- a/src/uicmd.cc Sun Jun 16 21:23:19 2013 +0200 +++ b/src/uicmd.cc Mon Jun 17 15:00:05 2013 +0300 @@ -70,6 +70,7 @@ */ static BrowserWindow *UIcmd_tab_new(CustTabs *tabs, UI *old_ui, int focus); static void close_tab_btn_cb (Fl_Widget *w, void *cb_data); +static char *UIcmd_make_search_str(const char *str); //---------------------------------------------------------------------------- @@ -649,6 +650,27 @@ } /* + * Return a search string of the suffix if str is prefixed by the first word of a search engine name + */ +static char *UIcmd_find_search_str(const char *str) +{ + int end = dList_length(prefs.search_urls); + int p = 0; + char *url = NULL; + while (p < end && !url) { + char *search = (char *)dList_nth_data(prefs.search_urls,p); + int len = strcspn(search, " "); + int res = strncasecmp(str, search, len); + if (res == 0 && (str[len] == 0 || str[len] == ' ')) { + prefs.search_url_idx = p; + url = UIcmd_make_search_str(str + len); + } + p++; + } + return url; +} + +/* * Open a new URL in the given browser window. * * our custom "file:" URIs are normalized here too. @@ -656,10 +678,14 @@ void a_UIcmd_open_urlstr(void *vbw, const char *urlstr) { char *new_urlstr; + char *search_urlstr = NULL; DilloUrl *url; int ch; BrowserWindow *bw = (BrowserWindow*)vbw; + if ((search_urlstr = UIcmd_find_search_str(urlstr))) { + urlstr = search_urlstr; + } if (urlstr && *urlstr) { /* Filter URL string */ new_urlstr = a_Url_string_strip_delimiters(urlstr); @@ -680,6 +706,8 @@ url = a_Url_new(new_urlstr, NULL); } dFree(new_urlstr); + if (search_urlstr) + dFree(search_urlstr); if (url) { a_UIcmd_open_url(bw, url); -- Aki Helin
Hi, 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? Cheers, Johannes
Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
Hi,
On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote:
Hi,
[...] 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?
Looks good to me. You could even drop the 'len > 0' check, so that prefixing with space leads to search with your first search engine, and an optional prefix can be given to choose another one. -- Aki Helin
On Mon, Jun 17, 2013 at 11:53:45PM +0300, Aki Helin wrote:
Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
Hi,
On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote:
Hi,
[...] 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?
Looks good to me. You could even drop the 'len > 0' check, so that prefixing with space leads to search with your first search engine, and an optional prefix can be given to choose another one.
Not sure about that. What I really hate with other browsers is when they send the location I typed to some search engine just because they think it's not a hostname. Searching for everything that starts with a blank seems a bit too aggressive to me. Johannes
Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
On Mon, Jun 17, 2013 at 11:53:45PM +0300, Aki Helin wrote:
Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
Hi,
On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote:
Hi,
[...] 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?
Looks good to me. You could even drop the 'len > 0' check, so that prefixing with space leads to search with your first search engine, and an optional prefix can be given to choose another one.
Not sure about that. What I really hate with other browsers is when they send the location I typed to some search engine just because they think it's not a hostname. Searching for everything that starts with a blank seems a bit too aggressive to me.
On second thought, it is. It would also lead to pasted URLs being sent to search engine if you accidentally copied a space. -- Aki Helin
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.
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
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
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.-
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
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
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.-
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
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.-
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
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
"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
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
participants (6)
-
aki.helin＠iki.fi -
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
sgeerken＠dillo.org