June 2013 - Dillo-dev - lists.mailman3.com

Search from address bar

by aki.helin＠iki.fi

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

June 18, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

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

June 17, 2013

Search from address bar

by aki.helin＠iki.fi

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

June 17, 2013

Search from address bar

by Johannes.Hofmann＠gmx.de

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

June 17, 2013

Search from address bar

by aki.helin＠iki.fi

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

June 17, 2013

Image Scaling

by sgeerken＠dillo.org

Hi! Gamma is now considered when scaling images, e. g. at <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html>, you will see Mr Tenzin Gyatso four times. There is an enumeration value at the begining of dw/fltkimgbuf.cc: if it turns out that there are performance problems on some platforms, the scaling mode may made configurable. Now back to more important tasks. :-) Sebastian

June 17, 2013

Image Scaling

by sgeerken＠dillo.org

On Mo, Jun 17, 2013, Johannes Hofmann wrote: > On Sun, Jun 16, 2013 at 10:52:57PM +0200, Sebastian Geerken wrote: > > [...] > > > > > Nice! BTW, I have this page bookmarked for quite some time: > > > > > http://www.4p8.com/eric.brasseur/gamma.html > > > > > I don't know whether this makes a difference in real life, but the > > > > > examples are interesting. > > > > > > > > Interesting! > > > > > > > > I didn't read the whole article, but it made me wonder what effect a > > > > gamma correction has on image scaling. See the test page > > > > <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html> with: > > > > > > > > 1. dillo 3.0.3, > > > > 2. current version from the hg repository, and > > > > 3. latter with the attached patch applied. > > > > > > > > The patch uses floating point arithmetics; perhaps there is a faster > > > > algorithm based on integer arithmetics. > > > > > > I don't know, but we could cache the values as in attached patch. > > > > Yes, I also thought about this, and probably the fastest way is to > > calculate all values once, at the beginning, and later only access the > > array. > > > > I've been working on the other side: from what I've understood, image > > data is in most cases already gamma-corrected. I'd like to extend > > ImgBuf by the gamma value, and the different parsers (GIF, JPEG, PNG) > > should extract the factor from the image. > > > > So far, I'm working on JPEG, and came upon the field "output_gamma" in > > "struct jpeg_decompress_struct". Unfortunately, this value seems > > always 1. Can someone give me a hint? > > http://www.cambridgeincolour.com/tutorials/gamma-correction.htm > has some info on the topic. Thanks. > I think we can completely ignore gamma unless we actually touch the > color values. I think the only place we do that is in the image > scaling code. > For the web I think it's safe to simply assume a gamma value of 2.2. > To improve local image browsing we might check for embedded color profiles > and use the gamma value provided there. > That's how I understand it at least. I've just added gamma information to the whole chain (from image decoders to FltkImgBuf), without using it at all. Currently, all image decoders pass a value of 1/2.2, ignoring the possible values in the file. May be fixed. I found it useful just to have this value stored. I do not plan to correct any image values (assuming that the display has a gamma of 2.2), but just to use gamma for scaling. Sebastian

June 17, 2013

Image Scaling

by johannes.hofmann＠gmx.de

On Sun, Jun 16, 2013 at 10:52:57PM +0200, Sebastian Geerken wrote: > [...] > > > > Nice! BTW, I have this page bookmarked for quite some time: > > > > http://www.4p8.com/eric.brasseur/gamma.html > > > > I don't know whether this makes a difference in real life, but the > > > > examples are interesting. > > > > > > Interesting! > > > > > > I didn't read the whole article, but it made me wonder what effect a > > > gamma correction has on image scaling. See the test page > > > <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html> with: > > > > > > 1. dillo 3.0.3, > > > 2. current version from the hg repository, and > > > 3. latter with the attached patch applied. > > > > > > The patch uses floating point arithmetics; perhaps there is a faster > > > algorithm based on integer arithmetics. > > > > I don't know, but we could cache the values as in attached patch. > > Yes, I also thought about this, and probably the fastest way is to > calculate all values once, at the beginning, and later only access the > array. > > I've been working on the other side: from what I've understood, image > data is in most cases already gamma-corrected. I'd like to extend > ImgBuf by the gamma value, and the different parsers (GIF, JPEG, PNG) > should extract the factor from the image. > > So far, I'm working on JPEG, and came upon the field "output_gamma" in > "struct jpeg_decompress_struct". Unfortunately, this value seems > always 1. Can someone give me a hint? http://www.cambridgeincolour.com/tutorials/gamma-correction.htm has some info on the topic. I think we can completely ignore gamma unless we actually touch the color values. I think the only place we do that is in the image scaling code. For the web I think it's safe to simply assume a gamma value of 2.2. To improve local image browsing we might check for embedded color profiles and use the gamma value provided there. That's how I understand it at least. Johannes

June 17, 2013

Image Scaling

by sgeerken＠dillo.org

[...] > > > Nice! BTW, I have this page bookmarked for quite some time: > > > http://www.4p8.com/eric.brasseur/gamma.html > > > I don't know whether this makes a difference in real life, but the > > > examples are interesting. > > > > Interesting! > > > > I didn't read the whole article, but it made me wonder what effect a > > gamma correction has on image scaling. See the test page > > <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html> with: > > > > 1. dillo 3.0.3, > > 2. current version from the hg repository, and > > 3. latter with the attached patch applied. > > > > The patch uses floating point arithmetics; perhaps there is a faster > > algorithm based on integer arithmetics. > > I don't know, but we could cache the values as in attached patch. Yes, I also thought about this, and probably the fastest way is to calculate all values once, at the beginning, and later only access the array. I've been working on the other side: from what I've understood, image data is in most cases already gamma-corrected. I'd like to extend ImgBuf by the gamma value, and the different parsers (GIF, JPEG, PNG) should extract the factor from the image. So far, I'm working on JPEG, and came upon the field "output_gamma" in "struct jpeg_decompress_struct". Unfortunately, this value seems always 1. Can someone give me a hint? Sebastian

June 16, 2013

Image Scaling

by Johannes.Hofmann＠gmx.de

On Sun, Jun 16, 2013 at 11:42:35AM +0200, Sebastian Geerken wrote: > On Sa, Jun 15, 2013, Johannes Hofmann wrote: > > On Fri, Jun 14, 2013 at 08:01:00PM +0200, Sebastian Geerken wrote: > > > Hi! > > > > > > I've just push some changes for a better image scaling. See these two > > > examples for the effect: > > > > > > - http://www.dillo.org/~sgeerken/grid.html > > > - http://www.dillo.org/~sgeerken/tenniel.html > > > > > > I'm not completely sure about the side-effects. It should be slightly > > > slower (see comment: it can be improved), and it will not work with > > > other that RGB and RGBA data (for the case that Imgbuf is used for > > > other representations). The old code is still there; just look at > > > FltkImgbuf::scaleRow. > > > > Nice! BTW, I have this page bookmarked for quite some time: > > http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.h… > > I don't know whether this makes a difference in real life, but the > > examples are interesting. > > Interesting! > > I didn't read the whole article, but it made me wonder what effect a > gamma correction has on image scaling. See the test page > <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html> with: > > 1. dillo 3.0.3, > 2. current version from the hg repository, and > 3. latter with the attached patch applied. > > The patch uses floating point arithmetics; perhaps there is a faster > algorithm based on integer arithmetics. I don't know, but we could cache the values as in attached patch. Johannes

June 16, 2013