- 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

Image Scaling

by sgeerken＠dillo.org

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. Sebastian

June 16, 2013

Image Scaling

by Johannes.Hofmann＠gmx.de

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. Johannes

June 15, 2013

do not truncate long filenames beginning with dot

by sgeerken＠dillo.org

On Sa, Jun 15, 2013, Dennis New wrote: > On Tue, 11 Jun 2013 23:26:21 -0400, Jorge Arellano Cid wrote: > > On Tue, Jun 11, 2013 at 09:23:29PM +0200, Johannes Hofmann wrote: > > > On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > > > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > > > > Sometimes, when trying to save a document with long > > > > > > filenames, the truncated default save-as filename will start > > > > > > with a dot. (Ie. a hidden file.) This behaviour should > > > > > > change. Perhaps truncate the end of the filename instead (and > > > > > > preserve the file extension)? > > > > > > > > > > Do you have an example where this happens? I see that it can > > > > > happen with URLs like http://dillo.org/bla/.blub > > > > > Is this the case where you are seeing the issue or do you get it > > > > > with other types of URLs as well? > > > > > > > > I was to ask the same question days ago (yes I reviewed the > > > > code to make a quick patch and it cuts starting from the end). An > > > > example would be clarifying. > > > > > > If we don't get any more feedback, I'd just replace dots with > > > underscores as well. What do you think? > > > > That was one of the first things I considered, but thought that > > when saving a ".config" file it was good to keep the name. I'd like > > to know the real problem the user had. > > The problem is with very long filenames, such as: > > http://dennisn.dyndns.org/guest/pubstuff/dillo.long.file.name-0.69_r1337.fi… > > Dillo seems to truncate with just the last 64 chars. So, in this > example, the save-as filename would be saved as a hidden file > ".file.name-....txt". > > Perhaps a better solution would be to truncate the *middle* of the > filename, thus preserving the beginning and file extension? The attached patch does this, and inserts an ellipsis to indicate that something was replaced. The above URL becomes dillo.long.file.name-0.69_r133...789012345678901234567890123.txt which is 64 characters long. I like this approach, because both the beginning and the end are the most characteristic parts of a filename. Sebastian

June 15, 2013

do not truncate long filenames beginning with dot

by dennisn＠dennisn.dyndns.org

On Tue, 11 Jun 2013 23:26:21 -0400, Jorge Arellano Cid wrote: > On Tue, Jun 11, 2013 at 09:23:29PM +0200, Johannes Hofmann wrote: > > On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > > > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > > > Sometimes, when trying to save a document with long > > > > > filenames, the truncated default save-as filename will start > > > > > with a dot. (Ie. a hidden file.) This behaviour should > > > > > change. Perhaps truncate the end of the filename instead (and > > > > > preserve the file extension)? > > > > > > > > Do you have an example where this happens? I see that it can > > > > happen with URLs like http://dillo.org/bla/.blub > > > > Is this the case where you are seeing the issue or do you get it > > > > with other types of URLs as well? > > > > > > I was to ask the same question days ago (yes I reviewed the > > > code to make a quick patch and it cuts starting from the end). An > > > example would be clarifying. > > > > If we don't get any more feedback, I'd just replace dots with > > underscores as well. What do you think? > > That was one of the first things I considered, but thought that > when saving a ".config" file it was good to keep the name. I'd like > to know the real problem the user had. The problem is with very long filenames, such as: http://dennisn.dyndns.org/guest/pubstuff/dillo.long.file.name-0.69_r1337.fi… Dillo seems to truncate with just the last 64 chars. So, in this example, the save-as filename would be saved as a hidden file ".file.name-....txt". Perhaps a better solution would be to truncate the *middle* of the filename, thus preserving the beginning and file extension?

June 15, 2013

Image Scaling

by sgeerken＠dillo.org

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. Sebastian

June 14, 2013

shortcuts to open links in new tab and new window

by dennisn＠dennisn.dyndns.org

Currently it seems like you can only have it one way, via the "middle_click_opens_new_tab" dillorc option. (And to do it the other way, you have to right click and navigate the menus. A lengthy process :). I think it would be quite useful if both were available via a shortcut... perhaps have this option toggle the meaning of ShiftMiddleClick and MiddleClick... whereby one will open the link in a new window, and the other in a new tab?

June 14, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

Hi! Is there anything new on this topic? On Sat, May 25, 2013, August Karlstrom wrote: > On 2013-05-23 22:02, Sebastian Geerken wrote: > >Did you call "autogen.sh" again before "configure"? > > Yes, I followed the instructions at http://www.dillo.org/source.html. > > >To get more > >informations: what is the output of "configure"? Or, better, send the > >your "config.log". > > OK, I have attached config.log. The config.log looks OK, the value of LIBX11_LIBS is set. Is it also set in Makefile, Makefile.in, src/Makefile, src/Makefile.in? In all files, there should be the line LIBX11_LIBS = @LIBX11_LIBS@ (Makefile.in) LIBX11_LIBS = -lX11 (Makefile) Futhermore, part of "dillo_LDADD" should be "@LIBX11_LIBS@" in src/Makefile.in, and "-lX11" in src/Makefile. Please check this. What version of automake do you use? According to config.log, your autoconf version is 2.69. OTOH, I must admit that my autoconf/automake knowledge is limited, so perhaps someone else may help here. Sebastian

June 14, 2013

do not truncate long filenames beginning with dot

by jcid＠dillo.org

On Tue, Jun 11, 2013 at 09:23:29PM +0200, Johannes Hofmann wrote: > On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > > Sometimes, when trying to save a document with long filenames, the > > > > truncated default save-as filename will start with a dot. (Ie. a hidden > > > > file.) This behaviour should change. Perhaps truncate the end of the > > > > filename instead (and preserve the file extension)? > > > > > > Do you have an example where this happens? I see that it can > > > happen with URLs like http://dillo.org/bla/.blub > > > Is this the case where you are seeing the issue or do you get it > > > with other types of URLs as well? > > > > I was to ask the same question days ago (yes I reviewed the code to > > make a quick patch and it cuts starting from the end). An example would > > be clarifying. > > If we don't get any more feedback, I'd just replace dots with > underscores as well. What do you think? That was one of the first things I considered, but thought that when saving a ".config" file it was good to keep the name. I'd like to know the real problem the user had. -- Cheers Jorge.-

June 12, 2013

do not truncate long filenames beginning with dot

by Johannes.Hofmann＠gmx.de

On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > Sometimes, when trying to save a document with long filenames, the > > > truncated default save-as filename will start with a dot. (Ie. a hidden > > > file.) This behaviour should change. Perhaps truncate the end of the > > > filename instead (and preserve the file extension)? > > > > Do you have an example where this happens? I see that it can > > happen with URLs like http://dillo.org/bla/.blub > > Is this the case where you are seeing the issue or do you get it > > with other types of URLs as well? > > I was to ask the same question days ago (yes I reviewed the code to > make a quick patch and it cuts starting from the end). An example would > be clarifying. If we don't get any more feedback, I'd just replace dots with underscores as well. What do you think? Cheers, Johannes

June 11, 2013

do not truncate long filenames beginning with dot

by jcid＠dillo.org

On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > Sometimes, when trying to save a document with long filenames, the > > truncated default save-as filename will start with a dot. (Ie. a hidden > > file.) This behaviour should change. Perhaps truncate the end of the > > filename instead (and preserve the file extension)? > > Do you have an example where this happens? I see that it can > happen with URLs like http://dillo.org/bla/.blub > Is this the case where you are seeing the issue or do you get it > with other types of URLs as well? I was to ask the same question days ago (yes I reviewed the code to make a quick patch and it cuts starting from the end). An example would be clarifying. -- Cheers Jorge.-

June 10, 2013

do not truncate long filenames beginning with dot

by Johannes.Hofmann＠gmx.de

On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > Sometimes, when trying to save a document with long filenames, the > truncated default save-as filename will start with a dot. (Ie. a hidden > file.) This behaviour should change. Perhaps truncate the end of the > filename instead (and preserve the file extension)? Do you have an example where this happens? I see that it can happen with URLs like http://dillo.org/bla/.blub Is this the case where you are seeing the issue or do you get it with other types of URLs as well? Cheers, Johannes

June 10, 2013

Preventing page caching

by Johannes.Hofmann＠gmx.de

On Sun, Jun 09, 2013 at 05:14:15PM +0200, August Karlstrom wrote: > How do I prevent page caching in Dillo? I have tried adding > > <meta http-equiv="cache-control" content="no-cache" /> > > but it has no effect in Dillo. In Firefox it works as expected. I'm > using Dillo 3.0.3. Any clues? This is not implemented in Dillo, but there had been patches floating around to add support for it. Regards, Johannes

June 9, 2013

Preventing page caching

by fusionfile＠gmail.com

How do I prevent page caching in Dillo? I have tried adding <meta http-equiv="cache-control" content="no-cache" /> but it has no effect in Dillo. In Firefox it works as expected. I'm using Dillo 3.0.3. Any clues? Regards, August

June 9, 2013

dillo bug#1127

by Johannes.Hofmann＠gmx.de

On Mon, Jun 03, 2013 at 02:09:46PM +0200, Urban Lundin wrote: > Dear Johannes, > > We tried your patch for the xembed structure and recompiled it, it > works fine in our main application. > Thanks a lot for solving this issue! Ok, I committed the fix. Cheers, Johannes

June 3, 2013

do not truncate long filenames beginning with dot

by jcid＠dillo.org

On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > Sometimes, when trying to save a document with long filenames, the > truncated default save-as filename will start with a dot. (Ie. a hidden > file.) This behaviour should change. Perhaps truncate the end of the > filename instead (and preserve the file extension)? Yes. This should not happen. -- Cheers Jorge.-

May 29, 2013

do not truncate long filenames beginning with dot

by dennisn＠dennisn.dyndns.org

Sometimes, when trying to save a document with long filenames, the truncated default save-as filename will start with a dot. (Ie. a hidden file.) This behaviour should change. Perhaps truncate the end of the filename instead (and preserve the file extension)?

May 29, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-23 22:02, Sebastian Geerken wrote: > Did you call "autogen.sh" again before "configure"? Yes, I followed the instructions at http://www.dillo.org/source.html. > To get more > informations: what is the output of "configure"? Or, better, send the > your "config.log". OK, I have attached config.log. /August

May 25, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Thu, May 23, August Karlstrom wrote: > On 2013-05-22 15:33, Sebastian Geerken wrote: > [...] > >August: Please test whether the version from the repository works for > >you. > > I still get an error when compiling Dillo (version 2013-05-22, > changeset 2843:60a7bb6ca06b): > > $ make > ... > g++ -I/usr/include/cairo -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > -I/usr/include/freetype2 -I/usr/include/cairo > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -I/usr/include/pixman-1 -I/usr/include/freetype2 > -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter > -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test > dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a > ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu > -Wl,-Bsymbolic-functions -lfltk > /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): > undefined reference to symbol 'XCreatePixmap' > /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO > /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker > command line > /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: > Invalid operation > collect2: error: ld returned 1 exit status > make[2]: *** [dw-anchors-test] Error 1 > make[2]: Leaving directory `/tmp/dillo3/test' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/dillo3' > make: *** [all] Error 2 > > Apparently -lX11 has not been added. Although I don't see how that > would make a difference I can also mention that I start X Windows > (Blackbox WM) from the console with the startx command without using > a display manager. Startx instead of xdm should not make a difference. Did you call "autogen.sh" again before "configure"? To get more informations: what is the output of "configure"? Or, better, send the your "config.log". Sebastian

May 23, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-22 15:33, Sebastian Geerken wrote: [...] > August: Please test whether the version from the repository works for > you. I still get an error when compiling Dillo (version 2013-05-22, changeset 2843:60a7bb6ca06b): $ make ... g++ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/tmp/dillo3/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/dillo3' make: *** [all] Error 2 Apparently -lX11 has not been added. Although I don't see how that would make a difference I can also mention that I start X Windows (Blackbox WM) from the console with the startx command without using a display manager. Regards, August

May 23, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Wed, May 22, Johannes Hofmann wrote: > On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote: > > On Sat, May 18, Johannes Hofmann wrote: > > > On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > > > > On Sat, May 18, Johannes Hofmann wrote: > > > > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > > > > [...] > > > > > > > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > > > > not, so that an additional "-lX11" is necessary. Should we add it > > > > > > generally? It does not harm; we have only to care about other systems > > > > > > than X11. > > > > > > > > > > Could we check for libX11 in configure and link explicitely against > > > > > it if available but not fail otherwise? > > > > > That way dillo should still compile on OSX. > > > > > > > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > > > > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > > > > not found where X_PROTOCOL is defined. > > > > > > That comes from the fltk headers depending on whether fltk was built > > > with X11 backend or not. > > > > Do not find it, strange. > > > > > I don't see how we could get that information at configure time. > > > Maybe some fltk-config option? > > > > See attached patch for an incomplete implementation. On my system, it > > says "checking whether to link to X11... yes", on OSX it should say > > "... no". > > Yes, works ok on OSX: > > checking for socklen_t... socklen_t > checking FLTK 1.3... yes > checking whether to link to X11... no Good. I've extended it and it is now in the repository. When cross-compiling (has anyone tested this?), nothing should change. August: Please test whether the version from the repository works for you. Sebastian

May 22, 2013

Can't compile Dillo 3.0.3

by johannes.hofmann＠gmx.de

On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote: > On Sat, May 18, Johannes Hofmann wrote: > > On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > > > On Sat, May 18, Johannes Hofmann wrote: > > > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > > > [...] > > > > > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > > > not, so that an additional "-lX11" is necessary. Should we add it > > > > > generally? It does not harm; we have only to care about other systems > > > > > than X11. > > > > > > > > Could we check for libX11 in configure and link explicitely against > > > > it if available but not fail otherwise? > > > > That way dillo should still compile on OSX. > > > > > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > > > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > > > not found where X_PROTOCOL is defined. > > > > That comes from the fltk headers depending on whether fltk was built > > with X11 backend or not. > > Do not find it, strange. > > > I don't see how we could get that information at configure time. > > Maybe some fltk-config option? > > See attached patch for an incomplete implementation. On my system, it > says "checking whether to link to X11... yes", on OSX it should say > "... no". Yes, works ok on OSX: checking for socklen_t... socklen_t checking FLTK 1.3... yes checking whether to link to X11... no Cheers, Johannes

May 22, 2013

dillo bug#1127

by Johannes.Hofmann＠gmx.de

Hi, On Mon, May 20, 2013 at 02:07:54PM +0200, Urban Lundin wrote: > Hi Johannes, > > That sounds great if you could attempt to solve this issue! > We have made a small example in TCL/TK (which you have to install > first, available through http://www.tcl.tk/) > > We did not try to embed suckless as we could not find a simple > example inside it. > > > Then the example is below. Thanks for the example. For me it works with the following patch for dillo: diff -r ace33e3969af src/xembed.cc --- a/src/xembed.cc Sun Apr 28 15:11:03 2013 +0200 +++ b/src/xembed.cc Mon May 20 19:38:06 2013 +0200 @@ -108,6 +108,7 @@ createInternal(xid); setXembedInfo(1); Fl::event_dispatch(event_handler); + Fl_Window::show(); } void Xembed::createInternal(uint32_t parent) { Before pushing it to the main repo I need to read http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html a bit more, but to me it seems a reasonable thing to do. It would be cool, if anyone using the claws mail dillo plugin could verify that the above patch doesn't break embedding in claws mail. Cheers, Johannes

May 20, 2013

Can't compile Dillo 3.0.3

by Johannes.Hofmann＠gmx.de

On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote: > On Sat, May 18, Johannes Hofmann wrote: > > On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > > > On Sat, May 18, Johannes Hofmann wrote: > > > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > > > [...] > > > > > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > > > not, so that an additional "-lX11" is necessary. Should we add it > > > > > generally? It does not harm; we have only to care about other systems > > > > > than X11. > > > > > > > > Could we check for libX11 in configure and link explicitely against > > > > it if available but not fail otherwise? > > > > That way dillo should still compile on OSX. > > > > > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > > > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > > > not found where X_PROTOCOL is defined. > > > > That comes from the fltk headers depending on whether fltk was built > > with X11 backend or not. > > Do not find it, strange. Sorry, it's not in the fltk headers, but via fltk headers. It's defined in X11/X.h. > > > I don't see how we could get that information at configure time. > > Maybe some fltk-config option? > > See attached patch for an incomplete implementation. On my system, it > says "checking whether to link to X11... yes", on OSX it should say > "... no". > > Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. > Perhaps, something with AC_COMPILE_IFELSE could also work. > > Sebastian > > diff -r 2a024fd43fe8 configure.ac > --- a/configure.ac Sat May 18 21:27:59 2013 +0200 > +++ b/configure.ac Sat May 18 21:58:45 2013 +0200 > @@ -124,6 +124,28 @@ > AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) > esac > > +dnl ----------------------------------- > +dnl Test for X11 (only on some systems) > +dnl ----------------------------------- > +AC_MSG_CHECKING([whether to link to X11]) > +AC_LANG_PUSH([C++]) > +old_libs=$LIBS > +old_cxxflags=$CXXFLAGS > +LIBS=$LIBFLTK_LIBS > +CXXFLAGS=$LIBFLTK_CXXFLAGS > +AC_RUN_IFELSE([AC_LANG_PROGRAM([[ > +#define FL_INTERNALS > +#include <FL/x.H> > +]],[[ > +#ifdef X_PROTOCOL > + return 0; > +#else > + return 1; > +#endif > +]])], [AC_MSG_RESULT(yes)] ,[AC_MSG_RESULT(no)]) > +CXXFLAGS=$old_cxxflags > +LIBS=$old_libs > +AC_LANG_POP([C++]) > > dnl ---------------- > dnl Test for libjpeg Ah that's cool. It's good to base the decision for linking and the ifdef in the code on the same thing. I can test it on OSX on tuesday. Johannes

May 18, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Sat, May 18, Johannes Hofmann wrote: > On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > > On Sat, May 18, Johannes Hofmann wrote: > > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > > [...] > > > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > > not, so that an additional "-lX11" is necessary. Should we add it > > > > generally? It does not harm; we have only to care about other systems > > > > than X11. > > > > > > Could we check for libX11 in configure and link explicitely against > > > it if available but not fail otherwise? > > > That way dillo should still compile on OSX. > > > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > > not found where X_PROTOCOL is defined. > > That comes from the fltk headers depending on whether fltk was built > with X11 backend or not. Do not find it, strange. > I don't see how we could get that information at configure time. > Maybe some fltk-config option? See attached patch for an incomplete implementation. On my system, it says "checking whether to link to X11... yes", on OSX it should say "... no". Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. Perhaps, something with AC_COMPILE_IFELSE could also work. Sebastian

May 18, 2013

Can't compile Dillo 3.0.3

by Johannes.Hofmann＠gmx.de

On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote: > On Sat, May 18, Johannes Hofmann wrote: > > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > > [...] > > > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > > not, so that an additional "-lX11" is necessary. Should we add it > > > generally? It does not harm; we have only to care about other systems > > > than X11. > > > > Could we check for libX11 in configure and link explicitely against > > it if available but not fail otherwise? > > That way dillo should still compile on OSX. > > I thought of this. The code is included in "#ifdef X_PROTOCOL", so > making "-lX11" depend on this X_PROTOCOL should be save; however, I've > not found where X_PROTOCOL is defined. That comes from the fltk headers depending on whether fltk was built with X11 backend or not. I don't see how we could get that information at configure time. Maybe some fltk-config option? Johannes

May 18, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Sat, May 18, Johannes Hofmann wrote: > On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > > [...] > > > > X11 is needed in src/xembed.cc. It seems that on most systems it is > > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > > not, so that an additional "-lX11" is necessary. Should we add it > > generally? It does not harm; we have only to care about other systems > > than X11. > > Could we check for libX11 in configure and link explicitely against > it if available but not fail otherwise? > That way dillo should still compile on OSX. I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined. Sebastian

May 18, 2013

Can't compile Dillo 3.0.3

by Johannes.Hofmann＠gmx.de

On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote: > On Sat, May 11, August Karlstrom wrote: > > Linking with libX11 is what's missing: > > > > LIBS=-lX11 ./configure > > make > > make install > > > > This means that libX11 needs to be added to the build scripts. > > On Mon, May 13, August Karlstrom wrote: > > This is what I get: > > > > $ fltk-config --ldflags > > -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk > > $ fltk-config --ldstaticflags > > -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext > > -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 > > > > >The configure script of dillo uses "--ldflags", which is used for > > >dynamic linking against "libfltk.so", while "--ldstaticflags" is used > > >for linking against "libfltk.a". Which files of the two do you have in > > >the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is > > >that "libfltk.so" does not exist and so dillo is linked statically. > > > > I do have both the dynamic and the static libraries: > > > > $ ls /usr/lib/x86_64-linux-gnu/libfltk* > > /usr/lib/x86_64-linux-gnu/libfltk.a > > [..] > > /usr/lib/x86_64-linux-gnu/libfltk.so > > /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 > > X11 is needed in src/xembed.cc. It seems that on most systems it is > linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others > not, so that an additional "-lX11" is necessary. Should we add it > generally? It does not harm; we have only to care about other systems > than X11. Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX. Johannes

May 18, 2013

Problems with DuckDuckGo

by sgeerken＠dillo.org

Hi! Somehow, dillo seems to have problems with redirections from DuckDuckGo to other sites. If you search (Ctrl-S) for "foo", with standard preferences, there is no problem, while searching for "foo !i" does not work: dillo stops retrieving the URL <https://duckduckgo.com/lite/?kp=-1&q=foo+%21i>. Entering this URL in Firefox works correctly, redirecting to Google image search. Sebastian

May 18, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Sat, May 11, August Karlstrom wrote: > Linking with libX11 is what's missing: > > LIBS=-lX11 ./configure > make > make install > > This means that libX11 needs to be added to the build scripts. On Mon, May 13, August Karlstrom wrote: > This is what I get: > > $ fltk-config --ldflags > -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk > $ fltk-config --ldstaticflags > -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext > -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 > > >The configure script of dillo uses "--ldflags", which is used for > >dynamic linking against "libfltk.so", while "--ldstaticflags" is used > >for linking against "libfltk.a". Which files of the two do you have in > >the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is > >that "libfltk.so" does not exist and so dillo is linked statically. > > I do have both the dynamic and the static libraries: > > $ ls /usr/lib/x86_64-linux-gnu/libfltk* > /usr/lib/x86_64-linux-gnu/libfltk.a > [..] > /usr/lib/x86_64-linux-gnu/libfltk.so > /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11. Sebastian

May 18, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-13 13:21, Sebastian Geerken wrote: > On Sat, May 11, August Karlstrom wrote: >> [...] >> Linking with libX11 is what's missing: >> >> LIBS=-lX11 ./configure >> make >> make install >> >> This means that libX11 needs to be added to the build scripts. > > I've looked at the fltk-config script, and found that it has two > options: > > $ fltk-config --ldflags > -L/usr/lib/x86_64-linux-gnu -lfltk > $ fltk-config --ldstaticflags > /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 This is what I get: $ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk $ fltk-config --ldstaticflags -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 > The configure script of dillo uses "--ldflags", which is used for > dynamic linking against "libfltk.so", while "--ldstaticflags" is used > for linking against "libfltk.a". Which files of the two do you have in > the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is > that "libfltk.so" does not exist and so dillo is linked statically. I do have both the dynamic and the static libraries: $ ls /usr/lib/x86_64-linux-gnu/libfltk* /usr/lib/x86_64-linux-gnu/libfltk.a /usr/lib/x86_64-linux-gnu/libfltk_cairo.a /usr/lib/x86_64-linux-gnu/libfltk_cairo.so /usr/lib/x86_64-linux-gnu/libfltk_cairo.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_forms.a /usr/lib/x86_64-linux-gnu/libfltk_forms.so /usr/lib/x86_64-linux-gnu/libfltk_forms.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_gl.a /usr/lib/x86_64-linux-gnu/libfltk_gl.so /usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_images.a /usr/lib/x86_64-linux-gnu/libfltk_images.so /usr/lib/x86_64-linux-gnu/libfltk_images.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk.so /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 Regards, August

May 13, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Sat, May 11, August Karlstrom wrote: > [...] > Linking with libX11 is what's missing: > > LIBS=-lX11 ./configure > make > make install > > This means that libX11 needs to be added to the build scripts. I've looked at the fltk-config script, and found that it has two options: $ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -lfltk $ fltk-config --ldstaticflags /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 The configure script of dillo uses "--ldflags", which is used for dynamic linking against "libfltk.so", while "--ldstaticflags" is used for linking against "libfltk.a". Which files of the two do you have in the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is that "libfltk.so" does not exist and so dillo is linked statically. (A simple test confirms this: renaming "libfltk.so" results in similar errors.) For this case, the configure script of dillo should be modified. My suggestions: - Generally make it possible to use "--ldstaticflags". An option for this, "--enable-static-fltk"? - There should be some tests to detect this error. Sebastian

May 13, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-11 21:38, Jorge Arellano Cid wrote: > On Sat, May 11, 2013 at 06:46:53PM +0200, August Karlstrom wrote: >> Linking with libX11 is what's missing: >> >> LIBS=-lX11 ./configure >> make >> make install >> >> This means that libX11 needs to be added to the build scripts. > > I'm using Debian on amd64 and -lX11 doesn't appear in the options, > though it compiles OK, but libX11.so.6 gets linked anyway! > > (AFAICS X11 gets in indirectly by including FL/x.H in xembed.c). > > What OS are you using? Lubuntu 13.04 with Blackbox window manager. /August

May 11, 2013

Can't compile Dillo 3.0.3

by jcid＠dillo.org

On Sat, May 11, 2013 at 06:46:53PM +0200, August Karlstrom wrote: > On 2013-05-10 22:48, August Karlstrom wrote: > >On 2013-05-10 17:44, Sebastian Geerken wrote: > >>It is identical to mine (Debian wheezy amd64) except this option: > >> > >>>-Wl,-Bsymbolic-functions > >> > >>Maybe you should try it without it (simply by typing the command > >>manually). The documentation does not give a reason for hope, however > >>(man ld): > >> > >> -Bsymbolic-functions > >> When creating a shared library, bind references to global > >>function > >> symbols to the definition within the shared library, if > >>any. This > >> option is only meaningful on ELF platforms which support > >>shared > >> libraries. > > > >Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions. > > Linking with libX11 is what's missing: > > LIBS=-lX11 ./configure > make > make install > > This means that libX11 needs to be added to the build scripts. I'm using Debian on amd64 and -lX11 doesn't appear in the options, though it compiles OK, but libX11.so.6 gets linked anyway! (AFAICS X11 gets in indirectly by including FL/x.H in xembed.c). What OS are you using? -- Cheers Jorge.-

May 11, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-10 22:48, August Karlstrom wrote: > On 2013-05-10 17:44, Sebastian Geerken wrote: >> It is identical to mine (Debian wheezy amd64) except this option: >> >>> -Wl,-Bsymbolic-functions >> >> Maybe you should try it without it (simply by typing the command >> manually). The documentation does not give a reason for hope, however >> (man ld): >> >> -Bsymbolic-functions >> When creating a shared library, bind references to global >> function >> symbols to the definition within the shared library, if >> any. This >> option is only meaningful on ELF platforms which support >> shared >> libraries. > > Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions. Linking with libX11 is what's missing: LIBS=-lX11 ./configure make make install This means that libX11 needs to be added to the build scripts. Regards, August

May 11, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-10 17:44, Sebastian Geerken wrote: > It is identical to mine (Debian wheezy amd64) except this option: > >> -Wl,-Bsymbolic-functions > > Maybe you should try it without it (simply by typing the command > manually). The documentation does not give a reason for hope, however > (man ld): > > -Bsymbolic-functions > When creating a shared library, bind references to global function > symbols to the definition within the shared library, if any. This > option is only meaningful on ELF platforms which support shared > libraries. Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions. /August

May 10, 2013

Can't compile Dillo 3.0.3

by sgeerken＠dillo.org

On Fri, May 10, August Karlstrom wrote: > On 2013-05-10 11:48, Johannes Hofmann wrote: > >Could you please post the linker command line? > > Sure, here it is: > > g++ -I/usr/include/libpng12 -I/usr/include/cairo > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -I/usr/include/pixman-1 -I/usr/include/freetype2 > -I/usr/include/libpng12 -I/usr/include/freetype2 > -I/usr/include/cairo -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti > -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o > ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o > history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o > chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o > dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o > html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o > image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a > ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a > ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg > -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 > -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz > -lpthread It is identical to mine (Debian wheezy amd64) except this option: > -Wl,-Bsymbolic-functions Maybe you should try it without it (simply by typing the command manually). The documentation does not give a reason for hope, however (man ld): -Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries. > >You could try > >export LDFLAGS=-lX11 > >and then run configure;make again. I have found it always convenient to type something like: $ CFLAGS=... ./configure The modified variables become part of the generated Makefile. Sebastian

May 10, 2013

Can't compile Dillo 3.0.3

by fusionfile＠gmail.com

On 2013-05-10 11:48, Johannes Hofmann wrote: > Could you please post the linker command line? Sure, here it is: g++ -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz -lpthread > You could try > export LDFLAGS=-lX11 > and then run configure;make again. Unfortunately, this did not make a difference. Thanks Johannes for taking the time. Regards, August

May 10, 2013

Can't compile Dillo 3.0.3

by Johannes.Hofmann＠gmx.de

Hi August, On Fri, May 10, 2013 at 11:33:13AM +0200, August Karlstrom wrote: > I'm trying to compile Dillo 3.0.3 but I get an error from the linker saying: > > /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' > /usr/bin/ld: note: 'XSync' is defined in DSO > /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker > command line > > How do I add -lX11 to the linker command line? I have tried > > $ LDLIBS=-lX11 make > > but it makes no difference. My OS is Lubuntu 13.04. Could you please post the linker command line? You could try export LDFLAGS=-lX11 and then run configure;make again. Please let us know how this works. It might be that we are missing an explicit -lX11 somewhere and rely on fltkconfig --ldflags to add it - which may not be sufficient in some cases. Cheers, Johannes

May 10, 2013

MSG and different levels of chattiness

by corvid＠lavabit.com

I was thinking this morning about how dillo can either be set to be extremely chatty or basically silent, and that maybe it would be good to have some intermediate possibilities. So here I tried adding a msg_level_min (1-4: 1 for msgs like open_url, 2 for policies like denying redirection or information like creating a file, 3 for warnings, 4 for dillo errors) : http://www.dillo.org/test/msg_levels.diff dillorc makes it sound like show_msg is mostly for debugging, whereas we use stdout a fair amount for msgs that we want a user to see... But then there's the fact that maybe no one runs anything from a cmdline anymore, in which case maybe we should also/instead be logging to a fltk window that can pop up like the window for html bugs -- or possibly a widget that can show up in the UI (although the latter might be brittle and an excessive amount of trouble).

April 26, 2013

3.0.3 does not compile on Debian GNU/Hurd (was: dillo-3.0.3 release is ready for download!)

by sgeerken＠dillo.org

On Mon, Apr 22, Axel Beckert wrote: > On Wed, Apr 17, 2013 at 06:09:35PM +0200, Axel Beckert wrote: > > Debian package is in the works. Compiled fine already multiple times. > > :-) > > It failed to build on Debian GNU/Hurd since PATH_MAX seems only > optional in POSIX and not defined on Hurd. (See also > http://www.gnu.org/software/hurd/hurd/porting/guidelines.html) > > Full build log at > https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=hurd-i386&ver=3.0… > > 3.0.2?compiled fine about 11 months ago: > https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=hurd-i386&ver=3.0… > > The following patch by Pino Toscano fixes this issue. I've applied it > to the Debian package for now, but would be happy if it (or a similar > patch) would be incorporated into Dillo officially. > > http://patch-tracker.debian.org/patch/series/view/dillo/3.0.3-2/FTBFS-on-hu… Has been applied. > Otherwise Dillo 3.0.3 works fine as expected. :-) Good! Sebastian

April 23, 2013