diff options
Diffstat (limited to 'old/oldmail/200008.txt')
| -rw-r--r-- | old/oldmail/200008.txt | 3527 |
1 files changed, 3527 insertions, 0 deletions
diff --git a/old/oldmail/200008.txt b/old/oldmail/200008.txt new file mode 100644 index 0000000..8133b5d --- /dev/null +++ b/old/oldmail/200008.txt @@ -0,0 +1,3527 @@ +Re: [Dillo-dev]bug#77 is anchor-related + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-27 16:32 + +Eric GAUDET wrote: +> +> Hi all, +> bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with +> Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason, +> dw->container is null for one widget, doing a segfault when accessed. +> This is related to anchors, so I hope Sebastian can fix that easilly ;-) + +Funny, I've inserted this bug. ;-) + +Dw_page_set_scroller_pos searches the GtkDwScroller that "contains" +the DwPage. Normally, page->parent is a DwBorder, page->parent->parent +is NULL (i. e. the DwBorder is a toplevel Dw widget), and +page->parent->container->widget point to the GtkDwView (a normal Gtk+ +widget, which parent is the GtkDwScroller). page->container is always +NULL. + +When examining the bug, I found that page->parent is NULL (and also +page->container). The bug seems to lie deeper in Dw, but since Dw is +planned to be elemenated and relaced by Gtk+, I'd suggest to forget +it. ;-) + +Sebastian + + + +[Dillo-dev]bug#77 is anchor-related + +From: Eric GAUDET <egaudet@in...> - 2000-08-27 14:07 + +Hi all, +bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with +Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason, +dw->container is null for one widget, doing a segfault when accessed. +This is related to anchors, so I hope Sebastian can fix that easilly ;-) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 27-Aug-2000 a 23:01:22 +---------------------------------- + + + +Re: [Dillo-dev]support for background images? + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-26 14:30 + +Sean 'Shaleh' Perry wrote: +> That said, please do visit the html validator link I sent previously. In css +> supporting browsers, a line of incorrect html is set against a grey background. + +At least it is readable in dillo. ;-) + +> We have to be able to affect the appearance of a page on a per word basis. + +Currently, DwPage can assign attributes to words. I don't think it is +too difficult to add backgrounds to DwPageAttr. I'll test it soon. + +Sebastian + + + +[Dillo-dev]bug no insertion : I'm patching lists + +From: Eric GAUDET <egaudet@in...> - 2000-08-26 13:18 + +Hi all, +the inserting in bug tracking engine doesn't work for me (server +internal error). +Be aware I'm partching the lists tags and dw_bullets right now, to make +attribute type being recognized (both OL and UL), and also to correct +the bug about numbering reported a few days ago. + +I wont address bug#78 this time because it's a P tag problem. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 26-Aug-2000 a 16:29:43 +---------------------------------- + + + +Re: [Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 10:00 + +> I'm currently working on DwPage (table sections will be DwPage's, +> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +> Html_tag_open_body), I'll set it as the the page's background. (I +> hope. ;-) +> + +hmm, seems the dicache and the rest of the image code assumes the goal is to +place the image on the page. Will have to read thru the entire image code to +lay this out and understand a proper implementation. Sounds like this can wait +(-: + + + +Re: [Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 09:37 + +> I'm currently working on DwPage (table sections will be DwPage's, +> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +> Html_tag_open_body), I'll set it as the the page's background. (I +> hope. ;-) +> + +will add this to my list of things todo. + +That said, please do visit the html validator link I sent previously. In css +supporting browsers, a line of incorrect html is set against a grey background. +We have to be able to affect the appearance of a page on a per word basis. + + + +Re: [Dillo-dev]support for background images? + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-26 09:25 + +Sean 'Shaleh' Perry wrote: +> +> Thought I would toss this out in the mess of ideas lately: +> +> we ought to support background images. style sheets allow you to specify +> backgrounds for just about everything. So, what would be best is a mechanism +> for: +> +> load image +> place image in the background of widget X +> +> X could be Page, table section, etc. +> +> Seems funny that the bug list looks better in ns than in dillo (-: + +I'm currently working on DwPage (table sections will be DwPage's, +too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +Html_tag_open_body), I'll set it as the the page's background. (I +hope. ;-) + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET <egaudet@in...> - 2000-08-26 03:21 + +Le 25-Aug-2000, on m'a dit : +> > ok, what about both, then (anchors and headings) ? Some of them can +> > be +> > duplicates (anchor are often used to link to pararaphs titles). +> > And "Top of page" and "Bottom of page", even if not anchored, would +> > be +> > useful too. +> +> It's quite simple, I've begun to implement it (both headings and +> anchors). But I will not work on it the next time. Is anyone +> interested in completing it? I'll send him the patch. +> +> Sebastian + +I can try. Send me the patch. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 26-Aug-2000 a 12:21:03 +---------------------------------- + + + +[Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-26 00:14 + +Thought I would toss this out in the mess of ideas lately: + +we ought to support background images. style sheets allow you to specify +backgrounds for just about everything. So, what would be best is a mechanism +for: + +load image +place image in the background of widget X + +X could be Page, table section, etc. + +Seems funny that the bug list looks better in ns than in dillo (-: + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 18:59 + +Eric GAUDET wrote: +> +> Le 25-Aug-2000, on m'a dit : +> > Eric GAUDET wrote: +> > > Hi, +> > > I just thought about one (new idea?) feature about anchors : would +> > > it +> > > be possible to list them in a menu entry (Named "Chapters"? +> > > "Index"? +> > > "Content"?). Doing that, each time a page is loaded, this menu +> > > entry +> > > would be updated and the user could conveniently "jump" to anchors +> > > in +> > > the page without scrolling. +> > > +> > > What do you think ? +> > +> > That would be possible. But I think a menu of the anchors in a page +> > is not very useful. Better would be to list all the <h1>...<h6>. +> > That could also be possible by adding "pseudo anchors". If you get +> > a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR +> > "@id" or so, where id is a unique number (unique in the page). +> > +> +> ok, what about both, then (anchors and headings) ? Some of them can be +> duplicates (anchor are often used to link to pararaphs titles). +> And "Top of page" and "Bottom of page", even if not anchored, would be +> useful too. + +It's quite simple, I've begun to implement it (both headings and +anchors). But I will not work on it the next time. Is anyone +interested in completing it? I'll send him the patch. + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET <egaudet@in...> - 2000-08-25 14:22 + +Le 25-Aug-2000, on m'a dit : +> I didn't actually mean dillo's plugins (I currenty don't know how +> they work anyway), but some other sort of +> extend-dillo-without-modifying-the-sources, which could be called +> modules to avoid confusing. What I thought is: You can think of +> thousands of useful functions for dillo. When putting them all into +> dillo, the code gets big although a user might not use all these +> features. Indeed, such an interface should 1. be designed properly, +> and 2. not in the near future (currently we have other problems). +> + +Totally agreed ! (on everything : "thousands useful functions", "module +interface design", "we have other problems") What I was pointing out is +such a module interface design could be really tricky to come out with, +especially since it hasn't been planned of from the begining. + +> Sebastian +> +> PS1: I'm currently not interested in working on something like that, +> it was just an idea. ;-) +> + +While you're talking about that, I wanted to tell how nice it is to be +in that mailing list, with people throwing interesting ideas (even if +not interested in working on them ;-), nice and respectful ambiance (no +troll here : great !). + +> PS2: Counting characters is exotic enough that is reasonable to let +> the user save the page and start an other program. Trying to connect +> a webbrowser to all of the world is indeed quite idiotic. + +ok, that was a poor example, but who knows ? ;-) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 25-Aug-2000 a 23:09:58 +---------------------------------- + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 13:43 + +Eric GAUDET wrote: +> [...] +> > Another idea: What about a mechanism to let the user ("user" is +> > anyone who does not changes the sources of dillo ;-) write such +> > things. +> > Perhaps plugins? The plugin transmits to dillo what is interesting +> > for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id +> > for referring to the tags to the plugin. When a user clickes on an +> > item in the plugin's list, the plugin sends a url to dillo. +> > +> +> That would mean calling _every_ (registered) plugin each time a page +> is loaded. Seems possible, but that can slow down thing. +> Registering the tags is interesting because dillo doesn't have to send +> the whole page, and the plugin doesn't have to parse html. But I'm not +> sure that's how plugins are supposed to work, though I'm still waiting +> for complete plugins specs (Jorge ?). +> I mean : we'll have to change dillo's html parsing for that type of +> plugins ; what about a plugin wanting to count how many "e" there's in +> a page ? interesting, but we'll have to change dillo's sources for that. +> What about a pluggin wanting to scan images before rendered and censor +> those where there's too much "skin tones" ? interesting, but we'll have +> to change dillo's sources once again for that. +> The cleanest way would be to send each page to the pluggin, and wait for +> the plugin to render the page. The html parser could be a plugin : that +> way we could have a pdf-plugin, a rtf-plugin ... that would be nice. +> But that's not what we are doing : we are doing an html browser, and +> html source is intended to be in the browser, not sent to plugins. +> The way Jorge defined plugins (that can change) is clean and simple : a +> plugin call looks like a link ("dpi://myplugin"), some datas are sent +> (name=value type), the plugin sends back an html page (and possibly ask +> dillo to update its menus, but there's no protocol for that yet, though +> I'm working on it). That's it. There's no two-way interaction between +> dillo and the plugins. There is no possibility for a plugin to ask dillo +> about its internals, such as page source, history. +> Albeit your module/plugin idea is interesting, that would mean a big +> rewrite in dillo's whole html parsing and plugin system (I know, +> it's not written yet) just to avoid small changes in dillo's menus and +> anchor (and H1..h6) parsing. +> In a nutshell, I think it's better and easier to keep these things in +> dillo, until we define (not soon) a clear mecanisme for external +> modules, which aren't plugins. +> +> (man, _that's_ a long answer to a not very useful question ;-) + +I didn't actually mean dillo's plugins (I currenty don't know how they +work anyway), but some other sort of +extend-dillo-without-modifying-the-sources, which could be called +modules to avoid confusing. What I thought is: You can think of +thousands of useful functions for dillo. When putting them all into +dillo, the code gets big although a user might not use all these +features. Indeed, such an interface should 1. be designed properly, +and 2. not in the near future (currently we have other problems). + +Sebastian + +PS1: I'm currently not interested in working on something like that, +it was just an idea. ;-) + +PS2: Counting characters is exotic enough that is reasonable to let +the user save the page and start an other program. Trying to connect a +webbrowser to all of the world is indeed quite idiotic. + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET <egaudet@in...> - 2000-08-25 11:03 + +Le 25-Aug-2000, on m'a dit : +> Eric GAUDET wrote: +> > Hi, +> > I just thought about one (new idea?) feature about anchors : would +> > it +> > be possible to list them in a menu entry (Named "Chapters"? +> > "Index"? +> > "Content"?). Doing that, each time a page is loaded, this menu +> > entry +> > would be updated and the user could conveniently "jump" to anchors +> > in +> > the page without scrolling. +> > +> > What do you think ? +> +> That would be possible. But I think a menu of the anchors in a page +> is not very useful. Better would be to list all the <h1>...<h6>. +> That could also be possible by adding "pseudo anchors". If you get +> a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR +> "@id" or so, where id is a unique number (unique in the page). +> + +ok, what about both, then (anchors and headings) ? Some of them can be +duplicates (anchor are often used to link to pararaphs titles). +And "Top of page" and "Bottom of page", even if not anchored, would be +useful too. + +> Another idea: What about a mechanism to let the user ("user" is +> anyone who does not changes the sources of dillo ;-) write such +> things. +> Perhaps plugins? The plugin transmits to dillo what is interesting +> for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id +> for referring to the tags to the plugin. When a user clickes on an +> item in the plugin's list, the plugin sends a url to dillo. +> + +That would mean calling _every_ (registered) plugin each time a page +is loaded. Seems possible, but that can slow down thing. +Registering the tags is interesting because dillo doesn't have to send +the whole page, and the plugin doesn't have to parse html. But I'm not +sure that's how plugins are supposed to work, though I'm still waiting +for complete plugins specs (Jorge ?). +I mean : we'll have to change dillo's html parsing for that type of +plugins ; what about a plugin wanting to count how many "e" there's in +a page ? interesting, but we'll have to change dillo's sources for that. +What about a pluggin wanting to scan images before rendered and censor +those where there's too much "skin tones" ? interesting, but we'll have +to change dillo's sources once again for that. +The cleanest way would be to send each page to the pluggin, and wait for +the plugin to render the page. The html parser could be a plugin : that +way we could have a pdf-plugin, a rtf-plugin ... that would be nice. +But that's not what we are doing : we are doing an html browser, and +html source is intended to be in the browser, not sent to plugins. +The way Jorge defined plugins (that can change) is clean and simple : a +plugin call looks like a link ("dpi://myplugin"), some datas are sent +(name=value type), the plugin sends back an html page (and possibly ask +dillo to update its menus, but there's no protocol for that yet, though +I'm working on it). That's it. There's no two-way interaction between +dillo and the plugins. There is no possibility for a plugin to ask dillo +about its internals, such as page source, history. +Albeit your module/plugin idea is interesting, that would mean a big +rewrite in dillo's whole html parsing and plugin system (I know, +it's not written yet) just to avoid small changes in dillo's menus and +anchor (and H1..h6) parsing. +In a nutshell, I think it's better and easier to keep these things in +dillo, until we define (not soon) a clear mecanisme for external +modules, which aren't plugins. + +(man, _that's_ a long answer to a not very useful question ;-) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 25-Aug-2000 a 19:02:34 +---------------------------------- + + + +Re: [Dillo-dev]java in dillo + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 09:58 + +Sean 'Shaleh' Perry wrote: +> +> On 25-Aug-2000 Eric GAUDET wrote: +> > Hi again, +> > Anybody working on applets in Dillo ? I wondered if it was possible for +> > dillo to launch the 'appletviewer' program (from a separate JDK) and +> > then "swallow" its windows to render the initial html page (just like +> > wharf, dock or gnome/kde pannel do with dockable applets). +> > +> > I don't think I'll see that soon, but that could be fairly doable. +> > +> +> I doubt this will work. swallowed apps work because of an agreement between +> the app and the window manager / panel. + +Furthermore, communication between applet and browser (class +AppletContext) will not be possible. Perhaps Kaffe or Japhar can be +used somehow. + +> What we probably need to do is have a +> widget which is an arbitrary window. Then java, javascript, embedded +> <objects>, animations, etc can be placed in this widget. + +Perhaps look at GtkSocket/GtkPlug. They provide a mechanism to embed +windows created by other programs. + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-25 09:58 + +Eric GAUDET wrote: +> Hi, +> I just thought about one (new idea?) feature about anchors : would it +> be possible to list them in a menu entry (Named "Chapters"? "Index"? +> "Content"?). Doing that, each time a page is loaded, this menu entry +> would be updated and the user could conveniently "jump" to anchors in +> the page without scrolling. +> +> What do you think ? + +That would be possible. But I think a menu of the anchors in a page is +not very useful. Better would be to list all the <h1>...<h6>. That +could also be possible by adding "pseudo anchors". If you get a tag +which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR "@id" +or so, where id is a unique number (unique in the page). + +Another idea: What about a mechanism to let the user ("user" is anyone +who does not changes the sources of dillo ;-) write such things. +Perhaps plugins? The plugin transmits to dillo what is interesting for +it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id for +referring to the tags to the plugin. When a user clickes on an item in +the plugin's list, the plugin sends a url to dillo. + +Sebastian + + + +RE: [Dillo-dev]java in dillo + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-25 04:17 + +On 25-Aug-2000 Eric GAUDET wrote: +> Hi again, +> Anybody working on applets in Dillo ? I wondered if it was possible for +> dillo to launch the 'appletviewer' program (from a separate JDK) and +> then "swallow" its windows to render the initial html page (just like +> wharf, dock or gnome/kde pannel do with dockable applets). +> +> I don't think I'll see that soon, but that could be fairly doable. +> + +I doubt this will work. swallowed apps work because of an agreement between +the app and the window manager / panel. What we probably need to do is have a +widget which is an arbitrary window. Then java, javascript, embedded +<objects>, animations, etc can be placed in this widget. + + + +[Dillo-dev]java in dillo + +From: Eric GAUDET <egaudet@in...> - 2000-08-25 04:10 + +Hi again, +Anybody working on applets in Dillo ? I wondered if it was possible for +dillo to launch the 'appletviewer' program (from a separate JDK) and +then "swallow" its windows to render the initial html page (just like +wharf, dock or gnome/kde pannel do with dockable applets). + +I don't think I'll see that soon, but that could be fairly doable. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 25-Aug-2000 a 13:06:05 +---------------------------------- + + + +[Dillo-dev]Anchor : feature wish + +From: Eric GAUDET <egaudet@in...> - 2000-08-25 04:06 + +Hi, +I just thought about one (new idea?) feature about anchors : would it +be possible to list them in a menu entry (Named "Chapters"? "Index"? +"Content"?). Doing that, each time a page is loaded, this menu entry +would be updated and the user could conveniently "jump" to anchors in +the page without scrolling. + +What do you think ? + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 25-Aug-2000 a 12:59:58 +---------------------------------- + + + +[Dillo-dev]another fun test site + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-24 20:09 + +validator.w3.org + +This takes a web site and shows how valid its HTML is. Also can include the +parse tree of the document. + +dillo currently fails to lay out the results properly. + + + +[Dillo-dev]Dw -> Gtk + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-24 16:34 + +Hi! + +There is a problem (and an idea on its solution) with Gtk+: + +A rule of Gtk+ is, that widgets have to deal with any size allocation, +but some of the Dw widgets depend on a more complicated size +negotiation, which is currently done by a_Dw_size_nego_x, e. g.: + +- DwPage, which should always allocate the size needed to display all +the text, +- the not-yet-written table widget, comparable to DwPage, and +- DwImage's with relative size (?). + +I've thought about several ways, the one I prefer is this: + +Such widgets do not simply accept the GtkAllocation in +gtk_xxx_size_allocate, but correct it before storing it in +widget->allocation. The standard Gtk+ containers do not refer to these +corrected allocations, but to those they have calculated for there +children, so you get either unintended spaces or overlapping widgets. +So, dillo's new containers (e. g. the table) should use these +"reallocations". + +I've tested it by writing a few useless widgets, and it works. + +Some alternatives which have also come to my mind: + +- Derive all widgets from one base widget GtkDwWidget which has a +functionality similar to a_Dw_size_nego_x. A container could do some +thing like this: + +if (GTK_IS_DW_WIDGET (child)) { +/* use the functionality of GtkDwWidget */ +} else { +/* standard size allocation */ +} + +Since Gtk+ does not provide multiple inheritance, there will be the +problem which base class to use for GtkDwBase. E.g., should images be +containers? Deriving from and so reusing other Gtk+ widgets will be +impossible. + +- Children resize themselves on a size allocation. This is somehow +possible (I once wrote something like this), but this will result in a +horrible overhead. + +Comments? + +Sebastian + + + +[Dillo-dev]still some concerns about HR tag + +From: Eric GAUDET <egaudet@in...> - 2000-08-23 13:46 + +Hi, I just tested the HR "bug-fix" in dillo v0.2.4 : the line's width +is the page's width all right. But the horizontal page slider is still +there !!! (you can scroll to see the emptyness in the right) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Aug-2000 a 22:42:31 +"Si la japonaise est la négation la plus aboslue de la femme, +elle est aussi la négation la plus absolue de la beauté grecque." +(Louis Martin, l'Anglais est-il un juif ?, 1895) +---------------------------------- + + + +[Dillo-dev]style sheets + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 07:02 + +So, was driving home tonight and an idea hit me. + +Style sheets are meant to be cascading (they stack). So, we can implement user +preferences as local style sheets which come first (highest) or last based on +settings. The allow_whitebg becomes a simple style sheet line. + +Properly implementing font and what not will require some ground work and if I +am doing that, I may as well look to the future. + +Comments? + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 06:59 + +> +> And the same thing when going to http://www.mysite.org/ and the browser +> popups-up a window asking for your login and password. (the http side +> is the same, basically you have to encode in base64 the string +> "user:password" and send that in the http request) +> + +right + +Playing with <font> right now and pondering style sheets. Need to set up a +local http server to play with http auth, cgi, and the like. + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET <egaudet@in...> - 2000-08-23 03:35 + +Le 22-Aug-2000, on m'a dit : +> > +> > I mean http auth, as in http://user:password@ww.../ +> > +> +> the URL parser needs to understand this. Then the proper http send +> mechanism +> needs to be used. I do not think this would be too hard. Now I +> have two +> reasons to read the HTTP spec. +> + +And the same thing when going to http://www.mysite.org/ and the browser +popups-up a window asking for your login and password. (the http side +is the same, basically you have to encode in base64 the string +"user:password" and send that in the http request) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Aug-2000 a 12:31:30 +---------------------------------- + + + +[Dillo-dev]currently working on <font> + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-23 01:39 + +I have an initial implementation of <font> put together. It currently only +handles the color attribute, but more to come. My current problem is that when +the tag is popped, the color is not reset. I am confused, the rest of the font +like tags (bold, cite) clean up after themselves by simply popping their tag. +Will get it when I get a chance. + + + +Re: [Dillo-dev]0.2.4 release + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 22:27 + +Hi, Sean, + +Sean 'Shaleh' Perry wrote: +> +> > +> > 2. The better way: Leave "not-reloading" enabled, but push the url's +> > on the stack "by hand". See the "else" part of "if (must_load)". I +> > tried to implement it, bud didn't understand how. I think it is done +> > in a_Nav_expect_done, but calling it (or a modified version of it) +> > didn't work. This is an other point worth to improve. +> > +> +> enclosed is the beginnings of this patch. If I go to foo.html, then follow +> foo.html#link, then hit back, I get to foo.html. However if I go to +> foo.html#second from foo.html#link, then hit back I still go to foo.html. Not +> quite sure how the anchor system works. Maybe you can take the code and go +> from there. + +My changes in the Nav module only consist of a few lines. Most of my +code is in GtkDwScroller and DwPage. Furthermore, I did not understand +the navigation mechanism very good, so perhaps someone else should +work on this problem. + +BTW: I sent Jorge some documentation, I think, he should include it +into the release. + +> The patch is longer than it needs to be because I moved Nav_open_url to the end +> of the file and places a declaration at the top so the other functions know +> about it. This mimics the layout of the other source modules. + +What about including "nav.h" in "nav.c"? That would also let the +compiler check the function prototypes against there definitions. + +> I think there is something wrong with calling a_Foo_bar() in module Foo. + +Yes, propably there should be a seperate function, which is called by +Nav_open_url and a_Nav_expect_done. + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 21:24 + +Jorge Arellano Cid wrote: +> +> Sean, +> +> > http://www.gphoto.org/news.html +> > +> > The GNU Public License link points to http://www.gnu.org, but dillo +> > thinks it points to http://www.gphoto.org. +> +> Fixed! (BUG #79) + +I wrote: +> [...] + +Ok, 5 minutes of wasted time. ;-) + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 21:19 + +Sean 'Shaleh' Perry wrote: +> +> http://www.gphoto.org/news.html +> +> The GNU Public License link points to http://www.gnu.org, but dillo +> thinks it points to http://www.gphoto.org. + +The html file looks like this: + +<a href= +"> + +When there are whitespaces after the attribute name, Html_get_attr +returns an empty string, and so a_Url_resolve_relative returns the +wrong url. + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-22 20:50 + +Sean, + + +> http://www.gphoto.org/news.html +> +> The GNU Public License link points to http://www.gnu.org, but dillo +> thinks it points to http://www.gphoto.org. + +Fixed! (BUG #79) + + + +Re: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 19:22 + +Attachments: nav.patch + +> +> 2. The better way: Leave "not-reloading" enabled, but push the url's +> on the stack "by hand". See the "else" part of "if (must_load)". I +> tried to implement it, bud didn't understand how. I think it is done +> in a_Nav_expect_done, but calling it (or a modified version of it) +> didn't work. This is an other point worth to improve. +> + +enclosed is the beginnings of this patch. If I go to foo.html, then follow +foo.html#link, then hit back, I get to foo.html. However if I go to +foo.html#second from foo.html#link, then hit back I still go to foo.html. Not +quite sure how the anchor system works. Maybe you can take the code and go +from there. + +The patch is longer than it needs to be because I moved Nav_open_url to the end +of the file and places a declaration at the top so the other functions know +about it. This mimics the layout of the other source modules. + +I think there is something wrong with calling a_Foo_bar() in module Foo. + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:10 + +> +> I mean http auth, as in http://user:password@ww.../ +> + +the URL parser needs to understand this. Then the proper http send mechanism +needs to be used. I do not think this would be too hard. Now I have two +reasons to read the HTTP spec. + + + +Re: [Dillo-dev]the source viewer widget + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:08 + +On 22-Aug-2000 Sebastian Geerken wrote: +> Sean 'Shaleh' Perry wrote: +>> I tried to add horizontal scrollbars to the GtkText widget in +>> a_Commands_viewsource(). For whatever reason, they are not used. Passing +>> them +>> into the constructor of GtkText has no effect. Even with the policy set to +>> ALWAYS the scrollbar is shown but does not actually function. +> +> I assume you want to enable horizontal scrolling and disable line +> wrapping? +> +> You can do this by calling gtk_text_set_line_wrap (text, FALSE), but +> horizontal adjustment isn't working correctly now. This is a bug of +> Gtk+, and it will propably fixed soon (or perhaps is already), so you +> should not care about it (or fix this bug in Gtk+ :-). +> + +well i feel better. I did all the line_wrap, word_wrap calls. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 18:08 + +On 22-Aug-2000 Jorge Arellano Cid wrote: +> +> +> On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote: +> +>> we need a "DNS not found" message in the GUI +>> +>> If the DNS resolver has problems, the user has no feed back on why +> +> Actually there's a message in the status window. +> Maybe not enough, but not nonexistent. +> + +yesterday I could not reach gtk.org, lots of IO_Abort messages on a terminal. +But the GUI gave no indication. I hit Stop, then tried again and I could not +tell it was doing anything except for more abort messages on the term. + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 17:09 + +Jorge Arellano Cid wrote: +> If you want to join in this effort, that's all I need to get +> started. + +If it's ok, I'll start with DwPage, because I have some ideas on it +(I'll post to the list when something gets useful). + +(Starting with DwPage doesn't make much sense, since I'll have to +deactivate the adding of Dw widgets. ;-) + +Sebastian + + + +RE: [Dillo-dev]0.2.4 release + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-22 14:36 + +On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote: + +> we need a "DNS not found" message in the GUI +> +> If the DNS resolver has problems, the user has no feed back on why + +Actually there's a message in the status window. +Maybe not enough, but not nonexistent. + +Jorge.- + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:58 + +Jorge Arellano Cid wrote: +> [...] +> > I'm interrested in implementing tables, and the simplest approach is +> > propably nesting of DwPage's. I have already played around with it +> > (nothing directly useful, but only to test how it could work), and got +> > results which are not what I intended, but --- you can see something +> > ;-) +> +> Yes, but we have Dw widgets in the way (some not instantiable +> some not nesting well). + +No, I meant something different: I extended DilloHtml by a stack for +DwPage's, so that parts of the same html doc can be written in +different DwPage's (this is needed for tables). This works mainly, so +I think it's a useful approach. + +Sebastian + + + +Re: [Dillo-dev]0.2.4 release + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:08 + +Sean 'Shaleh' Perry wrote: +> The back option after following an anchor takes me to the last page loaded, +> not +> the location I was at before I followed the anchor. + +There are two different ways to change it: + +1. Force reloading in Nav_open_url. (Set a "must_reload = TRUE" before +"if (must_load)" or so.) Then the page will be reloaded always, so +*all* url's will be pushed on the navigation stack. (Reloading will be +quite fast. :-) + +2. The better way: Leave "not-reloading" enabled, but push the url's +on the stack "by hand". See the "else" part of "if (must_load)". I +tried to implement it, bud didn't understand how. I think it is done +in a_Nav_expect_done, but calling it (or a modified version of it) +didn't work. This is an other point worth to improve. + +Sebastian + + + +Re: [Dillo-dev]the source viewer widget + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-22 13:08 + +Sean 'Shaleh' Perry wrote: +> I tried to add horizontal scrollbars to the GtkText widget in +> a_Commands_viewsource(). For whatever reason, they are not used. Passing +> them +> into the constructor of GtkText has no effect. Even with the policy set to +> ALWAYS the scrollbar is shown but does not actually function. + +I assume you want to enable horizontal scrolling and disable line +wrapping? + +You can do this by calling gtk_text_set_line_wrap (text, FALSE), but +horizontal adjustment isn't working correctly now. This is a bug of +Gtk+, and it will propably fixed soon (or perhaps is already), so you +should not care about it (or fix this bug in Gtk+ :-). + +Sebastian + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET <egaudet@in...> - 2000-08-22 05:54 + +Le 22-Aug-2000, on m'a dit : +> +> On 22-Aug-2000 Eric GAUDET wrote: +> > Le 22-Aug-2000, on m'a dit : +> >> animated gif support +> >> +> >> improved font support +> >> +> >> cookies +> >> +> > +> > And basic html authetification too. +> > +> +> do you mean SSL kinda stuff? http auth? or actual "this is good +> HTML"? +> + +I mean http auth, as in http://user:password@ww.../ + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 22-Aug-2000 a 14:53:52 +---------------------------------- + + + +[Dillo-dev]weird bug in anchor code + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 05:28 + +http://www.gphoto.org/news.html + +The GNU Public License link points to http://www.gnu.org, but dillo +thinks it points to http://www.gphoto.org. + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 05:13 + +On 22-Aug-2000 Eric GAUDET wrote: +> Le 22-Aug-2000, on m'a dit : +>> animated gif support +>> +>> improved font support +>> +>> cookies +>> +> +> And basic html authetification too. +> + +do you mean SSL kinda stuff? http auth? or actual "this is good HTML"? + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET <egaudet@in...> - 2000-08-22 05:10 + +Le 22-Aug-2000, on m'a dit : +> animated gif support +> +> improved font support +> +> cookies +> + +And basic html authetification too. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 22-Aug-2000 a 14:07:36 +---------------------------------- + + + +[Dillo-dev]other requests + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 04:30 + +animated gif support + +improved font support + +cookies + + + +Re: [Dillo-dev]GTK 1.3.1 + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 04:28 + +> May I suggest one of the following: +> +> * BUG#27: Client side image maps +> * BUG#62: Horizontal rules (50% already done) +> * BUG#60: Png's transparent backgrounds +> * <DIV> tag? +> + +div is only truly useful once we support style sheets. Until then it has no +meaning (it is like event boxes without events otherwise). + +Another would be to make dillo properly display numbered lists. Currently too +many newlines are shown. Compare netscape / mozilla / konqueror / whatever. + +Also, if code has: + +foo<br> +<br> + +the first br is used, any immediately following are ignored. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 00:31 + +On 21-Aug-2000 Jorge Arellano Cid wrote: +> +> Hi! +> +> Dillo-0.2.4 is ready for download! +> +> The guys at sourceforge managed to complicate file releases +> even more; I hope they change it soon... +> + +The back option after following an anchor takes me to the last page loaded, not +the location I was at before I followed the anchor. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-22 00:27 + +On 21-Aug-2000 Jorge Arellano Cid wrote: +> +> Hi! +> +> Dillo-0.2.4 is ready for download! +> +> The guys at sourceforge managed to complicate file releases +> even more; I hope they change it soon... +> + +we need a "DNS not found" message in the GUI + +If the DNS resolver has problems, the user has no feed back on why + + + +[Dillo-dev]0.2.4 release + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 16:51 + +Hi! + +Dillo-0.2.4 is ready for download! + +The guys at sourceforge managed to complicate file releases +even more; I hope they change it soon... + +Anyway, the file is there. + +Enjoy! +Jorge.- + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:28 + +Sebastian, + +> What is the current state in: +> +> 1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and +> 2. tables? + +Basically what I wrote in 'DilloWidget.txt' (within /doc dir). +I was expecting some help to start porting back Dw to GTK+ +(unless a better approach was pointed out). + +> I'm interrested in implementing tables, and the simplest approach is +> propably nesting of DwPage's. I have already played around with it +> (nothing directly useful, but only to test how it could work), and got +> results which are not what I intended, but --- you can see something +> ;-) + +Yes, but we have Dw widgets in the way (some not instantiable +some not nesting well). + +> There should propably a widget for tables + +Of course! + +> [...] + +Looks quite similar to DilloWidget.txt! + +> So, what is currently planned on this topic? + +A question to Peter Mattis for advice on the table widget +implementation, and to start by porting back Dw to GTK+, and +finally, to work the table widget. + +If you want to join in this effort, that's all I need to get +started. +BTW: I wrote the widget documentation with a view to help it +happen ;-) + + +Jorge.- + + + +Re: [Dillo-dev]GTK 1.3.1 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:17 + +Jörgen, + +> Hi all! +> +> I recently downloaded the devel branch of GTK and tried it with Dillo. I'm +> pleased to see that the exposure problems are not there anymore. I could +> remove the event boxes from the checkboxes and radio buttons. + +!!??? +Funny, I always thought that the problem was with Dw. Even +more, the event boxes were designed for widgets lacking a window, +just a the ones we had. + +Unless the new GTK+ provides a default window for every widget, +I'm a little puzzled with this. + +> There were no problems porting the code either. + +Let's keep the event boxes for now (it will be a long time +until updating makes 1.3.1 the default GTK+). + +> PS. I really need something to code on instead of writing stuff like this +> ;-) + +May I suggest one of the following: + +* BUG#27: Client side image maps +* BUG#62: Horizontal rules (50% already done) +* BUG#60: Png's transparent backgrounds +* <DIV> tag? + + +Jorge.- + + + +Re: [Dillo-dev]dillo can't read pngs on gphoto.org + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-21 01:16 + +Sean, + +> So, I was making dillo ignore the text between SCRIPT tags (it puts them in the +> stash, then ignores the stash) + +Good! + +> I was looking for test sites. gphoto.org is a +> good one. It uses roll overs and what not for fancy browsing. While looking +> around the site I notice that dillo often fails to render the pngs it find +> there. Anyone mind looking at this and suggesting why? + +This is BUG#4. +I went to gphoto with 0.2.4 and everything was OK. + +Anyway, I'm planning to release 0.2.4 tomorrow in the morning! + +Jorge.- + + + +[Dillo-dev]the source viewer widget + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-21 00:27 + +I tried to add horizontal scrollbars to the GtkText widget in +a_Commands_viewsource(). For whatever reason, they are not used. Passing them +into the constructor of GtkText has no effect. Even with the policy set to +ALWAYS the scrollbar is shown but does not actually function. + + + +[Dillo-dev]dillo can't read pngs on gphoto.org + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-20 21:45 + +So, I was making dillo ignore the text between SCRIPT tags (it puts them in the +stash, then ignores the stash) I was looking for test sites. gphoto.org is a +good one. It uses roll overs and what not for fancy browsing. While looking +around the site I notice that dillo often fails to render the pngs it find +there. Anyone mind looking at this and suggesting why? + +On the SCRIPT reading, the stash is a great thing. When we get around to +adding script support, we just pass the stash to the interpreter. + + + +[Dillo-dev]GTK 1.3.1 + +From: Jörgen Viksell <vsksga@ho...> - 2000-08-19 23:32 + +Hi all! + +I recently downloaded the devel branch of GTK and tried it with Dillo. I'm +pleased to see that the exposure problems are not there anymore. I could +remove the event boxes from the checkboxes and radio buttons. +There were no problems porting the code either. + +PS. I really need something to code on instead of writing stuff like this +;-) + +// Jörgen +________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com + + + +Re: [Dillo-dev]Question + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:22 + +Okki, + +> Hi, +> +> Can we have a CVS (read only ?) acces for the sources ? +> +> Thanx + +This is a good idea, and we have the possibility to set it up +in sourceforge. The problem is with me, not savvy in CVS and too +busy to be in charge of it. Anyway, if the volunteer arises, no +problem. + +Jorge.- + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:21 + +Sean, + +> >> Alternatively, what do you think about getting rid of the location +> >> window and Ctrl-L fucing the cursor to the location bar? + +Just as Andrew pointed out, the idea is to move the text cursor + +> one use most browsers give their location window is a file chooser so it is +> easy to browse local html directories, like those in library docs. dillo +> currently has no way to do this and removing the location window would give no +> obvious place to put this functionality. + +There's a way: File | Open File. (Ctrl-O) +Unfortunately, the shortcut-keys code is somewhat buggy and +needs a revision. + +Anyway, you can type 'file:' in the location bar. + +Maybe I'll let everyone test the feature with Ctrl-N (New), +having the same functionallity of the "NEW" button. + +Jorge.- + + + +Re: [Dillo-dev]I18n + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-19 20:21 + +Sebastian, + +> Jorge Arellano Cid wrote: +> > Personally, I hate internationalization. (This is just my +> > personal feel on the subject). +> > [...] +> +> I, personally, cannot confirm this, my experiences with traductions +> (into german) are quite good. + +Germans are serious people! :-) + +> [...] +> Of course, any other tasks, mainly writing the .po files (the message +> tables), currently have very low priority. + +Let's work the code base for tables. I'll answer your post ASAP +(basically I also think better to lean on GTK+). + +> > I think that if we +> > manage to provide those "mission critical" ones, a growing +> > community will provide patches for the others; but if we fail +> > with the critical ones, the whole project could get stuck and ... +> +> >From this point of view, you are right: after a specific point +> (assumed it will be reached), productivity somehow grows. (Why is it +> not possible to use "quasi" as an adverb in english? ;-) + +Hmmmm, sometimes they use 'almost', and certainly some of those +prefer to express it in a ironic way! ;) + + +Jorge.- + + + +RE: [Dillo-dev]Dw vs. Gtk + +From: Eric GAUDET <egaudet@in...> - 2000-08-19 16:26 + +Le 19-Aug-2000, on m'a dit : +> I'm interrested in implementing tables, +... +> It could be implemented as Dw or as Gtk+ widget. The latter would +> have following effects: +> +> - It would be simpler to write, since I know Gtk+ better that Dw +> (and there are much more examples :-) +> +.... +> +> So, what is currently planned on this topic? +> +> Sebastian +> + +I guess you're elected to implement tables in dillo : congratulations +;-) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 20-Aug-2000 a 01:22:35 +---------------------------------- + + + +[Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-19 09:26 + +What is the current state in: + +1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and +2. tables? + +I'm interrested in implementing tables, and the simplest approach is +propably nesting of DwPage's. I have already played around with it +(nothing directly useful, but only to test how it could work), and got +results which are not what I intended, but --- you can see something +;-) + +There should propably a widget for tables (I think it should be +written from scratch, since the Gtk+ containers do not exactly provide +the functionality for this problem). It could be implemented as Dw or +as Gtk+ widget. The latter would have following effects: + +- It would be simpler to write, since I know Gtk+ better that Dw (and +there are much more examples :-) + +- Perhaps the table widget should itself contain Gtk+ widgets. So, +until DwPage gets gtk'd (or not), there is a wrapper widget needed as +container for DwPage. Currently, only GtkDwView may contain a Dw +widget, but cannot be used for this case. + +- One function of Dw is not provided by Gtk+: changing only one +dimension (normally the width), which then affects the other. This had +to be added. + +- The well known problems would be eliminated. + +So, what is currently planned on this topic? + +Sebastian + + + +Re: [Dillo-dev]I18n + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-19 09:26 + +Hi, Jorge! + +Jorge Arellano Cid wrote: +> Personally, I hate internationalization. (This is just my +> personal feel on the subject). +> +> This mostly because: +> +> - I understand english! +> +> - Living in a spanish-speaking country, had brought several +> nasty experiences related with it. Bad traductions, +> missconfigured systems, and impossible to understand spanish +> books. +> [...] + +I, personally, cannot confirm this, my experiences with traductions +(into german) are quite good. But I think this is no point. (You are +free to unset your $LANG variable ;-) + +> I can also see several tasks (like this one, download +> implementation, etc), that can be added easily, my main concerns +> are not with them but with those that can affect the whole +> project (as not being able to render tables). + +I only meant to prepare dillo, i. e. only include "_" and "_N". I +personally think, it should always be included from the beginning, +since it gets quite hard to add it to an existing project. Then use of +"_" and "_N" is quite simple (assumed you remember it ;-). + +Of course, any other tasks, mainly writing the .po files (the message +tables), currently have very low priority. + +> I think that if we +> manage to provide those "mission critical" ones, a growing +> community will provide patches for the others; but if we fail +> with the critical ones, the whole project could get stuck and ... + +From this point of view, you are right: after a specific point +(assumed it will be reached), productivity somehow grows. (Why is it +not possible to use "quasi" as an adverb in english? ;-) + +Sebastian + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-19 00:39 + +>> +>> Alternatively, what do you think about getting rid of the location +>> window and Ctrl-L fucing the cursor to the location bar? +> +> Cool! +> +> Is it OK with you Sean? +> + +one use most browsers give their location window is a file chooser so it is +easy to browse local html directories, like those in library docs. dillo +currently has no way to do this and removing the location window would give no +obvious place to put this functionality. + + + +[Dillo-dev]Question + +From: Okki <okki@wa...> - 2000-08-18 22:46 + +Hi, + +Can we have a CVS (read only ?) acces for the sources ? + +Thanx + + + +RE: [Dillo-dev]Misc. answers. + +From: Andrew McPherson <andrew@ma...> - 2000-08-17 19:35 + +On Thu, 17 Aug 2000, Sean 'Shaleh' Perry wrote: + +> +> On 16-Aug-2000 Jorge Arellano Cid wrote: +> > +> > Eric, +> > +> >> Le 15-Aug-2000, on m'a dit : +> >> > > Anyway, we can get rid of the open +> >> > > location window (because the location bar provides the same +> >> > > functionality). +> >> > > Comments? +> >> > > +> >> > +> >> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> >> > never move +> >> > my mouse. +> >> > +> >> +> >> Alternatively, what do you think about getting rid of the location +> >> window and Ctrl-L fucing the cursor to the location bar? +> > +> > Cool! +> > +> > Is it OK with you Sean? +> > +> +> Hey, it's your project. I was always told to never move the mouse. How about +> testing this feature and leaving the other code #if 0'ed out? +> + +Sorry to jump in on the conversation. I haven't posted anything in a +while. + +I think he means move the text cursor to the location bar, not the mouse +pointer. Moving the mouse pointer would be a bit strange- it reminds me of +hitting the "start menu" button on Windows keyboards. Ugh. Moving the text +cursor would be nice, though, as long as it selected the current location. +That way I could still do Ctl-L, then type, without having to manually +delete the existing location. + +Just my $.02 + +-Andrew + + + +Re: [Dillo-dev]I18n + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-17 18:58 + +> +> I can also see several tasks (like this one, download +> implementation, etc), that can be added easily, my main concerns +> are not with them but with those that can affect the whole +> project (as not being able to render tables). I think that if we +> manage to provide those "mission critical" ones, a growing +> community will provide patches for the others; but if we fail +> with the critical ones, the whole project could get stuck and ... +> + +the html renderer should render the page in whatever language it was told the +page was. More on this as I (we) add <meta> tag and HTML 4.x support. + +The part we care about for code is the actual gui -- i.e. menus, buttons, etc. + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-17 18:53 + +On 16-Aug-2000 Jorge Arellano Cid wrote: +> +> Eric, +> +>> Le 15-Aug-2000, on m'a dit : +>> > > Anyway, we can get rid of the open +>> > > location window (because the location bar provides the same +>> > > functionality). +>> > > Comments? +>> > > +>> > +>> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +>> > never move +>> > my mouse. +>> > +>> +>> Alternatively, what do you think about getting rid of the location +>> window and Ctrl-L fucing the cursor to the location bar? +> +> Cool! +> +> Is it OK with you Sean? +> + +Hey, it's your project. I was always told to never move the mouse. How about +testing this feature and leaving the other code #if 0'ed out? + + + +Re: [Dillo-dev]I18n + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:11 + +Sebastian, + +> Hi! +> +> When dillo is supposed to be used by end users (in the future ;-), +> perhaps we should start to internationalize it. Soon, because it gets +> more difficult the more the project advances. From the view of a +> programmer, gettext is quite simple to use (and can easily be +> deactivated on systems on which it is not supported). +> [...] +> What do you think about this? + +Personally, I hate internationalization. (This is just my +personal feel on the subject). + +This mostly because: + +- I understand english! + +- Living in a spanish-speaking country, had brought several +nasty experiences related with it. Bad traductions, +missconfigured systems, and impossible to understand spanish +books. + +............................................................... +For instance: + +'case sensitive' : "sensible al caso". (awful!) +("hace diferencia entre mayúsculas y +minúsculas" is the right one) + +'Save' : 'Salvar' (to escape danger! instead of 'Grabar') + +'Do you want to delete (Y/N)' +'Desea borrar el archivo (S/N)' +You got to answer 'Y' to get the job done! + +Not to mention the big mess with Hotkeys (not mnemonic anymore) + +Translated manpages on missconfigured terminals: +'había un niño' becomes 'hab<ED>a un ni<F1>o' +(this is a big problem when you're not root) + +Finally, when traductions are larger (in characters) than the +original sentences, they often render truncated. +............................................................... + + +I'm not against been understood in other languajes, is just +that my experiences are bad with it, except when the SW authors +include their own support (i.e. they provide the translations, +menu arrangements, new hotkeys and things like that). + +I can also see several tasks (like this one, download +implementation, etc), that can be added easily, my main concerns +are not with them but with those that can affect the whole +project (as not being able to render tables). I think that if we +manage to provide those "mission critical" ones, a growing +community will provide patches for the others; but if we fail +with the critical ones, the whole project could get stuck and ... + + +Jorge.- + +-- + +Ps: The guys from Intel (Taiwan) told me that dillo was ported +to the StrongARM-110 and StrongARM-11x0 boards. + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:11 + +Eric, + +> Le 15-Aug-2000, on m'a dit : +> > > Anyway, we can get rid of the open +> > > location window (because the location bar provides the same +> > > functionality). +> > > Comments? +> > > +> > +> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> > never move +> > my mouse. +> > +> +> Alternatively, what do you think about getting rid of the location +> window and Ctrl-L fucing the cursor to the location bar? + +Cool! + +Is it OK with you Sean? + +Jorge.- + + + +Re: [Dillo-dev]Html Parser + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:10 + +Sebastian, + +> Is there any reason for a separate function list F_list in html.c. Why +> are the functions not directly integrated in the Tags list (static +> TagInfo Tags[NTAGS])? + +Once upon a time there was one, but I don't remember it now! ;) + +Sean provided me with a patch for that, so consider it done. + +Jorge.- + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-16 17:10 + +Sean, + +> In previous projects, smaller patches over time were easier to get applied +> than one giant "I changed everything" patch. But each group is different. + +My point is that as each patch modified the former, I had to +study them all. (And YES, I also prefer small patches). + +> [...] +> > I found a better place that needs a single call to the entity +> > parsing function. Not implemented yet, but if it works, I'll keep +> > it. +> > +> +> that would be cool, I have not quite understood all that is html.c + +Well, it seems I'll keep the old scheme. The entities parsing +could have been handled in Html_write, but that requires to show +unsupported tags as words (not bad, but the standar advices to +ignore them). + +> >> loading large images is rather slow, I noticed this on screen +> >> shot pages +> +> > Maybe due to ... +> +> nope, simply going to some guys web page with a 1200x100 screen shot. + +I guess you are comparing the time with another browser... +There's a tricky way to speed up image transfers on slow +networks: If you get a Content-Length tag from the web server, +you can use HTTP1.1 to open new connections to start retrieving +partial chunks of unreceived data... + +I remember that sometime ago I started donloading a big image +with Netscape and after a while, started dillo to do the same; +dillo finished first and Netscape took a lot more to finish (Not +only Network traffic, also the specific HTTP-connection can be +significant sometimes). + +> the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. +> I will have to set up a cgi and test it more thoroughly. + +Not the server expecting a cookie? (unsuported in dillo) + + +Jorge.- + + + +[Dillo-dev]I18n + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-15 11:25 + +Hi! + +When dillo is supposed to be used by end users (in the future ;-), +perhaps we should start to internationalize it. Soon, because it gets +more difficult the more the project advances. From the view of a +programmer, gettext is quite simple to use (and can easily be +deactivated on systems on which it is not supported). + +I do not mean to start writing .po files, but simply prepare dillo by +using the "_" and "_N" macros, and define them as + +#define _(s) (s) +#define _N(s) (s) + +somewhere. Then, use of these macros should become part of the coding +standards. After this, the following tasks could be done later: + +- adding calls of setlocale() and textdomain(), and +- writing .po files. + +What do you think about this? + +Sebastian. + + + +[Dillo-dev]Html Parser + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-15 10:42 + +Hi! + +Is there any reason for a separate function list F_list in html.c. Why +are the functions not directly integrated in the Tags list (static +TagInfo Tags[NTAGS])? + +Sebastian. + + + +[Dillo-dev]Dillo on StrongARM + +From: <chester@li...> - 2000-08-15 10:34 + +Hi all, +I am glad to let you know that,dillo is port to StrongARM-110 and +StrongARM-11x0 board. +And I hope dillo will more strong!! + + +Best regards, + +Chester + + + +RE: [Dillo-dev]Misc. answers. + +From: Eric GAUDET <egaudet@in...> - 2000-08-15 09:41 + +Le 15-Aug-2000, on m'a dit : +> > Anyway, we can get rid of the open +> > location window (because the location bar provides the same +> > functionality). +> > Comments? +> > +> +> please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> never move +> my mouse. +> + +Alternatively, what do you think about getting rid of the location +window and Ctrl-L fucing the cursor to the location bar ? + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 15-Aug-2000 a 18:39:05 +---------------------------------- + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-15 08:47 + +> +> From the four patches you sent on the same thing, I finally +> kept the full entities list and used a libc binary search call. +> There're some interesting points: +> +> - All the isocodes in the list are not supported by current +> font (Some of them don't render). +> - Performance is a very relative subject here (commented below) +> +> (more on this subject near the bottom) +> + +My apologies on the rapid patches. I am used to people who want them early. +Plus I get eager (-: + +I hope I did not actually send you four identical files, I seem to recall each +adding onto the last. But yes, I could have held them and sent one big patch. + +In previous projects, smaller patches over time were easier to get applied than +one giant "I changed everything" patch. But each group is different. + +>> {Sean} +>> So, I used dillo some more today. yp.yahoo.com has a submit button whose +>> text +>> is: "Start Search". This is not handled by dillo either. So, I went +>> thru +>> and added Html_parse_entities() calls in a few more places. Now I need to +>> handle the memory use associated with this, right now I am leaking small +>> bits +>> of memory. Once I get this sorted out I will send a new patch. +> +> I found a better place that needs a single call to the entity +> parsing function. Not implemented yet, but if it works, I'll keep +> it. +> + +that would be cool, I have not quite understood all that is html.c + +>> {Sean} +>> The open location window does not seem to set itself as a transient. +>> This causes several window managers to hide the window when it opens. It +>> should load on top of the browser window. This window too could use some +>> beautification. +> +> Yes, that semms to be a bug. Anyway, we can get rid of the open +> location window (because the location bar provides the same +> functionality). +> Comments? +> + +please keep it. This allows me to "Ctrl-L, http://foo, enter" and never move +my mouse. + +>> loading large images is rather slow, I noticed this on screen +>> shot pages +> +> Mmmmm.... There's no special handling for image connections. +> Maybe you were downloading another document while fetching the +> page. This seems weird at the beginning, but it's possible! +> + +nope, simply going to some guys web page with a 1200x100 screen shot. + +>> {Sean} +>> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +>> reading the HTTP spec and looking at a proper implementation of this. If +>> anyone else is looking at this, let me know. +> +> I read your complaints on GET method too, the bug track engine +> uses GET and I've used POST without any problems. I'm not saying +> it's perfect, but can you be more specific please? +> + +the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. +I will have to set up a cgi and test it more thoroughly. + +> +> Performance is a very relative subject here. Mainly because +> entities are scarce in the average HTML page (a minimal ratio), +> and because the Html_parse_entities function, returns without +> any searching almost all of the time (when the word doesn't have +> entities). +> + +absolutely, however, I do go to sites where there is an entity on every line. + + + +[Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-14 22:16 + +Hi everyone! +(I've been a bit overworked and also caught by a cold, I hope +that explains my disappearance ;) + + +Here I'll try to answer queued stuff: + +> {Sean} +> Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok +> plus I added some more checking around the .dillo directory at startup. + +Integrated (done). + +> {Sean} +> Enclosed is a patch for #68. My solution was to pull the call to +> Html_parse_entities() out of the else, so it will get called regardless of the +> current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include +> a len member and simply added the length of every entity to the array. +> ... by adding the len field the call to +> strlen() is removed from the for loop. This should help the performance of +> Html_parse_entities some. + +From the four patches you sent on the same thing, I finally +kept the full entities list and used a libc binary search call. +There're some interesting points: + +- All the isocodes in the list are not supported by current +font (Some of them don't render). +- Performance is a very relative subject here (commented below) + +(more on this subject near the bottom) + +> {Sean} +> So, I used dillo some more today. yp.yahoo.com has a submit button whose text +> is: "Start Search". This is not handled by dillo either. So, I went thru +> and added Html_parse_entities() calls in a few more places. Now I need to +> handle the memory use associated with this, right now I am leaking small bits +> of memory. Once I get this sorted out I will send a new patch. + +I found a better place that needs a single call to the entity +parsing function. Not implemented yet, but if it works, I'll keep +it. + +> {Sebastian} +> I encounterd a bug which sounds very simimar to #69: +> +> When I go to " +> and then, before the page is completely loaded (chances are quite good, +> since it is rather long), click on a link at the top, dillo starts to +> load and show the new page, but after a second or so *allways* crashes. + +Yes, I'll try to explain that here: + +That happens cause the IO engine is not finished yet. When you +load a page, and start loading another before the former +finishes, the IO emgine keeps loading and feeding both! (a sure +way for crashes). +That happens with the main page, not with images (unless the +image is the main page). +Images within an HTML page have already an aborting mechanism, +within the image sink, so the browser doesn't crash with these. + +A correct solution for this problem is not an easy task (I have +some ideas, but queued in favor of table support). + +> {Sean} +> Enclosed is a patch that includes the changes to html.c I sent last time along +> with the additional changes so that entities are checked for in FORM inputs +> as well. As far as I can tell, all entities are caught now. + +I hope the previous solution to work with forms too... + +> Also in my patch is a bug fix for Html_parse_entities(). If the html contained +> a malformed entity, i.e. "&", the output would be "mp". This would be a +> good item to add to test case html files. Another would be "&cpy;", which is +> copyright with a typo. This flexes the case where it is a valid form of an +> entity, but not a matching entity. + +In the spirit of XHTML, I don't aim to support "malformed" HTML +pages. Anyway, the bug fix is OK (I mean, unrecognized "entities" +must be rendered as a word). + + +> {Sean} +> The open location window does not seem to set itself as a transient. +> This causes several window managers to hide the window when it opens. It +> should load on top of the browser window. This window too could use some +> beautification. + +Yes, that semms to be a bug. Anyway, we can get rid of the open +location window (because the location bar provides the same +functionality). +Comments? + +> loading large images is rather slow, I noticed this on screen +> shot pages + +Mmmmm.... There's no special handling for image connections. +Maybe you were downloading another document while fetching the +page. This seems weird at the beginning, but it's possible! + +As you all may have noticed, dillo doesn't handle downloads +yet, but if you click on a link that has an unhandled MIME type, +the download starts, and is not aborted (see explanation above). +Furthermore, if you wait until it's got, you can put the url in +the location bar and force dillo to go there (nothing will be +rendered), and after that, hitting save does the trick! + +If not the case, I'm sure someone will appreciate the trick :) + +> The number of images gauge often shows "N of M" instead of "N of N", +> i.e. "20 of 23". Why are some images not getting loaded? + +Another subtle explanation! +Images are got in general, the problem is that the gauge is not +updated right (yes, a Bug). + +I say in general, because when the image hits a redirection, +it's not retrieved (not a bug, but lack of implementation). + +> {Sean} +> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +> reading the HTTP spec and looking at a proper implementation of this. If +> anyone else is looking at this, let me know. + +I read your complaints on GET method too, the bug track engine +uses GET and I've used POST without any problems. I'm not saying +it's perfect, but can you be more specific please? + +> {Sean} +> I re-did the core of Html_parse_entities(). The named entity check is now a +> binary search. Also added a few checks so that malformed html never makes it +> in to be checked. +> +> My initial tests show the new version is about twice as fast as the old one. +> [...] +> 76.92 0.10 0.10 6000 16666.67 16666.67 Html_parse_entities +> 15.38 0.12 0.02 main +> 7.69 0.13 0.01 6000 1666.67 1666.67 Html_parse_entities2 +> [...] +> Because a binary search is now used and I changed the code layout, the entity +> list no longer needs my previous addition of length values. This patch removes +> them. + +Performance is a very relative subject here. Mainly because +entities are scarce in the average HTML page (a minimal ratio), +and because the Html_parse_entities function, returns without +any searching almost all of the time (when the word doesn't have +entities). + +Anyway, testing with a page that has a "high entity ratio", +profiling shows that the time spent in Html_parse_entities is no +more that 5%, so optimizing the (5%xratio) is not very +significant. Even more, the older scheme used a linear search, +but its first items where the most expected entities, so it +usually performed better than the binary search. + +Please don't get me wrong, I was amazed too, so I pushed it +further and implemented a minimal perfect hash function for the +whole entities list. Guess what, the MPH function was slightly +faster than the binary search, but not worth the added complexity +though. The funny thing is that it was slower than the linear +search for pages that only used the top five entities of the +list! + +Knowing that since ISO-LATIN1 was adopted as the standar +charset for HTML (strongly decreasing the entities use), and +considering several other facts, I decided to trade off and used +a libc binary search and with the large entity list. + +---- + +Some final suggestions: + +- Please don't rush your patches to me. It's much better to +hold on for a while, test them thoroughly and finally sending +them. + +- Please don't post things you're not sure off without stating +clearly your doubts (Just to avoid confussion). + +- Please bear in mind that this is a public list and that +several persons read it. Think carefully what you post and +be as concise as you can. + + +I want to thank everyone that was kind enough to read this far, +and also want to thank the whole developing team for the +excellent work, and in particular, the polite bounds into which +we all agreed to express ourselves. + + +Sincerely +Jorge.- + + +Ps: I'm studying Sebastian's code and trying to find a way to +integrate the scroll-position remind feature into it. + + + +Re: [Dillo-dev]meta refresh support, and form POST + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-12 00:33 + +> +> Something like this might work: +> +> gboolean stuff_to_do(gpointer data) +> { +> Do the stuff that is to be done... +> +> return FALSE; +> } +> +> g_timeout_add(milliseconds, stuff_to_do, NULL); +> + +right, but the problem with a call back is I have to arrange for it to get data +somehow. Which would me some kind of global data )-: + +Will consider the possibilties though. + + + +Re: [Dillo-dev]some thoughts + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-12 00:32 + +On 11-Aug-2000 Sebastian Geerken wrote: +> Sean 'Shaleh' Perry wrote: +>> [...] +>> the view source window has the ok button at the bottom. It makes the +>> window +>> look ugly and is generally useless. +> +> What about starting an external text viewer, determined by the user? +> Dillo could write the content into a temporary file, or pipe it through +> stdin. The builtin text viewer could be left as standard, but should not +> be improved. +> + +nah, that is over kill. If the close button is removed, the window looks just +like netscape's -- just without syntax highlighting. + + + +Re: [Dillo-dev]meta refresh support, and form POST + +From: Jörgen Viksell <vsksga@ho...> - 2000-08-11 19:55 + +>Implementation question: the format is content="2;URL= +>where +>the '2' is the number of seconds before loading the page. How should I get +>this pause without freezing the browser? My current code ignores the +>delay completely. + +Something like this might work: + +gboolean stuff_to_do(gpointer data) +{ +Do the stuff that is to be done... + +return FALSE; +} + +g_timeout_add(milliseconds, stuff_to_do, NULL); + +// Jörgen + + + +________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com + + + +Re: [Dillo-dev]some thoughts + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-11 10:04 + +Sean 'Shaleh' Perry wrote: +> [...] +> the view source window has the ok button at the bottom. It makes the +> window +> look ugly and is generally useless. + +What about starting an external text viewer, determined by the user? +Dillo could write the content into a temporary file, or pipe it through +stdin. The builtin text viewer could be left as standard, but should not +be improved. + +Sebastian. + + + +[Dillo-dev]meta refresh support, and form POST + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-11 08:46 + +I am working on meta refresh support. This causes dillo to crash just like the +previously mentioned "click a link before the text is finished rendering" bug. +So, looks like I get to kill two birds with one stone (-: + +Implementation question: the format is content="2;URL= where +the '2' is the number of seconds before loading the page. How should I get +this pause without freezing the browser? My current code ignores the +delay completely. + +Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +reading the HTTP spec and looking at a proper implementation of this. If +anyone else is looking at this, let me know. + +I have mailed Jorge several patches this week for improved entity support and +some minor speed improvements to html.c in general. + +See you all in a week (-: I will be reading mail sporadically. + + + +[Dillo-dev]some thoughts + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-10 23:56 + +Been using dillo off and on for most of this week. My list of little gripes so +far: + +the view source window has the ok button at the bottom. It makes the window +look ugly and is generally useless. + +The open location window does not seem to set itself as a transient. This +causes several window managers to hide the window when it opens. It should +load on top of the browser window. This window too could use some +beautification. + +loading large images is rather slow, I noticed this on screen shot pages + +the number of images gauge often shows "N of M" instead of "N of N", i.e. "20 +of 23". Why are some images not getting loaded? + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-09 00:31 + +Sebastian, + +> > [...] +> > It should work in a reasonable way! +> > I mean, in a clear, unambiguous, and practical way. +> > (And finally we can always count on the always-reloading +> > scheme; dillo is very fast doing that). +> +> Yes, this is true. By testing I found that even long pages are reloaded +> in a reasonable time. +> +> Nevertheless, "not-reloading" is a nice feature, + +Of course it is. + +> but still not fully +> complete, and I will stop writing on it in the next time (meanwhile I am +> sucked of this whole problem :-). + +I've been there... + +> It will be deactivated it in the +> patch, but I think it should be left as an option for future extensions. +> +> Shall I remove and put it in a separate patch, or leave it in the code, +> but deactivate (#if 0 ... #endif) it? + +#if 0, it (I want to study the code anyway) + + +> PS: Is it possible to include .php pages or so into the html test suite? +> I used it to create some extreme situations, e. g. slowing down reading +> by including "<?php sleep(10); ?>". + +If that's to de done, I'd prefer it to have its own tarball. +Not everyone has a php-configured web server running. I like the +idea though. + + +Jorge.- + + + +RE: [Dillo-dev]Bug #69 + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-08 20:06 + +On 08-Aug-2000 Sebastian Geerken wrote: +> Hi! +> +> I encounterd a bug which sounds very simimar to #69: +> +> When I go to " +> and then, before the page is completely loaded (chances are quite good, +> since it is rather long), click on a link at the top, dillo starts to +> load and show the new page, but after a second or so *allways* crashes. +> + +I can confirm this. Most pages load so fast in dillo that this is hard to test +(-: But try this: + +go to a search engine page, search and as soon as a link appears click it. +Just keep clicking links as fast as they appear (who cares where they go). I +found about three or so in dillo dies. Most likely the result of lack of +function return value checking. + + + +[Dillo-dev]Bug #69 + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-08 15:47 + +Hi! + +I encounterd a bug which sounds very simimar to #69: + +When I go to " +and then, before the page is completely loaded (chances are quite good, +since it is rather long), click on a link at the top, dillo starts to +load and show the new page, but after a second or so *allways* crashes. + +(You will get the wrong page because of bug #65, but after fixing the +bug, it remains the same.) + +If you wait, until the page has been loaded completely, all works. + +I hope this will helpful. + +Sebastian. + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-08 12:58 + +Hi, Jorge! + +Jorge Arellano Cid wrote: +> > > Maybe, if the timeout function validates itself, the problem can +> > > be addressed in a simpler way. I mean, let the timeout function +> > > start, poll until it finds the #anchor, then set its AnchorFound +> > > flag and to continue correcting the value until: +> > > +> > > - #anchor is not found anymore or +> > > - user scrolls the page (either with keyboard or with mouse) +> > > When one of those happens, it removes itself. +> > +> > Changing of anchor positions depends of other things (e. g. images), so +> > this is not the point. +> +> I meant that it'd be clearer to let the timeout function remove +> itself, than to push a removal function into another function +> (an attempt to avoid coupling). + +Yes, this has been done from the beginning (except only two cases: +Dw_gtk_scroller_destroy, and before a new timeout function is started). + +> > An other point: A new behavior, which I have implemented, is, that the +> > page is *not* reloaded (even from cache) in some cases. Currently: if +> > old and new url are the same *and* there is no #anchor. In this case the +> > url is pushed, the scroller jumps to the anchor, but nothing is done +> > else. +> +> Interesting; careful considerations must be done though... +> +> > As I have seen, the HTML spec does not say anything about this, so how +> > should it work at the end? +> +> It should work in a reasonable way! +> I mean, in a clear, unambiguous, and practical way. +> (And finally we can always count on the always-reloading +> scheme; dillo is very fast doing that). + +Yes, this is true. By testing I found that even long pages are reloaded +in a reasonable time. + +Nevertheless, "not-reloading" is a nice feature, but still not fully +complete, and I will stop writing on it in the next time (meanwhile I am +sucked of this whole problem :-). It will be deactivated it in the +patch, but I think it should be left as an option for future extensions. + +Shall I remove and put it in a separate patch, or leave it in the code, +but deactivate (#if 0 ... #endif) it? + +Sebastian. + +PS: Is it possible to include .php pages or so into the html test suite? +I used it to create some extreme situations, e. g. slowing down reading +by including "<?php sleep(10); ?>". + + + +RE: [Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-07 23:53 + +On 07-Aug-2000 Jorge Arellano Cid wrote: +> +> Sean, +> +> First of all, I want to welcome you to the project and to thank +> your first patch contributions (just integrated the first one; +> look at the bug-track). +> + +thanks, it is nice to have a free browser again (-: Hope to have all of #68 +done in the next few days. + +> +> Ps: Please don't send patches to the mailing list, send them +> directly to me (or privately upon request). +> + +will do. + + + +RE: [Dillo-dev]bug #68 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-07 23:19 + +Sean, + +First of all, I want to welcome you to the project and to thank +your first patch contributions (just integrated the first one; +look at the bug-track). + +> The functions without header comments (/* ? */), do we desire them to be +> commented? + +Yes! (It'd be great if we ever get the full source commented). + + +Jorge.- + +Ps: Please don't send patches to the mailing list, send them +directly to me (or privately upon request). + + + +Re: [Dillo-dev]Re: Plugins (was: Misc. answers) + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-07 23:19 + +Eric, + +> What's good in using http rather than a raw html page? I'm afraid http would +> need much more code (libs) to do for a very small benefit (I can't even name +> one :-/). + +Take it easy, all you'll need to do is to output the HTML page +with a HTTP content header: + +························· +Content-Type: text/html + +<HTML> +... +</HTML> +························· + +You may also add a "Content-Length" field, but that's not a +requirement (this is exactly the same way we use to handle local +files). + +> ... or are we talking about the same thing ? ;-) + +Yes. +(No MIME, no libs, no complicated stuff, just a minimal HTTP +header). + + +Jorge.- + + + +RE: [Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 23:45 + +On 06-Aug-2000 Sean 'Shaleh' Perry wrote: +> Enclosed is a patch for #68. My solution was to pull the call to +> Html_parse_entities() out of the else, so it will get called regardless of +> the current DILLO_HTML_PARSE_MODE. + +So, I used dillo some more today. yp.yahoo.com has a submit button whose text +is: "Start Search". This is not handled by dillo either. So, I went thru +and added Html_parse_entities() calls in a few more places. Now I need to +handle the memory use associated with this, right now I am leaking small bits +of memory. Once I get this sorted out I will send a new patch. + +The functions without header comments (/* ? */), do we desire them to be +commented? + + + +[Dillo-dev]Gif segfault : not dillo's bug + +From: Eric GAUDET <egaudet@in...> - 2000-08-06 14:42 + +Hi all, +I've been testing dillo's image rendering for a while, and I noticed a segfault +with some gif (mostly banners, only animated ?). It's not dillo's fault, it's a +libungif fault (v4.1.0) : every imlib-dependant program segfaults. Version +4.1.0b1 corrects this bug, unfortunatly no package of this version is available +: you'll have to get the tarball from libungif site, compile and install it +yourself. Doing that, you'll break packages dependancies (imlib, ...), but +compilation and replacement is very easy. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 06-Aug-2000 a 23:35:52 +---------------------------------- + + + +[Dillo-dev]Re: est suite (was: Misc. answers) + +From: Eric GAUDET <egaudet@in...> - 2000-08-06 10:27 + +Le 05-Aug-2000, on m'a dit : +> +> ---- [Test Suite] ---- +> +> > > The main point of it is to have a set of pages to test backward +> > > rendering capabilities (not breaking what was working in former +> > > versions of dillo), and to have a record of simple things that +> > > are not working yet, but that we're close to add. +> > > +> > +> > That would be a collection of existing pages you and other developers have +> > done before. (see above) +> +> And some other interesting stuff added later. +> +> > > Just assemble a small testing suite and you'll eventually +> > > receive contributions (I have some!). +> > +> > Do you want me to assemble the pages, then send you the assemblage for +> > publishing ? I can do that. +> +> Perfect. +> + +Ok, everybody send me your pages at the address below, in a tgz, if possible +with a short description of what each page is supposed to test. I'll put them +together. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 06-Aug-2000 a 11:56:07 +---------------------------------- + + + +[Dillo-dev]Re: Plugins (was: Misc. answers) + +From: Eric GAUDET <egaudet@in...> - 2000-08-06 10:27 + +Le 05-Aug-2000, on m'a dit : +> ---- [Plugins] ---- +> +> > > The only difference is that information from the browser is +> > > passed to the plugin using its stdin, not the command line, and +> > > encoded as if the recepting program was a CGI. +> > +> > What do you mean with this CGI-thing : do you want the program to use HTTP +> > as transport, not stdout? +> +> The plugin-program outputs to its stdout in HTTP format. +> + +Herrr ... by http format, you mean a subset of it : some infos of the header +(content, cache). Not the full mime-encoding stuff, I hope. + +> > AFAIK CGIs prints to stdout for the web server. +> +> Right. +> + +an html page, plain text, no header, no http. The first bytes sent are "<html". + +What's good in using http rather than a raw html page ? I'm afraid http would +need much more code (libs) to do for a very small benefit (I can't even name +one :-/). + +... or are we talking about the same thing ? ;-) + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 06-Aug-2000 a 12:07:10 +---------------------------------- + + + +[Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 09:17 + +Attachments: dillo2.patch + +Enclosed is a patch for #68. My solution was to pull the call to +Html_parse_entities() out of the else, so it will get called regardless of the +current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include +a len member and simply added the length of every entity to the array. +Since we know what the string is, it is silly to perform the computation. +This entire array could be dynamically generated from a list of entities, +assuming the list ever changes. By adding the len field the call to +strlen() is removed from the for loop. This should help the performance of +Html_parse_entities some. + +The two patches (this one and the last one) are independent of each other. + + + +[Dillo-dev]Bug #61 patch, plus extras + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-08-06 08:37 + +Attachments: dillo.patch + +It is soooo great to see a new browser. Anyway, here is a little contribution +to the cause: + +Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok +plus I added some more checking around the .dillo directory at startup. + +To fully clean up #61, the path shown should not be: /path/to/directory/./. To +solve this I have to understand where the URL is getting sent from and where +the string displayed is shown. + +BTW, anyone have some emacs magic so I can edit the code with emacs? I used vi +for this so I could follow the coding standards. + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-05 16:46 + +Sebastian, + +> Since I had problems to understand how several modules are connected, I +> tried to minimize communication between Html/Dw and GtkDwScroller by +> using flags and timeout functions. This is a workaround, but it will +> work ;-). I will comment and document my patch as good as it is needed +> by someone else, who wants to implement it more elegant, after he has +> understood the whole code better than I. + +Excellent, keep up the good work! + +> [...] +> What does not work correct: Go to a (large) page, scroll down and resize +> the window. Since the recalculation of the position is quite simple, you +> often get to a different position. But this has nothing to do with my +> patch. (A bug? Other browsers have this problem, too.) + +Yes, that's a different problem. +I think better to solve the #anchor problem well, before we +attempt to address this new one. +Remember that we still have to support remembering the +scrolling position of previously browsed pages (maybe just saving +the vertical adjustment value in the navigation stack). +[This problem will be affected by window resizes too.] + +> > Maybe, if the timeout function validates itself, the problem can +> > be addressed in a simpler way. I mean, let the timeout function +> > start, poll until it finds the #anchor, then set its AnchorFound +> > flag and to continue correcting the value until: +> > +> > - #anchor is not found anymore or +> > - user scrolls the page (either with keyboard or with mouse) +> > When one of those happens, it removes itself. +> +> Changing of anchor positions depends of other things (e. g. images), so +> this is not the point. + +I meant that it'd be clearer to let the timeout function remove +itself, than to push a removal function into another function +(an attempt to avoid coupling). + +> An other point: A new behavior, which I have implemented, is, that the +> page is *not* reloaded (even from cache) in some cases. Currently: if +> old and new url are the same *and* there is no #anchor. In this case the +> url is pushed, the scroller jumps to the anchor, but nothing is done +> else. + +Interesting; careful considerations must be done though... + +> As I have seen, the HTML spec does not say anything about this, so how +> should it work at the end? + +It should work in a reasonable way! +I mean, in a clear, unambiguous, and practical way. +(And finally we can always count on the always-reloading +scheme; dillo is very fast doing that). + + +Regards +Jorge.- + + + +[Dillo-dev]Re: Misc. answers + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-05 16:46 + +Hi there! + +Here are some answers that were queued in my "todo:" list: + + +---- [Test Suite] ---- + +> > The main point of it is to have a set of pages to test backward +> > rendering capabilities (not breaking what was working in former +> > versions of dillo), and to have a record of simple things that +> > are not working yet, but that we're close to add. +> > +> +> That would be a collection of existing pages you and other developers have done +> before. (see above) + +And some other interesting stuff added later. + +> ... +> So, what you want basically is problem-exposing pages. + +Not only that. + +> > Just assemble a small testing suite and you'll eventually +> > receive contributions (I have some!). +> +> Do you want me to assemble the pages, then send you the assemblage for +> publishing ? I can do that. + +Perfect. + + +---- [PNG Code] ---- + +> > Finally, Geoff Lane (author of PNG support), told me it was +> > alpha code. +> > +> +> Does he still support the code, or is it up to us ? + +Geoff is not supporting it, so I guess it's up to Luca ;-) + +> I did all my testings with a png image _in_ an html page : if you don't have +> the bug when loading the page, you'll never have it when clicking reload. You +> have to quit dillo and reload the page. +> +> That strange : does dillo have a different caching behavior when the the +> "page" is an image? (it seems dillo re-decoding the image then) + +Good point! +Actually the caching scheme is only one, but cache querying is +different. When an IMG tag is found in a HTML page, the dicache +is asked for the image (decompressed image cache), and when it's +a bare URL, a_Cache_open_url is requested to do the job +(bypassing the dicache). + +The dicache code is expecting a full rewrite (I wrote that +before, but don't remember where nor to whom). + +Hope that helps. + + + +---- [Plugins] ---- + +> > The only difference is that information from the browser is +> > passed to the plugin using its stdin, not the command line, and +> > encoded as if the recepting program was a CGI. +> +> What do you mean with this CGI-thing : do you want the program to use HTTP as +> transport, not stdout? + +The plugin-program outputs to its stdout in HTTP format. + +> AFAIK CGIs prints to stdout for the web server. + +Right. + +> Will CGI environment variables be passed to the program ? (REMOTE_HOST and +> stuff) I don't see that useful. + +No, we'll forget about environment vars. + + +Jorge.- + + + +[Dillo-dev]New release! + +From: Jorge Arellano Cid <jcid@ca...> - 2000-08-04 21:39 + +Hi there, + +A lot of work and effort has been put in this release. I hope +you all enjoy the difference. +Most notably there's new extensive documentation about dillo widget +(Dw), and IO.txt has been polished. + +I'll qoute a bit from IO.txt here: + +" Data transfer between threads inside the browser is handled by +pipes, shared memory is little used. This almost obviates the +need for explicit synchronization, which is one of the main areas +of complexity and bugs in concurrent programs. Dillo handles its +threads in a way that its developers can think of it as running +on a single thread of control. This is accomplished by making the +DNS engine call-backs happen within the main thread, and by +isolating file loading with pipes." + + + +Severals bugs and leaks were fixed, and stability also improved! + +Download and enjoy! + +Jorge.- +-- + + + +RE: [Dillo-dev]Re: Eric + +From: Eric GAUDET <egaudet@in...> - 2000-08-02 04:50 + +Le 01-Aug-2000, on m'a dit : +> > then the program "bm" prints a html page in stdout (and can do something +> > else, like writing a file on the disk), which page dillo will render. +... +> +> Basically, that's the idea. +> +> The only difference is that information from the browser is +> passed to the plugin using its stdin, not the command line, and +> encoded as if the recepting program was a CGI. +> +> + +What do you mean with this CGI-thing : do you want the program to use HTTP as +transport, not stdout ? AFAIK CGIs prints to stdout for the web server. +Will CGI environment variables be passed to the program ? (REMOTE_HOST and +stuff) I don't see that useful. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 02-Aug-2000 a 13:41:55 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:15 + +Le 01-Aug-2000, on m'a dit : +> Il mar, 01 ago 2000, hai scritto: +> +> > When I read libpng docs (example.c), it has directions on +> > decoding several images at the same time, so it seems that the +> > library can handle that. +> > On the other hand, I can't reproduce the bug with a single +> > image. +> +> I can. I open a png image then click on reload button several timesand I got +> a white image. +> + +I did all my testings with a png image _in_ an html page : if you don't have +the bug when loading the page, you'll never have it when clicking reload. You +have to quit dillo and reload the page. + +That's strange : does dillo have a different caching behavior when the the +"page" is an image ? (it seems dillo's re-decoding the image then) + +> > An interesting fact is that sometimes PNGs render not +> > completely white, but with colors bleached away! (One more hint +> > towards thinking the bug is PNG specific). +> +> Me too! +> + +I'll try again with image only. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 02-Aug-2000 a 12:08:52 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> Eric, +> +> > > Bug #4 (images as white square): I can reproduce it only with PNG. Gif +> > > and jpeg works just fine. Maybe a png specific problem ?!? +> > +> > I noticed the bug is much more frequent when there is several images: I +> > wonder if my libpng is compiled reentrant. +> +> When I read libpng docs (example.c), it has directions on +> decoding several images at the same time, so it seems that the +> library can handle that. +> On the other hand, I can't reproduce the bug with a single +> image. +> + +I've done all my testings using a page with a single png image. It happens. +It is true that it happens less with only one image (maybe 1 out of 20) than +with several images (my test page with 17 png has 2 to 5 white images each +time), but it happens. I noticed it happens less with the 17-images page when I +print a lot of debug informations during decoding, thus slowing down the +process, that's why I was thinking of a reentrance bug. I'm not sure now + +> An interesting fact is that sometimes PNGs render not +> completely white, but with colors bleached away! (One more hint +> towards thinking the bug is PNG specific). +> + +I'm using 64x32 one-color images, and sometimes (rarely) I have one or two +lines of randomly colored pixels. + +> Finally, Geoff Lane (author of PNG support), told me it was +> alpha code. +> + +Does he still support the code, or is it up to us ? + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 01-Aug-2000 a 22:46:29 +---------------------------------- + + + +Re: [Dillo-dev]Html test suite + +From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> The main point of it is to have a set of pages to test backward +> rendering capabilities (not breaking what was working in former +> versions of dillo), and to have a record of simple things that +> are not working yet, but that we're close to add. +> + +That would be a collection of existing pages you and other developers have done +before. (see above) + +> For instance, a page that reproduces the white square rendering +> bug, would be useful, + +I have a page doing that. Anybody interested ? + +> The other fact to take into account, is not to devote much time +> on assembling an HTML test suite, just find a page that shows +> some problems and add it to our test list; if you can reduce its +> size, that'd be good. +> + +So, what you want basically is problem-exposing pages. + +> Just assemble a small testing suite and you'll eventually +> receive contributions (I have some!). +> +> Ps: If you want my test examples, drop me a note. +> + +Do you want me to assemble the pages, then send you the assemblage for +publishing ? I can do that. + +I'll begin with "should-work-to-be-a-good-browser" pages : some basic text +formating and character rendering : everything dillo can do now (as for +v0.2.2), plus everything (I feel) should work on any decent browser. + +If anybody needs pages to test a specific problem and is not in the mood doing +doing them by himself, just send me an email I'prepare a few pages for the next +day. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 01-Aug-2000 a 23:32:24 +---------------------------------- + + + +RE: bookmarks [Dillo-dev]Re: Eric + +From: Eric GAUDET <egaudet@in...> - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> Eric, +> +> > You said that before and I love this idea. I'd like to see a practical +> > example of plugin, even alpha stage, before I decide I can do it right. +> +> OK, I'll try to provide you with that. +> (Most probably a patch over dillo-0.2.3). +> +... +> The only difference is that information from the browser is +> passed to the plugin using its stdin, not the command line, and +> encoded as if the recepting program was a CGI. +> + +Understood. I'm interested, then. + +---------------------------------- +Eric GAUDET <egaudet@in...> +Le 01-Aug-2000 a 22:55:20 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Luca Rota <drake@it...> - 2000-08-01 23:14 + +Il mar, 01 ago 2000, hai scritto: + +> When I read libpng docs (example.c), it has directions on +> decoding several images at the same time, so it seems that the +> library can handle that. +> On the other hand, I can't reproduce the bug with a single +> image. + +I can. I open a png image then click on reload button several timesand I got a +white image. + +> An interesting fact is that sometimes PNGs render not +> completely white, but with colors bleached away! (One more hint +> towards thinking the bug is PNG specific). + +Me too! + +Ciao, +Luca + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-01 15:08 + +Hi, Jorge! + +First a few notes: + +Anchors basicly work. There are a few details and tests to do, but I do +not think I will get severe problems. So the patch will propably be +finished in a few days. + +Since I had problems to understand how several modules are connected, I +tried to minimize communication between Html/Dw and GtkDwScroller by +using flags and timeout functions. This is a workaround, but it will +work ;-). I will comment and document my patch as good as it is needed +by someone else, who wants to implement it more elegant, after he has +understood the whole code better than I. + +Jorge Arellano Cid wrote: +> If the "scroller" and "view" code was right, maybe I'd suggest +> you to try a patch based on "changed" and "value changed" +> signals, but that code is a mess! + +I've tried to catch "changed" signals, but it didn't work reliable. The +timeout function works well, and is always removed at some point (there +is no "timeout function leak"). The only problem is, that it continues +running a while without use (and so taking a not measurable amount of +CPU time ;-), but this is only a question of design, not of runtime +behaviour. + +> [...] +> I see several things here: +> +> - The timeout function should not override user scrolling +> (i.e. if the user scrolls the page with the mouse). + +I already planned this. When, e. g, the user scrolls the page, before +the requested anchor has been read *anyway* (e. g. when transmission is +very slow, and meanwhile he is interrested in the informations at the +top of the page), he should not be confused by a sudden jump to an other +position (I think so). I have added a line to Dw_gtk_view_v_scroll, and +it works. + +> - Html_close can't be trusted to happen. + +Ok, I don't use it. (It does not work either in many cases.) + +> - Image reception can't be trusted. + +I didn't use it. + +> - It would be nice to have a #anchor display function that +> doesn't get fooled with page resizes (as we're trying). + +That works. Precisely, following works: + +1. Go to an url "foo#bar" where foo is very long and "#bar" at the very +bottom, then *immediately* resize the window (before the <a name="bar"> +is read). + +2. Go to a page, wait until it is loaded, resize the window, and jump to +an anchor in the same page. + +3. Go to an url "foo#bar", wait until it is visible (e. g. transmission +is over), and resize the window. (This is not really intended, but a +side effect, since the timeout function is still running.) + +What does not work correct: Go to a (large) page, scroll down and resize +the window. Since the recalculation of the position is quite simple, you +often get to a different position. But this has nothing to do with my +patch. (A bug? Other browsers have this problem, too.) + +> Maybe, if the timeout function validates itself, the problem can +> be addressed in a simpler way. I mean, let the timeout function +> start, poll until it finds the #anchor, then set its AnchorFound +> flag and to continue correcting the value until: +> +> - #anchor is not found anymore or + +Changing of anchor positions depends of other things (e. g. images), so +this is not the point. + +> - user scrolls the page (either with keyboard or with mouse) + +See above. + +> When one of those happens, it removes itself. + +An other point: A new behavior, which I have implemented, is, that the +page is *not* reloaded (even from cache) in some cases. Currently: if +old and new url are the same *and* there is no #anchor. In this case the +url is pushed, the scroller jumps to the anchor, but nothing is done +else. + +As I have seen, the HTML spec does not say anything about this, so how +should it work at the end? + +Sebastian. + + + +[Dillo-dev]Gtk containers + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-08-01 15:08 + +Jorge Arellano Cid wrote: +[about docs] +> I think it's a matter cause it doesn't work as expected. Some +> parts are missing, some other are incomplete, and some have +> workaround tweaks. +> For instance, when Jörgen fixed the checkboxes, his code was +> right, but it didn't work because button widgets were not +> receiving the expose events. + +Perhaps a hint: The container implementations of GtkDwScroller and +GtkDwView look a bit incomplete. If you look e. g. at the source of +GtkBox, you find that there are 6 specific functions defined by +GtkContainer (like abstract virtual methods in C++), which are put into +the class structure: gtk_box_add, gtk_box_remove, gtk_box_forall, +gtk_box_child_type, gtk_box_set_child_arg and gtk_box_get_child_arg. So, +perhaps, Jörgen's code works, when GtkDwView is implemented in the +correct way. + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39 + +Eric, + +> > Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +> > jpeg works just fine. Maybe a png specific problem ?!? +> +> I noticed the bug is much more frequent when there is several images: I wonder +> if my libpng is compiled reentrant. + +When I read libpng docs (example.c), it has directions on +decoding several images at the same time, so it seems that the +library can handle that. +On the other hand, I can't reproduce the bug with a single +image. + +An interesting fact is that sometimes PNGs render not +completely white, but with colors bleached away! (One more hint +towards thinking the bug is PNG specific). + +Finally, Geoff Lane (author of PNG support), told me it was +alpha code. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39 + +Seth, + +> > > Bug #63 (Segfault when you click enter in location field) +> +> I found that bug running on an older slack install, when I tried to reproduce +> it on a newer mandrake install everything seemed fine. + +Thanks for the explanation. + +Jorge.- + +Ps: Older than SLK-3.6? + + + +RE: [Dillo-dev]Re: Eric + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39 + +Eric, + +> > - Implementing the bookmarks as an external plugin. The idea of +> > doing it keeps rolling in my mind. Basically a dpi:/ (dillo +> > plugin) URL can be defined, and when accessing dpi:/bm (bookmark) +> > an external program can be launched on a thread to 'cat' the +> > bookmarks file (this is very much like current file handling). +> > The point with this scheme is that the plugin can be extended +> > to achieve more functionality (add, move, remove bookmark, make +> > category, etc). All implemented in a CGI fashioned way. +> > With that example, other people can start thinking of other +> > plugins, like a man page processor, or info file processor, a +> > dillorc options interface, etc. +> > +> +> You said that before and I love this idea. I'd like to see a practical example +> of plugin, even alpha stage, before I decide I can do it right. + +OK, I'll try to provide you with that. +(Most probably a patch over dillo-0.2.3). + +> What I understand, is there's a program called bm in ~/.dillo/plugin/ or +> /usr/local/lib/dillo/ (or is it /usr/local/share/dillo/ ?), that take its +> arguments on the command line (ie : when calling the URL +> "dpi:/bm?subdirectoy=News&fontsize=16", dillo is opening a read only pipe with +> the command line "bm subdirectory=News fontsize=16"), then the program "bm" +> prints a html page in stdout (and can do something else, like writing a file +> on the disk), which page dillo will render. +> Is that what you have in mind ? If not, can you describe precisely the calling +> mecanism, as well as the data retrieving. + +Basically, that's the idea. + +The only difference is that information from the browser is +passed to the plugin using its stdin, not the command line, and +encoded as if the recepting program was a CGI. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39 + +Luca, + +> Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +> jpeg works just fine. Maybe a png specific problem ?!? + +Could be... +When I made the entry, a long time ago, it seemed to happen at +random images in ESR's page (not only PNGs there). But when I +checked it yesterday, the blank images were only PNGs. + +> Bug #62 (<hr> tag's width problem): Dw_hruler_size_nego_y() (file dw_hrule.c) +> is commented. But that code seem ok! It works! Why is commented? + +Because I haven't finished it yet ;) +Dillo 0.2.3 will have it uncommented. + +> Bug #63 (Segfault when you click enter in location field): +> I can't reproduce it. + +After reading Seth's post, I decided to remove the entry. + + +Jorge.- + + + +Re: [Dillo-dev]Html test suite + +From: Jorge Arellano Cid <jcid@ne...> - 2000-08-01 13:39 + +Eric, + +> I've done some pages to begin with : basic html structure, colors. I'm +> currently finishing the characters page. +> But I'm not sure what's urgent to do next. + +I understand. + +> What html specs do you want me to build test pages for (high and medium +> priority) ? Do you want first (only ?) well-formated documents, or do you need +> faulty documents too (missing, misplaced or incorrect tags) + +The main point of it is to have a set of pages to test backward +rendering capabilities (not breaking what was working in former +versions of dillo), and to have a record of simple things that +are not working yet, but that we're close to add. + +For instance, a page that reproduces the white square rendering +bug, would be useful, but a table rendering suit makes no sense +at this stage. + +The other fact to take into account, is not to devote much time +on assembling an HTML test suite, just find a page that shows +some problems and add it to our test list; if you can reduce its +size, that'd be good. + +Just assemble a small testing suite and you'll eventually +receive contributions (I have some!). + + +> PS: Do we aim for html 3 or html 4 compliance ? + +Neither one! +We strive for a "usable" HTML web browser. +(Kind of a vague answer, but true) + + + +Jorge.- + + +Ps: If you want my test examples, drop me a note. + + |