Re: [Dillo-dev]bug#77 is anchor-related From: Sebastian Geerken - 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 - 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 Le 27-Aug-2000 a 23:01:22 ---------------------------------- Re: [Dillo-dev]support for background images? From: Sebastian Geerken - 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 - 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 Le 26-Aug-2000 a 16:29:43 ---------------------------------- Re: [Dillo-dev]support for background images? From: Sean 'Shaleh' Perry - 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 - 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 - 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 - 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 Le 26-Aug-2000 a 12:21:03 ---------------------------------- [Dillo-dev]support for background images? From: Sean 'Shaleh' Perry - 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 - 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

...

. > > 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 - 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 Le 25-Aug-2000 a 23:09:58 ---------------------------------- Re: [Dillo-dev]Anchor : feature wish From: Sebastian Geerken - 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 - 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

...

. > 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 Le 25-Aug-2000 a 19:02:34 ---------------------------------- Re: [Dillo-dev]java in dillo From: Sebastian Geerken - 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 > , 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 - 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

...

. 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 - 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 , animations, etc can be placed in this widget. [Dillo-dev]java in dillo From: Eric GAUDET - 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 Le 25-Aug-2000 a 13:06:05 ---------------------------------- [Dillo-dev]Anchor : feature wish From: Eric GAUDET - 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 Le 25-Aug-2000 a 12:59:58 ---------------------------------- [Dillo-dev]another fun test site From: Sean 'Shaleh' Perry - 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 - 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 - 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 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 - 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 - 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 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 - 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 Le 23-Aug-2000 a 12:31:30 ---------------------------------- [Dillo-dev]currently working on From: Sean 'Shaleh' Perry - 2000-08-23 01:39 I have an initial implementation of 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 - 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 - 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 - 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: 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 Le 22-Aug-2000 a 14:53:52 ---------------------------------- [Dillo-dev]weird bug in anchor code From: Sean 'Shaleh' Perry - 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 - 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 - 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 Le 22-Aug-2000 a 14:07:36 ---------------------------------- [Dillo-dev]other requests From: Sean 'Shaleh' Perry - 2000-08-22 04:30 animated gif support improved font support cookies Re: [Dillo-dev]GTK 1.3.1 From: Sean 'Shaleh' Perry - 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 > *
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

the first br is used, any immediately following are ignored. RE: [Dillo-dev]0.2.4 release From: Sean 'Shaleh' Perry - 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 - 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 - 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 - 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 - 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 *
tag? Jorge.- Re: [Dillo-dev]dillo can't read pngs on gphoto.org From: Jorge Arellano Cid - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 Le 20-Aug-2000 a 01:22:35 ---------------------------------- [Dillo-dev]Dw vs. Gtk From: Sebastian Geerken - 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 - 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 - 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 - 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 - 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 - 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 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 - 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 - 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 'haba un nio' (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 - 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 - 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 - 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 - 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 - 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: - 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 - 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 Le 15-Aug-2000 a 18:39:05 ---------------------------------- RE: [Dillo-dev]Misc. answers. From: Sean 'Shaleh' Perry - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 "". 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 - 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 - 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 - 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 "". RE: [Dillo-dev]bug #68 From: Sean 'Shaleh' Perry - 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 - 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 - 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 ... ························· 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 - 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 - 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 Le 06-Aug-2000 a 23:35:52 ---------------------------------- [Dillo-dev]Re: est suite (was: Misc. answers) From: Eric GAUDET - 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 Le 06-Aug-2000 a 11:56:07 ---------------------------------- [Dillo-dev]Re: Plugins (was: Misc. answers) From: Eric GAUDET - 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 " Le 06-Aug-2000 a 12:07:10 ---------------------------------- [Dillo-dev]bug #68 From: Sean 'Shaleh' Perry - 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 - 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 - 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 - 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 - 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 - 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 Le 02-Aug-2000 a 13:41:55 ---------------------------------- RE: [Dillo-dev]Bug #4, #62, #63 From: Eric GAUDET - 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 Le 02-Aug-2000 a 12:08:52 ---------------------------------- RE: [Dillo-dev]Bug #4, #62, #63 From: Eric GAUDET - 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 Le 01-Aug-2000 a 22:46:29 ---------------------------------- Re: [Dillo-dev]Html test suite From: Eric GAUDET - 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 Le 01-Aug-2000 a 23:32:24 ---------------------------------- RE: bookmarks [Dillo-dev]Re: Eric From: Eric GAUDET - 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 Le 01-Aug-2000 a 22:55:20 ---------------------------------- RE: [Dillo-dev]Bug #4, #62, #63 From: Luca Rota - 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 - 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 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 - 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 - 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 - 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 - 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 - 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 (
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 - 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.