[Dillo-dev]ALT attribute in `img' tag From: Livio Baldini Soares - 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 [Dillo-dev]dillo-0.3.1 From: Jorge Arellano Cid - 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 - 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 Re: [Dillo-dev]Entity parsing in links From: Eric GAUDET - 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 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 - 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 - 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: - 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) > > 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 Re: [Dillo-dev]Entity parsing in links From: Sam Dennis - 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! > > > > > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > http://lists.so....net/mailman/listinfo/dillo-dev -- Sam Dennis "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 - 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 : > > > 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 "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 - 2000-12-23 19:59 Jorge Arellano Cid writes: > > Hi everyone! Howdy! > 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 Re: [Dillo-dev]Entity parsing in links From: Sam Dennis - 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 "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 - 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 - 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 - 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 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 - 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 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 - 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 Re: [Dillo-dev]Entity parsing in links From: Livio Baldini Soares - 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 : > > 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 [Dillo-dev]0.3.1 release From: Jorge Arellano Cid - 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 - 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: > > > >> > >> > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > http://lists.so....net/mailman/listinfo/dillo-dev ----------------------------------- Eric GAUDET Le 23-Dec-2000 a 10:36:02 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Entity parsing in links From: Livio Baldini Soares - 2000-12-23 00:09 Sam Dennis writes: > On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote: > > > > 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 Re: [Dillo-dev]Entity parsing in links From: Sam Dennis - 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 (). > > 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: > annotate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 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 > > _______________________________________________ > 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 "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 - 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 (). 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: annotate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 Re: [Dillo-dev]Modularization(?) in Dillo From: Livio Baldini Soares - 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 RE: [Dillo-dev]Modularization(?) in Dillo From: Eric GAUDET - 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 Le 18-Dec-2000 a 21:05:24 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Cookies From: Eric GAUDET - 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 Le 18-Dec-2000 a 20:59:06 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]Modularization(?) in Dillo From: Livio Baldini Soares - 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 Re: [Dillo-dev]Cookies From: Livio Baldini Soares - 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 [Dillo-dev]A few answers From: Jorge Arellano Cid - 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 - 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 Le 17-Dec-2000 a 22:45:21 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]Fontsize From: Bruno Widmann - 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

-

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 - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]SourceForge downtime From: Jorge Arellano Cid - 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 tag From: Jorge Arellano Cid - 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 ( tag) From: Livio Baldini Soares - 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 [Dillo-dev]html tag implementations From: Sean 'Shaleh' Perry - 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 ( tag) From: Sean 'Shaleh' Perry - 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 ( tag) From: Sean 'Shaleh' Perry - 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 ( tag) From: Sean 'Shaleh' Perry - 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 - 2000-12-10 20:30 Hellos, forgot to mention something... Livio Baldini Soares writes: > 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 Re: [Dillo-dev]Bug #109 ( tag) From: Livio Baldini Soares - 2000-12-10 18:32 Eric GAUDET writes: > -- En reponse de "[Dillo-dev]Bug #109 ( 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 > > 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 Re: [Dillo-dev]Bug #96 From: Livio Baldini Soares - 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: > > 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... 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 RE: [Dillo-dev]Bug #109 ( tag) From: Eric GAUDET - 2000-12-10 08:00 -- En reponse de "[Dillo-dev]Bug #109 ( 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

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 Le 10-Dec-2000 a 16:03:49 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]Bug #109 ( tag) From: Livio Baldini Soares - 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 #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 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 , 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

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 Re: [Dillo-dev]Bug #96 From: Eric GAUDET - 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 Le 10-Dec-2000 a 12:23:43 "Le verbe inexister ... inexiste !" ----------------------------------- RE: [Dillo-dev]Comments From: Eric GAUDET - 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 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 - 2000-12-10 02:15 Livio Baldini Soares writes: > Jorge Arellano Cid writes: > > ---- > > 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 Re: [Dillo-dev]Comments From: Livio Baldini Soares - 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. > ---- > 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 [Dillo-dev]Comments From: Jorge Arellano Cid - 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 - 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 - 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 Re: [Dillo-dev]Bug #96 From: Livio Baldini Soares - 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 RE: [Dillo-dev]Bug #96 From: Eric GAUDET - 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 Le 09-Dec-2000 a 21:22:34 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Re: * From: Jorge Arellano Cid - 2000-12-06 00:48 Hi, > Eric GAUDET 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 - 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 - 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 big warning on the bug insertion page asking people to test _several_ time the how-to-reproduce method before they submit. ----------------------------------- Eric GAUDET Le 05-Dec-2000 a 18:40:59 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Re: * From: Eric GAUDET - 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 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 - 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 Re: [Dillo-dev]Re: * From: Livio Baldini Soares - 2000-12-05 01:39 Eric GAUDET writes: > -- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le > 01-Dec-2000 : > >> [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 Re: [Dillo-dev]Re: * From: Livio Baldini Soares - 2000-12-05 01:29 Hi Jorge, Jorge Arellano Cid writes: > > Hi! > > > 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. > > [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. > > [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 RE: [Dillo-dev]Re: * From: Rafael R. Sevilla - 2000-12-03 18:37 RE: [Dillo-dev]Re: * From: Eric GAUDET - 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 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 Le 04-Dec-2000 a 01:38:50 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]Re: * From: Olaf Dietsche - 2000-12-03 15:48 Eric GAUDET 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 - 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 - 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 Le 02-Dec-2000 a 10:24:24 "Le verbe inexister ... inexiste !" ----------------------------------- RE: [Dillo-dev]Re: * From: Sean 'Shaleh' Perry - 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 - 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 - 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 Le 01-Dec-2000 a 18:13:57 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]Bug #96 From: Livio Baldini Soares - 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 Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's) From: Livio Baldini Soares - 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