diff options
Diffstat (limited to 'old/oldmail/200012.txt')
| -rw-r--r-- | old/oldmail/200012.txt | 2938 |
1 files changed, 2938 insertions, 0 deletions
diff --git a/old/oldmail/200012.txt b/old/oldmail/200012.txt new file mode 100644 index 0000000..d692502 --- /dev/null +++ b/old/oldmail/200012.txt @@ -0,0 +1,2938 @@ +[Dillo-dev]ALT attribute in `img' tag + +From: Livio Baldini Soares <livio@li...> - 2000-12-27 20:17 + +Hi all! + +Recently I've inserted bug #116, to support ALT attributes in `img' +tags. Starting out the code, I realized that some of the needed +changes would go in dw_page.c and possibly html.c. Well I just read in +Allan's News, that Sebastian is planning to release his new Dw... + +Sebastian, have you done anything about the ALT attribute? And if +not should I wait a while for you to release what your doing before +trying to support ALT? + +best regards, + +-- +Livio <livio@li...> + + + +[Dillo-dev]dillo-0.3.1 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-27 17:54 + +Surprise! + + +dillo-0.3.1 is ready for download (sourceforge is back :) + +Enjoy +Jorge.- + + + +[Dillo-dev]Window geometry (get_size fix and new dillorc option) + +From: Livio Baldini Soares <livio@li...> - 2000-12-26 06:04 + +Hi guys, + +I've recently joined gtk list at gtk-list@gn..., and learned the +proper way of finding out a window's dimension. I was getting: +window->allocation.width +window->alloction.height + +in the patch I sent to make a new windows the same as parent +one. Seems that the "right" way to do it is calling +`gdk_window_get_size()`. I've already sent a patch to Jorge fixing +this up.. sorry guys. + +While I was on that "theme", I started to think about making an +option in dillorc for initial geometry size, because the first thing I +do when I open Dillo, is resize it... + +So that's what I've done. But I'm not sure the patch is good, +specially the string manipulations I've done to extract width and +height. The patch is at (I'm not sending it attached since it's +5k == 130 lines long): +http://www.linux.ime.usp.br/~livio/dillo/geometry_pref.diff + +The sintax in your dillorc, should be something like: + +> geometry="800x600" + +The patch changes the following files: + +dillorc: added comments and the above example +commands.c: changes the window size method to `gdk_window_get_size()', +like described abouve. +dillo.c: changed window initialization to get the preference size. +prefs.c: humm... did it! Look at my string stuff to see if I'm doing +it right +prefs.h: added +> #define DW_GEOMETRY_DEFAULT_WIDTH 640 +> #define DW_GEOMETRY_DEFAULT_HEIGHT 550 + +and `width' and `height' in struct _DilloPrefs. + +That's all... hope you like it (I did, don't have to keep resizing +dillo no more!) + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Entity parsing in links + +From: Eric GAUDET <egaudet@in...> - 2000-12-25 17:10 + +-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Jorge +Arellano Cid, le 24-Dec-2000 : +> I'll reply this post even though I know some posts hasn't +> arrived to my inbox (Is anyone else losing emails from the list?) +> + +I received Livio's replies to Sam before Sam's messages a couple of +times a few days ago. + +---------------------------------------- +Eric GAUDET <egaudet@in...> +Le 26-Dec-2000 a 02:08:48 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +[Dillo-dev]Dillo Weekly News + +From: adc <shark@bl...> - 2000-12-24 23:12 + +Hi, the latest Dillo Weekly News has been posted. +You can find it at +http://www.shark.pwp.blueyonder.co.uk/news/news231200.html +please note that the links to the archives aren't filled in yet as I can't +get connected to the sourceforge site, it looks like sadly the problems at +sourceforge are continuing, I will fill them in as soon as possible. + + +-- +adc + + + +Re: [Dillo-dev]Entity parsing in links + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-24 00:57 + +Hi, + +I'll reply this post even though I know some posts hasn't +arrived to my inbox (Is anyone else losing emails from the list?) + + +> On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote: +> > +> > * When HTML (4.0 or 4.1) was reformulated as a SGML +> > application, the entities-parsing problem sprung-in. It wasn't +> > there until this point. SGML say they MUST be parsed. And the URL +> > rfc says that characters MUST be escaped according to the context +> > in which they're used. +> > So, URLs may have entities in them, and we should parse +> > them. +> +> Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that +> have entities. Parsing entities in URLs would be a dire mistake. + +Once again: + +URLs don't have entities (as the URI/URL rfc say), but when +dealing with: + +<A HREF="> + +in a SGML context, "A" becomes an element "HREF" an atribute +and " the atribute value. + +Entities must be parsed inside atributes values. + +If you don't believe me, read [HTML 4.01 Appendix B 2.2] + +BTW: I just updated the home site and added a new link: MISC. +It will drive you to a handful of useful locations (including +docs, reading, etc; just click it!) + + +Finally, today I tried three times to upload the 0.3.1 version +to SourceForge, but it didn't work. Also checked the FTP incoming +directory and found a huge list of uploaded SW (guess there're +lots of people with the same problem). + + +Have a nice Christmas and hope to see you before 2001. +Jorge.- + + + +Re: [Dillo-dev]Bug #71 + +From: Livio Baldini Soares <livio@li...> - 2000-12-23 21:27 + +Jorge Arellano Cid writes: +> +> Hi, +> +> It seems I'm missing some emails from the list :( + +That's bad... You can always read from the archives: +http://www.geocrawler.com/lists/3/SourceForge/702/0/ Call me +suspicious, but I do that sometimes to check that I'm getting all +email. + +> I haven't seen this one (and some others) until quoted later. +> Sourceforge warned us that the mailing list was going to be moved +> with the respective downtime and glitches; just hope this not to +> continue... + +This was about a fix for bug #71 I +made. (http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff) + +<snip> + +> +> Well, I have the FTP-plugin code here in my machine, and is +> time to put some work on it. The problem I face is that my todo +> list is always bigger than the time I have, so the only solution +> is to work on a priority basis. + +Uhh... and I was *"almost"* finishing mine... (about 10% done ;-) +That's ok, I learned A LOT about Dillo's IO system! + +> I know some of you may have noticed that there're three BUGs in +> the bug-track (taken by me) that haven't had any progress in the +> past weeks. They were scheduled, but I spent lots of time fixing +> patches; please help me by designning & reviewing your patches +> carefully before submitting them, there's no better thing for a +> maintainer to receive than a clean patch that's just a skim away +> from integration. + +No stress man! 8^) +Just for curiosity, what types of mistakes come up? What kind of +reviewing to you wish us to perform to make your work easier? (I mean, +what are the most common errors?) +What I do is after making a patch, get a clean copy from CVS and apply +my patch to it, and see if everything ok... besides always strinving +to maintain clean codes. + + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis <sam@ma...> - 2000-12-23 20:30 + +On Sat, Dec 23, 2000 at 05:59:46PM -0200, Livio Baldini Soares wrote: +> Jorge Arellano Cid writes: +> > +> > Hi everyone! +> +> Howdy! +> +> <snip> +> +> > So, URLs may have entities in them, and we should parse +> > them. +> > +> > +> > This problem is BUG#114. +> +> Well in that case, a possible patch is at: +> http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff +> +> Humm. I've been thinking about this patch, and what it does is parse +> entities in ALL attributes strings. Does anybody know if THAT's +> correct or is entity parsing only allowed in URL's? (Don't mean to +> start another polemic ;-) + +Not specific to URLs at all, honestly! It is specific to attributes +containing literal character data, though, although we don't actually deal +with any others yet, I think. + +> +> bye! +> +> -- +> Livio <livio@li...> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +-- +Sam Dennis <sam@ma...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis <sam@ma...> - 2000-12-23 20:16 + +On Sat, Dec 23, 2000 at 01:14:10AM -0200, Livio Baldini Soares wrote: +> Eric GAUDET writes: +> > -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +> > Baldini Soares, le 23-Dec-2000 : +> +> <snip> + +<further snip> + +> PS: Just for the hell of it, I'm sending in a patch against today's +> 0.3.1 version that enables entity parsing in attributes... +> +> best regards to all, +> +> **************************************************************** +> --- dillo/src/html.c Fri Dec 22 23:45:10 2000 +> +++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000 +> @@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char * +> * 0 if value is bigger than datasize +> * (This code is complex, but avoids a second pass over the value --Jcid) +> */ +> -static gint Html_get_attr_value(const char *tag, gint tagsize, +> +static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize, +> char *data, gint datasize) +> { +> - gint i; +> + gint i, tagsize; +> + gchar *tag; +> + +> + tag = Html_parse_entities((gchar *)old_tag, old_tagsize); +> + tagsize = strlen(tag); +> +> if (tag[0] == '"'|| tag[0] == '\´ ) { +> /* copy to end quote or to datasize */ +> @@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch +> if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/') +> i--; +> } +> + +> + g_free(tag); +> +> if ( i < tagsize && i < datasize ) { +> *--data = '\0'; + +A bit messy, that would replace entites throughout the entire tag, which is +not desirable as not even every type (although we treat them the same for +now) of attribute allows entities. + +It would likely work in all cases (use of an ampersand elsewhere in tags +would be extremely uncommon, even though it is allowed), but that's not the +point. + +-- +Sam Dennis <sam@ma...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares <livio@li...> - 2000-12-23 19:59 + +Jorge Arellano Cid writes: +> +> Hi everyone! + +Howdy! + +<snip> + +> So, URLs may have entities in them, and we should parse +> them. +> +> +> This problem is BUG#114. + +Well in that case, a possible patch is at: +http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff + +Humm. I've been thinking about this patch, and what it does is parse +entities in ALL attributes strings. Does anybody know if THAT's +correct or is entity parsing only allowed in URL's? (Don't mean to +start another polemic ;-) + +bye! + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis <sam@ma...> - 2000-12-23 19:59 + +On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote: +> +> * When HTML (4.0 or 4.1) was reformulated as a SGML +> application, the entities-parsing problem sprung-in. It wasn't +> there until this point. SGML say they MUST be parsed. And the URL +> rfc says that characters MUST be escaped according to the context +> in which they're used. +> So, URLs may have entities in them, and we should parse +> them. + +Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that +have entities. Parsing entities in URLs would be a dire mistake. + +-- +Sam Dennis <sam@ma...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 13:02 + +Hi everyone! + + +Once upon a time ;-) there was BUG#95 (Entities parsing within +URLs) and now there's BUG#114 (basically the same), and a lot of +email and doc-research had been done. + +The fact is somewhat complicated and although I explained it +before, when re-reading my post I found it less clear to follow +than when writing it. +I hope this new explanation to be better... + + +* The URL (URI) RFCs don't say a word about entities. The only +escaping mechanism allowed there is hexadecimal (i.e. %xx +sequences). So according to this source, they MUST NOT be parsed. + +* Up to HTML 3.2 this wasn't an issue, so no clue was found +here (AFAIK). + +* When HTML (4.0 or 4.1) was reformulated as a SGML +application, the entities-parsing problem sprung-in. It wasn't +there until this point. SGML say they MUST be parsed. And the URL +rfc says that characters MUST be escaped according to the context +in which they're used. +So, URLs may have entities in them, and we should parse +them. + + +This problem is BUG#114. + + +Jorge.- + + + +RE: [Dillo-dev]Bug #71 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 13:02 + +Hi, + +It seems I'm missing some emails from the list :( +I haven't seen this one (and some others) until quoted later. +Sourceforge warned us that the mailing list was going to be moved +with the respective downtime and glitches; just hope this not to +continue... + +> -- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le +> 23-Dec-2000 : +> > Oh, since I've looked though all the IO code carefully, I was +> > thinking of adding a FTP handler in Dillo... do we have an interest +> > for adding this support? Is there any other method that anyone wants +> > supported? (Should I spend my time doing this stuff, or does anyone +> > think there are more "pressing" issues to finish first?). +> +> Adding ftp would be very nice and is a short term to-do. IMHO a decent +> web browser have to provide http:, file: and ftp: protocols. + +Well, I have the FTP-plugin code here in my machine, and is +time to put some work on it. The problem I face is that my todo +list is always bigger than the time I have, so the only solution +is to work on a priority basis. + +I know some of you may have noticed that there're three BUGs in +the bug-track (taken by me) that haven't had any progress in the +past weeks. They were scheduled, but I spent lots of time fixing +patches; please help me by designning & reviewing your patches +carefully before submitting them, there's no better thing for a +maintainer to receive than a clean patch that's just a skim away +from integration. + +Sincerely +Jorge.- + + + +[Dillo-dev][ANN] Html.testsuite updated + +From: Eric GAUDET <egaudet@in...> - 2000-12-23 09:29 + +Hi all, +assuming today's cvs version is the official v0.3.1, I tested it +against the Html.testsuite and updated the testsuite accordingly. + +http://www.rti-zone.org/dillo/ + +---------------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Dec-2000 a 18:27:38 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +RE: [Dillo-dev]Bug #71 + +From: Eric GAUDET <egaudet@in...> - 2000-12-23 07:28 + +-- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le +23-Dec-2000 : +> Oh, since I've looked though all the IO code carefully, I was +> thinking of adding a FTP handler in Dillo... do we have an interest +> for adding this support? Is there any other method that anyone wants +> supported? (Should I spend my time doing this stuff, or does anyone +> think there are more "pressing" issues to finish first?). +> + +Adding ftp would be very nice and is a short term to-do. IMHO a decent +web browser have to provide http:, file: and ftp: protocols. + +---------------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Dec-2000 a 16:23:20 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +[Dillo-dev]Bug #71 + +From: Livio Baldini Soares <livio@li...> - 2000-12-23 07:08 + +Hi there, + +I started to track down bug #71 today. It's the one that when you +have a HTML as the source of an image then that HTML title gets the +window's title. + +I spent more than an hour going over IO/MIME/Callback +code... Congratulations on whoever made this IO system, it's pretty +nice! Ok, then I finally found out what the problem was. After we make +the image request, when the document arrives there is a MIME lookup to +see which callback to use to handle the incoming stuff. If we have an +HTML then it's classified as text/html, which is ok. + +But the problem is that mime already calls text/html callback, which +is `a_Html_text()' (html.c). And then that will set the callback to +`Html_callback' and start "rendering" the HTML in the page (but we +don't see anything expect for the window's title changing), and we +were only expecting an image... + +The solution I've implemented is to verify in `a_Html_text' is the +DilloWeb->flags is actually a WEB_RootUrl, if it's not just bail out. + +For you guys that are "Dillo-oldies", is there anything wrong in +what I'm proposing? Should I initialize `html' in that function, waste +some time/space, but cleanly exit, or return NULL, saving that +time/space, but get a GTK_CRITICAL_ASSERT warning? Right now I chose +the first option. + +The patch is really small (3 lines of code), you can get at: +http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff +but I'm sending it below. + +Oh, since I've looked though all the IO code carefully, I was +thinking of adding a FTP handler in Dillo... do we have an interest +for adding this support? Is there any other method that anyone wants +supported? (Should I spend my time doing this stuff, or does anyone +think there are more "pressing" issues to finish first?). + + +Here is the patch against 0.3.1 version (CVS 22/December/2000): +********************** +diff -pru dillo/src/html.c dillo.new/src/html.c +--- dillo/src/html.c Fri Dec 22 23:45:10 2000 ++++ dillo.new/src/html.c Sat Dec 23 04:17:18 2000 +@@ -72,6 +72,13 @@ Dw *a_Html_text(const char *Type, void * +DilloWeb *web = P; +DilloHtml *html = Html_new(web->bw); + ++ if (!(web->flags & WEB_RootUrl)) { ++ /* Asked for non-RootUrl (image or other mime), and got an ++ text/html MIME type... just bail out and save our skin. */ ++ *Call = a_Cache_null_client; ++ return html->dw; ++ } ++ +*Data = (void *) html; +*Call = (CA_Callback_t) Html_callback; + +*************************** + + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares <livio@li...> - 2000-12-23 03:14 + +Eric GAUDET writes: +> -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +> Baldini Soares, le 23-Dec-2000 : + +<snip> +> +> That's not true at all : urls don't have entities parsing mecanism. The +> only parsing for urls is escaping with % HEX HEX. '&' is a reserved +> character for separating 'name=value' blocks in an url. +> Unfortunatly, a few sites use entities in their urls, and some browsers +> (nestcape at least) allow this (but netscape's entities parsing is +> admitedly broken). +> This issue have already been discussed a few weeks ago in the list, +> please read the archives for more details + +Oops your right! Really sorry about that. There are two messages in the +archive concerning that, seems that this was a deleted "bug" (#95): + +http://www.geocrawler.com/archives/3/702/2000/11/0/4658162/ +http://www.geocrawler.com/archives/3/702/2000/11/0/4701809/ + +I should of read the archives... I think I assumed the Sourceforge +wouldn't be wrong in making HTML... + +Jorge, when you have time, please delete bug #114 (the one I've +inserted). + +By the way, since version 0.3.1 is out, do you strip out the bugs +with smileys on them (the `done` fixes)? Or do you keep them on for a +while, so everyone knows hows Dillo's developing? + +PS: Just for the hell of it, I'm sending in a patch against today's +0.3.1 version that enables entity parsing in attributes... + +best regards to all, + +**************************************************************** +--- dillo/src/html.c Fri Dec 22 23:45:10 2000 ++++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000 +@@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char * +* 0 if value is bigger than datasize +* (This code is complex, but avoids a second pass over the value --Jcid) +*/ +-static gint Html_get_attr_value(const char *tag, gint tagsize, ++static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize, +char *data, gint datasize) +{ +- gint i; ++ gint i, tagsize; ++ gchar *tag; ++ ++ tag = Html_parse_entities((gchar *)old_tag, old_tagsize); ++ tagsize = strlen(tag); + +if (tag[0] == '"'|| tag[0] == '\´ ) { +/* copy to end quote or to datasize */ +@@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch +if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/') +i--; +} ++ ++ g_free(tag); + +if ( i < tagsize && i < datasize ) { +*--data = '\0'; +******************************************************** + +-- +Livio <livio@li...> + + + +[Dillo-dev]0.3.1 release + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-23 02:01 + +Hi, + +I tryed to make a new release today(dillo-0.3.1), but +sourceforge servers didn't work. They claim to be under DDOS +atacks and it seems to be true :-) + +I'll try again tomorrow. The new version is in the CVS though. + +Jorge.- + + + +Re: [Dillo-dev]Entity parsing in links + +From: Eric GAUDET <egaudet@in...> - 2000-12-23 01:40 + +-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +Baldini Soares, le 23-Dec-2000 : +> +> Sam Dennis writes: +>> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares +>> wrote: +> +> <snip> +> +>> > +>> > And that's exactly what Dillo sends, but Netscape, p.e, parses +>> > `&' into a `&'. So what is the correct action to perform? Is +>> > Dillo +>> > wrong or is Sourceforge wrong? +>> > +> +>> We're wrong, according to the specifications, character entities are +>> allowed +>> in attributes, and therefore '&' *must* be used in place of just +>> '&'. +>> +>> It's not just links, it's all string attributes. +>> +> + +That's not true at all : urls don't have entities parsing mecanism. The +only parsing for urls is escaping with % HEX HEX. '&' is a reserved +character for separating 'name=value' blocks in an url. +Unfortunatly, a few sites use entities in their urls, and some browsers +(nestcape at least) allow this (but netscape's entities parsing is +admitedly broken). +This issue have already been discussed a few weeks ago in the list, +please read the archives for more details + +> Thanks for looking this up Sam! +> +> I've put in the bug in the bug-track, it's bug #114. I've already +> assigned it to me ;^) I'll get to it after Christmas probably. +> +> PS: Jorge, how you doing with 0.3.1 version? Will it come out +> before +> Christmas? Hope so! +> +> best regards to all, +> +> -- +> Livio <livio@li...> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Dec-2000 a 10:36:02 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares <livio@li...> - 2000-12-23 00:09 + +Sam Dennis writes: +> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote: + +<snip> + +> > +> > And that's exactly what Dillo sends, but Netscape, p.e, parses +> > `&' into a `&'. So what is the correct action to perform? Is Dillo +> > wrong or is Sourceforge wrong? +> > + +> We're wrong, according to the specifications, character entities are allowed +> in attributes, and therefore '&' *must* be used in place of just '&'. +> +> It's not just links, it's all string attributes. +> + +Thanks for looking this up Sam! + +I've put in the bug in the bug-track, it's bug #114. I've already +assigned it to me ;^) I'll get to it after Christmas probably. + +PS: Jorge, how you doing with 0.3.1 version? Will it come out before +Christmas? Hope so! + +best regards to all, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis <sam@ma...> - 2000-12-22 21:30 + +On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote: +> Hi yall, +> +> I'm not sure this is a Dillo bug yet, so that's why I haven't added +> it to the bug-track. Does any one know if entities (like > +> &) are supposed to be parsed in links (<a href=XXX>). +> +> I was browsing through Dillo's CVS, looking in the Changelog, at: +> http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo +> +> And I clicked on `annotate` for revision 1.19, then I got an +> error. If you look at that page's source you can see that the link is: +> <a href="/cgi-bin/cvsweb.cgi/dillo/ChangeLog?annotate=1.19&cvsroot=dillo">annotate</a> +> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +> +> And that's exactly what Dillo sends, but Netscape, p.e, parses +> `&' into a `&'. So what is the correct action to perform? Is Dillo +> wrong or is Sourceforge wrong? +> +> best regards, +> +> -- +> Livio <livio@li...> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +We're wrong, according to the specifications, character entities are allowed +in attributes, and therefore '&' *must* be used in place of just '&'. + +It's not just links, it's all string attributes. + +-- +Sam Dennis <sam@ma...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares <livio@li...> - 2000-12-22 03:07 + +Hi yall, + +I'm not sure this is a Dillo bug yet, so that's why I haven't added +it to the bug-track. Does any one know if entities (like > +&) are supposed to be parsed in links (<a href=XXX>). + +I was browsing through Dillo's CVS, looking in the Changelog, at: +http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo + +And I clicked on `annotate` for revision 1.19, then I got an +error. If you look at that page's source you can see that the link is: +<a href="/cgi-bin/cvsweb.cgi/dillo/ChangeLog?annotate=1.19&cvsroot=dillo">annotate</a> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +And that's exactly what Dillo sends, but Netscape, p.e, parses +`&' into a `&'. So what is the correct action to perform? Is Dillo +wrong or is Sourceforge wrong? + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Modularization(?) in Dillo + +From: Livio Baldini Soares <livio@li...> - 2000-12-18 17:17 + +Hi Eric, + +Eric GAUDET writes: +> I've been thinking about that some times ago. What I wanted to do is to +> make a single bookmars menu attached the menubar of each browser +> window, but it seems to be impossible to attach a menu more than once +> in gtk, right ? + +Yes that's right! That's the whole problem with the bookmark menu +issue. You can't attach the same menubar to more than one menu... the +solution will have to be to create a new menubar widget... ok. But +current `Bookmarks_goto_bookmark` (the callback from choosing a +particular bookmark menuitem), sees if the selected widget is equal to +the first created one... that won't work. A fix for this would be to +pass the widget's index from `DilloBookmark bookmark[]`. + +But then we get another problem, we also need the browserwindow, or +else we won't know which *bw should we give to a_Nav_push(). + +So we need to pass the callback two arguments, but GTK only supports +callbacks with one argument (actually two, but the first you don't +choose, it's always the GTK_OBJECT which generated the event +signal). The solution GTK recommends for this (which is the obvious +one), is to create a struct with the desired fields and pass a pointer +to the struct. + +That's what I'm doing now (actually, I'm not since I'm in the middle +of final exams and they're *killing* me...), but I'll get to it at the +end of this week. That's why I'm was asking about where to place the +struct. + +So does `put it in bookmark.c` win? + +PS: What about the make new window the same size as the current one? +Did you finally get to resolving that? + +see yall, + +-- +Livio <livio@li...> + + + +RE: [Dillo-dev]Modularization(?) in Dillo + +From: Eric GAUDET <egaudet@in...> - 2000-12-18 12:09 + +I've been thinking about that some times ago. What I wanted to do is to +make a single bookmars menu attached the menubar of each browser +window, but it seems to be impossible to attach a menu more than once +in gtk, right ? + +-- En reponse de "[Dillo-dev]Modularization(?) in Dillo" de Livio +Baldini Soares, le 18-Dec-2000 : +> +> Hi all, +> +> I'm working on bug #110 (the bookmarks menu not appearing in +> new window) and was checking for the best way to fix this. I figured +> that all have to create a struct with a pointer to a menuitem (or an +> array index) and a pointer to the bw, and pass that struct to the +> callback (it really doesn't matter for now). What I want to get to, +> is +> where should I put (define) this new struct? +> +> I've seen that DilloBookmark is defined in browser.h, but should it +> be there at all? Because that's a struct that has no interest for the +> other modules, not even BrowserWindow, it is only used in +> bookmark.c. Since no other module should know, or need to know, what +> is a DilloBookmark, I suggest we take it out of browser.h and put it +> in bookmark.h (and I even dare say bookmark.c). And the struct that +> I'll create? I guess it should go in bookmark.c, since it is not +> interesting for other modules including bookmark.h to know? Or should +> I put it in bookmark.h, for cleanliness sake? +> + +I'll go for everything in bookmark.c, since it's not needed outside. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 18-Dec-2000 a 21:05:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Cookies + +From: Eric GAUDET <egaudet@in...> - 2000-12-18 12:04 + +-- En reponse de "Re: [Dillo-dev]Cookies" de Livio Baldini Soares, le +18-Dec-2000 : +>> How to +>> manage persistant cookies, what kind of power the user should have +>> over +>> them, including, of course, denial of cookies, etc. +> +> +... +> Netscape 6, for example, has a type of "cookie manager", where you +> can define a rule (accept always, accept never) for each separate +> URL. I thought it very good. So I enabled cookies from sourceforge +> and +> disabled for the rest of the world... +> +> I would like Dillo to have something similar, a "cookie manager" +> with flexible rules for accepting/denying cookies for diferent +> sites. Maybe this manager could be integrated as a plugin... +> +> Any ideas? +> + +That would be very nice. What about a cookierc (text) file containing +all the rules (each line being a rule for an URL). I volunteer to code +a plugin for the manager (once the cookierc specs are decided). + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 18-Dec-2000 a 20:59:06 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Modularization(?) in Dillo + +From: Livio Baldini Soares <livio@li...> - 2000-12-18 11:15 + +Hi all, + +I'm working on bug #110 (the bookmarks menu not appearing in +new window) and was checking for the best way to fix this. I figured +that all have to create a struct with a pointer to a menuitem (or an +array index) and a pointer to the bw, and pass that struct to the +callback (it really doesn't matter for now). What I want to get to, is +where should I put (define) this new struct? + +I've seen that DilloBookmark is defined in browser.h, but should it +be there at all? Because that's a struct that has no interest for the +other modules, not even BrowserWindow, it is only used in +bookmark.c. Since no other module should know, or need to know, what +is a DilloBookmark, I suggest we take it out of browser.h and put it +in bookmark.h (and I even dare say bookmark.c). And the struct that +I'll create? I guess it should go in bookmark.c, since it is not +interesting for other modules including bookmark.h to know? Or should +I put it in bookmark.h, for cleanliness sake? + +bye yall, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Cookies + +From: Livio Baldini Soares <livio@li...> - 2000-12-18 10:47 + +Hello Sam, + +Sam Dennis writes: +> I seem to remember someone mentioning haved worked on, or at least having +> thought about, cookies in dillo. I'd like to bring it up again, as this +> seems like a good time to start thinking about implementing them. How to +> manage persistant cookies, what kind of power the user should have over +> them, including, of course, denial of cookies, etc. + + +I personally really dislike cookies. I only accept them when they're +really necessary for some service (like when `logging in` at +Sourceforge's web site). I would really like a finer control over +ccokies than what Netscape 4.X gives me. + +Netscape 6, for example, has a type of "cookie manager", where you +can define a rule (accept always, accept never) for each separate +URL. I thought it very good. So I enabled cookies from sourceforge and +disabled for the rest of the world... + +I would like Dillo to have something similar, a "cookie manager" +with flexible rules for accepting/denying cookies for diferent +sites. Maybe this manager could be integrated as a plugin... + +Any ideas? + +-- +Livio <livio@li...> + + + +[Dillo-dev]A few answers + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-17 17:48 + +Hi, + +Dillo 0.3.1 is almost ready for a release; most probably by +December 22. It is a very nice upgrade, you'll appreciate... +In the mean time, SourceForge made the move to their new +servers, but the download counters problem remain :( Just checked +a few projects and no one got their file-hits right... Anyway, +dillo-0.3.1 will be there before Christmas. + + +Jorge.- + +----- +[Bruno] + +> I have a rather small monitor, and for my taste dillo +> displays text in a fontsize too small. It would be nice if +> you could change fonts/fontsizes in the ~/.dillo/dillorc file. +> ... + +Sometime ago Sebastian suggested a font-factor; that's a very +good idea to implement. A single number in dillorc that scales +font sizes (a flash skim through html.c showed that you'll have +to search some hard coded font-size numbers within the code to +implement it; not hard though!). + +----- +[Cookies] + +J=F6rgen submitted a patch a long time ago. It's not complete and +the unimplemented part is the cookie sending one. This patch has +been procrastinated due to: + +a) priorities +b) the url-passing scheme needs a new implementation + +Currently, POST and GET do some url-string hacking to get their +data to the IO part, and then to the remote server. Cookies need +to send some information too, and the same happens with +authentication. + +This is basically a matter of defining a Url structure and +passing it to a lot of functions. The complex part is that +there're lots of functions that expect a URL string, there're +several workarounds, some hacks also, and last but not the least: +dillo's code is very tight and dependent on URLs (they are used +as primary Keys in the cache for instance, and several decisions +are being made in the URL passing chain from one module into +another). + +Ah, there's also the problem of URL normalization in between. + +---- +[Patches] + +Please send them with 'diff -pru', that makes it easier for me. + + + +[Dillo-dev][ANN] Dillo-pluginsin PHP + +From: Eric GAUDET <egaudet@in...> - 2000-12-17 13:50 + +Hi folks, +I just posted "a Dillo-plugin for using PHP to build applications using +the Dillo-plugins mechanism. This is really a wrapper to PHP compiled +as CGI, not an Apache module. (enclosed in the archive a sample php +application, and hints for compiling PHP)" + +http://www.rti-zone.org/dillo/ + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 17-Dec-2000 a 22:45:21 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Fontsize + +From: Bruno Widmann <bwidmann@ut...> - 2000-12-15 15:27 + +Hi, + +I have a rather small monitor, and for my taste dillo +displays text in a fontsize too small. It would be nice if +you could change fonts/fontsizes in the ~/.dillo/dillorc file. + +I had a look around the sources, and found that in html.c +the fontsize seems to be hardcoded. + +in Html_page_check there is + +font.size = 12; + +and in Html_tag_open_h there is + +gint sizes[] = {24, 18, 18, 14, 12, 10} + +which sets fontsizes for text under <H1> - <H6> + +I have allready played around with prefs.c/h and it's quite +simple to add config items there so that you can change these values +via dillorc. + +But I don't know if this is the "right way" to do it. +Or maybe thers something else planed for fonthandling? If it's ok +to add these values to the configfiles i could submit a patch. + + + +[Dillo-dev]Cookies + +From: Sam Dennis <sam@ma...> - 2000-12-14 22:37 + +I seem to remember someone mentioning haved worked on, or at least having +thought about, cookies in dillo. I'd like to bring it up again, as this +seems like a good time to start thinking about implementing them. How to +manage persistant cookies, what kind of power the user should have over +them, including, of course, denial of cookies, etc. + +-- +Sam Dennis <sam@ma...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]SourceForge downtime + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-14 12:24 + +Hi, + +There's a downtime scheduled to Friday December 15, it will +affect: Web site, CVS, mailing lists and mailing aliases. + +You have been warned... :-) + +Jorge.- + + + +[Dillo-dev]Bug #109 <font> tag + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-12 12:17 + +Hi, + + +Please note that when making the bug-track entry for FONT +tags, Livio did the right thing (according to the rules); even +more, when he finally found out that there was someone else +working on it, he apologized gently (even though it was not his +fault), and offered his help. --meus parabêns pro senhor. + +BUGs are not owned: there's a explicit recommendation to those +interested in helping the developer that first took them, to +contact him and to offer any help. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #109 (<font> tag) + +From: Livio Baldini Soares <livio@li...> - 2000-12-12 05:55 + +Sean 'Shaleh' Perry writes: + +> > +> > Would you like me to change the bug-track entry so that the being +> > `worked on` field points to you? (Of course, you can do it yourself if +> > you want, it's but #109). +> > +> +> I thought I was marked somewhere on that. WIll make sure I own 109. + +Ok, I've done this for you. I put in the `Being worked by:` field +with value "shaleh@vi...". You can change that or add more info in +the volunteering page (http://dillo.so....net/Dvolunteer.html). + +Sorry again for the mix-up, + +best regards, + +-- +Livio <livio@li...> + + + +[Dillo-dev]html tag implementations + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:25 + +Would anyone who has added support for an unsupported tag please mail me your +patches. I see several new bugs where people claim to have implemented +some new tag. I would like to integrate that work with my own. + + + +RE: [Dillo-dev]Bug #109 (<font> tag) + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:24 + +> +> I think Sean made a patch for all font stuff. He should have made a +> bugtrack entry too :-/ +> + +yeah, i should use the bug engine more, I just hate it, sorry Jorge. It does +not order the items at all, I can not easily find new items for old ones, or do +many other things I am used to from a bug tracking system. Why not use the +sourceforge one? Or something, anything. + + + +Re: [Dillo-dev]Bug #109 (<font> tag) + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:20 + +> +> Would you like me to change the bug-track entry so that the being +> `worked on` field points to you? (Of course, you can do it yourself if +> you want, it's but #109). +> + +I thought I was marked somewhere on that. WIll make sure I own 109. + + + +RE: [Dillo-dev]Bug #109 (<font> tag) + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-11 21:19 + +On 10-Dec-2000 Livio Baldini Soares wrote: +> Hi yall, +> +> I've included bug #109 into the bug-track, when I was looking at a +> teacher's page when I noticed that some colored text wasn't colored +>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> + +hmm, how many mails have I sent saying I had font (and most other font +touching) tags working quite nicely (-: Would you mind sending me your +patch so I could integrate your work. + +Jorge asked me to keep my html cleanups until after Sebastian releases his Dw +widget. + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares <livio@li...> - 2000-12-10 20:30 + +Hellos, forgot to mention something... + +Livio Baldini Soares writes: + +<BIG snip> + +> The patch is in: +> http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff +> +> If you want I can e-mail it to you personally, so I wouldn't +> generate extar traffic on the list. Hope this helps you on what you're +> doing. + +This pacth is to be applied against current CVS version +(Dec-10). Jorge uploaded a new version (yesterday), and those changes +are necessary for this patch to work. + + +that's all, bye, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Bug #109 (<font> tag) + +From: Livio Baldini Soares <livio@li...> - 2000-12-10 18:32 + +Eric GAUDET writes: +> -- En reponse de "[Dillo-dev]Bug #109 (<font> tag)" de Livio Baldini +> Soares, le 10-Dec-2000 : +> > Hi yall, +> > +> > I've included bug #109 into the bug-track, when I was looking at a +> > teacher's page when I noticed that some colored text wasn't colored +> >:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> > +> +> I think Sean made a patch for all font stuff. He should have made a +> bugtrack entry too :-/ + +Oops! Sorry for the mix up, you're right. I checked the mailing +archives and seems like Sean has being doing font stuff for some time +now... Sorry abou that Sean! + +Would you like me to change the bug-track entry so that the being +`worked on` field points to you? (Of course, you can do it yourself if +you want, it's but #109). + +I'll discontinue with my version, since your's is probably much +better, and you have been in to this much longer than I. + +> +> About SIZE, each browser is free to render it as it likes, so your idea +> of multiplying by 4 is good. +> Let me propose something : make new dillorc parameters for these (say +> default_font_size and default_font_step) +> + +Good idea. + +> As for FACE, Jorge doesn't like it, and I agree with him on this point +> : html is for client-side rendering, the author is not supposed to use +> his own fonts. We choosed (so far) to ignore it. + +Hum... strange. But surelly Dillo will have an option +`Render it just like the author intended to be', will it not? I mean, +it's really nice to have a very flexible rendering system, so the +client can do all his heart's will, but sometimes the client's heart's +is willing to see it like the author intended... and then you'd be +taking away flexibility... + +*yeah my english sucks! Did you understand a word I said?* + +> (BTW number 1 to 7 is 7 font sizes, not 8 ;-) + +Oops... I guess I should catch up on my sleep :-o + +<snip> +> > checking if all chars are valid hex digits [0-9a-fA-F]. Any body +> > know someway better to do this? +> > +> +> If you check first for named colors, then your hex 6-digits scan, +> you're good. +> ("0x" is not in HTML specs, only "#") + +Like Homer would say: "DOPE" (tap on the head!) Of course! + + +bye all, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares <livio@li...> - 2000-12-10 18:18 + +Hi Eric, + +before anything I would like to say that I really don't want to +start arguments or flames or anything like that... I just want to help +you out, like you've always done for me. So sorry if I still disagree +with you, but I think this kind of stuff is worth discussing so that +we ALL can learn from (specially me, who knows too little...). If I'm +being a pest about this issue, let me know and I'll drop it, ok? + +With that said let's get to more interesting issues ;-) + +Eric GAUDET writes: + +<big snip> + +> > What do you need this info (focused window) for? Could you use the +> > solution I've made for your problem too? Maybe I can help out... +> > +> +> Well, that's actually why I made this proposal : your solution can't be +> applied to my problem ;-) +> But I though mine would solve both (and probably more) at the same time, +> so it can have some good in it. +> +> (since your want more infos, I needed to know the size and position of +> the window that was clicked to open a new window and smartly adjust its +> geometry) + +Ok, I've thought a little bit more about this and I think that both +solutions are ok. But my solution seems easier for bug #96 and your +solution to the "opening new same sized window" problem (or maybe +not... read on). + +Let me see if I understand correctly this problem ... To use my +solution on to implement this you'll have to connect a signal to a +callback with two arguments: (1 = the clicked link, 2= the clicked bw, +to extract the size). But this is already handled in +Dw_page_handle_event... and then it calls +a_Commands_open_link_nw_callback with the bw that was CLICKED by the +user... (isn't this what you wanted?). So, theoretically, all you'd +have to is get the size from the `bw` in +a_Commands_open_link_nw_callback and pass it to a modified +a_Interface_new_browser_window which takes the size as arguments... + +Sorry, if am still missing the point... but it still seems needless +to have the last_clicked_bw. I think it is totally feasible to use my +solution... hum, let me see... + +<Sometime passes .... > + +Ok, I have a patch here that opens new windows the same size as the +parent window the call came from (wether from the menu `New Window`, +or clicking with button 2, or clicking with button 3 and selecting +`Open Link in new window`). Are looking to this something similar? + +The patch is in: +http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff + +If you want I can e-mail it to you personally, so I wouldn't +generate extar traffic on the list. Hope this helps you on what you're +doing. + +> +> I understand, and I would agree on this. Most of the time. But real life +> coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_ +> time_fixing_many_similar_problems" kind of guy ;-) + +Yeah, you might be right, I lack lots of expericence. I'm still a +newbie at this open source programming stuff, and you guys are my +"gurus". So don't ever hesitate to say that I'm doing something wrong, +or being too stubborn, chances are, I'm completely wrong about what +I'm saying. + +later dude! + +-- +Livio <livio@li...> + + + +RE: [Dillo-dev]Bug #109 (<font> tag) + +From: Eric GAUDET <egaudet@in...> - 2000-12-10 08:00 + +-- En reponse de "[Dillo-dev]Bug #109 (<font> tag)" de Livio Baldini +Soares, le 10-Dec-2000 : +> Hi yall, +> +> I've included bug #109 into the bug-track, when I was looking at a +> teacher's page when I noticed that some colored text wasn't colored +>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> + +I think Sean made a patch for all font stuff. He should have made a +bugtrack entry too :-/ + +> 1) `size=absolute' or `size=[+-]relative'. +> What W3 says is that we should accept 8 font sizes (numbered from +> 1-7), but in Dillo we have more granularity, ending up with more +> numbered sizes (at least 24, which is in the <h1> tag). So how should +> I deal with this? In my patch I multiply html size value by 4, giving +> us Dillo size value... of course this isn't the "right" way to +> convert from font numbering. Anybody has any ideas? +> + +About SIZE, each browser is free to render it as it likes, so your idea +of multiplying by 4 is good. +Let me propose something : make new dillorc parameters for these (say +default_font_size and default_font_step) +As for FACE, Jorge doesn't like it, and I agree with him on this point +: html is for client-side rendering, the author is not supposed to use +his own fonts. We choosed (so far) to ignore it. +(BTW number 1 to 7 is 7 font sizes, not 8 ;-) + +> 2) a_Color_parse issues... +> +> There are two issues which I've encountered: +> +> i) color="Aqua" doesn't resolve to anything! It should resolve to +> "aqua" == 0x00ffff, shouldn't it? This issue seems to me like a +> Dillo bug... To fix this I changed all words to their lower-case +> representation. I did this with: +>> for (i = 0; i < strlen(subtag); i++) +>> subtag[i] = tolower(subtag[i]); +> Is there a better/more efficient way of doing this? +> + +Unfortunatly not. + +> ii) color="ff00aa" +> To read a color as a hex number Dillo requires a "0x" or "#" +> prefix, but I've found many html's with just color="56abf3", or +> something like this. Currently, to fix this, I did something +> TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only +> real fix which I thought of was to run over `subtag' string +> checking if all chars are valid hex digits [0-9a-fA-F]. Any +> body +> know someway better to do this? +> + +If you check first for named colors, then your hex 6-digits scan, +you're good. +("0x" is not in HTML specs, only "#") + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Dec-2000 a 16:03:49 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Bug #109 (<font> tag) + +From: Livio Baldini Soares <livio@li...> - 2000-12-10 05:43 + +Hi yall, + +I've included bug #109 into the bug-track, when I was looking at a +teacher's page when I noticed that some colored text wasn't colored +:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: + +#if 0 +<some_stuff> +#endif +Html_push_tag(...) + +Does anyone know/remember why this was commented out? Well it didn't +work anyway, so I started to see if I could get the <font> tag +working. After sometime I got a pretty good working version (it still +has a small render bug, but I think it's pretty much working). I +checked http://www.w3.org to see the qualifiers for the tag <font>, they are: +`face', `size' and `color'. So those are the one I've implemented. + +The current patch is in: +http://www.linux.ime.usp.br/~livio/dillo/font_tag.diff + +It will corretly render HTML like: +http://www.rti-zone.org/dillo/Html.testsuite/color.html +or +http://www.linux.ime.usp.br/~livio/dillo/font-test.html + + +The patch will change two files: src/html.c and src/colors.c. +There is are two small issues that are pending so I can get this patch +100% done. + +1) `size=absolute' or `size=[+-]relative'. +What W3 says is that we should accept 8 font sizes (numbered from +1-7), but in Dillo we have more granularity, ending up with more +numbered sizes (at least 24, which is in the <h1> tag). So how should +I deal with this? In my patch I multiply html size value by 4, giving +us Dillo size value... of course this isn't the "right" way to convert +from font numbering. Anybody has any ideas? + +2) a_Color_parse issues... + +There are two issues which I've encountered: + +i) color="Aqua" doesn't resolve to anything! It should resolve to +"aqua" == 0x00ffff, shouldn't it? This issue seems to me like a +Dillo bug... To fix this I changed all words to their lower-case +representation. I did this with: +> for (i = 0; i < strlen(subtag); i++) +> subtag[i] = tolower(subtag[i]); +Is there a better/more efficient way of doing this? + +ii) color="ff00aa" +To read a color as a hex number Dillo requires a "0x" or "#" +prefix, but I've found many html's with just color="56abf3", or +something like this. Currently, to fix this, I did something +TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only +real fix which I thought of was to run over `subtag' string +checking if all chars are valid hex digits [0-9a-fA-F]. Any body +know someway better to do this? + +I think that's all my doubts for now... and ideas/critics/support +are always supported, + +bye, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Bug #96 + +From: Eric GAUDET <egaudet@in...> - 2000-12-10 03:41 + +-- En reponse de "Re: [Dillo-dev]Bug #96" de Livio Baldini Soares, le +09-Dec-2000 : +>> BrowserWindow *topmost_bw; +>> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. +>> +>> Any thought ? +> +> Humm.. this could work too. But I think this solution is a little +> more complex. + +I don't quite see how a 3 lines-patch can be complex. + +> Not necessarilly, in all window managers/systems, does +> clicked == focused. I think we might have a long and tiresome battle +> to get all the cases where the window is focused, so the topmost_bw +> is always correct and accurate. + +Hum, you noticed the question mark. We could change the name for +last_clicked_bw, if you think it's less confusing. +What we really need is CLICKED, so our popup menus (which can be used +only when _click_ing) know what bw we're talking about. + +> I don't know, but it seems too tricky to get this to work out, and +> maybe "unclean"... +> + +*cough* +"unclean" is a dangerous concept : it makes you think the code is more +important that the application. +"maybe unclean" is even worse : it makes you think the same while +admitting you didn't investigate the problem. + +(don't get me wrong : I'm not advocating dirty-but-cool hacks, I'm more +like Jorge's "don't over-optimize" topic) + +> What do you need this info (focused window) for? Could you use the +> solution I've made for your problem too? Maybe I can help out... +> + +Well, that's actually why I made this proposal : your solution can't be +applied to my problem ;-) +But I though mine would solve both (and probably more) at the same time, +so it can have some good in it. + +(since your want more infos, I needed to know the size and position of +the window that was clicked to open a new window and smartly adjust its +geometry) + +> Sorry for the mean critic... but I think college has made me into a +> "avoid_global_variables,_they_will_give_you_trouble_in_the_future" +> kind of guy ;-) +> + +I understand, and I would agree on this. Most of the time. But real life +coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_ +time_fixing_many_similar_problems" kind of guy ;-) + +> best regards, +> + +likewise, +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Dec-2000 a 12:23:43 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Comments + +From: Eric GAUDET <egaudet@in...> - 2000-12-10 03:18 + +-- En reponse de "[Dillo-dev]Comments" de Jorge Arellano Cid, le +09-Dec-2000 : +> you'll notice in the Changelog that almost no patch got clean into +> the sources, I had to rework most of them; please be more careful +> before submitting. +> + +Can you tell us what are the common errors, so we can be more careful ? + +> ---- +> Checkboxes [Eric] +> +> Have you checked what the Specs say about it? +> + +VALUE is a requiered attribute for CHECKBOXES (and RADIO). We're talking +here about how to deal with faulty tag missing requiered attributes, +which is not uncommon in web pages. +Browsers have a different behavior : +- Dillo sends "name=" +- Netscape and Amaya send "name=on" +- Opera sends nothing (but renders the checkbox, which is the worse case +IMHO) +- (IE not tested) + +PS: another FORM related issue : the SUBMIT button's value is not +POSTed by Dillo. It should. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Dec-2000 a 12:02:55 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: Comments (more on GIF bug 98) + +From: Livio Baldini Soares <livio@li...> - 2000-12-10 02:15 + +Livio Baldini Soares writes: +> Jorge Arellano Cid writes: + +<big snip> + +> > ---- +> > GIF spec [Livio]: +> > +> > http://www.w3.org/Graphics/GIF/spec-gif89a.txt +> > (thanks for checking) +> +> Oh, should of looked in w3! Thanks, I'll check it later. +> + +Well I check it out. It *seems* to me that the coordinates from the +Logical Screen Descriptor are in fact ignorable, but I'm not +absolutely sure. Here is the part that matters from the GIF +specification: + +************************************** +> 18. Logical Screen Descriptor. +> +> a. Description. The Logical Screen Descriptor contains the parameters +> necessary to define the area of the display device within which the +> images will be rendered. The coordinates in this block are given with +> respect to the top-left corner of the virtual screen; they do not +> necessarily refer to absolute coordinates on the display device. This +> implies that they could refer to window coordinates in a window-based +> environment or printer coordinates when a printer is used. +************************************** + +Virtual-screen? Printer? It seems to me that it's ignorable, and we +can really just rely on the coordinates from the Image +Descriptor. Here's the spec info on the Image Descriptor: + +************************************** +> 20. Image Descriptor. +> +> +> a. Description. Each image in the Data Stream is composed of an Image +> Descriptor, an optional Local Color Table, and the image data. Each +> image must fit within the boundaries of the Logical Screen, as defined +> in the Logical Screen Descriptor. +> +> The Image Descriptor contains the parameters necessary to process a +> table based image. The coordinates given in this block refer to +> coordinates within the Logical Screen, and are given in pixels. This +> block is a Graphic-Rendering Block, optionally preceded by one or more +> Control blocks such as the Graphic Control Extension, and may be +> optionally followed by a Local Color Table; the Image Descriptor is +> always followed by the image data. +************************************* + +Well can anybody who's a better english speaker and has more image +knowledge tell me if I'd doing something wrong in ignoring the Logical +Screen Descriptor's coordinates? I think it's okay, specially after +reading this spec and reading xloadimage-4.1 source code (it ignores +it too). + +If there are no objections, then the patch I have completely fixes +bug #98.. just have to clean it up a bit before sending it in... + +Any feedback is appreciated, best regards to all, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Comments + +From: Livio Baldini Soares <livio@li...> - 2000-12-09 19:47 + +Jorge Arellano Cid writes: +> +> Hi, + +Hi Jorge! + +Nice work. I've seen that you've updated CVS versions twice after +the 0.3.0 release. That's really nice, cause we can see dillo change +dinamically and not in big jumps like before, hope you keep this +up. If you do intend to keep updating CVS with certain frequency, then +may I suggest a dillo-cvs-log@so...? I don't know how it's +done, but I've seen other projects do this, and I thoght it really +neat. Everytime someone (you) makes a CVS check-in, then the list +(dillo-cvs-log) receives an e-mail with the the list of modified files +and your log message, what do you think? If you like the idea, but +don't know how to do it, I can try and read the sourceforge manuals +for you and see if I discover something. + +<snip> + +> ---- +> GIF spec [Livio]: +> +> http://www.w3.org/Graphics/GIF/spec-gif89a.txt +> (thanks for checking) + +Oh, should of looked in w3! Thanks, I'll check it later. + +> +> Ah, have you finished BUG#96? The bug-track shows 90% and its +> already integrated into my source tree! + +It's not 90% anymore ;-) Yes I have finished! I put 90% cause I was +waiting to hear back from anybody to see if my bug fix was good +enough... but thinking it over for a week now, I couldn't come up with +anything better design, so I think it's good enough. I haven't changed +anything so the version you integrated is probably up-to-date. + + +> ---- +> Weekly news [Allan] +> +> Huh? :-) + +Yeah, where are you Allan? Hope that everything's okay with +you... (or hope you're travelling trough the world, meeting lots of +beatiful girls, and that's why you're kind of gone). I miss those +weekly news! + +bye yall, + +-- +Livio <livio@li...> + + + +[Dillo-dev]Comments + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-09 19:17 + +Hi, + + +Well, it seems that dillo is getting better and improving +faster than before. The patch queue is also being flooded at a +higher rate and from different persons. I'm very happy with this, +and also spent a lot of time integrating the patches; you'll +notice in the Changelog that almost no patch got clean into the +sources, I had to rework most of them; please be more careful +before submitting. + +Maybe that's due to what I call "the rush effect": when a +developer gets into a coding task and hasn't made the entry in +the bug track, he gets eager to finnish before any one else does. +Please avoid this situation (Yes, I received repeated patches, +and had to make some bug-track-entries myself to stop it). + +On the other hand, the big patch queue was very interesting +and after integration has made --no doubt!-- a better dillo; +Thanks everybody. + +Yes, there's enough material for making a new release, I just +want to test it some more, add a few improvements, wait for +sourceforge's counters to start working again and it'll be there. + + +Jorge.- + + +---- +GIF spec [Livio]: + +http://www.w3.org/Graphics/GIF/spec-gif89a.txt +(thanks for checking) + +Ah, have you finished BUG#96? The bug-track shows 90% and its +already integrated into my source tree! + + +---- +Checkboxes [Eric] + +Have you checked what the Specs say about it? + + +---- +Weekly news [Allan] + +Huh? :-) + + + +Re: [Dillo-dev]Bug #96 + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-12-09 18:03 + +Livio Baldini Soares writes: +> [...] +> Humm.. this could work too. But I think this solution is a little +> more complex. Not necessarilly, in all window managers/systems, does +> clicked == focused. I think we might have a long and tiresome battle +> to get all the cases where the window is focused, so the topmost_bw is +> always correct and accurate. I don't know, but it seems too tricky to +> get this to work out, and maybe "unclean"... + +Not necessary. There are simpler ways to check which window is +focused, but in this case, you indeed want to get the last window the +user had clicked into, not the focus window (and a window manager +*does not need* to focus this window). Another way would be to store +the browser window belonging to the page into the popup menu, just +before popping it up. + +However, I'd prefer Livius' implementation, there is really no need +to make the code kludgier as needed just to save little memory +(compared to the memory anyway allocated for a browser window). + +> What do you need this info (focused window) for? Could you use the +> solution I've made for your problem too? Maybe I can help out... +> +> Sorry for the mean critic... but I think college has made me into a +> "avoid_global_variables,_they_will_give_you_trouble_in_the_future" +> kind of guy ;-) + +The college had reasons for it. ;-) + +Sebastian + + + +[Dillo-dev]About bug #98 (GIF especification?) + +From: Livio Baldini Soares <livio@li...> - 2000-12-09 17:02 + +Hi all! + +Since I went trough the png test suite, I couldn't help noticing the +http://www.rti-zone.org/dillo/Html.testsuite/badgif.html, where +there's a gif that's not drawn correctly. I've found the problem and +made a patch to fix this, but I'm not sure I'm doing the "correct" +thing to fix it... but my fix doesn't seem to break any other GIFs. + +The problem is that gif->width and gif->height are supposed to be +read from 2 distinct places. From the Logical Screen Descriptor +(where: +gif->Width = LM_to_uint(buf[0], buf[1]); +gif->Height = LM_to_uint(buf[2], buf[3]); +) + +*and* from the Image Descriptor +(where: +gif->Width = LM_to_uint(buf[4], buf[5]); +gif->Height = LM_to_uint(buf[6], buf[7]); +) + +Currently Dillo is only reading it's width and height from the +Logical Screen Descritor. I've checked sources from gif2png and +xloadimage (xview), and they seem to respect only the Image Descriptor +width and height, and almost ignore and coordinates from Logical +Screen Desc (which is kind of strange). So what I've done is just +that, I don't call a_Dicache_set_parms from within Gif_get_descriptor, +but call it with the "correct" values from Gif_do_img_desc. This seems +to work fine with all GIF's and should work with all GIF's are +open-able(?) with xloadimage. (oh the patch is at: +http://www.linux.ime.usp.br/~livio/dillo/bad_gif.diff). + +But I want to make sure I'm doing the correct thing... So does +anybody know where I can find an GIF especification? Or like GIF-RFC? +IS there a GIF especification at all for public eyes? If I could get +one, them I could really make sure that my patch is full proof. + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares <livio@li...> - 2000-12-09 16:08 + +Eric GAUDET writes: +> Hey Livio, + +Hi Eric! + +> +> -- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le +> 01-Dec-2000 : +> > I started working on patch number 96. It was the bug that when +> > trying to `View Source` with multiple windows open, Dillo would +> > always get the last opened window and view that source, no matter on +> > what window we clicked. +> +> How did you eventually manage the problem ? + +Like I wrote in the previous e-mail, I've made each bw have it's own +menu_pop, i.e. make menu_pop a member of the struct +_BrowserWindow. This way the signal was corretly assigned to the right +bw. Personally, I think this is a clean fix, which doesn't require a +lot of rework, and seems to be robust. This way we don't have to worry +which is the focused or clicked window, since GTK deals corretly with +this when we connect the signal (right_button on bw -> open menu_pop). + +> I had a similar problem, needing to know what was the last clicked (== +> focused ?) window. The solution I used would help both of us, I think. I +> added a global variable in dillo.c : +> BrowserWindow *topmost_bw; +> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. +> +> Any thought ? + +Humm.. this could work too. But I think this solution is a little +more complex. Not necessarilly, in all window managers/systems, does +clicked == focused. I think we might have a long and tiresome battle +to get all the cases where the window is focused, so the topmost_bw is +always correct and accurate. I don't know, but it seems too tricky to +get this to work out, and maybe "unclean"... + +What do you need this info (focused window) for? Could you use the +solution I've made for your problem too? Maybe I can help out... + +Sorry for the mean critic... but I think college has made me into a +"avoid_global_variables,_they_will_give_you_trouble_in_the_future" +kind of guy ;-) + +best regards, + +-- +Livio <livio@li...> + + + +RE: [Dillo-dev]Bug #96 + +From: Eric GAUDET <egaudet@in...> - 2000-12-09 12:28 + +Hey Livio, + +-- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le +01-Dec-2000 : +> I started working on patch number 96. It was the bug that when +> trying to `View Source` with multiple windows open, Dillo would +> always get the last opened window and view that source, no matter on +> what window we clicked. + +How did you eventually manage the problem ? +I had a similar problem, needing to know what was the last clicked (== +focused ?) window. The solution I used would help both of us, I think. I +added a global variable in dillo.c : +BrowserWindow *topmost_bw; +This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. + +Any thought ? + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 09-Dec-2000 a 21:22:34 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Re: * + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-06 00:48 + +Hi, + +> Eric GAUDET <egaudet@in...> writes: +> +> > Do you still have this hash function ? I need one and I'm not sure mine +> > is that good. +> +> Doesn't glib include one? At least the header file suggests so. There +> are several function declarations named 'g_hash_table_*()'. So, this +> might be worth looking into. + +I digged into my archive and didn't find them :( +(I surely had been so dissapointed that ...!) + +Anyway, I was using mph-1.2.tar.gz (22 Kb), an excellent +package for generating minimal perfect hashes. Once you find a +function, it can be tuned in steps and table size, very cool +stuff. I remember that I built a hash function for every +supported HTML tag in dillo, and tuned it to half the size and 2 +or three steps; it was faster than the binary search, sure (4% or +so), but the added complexity, was not worth the trouble. + + +Jorge.- + + + +Re: [Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-12-05 10:19 + +Livio Baldini Soares writes: +> 2) +> Sometime ago I sent in a patch to correct, what I considered, a +> misbehaviour, but since nobody said anything (neither against or in +> favor), I'll ask again. When I type in the following in Dillo: +> +> /home/livio/ +> +> Dillo will then try to resolve http://home/livio/, but that isn't what +> I wanted him to do. Im my opinion Dillo should consider URL's starting +> with a '/' (slash) as a file request. What do you guys think? + +Yes, since '/' is not allowed in host names, I'd say this is a good +idea. + +Another idea: With all the plugins in future, how about a common +scheme based on regular expressions, configured by the user, e.g: + +/^ftp\.[[:alnum:]\.]+\// -> ftp:// (assuming that ftp server names +often begin with "ftp.") +/^[[:alnum:]\.]+\// -> http:// +/^\// -> file: +/^\(.+\)/ -> info: +/^\w+\(\w+\)$/ -> man: + +> I've made a patch to do exactly this. It's small, check it out at: +> http://www.linux.ime.usp.br/~livio/dillo/file.diff +> +> 3) +> I tried to reproduce bug #107, but I failed. If anyone on the list +> registered bug 107, could you please explain how to reproduce it, so I +> may that a llok at it? + +I didn't register it, but just try +http://download.so....net/dillo/dillo-0.3.0.tar.gz + +Sebastian + + + +RE: [Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Eric GAUDET <egaudet@in...> - 2000-12-05 09:53 + +-- En reponse de "[Dillo-dev]Final PNG transparent, file URI and bug +107" de Livio Baldini Soares, le 05-Dec-2000 : +> 1) +> Just wanted to write to say I've completely finished the png +> transparency implementation. Including the gamma correction which I +> didn't implement in the previous patch. So with that I think that the +> PNG test suite on Eric's site is pretty much complete, or have I +> skipped something? +> + +This png test suite is the official png test suite. + +> 2) +> Sometime ago I sent in a patch to correct, what I considered, a +> misbehaviour, but since nobody said anything (neither against or in +> favor), I'll ask again. When I type in the following in Dillo: +> +> /home/livio/ +> +> Dillo will then try to resolve http://home/livio/, but that isn't +> what I wanted him to do. Im my opinion Dillo should consider URL's +> starting with a '/' (slash) as a file request. What do you guys +> think? +> +> I've made a patch to do exactly this. It's small, check it out at: +> http://www.linux.ime.usp.br/~livio/dillo/file.diff +> + +That's too bad dillo's having a different behavior when getting a URL +in the command line or in the nav bar. Should be the same. + +> 3) +> I tried to reproduce bug #107, but I failed. If anyone on the list +> registered bug 107, could you please explain how to reproduce it, so +> I may that a look at it? +> + +No negfault for me either. I think it's the same bug with interrupting +download again. I'm pretty sure whoever made this entry can't reproduce +it every time. +IMHO there should be a <b>big</b> warning on the bug insertion page +asking people to test _several_ time the how-to-reproduce method before +they submit. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 05-Dec-2000 a 18:40:59 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Re: * + +From: Eric GAUDET <egaudet@in...> - 2000-12-05 09:39 + +-- En reponse de "Re: [Dillo-dev]Re: *" de Livio Baldini Soares, le +05-Dec-2000 : +> Eric GAUDET writes: +>> I had a quick look at the sources, and I don't understand why +>> passing bw isn't enough for finding what page was clicked. +>> However, I know the bug is there : _I_ did the bugtrack entry ! +> +> Well I'll try to explain it in my bad english... +> +> Since there was only one (global) `menu_popup`, everytime a new +> window was opened the same menu_popup would be (re)initialized (in +> a_Menu_popup_new). In that initialization the Menu_add (to connect a +> signal to a callback function), would be written over with the new +> parameter (the new *bw). So when the signal (event) called the +> callback, it would send the latest *bw NOT the current *bw. +> +> Ummm, did it get any clearer, or just confused you more? +> +> bye, + +I think I'm begining to see the light ;-) What I understand now is when +registering a call-back, the parameter (bw) is registered too. I though +the parameter was updated according to the calling widget each time the +callback was invoked (&bw). +... I should really read this gkt book I bought a while ago ;-) + + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 05-Dec-2000 a 18:33:54 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Livio Baldini Soares <livio@li...> - 2000-12-05 02:32 + +Hello again, + +Since I'm crowding too much this list lately I'll send in a 3 in 1 +e-mail. Here goes my three topics: + +1) +Just wanted to write to say I've completely finished the png +transparency implementation. Including the gamma correction which I +didn't implement in the previous patch. So with that I think that the +PNG test suite on Eric's site is pretty much complete, or have I +skipped something? + +2) +Sometime ago I sent in a patch to correct, what I considered, a +misbehaviour, but since nobody said anything (neither against or in +favor), I'll ask again. When I type in the following in Dillo: + +/home/livio/ + +Dillo will then try to resolve http://home/livio/, but that isn't what +I wanted him to do. Im my opinion Dillo should consider URL's starting +with a '/' (slash) as a file request. What do you guys think? + +I've made a patch to do exactly this. It's small, check it out at: +http://www.linux.ime.usp.br/~livio/dillo/file.diff + +3) +I tried to reproduce bug #107, but I failed. If anyone on the list +registered bug 107, could you please explain how to reproduce it, so I +may that a llok at it? + +that's about all, see yall latter, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Re: * + +From: Livio Baldini Soares <livio@li...> - 2000-12-05 01:39 + +Eric GAUDET writes: +> -- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le +> 01-Dec-2000 : + + +<big snip> + +> >> [BUG #96] +> > +> > I'll answer this one when I look up the patch code. I'm +> > interested cause a similar problem arises when trying to get the +> > link the mouse was over at click time (for "Save link as"). +> > +> +> I had a quick look at the sources, and I don't understand why passing bw +> isn't enough for finding what page was clicked. +> However, I know the bug is there : _I_ did the bugtrack entry ! + +Well I'll try to explain it in my bad english... + +Since there was only one (global) `menu_popup`, everytime a new +window was opened the same menu_popup would be (re)initialized (in +a_Menu_popup_new). In that initialization the Menu_add (to connect a +signal to a callback function), would be written over with the new +parameter (the new *bw). So when the signal (event) called the +callback, it would send the latest *bw NOT the current *bw. + +Ummm, did it get any clearer, or just confused you more? + +bye, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Re: * + +From: Livio Baldini Soares <livio@li...> - 2000-12-05 01:29 + +Hi Jorge, + +Jorge Arellano Cid writes: +> +> Hi! +> + +<snip> + +> +> Eric found a good solution by publishing pre-patches in his web +> site, maybe you can ask him for some space when necessary. + + +Ok, I agree that sometimes it can be annoying and waste of +bandwidght to have all patches attached to the list. I should of +thought of having my patches on a web page before :-( + +Here is a link to all the patches which I've made (or am currently +working on): + +http://www.linux.ime.usp.br/~livio/dillo/ + +It's my homepage from the University. It is REALLY slow, and +sometimes the University has it's backbone down and won't respond at +all. If anyone is trying to get a particular patch they can e-mail me +and ask, I'll be happy to provide it. + +<snip> + +> > [PNG transaparency] +> +> Please send me your last patch (when done) Livio. + +I've pretty much finished, and you can get it at: +http://www.linux.ime.usp.br/~livio/dillo/pang_transparency.diff + +But I will sent it to you personally. + +<snip> + +> > [BUG #96] +> +> I'll answer this one when I look up the patch code. I'm +> interested cause a similar problem arises when trying to get the +> link the mouse was over at click time (for "Save link as"). +> + +I've tried it out, and the patch I've made fixes the problem with +`Save link as...` too. The patch is here: + +http://www.linux.ime.usp.br/~livio/menu_pop.diff + + +that's about all... best regards, + +-- +Livio <livio@li...> + + + +RE: [Dillo-dev]Re: * + +From: Rafael R. Sevilla <dido@pa...> - 2000-12-03 18:37 + + + + + +RE: [Dillo-dev]Re: * + +From: Eric GAUDET <egaudet@in...> - 2000-12-03 16:42 + +he was talking about a minimal perfect hash function, not a hash +function robust for cryptography purposes. +However, I tested the the glib hash function for strings, and it's not +good _at_all_ : not near perfect (lots of collisions, any XOR-based +function is better). Almost unsuable. + +-- En reponse de "[Dillo-dev]Re: *" de Olaf Dietsche, le 03-Dec-2000 : +> Eric GAUDET <egaudet@in...> writes: +> +>> Do you still have this hash function ? I need one and I'm not sure +>> mine +>> is that good. +> +> Doesn't glib include one? At least the header file suggests so. There +> are several function declarations named 'g_hash_table_*()'. So, this +> might be worth looking into. +> +> Regards, Olaf. +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 04-Dec-2000 a 01:38:50 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: * + +From: Olaf Dietsche <olaf.dietsche@gm...> - 2000-12-03 15:48 + +Eric GAUDET <egaudet@in...> writes: + +> Do you still have this hash function ? I need one and I'm not sure mine +> is that good. + +Doesn't glib include one? At least the header file suggests so. There +are several function declarations named 'g_hash_table_*()'. So, this +might be worth looking into. + +Regards, Olaf. + + + +[Dillo-dev]just subscribed, dillo is faaaast :-) + +From: Olaf Grüttner <olaf@se...> - 2000-12-02 13:13 + +I just wanted to thank you guys. I recognize dillo being work in progress, +but is so fast it is wonderful and compared +to things like netscape 6 on linux it is lightning fast. + +can´t wait till tables are supported by dillo. + +keep up the good work!!! + +Olaf + +-- + + + +RE: [Dillo-dev]Re: * + +From: Eric GAUDET <egaudet@in...> - 2000-12-02 01:32 + +-- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le +01-Dec-2000 : +> Eric found a good solution by publishing pre-patches in his web +> site, maybe you can ask him for some space when necessary. +> + +Sure :-) (any free web hosting will do, though) + +> The University told us that code optimization was a task to be +> undertaken by the compiler (mainly peephole opt.), the real world +> is different! +> + +I used to code demos in asm-68k, I must still have some in the blood ;-) + +> Finally, never try to over-optimize!!! +> + +right ! But don't stop until your done with sensible loops code. + +> Speed opt. is a highly tricky matter. For instance, what seems +> faster in theory doesn't always show on reality: sometime ago I +> was tunning a minimal perfect hash function for dillo, and I +> succeeded!, but profiling revealed that the gain over a simple +> binary search was around 2%, and the added complexity was +> impressive. +> + +Do you still have this hash function ? I need one and I'm not sure mine +is that good. + +> +>> [BUG #96] +> +> I'll answer this one when I look up the patch code. I'm +> interested cause a similar problem arises when trying to get the +> link the mouse was over at click time (for "Save link as"). +> + +I had a quick look at the sources, and I don't understand why passing bw +isn't enough for finding what page was clicked. +However, I know the bug is there : _I_ did the bugtrack entry ! + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 02-Dec-2000 a 10:24:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Re: * + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-12-01 21:44 + +>> Another thing, there was a comment in the header of a_Url_squeeze +>> made by Jorge, saying the he wasn't sure that it was necessary. Well I +>> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a +>> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`, +>> and got the /index.html. Seems to work fine with both /../ and /./, +>> but I'm not sure if this is true to all HTTP servers. The only time +>> APACHE complains is when we send in a request for /FAQ/../../, APACHE +>> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents +>> this +> + +if the function is trivial, it probably saves the server some work. plus I +wonder what IIS does with this? + +>> [Code optimization] +> +> Eric's suggestions can be very insightful. I just want to add +> my two-cents. +> +> The University told us that code optimization was a task to be +> undertaken by the compiler (mainly peephole opt.), the real world +> is different! +> + +one thing I was taught was to profile, profile, profile. There is a nice GNU +tool called gprof to help with this. You compile the app with profiling turned +on, run it, then run gprof on the output (gmon.out I think). You get a +function call tree, time spent in each, etc. Very useful. + + + +[Dillo-dev]Re: * + +From: Jorge Arellano Cid <jcid@ne...> - 2000-12-01 20:16 + +Hi! + +As usual, here you'll find several answers (batch mode!) + +> Another thing, do you (or anybody +> else) have anything against sending patches to the list, so everyone +> can "pitch" in, and publically(?) discuss them. If not do you want me +> to CC: them to you, Jorge? + +I don't have an absolute answer for this question. +Cartainly, final-patches must be sent to me for revision and +inclusion, but those that can be considered as a "work in +progress" can be sent to the list for discussion. + +This mailing list has a reputation (gained over time) to be low +traffic and interesting, and I love it that way; maybe the best +way is hold patches while still polishing them and only request +some help or feedback when you really need it. Posting the patch +is a last resource, cause you always have the chance to send it +privately to the helping party. + +Eric found a good solution by publishing pre-patches in his web +site, maybe you can ask him for some space when necessary. + +> [...] +> I'll change the status to 100% in the bug-track when I get back net +> connection. Oh, and I'm NOT suppossed to put `done`, this is done by +> Jorge when he inserts the patch in the code (IF we agree the code is +> worth putting in), is this correct Jorge? + +Absolutely. + + +> Another thing, there was a comment in the header of a_Url_squeeze +> made by Jorge, saying the he wasn't sure that it was necessary. Well I +> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a +> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`, +> and got the /index.html. Seems to work fine with both /../ and /./, +> but I'm not sure if this is true to all HTTP servers. The only time +> APACHE complains is when we send in a request for /FAQ/../../, APACHE +> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents +> this + +Thanks for the info. + +BTW: Does anyone remember BUG#95? (Whether or not to parse +entities within URIs) I answered that sometime ago but, ....!!!, +my last research showed that although the URI RFC doesn't mention +entities, when the w3c guys decided to define HTML as SGML, +the entities parsing problem sprung-in, and the recomendation is +to parse them!!! (HTML 4.01 Appendix B 2.2). + +I don't if they changed the recommendation when they decided to +put-off SGML and defined XHTML as XML :-) + + +> [PNG transaparency] + +Please send me your last patch (when done) Livio. + + +> [Code optimization] + +Eric's suggestions can be very insightful. I just want to add +my two-cents. + +The University told us that code optimization was a task to be +undertaken by the compiler (mainly peephole opt.), the real world +is different! + +Some time ago I made some local vars optimizations that yielded +a bit more than a 100% percent speed gain!!!!! (with gcc :-). +When I exposed the problem to one of the gcc-tester's team, he +couldn't believe his eyes. + +Finally, never try to over-optimize!!! + +Speed opt. is a highly tricky matter. For instance, what seems +faster in theory doesn't always show on reality: sometime ago I +was tunning a minimal perfect hash function for dillo, and I +succeeded!, but profiling revealed that the gain over a simple +binary search was around 2%, and the added complexity was +impressive. + + +> [BUG #96] + +I'll answer this one when I look up the patch code. I'm +interested cause a similar problem arises when trying to get the +link the mouse was over at click time (for "Save link as"). + + + +Jorge.- + + + +Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's) + +From: Eric GAUDET <egaudet@in...> - 2000-12-01 09:29 + +-- En reponse de "Re: [Dillo-dev]Re: About bug #60 (transparency in +PNG's)" de Livio Baldini Soares, le 01-Dec-2000 : +> By the way, I also had forgotten to add a "composite" support, for +> when alpha value is between 0 (fully transparent) and 255 (totally +> opaque). I'm sending the new version, look at it and see if it's more +> 'decent' or is it still crappy? (Am sending it attached...) +> + +It's very nice. It's probably faster than the original code too. +BTW, testing for 0 and 255 is a very nice optimisation over +png_composite : as these values are more likely to be used, you avoid +calling a function. + +> Oh and I also checked the PNG test suite and compared against +> netscape 6 for Linux. The only thing that was different was the gamma +> correction. I guess there isn't any gamma correction with current PNG +> in dillo. Maybe I'll to do that some other time. Meanwhile, should I +> put such small problem in the bug-track, or should I leave it alone, +> hence it's "kind" of documented in the test suite? +> + +Isn't there a gamma-init function in pnglib ? +Anyway, IMHO we should all make more bugtrack entries, even for such +tiny problems, so we don't forget them. Jorge can always remove it if he +thinks it's not important. + +> I still have a doubt though. I currently left alone the outer for: +> for (i = 0; i < png->width; i++) { +> but just to acknowledge when to stop, cause I don't use `i` anywhere +> else. Do you see a better way to detect when png is over with. +> + +No, that's how it's done. Perhaps png->width can be calculated outside, +but it shouldn't matter much. +If it wasn't image processing (we're talking about hundred thousands +pixels, one loop for each pixel), I wouldn't suggest the following +(since i is not used) : +for ( i = png->width ; i ; i-- ) +;-))) + +Last thing : you've probably reviewed the gif decoding to learn how +transparency is delt with. Do you think the code is optimised enough ? + +ciao + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 01-Dec-2000 a 18:13:57 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Bug #96 + +From: Livio Baldini Soares <livio@li...> - 2000-12-01 04:21 + +Attachments: menu_pop.diff + +Hi! + +I started working on patch number 96. It was the bug that when +trying to `View Source` with multiple windows open, Dillo would always +get the last opened window and view that source, no matter on what +window we clicked. First I went to look for the source of the problem, +it appears to be the fact the the is only Menu_popup for all the +windows. And when we open a new window using +a_Interface_new_browser_window, we re-initilialize menu_popup, with: + +> menu_popup.menu = a_Menu_popup_new(bw); +> menu_popup.menu_over_link = a_Menu_popup_ol_new(bw); + +And in a_Menu_popup_new we add the callback for selecting View +Source, and all other Menu_popup entries. So for every new window, the +callback are changed to look up it's data from that window, ignoring +the possibility of other older windows... + +So I have thought up of two solutions, and for the first one I'm +sending in the patch which I've made (almost minimal changes to +current program): + +1) One solution is to have every window have it's own menu_popup. So +basically I changed struct _BrowserWindow to include a +DillowMenuPopup, and changed all ocurrences of menu_popup tp +bw->menu_popup. This is the solution I've implemented and am sending +the patch. + +2) The other soluion would involve more changes to current code, but +might be more economic. Instead of having each BrowserWindow have it's +own menu_popup like in (1), continue like current code, having a +global menu_poup, but use the browser_window[] Vector(? array?) index +to pass to the callback. So when the callback is called it checks, +somehow, from what window is the signal coming from and them access +the window using the browser_window[] array. I didn't like this idea +so much as it would make the code uglier and even though we would +economize a mune_popup per new window, we would create overhead to +find out from what window was the signal coming from and process that +information accordingly. + + +Any ideas/comments? I would really apreciate, since I still haven't +convinced myself I've chosen the right choice (or there may be +others...). + +Oh, and the patch is supposed to be applyied over the whole dillo +directory (from CVS), but will only affect: src/bookmark.c, +src/browser.h, src/commands.c, src/dw_page.c, src/interface.c, +src/menu.c. + +best regards to all, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's) + +From: Livio Baldini Soares <livio@li...> - 2000-12-01 03:04 + +Attachments: png_transparent2.diff + +Gee, thanks, Eric! + +Very nice tips you gave on my patch (some of the stuff I already +knew but was too lazy/sleepy to get things out). Sorry about the +newbie code... but with all of your suggestions, now I think the patch +is looking good... + +By the way, I also had forgotten to add an "composite" support, for +when alpha value is between 0 (fully transparent) and 255 (totally +opaque). I'm sending the new version, look at it and see if it's more +'decent' or is it still crappy? (Am sending it attached...) + +Oh and I also checked the PNG test suite and compared against +netscape 6 for Linux. The only thing that was different was the gamma +correction. I guess there isn't any gamma correction with current PNG +in dillo. Maybe I'll to do that some other time. Meanwhile, should I +put such small problem in the bug-track, or should I leave it alone, +hence it's "kind" of documented in the test suite? + +Eric GAUDET writes: +> +> IMHO there's several problem with your calculations : + +;-) + +> +> 1) the strol part is very inefficient, but that's not a real problem +> because this code is _outside_ the loop. Anyway, here's how to do it : +> (strip all the sprintf) +> bg_blue = (prefs.bg_color0 & 0xFF; +> bg_green = (prefs.bg_color>>8) & 0xFF; +> bg_red = (prefs.bg_color>>16) & 0xFF; + +Yeah, this one I knew was really bad... + +> +> 2) The loop is _always_ the sensible part ! You _never_ want to allocate +> local variables like you did : +> for (...) { +> gint p,a; +> (some compiler may optimize this, but you never know) +> As a rule of thumb, it's better to allocate local variables at the +> begining of a function. +> + +I agree completely, loops are what makes the code have a higher +complexity, and everything that can, should be put outside of the +loop. + +> 3) If you really want to improve speed, do all calculation only once in +> local variables : i*3 is computed three times, it would be better to +> have calculated i3 = i*3 and use i3. (same with i*4 used twice). +> You could also have done i3 += 3 each loop, but on pentium-generation +> cpu (whatever the brand, ppc, arm, ...) multiplications and additions +> cost the same so it doesn't matter, and using i*3 is often more +> readable and more robust (not sensible to initiallisation). +> +> 4) Even better : look into a table is a calculation. png->linebuf[3*i] +> is actually *(png + linebuf + 3*i). +> You could have declared +> guchar *pl = png->linebuf; +> and in the loop : +> if (!a){ +> *(pl++) = bg_red; +> *(pl++) = bg_green; +> *(pl++) = bg_blue; +> } +> + +Liked this option (4) much more than 3. + +> The else part is basically the same, if a little more trickier, and you +> can get rid of the costy for() : I let it to you as an exercise ;-) +> (hint : row_num*png->rowbytes is ugly) + +Well... how is it now? Less uglier? + +I still have a doubt though. I currently left alone the outer for: +for (i = 0; i < png->width; i++) { +but just to acknowledge when to stop, cause I don't use `i` anywhere +else. Do you see a better way to detect when png is over with. + +> +> 5) Last : if(!a) is more complex than if(a) : invert the if/else. +> +> Hope this helps. + +Yes! This helps a lot! Thanks a bunch Eric. + +best regards, + +-- +Livio <livio@li...> + + |