From jorl17.8 at gmail.com Sun Feb 1 01:06:49 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Sun Feb 1 01:07:54 2009 Subject: [Dillo-dev] Close-tab Button Message-ID: <1233446809.7062.0.camel@jorl17-laptop> Greetings to all. As a simple introduction may I say I thank you all for your work on Dillo. Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev. FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list. For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI). After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it. Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup. Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button. It may not seem reliable to do so many things in handle(). Any suggestions? It is functional, only you can say if it fully suits Dillo's needs though. Unfortunately, there are some problems: The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that. The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash. Thanks, Jo?o From onepoint at starurchin.org Sun Feb 1 02:45:52 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Feb 1 02:46:31 2009 Subject: [Dillo-dev] [Patch]: fix URL leak in Html_tag_open_link() Message-ID: <20090201014552.GC23164@omphalos.singularity> If Html_tag_open_link() gets a link that it decides not to use because of the media attribute, it returns without freeing the URL object it just created. The fix is to postpone creating the URL until after all the checks that might cause the function to return. Patch and test case attached. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1233451875 0 # Node ID b2673125b9232698640f087e7e09dfd17e863b45 # Parent 8568a970ae65ff3d50f78d59d219af2f92e3834f [mq]: fix-Html_tag_open_link-leaks-url diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -2852,8 +2852,7 @@ /* CSS stylesheet link */ if ((!(attrbuf = a_Html_get_attr(html, tag, tagsize, "rel")) || dStrcasecmp(attrbuf, "stylesheet")) || - (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "href")) || - !(url = a_Html_url_new(html, attrbuf, NULL, 0)))) + (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "href")))) return; /* IMPLIED attributes? */ if (((attrbuf = a_Html_get_attr(html, tag, tagsize, "type")) && @@ -2862,6 +2861,9 @@ !dStristr(attrbuf, "screen") && dStrcasecmp(attrbuf, "all"))) return; + if (!(url = a_Html_url_new(html, attrbuf, NULL, 0))) + return; + MSG(" Html_tag_open_link(): URL=%s\n", URL_STR(url)); _MSG(" repush after HEAD=%d\n", html->repush_after_head); -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20090201/b69ad6e5/index.html From corvid at lavabit.com Sun Feb 1 03:24:30 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 1 03:27:09 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090131215745.GA3135@assam.teanet> References: <20090131215745.GA3135@assam.teanet> Message-ID: <20090201022430.GA27697@local.gobigwest.com> Michal wrote: > Hi, > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > following sence (it's in Czech) > > "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" > > but in current hg tip it's displayed as > > "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > I noticed this first when the character coding code in post-dillo-2.0 > was changed. > > When the page is saved to disk and opened it works as expected. > > It appeared that it is somehow related to default dillorc. > > 1) remove the ~/.dillo directory > 2) dillo www.blisty.cz > 3) --> PASS > 4) quit dillo > 5) dillo www.blisty.cz > 6) --> FAIL > > Can anyone, please, have a look at this and say whether is it > reproducible and, perhaps, fix it? :) Breaks for me, too. Plus having to wait through 116K of download before anything appears is no fun. From corvid at lavabit.com Sun Feb 1 06:45:43 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 1 06:47:48 2009 Subject: [Dillo-dev] patch: 30x response without Location == segfault Message-ID: <20090201054542.GD27702@local.gobigwest.com> (new bug #886) The submitter got a 300 Multiple Choices without a Location header. from the RFC, If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. and Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. In this case, http://www.weather.gov/data/current_obs/PAFC.xml had no Location, and does have a body consisting of an HTML page giving alternatives. PS I think it might become more common for users to encounter Multiple Choices now that there's a pref for Accept-Language. -------------- next part -------------- diff -r 85d7464d4bba src/cache.c --- a/src/cache.c Sat Jan 31 21:18:42 2009 +0000 +++ b/src/cache.c Sun Feb 01 05:25:49 2009 +0000 @@ -642,7 +642,6 @@ static void Cache_parse_header(CacheEntr #ifndef DISABLE_COOKIES Dlist *Cookies; #endif - DilloUrl *location_url; Dlist *warnings; void *data; int i; @@ -660,26 +659,28 @@ static void Cache_parse_header(CacheEntr } if (header[9] == '3' && header[10] == '0') { /* 30x: URL redirection */ - entry->Flags |= CA_Redirect; - if (header[11] == '1') - entry->Flags |= CA_ForceRedirect; /* 301 Moved Permanently */ - else if (header[11] == '2') - entry->Flags |= CA_TempRedirect; /* 302 Temporary Redirect */ + if ((location_str = Cache_parse_field(header, "Location"))) { + DilloUrl *location_url; + + entry->Flags |= CA_Redirect; + if (header[11] == '1') + entry->Flags |= CA_ForceRedirect; /* 301 Moved Permanently */ + else if (header[11] == '2') + entry->Flags |= CA_TempRedirect; /* 302 Temporary Redirect */ - location_str = Cache_parse_field(header, "Location"); - location_url = a_Url_new(location_str, URL_STR_(entry->Url)); - if (URL_FLAGS(location_url) & (URL_Post + URL_Get) && - dStrcasecmp(URL_SCHEME(location_url), "dpi") == 0 && - dStrcasecmp(URL_SCHEME(entry->Url), "dpi") != 0) { - /* Forbid dpi GET and POST from non dpi-generated urls */ - MSG("Redirection Denied! '%s' -> '%s'\n", - URL_STR(entry->Url), URL_STR(location_url)); - a_Url_free(location_url); - } else { - entry->Location = location_url; - } - dFree(location_str); - + location_url = a_Url_new(location_str, URL_STR_(entry->Url)); + if (URL_FLAGS(location_url) & (URL_Post + URL_Get) && + dStrcasecmp(URL_SCHEME(location_url), "dpi") == 0 && + dStrcasecmp(URL_SCHEME(entry->Url), "dpi") != 0) { + /* Forbid dpi GET and POST from non dpi-generated urls */ + MSG("Redirection Denied! '%s' -> '%s'\n", + URL_STR(entry->Url), URL_STR(location_url)); + a_Url_free(location_url); + } else { + entry->Location = location_url; + } + dFree(location_str); + } } else if (strncmp(header + 9, "401", 3) == 0) { entry->Auth = Cache_parse_multiple_fields(header, "WWW-Authenticate"); From onepoint at starurchin.org Sun Feb 1 09:00:57 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Feb 1 09:01:31 2009 Subject: DO NOT: [Dillo-dev] [Patch]: fix URL leak in Html_tag_open_link() In-Reply-To: <20090201014552.GC23164@omphalos.singularity> References: <20090201014552.GC23164@omphalos.singularity> Message-ID: <20090201080057.GD23164@omphalos.singularity> Oops, I've got a reproducible crash from this patch. Let we figure out where I messed it up. Jeremy Henty From onepoint at starurchin.org Sun Feb 1 09:32:14 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Feb 1 09:32:49 2009 Subject: [Dillo-dev] [Patch]: [v2]: fix URL leak in Html_tag_open_link() Message-ID: <20090201083214.GE23164@omphalos.singularity> OK, I'm fairly sure this version is not as utterly broken as the previous one. :-) BTW, does a_Html_tag_open_link() really need to check the stylesheets preference twice? Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1233476501 0 # Node ID 609cfb1ad51538fc8f7d12d83b7148a48a37b109 # Parent 8568a970ae65ff3d50f78d59d219af2f92e3834f [mq]: fix-Html_tag_open_link-leaks-url diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -2850,11 +2850,10 @@ return; /* CSS stylesheet link */ - if ((!(attrbuf = a_Html_get_attr(html, tag, tagsize, "rel")) || - dStrcasecmp(attrbuf, "stylesheet")) || - (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "href")) || - !(url = a_Html_url_new(html, attrbuf, NULL, 0)))) + if (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "rel")) || + dStrcasecmp(attrbuf, "stylesheet")) return; + /* IMPLIED attributes? */ if (((attrbuf = a_Html_get_attr(html, tag, tagsize, "type")) && dStrcasecmp(attrbuf, "text/css")) || @@ -2862,6 +2861,12 @@ !dStristr(attrbuf, "screen") && dStrcasecmp(attrbuf, "all"))) return; + if (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "href"))) + return; + + if (!(url = a_Html_url_new(html, attrbuf, NULL, 0))) + return; + MSG(" Html_tag_open_link(): URL=%s\n", URL_STR(url)); _MSG(" repush after HEAD=%d\n", html->repush_after_head); From jcid at dillo.org Sun Feb 1 16:23:05 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 16:23:11 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090201022430.GA27697@local.gobigwest.com> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> Message-ID: <20090201152305.GM5972@dillo.org> On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > Michal wrote: > > Hi, > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > following sence (it's in Czech) > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > but in current hg tip it's displayed as > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > I noticed this first when the character coding code in post-dillo-2.0 > > was changed. > > > > When the page is saved to disk and opened it works as expected. > > > > It appeared that it is somehow related to default dillorc. > > > > 1) remove the ~/.dillo directory > > 2) dillo www.blisty.cz > > 3) --> PASS > > 4) quit dillo > > 5) dillo www.blisty.cz > > 6) --> FAIL > > > > Can anyone, please, have a look at this and say whether is it > > reproducible and, perhaps, fix it? :) > > Breaks for me, too. > > Plus having to wait through 116K of download before anything > appears is no fun. It works for me! :-) Seriously, I still have a pending item to review here, and it's when charset appears after the stylesheet in HEAD. This page also has timing issues: http://www.daemonnews.org It looks like queueing the stylesheets and asking for them after charset or at head close may fix it. I want to update the image process documentation before getting into this bug. If *somebody* wants to do it before me, go ahead! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Sun Feb 1 16:53:32 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 1 16:55:32 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090201152305.GM5972@dillo.org> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> Message-ID: <20090201155332.GF27702@local.gobigwest.com> Jorge wrote: > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > Michal wrote: > > > Hi, > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > following sence (it's in Czech) > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > but in current hg tip it's displayed as > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > was changed. > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > 1) remove the ~/.dillo directory > > > 2) dillo www.blisty.cz > > > 3) --> PASS > > > 4) quit dillo > > > 5) dillo www.blisty.cz > > > 6) --> FAIL > > > > > > Can anyone, please, have a look at this and say whether is it > > > reproducible and, perhaps, fix it? :) > > > > Breaks for me, too. > > > > Plus having to wait through 116K of download before anything > > appears is no fun. > > It works for me! :-) > > Seriously, I still have a pending item to review here, and it's > when charset appears after the stylesheet in HEAD. This page also > has timing issues: http://www.daemonnews.org > > It looks like queueing the stylesheets and asking for them > after charset or at head close may fix it. Does anyone else experience pages not rendering until download is complete? I see this with the dillo.org pages, for instance, since the meta charset is iso-8859-1. From jcid at dillo.org Sun Feb 1 17:41:50 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 17:41:56 2009 Subject: [Dillo-dev] Re: unused parameter warning in http.c In-Reply-To: <20090131220928.GD23594@local.gobigwest.com> References: <20090131220928.GD23594@local.gobigwest.com> Message-ID: <20090201164150.GN5972@dillo.org> On Sat, Jan 31, 2009 at 10:09:28PM +0000, corvid wrote: > surprised me until I remembered that you turned on -W. > I didn't realize that plain C doesn't allow the name > to be left off in those cases. > > What is the usual trick for this? The manpage talks > about an 'unused' attribute, but that sounds like a gcc-ism. In the past, for C, I've used these couple: 1.- Add a dummy test for the unused var. 2.- Remove the parameter from the function and cast it to match. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sun Feb 1 18:18:10 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 18:18:15 2009 Subject: [Dillo-dev] [Patch]: [v2]: fix URL leak in Html_tag_open_link() In-Reply-To: <20090201083214.GE23164@omphalos.singularity> References: <20090201083214.GE23164@omphalos.singularity> Message-ID: <20090201171810.GP5972@dillo.org> On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > OK, I'm fairly sure this version is not as utterly broken as the > previous one. :-) Committed (with just a small change) > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > preference twice? The repush scheme include parsing the HTML header twice. (not a big deal). -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sun Feb 1 18:46:59 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 18:47:05 2009 Subject: [Dillo-dev] patch: 30x response without Location == segfault In-Reply-To: <20090201054542.GD27702@local.gobigwest.com> References: <20090201054542.GD27702@local.gobigwest.com> Message-ID: <20090201174659.GU5972@dillo.org> On Sun, Feb 01, 2009 at 05:45:43AM +0000, corvid wrote: > (new bug #886) > The submitter got a 300 Multiple Choices > without a Location header. > > from the RFC, > If the server has a preferred choice of representation, it SHOULD > include the specific URI for that representation in the Location > field; user agents MAY use the Location field value for automatic > redirection. > and > Unless it was a HEAD request, the response SHOULD include an entity > containing a list of resource characteristics and location(s) from > which the user or user agent can choose the one most appropriate. > > In this case, http://www.weather.gov/data/current_obs/PAFC.xml > had no Location, and does have a body consisting of an > HTML page giving alternatives. > > PS I think it might become more common for users to encounter > Multiple Choices now that there's a pref for Accept-Language. Committed. Please update the bug tracker. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sun Feb 1 18:51:49 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 18:51:55 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <1233446809.7062.0.camel@jorl17-laptop> References: <1233446809.7062.0.camel@jorl17-laptop> Message-ID: <20090201175149.GV5972@dillo.org> On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > Greetings to all. > > As a simple introduction may I say I thank you all for your work on > Dillo. > > Currently, I am trying to implement the Close-Tab button. I've been > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > dillo-dev. > > FLTK Tabs don't support a close-tab button, as many of you have seen, > and the idea was to have a button at the end of the tabs list. > > For that, I created an fltk::Button widget in CustTabGroup. I position > this widget at the end of the tabs list and, then, I add() it to the > CustTabGroup's parent() (UI). > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > such a way that it doesn't resize the button itself, but only moves it. > > Refreshing the button (when changing/adding/closing tabs) is done in the > handle() method of the CustTabGroup. > > Just a second ago I solved one of the problems, which was the fact that > tab_height() returned 0 in the constructor and resize() didn't work. I > worked around that by constructing the button only in event() if > tab_height()>0 and it hasn't been constructed yet. This way we can use > the correct height for the button. > > It may not seem reliable to do so many things in handle(). Any > suggestions? We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects. > It is functional, only you can say if it fully suits Dillo's needs > though. Please post the patch here so we can look at it. > Unfortunately, there are some problems: > > The first one is the most-relevant one. When the list of tabs grows it > can go over the button. I have been trying to fix this, but I can't seem > to do it. > A possible way could (maybe) be to 'trick' the pager into thinking it > has less space left to draw the tabs, and that could possibly be > achieved using update_positions(), although I am having some problems > with that. Or maybe just tweaking the value. After all it's a workaround. > The second problem is a minor one, but annoying. I believe when CSS > rendering is triggered, the render area flickers and that is normal. > However, the way I implemented this (probably because of it being in > handle()) makes the Button also flash. A side affect of being a child of UI. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Sun Feb 1 18:57:59 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 1 18:59:59 2009 Subject: [Dillo-dev] What's left to do for dillo-2.1? In-Reply-To: <20090131140820.GA4051@blob.baaderstrasse.com> References: <20090131131507.GB23164@omphalos.singularity> <20090131140820.GA4051@blob.baaderstrasse.com> Message-ID: <20090201175759.GH27702@local.gobigwest.com> Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). That reminds me, it would be good to add some checking for malicious values before release. From Johannes.Hofmann at gmx.de Sun Feb 1 19:15:43 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 19:23:51 2009 Subject: [Dillo-dev] [Patch]: [v2]: fix URL leak in Html_tag_open_link() In-Reply-To: <20090201171810.GP5972@dillo.org> References: <20090201083214.GE23164@omphalos.singularity> <20090201171810.GP5972@dillo.org> Message-ID: <20090201181543.GA857@blob.baaderstrasse.com> On Sun, Feb 01, 2009 at 02:18:10PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > > > OK, I'm fairly sure this version is not as utterly broken as the > > previous one. :-) > > Committed > (with just a small change) > > > > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > > preference twice? > > The repush scheme include parsing the HTML header twice. > (not a big deal). I think Jeremy is referring to if (!prefs.load_stylesheets) return; in Html_tag_open_link() which seems redundant, as there is /* Remote stylesheets enabled? */ dReturn_if_fail (prefs.load_stylesheets); some lines above. Cheers, Johannes From Johannes.Hofmann at gmx.de Sun Feb 1 19:17:06 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 19:25:01 2009 Subject: [Dillo-dev] Refactored prefs.c to a much smaller size! Message-ID: <20090201181706.GB857@blob.baaderstrasse.com> Excellent! From Johannes.Hofmann at gmx.de Sun Feb 1 19:20:58 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 19:28:51 2009 Subject: [Dillo-dev] What's left to do for dillo-2.1? In-Reply-To: <20090201175759.GH27702@local.gobigwest.com> References: <20090131131507.GB23164@omphalos.singularity> <20090131140820.GA4051@blob.baaderstrasse.com> <20090201175759.GH27702@local.gobigwest.com> Message-ID: <20090201182058.GC857@blob.baaderstrasse.com> On Sun, Feb 01, 2009 at 05:57:59PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > agree? What's left to be done? > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > but we won't pass any ACID test soon anyway. > > I'd like to get the font-size issue on wikipedia.org fixed however - > > help on that is very welcome :-). > > That reminds me, it would be good to add some checking for > malicious values before release. Yes, I think stylengine.cc would be the right place. Maybe we can add some generic checks and remove the ones in html.cc - this needs to be checked. We also need to give cssparser.cc a thorough look regarding potential buffer overflows... Cheers, Johannes From Johannes.Hofmann at gmx.de Sun Feb 1 19:45:39 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 19:53:36 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090201155332.GF27702@local.gobigwest.com> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> Message-ID: <20090201184539.GA1399@blob.baaderstrasse.com> On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > Michal wrote: > > > > Hi, > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > following sence (it's in Czech) > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > but in current hg tip it's displayed as > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > was changed. > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > 1) remove the ~/.dillo directory > > > > 2) dillo www.blisty.cz > > > > 3) --> PASS > > > > 4) quit dillo > > > > 5) dillo www.blisty.cz > > > > 6) --> FAIL > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > reproducible and, perhaps, fix it? :) > > > > > > Breaks for me, too. > > > > > > Plus having to wait through 116K of download before anything > > > appears is no fun. > > > > It works for me! :-) > > > > Seriously, I still have a pending item to review here, and it's > > when charset appears after the stylesheet in HEAD. This page also > > has timing issues: http://www.daemonnews.org > > > > It looks like queueing the stylesheets and asking for them > > after charset or at head close may fix it. > > Does anyone else experience pages not rendering until > download is complete? I see this with the dillo.org > pages, for instance, since the meta charset is iso-8859-1. Yes, I'm also seeing it. Not sure when this started. From jcid at dillo.org Sun Feb 1 19:55:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 19:55:40 2009 Subject: [Dillo-dev] [Patch]: [v2]: fix URL leak in Html_tag_open_link() In-Reply-To: <20090201181543.GA857@blob.baaderstrasse.com> References: <20090201083214.GE23164@omphalos.singularity> <20090201171810.GP5972@dillo.org> <20090201181543.GA857@blob.baaderstrasse.com> Message-ID: <20090201185535.GW5972@dillo.org> On Sun, Feb 01, 2009 at 07:15:43PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 02:18:10PM -0300, Jorge Arellano Cid wrote: > > On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > > > > > OK, I'm fairly sure this version is not as utterly broken as the > > > previous one. :-) > > > > Committed > > (with just a small change) > > > > > > > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > > > preference twice? > > > > The repush scheme include parsing the HTML header twice. > > (not a big deal). > > I think Jeremy is referring to > > if (!prefs.load_stylesheets) > return; > > in Html_tag_open_link() which seems redundant, as there is > > /* Remote stylesheets enabled? */ > dReturn_if_fail (prefs.load_stylesheets); > > some lines above. Oh, Yes! Committed. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sun Feb 1 19:58:13 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 19:58:19 2009 Subject: [Dillo-dev] What's left to do for dillo-2.1? In-Reply-To: <20090201182058.GC857@blob.baaderstrasse.com> References: <20090131131507.GB23164@omphalos.singularity> <20090131140820.GA4051@blob.baaderstrasse.com> <20090201175759.GH27702@local.gobigwest.com> <20090201182058.GC857@blob.baaderstrasse.com> Message-ID: <20090201185813.GX5972@dillo.org> On Sun, Feb 01, 2009 at 07:20:58PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 05:57:59PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > agree? What's left to be done? > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > but we won't pass any ACID test soon anyway. > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > help on that is very welcome :-). > > > > That reminds me, it would be good to add some checking for > > malicious values before release. > > Yes, I think stylengine.cc would be the right place. > Maybe we can add some generic checks and remove the ones in html.cc > - this needs to be checked. > We also need to give cssparser.cc a thorough look regarding potential > buffer overflows... At some point in time the whole browser will need a check against malicious/random data. The dillo-2.x process has been focused on features. I agree that the CSS part needs a review before release. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Sun Feb 1 20:20:33 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 1 20:22:33 2009 Subject: [Dillo-dev] a policy for dillorc vs. style.css conflicts? Message-ID: <20090201192033.GA29275@local.gobigwest.com> I was just looking at some of the prefs that I don't think are doing anything right now, e.g., link_color, force_my_colors... I could stuff them into buildUserStyle(), but I don't know which should prevail in case of conflicts. I can't remember whether I've already mentioned that I've been wondering whether it might be reasonable to rip a bunch of color stuff out of dillorc and expect a dillo user to be able to deal with a well-commented sample style.css instead. From Johannes.Hofmann at gmx.de Sun Feb 1 20:27:58 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 20:35:53 2009 Subject: [Dillo-dev] a policy for dillorc vs. style.css conflicts? In-Reply-To: <20090201192033.GA29275@local.gobigwest.com> References: <20090201192033.GA29275@local.gobigwest.com> Message-ID: <20090201192758.GB1399@blob.baaderstrasse.com> On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > I was just looking at some of the prefs that I > don't think are doing anything right now, e.g., > link_color, force_my_colors... > I could stuff them into buildUserStyle(), but > I don't know which should prevail in case of > conflicts. > > I can't remember whether I've already mentioned that > I've been wondering whether it might be reasonable to > rip a bunch of color stuff out of dillorc and expect > a dillo user to be able to deal with a well-commented > sample style.css instead. Good point. I always favor simplicity so I think we should have just one way to modify the style. Having two (style.css and preferences) just adds confusion. We need to document this properly as you said. Johannes From Johannes.Hofmann at gmx.de Sun Feb 1 21:14:12 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 1 21:22:09 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090201184539.GA1399@blob.baaderstrasse.com> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> Message-ID: <20090201201412.GA6429@blob.baaderstrasse.com> On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > Michal wrote: > > > > > Hi, > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > following sence (it's in Czech) > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > was changed. > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > 2) dillo www.blisty.cz > > > > > 3) --> PASS > > > > > 4) quit dillo > > > > > 5) dillo www.blisty.cz > > > > > 6) --> FAIL > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > Breaks for me, too. > > > > > > > > Plus having to wait through 116K of download before anything > > > > appears is no fun. > > > > > > It works for me! :-) > > > > > > Seriously, I still have a pending item to review here, and it's > > > when charset appears after the stylesheet in HEAD. This page also > > > has timing issues: http://www.daemonnews.org > > > > > > It looks like queueing the stylesheets and asking for them > > > after charset or at head close may fix it. > > > > Does anyone else experience pages not rendering until > > download is complete? I see this with the dillo.org > > pages, for instance, since the meta charset is iso-8859-1. > > Yes, I'm also seeing it. Not sure when this started. According to hg bisect it starts with d29cdb5b842e, but I don't see any obvious issues there. Jorge, can you have a look please? Cheers, Johannes From onepoint at starurchin.org Sun Feb 1 21:45:06 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Feb 1 21:45:53 2009 Subject: [Dillo-dev] [patch]: fix signature of Html_add_new_linkimage() Message-ID: <20090201204506.GA14324@omphalos.singularity> A small cleanup patch. * The return value of Html_add_new_linkimage() is never used, so it should return void. * There's no need to pass the url to Html_add_new_linkimage() as a (DilloUrl **), so just copy the (DilloUrl *) pointer. Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1233515661 0 # Node ID 0453287a7ce814401c5addffc1fe01b1cd280c30 # Parent 6a892184d49851f0e03a85b3859776ab9c271f45 imported patch fix-Html_add_new_linkimage diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -288,17 +288,16 @@ /* * Add a new image. */ -static int Html_add_new_linkimage(DilloHtml *html, - DilloUrl **url, DilloImage *image) +static void Html_add_new_linkimage(DilloHtml *html, + DilloUrl *url, DilloImage *image) { DilloLinkImage *li = dNew(DilloLinkImage, 1); - li->url = *url; + li->url = url; li->image = image; int ni = html->images->size(); html->images->increase(); html->images->set(ni, li); - return ni; } /* @@ -2029,7 +2028,7 @@ load_now = a_UIcmd_get_images_enabled(html->bw) || (a_Capi_get_flags(url) & CAPI_IsCached); - Html_add_new_linkimage(html, &url, load_now ? NULL : Image); + Html_add_new_linkimage(html, url, load_now ? NULL : Image); if (load_now) Html_load_image(html->bw, url, Image); From jcid at dillo.org Sun Feb 1 22:05:09 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 22:05:57 2009 Subject: [Dillo-dev] FIELDSET element Message-ID: <20090201210509.GB22843@dillo.org> Hi, Now that we have align in CSS, it may be easy to add support for the FIELDSET element: http://www.w3.org/TR/html401/interact/forms.html#h-17.10 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Sun Feb 1 22:15:26 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 1 22:15:32 2009 Subject: [Dillo-dev] FIELDSET element In-Reply-To: <20090201210509.GB22843@dillo.org> References: <20090201210509.GB22843@dillo.org> Message-ID: <20090201211526.GC22843@dillo.org> On Sun, Feb 01, 2009 at 06:05:09PM -0300, Jorge Arellano Cid wrote: > Hi, > > Now that we have align in CSS, it may be easy to add support > for the FIELDSET element: > > http://www.w3.org/TR/html401/interact/forms.html#h-17.10 This is not an urgent matter. I just noticed BUG#720 while updating the bug tracker. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From crazycal00 at gmail.com Sun Feb 1 23:59:49 2009 From: crazycal00 at gmail.com (calvin morrison) Date: Sun Feb 1 23:59:54 2009 Subject: [Dillo-dev] Address Bar Text Clears Message-ID: Hi, Found kind of a bug but dunno if it really counts as one so i figured i'd run it past the mailing list first. open up a website, make sure to pick one that loads slowly and to type it in the address bar. as it's loading open up a new tab, now click back. the URL in the address bar field is empty. just thought i'd share. Calvin From jcid at dillo.org Mon Feb 2 00:56:41 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Feb 2 00:57:22 2009 Subject: [Dillo-dev] [patch]: fix signature of Html_add_new_linkimage() In-Reply-To: <20090201204506.GA14324@omphalos.singularity> References: <20090201204506.GA14324@omphalos.singularity> Message-ID: <20090201235641.GA9926@dillo.org> On Sun, Feb 01, 2009 at 08:45:06PM +0000, Jeremy Henty wrote: > > A small cleanup patch. > > * The return value of Html_add_new_linkimage() is never used, so it > should return void. Committed this part. > > * There's no need to pass the url to Html_add_new_linkimage() as a > (DilloUrl **), so just copy the (DilloUrl *) pointer. It's used to emphasize the url parameter changes owner. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From corvid at lavabit.com Mon Feb 2 00:58:32 2009 From: corvid at lavabit.com (corvid) Date: Mon Feb 2 01:00:35 2009 Subject: [Dillo-dev] Address Bar Text Clears In-Reply-To: References: Message-ID: <20090201235832.GC29275@local.gobigwest.com> Calvin wrote: > open up a website, make sure to pick one that loads slowly and to type > it in the address bar. as it's loading open up a new tab, now click > back. the URL in the address bar field is empty. Hmm...I can't seem to get this to break. Is this the 2.0 release or the current tree? Suitably recent FLTK2 snapshot? Are you running on OSX by any chance? From jorl17.8 at gmail.com Mon Feb 2 01:37:18 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Mon Feb 2 01:37:28 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090201175149.GV5972@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> Message-ID: <1233535038.18551.2.camel@jorl17-laptop> Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > Greetings to all. > > > > As a simple introduction may I say I thank you all for your work on > > Dillo. > > > > Currently, I am trying to implement the Close-Tab button. I've been > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > dillo-dev. > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > and the idea was to have a button at the end of the tabs list. > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > this widget at the end of the tabs list and, then, I add() it to the > > CustTabGroup's parent() (UI). > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > such a way that it doesn't resize the button itself, but only moves it. > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > handle() method of the CustTabGroup. > > > > Just a second ago I solved one of the problems, which was the fact that > > tab_height() returned 0 in the constructor and resize() didn't work. I > > worked around that by constructing the button only in event() if > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > the correct height for the button. > > > > It may not seem reliable to do so many things in handle(). Any > > suggestions? > > We need to get something working, review it, and then we may > ask in fltk.general whether it could have side effects. > > > It is functional, only you can say if it fully suits Dillo's needs > > though. > > Please post the patch here so we can look at it. > > > Unfortunately, there are some problems: > > > > The first one is the most-relevant one. When the list of tabs grows it > > can go over the button. I have been trying to fix this, but I can't seem > > to do it. > > A possible way could (maybe) be to 'trick' the pager into thinking it > > has less space left to draw the tabs, and that could possibly be > > achieved using update_positions(), although I am having some problems > > with that. > > Or maybe just tweaking the value. After all it's a workaround. > > > The second problem is a minor one, but annoying. I believe when CSS > > rendering is triggered, the render area flickers and that is normal. > > However, the way I implemented this (probably because of it being in > > handle()) makes the Button also flash. > > A side affect of being a child of UI. > So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically. Jo?o -------------- next part -------------- A non-text attachment was scrubbed... Name: close-button.diff Type: text/x-patch Size: 3503 bytes Desc: not available Url : /pipermail/attachments/20090202/51a57a0f/close-button.bin From corvid at lavabit.com Mon Feb 2 02:45:43 2009 From: corvid at lavabit.com (corvid) Date: Mon Feb 2 02:47:48 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090201201412.GA6429@blob.baaderstrasse.com> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> <20090201201412.GA6429@blob.baaderstrasse.com> Message-ID: <20090202014543.GD29275@local.gobigwest.com> Johannes wrote: > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > Michal wrote: > > > > > > Hi, > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > following sence (it's in Czech) > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > was changed. > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > 2) dillo www.blisty.cz > > > > > > 3) --> PASS > > > > > > 4) quit dillo > > > > > > 5) dillo www.blisty.cz > > > > > > 6) --> FAIL > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > Breaks for me, too. > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > appears is no fun. > > > > > > > > It works for me! :-) > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > when charset appears after the stylesheet in HEAD. This page also > > > > has timing issues: http://www.daemonnews.org > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > after charset or at head close may fix it. > > > > > > Does anyone else experience pages not rendering until > > > download is complete? I see this with the dillo.org > > > pages, for instance, since the meta charset is iso-8859-1. > > > > Yes, I'm also seeing it. Not sure when this started. > > According to hg bisect it starts with d29cdb5b842e, > but I don't see any obvious issues there. > Jorge, can you have a look please? With html->stop_parser = true; /* Avoid a race condition */ in Html_tag_open_meta(), we don't get to Html_tag_close_head in the usual way. We have to wait until the cache client callback is called with CA_Close, triggering DilloHtml::finishParsing, which closes all of the open tags. Html_tag_close_head() is called and we finally get our repush(). From crazycal00 at gmail.com Mon Feb 2 04:46:34 2009 From: crazycal00 at gmail.com (calvin morrison) Date: Mon Feb 2 04:47:07 2009 Subject: [Dillo-dev] Address Bar Text Clears In-Reply-To: <20090201235832.GC29275@local.gobigwest.com> References: <20090201235832.GC29275@local.gobigwest.com> Message-ID: Ubuntu 8.10 right off the website, all the latest stable releases. It's got to be before the page actually loads. I'll try to recreate it on my laptop. I've been able to duplicate the problem on, but only when accessing a wikispaces page? if you tab away and tab back the url disappers from the address bar. On Sun, Feb 1, 2009 at 11:58 PM, corvid wrote: > Calvin wrote: >> open up a website, make sure to pick one that loads slowly and to type >> it in the address bar. as it's loading open up a new tab, now click >> back. the URL in the address bar field is empty. > > Hmm...I can't seem to get this to break. > Is this the 2.0 release or the current tree? > Suitably recent FLTK2 snapshot? > Are you running on OSX by any chance? > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From Johannes.Hofmann at gmx.de Mon Feb 2 07:17:33 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Mon Feb 2 07:25:25 2009 Subject: [Dillo-dev] Address Bar Text Clears In-Reply-To: References: <20090201235832.GC29275@local.gobigwest.com> Message-ID: <20090202061733.GB914@blob.baaderstrasse.com> On Mon, Feb 02, 2009 at 03:46:34AM +0000, calvin morrison wrote: > Ubuntu 8.10 right off the website, all the latest stable releases. > It's got to be before the page actually loads. What does "dillo -v" report as version? Cheers, Johannes From Hole.destructor at gmx.de Mon Feb 2 10:07:44 2009 From: Hole.destructor at gmx.de (Hole.destructor@gmx.de) Date: Mon Feb 2 10:08:22 2009 Subject: [Dillo-dev] Rendering XHTML 1.1 Message-ID: <4986B7E0.8060508@gmx.de> Hello Dillo developers, since you are planing to release Dillo-2.1 in about a month, I am wondering whether there are plans to support XHTML 1.1, HTML 5 and XHTML 2 web pages in the near future? Thanks, Alexander. From onepoint at starurchin.org Mon Feb 2 10:53:28 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon Feb 2 10:54:03 2009 Subject: [Dillo-dev] [patch]: fix signature of Html_add_new_linkimage() In-Reply-To: <20090201235641.GA9926@dillo.org> References: <20090201204506.GA14324@omphalos.singularity> <20090201235641.GA9926@dillo.org> Message-ID: <20090202095328.GD14324@omphalos.singularity> On Sun, Feb 01, 2009 at 08:56:41PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 01, 2009 at 08:45:06PM +0000, Jeremy Henty wrote: > > > * There's no need to pass the url to Html_add_new_linkimage() as > > a (DilloUrl **), so just copy the (DilloUrl *) pointer. > > It's used to emphasize the url parameter changes owner. Fair enough, but it didn't convey that to me at all. It just looked obviously wrong. I wonder if a comment would make the point better. Just a thought. Regards, Jeremy Henty From jcid at dillo.org Mon Feb 2 13:42:20 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Feb 2 13:42:52 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090202014543.GD29275@local.gobigwest.com> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> <20090201201412.GA6429@blob.baaderstrasse.com> <20090202014543.GD29275@local.gobigwest.com> Message-ID: <20090202124220.GA6690@dillo.org> On Mon, Feb 02, 2009 at 01:45:43AM +0000, corvid wrote: > Johannes wrote: > > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > > Michal wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > > following sence (it's in Czech) > > > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > > was changed. > > > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > > 2) dillo www.blisty.cz > > > > > > > 3) --> PASS > > > > > > > 4) quit dillo > > > > > > > 5) dillo www.blisty.cz > > > > > > > 6) --> FAIL > > > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > > > Breaks for me, too. > > > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > > appears is no fun. > > > > > > > > > > It works for me! :-) > > > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > > when charset appears after the stylesheet in HEAD. This page also > > > > > has timing issues: http://www.daemonnews.org > > > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > > after charset or at head close may fix it. > > > > > > > > Does anyone else experience pages not rendering until > > > > download is complete? I see this with the dillo.org > > > > pages, for instance, since the meta charset is iso-8859-1. > > > > > > Yes, I'm also seeing it. Not sure when this started. > > > > According to hg bisect it starts with d29cdb5b842e, > > but I don't see any obvious issues there. > > Jorge, can you have a look please? > > With > html->stop_parser = true; /* Avoid a race condition */ > in Html_tag_open_meta(), we don't get to Html_tag_close_head > in the usual way. We have to wait until the cache client callback > is called with CA_Close, triggering DilloHtml::finishParsing, > which closes all of the open tags. Html_tag_close_head() > is called and we finally get our repush(). Good analysis. I'm looking into both issues... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcid at dillo.org Tue Feb 3 13:34:17 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Feb 3 13:34:57 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090202124220.GA6690@dillo.org> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> <20090201201412.GA6429@blob.baaderstrasse.com> <20090202014543.GD29275@local.gobigwest.com> <20090202124220.GA6690@dillo.org> Message-ID: <20090203123417.GB9663@dillo.org> On Mon, Feb 02, 2009 at 09:42:20AM -0300, Jorge Arellano Cid wrote: > On Mon, Feb 02, 2009 at 01:45:43AM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > > > Michal wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > > > following sence (it's in Czech) > > > > > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > > > was changed. > > > > > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > > > 2) dillo www.blisty.cz > > > > > > > > 3) --> PASS > > > > > > > > 4) quit dillo > > > > > > > > 5) dillo www.blisty.cz > > > > > > > > 6) --> FAIL > > > > > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > > > > > Breaks for me, too. > > > > > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > > > appears is no fun. > > > > > > > > > > > > It works for me! :-) > > > > > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > > > when charset appears after the stylesheet in HEAD. This page also > > > > > > has timing issues: http://www.daemonnews.org > > > > > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > > > after charset or at head close may fix it. > > > > > > > > > > Does anyone else experience pages not rendering until > > > > > download is complete? I see this with the dillo.org > > > > > pages, for instance, since the meta charset is iso-8859-1. > > > > > > > > Yes, I'm also seeing it. Not sure when this started. > > > > > > According to hg bisect it starts with d29cdb5b842e, > > > but I don't see any obvious issues there. > > > Jorge, can you have a look please? > > > > With > > html->stop_parser = true; /* Avoid a race condition */ > > in Html_tag_open_meta(), we don't get to Html_tag_close_head > > in the usual way. We have to wait until the cache client callback > > is called with CA_Close, triggering DilloHtml::finishParsing, > > which closes all of the open tags. Html_tag_close_head() > > is called and we finally get our repush(). > > Good analysis. > > I'm looking into both issues... OK, the tip has a patch for both problems. It passes these tests: Feb03 load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_S OK OK OK S = has remote CSS stylesheet HMS OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __S OK OK OK t = timing issue _MS OK OK OK x = always fails ---------------------------- and the reported cases too. I still don't feel comfortable with this part of the code: it's complex and has the Cache_ref() trick. Anyway, as far as tests are concerned it behaves well. Please test and report. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Johannes.Hofmann at gmx.de Tue Feb 3 13:47:48 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Tue Feb 3 13:55:43 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090130152246.GS5972@dillo.org> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> Message-ID: <20090203124748.GC2126@blob.baaderstrasse.com> yOn Fri, Jan 30, 2009 at 12:22:46PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > often I get a 404 Not Found and right now it's hanging. Everyone > > confirms that Mercurial itself is really fast and I've seen other > > reports criticising FreeHG's performance. Perhaps we should think > > about moving host? It's not always easy to find time to devote to > > Dillo so it's rather aggravating when that time is wasted just waiting > > for a connection to the server. I'm committed enough to grit my teeth > > and wait but I can see it putting off would-be contributors. > > > > Just a thought, > > Yes, I've also had trouble with it, and when normal it's slower > than our Wearlab's CVS. > > A couple of days ago (while developoing/reviewing patches) I > digged a bit on it and it seems that bitbucket is much faster. We > can try bitbucket while we find a long term solution (e.g. FSF's > savannah is offering Mercurial and Git repos, but the applying > process may take some time). > > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. > > Suggestions? I agree. freehg.org is just very simple to setup so I chose that for the CSS prototype. I doubt that setting up a savannah project would take very long. Anyone volunteering? Cheers, Johannes From onepoint at starurchin.org Tue Feb 3 14:45:36 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Tue Feb 3 14:46:14 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090203124748.GC2126@blob.baaderstrasse.com> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> Message-ID: <20090203134536.GI6099@omphalos.singularity> On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > I doubt that setting up a savannah project would take very long. Really? I just had a look and there's a long checklist. You have to supply a fairly detailed project description, so the core devs would have to agree to one before signing up. You have to list all your dependencies and assert that they are free too. You also have to check that all your files have a valid copyright notice, which is currently not true of most of our *.{h,hh} files. (Mind you, I got a laugh from their "I read carefully and won't check this" item.) I asked the local Linux Users Group for recommendations and bitbucket was mentioned. What do people think? Terms of service: http://bitbucket.org/site/terms/ Note the clauses: By submitting Content to Avantlumiere for inclusion on your Website, you grant Avantlumiere a world-wide, royalty-free, and non-exclusive license to reproduce, modify, adapt and publish the Content solely for the purpose of displaying, distributing and promoting your account or repository. I guess the "solely for the purpose of displaying ..." clause makes that OK. They presumably want to be able to advertise the fact that they host Dillo without us claiming copyright infringement, which is fair enough. Also: Avantlumiere reserves the right, at its sole discretion, to modify or replace any part of this Agreement. It is your responsibility to check this Agreement periodically for changes. Your continued use of or access to the Website following the posting of any changes to this Agreement constitutes acceptance of those changes. That makes me nervous, but bitbucket is popular so I guess people trust them not to mess their customers around. I'll set up a BitBucket repo if people agree. Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Tue Feb 3 15:10:11 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Tue Feb 3 15:18:06 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090203134536.GI6099@omphalos.singularity> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> <20090203134536.GI6099@omphalos.singularity> Message-ID: <20090203141011.GE2126@blob.baaderstrasse.com> On Tue, Feb 03, 2009 at 01:45:36PM +0000, Jeremy Henty wrote: > On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > > > I doubt that setting up a savannah project would take very long. > > Really? I just had a look and there's a long checklist. You have to > supply a fairly detailed project description, so the core devs would > have to agree to one before signing up. You have to list all your > dependencies and assert that they are free too. You also have to > check that all your files have a valid copyright notice, which is > currently not true of most of our *.{h,hh} files. (Mind you, I got a > laugh from their "I read carefully and won't check this" item.) Oh sorry, should have checked more carefully... > > I asked the local Linux Users Group for recommendations and bitbucket > was mentioned. What do people think? > > Terms of service: http://bitbucket.org/site/terms/ > > Note the clauses: > > By submitting Content to Avantlumiere for inclusion on your > Website, you grant Avantlumiere a world-wide, royalty-free, and > non-exclusive license to reproduce, modify, adapt and publish the > Content solely for the purpose of displaying, distributing and > promoting your account or repository. > > I guess the "solely for the purpose of displaying ..." clause makes > that OK. They presumably want to be able to advertise the fact that > they host Dillo without us claiming copyright infringement, which is > fair enough. > > Also: > > Avantlumiere reserves the right, at its sole discretion, to modify > or replace any part of this Agreement. It is your responsibility > to check this Agreement periodically for changes. Your continued > use of or access to the Website following the posting of any > changes to this Agreement constitutes acceptance of those changes. > > That makes me nervous, but bitbucket is popular so I guess people > trust them not to mess their customers around. Argh, I really hate this stuff. I guess we really want an independent server/virtual machine somewhere just as we have at wearlab until now. > > I'll set up a BitBucket repo if people agree. Maybe creating just frequently updated copy there would help already? Regards, Johannes From onepoint at starurchin.org Tue Feb 3 15:30:16 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Tue Feb 3 15:30:51 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090203141011.GE2126@blob.baaderstrasse.com> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> <20090203134536.GI6099@omphalos.singularity> <20090203141011.GE2126@blob.baaderstrasse.com> Message-ID: <20090203143016.GK6099@omphalos.singularity> On Tue, Feb 03, 2009 at 03:10:11PM +0100, Hofmann Johannes wrote: > I guess we really want an independent server/virtual machine > somewhere just as we have at wearlab until now. I already own a virtual machine at bytemark.co.uk. I can look into setting up mercurial there. The Bytemark hosting crew are pretty geek-savvy. Regards, Jeremy Henty From corvid at lavabit.com Tue Feb 3 16:59:40 2009 From: corvid at lavabit.com (corvid) Date: Tue Feb 3 17:01:45 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090203123417.GB9663@dillo.org> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> <20090201201412.GA6429@blob.baaderstrasse.com> <20090202014543.GD29275@local.gobigwest.com> <20090202124220.GA6690@dillo.org> <20090203123417.GB9663@dillo.org> Message-ID: <20090203155940.GJ29275@local.gobigwest.com> Jorge wrote: > I still don't feel comfortable with this part of the code: it's > complex and has the Cache_ref() trick. Anyway, as far as tests > are concerned it behaves well. I find myself thinking again how dicache for image/* with RGB internally is a lot like ??? for text/* with UTF-8 internally but they are handled completely differently. Of course I don't know dicache well enough to be too sure quite how far that analogy holds... From newman.x at gmail.com Tue Feb 3 17:03:09 2009 From: newman.x at gmail.com (Michal Nowak) Date: Tue Feb 3 17:03:14 2009 Subject: [Dillo-dev] Bad character coding for www.blisty.cz In-Reply-To: <20090203123417.GB9663@dillo.org> References: <20090131215745.GA3135@assam.teanet> <20090201022430.GA27697@local.gobigwest.com> <20090201152305.GM5972@dillo.org> <20090201155332.GF27702@local.gobigwest.com> <20090201184539.GA1399@blob.baaderstrasse.com> <20090201201412.GA6429@blob.baaderstrasse.com> <20090202014543.GD29275@local.gobigwest.com> <20090202124220.GA6690@dillo.org> <20090203123417.GB9663@dillo.org> Message-ID: <20090203160307.GA4637@assam.redhat.com> On Tue, Feb 03, 2009 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > OK, the tip has a patch for both problems. > It passes these tests: > > Feb03 load Reload Back > ---------------------------- > H__ OK OK OK H = has charset in HTTP header > HM_ OK OK OK M = has charset in META > H_S OK OK OK S = has remote CSS stylesheet > HMS OK OK OK _ = disabled > ___ OK OK OK > _M_ OK OK OK > __S OK OK OK t = timing issue > _MS OK OK OK x = always fails > ---------------------------- > > and the reported cases too. > > I still don't feel comfortable with this part of the code: it's > complex and has the Cache_ref() trick. Anyway, as far as tests > are concerned it behaves well. > > Please test and report. > Thanks, Jorge, I can confirm it's fixed now. -- Regards, Michal Nowak From jorl17.8 at gmail.com Tue Feb 3 20:48:18 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Tue Feb 3 20:49:46 2009 Subject: [Dillo-dev] [patch] Search Previous Message-ID: <1233690498.6707.6.camel@jorl17-laptop> Greetings. I 'spotted' a TODO on searching 'backwards' and decided to have a go at it. Basically, I implemented the Search Previous feature. I must say I have difficulties understanding the code behind FindtextState::search0(), so I did not base my code on it at all. Sure it could possibly be optimized, but it seems to do the job for now, I haven't found any bugs, if you find any, please do say. Additionally, I did not set any hotkeys for the search-previous action, maybe something like SHIFT+RETURN, since RETURN handles searching forwards? Also, I did not add any tests, and I only altered a line to make them compilable, but I might add some tests soon. Thanks, Jo?o -------------- next part -------------- A non-text attachment was scrubbed... Name: search-previous.diff Type: text/x-patch Size: 8506 bytes Desc: not available Url : /pipermail/attachments/20090203/5968373b/search-previous-0001.bin From Johannes.Hofmann at gmx.de Tue Feb 3 21:39:01 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Tue Feb 3 21:47:01 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <1233690498.6707.6.camel@jorl17-laptop> References: <1233690498.6707.6.camel@jorl17-laptop> Message-ID: <20090203203901.GA28334@blob.baaderstrasse.com> Hello, On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > Greetings. > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > it. Great. > > Basically, I implemented the Search Previous feature. > > I must say I have difficulties understanding the code behind > FindtextState::search0(), so I did not base my code on it at all. Sure > it could possibly be optimized, but it seems to do the job for now, I > haven't found any bugs, if you find any, please do say. FindtextState implements the Knuth-Morris-Pratt algorithm http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm for efficient searching. It is pretty clever but a bit tricky. I see some issues in your implementation. E.g. try to search for 'ab' in a string 'abababa'. Even more tricky is searching for ababb in abababb, i.e. the prefix matches, but once it no longer does you would need to backtrack. The easiest but inefficient way to implement searching is doing a strcmp() at every text position. The Knuth-Morris-Pratt algorithm avoids that. I think it would be best to adapt search0 somehow to allow backward searching - it's more or less the same thing as forward searching anyway. Some ugly edge cases when switching between forward and backward maybe :-) Thanks for working on that, Johannes > > Additionally, I did not set any hotkeys for the search-previous action, > maybe something like SHIFT+RETURN, since RETURN handles searching > forwards? > > Also, I did not add any tests, and I only altered a line to make them > compilable, but I might add some tests soon. > > Thanks, > > Jo?o > diff -r ccdc02768890 dw/findtext.cc > --- a/dw/findtext.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/findtext.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -66,8 +66,9 @@ > hlIterator = NULL; > } > > -FindtextState::Result FindtextState::search (const char *key, bool caseSens) > +FindtextState::Result FindtextState::search (const char *key, bool caseSens, bool backwards) > { > + > if (!widget || *key == 0) // empty keys are not found > return NOT_FOUND; > > @@ -91,13 +92,19 @@ > if (iterator) > delete iterator; > iterator = new CharIterator (widget); > - iterator->next (); > + > + if(backwards) { > + /* Go to end */ > + while(iterator->next () ) ; > + iterator->prev(); //We don't want to be at CharIterator::END. > + } else > + iterator->next (); > } else > newKey = false; > > bool firstTrial = !wasHighlighted || newKey; > > - if (search0 ()) { > + if (backwards ? search0Backwards () : search0 ()) { > // Highlighlighting is done with a clone. > hlIterator = iterator->cloneCharIterator (); > for (int i = 0; key[i]; i++) > @@ -116,10 +123,15 @@ > // Nothing found anymore, reset the state for the next trial. > delete iterator; > iterator = new CharIterator (widget); > - iterator->next (); > + if(backwards) { > + /* Go to end */ > + while(iterator->next () ) ; > + iterator->prev(); //We don't want to be at CharIterator::END. > + } else > + iterator->next (); > > // We expect a success. > - Result result2 = search (key, caseSens); > + Result result2 = search (key, caseSens, backwards); > assert (result2 == SUCCESS); > return RESTART; > } > @@ -179,6 +191,46 @@ > return false; > } > > +/* > + * Search backwards. > + */ > +bool FindtextState::search0Backwards () > +{ > + if (iterator->getChar () == CharIterator::END) > + return false; > + > + bool equal=false; > + int l = strlen (key); > + int j = l; > + > + /* get before the word */ > + for (int i = 0; i < l+1; i++) > + iterator->prev (); > + > + do { > + > + if (charsEqual (iterator->getChar (), key[l==1 ? 0 : j], caseSens)) { > + > + if((j==0 && equal) || l==1) { return true; } > + equal=true; > + > + } else if(j!=l) { > + > + /* Restart the search */ > + equal=false; > + j=l; > + continue; /* Do not iterate back when restarting the search. */ > + > + } > + > + if(!iterator->prev()) return false; /* No more text where to search */ > + > + j--; > + > + } while(true); > + > +} > + > bool FindtextState::search0 () > { > if (iterator->getChar () == CharIterator::END) > diff -r ccdc02768890 dw/findtext.hh > --- a/dw/findtext.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/findtext.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -62,6 +62,7 @@ > static int *createNexttab (const char *key, bool caseSens); > bool unhighlight (); > bool search0 (); > + bool search0Backwards (); > > inline static bool charsEqual (char c1, char c2, bool caseSens) > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > @@ -72,7 +73,7 @@ > ~FindtextState (); > > void setWidget (Widget *widget); > - Result search (const char *key, bool caseSens); > + Result search (const char *key, bool caseSens, bool backwards); > void resetSearch (); > }; > > diff -r ccdc02768890 dw/layout.hh > --- a/dw/layout.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/layout.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -255,8 +255,8 @@ > emitter.connectLayout (receiver); } > > /** \brief See dw::core::FindtextState::search. */ > - inline FindtextState::Result search (const char *str, bool caseSens) > - { return findtextState.search (str, caseSens); } > + inline FindtextState::Result search (const char *str, bool caseSens, int backwards) > + { return findtextState.search (str, caseSens, backwards); } > > /** \brief See dw::core::FindtextState::resetSearch. */ > inline void resetSearch () { findtextState.resetSearch (); } > diff -r ccdc02768890 src/findbar.cc > --- a/src/findbar.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/findbar.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -63,7 +63,21 @@ > > if (key[0] != '\0') > a_UIcmd_findtext_search(a_UIcmd_get_bw_by_widget(fb), > - key, case_sens); > + key, case_sens, false); > +} > + > +/* > + * Find previous occurrence of input key > + */ > +void Findbar::searchBackwards_cb(Widget *, void *vfb) > +{ > + Findbar *fb = (Findbar *)vfb; > + const char *key = fb->i->text(); > + bool case_sens = fb->check_btn->value(); > + > + if (key[0] != '\0') > + a_UIcmd_findtext_search(a_UIcmd_get_bw_by_widget(fb), > + key, case_sens, true); > } > > /* > @@ -96,7 +110,7 @@ > int button_width = 70; > int gap = 2; > int border = 2; > - int input_width = width - (2 * border + 3 * (button_width + gap)); > + int input_width = width - (2 * border + 4 * (button_width + gap)); > int x = border; > height -= 2 * border; > > @@ -121,7 +135,6 @@ > i->clear_tab_to_focus(); > i->set_click_to_focus(); > > - // TODO: search previous would be nice > next_btn = new HighlightButton(x, border, button_width, height, "Next"); > x += button_width + gap; > next_btn->tooltip("Find next occurrence of the search phrase"); > @@ -129,6 +142,12 @@ > next_btn->add_shortcut(KeypadEnter); > next_btn->callback(search_cb, this); > next_btn->clear_tab_to_focus(); > + > + prev_btn= new HighlightButton(x, border, button_width, height, "Previous"); > + prev_btn->tooltip("Find previous occurrence of the search phrase"); > + prev_btn->callback(searchBackwards_cb, this); > + prev_btn->clear_tab_to_focus(); > + x += button_width + gap; > > check_btn = new CheckButton(x, border, 2*button_width, height, > "Case-sensitive"); > diff -r ccdc02768890 src/findbar.hh > --- a/src/findbar.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/findbar.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -16,12 +16,13 @@ > */ > class Findbar : public Group { > Button *clrb; > - HighlightButton *hide_btn, *next_btn; > + HighlightButton *hide_btn, *next_btn, *prev_btn; > CheckButton *check_btn; > xpmImage *hideImg; > Input *i; > > static void search_cb (Widget *, void *); > + static void searchBackwards_cb (Widget *, void *); //add > static void search_cb2 (Widget *, void *); > static void hide_cb (Widget *, void *); > > diff -r ccdc02768890 src/uicmd.cc > --- a/src/uicmd.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/uicmd.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -17,6 +17,8 @@ > #include /* for rint */ > #include > #include > +#include > +#include > > #include "dir.h" > #include "ui.hh" > @@ -964,13 +1032,13 @@ > } > > /* > - * Search for next occurrence of key. > + * Search for next/previous occurrence of key. > */ > -void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens) > +void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens, int backwards) > { > Layout *l = (Layout *)bw->render_layout; > > - switch (l->search(key, case_sens)) { > + switch (l->search(key, case_sens, backwards)) { > case FindtextState::RESTART: > a_UIcmd_set_msg(bw, "No further occurrences of \"%s\". " > "Restarting from the top.", key); > diff -r ccdc02768890 src/uicmd.hh > --- a/src/uicmd.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/uicmd.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -34,7 +34,7 @@ > void a_UIcmd_add_bookmark(BrowserWindow *bw, const DilloUrl *url); > void a_UIcmd_fullscreen_toggle(BrowserWindow *bw); > void a_UIcmd_findtext_dialog(BrowserWindow *bw); > -void a_UIcmd_findtext_search(BrowserWindow *bw,const char *key,int case_sens); > +void a_UIcmd_findtext_search(BrowserWindow *bw,const char *key,int case_sens, int backwards); > void a_UIcmd_findtext_reset(BrowserWindow *bw); > void a_UIcmd_focus_main_area(BrowserWindow *bw); > void a_UIcmd_focus_location(void *vbw); > diff -r ccdc02768890 test/dw_find_test.cc > --- a/test/dw_find_test.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/test/dw_find_test.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -44,7 +44,7 @@ > static void findCallback (::fltk::Widget *widget, void *data) > { > //switch(layout->search ("worm", true)) { > - switch(layout->search ("WORM", false)) { > + switch(layout->search ("WORM", false, false)) { > case FindtextState::SUCCESS: > resultLabel->label("SUCCESS"); > break; > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From jorl17.8 at gmail.com Wed Feb 4 00:54:56 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Wed Feb 4 00:55:05 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <20090203203901.GA28334@blob.baaderstrasse.com> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> Message-ID: <1233705296.6707.123.camel@jorl17-laptop> Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > Hello, > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > Greetings. > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > it. > > Great. > > > > > Basically, I implemented the Search Previous feature. > > > > I must say I have difficulties understanding the code behind > > FindtextState::search0(), so I did not base my code on it at all. Sure > > it could possibly be optimized, but it seems to do the job for now, I > > haven't found any bugs, if you find any, please do say. > > FindtextState implements the Knuth-Morris-Pratt algorithm > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > for efficient searching. It is pretty clever but a bit tricky. > I see some issues in your implementation. E.g. try to search for > 'ab' in a string 'abababa'. > Even more tricky is searching for ababb in abababb, i.e. the prefix > matches, but once it no longer does you would need to backtrack. > The easiest but inefficient way to implement searching > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > algorithm avoids that. > I think it would be best to adapt search0 somehow to allow backward > searching - it's more or less the same thing as forward searching > anyway. Some ugly edge cases when switching between forward and > backward maybe :-) > > Thanks for working on that, > Johannes > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > maybe something like SHIFT+RETURN, since RETURN handles searching > > forwards? > > > > Also, I did not add any tests, and I only altered a line to make them > > compilable, but I might add some tests soon. > > > > Thanks, > > > > Jo?o Thanks for your answer. OK, I am still trying to 'go deep' with the KMP algorithm, but I have got (provisory) working search0Backwards() replacement. How efficient do you think it is to handle the word by reversing it? Rephrasing that, do you think there is a 'really' better way of searching backwards, than reversing the word and searching backwards? As far as code-changes it takes very few lines and I have a working example of it. However, the extra reversing work might hit us hard. Thanks, Jo?o From Johannes.Hofmann at gmx.de Wed Feb 4 08:51:26 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Feb 4 08:59:23 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <1233705296.6707.123.camel@jorl17-laptop> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> Message-ID: <20090204075126.GA891@blob.baaderstrasse.com> On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > Hello, > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > Greetings. > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > it. > > > > Great. > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > I must say I have difficulties understanding the code behind > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > it could possibly be optimized, but it seems to do the job for now, I > > > haven't found any bugs, if you find any, please do say. > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > for efficient searching. It is pretty clever but a bit tricky. > > I see some issues in your implementation. E.g. try to search for > > 'ab' in a string 'abababa'. > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > matches, but once it no longer does you would need to backtrack. > > The easiest but inefficient way to implement searching > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > algorithm avoids that. > > I think it would be best to adapt search0 somehow to allow backward > > searching - it's more or less the same thing as forward searching > > anyway. Some ugly edge cases when switching between forward and > > backward maybe :-) > > > > Thanks for working on that, > > Johannes > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > forwards? > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > compilable, but I might add some tests soon. > > > > > > Thanks, > > > > > > Jo?o > > Thanks for your answer. > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > got (provisory) working search0Backwards() replacement. How efficient do > you think it is to handle the word by reversing it? Rephrasing that, do > you think there is a 'really' better way of searching backwards, than > reversing the word and searching backwards? As far as code-changes it > takes very few lines and I have a working example of it. However, the > extra reversing work might hit us hard. Reversing the word (needle) we are searching for is no problem. It's supposed to be rather small and we only need to reverse it once. The point is to avoid the backtracking. So that every letter in the text (haystack) is only visited once. Regards, Johannes > > Thanks, > > Jo?o > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From jcid at dillo.org Wed Feb 4 14:35:24 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Feb 4 14:35:33 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <20090204075126.GA891@blob.baaderstrasse.com> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> Message-ID: <20090204133524.GH9663@dillo.org> On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > Hello, > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Greetings. > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > it. > > > > > > Great. > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > I must say I have difficulties understanding the code behind > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > haven't found any bugs, if you find any, please do say. > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > for efficient searching. It is pretty clever but a bit tricky. > > > I see some issues in your implementation. E.g. try to search for > > > 'ab' in a string 'abababa'. > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > matches, but once it no longer does you would need to backtrack. > > > The easiest but inefficient way to implement searching > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > algorithm avoids that. > > > I think it would be best to adapt search0 somehow to allow backward > > > searching - it's more or less the same thing as forward searching > > > anyway. Some ugly edge cases when switching between forward and > > > backward maybe :-) > > > > > > Thanks for working on that, > > > Johannes > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > forwards? > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > compilable, but I might add some tests soon. > > > > > > > > Thanks, > > > > > > > > Jo?o > > > > Thanks for your answer. > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > got (provisory) working search0Backwards() replacement. How efficient do > > you think it is to handle the word by reversing it? Rephrasing that, do > > you think there is a 'really' better way of searching backwards, than > > reversing the word and searching backwards? As far as code-changes it > > takes very few lines and I have a working example of it. However, the > > extra reversing work might hit us hard. > > Reversing the word (needle) we are searching for is no problem. It's supposed > to be rather small and we only need to reverse it once. > The point is to avoid the backtracking. So that every letter in the > text (haystack) is only visited once. If reversing the needle is all it takes, go ahead. If the code is simple and it takes twice the time a forward search, go ahead too. Backward search is much less used than forward search and it's better to have it than not, and unless the delay is annoying there's no compelling need to optimize. -- Cheers Jorge.- From onepoint at starurchin.org Wed Feb 4 15:47:51 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Feb 4 15:48:27 2009 Subject: [Dillo-dev] Leaking image structures Message-ID: <20090204144751.GP6099@omphalos.singularity> One of the biggest leaks that valgrind reports is image structures. I'm attaching logs that show memory being allocated by a_Png_new() and cousins and not being freed. There are also frequent leaks of memory allocated by the image libraries from within the various image callbacks, but I suspect these are just another effect of the Dillo image structures not being freed. Unfortunately I'm having a hard time tracking these leaks down. They regularly appear after long browsing sessions, but I haven't found any single page that reproduces them. I suspect they are caused by some race condition inside the CCC rather than the HTML parser. I am browsing with image loading enabled, and if I understand the code correctly that means that the Web structures in the CCC own all the references to image structures. The fact that image structures are reference counted makes it hard to know when the structures should be freed anyway. Indeed, does Dillo even ensure that image structures are freed? Maybe this is just a symptom of incomplete cleanup at exit rather than a true leak? I've looked over the code and can't see any obvious leaks so I'm rather stuck. Any tips for tracking this down? Even if it's not a true leak it would be good to have a fix that cleaned up the valgrind logs. Regards, Jeremy Henty -------------- next part -------------- # ==7655== 32,880 bytes in 1 blocks are possibly lost in loss record 194 of 199 # ==7655== at 0x4021AE8: malloc (vg_replace_malloc.c:207) # ==7655== by 0x8081E50: dMalloc (dlib.c:36) # ==7655== by 0x807BE71: a_Gif_new (gif.c:157) # ==7655== by 0x8062964: Dicache_image (dicache.c:414) # ==7655== by 0x8062A95: a_Dicache_gif_image (dicache.c:450) # ==7655== by 0x8083CAB: a_Mime_set_viewer (mime.c:142) # ==7655== by 0x805E323: a_Web_dispatch_by_type (web.cc:108) # ==7655== by 0x8061275: Cache_process_queue (cache.c:1113) # ==7655== by 0x8060B27: a_Cache_process_dbuf (cache.c:868) # ==7655== by 0x806435F: a_Capi_ccc (capi.c:601) # ==7655== by 0x805CE47: a_Chain_fcb (chain.c:112) # ==7655== by 0x8085263: Dpi_parse_token (dpi.c:219) { Memcheck:Leak fun:malloc fun:dMalloc fun:a_Gif_new fun:Dicache_image fun:a_Dicache_gif_image fun:a_Mime_set_viewer fun:a_Web_dispatch_by_type fun:Cache_process_queue fun:a_Cache_process_dbuf fun:a_Capi_ccc fun:a_Chain_fcb fun:Dpi_parse_token } # ==8963== 36,058 (14,411 direct, 21,647 indirect) bytes in 81 blocks are definitely lost in loss record 196 of 217 # ==8963== at 0x4021AE8: malloc (vg_replace_malloc.c:207) # ==8963== by 0x8081E50: dMalloc (dlib.c:36) # ==8963== by 0x807D319: a_Jpeg_new (jpeg.c:177) # ==8963== by 0x8062990: Dicache_image (dicache.c:414) # ==8963== by 0x8062AC5: a_Dicache_jpeg_image (dicache.c:459) # ==8963== by 0x8083CAB: a_Mime_set_viewer (mime.c:142) # ==8963== by 0x805E323: a_Web_dispatch_by_type (web.cc:108) # ==8963== by 0x8061275: Cache_process_queue (cache.c:1113) # ==8963== by 0x8060B27: a_Cache_process_dbuf (cache.c:868) # ==8963== by 0x806435F: a_Capi_ccc (capi.c:601) # ==8963== by 0x805CE47: a_Chain_fcb (chain.c:112) # ==8963== by 0x8085263: Dpi_parse_token (dpi.c:219) { Memcheck:Leak fun:malloc fun:dMalloc fun:a_Jpeg_new fun:Dicache_image fun:a_Dicache_jpeg_image fun:a_Mime_set_viewer fun:a_Web_dispatch_by_type fun:Cache_process_queue fun:a_Cache_process_dbuf fun:a_Capi_ccc fun:a_Chain_fcb fun:Dpi_parse_token } # ==25646== 92,068 bytes in 11 blocks are possibly lost in loss record 204 of 210 # ==25646== at 0x4021AE8: malloc (vg_replace_malloc.c:207) # ==25646== by 0x4041DAC: jpeg_get_small (in /usr/lib/libjpeg.so.62.0.0) # ==25646== by 0x4040EE4: alloc_small (in /usr/lib/libjpeg.so.62.0.0) # ==25646== by 0x403502C: jinit_marker_reader (in /usr/lib/libjpeg.so.62.0.0) # ==25646== by 0x4032647: jpeg_CreateDecompress (in /usr/lib/libjpeg.so.62.0.0) # ==25646== by 0x807CFDF: a_Jpeg_new (jpeg.c:191) # ==25646== by 0x80623BD: Dicache_image (dicache.c:412) # ==25646== by 0x80624F2: a_Dicache_jpeg_image (dicache.c:457) # ==25646== by 0x8083907: a_Mime_set_viewer (mime.c:142) # ==25646== by 0x805DD53: a_Web_dispatch_by_type (web.cc:108) # ==25646== by 0x8060CB9: Cache_process_queue (cache.c:1115) # ==25646== by 0x806056B: a_Cache_process_dbuf (cache.c:870) { Memcheck:Leak fun:malloc fun:jpeg_get_small fun:alloc_small fun:jinit_marker_reader fun:jpeg_CreateDecompress fun:a_Jpeg_new fun:Dicache_image fun:a_Dicache_jpeg_image fun:a_Mime_set_viewer fun:a_Web_dispatch_by_type fun:Cache_process_queue fun:a_Cache_process_dbuf } # ==23271== 350,107 (7,765 direct, 342,342 indirect) bytes in 58 blocks are definitely lost in loss record 192 of 208 # ==23271== at 0x4021AE8: malloc (vg_replace_malloc.c:207) # ==23271== by 0x8081AAC: dMalloc (dlib.c:36) # ==23271== by 0x8081B0A: dMalloc0 (dlib.c:52) # ==23271== by 0x807DF74: a_Png_new (png.c:422) # ==23271== by 0x8062365: Dicache_image (dicache.c:412) # ==23271== by 0x8062492: a_Dicache_png_image (dicache.c:439) # ==23271== by 0x8083907: a_Mime_set_viewer (mime.c:142) # ==23271== by 0x805DD53: a_Web_dispatch_by_type (web.cc:108) # ==23271== by 0x8060CB9: Cache_process_queue (cache.c:1115) # ==23271== by 0x8060F4E: Cache_delayed_process_queue_callback (cache.c:1206) # ==23271== by 0x4116F87: fltk::wait(float) (in /usr/lib/libfltk2.so.2.0) # ==23271== by 0x411705F: fltk::run() (in /usr/lib/libfltk2.so.2.0) { Memcheck:Leak fun:malloc fun:dMalloc fun:dMalloc0 fun:a_Png_new fun:Dicache_image fun:a_Dicache_png_image fun:a_Mime_set_viewer fun:a_Web_dispatch_by_type fun:Cache_process_queue } From akemnade at tzi.de Wed Feb 4 20:31:06 2009 From: akemnade at tzi.de (Andreas Kemnade) Date: Wed Feb 4 20:32:21 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090130172456.6e0c27ff@kemnade.info> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090130172456.6e0c27ff@kemnade.info> Message-ID: <20090204203106.6ab9e00a@kemnade.info> Hi, On Fri, 30 Jan 2009 17:24:56 +0100 Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 30 Jan 2009 12:22:46 -0300 > Jorge Arellano Cid wrote: > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > confirms that Mercurial itself is really fast and I've seen other > > > reports criticising FreeHG's performance. Perhaps we should think > > > about moving host? It's not always easy to find time to devote to > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > for a connection to the server. I'm committed enough to grit my teeth > > > and wait but I can see it putting off would-be contributors. > > > > > > Just a thought, > > > > Yes, I've also had trouble with it, and when normal it's slower > > than our Wearlab's CVS. > > > > A couple of days ago (while developoing/reviewing patches) I > > digged a bit on it and it seems that bitbucket is much faster. We > > can try bitbucket while we find a long term solution (e.g. FSF's > > savannah is offering Mercurial and Git repos, but the applying > > process may take some time). > > > > At some point in time we should move out from the Wearlab, as > > it may be closed soon. Currently we need webserver/CGI/python > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > we may use another bugtracker too. > > > The server which actually hosts the dillo debian and openmoko > packages should be an alternative. > At least performance and bandwidth should be no problem. Maybe moving > hg there is a starting point. > ok, try hg clone http://hg.dillo.org/dillo just add entries for hg.dillo.org in your /etc/hosts to point to that server. 85.214.105.140 hg.dillo.org or 2001:6f8:900:71b::2 hg.dillo.org push access (with ssl) is not set up yet. When it is done, of course the dns can be changed so that hg.dillo.org points to the right server. Greetings Andreas Kemnade -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20090204/e64b0d7a/signature.pgp From onepoint at starurchin.org Wed Feb 4 22:19:58 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Feb 4 22:20:34 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090204203106.6ab9e00a@kemnade.info> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090130172456.6e0c27ff@kemnade.info> <20090204203106.6ab9e00a@kemnade.info> Message-ID: <20090204211958.GA2934@omphalos.singularity> On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > ok, try hg clone http://hg.dillo.org/dillo Now *that* was nice and fast! Thanks! Jeremy Henty From jcid at dillo.org Thu Feb 5 11:36:58 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Feb 5 11:37:04 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090204203106.6ab9e00a@kemnade.info> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090130172456.6e0c27ff@kemnade.info> <20090204203106.6ab9e00a@kemnade.info> Message-ID: <20090205103658.GL9663@dillo.org> On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 30 Jan 2009 17:24:56 +0100 > Andreas Kemnade wrote: > > > Hi Jorge, > > > > On Fri, 30 Jan 2009 12:22:46 -0300 > > Jorge Arellano Cid wrote: > > > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > > confirms that Mercurial itself is really fast and I've seen other > > > > reports criticising FreeHG's performance. Perhaps we should think > > > > about moving host? It's not always easy to find time to devote to > > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > > for a connection to the server. I'm committed enough to grit my teeth > > > > and wait but I can see it putting off would-be contributors. > > > > > > > > Just a thought, > > > > > > Yes, I've also had trouble with it, and when normal it's slower > > > than our Wearlab's CVS. > > > > > > A couple of days ago (while developoing/reviewing patches) I > > > digged a bit on it and it seems that bitbucket is much faster. We > > > can try bitbucket while we find a long term solution (e.g. FSF's > > > savannah is offering Mercurial and Git repos, but the applying > > > process may take some time). > > > > > > At some point in time we should move out from the Wearlab, as > > > it may be closed soon. Currently we need webserver/CGI/python > > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > > we may use another bugtracker too. > > > > > The server which actually hosts the dillo debian and openmoko > > packages should be an alternative. > > At least performance and bandwidth should be no problem. Maybe moving > > hg there is a starting point. > > > ok, try > hg clone http://hg.dillo.org/dillo > > just add entries for hg.dillo.org in your /etc/hosts to point to that server. > 85.214.105.140 hg.dillo.org It works very well! > push access (with ssl) is not set up yet. > When it is done, of course the dns can be changed so that > hg.dillo.org points to the right server. Good. Just let me know when it's done. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Feb 5 12:14:43 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Feb 5 12:22:39 2009 Subject: [Dillo-dev] Re: view stylesheets from page menu In-Reply-To: <20090205111903.GP9663@dillo.org> References: <20090203171327.GK29275@local.gobigwest.com> <20090203190012.GA26798@blob.baaderstrasse.com> <20090205111903.GP9663@dillo.org> Message-ID: <20090205111443.GA1030@blob.baaderstrasse.com> On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 03, 2009 at 08:00:12PM +0100, Hofmann Johannes wrote: > > Hi corvid, > > > > On Tue, Feb 03, 2009 at 05:13:27PM +0000, corvid wrote: > > > > > > (a rough quick patch just to get feedback) > > > I saw that Jorge added cssUrls, which provided an opportunity... > > > > Very nice! Just one small thing. The stylesheets entry does not get > > disabled on non-CSS pages here. Extending the check like this: > > > > + if (cssUrls && cssUrls->size () > 0) { > > > > helps. > > To me: It looks more like a developers feature than one for user level. Well, not more than "View page source". I think it's important and in the spirit of dillo to make the web as transparent for the user as possible. > > > > BTW: Viewing stylesheets in a normal browser window is really fast > > compared to the fltk text viewer we use for "View page source"! > > Yes, since a long time I've wanted to find some time to turn > "View page source" into a dpi. > > Maybe after the close-tab button I can give it a hand. > Yes, that would be great. Cheers, Johannes > -- > Cheers > Jorge.- From dillo-dev at toykeeper.net Thu Feb 5 13:52:40 2009 From: dillo-dev at toykeeper.net (Scott Scriven) Date: Thu Feb 5 13:53:18 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090203134536.GI6099@omphalos.singularity> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> <20090203134536.GI6099@omphalos.singularity> Message-ID: <20090205125240.GA14190@mutt.xyzz.org> * Jeremy Henty wrote: > On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > > I doubt that setting up a savannah project would take very long. > Really? I just had a look and there's a long checklist. ... Did anyone ever look at launchpad? https://launchpad.net/+tour It's a "batteries included" type of project infrastructure host, feature-rich, easy, reliable, and free. It could provide hosting for almost everything the project needs and provide plenty of room to grow. The tour gives a pretty good overview... it may be a lot to absorb all at once, but it's worth a look. -- Scott From onepoint at starurchin.org Thu Feb 5 16:27:23 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu Feb 5 16:28:00 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090205125240.GA14190@mutt.xyzz.org> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> <20090203134536.GI6099@omphalos.singularity> <20090205125240.GA14190@mutt.xyzz.org> Message-ID: <20090205152723.GB2934@omphalos.singularity> On Thu, Feb 05, 2009 at 05:52:40AM -0700, Scott Scriven wrote: > Did anyone ever look at launchpad? > > https://launchpad.net/+tour > > It's a "batteries included" type of project infrastructure host, > feature-rich, easy, reliable, and free. It could provide hosting > for almost everything the project needs and provide plenty of > room to grow. Looks good, but I think Dillo would have to migrate away from Mercurial to use it. They use bzr, and although they integrate with some other VCSs, mercurial isn't one of them. Regards, Jeremy Henty From corvid at lavabit.com Thu Feb 5 16:48:56 2009 From: corvid at lavabit.com (corvid) Date: Thu Feb 5 16:50:59 2009 Subject: [Dillo-dev] Re: view stylesheets from page menu In-Reply-To: <20090205111443.GA1030@blob.baaderstrasse.com> References: <20090203171327.GK29275@local.gobigwest.com> <20090203190012.GA26798@blob.baaderstrasse.com> <20090205111903.GP9663@dillo.org> <20090205111443.GA1030@blob.baaderstrasse.com> Message-ID: <20090205154856.GP29275@local.gobigwest.com> Johannes wrote: > On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > > To me: It looks more like a developers feature than one for user level. > > Well, not more than "View page source". Yes, the same charge could be levelled against the bug meter. > I think it's important and in the spirit of dillo to make the web as > transparent for the user as possible. Well said. And part of my motivation was that I was thinking of extending what I have now so that I could examine the URLs before loading them. From onepoint at starurchin.org Thu Feb 5 20:55:46 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu Feb 5 20:56:21 2009 Subject: [Dillo-dev] [patch]: fix leak in a_Cookies_get_query() Message-ID: <20090205195546.GI2934@omphalos.singularity> This patch stops a_Cookies_get_query() leaking. However, I'm a little puzzled by the logic here. Why does a_Cookies_get_query() return a "Cookies2" header even if the cookies DPI returns nothing? Can't it just return NULL or an empty string? Wouldn't that be cleaner? Regards, Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1233819031 0 # Node ID 868d7c1182b79ed49a878b7f49a46a88d7ad8190 # Parent 742035273c87811d6dee77420cee2df68a0db12e imported patch fix-a_Cookies_get_query-leak diff --git a/src/cookies.c b/src/cookies.c --- a/src/cookies.c +++ b/src/cookies.c @@ -202,9 +202,11 @@ query = dStrdup("Cookie2: $Version=\"1\"\r\n"); if (dpip_tag != NULL) { + char *query2 = query; char *cookie = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cookie"); dFree(dpip_tag); - query = dStrconcat(query, cookie, NULL); + query = dStrconcat(query2, cookie, NULL); + dFree(query2); dFree(cookie); } return query; From corvid at lavabit.com Thu Feb 5 21:12:25 2009 From: corvid at lavabit.com (corvid) Date: Thu Feb 5 21:14:28 2009 Subject: [Dillo-dev] [patch]: fix leak in a_Cookies_get_query() In-Reply-To: <20090205195546.GI2934@omphalos.singularity> References: <20090205195546.GI2934@omphalos.singularity> Message-ID: <20090205201225.GR29275@local.gobigwest.com> Jeremy wrote: > This patch stops a_Cookies_get_query() leaking. However, I'm a little > puzzled by the logic here. Why does a_Cookies_get_query() return a > "Cookies2" header even if the cookies DPI returns nothing? Can't it > just return NULL or an empty string? Wouldn't that be cleaner? We return it if we are willing to accept cookies from the server. It indicates that dillo accepts the newer-style cookies. If we don't really want any cookies from them anyway, we return an empty string. From jorl17.8 at gmail.com Thu Feb 5 21:56:24 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Thu Feb 5 21:56:54 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <20090204133524.GH9663@dillo.org> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> Message-ID: <1233867384.6763.19.camel@jorl17-laptop> Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > Hello, > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Greetings. > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > it. > > > > > > > > Great. > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > I see some issues in your implementation. E.g. try to search for > > > > 'ab' in a string 'abababa'. > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > matches, but once it no longer does you would need to backtrack. > > > > The easiest but inefficient way to implement searching > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > algorithm avoids that. > > > > I think it would be best to adapt search0 somehow to allow backward > > > > searching - it's more or less the same thing as forward searching > > > > anyway. Some ugly edge cases when switching between forward and > > > > backward maybe :-) > > > > > > > > Thanks for working on that, > > > > Johannes > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > forwards? > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > compilable, but I might add some tests soon. > > > > > > > > > > Thanks, > > > > > > > > > > Jo?o > > > > > > Thanks for your answer. > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > got (provisory) working search0Backwards() replacement. How efficient do > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > you think there is a 'really' better way of searching backwards, than > > > reversing the word and searching backwards? As far as code-changes it > > > takes very few lines and I have a working example of it. However, the > > > extra reversing work might hit us hard. > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > to be rather small and we only need to reverse it once. > > The point is to avoid the backtracking. So that every letter in the > > text (haystack) is only visited once. > > If reversing the needle is all it takes, go ahead. > If the code is simple and it takes twice the time a forward > search, go ahead too. Backward search is much less used than > forward search and it's better to have it than not, and unless > the delay is annoying there's no compelling need to optimize. > > Thanks for the answer. OK, I think I worked it out, but the string is being reversed everytime we search backwards, to maintain compatibility with forward searching. Of course an alternative is to store it as private member, what do you think? I couldn't find any function for reversing a C-String in dillo's code, so I put my own as a static member in FindtextState, should I move it elsewhere? I tested multiple cases and it seems (to me) that this one is bugless, maybe you'll find a nasty/dirty bug I caused, but time will tell :) Also, the reverse string function was the only one added, all the rest was only altered. Thanks for the support, Jo?o From jorl17.8 at gmail.com Thu Feb 5 23:04:32 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Thu Feb 5 23:04:45 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <1233867384.6763.19.camel@jorl17-laptop> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> <1233867384.6763.19.camel@jorl17-laptop> Message-ID: <1233871472.6763.28.camel@jorl17-laptop> Qui, 2009-02-05 ?s 20:56 +0000, Jo?o Ricardo Louren?o escreveu: > Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > > Hello, > > > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > Greetings. > > > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > > it. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > > I see some issues in your implementation. E.g. try to search for > > > > > 'ab' in a string 'abababa'. > > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > > matches, but once it no longer does you would need to backtrack. > > > > > The easiest but inefficient way to implement searching > > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > > algorithm avoids that. > > > > > I think it would be best to adapt search0 somehow to allow backward > > > > > searching - it's more or less the same thing as forward searching > > > > > anyway. Some ugly edge cases when switching between forward and > > > > > backward maybe :-) > > > > > > > > > > Thanks for working on that, > > > > > Johannes > > > > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > > forwards? > > > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > > compilable, but I might add some tests soon. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jo?o > > > > > > > > Thanks for your answer. > > > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > > got (provisory) working search0Backwards() replacement. How efficient do > > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > > you think there is a 'really' better way of searching backwards, than > > > > reversing the word and searching backwards? As far as code-changes it > > > > takes very few lines and I have a working example of it. However, the > > > > extra reversing work might hit us hard. > > > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > > to be rather small and we only need to reverse it once. > > > The point is to avoid the backtracking. So that every letter in the > > > text (haystack) is only visited once. > > > > If reversing the needle is all it takes, go ahead. > > If the code is simple and it takes twice the time a forward > > search, go ahead too. Backward search is much less used than > > forward search and it's better to have it than not, and unless > > the delay is annoying there's no compelling need to optimize. > > > > > > Thanks for the answer. > > OK, I think I worked it out, but the string is being reversed everytime > we search backwards, to maintain compatibility with forward searching. > Of course an alternative is to store it as private member, what do you > think? > > I couldn't find any function for reversing a C-String in dillo's code, > so I put my own as a static member in FindtextState, should I move it > elsewhere? > > I tested multiple cases and it seems (to me) that this one is bugless, > maybe you'll find a nasty/dirty bug I caused, but time will tell :) > > Also, the reverse string function was the only one added, all the rest > was only altered. > > Thanks for the support, > > Jo?o (Apart from the fact I didn't attach any patch...) Scratch that, my bad, that patch contained various bugs. The first kind of bug related to a typo which I now fixed. The second kind because of me interpreting code the wrong way and the third one because of the particular case of searching for things either at the beggining or at the end of the page. I think I fixed all of them and have an updated patch, excuse me for my previous mistakes... Jo?o -------------- next part -------------- A non-text attachment was scrubbed... Name: find-backwards.diff Type: text/x-patch Size: 11365 bytes Desc: not available Url : /pipermail/attachments/20090205/41ac5673/find-backwards-0001.bin From dillo-dev at toykeeper.net Thu Feb 5 23:10:20 2009 From: dillo-dev at toykeeper.net (Scott Scriven) Date: Thu Feb 5 23:10:30 2009 Subject: [Dillo-dev] FreeHG performance In-Reply-To: <20090205152723.GB2934@omphalos.singularity> References: <20090130132147.GF2972@omphalos.singularity> <20090130152246.GS5972@dillo.org> <20090203124748.GC2126@blob.baaderstrasse.com> <20090203134536.GI6099@omphalos.singularity> <20090205125240.GA14190@mutt.xyzz.org> <20090205152723.GB2934@omphalos.singularity> Message-ID: <20090205221020.GA16501@mutt.xyzz.org> * Jeremy Henty wrote: > Looks good, but I think Dillo would have to migrate > away from Mercurial to use it. After using hg for the past couple years and bzr for about a year, I've found bzr to be an upgrade. I still use both on a regular basis, but no longer choose hg for any new projects. The main differences to be aware of are: - Branches are directories instead of labels. Each directory has only one "head", and you switch between branches with "cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix". - There are a lot of plugins available to extend functionality in various ways. A couple I recommend are bzr-gtk ("bzr vis" is a nice way to browse history) and bzr-bisect (helps isolate where bugs were introduced). - It has a concept of a main line of development, and meaningful version numbers. Merges are always explicit, even when hg would merge in-line. This makes feature branches more useful. That last one probably requires a little more explanation. Say you branch from trunk at r100 to add a feature. It requires some major changes, so you break everything while refactoring and spend a few revisions getting it all working again. It takes 10 revisions total. So, you send the changes upstream. They like it. They merge it... And nobody else checked anything in while you were working. Now (in hg) trunk is at r110, with your new feature. And the revision graph ends up being a straight line, so there's no evidence a merge occurred. If anyone tries to use r101 through r109, they'll find that it's all broken. The way bzr handles it is you submit 10 revisions, and when merged, trunk bumps up to r101. The revision graph shows a branch off to the side with 10 changes (r100.1.1 through r100.1.10) and a merge at the end (r101), and the trunk contains only non-broken versions. It makes more sense to me. > They use bzr, and although they integrate with some other > VCSs, mercurial isn't one of them. It's a one-time conversion, instead of the two-way conduit they support for subversion. I tried it just now (using bzr-fastimport) and it worked. The new branch is in my "junk" folder (launchpad equivalent of /tmp/) if anyone wants to try it: bzr branch lp:~toykeeper/+junk/dillo Personally, the main thing I find annoying about bzr is that it's not the easiest thing to type. I use "alias b=bzr" in my shell to fix that. -- Scott From onepoint at starurchin.org Fri Feb 6 00:01:57 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Fri Feb 6 00:03:11 2009 Subject: [Dillo-dev] [patch]: fix leak in a_Cookies_get_query() In-Reply-To: <20090205201225.GR29275@local.gobigwest.com> References: <20090205195546.GI2934@omphalos.singularity> <20090205201225.GR29275@local.gobigwest.com> Message-ID: <20090205230157.GA13091@omphalos.singularity> On Thu, Feb 05, 2009 at 08:12:25PM +0000, corvid wrote: > Jeremy wrote: > > Why does a_Cookies_get_query() return a "Cookies2" header even if > > the cookies DPI returns nothing? [...] > > We return it if we are willing to accept cookies from the server. It > indicates that dillo accepts the newer-style cookies. If we don't > really want any cookies from them anyway, we return an empty string. OK, thanks for the explanation. Jeremy Henty From CHalbersma.12 at westminster-mo.edu Fri Feb 6 03:27:30 2009 From: CHalbersma.12 at westminster-mo.edu (Halbersma, Christopher) Date: Fri Feb 6 03:28:39 2009 Subject: [Dillo-dev] RE: Free HG performance Message-ID: <3AD6C1FCD7174047906F87077662D402EA2AC9AB3F@mail1.westminster-mo.edu> Souceforge always seemed pretty good at hosting open souce projects. Of course I could be wrong there. Christopher "Chewy" R. Halbersma From dillo-dev at toykeeper.net Fri Feb 6 06:20:17 2009 From: dillo-dev at toykeeper.net (Scott Scriven) Date: Fri Feb 6 06:20:56 2009 Subject: [Dillo-dev] RE: Free HG performance In-Reply-To: <3AD6C1FCD7174047906F87077662D402EA2AC9AB3F@mail1.westminster-mo.edu> References: <3AD6C1FCD7174047906F87077662D402EA2AC9AB3F@mail1.westminster-mo.edu> Message-ID: <20090206052017.GB16501@mutt.xyzz.org> * Halbersma, Christopher wrote: > Souceforge always seemed pretty good at hosting open souce > projects. Of course I could be wrong there. It used to be The Place for hosting open projects, years ago... but its service and policies have been slowly declining while better alternatives popped up. The other services I've seen mentioned so far are FreeHG, BitBucket, Savannah, and Launchpad. FreeHG hosts Mercurial branches. It sounds like it's not reliable though, and doesn't really do anything else. BitBucket provides Mercurial hosting, bug tracking, and a wiki. I haven't found more than a summary about it. Savannah was born from an old open-source version of SourceForge. It is similar but has better code hosting options (including hg and git). It currently hosts 3022 projects, 60739 users, and 25504 bugs. Launchpad is an original project management service from Canonical, and offers relatively unique options (see the tour for details). It currently hosts 10141 projects, 2560014 users, 4310 teams, 323833 bugs, 24561 branches, 1117574 translations, 59871 answers, and 14499 blueprints. This is an exciting time for community software development... the past couple years have been a very creative time full of new ideas about how to collaborate, and it looks like things are only accelerating from here. Although it can be hard to decide which emerging systems to use, I'm happy to have no lack of options. :) -- Scott From corvid at lavabit.com Fri Feb 6 07:22:54 2009 From: corvid at lavabit.com (corvid) Date: Fri Feb 6 07:25:01 2009 Subject: [Dillo-dev] name/id bug Message-ID: <20090206062254.GS29275@local.gobigwest.com>

gives HTML warning: line 2, 'id' and 'name' attribute of tag differ HTML warning: line 4, Anchor names must be unique within the document Dillo would seem to be unhappy now that the id attr is checked before open_a checks the name attr -- but then it looks like the move was made in October (a88b4a31cb7a) and I have a dillo around from roughly Dec. 22 that does not have a problem with this. In any case, I don't know whether there are styleEngine issues with just sticking the id check back after the open. From Johannes.Hofmann at gmx.de Fri Feb 6 10:58:37 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Feb 6 11:06:34 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206062254.GS29275@local.gobigwest.com> References: <20090206062254.GS29275@local.gobigwest.com> Message-ID: <20090206095837.GA4925@blob.baaderstrasse.com> On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > >

>

> > > gives > HTML warning: line 2, 'id' and 'name' attribute of tag differ > HTML warning: line 4, Anchor names must be unique within the document > > Dillo would seem to be unhappy now that the id attr is checked before > open_a checks the name attr -- but then it looks like the move was > made in October (a88b4a31cb7a) and I have a dillo around from > roughly Dec. 22 that does not have a problem with this. Yes, the problem was caused by moving the check. > > In any case, I don't know whether there are styleEngine issues with > just sticking the id check back after the open. We need to parse the "id" attribute before the open, as it's used to determine the style used in open*. But I don't understand the reason for the name/id check in the first place: foo bar foo bar is correct HTML according to http://validator.w3.org/. I would propose to remove this check completely. Opinions? Cheers, Johannes From Johannes.Hofmann at gmx.de Fri Feb 6 11:06:11 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Feb 6 11:14:07 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206095837.GA4925@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> Message-ID: <20090206100611.GA5037@blob.baaderstrasse.com> On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > >

> >

> > > > > > gives > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > HTML warning: line 4, Anchor names must be unique within the document > > > > Dillo would seem to be unhappy now that the id attr is checked before > > open_a checks the name attr -- but then it looks like the move was > > made in October (a88b4a31cb7a) and I have a dillo around from > > roughly Dec. 22 that does not have a problem with this. > > Yes, the problem was caused by moving the check. > > > > > In any case, I don't know whether there are styleEngine issues with > > just sticking the id check back after the open. > > We need to parse the "id" attribute before the open, as it's used to > determine the style used in open*. > > But I don't understand the reason for the name/id check in the first > place: > > > > foo bar > > foo bar > > > > is correct HTML according to http://validator.w3.org/. > I would propose to remove this check completely. Opinions? Ooops, stop! I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 It seems that name and id must be equal and it's a bug in http://validator.w3.org/ that it doesn't catch it. I will try to fix the check in dillo. Cheers, Johannes From Johannes.Hofmann at gmx.de Fri Feb 6 12:38:20 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Feb 6 12:46:18 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206100611.GA5037@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> Message-ID: <20090206113820.GA98817@blob.baaderstrasse.com> On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > >

> > >

> > > > > > > > > gives > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > open_a checks the name attr -- but then it looks like the move was > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > roughly Dec. 22 that does not have a problem with this. > > > > Yes, the problem was caused by moving the check. > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > just sticking the id check back after the open. > > > > We need to parse the "id" attribute before the open, as it's used to > > determine the style used in open*. > > > > But I don't understand the reason for the name/id check in the first > > place: > > > > > > > > foo bar > > > > foo bar > > > > > > > > is correct HTML according to http://validator.w3.org/. > > I would propose to remove this check completely. Opinions? > > Ooops, stop! > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > It seems that name and id must be equal and it's a bug in > http://validator.w3.org/ that it doesn't catch it. > I will try to fix the check in dillo. Please test/review current tip Cheers, Johannes From jcid at dillo.org Fri Feb 6 14:44:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 14:44:22 2009 Subject: [Dillo-dev] Re: view stylesheets from page menu In-Reply-To: <20090205154856.GP29275@local.gobigwest.com> References: <20090203171327.GK29275@local.gobigwest.com> <20090203190012.GA26798@blob.baaderstrasse.com> <20090205111903.GP9663@dillo.org> <20090205111443.GA1030@blob.baaderstrasse.com> <20090205154856.GP29275@local.gobigwest.com> Message-ID: <20090206134422.GA5991@dillo.org> On Thu, Feb 05, 2009 at 03:48:56PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > > > To me: It looks more like a developers feature than one for user level. > > > > Well, not more than "View page source". > > Yes, the same charge could be levelled against the bug meter. > > > I think it's important and in the spirit of dillo to make the web as > > transparent for the user as possible. > > Well said. > > And part of my motivation was that I was thinking of extending what > I have now so that I could examine the URLs before loading them. No problem at all. I just don't want to clutter menus very much. BTW a simple preference in the same way as the button panel solves it, if necessary. corvid: please clean it up, and bundle "Load images" after a menu separator after the CSS section of the tools menu. The "load on/off" icon at the bottom should dissappear then. -- Cheers Jorge.- From jcid at dillo.org Fri Feb 6 15:06:46 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 15:06:49 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206100611.GA5037@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> Message-ID: <20090206140646.GB5991@dillo.org> On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > >

> > >

> > > > > > > > > gives > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > open_a checks the name attr -- but then it looks like the move was > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > roughly Dec. 22 that does not have a problem with this. > > > > Yes, the problem was caused by moving the check. > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > just sticking the id check back after the open. > > > > We need to parse the "id" attribute before the open, as it's used to > > determine the style used in open*. > > > > But I don't understand the reason for the name/id check in the first > > place: > > > > > > > > foo bar > > > > foo bar > > > > > > > > is correct HTML according to http://validator.w3.org/. > > I would propose to remove this check completely. Opinions? > > Ooops, stop! > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > It seems that name and id must be equal and it's a bug in > http://validator.w3.org/ that it doesn't catch it. > I will try to fix the check in dillo. Yeah, please give it a hand. Dillo is broken on this check, e.g.: http://www.validome.org/lang/en/ Dillo counts one bug: "HTML warning: line 30, Anchor names must be unique within the document" but line 30 is OK: "" -- Cheers Jorge.- From jcid at dillo.org Fri Feb 6 15:18:05 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 15:18:09 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206140646.GB5991@dillo.org> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206140646.GB5991@dillo.org> Message-ID: <20090206141805.GC5991@dillo.org> On Fri, Feb 06, 2009 at 11:06:46AM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > >

> > > >

> > > > > > > > > > > > gives > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > open_a checks the name attr -- but then it looks like the move was > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > just sticking the id check back after the open. > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > determine the style used in open*. > > > > > > But I don't understand the reason for the name/id check in the first > > > place: > > > > > > > > > > > > foo bar > > > > > > foo bar > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > I would propose to remove this check completely. Opinions? > > > > Ooops, stop! > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > It seems that name and id must be equal and it's a bug in > > http://validator.w3.org/ that it doesn't catch it. > > I will try to fix the check in dillo. > > Yeah, please give it a hand. Dillo is broken on this check, > e.g.: > > http://www.validome.org/lang/en/ > > Dillo counts one bug: > > "HTML warning: line 30, Anchor names must be unique within the document" > > but line 30 is OK: > > "" BTW, current tip works right with this page. -- Cheers Jorge.- From jcid at dillo.org Fri Feb 6 15:59:01 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 15:59:09 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206113820.GA98817@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> Message-ID: <20090206145901.GD5991@dillo.org> On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > >

> > > >

> > > > > > > > > > > > gives > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > open_a checks the name attr -- but then it looks like the move was > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > just sticking the id check back after the open. > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > determine the style used in open*. > > > > > > But I don't understand the reason for the name/id check in the first > > > place: > > > > > > > > > > > > foo bar > > > > > > foo bar > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > I would propose to remove this check completely. Opinions? > > > > Ooops, stop! > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > It seems that name and id must be equal and it's a bug in > > http://validator.w3.org/ that it doesn't catch it. > > I will try to fix the check in dillo. > > Please test/review current tip After a quick review, it seems to me that the proper solution is to add a test in the open function for A, APPLET, FORM, FRAME, IFRAME, IMG and MAP. Something like: if (id && nameVal && strcmp(nameVal, id)) BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); if (nameVal) Html_add_anchor(html, nameVal); -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Feb 6 16:01:58 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Feb 6 16:09:54 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206145901.GD5991@dillo.org> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> <20090206145901.GD5991@dillo.org> Message-ID: <20090206150158.GA877@blob.baaderstrasse.com> On Fri, Feb 06, 2009 at 11:59:01AM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > > > >

> > > > >

> > > > > > > > > > > > > > > gives > > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > > open_a checks the name attr -- but then it looks like the move was > > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > > just sticking the id check back after the open. > > > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > > determine the style used in open*. > > > > > > > > But I don't understand the reason for the name/id check in the first > > > > place: > > > > > > > > > > > > > > > > foo bar > > > > > > > > foo bar > > > > > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > > I would propose to remove this check completely. Opinions? > > > > > > Ooops, stop! > > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > > It seems that name and id must be equal and it's a bug in > > > http://validator.w3.org/ that it doesn't catch it. > > > I will try to fix the check in dillo. > > > > Please test/review current tip > > After a quick review, it seems to me that the proper solution > is to add a test in the open function for A, APPLET, FORM, FRAME, > IFRAME, IMG and MAP. Something like: > > if (id && nameVal && strcmp(nameVal, id)) > BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); > if (nameVal) > Html_add_anchor(html, nameVal); If id and nameVal don't differ, we don't want to call Html_add_anchor(). It has already been called with the same value from Html_parse_common_attrs(). We could put the corresponding code that is currently in Html_tag_open_a() in a new function Html_handle_name_attr() and call that from all elements that allow a "name" attribute. Cheers, Johannes From jcid at dillo.org Fri Feb 6 16:29:37 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 17:27:41 2009 Subject: [Dillo-dev] [patch]: fix leak in a_Cookies_get_query() In-Reply-To: <20090205195546.GI2934@omphalos.singularity> References: <20090205195546.GI2934@omphalos.singularity> Message-ID: <20090206152937.GF5991@dillo.org> On Thu, Feb 05, 2009 at 07:55:46PM +0000, Jeremy Henty wrote: > > This patch stops a_Cookies_get_query() leaking. Committed. -- Cheers Jorge.- From jcid at dillo.org Fri Feb 6 17:34:24 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 17:34:26 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206150158.GA877@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> <20090206145901.GD5991@dillo.org> <20090206150158.GA877@blob.baaderstrasse.com> Message-ID: <20090206163424.GG5991@dillo.org> On Fri, Feb 06, 2009 at 04:01:58PM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 11:59:01AM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > > > > > >

> > > > > >

> > > > > > > > > > > > > > > > > > gives > > > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > > > open_a checks the name attr -- but then it looks like the move was > > > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > > > just sticking the id check back after the open. > > > > > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > > > determine the style used in open*. > > > > > > > > > > But I don't understand the reason for the name/id check in the first > > > > > place: > > > > > > > > > > > > > > > > > > > > foo bar > > > > > > > > > > foo bar > > > > > > > > > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > > > I would propose to remove this check completely. Opinions? > > > > > > > > Ooops, stop! > > > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > > > It seems that name and id must be equal and it's a bug in > > > > http://validator.w3.org/ that it doesn't catch it. > > > > I will try to fix the check in dillo. > > > > > > Please test/review current tip > > > > After a quick review, it seems to me that the proper solution > > is to add a test in the open function for A, APPLET, FORM, FRAME, > > IFRAME, IMG and MAP. Something like: > > > > if (id && nameVal && strcmp(nameVal, id)) > > BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); > > if (nameVal) > > Html_add_anchor(html, nameVal); > > If id and nameVal don't differ, we don't want to call > Html_add_anchor(). It has already been called with the same value > from Html_parse_common_attrs(). > > We could put the corresponding code that is currently in > Html_tag_open_a() in a new function Html_handle_name_attr() and call > that from all elements that allow a "name" attribute. Right, that's the idea. Maybe: if (id && strcmp(nameVal, id) == 0) { BUG_MSG("'id' and 'name' attribute of tag differ\n"); } else { Html_add_anchor(html, nameVal); } -- Cheers Jorge.- From jcid at dillo.org Fri Feb 6 17:38:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 17:38:42 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206150158.GA877@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> <20090206145901.GD5991@dillo.org> <20090206150158.GA877@blob.baaderstrasse.com> Message-ID: <20090206163835.GH5991@dillo.org> On Fri, Feb 06, 2009 at 04:01:58PM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 11:59:01AM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > > > > > >

> > > > > >

> > > > > > > > > > > > > > > > > > gives > > > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > > > open_a checks the name attr -- but then it looks like the move was > > > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > > > just sticking the id check back after the open. > > > > > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > > > determine the style used in open*. > > > > > > > > > > But I don't understand the reason for the name/id check in the first > > > > > place: > > > > > > > > > > > > > > > > > > > > foo bar > > > > > > > > > > foo bar > > > > > > > > > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > > > I would propose to remove this check completely. Opinions? > > > > > > > > Ooops, stop! > > > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > > > It seems that name and id must be equal and it's a bug in > > > > http://validator.w3.org/ that it doesn't catch it. > > > > I will try to fix the check in dillo. > > > > > > Please test/review current tip > > > > After a quick review, it seems to me that the proper solution > > is to add a test in the open function for A, APPLET, FORM, FRAME, > > IFRAME, IMG and MAP. Something like: > > > > if (id && nameVal && strcmp(nameVal, id)) > > BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); > > if (nameVal) > > Html_add_anchor(html, nameVal); > > If id and nameVal don't differ, we don't want to call > Html_add_anchor(). It has already been called with the same value > from Html_parse_common_attrs(). > > We could put the corresponding code that is currently in > Html_tag_open_a() in a new function Html_handle_name_attr() and call > that from all elements that allow a "name" attribute. BTW, http://www.validome.org/lang/ge/errors/MISC/3005 says that they must be equal for the above mentioned elements only. I don't know what's the rule for other elements with "name" attr. though. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Feb 6 17:38:44 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Fri Feb 6 17:46:41 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206163424.GG5991@dillo.org> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> <20090206145901.GD5991@dillo.org> <20090206150158.GA877@blob.baaderstrasse.com> <20090206163424.GG5991@dillo.org> Message-ID: <20090206163844.GA2812@blob.baaderstrasse.com> On Fri, Feb 06, 2009 at 01:34:24PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 06, 2009 at 04:01:58PM +0100, Hofmann Johannes wrote: > > On Fri, Feb 06, 2009 at 11:59:01AM -0300, Jorge Arellano Cid wrote: > > > On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > > > > > > > >

> > > > > > >

> > > > > > > > > > > > > > > > > > > > > gives > > > > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > > > > open_a checks the name attr -- but then it looks like the move was > > > > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > > > > just sticking the id check back after the open. > > > > > > > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > > > > determine the style used in open*. > > > > > > > > > > > > But I don't understand the reason for the name/id check in the first > > > > > > place: > > > > > > > > > > > > > > > > > > > > > > > > foo bar > > > > > > > > > > > > foo bar > > > > > > > > > > > > > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > > > > I would propose to remove this check completely. Opinions? > > > > > > > > > > Ooops, stop! > > > > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > > > > It seems that name and id must be equal and it's a bug in > > > > > http://validator.w3.org/ that it doesn't catch it. > > > > > I will try to fix the check in dillo. > > > > > > > > Please test/review current tip > > > > > > After a quick review, it seems to me that the proper solution > > > is to add a test in the open function for A, APPLET, FORM, FRAME, > > > IFRAME, IMG and MAP. Something like: > > > > > > if (id && nameVal && strcmp(nameVal, id)) > > > BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); > > > if (nameVal) > > > Html_add_anchor(html, nameVal); > > > > If id and nameVal don't differ, we don't want to call > > Html_add_anchor(). It has already been called with the same value > > from Html_parse_common_attrs(). > > > > We could put the corresponding code that is currently in > > Html_tag_open_a() in a new function Html_handle_name_attr() and call > > that from all elements that allow a "name" attribute. > > Right, that's the idea. > Maybe: > > if (id && strcmp(nameVal, id) == 0) { > BUG_MSG("'id' and 'name' attribute of tag differ\n"); > } else { > Html_add_anchor(html, nameVal); > } That's not quite it. I think the original test, that I now moved to Html_tag_open_a() is ok: if (!id || strcmp(nameVal, id)) { if (id) BUG_MSG("'id' and 'name' attribute of tag differ\n"); Html_add_anchor(html, nameVal); } I.e. do something if id is not set or id and name differ. Then if they differ output a warning. Add an anchor for the new string. Cheers, Johannes From jcid at dillo.org Fri Feb 6 21:56:28 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Feb 6 21:56:31 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <1233535038.18551.2.camel@jorl17-laptop> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> Message-ID: <20090206205628.GJ5991@dillo.org> On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > > Greetings to all. > > > > > > As a simple introduction may I say I thank you all for your work on > > > Dillo. > > > > > > Currently, I am trying to implement the Close-Tab button. I've been > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > > dillo-dev. > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > > and the idea was to have a button at the end of the tabs list. > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > > this widget at the end of the tabs list and, then, I add() it to the > > > CustTabGroup's parent() (UI). > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > > such a way that it doesn't resize the button itself, but only moves it. > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > > handle() method of the CustTabGroup. > > > > > > Just a second ago I solved one of the problems, which was the fact that > > > tab_height() returned 0 in the constructor and resize() didn't work. I > > > worked around that by constructing the button only in event() if > > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > > the correct height for the button. > > > > > > It may not seem reliable to do so many things in handle(). Any > > > suggestions? > > > > We need to get something working, review it, and then we may > > ask in fltk.general whether it could have side effects. > > > > > It is functional, only you can say if it fully suits Dillo's needs > > > though. > > > > Please post the patch here so we can look at it. > > > > > Unfortunately, there are some problems: > > > > > > The first one is the most-relevant one. When the list of tabs grows it > > > can go over the button. I have been trying to fix this, but I can't seem > > > to do it. > > > A possible way could (maybe) be to 'trick' the pager into thinking it > > > has less space left to draw the tabs, and that could possibly be > > > achieved using update_positions(), although I am having some problems > > > with that. > > > > Or maybe just tweaking the value. After all it's a workaround. > > > > > The second problem is a minor one, but annoying. I believe when CSS > > > rendering is triggered, the render area flickers and that is normal. > > > However, the way I implemented this (probably because of it being in > > > handle()) makes the Button also flash. > > > > A side affect of being a child of UI. > > > > So, as requested, here is what I have got until now. There is a > particular line I think is not necessary, I commented that specifically. I'm reviewing it now. -- Cheers Jorge.- From corvid at lavabit.com Sat Feb 7 06:01:12 2009 From: corvid at lavabit.com (corvid) Date: Sat Feb 7 06:03:19 2009 Subject: [Dillo-dev] patch: line appearance Message-ID: <20090207050112.GA7682@local.gobigwest.com> I was thinking that large text with a thin line through it looks odd. Turns out that there was also a problem with causing the line to be too high. This looks about right to me with the few fonts I have around. I'm attaching an example html file as well. PS Might be good to go through that area of the code one day to see what opportunities there are to make it clearer... -------------- next part -------------- diff -r b96171419f45 dw/textblock.cc --- a/dw/textblock.cc Fri Feb 06 17:58:24 2009 +0000 +++ b/dw/textblock.cc Sat Feb 07 03:57:18 2009 +0000 @@ -1299,20 +1299,24 @@ void Textblock::drawLine (Line *line, co /* strike-through */ if (word->style->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH) - view->drawLine (color, core::style::Color::SHADING_NORMAL, - xWorld, - yWorldBase - word->size.ascent / 2 + diff, - xWorld + word->size.width - 1, - yWorldBase - word->size.ascent / 2 + diff); + view->drawRectangle (color, core::style::Color::SHADING_NORMAL, + true, xWorld, + yWorldBase + + (diff + word->size.descent - word->size.ascent)/2, + word->size.width, + 1 + (word->size.ascent + word->size.descent - + abs(diff)) / 18); if (wordIndex + 1 < line->lastWord && (word->spaceStyle->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH)) - view->drawLine (word->spaceStyle->color, + view->drawRectangle (word->spaceStyle->color, core::style::Color::SHADING_NORMAL, - xWorld + word->size.width, - yWorldBase - word->size.ascent / 2 + diff, - xWorld + word->size.width + word->effSpace - 1, - yWorldBase - word->size.ascent / 2 + diff); + true, xWorld + word->size.width, + yWorldBase + + (diff + word->size.descent - word->size.ascent)/2, + word->effSpace, + 1 + (word->size.ascent + word->size.descent - + abs(diff)) / 18); for (layer = 0; layer < core::HIGHLIGHT_NUM_LAYERS; layer++) { if (hlStart[layer].index <= wordIndex && @@ -1373,13 +1377,14 @@ void Textblock::drawLine (Line *line, co yWorldBase + 1 + diff); if (word->style->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH) - view->drawLine (color, + view->drawRectangle (color, core::style::Color::SHADING_INVERSE, - startHL, - yWorldBase - word->size.ascent / 2 + diff, - startHL + widthHL - 1, - yWorldBase - word->size.ascent / 2 - + diff); + true, startHL, + yWorldBase + (diff + word->size.descent - + word->size.ascent) / 2, + widthHL, + 1 + (word->size.ascent + + word->size.descent - abs(diff)) /18); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20090207/41d8de70/linethrough.html From Johannes.Hofmann at gmx.de Sat Feb 7 15:32:46 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Feb 7 15:41:08 2009 Subject: [Dillo-dev] patch: line appearance In-Reply-To: <20090207050112.GA7682@local.gobigwest.com> References: <20090207050112.GA7682@local.gobigwest.com> Message-ID: <20090207143246.GA1414@blob.baaderstrasse.com> On Sat, Feb 07, 2009 at 05:01:12AM +0000, corvid wrote: > I was thinking that large text with a thin line through it > looks odd. > Turns out that there was also a problem with causing the > line to be too high. > > This looks about right to me with the few fonts I have around. Maybe one could determine the line width based on the xHeight member of the font? Just an idea. Cheers, Johannes From corvid at lavabit.com Sat Feb 7 16:57:13 2009 From: corvid at lavabit.com (corvid) Date: Sat Feb 7 16:59:17 2009 Subject: [Dillo-dev] patch: line appearance In-Reply-To: <20090207143246.GA1414@blob.baaderstrasse.com> References: <20090207050112.GA7682@local.gobigwest.com> <20090207143246.GA1414@blob.baaderstrasse.com> Message-ID: <20090207155713.GA8385@local.gobigwest.com> Johannes wrote: > On Sat, Feb 07, 2009 at 05:01:12AM +0000, corvid wrote: > > I was thinking that large text with a thin line through it > > looks odd. > > Turns out that there was also a problem with causing the > > line to be too high. > > > > This looks about right to me with the few fonts I have around. > > Maybe one could determine the line width based on the xHeight member > of the font? Just an idea. Ah, good. 'diff' was sort of compensating for what sup and sub do to ascent and descent, but imperfectly -- as you probably noticed. Here's a new patch. -------------- next part -------------- diff -r b96171419f45 dw/textblock.cc --- a/dw/textblock.cc Fri Feb 06 17:58:24 2009 +0000 +++ b/dw/textblock.cc Sat Feb 07 15:47:25 2009 +0000 @@ -1299,20 +1299,22 @@ void Textblock::drawLine (Line *line, co /* strike-through */ if (word->style->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH) - view->drawLine (color, core::style::Color::SHADING_NORMAL, - xWorld, - yWorldBase - word->size.ascent / 2 + diff, - xWorld + word->size.width - 1, - yWorldBase - word->size.ascent / 2 + diff); + view->drawRectangle (color, core::style::Color::SHADING_NORMAL, + true, xWorld, + yWorldBase + + (diff + word->size.descent - word->size.ascent)/2, + word->size.width, + 1 + word->style->font->xHeight / 10); if (wordIndex + 1 < line->lastWord && (word->spaceStyle->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH)) - view->drawLine (word->spaceStyle->color, + view->drawRectangle (word->spaceStyle->color, core::style::Color::SHADING_NORMAL, - xWorld + word->size.width, - yWorldBase - word->size.ascent / 2 + diff, - xWorld + word->size.width + word->effSpace - 1, - yWorldBase - word->size.ascent / 2 + diff); + true, xWorld + word->size.width, + yWorldBase + + (diff + word->size.descent - word->size.ascent)/2, + word->effSpace, + 1 + word->style->font->xHeight / 10); for (layer = 0; layer < core::HIGHLIGHT_NUM_LAYERS; layer++) { if (hlStart[layer].index <= wordIndex && @@ -1373,13 +1375,13 @@ void Textblock::drawLine (Line *line, co yWorldBase + 1 + diff); if (word->style->textDecoration & core::style::TEXT_DECORATION_LINE_THROUGH) - view->drawLine (color, + view->drawRectangle (color, core::style::Color::SHADING_INVERSE, - startHL, - yWorldBase - word->size.ascent / 2 + diff, - startHL + widthHL - 1, - yWorldBase - word->size.ascent / 2 - + diff); + true, startHL, + yWorldBase + (diff + word->size.descent - + word->size.ascent) / 2, + widthHL, + 1 + word->style->font->xHeight / 10); } } } From onepoint at starurchin.org Sat Feb 7 18:57:21 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Feb 7 18:57:59 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image Message-ID: <20090207175721.GG32473@omphalos.singularity> There is IMHO a nasty code smell around a_Html_add_new_image(): it takes a boolean parameter that determines whether or not it actually adds the image. It's only called from two other places, once with the parameter set to false and once with it set to true. This patch cleans things up by renaming a_Html_add_new_image() to a_Html_image_new(), removing the boolean parameter and making the caller add the image (or not) as appropriate. Perhaps it is a judgement call as to whether this is an improvement, but I feel that it is. Please comment. Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Sat Feb 7 19:55:25 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sat Feb 7 20:03:30 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207175721.GG32473@omphalos.singularity> References: <20090207175721.GG32473@omphalos.singularity> Message-ID: <20090207185525.GA10066@blob.baaderstrasse.com> On Sat, Feb 07, 2009 at 05:57:21PM +0000, Jeremy Henty wrote: > > There is IMHO a nasty code smell around a_Html_add_new_image(): it > takes a boolean parameter that determines whether or not it actually > adds the image. It's only called from two other places, once with the > parameter set to false and once with it set to true. > > This patch cleans things up by renaming a_Html_add_new_image() to > a_Html_image_new(), removing the boolean parameter and making the > caller add the image (or not) as appropriate. > > Perhaps it is a judgement call as to whether this is an improvement, > but I feel that it is. Please comment. did you forget to attach the patch? Cheers, Johannes From onepoint at starurchin.org Sat Feb 7 20:15:19 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Feb 7 20:16:08 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207175721.GG32473@omphalos.singularity> References: <20090207175721.GG32473@omphalos.singularity> Message-ID: <20090207191519.GH32473@omphalos.singularity> D'oh! Patch attached. Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1234012049 0 # Node ID c0296f31e1b3e964bac2e9d9e4553c730e4b31b5 # Parent e766286e0884ec7326bb508304c5371cecdefb8e imported patch mod-a_Html_add_new_image diff --git a/src/form.cc b/src/form.cc --- a/src/form.cc +++ b/src/form.cc @@ -1911,7 +1911,7 @@ html->styleEngine->setPseudoLink (); /* create new image and add it to the button */ - if ((Image = a_Html_add_new_image(html, tag, tagsize, url, false))) { + if ((Image = a_Html_image_new(html, tag, tagsize, url))) { IM2DW(Image)->setStyle (html->styleEngine->style ()); ResourceFactory *factory = HT2LT(html)->getResourceFactory(); ComplexButtonResource *complex_b_r = diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -1932,9 +1932,8 @@ * Read image-associated tag attributes, * create new image and add it to the html page (if add is TRUE). */ -DilloImage *a_Html_add_new_image(DilloHtml *html, const char *tag, - int tagsize, DilloUrl *url, - bool add) +DilloImage *a_Html_image_new(DilloHtml *html, const char *tag, + int tagsize, DilloUrl *url) { const int MAX_W = 6000, MAX_H = 6000; @@ -1974,7 +1973,7 @@ dFree(width_ptr); dFree(height_ptr); width_ptr = height_ptr = NULL; - MSG("a_Html_add_new_image: suspicious image size request %dx%d\n", w, h); + MSG("a_Html_image_new: suspicious image size request %dx%d\n", w, h); } else { if (CSS_LENGTH_TYPE(l_w) != CSS_LENGTH_TYPE_AUTO) props.set (CssProperty::CSS_PROPERTY_WIDTH, l_w); @@ -2035,10 +2034,6 @@ /* Add a new image widget to this page */ Image = a_Image_new(0, 0, alt_ptr, 0); - if (add) { - DW2TB(html->dw)->addWidget((Widget*)Image->dw, - html->styleEngine->style()); - } if (DW2TB(html->dw)->getBgColor()) Image->bg_color = DW2TB(html->dw)->getBgColor()->getColor(); @@ -2101,7 +2096,8 @@ /* TODO: usemap URLs outside of the document are not used. */ usemap_url = a_Html_url_new(html, attrbuf, NULL, 0); - Image = a_Html_add_new_image(html, tag, tagsize, url, true); + Image = a_Html_image_new(html, tag, tagsize, url); + DW2TB(html->dw)->addWidget((Widget*)Image->dw, html->styleEngine->style()); /* Image maps */ if (a_Html_get_attr(html, tag, tagsize, "ismap")) { diff --git a/src/html_common.hh b/src/html_common.hh --- a/src/html_common.hh +++ b/src/html_common.hh @@ -257,9 +257,8 @@ const char *url_str, const char *base_url, int use_base_url); -DilloImage *a_Html_add_new_image(DilloHtml *html, const char *tag, - int tagsize, DilloUrl *url, - bool add); +DilloImage *a_Html_image_new(DilloHtml *html, const char *tag, + int tagsize, DilloUrl *url); char *a_Html_parse_entities(DilloHtml *html, const char *token, int toksize); void a_Html_pop_tag(DilloHtml *html, int TagIdx); From corvid at lavabit.com Sat Feb 7 21:20:18 2009 From: corvid at lavabit.com (corvid) Date: Sat Feb 7 21:22:23 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207175721.GG32473@omphalos.singularity> References: <20090207175721.GG32473@omphalos.singularity> Message-ID: <20090207202018.GC8385@local.gobigwest.com> Jeremy wrote: > There is IMHO a nasty code smell around a_Html_add_new_image(): it > takes a boolean parameter that determines whether or not it actually > adds the image. It's only called from two other places, once with the > parameter set to false and once with it set to true. > > This patch cleans things up by renaming a_Html_add_new_image() to > a_Html_image_new(), removing the boolean parameter and making the > caller add the image (or not) as appropriate. > > Perhaps it is a judgement call as to whether this is an improvement, > but I feel that it is. Please comment. In principle it might be dangerous in some way for the callers to wait to add widgets until after Html_load_image() is called, but as long as there aren't any timeouts in between, I don't think we'd be able to make it break. From jcid at dillo.org Sat Feb 7 22:33:29 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Feb 7 22:33:57 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090206205628.GJ5991@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> Message-ID: <20090207213329.GK5991@dillo.org> On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote: > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > > > Greetings to all. > > > > > > > > As a simple introduction may I say I thank you all for your work on > > > > Dillo. > > > > > > > > Currently, I am trying to implement the Close-Tab button. I've been > > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > > > dillo-dev. > > > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > > > and the idea was to have a button at the end of the tabs list. > > > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > > > this widget at the end of the tabs list and, then, I add() it to the > > > > CustTabGroup's parent() (UI). > > > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > > > such a way that it doesn't resize the button itself, but only moves it. > > > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > > > handle() method of the CustTabGroup. > > > > > > > > Just a second ago I solved one of the problems, which was the fact that > > > > tab_height() returned 0 in the constructor and resize() didn't work. I > > > > worked around that by constructing the button only in event() if > > > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > > > the correct height for the button. > > > > > > > > It may not seem reliable to do so many things in handle(). Any > > > > suggestions? > > > > > > We need to get something working, review it, and then we may > > > ask in fltk.general whether it could have side effects. > > > > > > > It is functional, only you can say if it fully suits Dillo's needs > > > > though. > > > > > > Please post the patch here so we can look at it. > > > > > > > Unfortunately, there are some problems: > > > > > > > > The first one is the most-relevant one. When the list of tabs grows it > > > > can go over the button. I have been trying to fix this, but I can't seem > > > > to do it. > > > > A possible way could (maybe) be to 'trick' the pager into thinking it > > > > has less space left to draw the tabs, and that could possibly be > > > > achieved using update_positions(), although I am having some problems > > > > with that. > > > > > > Or maybe just tweaking the value. After all it's a workaround. > > > > > > > The second problem is a minor one, but annoying. I believe when CSS > > > > rendering is triggered, the render area flickers and that is normal. > > > > However, the way I implemented this (probably because of it being in > > > > handle()) makes the Button also flash. > > > > > > A side affect of being a child of UI. > > > > > > > So, as requested, here is what I have got until now. There is a > > particular line I think is not necessary, I commented that specifically. > > I'm reviewing it now. Well, the good part is that it works and can be polished a bit. The problem is side effects (e.g. redraw storms while moving the mouse over the panel buttons, and who knows what else?). I tried a different approach and it almost worked OK, but after resizing the window, the redraw storms are on the whole window. Frustrating... It looks like drawing the button in the pager could work. I'll try to write some code this way. -- Cheers Jorge.- From jorl17.8 at gmail.com Sat Feb 7 22:57:52 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Sat Feb 7 22:58:00 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090207213329.GK5991@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> Message-ID: <1234043872.22906.0.camel@jorl17-laptop> S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu: > On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote: > > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > > > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > > > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Greetings to all. > > > > > > > > > > As a simple introduction may I say I thank you all for your work on > > > > > Dillo. > > > > > > > > > > Currently, I am trying to implement the Close-Tab button. I've been > > > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > > > > dillo-dev. > > > > > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > > > > and the idea was to have a button at the end of the tabs list. > > > > > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > > > > this widget at the end of the tabs list and, then, I add() it to the > > > > > CustTabGroup's parent() (UI). > > > > > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > > > > such a way that it doesn't resize the button itself, but only moves it. > > > > > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > > > > handle() method of the CustTabGroup. > > > > > > > > > > Just a second ago I solved one of the problems, which was the fact that > > > > > tab_height() returned 0 in the constructor and resize() didn't work. I > > > > > worked around that by constructing the button only in event() if > > > > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > > > > the correct height for the button. > > > > > > > > > > It may not seem reliable to do so many things in handle(). Any > > > > > suggestions? > > > > > > > > We need to get something working, review it, and then we may > > > > ask in fltk.general whether it could have side effects. > > > > > > > > > It is functional, only you can say if it fully suits Dillo's needs > > > > > though. > > > > > > > > Please post the patch here so we can look at it. > > > > > > > > > Unfortunately, there are some problems: > > > > > > > > > > The first one is the most-relevant one. When the list of tabs grows it > > > > > can go over the button. I have been trying to fix this, but I can't seem > > > > > to do it. > > > > > A possible way could (maybe) be to 'trick' the pager into thinking it > > > > > has less space left to draw the tabs, and that could possibly be > > > > > achieved using update_positions(), although I am having some problems > > > > > with that. > > > > > > > > Or maybe just tweaking the value. After all it's a workaround. > > > > > > > > > The second problem is a minor one, but annoying. I believe when CSS > > > > > rendering is triggered, the render area flickers and that is normal. > > > > > However, the way I implemented this (probably because of it being in > > > > > handle()) makes the Button also flash. > > > > > > > > A side affect of being a child of UI. > > > > > > > > > > So, as requested, here is what I have got until now. There is a > > > particular line I think is not necessary, I commented that specifically. > > > > I'm reviewing it now. > > Well, the good part is that it works and can be polished a bit. > The problem is side effects (e.g. redraw storms while moving the mouse > over the panel buttons, and who knows what else?). > > I tried a different approach and it almost worked OK, but after > resizing the window, the redraw storms are on the whole window. > > Frustrating... > > It looks like drawing the button in the pager could work. I'll > try to write some code this way. > Thanks. Redraw storms are visible when running it under valgrind. Also, parts of the code there were/are unnecessary. For instance, we could send the redraw() message only when adding a new tab and not continuously, but the redraw storms continue either way... Adding it to the pager seems the way to go there, but will you add it as a button, or a custom drawn widget? If you need any help, do say, I'll try to do my best, Jo?o From onepoint at starurchin.org Sat Feb 7 23:37:10 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Feb 7 23:37:46 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207202018.GC8385@local.gobigwest.com> References: <20090207175721.GG32473@omphalos.singularity> <20090207202018.GC8385@local.gobigwest.com> Message-ID: <20090207223710.GI32473@omphalos.singularity> On Sat, Feb 07, 2009 at 08:20:18PM +0000, corvid wrote: > Jeremy wrote: > > There is IMHO a nasty code smell around a_Html_add_new_image(): it > > takes a boolean parameter that determines whether or not it > > actually adds the image. It's only called from two other places, > > once with the parameter set to false and once with it set to true. > > [...] > In principle it might be dangerous in some way for the callers to > wait to add widgets until after Html_load_image() is called, If we want the a_Html_* API to guard against that then that is another reason for changing it, since the current API allows you to create the image and not add it. In that case I'd suggest applying my patch and then changing a_Html_image_new() to static Html_image_new() and adding a_Html_add_new_image() and a_Html_add_new_image_button(). That would fix the code smell *and* enforce the "add any image that you create" condition. Does that make sense? Regards, Jeremy Henty From jcid at dillo.org Sat Feb 7 23:58:07 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Feb 7 23:58:22 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <1234043872.22906.0.camel@jorl17-laptop> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> Message-ID: <20090207225807.GL5991@dillo.org> On Sat, Feb 07, 2009 at 09:57:52PM +0000, Jo?o Ricardo Louren?o wrote: > S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu: > > On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > > > > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > > > > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > Greetings to all. > > > > > > > > > > > > As a simple introduction may I say I thank you all for your work on > > > > > > Dillo. > > > > > > > > > > > > Currently, I am trying to implement the Close-Tab button. I've been > > > > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > > > > > dillo-dev. > > > > > > > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > > > > > and the idea was to have a button at the end of the tabs list. > > > > > > > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > > > > > this widget at the end of the tabs list and, then, I add() it to the > > > > > > CustTabGroup's parent() (UI). > > > > > > > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > > > > > such a way that it doesn't resize the button itself, but only moves it. > > > > > > > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > > > > > handle() method of the CustTabGroup. > > > > > > > > > > > > Just a second ago I solved one of the problems, which was the fact that > > > > > > tab_height() returned 0 in the constructor and resize() didn't work. I > > > > > > worked around that by constructing the button only in event() if > > > > > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > > > > > the correct height for the button. > > > > > > > > > > > > It may not seem reliable to do so many things in handle(). Any > > > > > > suggestions? > > > > > > > > > > We need to get something working, review it, and then we may > > > > > ask in fltk.general whether it could have side effects. > > > > > > > > > > > It is functional, only you can say if it fully suits Dillo's needs > > > > > > though. > > > > > > > > > > Please post the patch here so we can look at it. > > > > > > > > > > > Unfortunately, there are some problems: > > > > > > > > > > > > The first one is the most-relevant one. When the list of tabs grows it > > > > > > can go over the button. I have been trying to fix this, but I can't seem > > > > > > to do it. > > > > > > A possible way could (maybe) be to 'trick' the pager into thinking it > > > > > > has less space left to draw the tabs, and that could possibly be > > > > > > achieved using update_positions(), although I am having some problems > > > > > > with that. > > > > > > > > > > Or maybe just tweaking the value. After all it's a workaround. > > > > > > > > > > > The second problem is a minor one, but annoying. I believe when CSS > > > > > > rendering is triggered, the render area flickers and that is normal. > > > > > > However, the way I implemented this (probably because of it being in > > > > > > handle()) makes the Button also flash. > > > > > > > > > > A side affect of being a child of UI. > > > > > > > > > > > > > So, as requested, here is what I have got until now. There is a > > > > particular line I think is not necessary, I commented that specifically. > > > > > > I'm reviewing it now. > > > > Well, the good part is that it works and can be polished a bit. > > The problem is side effects (e.g. redraw storms while moving the mouse > > over the panel buttons, and who knows what else?). > > > > I tried a different approach and it almost worked OK, but after > > resizing the window, the redraw storms are on the whole window. > > > > Frustrating... > > > > It looks like drawing the button in the pager could work. I'll > > try to write some code this way. > > > > Thanks. Redraw storms are visible when running it under valgrind. Also, > parts of the code there were/are unnecessary. For instance, we could > send the redraw() message only when adding a new tab and not > continuously, but the redraw storms continue either way... > > Adding it to the pager seems the way to go there, but will you add it as > a button, or a custom drawn widget? Custom drawn widget. > If you need any help, do say, I'll try to do my best, Good! Currently I have a good start. It draws the "button" from draw_tabs() and the events can be got from CustTabGroup's handle(). I'll try to advance it a bit more and then send you the code for finishing. -- Cheers Jorge.- From corvid at lavabit.com Sun Feb 8 00:59:03 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 8 01:01:08 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207223710.GI32473@omphalos.singularity> References: <20090207175721.GG32473@omphalos.singularity> <20090207202018.GC8385@local.gobigwest.com> <20090207223710.GI32473@omphalos.singularity> Message-ID: <20090207235903.GD8385@local.gobigwest.com> Jeremy wrote: > On Sat, Feb 07, 2009 at 08:20:18PM +0000, corvid wrote: > > Jeremy wrote: > > > > There is IMHO a nasty code smell around a_Html_add_new_image(): it > > > takes a boolean parameter that determines whether or not it > > > actually adds the image. It's only called from two other places, > > > once with the parameter set to false and once with it set to true. > > > [...] > > In principle it might be dangerous in some way for the callers to > > wait to add widgets until after Html_load_image() is called, > > If we want the a_Html_* API to guard against that then that is another > reason for changing it, since the current API allows you to create the > image and not add it. In that case I'd suggest applying my patch and > then changing a_Html_image_new() to static Html_image_new() and adding > a_Html_add_new_image() and a_Html_add_new_image_button(). That would > fix the code smell *and* enforce the "add any image that you create" > condition. Does that make sense? I'm not sure the "danger" is really worth worrying about; it's just something that crossed my mind... From onepoint at starurchin.org Sun Feb 8 02:37:57 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Feb 8 02:38:34 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207235903.GD8385@local.gobigwest.com> References: <20090207175721.GG32473@omphalos.singularity> <20090207202018.GC8385@local.gobigwest.com> <20090207223710.GI32473@omphalos.singularity> <20090207235903.GD8385@local.gobigwest.com> Message-ID: <20090208013757.GJ32473@omphalos.singularity> On Sat, Feb 07, 2009 at 11:59:03PM +0000, corvid wrote: > Jeremy wrote: > > On Sat, Feb 07, 2009 at 08:20:18PM +0000, corvid wrote: > > > > > > In principle it might be dangerous in some way for the callers > > > to wait to add widgets until after Html_load_image() is called, > > > > If we want the a_Html_* API to guard against that then that is > > another reason for changing it, since the current API allows you > > to create the image and not add it. [...] > > I'm not sure the "danger" is really worth worrying about; it's just > something that crossed my mind... Sure, but even if there's no real danger it's nice to have an API that expresses how the code is meant to work. Regards, Jeremy Henty From jorl17.8 at gmail.com Sun Feb 8 14:11:44 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Sun Feb 8 14:11:53 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090208023849.GM5991@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> <20090208023849.GM5991@dillo.org> Message-ID: <1234098704.6886.4.camel@jorl17-laptop> S?b, 2009-02-07 ?s 23:38 -0300, Jorge Arellano Cid escreveu: > On Sat, Feb 07, 2009 at 09:57:52PM +0000, Jo?o Ricardo Louren?o wrote: > > S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu: > > > On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > > > > > > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > > Greetings to all. > > > > > > > > > > > > > > As a simple introduction may I say I thank you all for your work on > > > > > > > Dillo. > > > > > > > > > > > > > > Currently, I am trying to implement the Close-Tab button. I've been > > > > > > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > > > > > > dillo-dev. > > > > > > > > > > > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > > > > > > and the idea was to have a button at the end of the tabs list. > > > > > > > > > > > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > > > > > > this widget at the end of the tabs list and, then, I add() it to the > > > > > > > CustTabGroup's parent() (UI). > > > > > > > > > > > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > > > > > > such a way that it doesn't resize the button itself, but only moves it. > > > > > > > > > > > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > > > > > > handle() method of the CustTabGroup. > > > > > > > > > > > > > > Just a second ago I solved one of the problems, which was the fact that > > > > > > > tab_height() returned 0 in the constructor and resize() didn't work. I > > > > > > > worked around that by constructing the button only in event() if > > > > > > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > > > > > > the correct height for the button. > > > > > > > > > > > > > > It may not seem reliable to do so many things in handle(). Any > > > > > > > suggestions? > > > > > > > > > > > > We need to get something working, review it, and then we may > > > > > > ask in fltk.general whether it could have side effects. > > > > > > > > > > > > > It is functional, only you can say if it fully suits Dillo's needs > > > > > > > though. > > > > > > > > > > > > Please post the patch here so we can look at it. > > > > > > > > > > > > > Unfortunately, there are some problems: > > > > > > > > > > > > > > The first one is the most-relevant one. When the list of tabs grows it > > > > > > > can go over the button. I have been trying to fix this, but I can't seem > > > > > > > to do it. > > > > > > > A possible way could (maybe) be to 'trick' the pager into thinking it > > > > > > > has less space left to draw the tabs, and that could possibly be > > > > > > > achieved using update_positions(), although I am having some problems > > > > > > > with that. > > > > > > > > > > > > Or maybe just tweaking the value. After all it's a workaround. > > > > > > > > > > > > > The second problem is a minor one, but annoying. I believe when CSS > > > > > > > rendering is triggered, the render area flickers and that is normal. > > > > > > > However, the way I implemented this (probably because of it being in > > > > > > > handle()) makes the Button also flash. > > > > > > > > > > > > A side affect of being a child of UI. > > > > > > > > > > > > > > > > So, as requested, here is what I have got until now. There is a > > > > > particular line I think is not necessary, I commented that specifically. > > > > > > > > I'm reviewing it now. > > > > > > Well, the good part is that it works and can be polished a bit. > > > The problem is side effects (e.g. redraw storms while moving the mouse > > > over the panel buttons, and who knows what else?). > > > > > > I tried a different approach and it almost worked OK, but after > > > resizing the window, the redraw storms are on the whole window. > > > > > > Frustrating... > > > > > > It looks like drawing the button in the pager could work. I'll > > > try to write some code this way. > > > > > > > Thanks. Redraw storms are visible when running it under valgrind. Also, > > parts of the code there were/are unnecessary. For instance, we could > > send the redraw() message only when adding a new tab and not > > continuously, but the redraw storms continue either way... > > > > Adding it to the pager seems the way to go there, but will you add it as > > a button, or a custom drawn widget? > > > > If you need any help, do say, I'll try to do my best, > > Attached goes a patch that behaves nicely. > Please polish it to a final state. It is commented. > > The button drawing code lacks the "X", the callback is not hooked, > and there's no tooltip, but it doesn't trigger redraw storms, > and feels right. > > Good luck! OK, I've already implemented update_positions() to prevent tabs from going over the button (grabbed it from FLTK and altered it). I don't think there is the need for a callback function, since it only calls a simple line. I've noticed that we have no checking if the button is visible or not, so it is working even though there are no tabs, I'll add a check for that in event() rather than in other places. Thanks, Jo?o From jcid at dillo.org Sun Feb 8 17:52:06 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 17:52:04 2009 Subject: [Dillo-dev] Rendering XHTML 1.1 In-Reply-To: <4986B7E0.8060508@gmx.de> References: <4986B7E0.8060508@gmx.de> Message-ID: <20090208165206.GN5991@dillo.org> On Mon, Feb 02, 2009 at 10:07:44AM +0100, Hole.destructor@gmx.de wrote: > Hello Dillo developers, > > since you are planing to release Dillo-2.1 in about a month, I am > wondering whether there are plans to support XHTML 1.1, XHTML 1.1 is possible now. It's disabled because we are not making a formal validation (though Firefox doesn't do it either). > HTML 5 and XHTML > 2 web pages in the near future? Not in the near future. Unless new developers, knowledgeable in that area, join us. -- Cheers Jorge.- From jcid at dillo.org Sun Feb 8 21:03:42 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 21:04:09 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <1233871472.6763.28.camel@jorl17-laptop> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> <1233867384.6763.19.camel@jorl17-laptop> <1233871472.6763.28.camel@jorl17-laptop> Message-ID: <20090208200342.GP5991@dillo.org> On Thu, Feb 05, 2009 at 10:04:32PM +0000, Jo?o Ricardo Louren?o wrote: > Qui, 2009-02-05 ?s 20:56 +0000, Jo?o Ricardo Louren?o escreveu: > > Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > > > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > > > Hello, > > > > > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > > Greetings. > > > > > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > > > it. > > > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > > > I see some issues in your implementation. E.g. try to search for > > > > > > 'ab' in a string 'abababa'. > > > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > > > matches, but once it no longer does you would need to backtrack. > > > > > > The easiest but inefficient way to implement searching > > > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > > > algorithm avoids that. > > > > > > I think it would be best to adapt search0 somehow to allow backward > > > > > > searching - it's more or less the same thing as forward searching > > > > > > anyway. Some ugly edge cases when switching between forward and > > > > > > backward maybe :-) > > > > > > > > > > > > Thanks for working on that, > > > > > > Johannes > > > > > > > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > > > forwards? > > > > > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > > > compilable, but I might add some tests soon. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jo?o > > > > > > > > > > Thanks for your answer. > > > > > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > > > got (provisory) working search0Backwards() replacement. How efficient do > > > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > > > you think there is a 'really' better way of searching backwards, than > > > > > reversing the word and searching backwards? As far as code-changes it > > > > > takes very few lines and I have a working example of it. However, the > > > > > extra reversing work might hit us hard. > > > > > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > > > to be rather small and we only need to reverse it once. > > > > The point is to avoid the backtracking. So that every letter in the > > > > text (haystack) is only visited once. > > > > > > If reversing the needle is all it takes, go ahead. > > > If the code is simple and it takes twice the time a forward > > > search, go ahead too. Backward search is much less used than > > > forward search and it's better to have it than not, and unless > > > the delay is annoying there's no compelling need to optimize. > > > > > > > > > > Thanks for the answer. > > > > OK, I think I worked it out, but the string is being reversed everytime > > we search backwards, to maintain compatibility with forward searching. > > Of course an alternative is to store it as private member, what do you > > think? Not necessary > > I couldn't find any function for reversing a C-String in dillo's code, > > so I put my own as a static member in FindtextState, should I move it > > elsewhere? Let's leave it there until needed. > > I tested multiple cases and it seems (to me) that this one is bugless, > > maybe you'll find a nasty/dirty bug I caused, but time will tell :) Now the "real world" test begins. > Scratch that, my bad, that patch contained various bugs. The first kind > of bug related to a typo which I now fixed. The second kind because of > me interpreting code the wrong way and the third one because of the > particular case of searching for things either at the beggining or at > the end of the page. I think I fixed all of them and have an updated > patch, excuse me for my previous mistakes... Committed! It has some changes: - Mainly whitespace (i.e. indentation). Please review them. - Added Shift+Enter as keyboard shortcut. - Simpler implementation of rev. It feels good! -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Sun Feb 8 21:18:04 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Sun Feb 8 21:26:02 2009 Subject: [Dillo-dev] CSS update committed Message-ID: <20090208201804.GA11589@blob.baaderstrasse.com> Hi, I just committed a major update of the CSS code. CSS values now have a type and the CSS parser can accept multiple types for one property. One example is font-size, which can either be a length or an enum (xx-small, x-small, ...). This fixes the font size issue on wikipedia.org. Cheers, Johannes From corvid at lavabit.com Sun Feb 8 21:59:18 2009 From: corvid at lavabit.com (corvid) Date: Sun Feb 8 22:01:27 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <20090208200342.GP5991@dillo.org> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> <1233867384.6763.19.camel@jorl17-laptop> <1233871472.6763.28.camel@jorl17-laptop> <20090208200342.GP5991@dillo.org> Message-ID: <20090208205918.GG8385@local.gobigwest.com> Nice! I notice that if I search backward for a space, it won't loop back to the end after reaching the top. From jcid at dillo.org Sun Feb 8 22:03:09 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 22:23:58 2009 Subject: [Dillo-dev] name/id bug In-Reply-To: <20090206163844.GA2812@blob.baaderstrasse.com> References: <20090206062254.GS29275@local.gobigwest.com> <20090206095837.GA4925@blob.baaderstrasse.com> <20090206100611.GA5037@blob.baaderstrasse.com> <20090206113820.GA98817@blob.baaderstrasse.com> <20090206145901.GD5991@dillo.org> <20090206150158.GA877@blob.baaderstrasse.com> <20090206163424.GG5991@dillo.org> <20090206163844.GA2812@blob.baaderstrasse.com> Message-ID: <20090208210309.GQ5991@dillo.org> On Fri, Feb 06, 2009 at 05:38:44PM +0100, Hofmann Johannes wrote: > On Fri, Feb 06, 2009 at 01:34:24PM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 06, 2009 at 04:01:58PM +0100, Hofmann Johannes wrote: > > > On Fri, Feb 06, 2009 at 11:59:01AM -0300, Jorge Arellano Cid wrote: > > > > On Fri, Feb 06, 2009 at 12:38:20PM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 06, 2009 at 11:06:11AM +0100, Hofmann Johannes wrote: > > > > > > On Fri, Feb 06, 2009 at 10:58:37AM +0100, Hofmann Johannes wrote: > > > > > > > On Fri, Feb 06, 2009 at 06:22:54AM +0000, corvid wrote: > > > > > > > > > > > > > > > >

> > > > > > > >

> > > > > > > > > > > > > > > > > > > > > > > > gives > > > > > > > > HTML warning: line 2, 'id' and 'name' attribute of tag differ > > > > > > > > HTML warning: line 4, Anchor names must be unique within the document > > > > > > > > > > > > > > > > Dillo would seem to be unhappy now that the id attr is checked before > > > > > > > > open_a checks the name attr -- but then it looks like the move was > > > > > > > > made in October (a88b4a31cb7a) and I have a dillo around from > > > > > > > > roughly Dec. 22 that does not have a problem with this. > > > > > > > > > > > > > > Yes, the problem was caused by moving the check. > > > > > > > > > > > > > > > > > > > > > > > In any case, I don't know whether there are styleEngine issues with > > > > > > > > just sticking the id check back after the open. > > > > > > > > > > > > > > We need to parse the "id" attribute before the open, as it's used to > > > > > > > determine the style used in open*. > > > > > > > > > > > > > > But I don't understand the reason for the name/id check in the first > > > > > > > place: > > > > > > > > > > > > > > > > > > > > > > > > > > > > foo bar > > > > > > > > > > > > > > foo bar > > > > > > > > > > > > > > > > > > > > > > > > > > > > is correct HTML according to http://validator.w3.org/. > > > > > > > I would propose to remove this check completely. Opinions? > > > > > > > > > > > > Ooops, stop! > > > > > > I just found this: http://www.validome.org/lang/ge/errors/MISC/3005 > > > > > > It seems that name and id must be equal and it's a bug in > > > > > > http://validator.w3.org/ that it doesn't catch it. > > > > > > I will try to fix the check in dillo. > > > > > > > > > > Please test/review current tip > > > > > > > > After a quick review, it seems to me that the proper solution > > > > is to add a test in the open function for A, APPLET, FORM, FRAME, > > > > IFRAME, IMG and MAP. Something like: > > > > > > > > if (id && nameVal && strcmp(nameVal, id)) > > > > BUG_MSG("'id' and 'name' attribute of <%s> tag differ\n", tag_name); > > > > if (nameVal) > > > > Html_add_anchor(html, nameVal); > > > > > > If id and nameVal don't differ, we don't want to call > > > Html_add_anchor(). It has already been called with the same value > > > from Html_parse_common_attrs(). > > > > > > We could put the corresponding code that is currently in > > > Html_tag_open_a() in a new function Html_handle_name_attr() and call > > > that from all elements that allow a "name" attribute. > > > > Right, that's the idea. > > Maybe: > > > > if (id && strcmp(nameVal, id) == 0) { > > BUG_MSG("'id' and 'name' attribute of tag differ\n"); > > } else { > > Html_add_anchor(html, nameVal); > > } > > That's not quite it. I think the original test, that I now moved to > Html_tag_open_a() is ok: > > if (!id || strcmp(nameVal, id)) { > if (id) > BUG_MSG("'id' and 'name' attribute of tag differ\n"); > Html_add_anchor(html, nameVal); > } > > I.e. do something if id is not set or id and name differ. > Then if they differ output a warning. > Add an anchor for the new string. You're right. -- Cheers Jorge.- From jcid at dillo.org Sun Feb 8 22:23:59 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 22:24:03 2009 Subject: [Dillo-dev] patch: line appearance In-Reply-To: <20090207050112.GA7682@local.gobigwest.com> References: <20090207050112.GA7682@local.gobigwest.com> Message-ID: <20090208212359.GR5991@dillo.org> On Sat, Feb 07, 2009 at 05:01:12AM +0000, corvid wrote: > I was thinking that large text with a thin line through it > looks odd. > Turns out that there was also a problem with causing the > line to be too high. > > This looks about right to me with the few fonts I have around. > > I'm attaching an example html file as well. Committed. -- Cheers Jorge.- From jcid at dillo.org Sun Feb 8 22:24:33 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 22:24:31 2009 Subject: [Dillo-dev] patch: line appearance In-Reply-To: <20090207155713.GA8385@local.gobigwest.com> References: <20090207050112.GA7682@local.gobigwest.com> <20090207143246.GA1414@blob.baaderstrasse.com> <20090207155713.GA8385@local.gobigwest.com> Message-ID: <20090208212433.GS5991@dillo.org> On Sat, Feb 07, 2009 at 03:57:13PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Feb 07, 2009 at 05:01:12AM +0000, corvid wrote: > > > I was thinking that large text with a thin line through it > > > looks odd. > > > Turns out that there was also a problem with causing the > > > line to be too high. > > > > > > This looks about right to me with the few fonts I have around. > > > > Maybe one could determine the line width based on the xHeight member > > of the font? Just an idea. > > Ah, good. 'diff' was sort of compensating for what sup and sub do to > ascent and descent, but imperfectly -- as you probably noticed. > > Here's a new patch. BTW, the new patch was the committed one. -- Cheers Jorge.- From jcid at dillo.org Sun Feb 8 22:34:11 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 22:34:10 2009 Subject: [Dillo-dev] patch: clean up a_Html_add_image In-Reply-To: <20090207175721.GG32473@omphalos.singularity> References: <20090207175721.GG32473@omphalos.singularity> Message-ID: <20090208213411.GT5991@dillo.org> On Sat, Feb 07, 2009 at 05:57:21PM +0000, Jeremy Henty wrote: > > There is IMHO a nasty code smell around a_Html_add_new_image(): it > takes a boolean parameter that determines whether or not it actually > adds the image. It's only called from two other places, once with the > parameter set to false and once with it set to true. > > This patch cleans things up by renaming a_Html_add_new_image() to > a_Html_image_new(), removing the boolean parameter and making the > caller add the image (or not) as appropriate. > > Perhaps it is a judgement call as to whether this is an improvement, > but I feel that it is. Please comment. It looks like an improvement. Committed. -- Cheers Jorge.- From jcid at dillo.org Sun Feb 8 23:38:53 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Feb 8 23:38:51 2009 Subject: [Dillo-dev] CSS update committed In-Reply-To: <20090208201804.GA11589@blob.baaderstrasse.com> References: <20090208201804.GA11589@blob.baaderstrasse.com> Message-ID: <20090208223853.GV5991@dillo.org> On Sun, Feb 08, 2009 at 09:18:04PM +0100, Hofmann Johannes wrote: > Hi, > > I just committed a major update of the CSS code. CSS values now have > a type and the CSS parser can accept multiple types for one > property. One example is font-size, which can either be a length or > an enum (xx-small, x-small, ...). > This fixes the font size issue on wikipedia.org. I just saw the big commit! It'd be very good if you provide us with examples of what is changing (just as you did, just a bit more for non CSS-savvy guys like me ;). -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Feb 9 09:35:18 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Mon Feb 9 09:43:15 2009 Subject: [Dillo-dev] CSS update committed In-Reply-To: <20090208223853.GV5991@dillo.org> References: <20090208201804.GA11589@blob.baaderstrasse.com> <20090208223853.GV5991@dillo.org> Message-ID: <20090209083518.GA917@blob.baaderstrasse.com> On Sun, Feb 08, 2009 at 07:38:53PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 08, 2009 at 09:18:04PM +0100, Hofmann Johannes wrote: > > Hi, > > > > I just committed a major update of the CSS code. CSS values now have > > a type and the CSS parser can accept multiple types for one > > property. One example is font-size, which can either be a length or > > an enum (xx-small, x-small, ...). > > This fixes the font size issue on wikipedia.org. > > I just saw the big commit! > > It'd be very good if you provide us with examples of what > is changing (just as you did, just a bit more for non CSS-savvy > guys like me ;). The visible change is that "font-size: normal", "font-size: smaller", or "font-size: xx-large", etc. should work now as expected. In addition font-weight handling has been moved to the new scheme. The commit also provides the ground work to support the "inherit" special value in the future. Cheers, Johannes From jorl17.8 at gmail.com Mon Feb 9 19:11:36 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Mon Feb 9 19:12:09 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <20090208205918.GG8385@local.gobigwest.com> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> <1233867384.6763.19.camel@jorl17-laptop> <1233871472.6763.28.camel@jorl17-laptop> <20090208200342.GP5991@dillo.org> <20090208205918.GG8385@local.gobigwest.com> Message-ID: <1234203096.6768.5.camel@jorl17-laptop> Dom, 2009-02-08 ?s 20:59 +0000, corvid escreveu: > Nice! > > I notice that if I search backward for a space, > it won't loop back to the end after reaching the top. > > > Thanks for reporting that. I've been digging through the code, seeking for an explanation, but can't seem to find it. Any ideas? It's odd that it happens only with a space, and I've been checking and it *seems* that the code finds the character, what can be wrong? Anyway, I'll keep digging... Jo?o From jcid at dillo.org Mon Feb 9 19:44:57 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Feb 9 19:44:55 2009 Subject: [Dillo-dev] [patch] Search Previous In-Reply-To: <1234203096.6768.5.camel@jorl17-laptop> References: <1233690498.6707.6.camel@jorl17-laptop> <20090203203901.GA28334@blob.baaderstrasse.com> <1233705296.6707.123.camel@jorl17-laptop> <20090204075126.GA891@blob.baaderstrasse.com> <20090204133524.GH9663@dillo.org> <1233867384.6763.19.camel@jorl17-laptop> <1233871472.6763.28.camel@jorl17-laptop> <20090208200342.GP5991@dillo.org> <20090208205918.GG8385@local.gobigwest.com> <1234203096.6768.5.camel@jorl17-laptop> Message-ID: <20090209184457.GC27915@dillo.org> On Mon, Feb 09, 2009 at 06:11:36PM +0000, Jo?o Ricardo Louren?o wrote: > Dom, 2009-02-08 ?s 20:59 +0000, corvid escreveu: > > Nice! > > > > I notice that if I search backward for a space, > > it won't loop back to the end after reaching the top. > > > > > > > > Thanks for reporting that. > > I've been digging through the code, seeking for an explanation, but > can't seem to find it. Any ideas? > > It's odd that it happens only with a space, and I've been checking and > it *seems* that the code finds the character, what can be wrong? > > Anyway, I'll keep digging... Please assign less priority to this bug, than to the close-tab button. -- Cheers Jorge.- From jcid at dillo.org Mon Feb 9 19:51:39 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Feb 9 19:51:35 2009 Subject: [Dillo-dev] Leaking image structures In-Reply-To: <20090204144751.GP6099@omphalos.singularity> References: <20090204144751.GP6099@omphalos.singularity> Message-ID: <20090209185139.GD27915@dillo.org> On Wed, Feb 04, 2009 at 02:47:51PM +0000, Jeremy Henty wrote: > > One of the biggest leaks that valgrind reports is image structures. > I'm attaching logs that show memory being allocated by a_Png_new() and > cousins and not being freed. There are also frequent leaks of memory > allocated by the image libraries from within the various image > callbacks, but I suspect these are just another effect of the Dillo > image structures not being freed. > > Unfortunately I'm having a hard time tracking these leaks down. They > regularly appear after long browsing sessions, but I haven't found any > single page that reproduces them. I suspect they are caused by some > race condition inside the CCC rather than the HTML parser. I am > browsing with image loading enabled, and if I understand the code > correctly that means that the Web structures in the CCC own all the > references to image structures. > > The fact that image structures are reference counted makes it hard to > know when the structures should be freed anyway. Indeed, does Dillo > even ensure that image structures are freed? Maybe this is just a > symptom of incomplete cleanup at exit rather than a true leak? > > I've looked over the code and can't see any obvious leaks so I'm > rather stuck. Any tips for tracking this down? Even if it's not a > true leak it would be good to have a fix that cleaned up the valgrind > logs. To me it looks like something akin to an aborted request may be the responsible for the reported leaks. Maybe an image redirection, or something that should be an image but ends actually being HTML content. In this case the process is aborted and probably there's an unref missing. A test case would be really valuable. In trying to build a test case, I'd start checking the above suggested cases. -- Cheers Jorge.- From corvid at lavabit.com Mon Feb 9 20:44:03 2009 From: corvid at lavabit.com (corvid) Date: Mon Feb 9 20:46:07 2009 Subject: [Dillo-dev] Leaking image structures In-Reply-To: <20090209185139.GD27915@dillo.org> References: <20090204144751.GP6099@omphalos.singularity> <20090209185139.GD27915@dillo.org> Message-ID: <20090209194402.GK8385@local.gobigwest.com> Probably not related, but occasionally progressive jpegs haven't been displaying some of the later scans. (But it's rare and doesn't repeat itself when I try again.) From jorl17.8 at gmail.com Mon Feb 9 22:23:38 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Mon Feb 9 22:23:48 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090207225807.GL5991@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> <20090207225807.GL5991@dillo.org> Message-ID: <1234214618.6601.34.camel@jorl17-laptop> A simple update. I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible). I've got a working tooltip, added to CustTabGroup. The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable. Thanks, Jo?o From jorl17.8 at gmail.com Mon Feb 9 22:34:14 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Mon Feb 9 22:34:22 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <1234214617.6601.33.camel@jorl17-laptop> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> <20090207225807.GL5991@dillo.org> <1234214617.6601.33.camel@jorl17-laptop> Message-ID: <1234215254.6601.43.camel@jorl17-laptop> Seg, 2009-02-09 ?s 21:23 +0000, Jo?o Ricardo Louren?o escreveu: > A simple update. > > I've fixed most issues I found. For instance, we were processing the > click on PUSH and not RELEASE, that was causing some problems and The > issue I talked about earlier (working while not visible). > > I've got a working tooltip, added to CustTabGroup. > > The only problem is drawing into the button. Should I use an image (or > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > Adding a cross is easy, adding an image involves digging some more but > it is obviously doable. > > Thanks, > > Jo?o Oh, not to mention preventing tabs from going over the button. However, I was testing multiple clicks on the button and it seems that dragging the pressing, dragging and quickly releasing the mouse button makes the events not reach its destination - I'm guessing a DRAG messages is being sent, we have to prevent for that too. Jo?o From corvid at lavabit.com Mon Feb 9 23:38:10 2009 From: corvid at lavabit.com (corvid) Date: Mon Feb 9 23:40:14 2009 Subject: [Dillo-dev] perhaps an iterator bug Message-ID: <20090209223810.GL8385@local.gobigwest.com> I was trying the new search functionality a bit more and found this (it's also present in my Dec 2008 dillo*). With the page:
no close-tr
has a close-tr
here's another line
if I search for "rh", it finds one instance of it split between the second and third table rows. * My older dillos were lost in a tragic "I don't think I need my CVS stuff anymore" accident. From jcid at dillo.org Tue Feb 10 20:55:27 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Feb 10 20:56:03 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <1234214618.6601.34.camel@jorl17-laptop> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> <20090207225807.GL5991@dillo.org> <1234214618.6601.34.camel@jorl17-laptop> Message-ID: <20090210195527.GC27658@dillo.org> On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > A simple update. > > I've fixed most issues I found. For instance, we were processing the > click on PUSH and not RELEASE, that was causing some problems and The > issue I talked about earlier (working while not visible). Good. > I've got a working tooltip, added to CustTabGroup. Good 2. I feared this could be harder. > The only problem is drawing into the button. Should I use an image (or > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > Adding a cross is easy, adding an image involves digging some more but > it is obviously doable. Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope). -- Cheers Jorge.- From jcid at dillo.org Tue Feb 10 21:03:18 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Feb 10 21:03:54 2009 Subject: [Dillo-dev] perhaps an iterator bug In-Reply-To: <20090209223810.GL8385@local.gobigwest.com> References: <20090209223810.GL8385@local.gobigwest.com> Message-ID: <20090210200318.GD27658@dillo.org> On Mon, Feb 09, 2009 at 10:38:10PM +0000, corvid wrote: > I was trying the new search functionality a bit more > and found this (it's also present in my Dec 2008 dillo*). > > With the page: > > > > >
no close-tr >
has a close-tr
here's another line
> > if I search for "rh", it finds one instance of it > split between the second and third table rows. Hmmm, this could take some time to fix. The last time I digged in the textblock for a bug with NBSP handling, it was clear that the internal representation for whitespace is somewhat fuzzy. I was looking for the mishandled NBSP in this page: http://www.fltk.org/newsgroups.php?gfltk.development+T "[Show Messages xxxx - yyyy]" should be all in one line. -- Cheers Jorge.- From furaisanjin at gmail.com Wed Feb 11 09:40:15 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Feb 11 09:40:21 2009 Subject: [Dillo-dev] google news link Message-ID: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> Hi all. I find that nothing happens when I click links on side bar within google news. On this page (http://news.google.com/news?ned=us), there are links such as World, U.S. and so on. None of them is clickable. Regards, furaisanjin From Johannes.Hofmann at gmx.de Wed Feb 11 09:57:09 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Feb 11 10:05:09 2009 Subject: [Dillo-dev] google news link In-Reply-To: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> References: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> Message-ID: <20090211085708.GA985@blob.baaderstrasse.com> Hi, On Wed, Feb 11, 2009 at 05:40:15PM +0900, furaisanjin wrote: > Hi all. > > I find that nothing happens when I click links on side bar within google news. > > On this page (http://news.google.com/news?ned=us), there are links > such as World, U.S. and so on. None of them is clickable. That's because they use some javascript to handle these buttons. However the cursor changes because of CSS. If you switch off CSS or use dillo-2.0, the cursor will not change. That makes me think whether it is a good idea to let the cursor be changed from CSS. For example: harmless might trick someone to click a link it doesn't want to. Or am I paranoid here? Regards, Johannes From furaisanjin at gmail.com Wed Feb 11 12:40:01 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Feb 11 12:40:06 2009 Subject: [Dillo-dev] google news link In-Reply-To: <20090211085708.GA985@blob.baaderstrasse.com> References: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> <20090211085708.GA985@blob.baaderstrasse.com> Message-ID: <144aa14b0902110340u27a37e32w71fb4b181c05419c@mail.gmail.com> I notice that dillo doesn't allow

inside . That's why link doesn't work. This is one example from news.google.com.
World
Regards, furaisanjin From jcid at dillo.org Wed Feb 11 13:37:59 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Feb 11 13:38:34 2009 Subject: [Dillo-dev] google news link In-Reply-To: <144aa14b0902110340u27a37e32w71fb4b181c05419c@mail.gmail.com> References: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> <20090211085708.GA985@blob.baaderstrasse.com> <144aa14b0902110340u27a37e32w71fb4b181c05419c@mail.gmail.com> Message-ID: <20090211123759.GF27658@dillo.org> On Wed, Feb 11, 2009 at 08:40:01PM +0900, furaisanjin wrote: > I notice that dillo doesn't allow
inside . That's why link > doesn't work. This is one example from news.google.com. > > >
> > > World > >
> Yes. It's dillo trying to follow and help others to play by standards. This page has more than a hundred bugs in the bug-meter. A is an "inline container", DIV is a "block element". Only "block containers" are allowed to have "block elements" inside. Hence it is a bug. In this case Dillo closes the inline container and keeps on parsing. BTW, this is the same reason why you can't make a link out of a TABLE. -- Cheers Jorge.- From jcid at dillo.org Wed Feb 11 14:58:24 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Feb 11 14:59:00 2009 Subject: [Dillo-dev] New mercurial repository Message-ID: <20090211135824.GH27658@dillo.org> Hi, Good news: Andreas K. has just set a fast Hg repository for dillo. Try it at: http://hg.dillo.org/dillo I'll switch the web page to point to it after sending this email. Enjoy! :-) -- Cheers Jorge.- From jcid at dillo.org Wed Feb 11 15:27:00 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Feb 11 15:27:35 2009 Subject: [Dillo-dev] ChangeLog Message-ID: <20090211142700.GJ27658@dillo.org> Hi, Johannes, corvid: it'd be good if you can update the ChangeLog file with your work. This ChangeLog is meant to be human-readable so please summarize as usual and highlight the important points. We have the full details in HG after all. -- Cheers Jorge.- From corvid at lavabit.com Wed Feb 11 17:05:06 2009 From: corvid at lavabit.com (corvid) Date: Wed Feb 11 17:07:05 2009 Subject: [Dillo-dev] google news link In-Reply-To: <20090211085708.GA985@blob.baaderstrasse.com> References: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> <20090211085708.GA985@blob.baaderstrasse.com> Message-ID: <20090211160506.GC15350@local.gobigwest.com> Johannes wrote: > That makes me think whether it is a good idea to let the cursor be > changed from CSS. For example: > > harmless > > might trick someone to click a link it doesn't want to. > Or am I paranoid here? If it's paranoia, it's a healthy paranoia :) (I already had to force underlining of links in style.css. I can't understand why non-malicious sites turn that off to make it hard to tell what's what.) From corvid at lavabit.com Wed Feb 11 17:27:55 2009 From: corvid at lavabit.com (corvid) Date: Wed Feb 11 17:29:54 2009 Subject: [Dillo-dev] New mercurial repository In-Reply-To: <20090211135824.GH27658@dillo.org> References: <20090211135824.GH27658@dillo.org> Message-ID: <20090211162755.GD15350@local.gobigwest.com> Jorge wrote: > Good news: Andreas K. has just set a fast Hg repository for > dillo. Try it at: http://hg.dillo.org/dillo Blazing fast after being accustomed to freehg. Thanks Andreas! BTW, the web interface wants to load http://hg.dillo.org/?static=style.css which gets a 500 internal server error. From onepoint at starurchin.org Wed Feb 11 18:15:46 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Feb 11 18:16:21 2009 Subject: [Dillo-dev] New mercurial repository In-Reply-To: <20090211135824.GH27658@dillo.org> References: <20090211135824.GH27658@dillo.org> Message-ID: <20090211171546.GP25867@omphalos.singularity> On Wed, Feb 11, 2009 at 10:58:24AM -0300, Jorge Arellano Cid wrote: > Good news: Andreas K. has just set a fast Hg repository for > dillo. Try it at: http://hg.dillo.org/dillo This is a vast improvement. Many thanks to Andreas! Jeremy Henty From onepoint at starurchin.org Wed Feb 11 18:25:26 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Feb 11 18:25:58 2009 Subject: [Dillo-dev] google news link In-Reply-To: <20090211123759.GF27658@dillo.org> References: <144aa14b0902110040m178efc17l27ce95946a9e7f85@mail.gmail.com> <20090211085708.GA985@blob.baaderstrasse.com> <144aa14b0902110340u27a37e32w71fb4b181c05419c@mail.gmail.com> <20090211123759.GF27658@dillo.org> Message-ID: <20090211172526.GQ25867@omphalos.singularity> On Wed, Feb 11, 2009 at 09:37:59AM -0300, Jorge Arellano Cid wrote: > A is an "inline container", DIV is a "block element". Only "block > containers" are allowed to have "block elements" inside. Hence it > is a bug. In this case Dillo closes the inline container and > keeps on parsing. Could the Dillo parser emit the warning but not close the container? The result would be more useful to the user, and web devs who care about correctness would still see the warning. (Disclaimer: I have no idea whether my suggestion is feasible, it's just a thought.) Regards, Jeremy Henty From jcid at dillo.org Wed Feb 11 21:06:55 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Feb 11 21:07:31 2009 Subject: [Dillo-dev] Repush and scroll position Message-ID: <20090211200655.GM27658@dillo.org> Hi, Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top. Please test. -- Cheers Jorge.- From jorl17.8 at gmail.com Wed Feb 11 22:23:02 2009 From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=) Date: Wed Feb 11 22:23:11 2009 Subject: [Dillo-dev] Close-tab Button In-Reply-To: <20090210195527.GC27658@dillo.org> References: <1233446809.7062.0.camel@jorl17-laptop> <20090201175149.GV5972@dillo.org> <1233535038.18551.2.camel@jorl17-laptop> <20090206205628.GJ5991@dillo.org> <20090207213329.GK5991@dillo.org> <1234043872.22906.0.camel@jorl17-laptop> <20090207225807.GL5991@dillo.org> <1234214618.6601.34.camel@jorl17-laptop> <20090210195527.GC27658@dillo.org> Message-ID: <1234387382.8945.19.camel@jorl17-laptop> Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > A simple update. > > > > I've fixed most issues I found. For instance, we were processing the > > click on PUSH and not RELEASE, that was causing some problems and The > > issue I talked about earlier (working while not visible). > > Good. > > > I've got a working tooltip, added to CustTabGroup. > > Good 2. I feared this could be harder. > > > The only problem is drawing into the button. Should I use an image (or > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > Adding a cross is easy, adding an image involves digging some more but > > it is obviously doable. > > Try drawing a cross with a couple of lines. After all this is a > well-baheved workaround, but no more. At some point in time it > will be fixed in FLTK (I hope). > Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these. To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code: fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH); Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross... I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself. Thanks, Jo?o From furaisanjin at gmail.com Wed Feb 11 23:51:36 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Feb 11 23:51:42 2009 Subject: [Dillo-dev] style parsing on iframe Message-ID: <144aa14b0902111451y55a59368xd67a5da4c53f736c@mail.gmail.com> Hi all. I'm wondering if it's necessary to parse style on iframe. I see a large bullet sometimes and this is one example page. http://www.oshiimamoru.com/news/news_r0807.htm The page contains this kind of iframe tag.