Discussion:
Search from address bar
Aki Helin
2013-06-17 12:16:09 UTC
Permalink
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
Johannes Hofmann
2013-06-17 19:37:36 UTC
Permalink
Hi,
Post by Aki Helin
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
Aki Helin
2013-06-17 20:53:45 UTC
Permalink
Post by Johannes Hofmann
Hi,
Post by Aki Helin
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
Johannes Hofmann
2013-06-17 21:31:48 UTC
Permalink
Post by Aki Helin
Post by Johannes Hofmann
Hi,
Post by Aki Helin
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
Aki Helin
2013-06-18 04:49:18 UTC
Permalink
Post by Johannes Hofmann
Post by Aki Helin
Post by Johannes Hofmann
Hi,
Post by Aki Helin
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
corvid
2013-06-19 16:41:23 UTC
Permalink
Post by Johannes Hofmann
Post by Aki Helin
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.
Johannes Hofmann
2013-06-20 18:20:27 UTC
Permalink
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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
Johannes Hofmann
2013-07-09 19:51:39 UTC
Permalink
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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
Jorge Arellano Cid
2013-07-09 21:02:12 UTC
Permalink
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.-
Johannes Hofmann
2013-07-10 07:21:51 UTC
Permalink
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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
Johannes Hofmann
2013-07-18 21:06:36 UTC
Permalink
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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
Jorge Arellano Cid
2013-07-19 15:22:36 UTC
Permalink
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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.-
Johannes Hofmann
2013-07-21 17:19:16 UTC
Permalink
Post by Jorge Arellano Cid
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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.
search_url="Free Dictionary http://www.thefreedictionary.com/%s"
search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s"
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
Jorge Arellano Cid
2013-07-23 16:39:30 UTC
Permalink
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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.
search_url="Free Dictionary http://www.thefreedictionary.com/%s"
search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s"
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 ':'.
* We stick with title and url only and for your example one would
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.
Post by Johannes Hofmann
* Or we enhance the prefs parser and somehow have separate fields
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.-
Johannes Hofmann
2013-07-23 21:25:49 UTC
Permalink
Post by Jorge Arellano Cid
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by Jorge Arellano Cid
Hi Johannes,
Post by Johannes Hofmann
Post by Johannes Hofmann
Post by corvid
Post by Johannes Hofmann
Post by Aki Helin
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.
"[<label> ]<url>"
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
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.
search_url="Free Dictionary http://www.thefreedictionary.com/%s"
search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s"
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 ':'.
* We stick with title and url only and for your example one would
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.
Post by Johannes Hofmann
* Or we enhance the prefs parser and somehow have separate fields
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

Sebastian Geerken
2013-06-18 10:51:03 UTC
Permalink
Post by Aki Helin
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
Aki Helin
2013-06-18 17:18:46 UTC
Permalink
Post by Sebastian Geerken
Post by Aki Helin
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
Johannes Hofmann
2013-06-18 17:58:20 UTC
Permalink
Post by Aki Helin
Post by Sebastian Geerken
Post by Aki Helin
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
Loading...