diff options
Diffstat (limited to 'old/oldmail/200010.txt')
| -rw-r--r-- | old/oldmail/200010.txt | 3767 |
1 files changed, 3767 insertions, 0 deletions
diff --git a/old/oldmail/200010.txt b/old/oldmail/200010.txt new file mode 100644 index 0000000..57816c2 --- /dev/null +++ b/old/oldmail/200010.txt @@ -0,0 +1,3767 @@ +[Dillo-dev]Dw details + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-31 15:04 + +Hi! + +Some details on my Dw design. Implementation is far enough to make be +beleive that this design should work quite well. In detail: + +- DwWidget: set_width and set_height are currently not used, instead, +this feature is currently implemented otherwise. Will be changed +next. +The implementation of a_widget_queue_resize is currently very simple +and inefficient, but works; changes should not effect the other +code. + +- DwContainer: There won't be much implementation, anyway. + +- Interaction between Gtk and Dw: GtkLayout does a good job ;-). +Embedding of Gtk+ widgets by DwEmbedGtk works mainly. (BTW, focus +works very nice now.) + +DwWidget +-------- + +My goal for the new design was mainly to make dillo's widgets more +similar to Gtk+ widgets. + +struct _DwWidget +{ +GtkObject object; + +/* some more members, will change */ +}; + + +struct _DwWidgetClass +{ +GtkObjectClass parent_class; + +void (*size_request) (DwWidget *widget, +DwRequisition *requisition); +void (*size_allocate) (DwWidget *widget, +DwAllocation *allocation); +void (*set_width) (DwWidget *widget, +guint32 width); +void (*set_height) (DwWidget *widget, +guint32 height); +void (*draw) (DwWidget *widget, +DwRectangle *area, +GdkEventExpose *); +/* further methods for events */ +}; + +size_request and size_allocate work quite exactly as in GtkWidget. I +added two methods, set_width and set_height, which may (but need not) +have an effect on the behaviour of size_request. (Probably, set_height +will not be used anyway, but it is there for symmetry.) Most widgets +in dillo will use size_request much more often that size_allocate. + +There is a function a_dw_widget_queue_resize, which a widget must call +when its desired change has changed (e.g. if a word is added to a +page). The implementation is based on the size_request and +size_allocate methods, similar to gtk_widget_queue_resize), so a +widget must not implement anything like idle functions etc. (BTW, +a_dw_widget_queue_resize as well as gtk_widget_queue_resize do work +with idle functions.) + +Since DwWidget's are windowless "per se", there is no need for +distinguishing between a draw and an expose method. However, if the +draw function is called because of an expose event, the method will +receive it as third argument (otherwise NULL), in case, if the widget +is interested in further details. + + +DwContainer +----------- + +Quite similar to GtkContainer. + + +Interaction between Gtk and Dw +------------------------------ + +The top level Dw widget is handled by a Gtk+ widget GtkDwViewport, +derived from GtkLayout. GtkDwViewport is responsible for all events +for Dw widgets, the underlying GtkLayout for events for embedded Gtk+ +widgets. + +There is still a widget DwEmbedGtk for embedding Gtk+ widgets into a +DwWidget. Some "events" (like destroy or size_request) of those +widgets have to be caught by signals, since Gtk+ does not regard the +DwEmbedGtk as the parent of the Gtk+ widget. + +(I first tried another approach, without GtkLayout, which made the +design simpler, but had severe problems with the Gtk+ widgets. So I +decided to use GtkLayout, which does a good job for this.) + + +Sebastian + + + +RE: [Dillo-dev]Progress + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-10-30 00:36 + +During some recent plane trips I have mostly finished my work on dillo and +rendering of font modifying tags. font tab itself is supported, it does not +yet support the face attribute. The sub and super tags need attention, they +are the only major things not working yet. + +I intend to add a flag to dillo's configuration to ignore all font modifying +tags in the html, or only specific ones. I have even pondered saying it is ok +if font color= is set, but not font face=. Jorge, I know how much you hate not +being able to control what html authors do and I would like to give our users a +rich set of control over this. Personally, I like to see pages the way the +author intended, but I know not everyone does. Comments on implementation of +user prefs welcome. Need just a little cleanup of the code and I can submit a +patch. + +Jorge, would you like for this to happen after Sebastian's Dw changes? + +Sorry for not being very talkative lately, this is the first time this machine +has been on in a week. + + + +[Dillo-dev]Dw progress + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-28 10:43 + +Hi! + +Another good news: Dw is working quite nice already. Embedding Gtk+ +widgets is now (nearly) perfect, there are no expose problems anymore, +even resize queueing of Gtk+ widgets are recognized. After making +some changes and fixing some bugs, I'll soon start re-intigreating it +into dillo. + +A note to bug #86: tabbing between widgets works automatically (done +by the base class GtkLayout or somewhere else), but the toplevel Gtk+ +widget (GtkDwViewport) isn't focussable yet, so e.g. the arrow keys +don't work. Making GtkDwViewport focussable will cause some other +problems, since you may not focus children of focussable containers by +pressing the tab key (but you may by clicking on them). I'll work on +it (and make an entry in the bug tracking engine). + +Images: I'll first deactivate images, and then take a look at Jorge's +changes. + +Sebastian + + + +[Dillo-dev]Dillo-plugins first release + +From: Eric GAUDET <egaudet@in...> - 2000-10-27 16:07 + +Hi guys, +As I promised, I just made available all the Dillo-plugins stuff I've +been working on at: +http://www.rti-zone.org/dillo/ + +Feel free to send me any comments about this. +It's stable and almost complete, so you can try and do your own +Dillo-plugins right now. + +I'm still working on the patch, and I'll finish it hopefully soon +enough to be reviewed by Jorge and integrated in Dillo v0.3. + +A usable Bookmarks Dillo-plugin will be available soon too, but its +developement will be disconnected of Dillo. (I'm not forking Dillo ! +The purpose of plugins is to be external programs). +The internal bookmarks menu won't be removed until Jorge decides so. + +Ciao + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 28-Oct-2000 a 00:55:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Progress + +From: Jorge Arellano Cid <jcid@ne...> - 2000-10-27 12:40 + +Hi! + +A few days ago I finally devised a way to simplify the complex +alternative design; it was a major task with lots of changes that +I hope to document in the future. + +The good news is that I have a running prototype of dillo-0.3.0 +with it! + +The prototype runs very good and only requires some polishing +before being adopted as the basis for our new release. + +In brief: + +- The imgsink stuff was completely removed. +- The dicache was rewritten from scratch and integrated +into the normal cache. +- A single client queue is being used for both caches. +- The file descriptors were replaced by cache keys that serve +as connection handlers. +- The image data structure and related sources got changed. +- Every decoder (png, gif, jpeg) was adapted to the new +scheme. + + +The current prototype already solves the file caching problem +(and the severe memory leaks related). Now, I'll try to fix BUGs +using the tools that this new design provide. When I finish that, +it will be time to move the patch queue... But before I start +patching, I'll upload the prototype to the CVS server so it can +be tested. + +I only hope this design succeeds to provide what we need... + + +Jorge.- + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark <shark@bl...> - 2000-10-24 14:53 + +I've just posted the latest Dillo weekly news, this was meant to be done on +Sunday so I'm sorry it's so late but I had a uni deadline to make (just). +Anyway you can find it at +http://www.shark.pwp.blueyonder.co.uk/news/news221000.html + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Wild idea : frames + +From: Eric GAUDET <egaudet@in...> - 2000-10-24 12:39 + +-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Eric GAUDET, le +24-Oct-2000 : +>>> Don't render frames embeding DwPages in DwPages, but +>>> create an actual browser page for each frame of the +>>> frameset, with the correct width and height. The +>>> user can then place the frames as he wants without +>>> being bugged with having to read a page in a tiny +>>> window. +>> +>> As I think about this, this sounds like a neat +>> approach for re-sizable frames. But bear in mind that +>> not all frames are re-sizable. We'll need to handle +>> both re-sizable AND non-re-sizable frames, IMHO. +>> +> +> While we could probably intercept resizing messages, I'm not sure +> this +> would be a good idea. I want to keep control over sites designed for +> large screens (I "only" have a 800x600 laptop). I don't see where in +> html concepts the user is denied to customised his browser's +> behavior. +> + +More precisely on attributes : +- NORESIZE should be used to allow the browser window to be +resized without the DwPage renegotiation its dimensions. (only useful +with sizes in %) +- SCROLLING should always be auto : there's no point to deny scrolling +in such a frame implementation. +- FRAMEBORDER, MARGINWIDTH, MARGINHEIGHT : ignored. I agree there will +be a problem here with complex pages using frames for showing fancy +displays, mostly for java applets and video streaming (none of which we +plan to support anytime soon). Those pages should be built with tables +anyway, and I don't care if we can't render "correctly" poorly designed +pages. + +This multi-window implementation for frames is allowed by HTML4 specs : +(quoted from W3C site) +"16.1 Introduction to frames +HTML frames allow authors to present documents in multiple views, +which may be independent windows or subwindows. Multiple views offer +designers a way to keep certain information visible, while other views +are scrolled or replaced." + +The "subwindows" is the way most browsers render frames, but not the +only one ;-) + +PS: I didn't came with this idea to make frames implementation simpler, +but because I think this could be convenient for users. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 24-Oct-2000 a 21:21:30 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Wild idea : frames + +From: Eric GAUDET <egaudet@in...> - 2000-10-24 08:57 + +-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Daniel Roberts, +le 24-Oct-2000 : +> --- Eric GAUDET <egaudet@in...> wrote: +>> Don't render frames embeding DwPages in DwPages, but +>> create an actual browser page for each frame of the +>> frameset, with the correct width and height. The +>> user can then place the frames as he wants without +>> being bugged with having to read a page in a tiny +>> window. +> +> As I think about this, this sounds like a neat +> approach for re-sizable frames. But bear in mind that +> not all frames are re-sizable. We'll need to handle +> both re-sizable AND non-re-sizable frames, IMHO. +> + +While we could probably intercept resizing messages, I'm not sure this +would be a good idea. I want to keep control over sites designed for +large screens (I "only" have a 800x600 laptop). I don't see where in +html concepts the user is denied to customised his browser's behavior. + +>> We'll also need to add an identifier for the +>> frameset (say a hash of the url ?), in case the same +>> target names are used in different framesets. That +>> doesn't seem pose any problem. +> +> Actually, would it not be easier if we simply embedded +> the DwPages within some master widget that contained +> the master URL and the master frameset? +> + +That's the current design "to-be" with Sebastian's new Dw widgets. + +> Also, another problem will surface in the course of +> this: How on earth do we plan to handle bookmarking, +> and back/forward buttons for frames? Last time I +> checked, the W3C HTML specs generally seemed to admit +> that this was a very messy situation in HTML. In +> Netscape, they had a HECK of a time with this. +> Bookmarking was impossible, and back/forward had to be +> given an ugly hack to handle frames, originally. +> + +For bookmarking, we can bookmark only the frameset's URL. For +back/forward button, I don't see any problem : each browser window +already has its own history. + +> In this course of thought, yet another thought has +> occured to me: With so many different +> languages/protocols (http, ftp, html, xml, xslt, css, +> JavaScript, etc.), why not make Dillo more generic and +> modular by breaking the HTML support out into a +> plugin? +> + +Plugins plan do handle all this (both protocols and languages). +However, we'll need a final rendering language, and IMHO html is not +worth than any other, and likely better designed than anything we can +design for scratch for our own use. +And plugins have a drawback, which was already addressed (in +Dillo-plugins protocol, to be plublished soon) about make a http plugin: +"While it is possible to override "http:", this unlikely to be a good +idea : doing that will cause Dillo to fork a Dillo-plugin for each http +request. While Dillo's main purpose is being an http client, it would +be much better to patch Dillo's http layer (instead of doing a +Dillo-plugin for that) if you want to modify/fix/enhance Dillo's http +behavior." + +Same for html : Dillo was designed for fast html rendering, we should +keep html inside Dillo as THE low-level language for pages rendering. + +> Speaking of which, BTW, whatever became of the FTP plugin? + +It's cooking, be patient. + +More on Dillo-plugins by friday. (protocol and design draft +documentation, patch, sample plugin and usable bookmark plugin) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 24-Oct-2000 a 17:39:29 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Wild idea : frames + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-24 01:53 + +--- Eric GAUDET <egaudet@in...> wrote: +> Don't render frames embeding DwPages in DwPages, but +> create an actual browser page for each frame of the +> frameset, with the correct width and height. The +> user can then place the frames as he wants without +> being bugged with having to read a page in a tiny +> window. + +As I think about this, this sounds like a neat +approach for re-sizable frames. But bear in mind that +not all frames are re-sizable. We'll need to handle +both re-sizable AND non-re-sizable frames, IMHO. + +> We'll also need to add an identifier for the +> frameset (say a hash of the url ?), in case the same +> target names are used in different framesets. That +> doesn't seem pose any problem. + +Actually, would it not be easier if we simply embedded +the DwPages within some master widget that contained +the master URL and the master frameset? + +Also, another problem will surface in the course of +this: How on earth do we plan to handle bookmarking, +and back/forward buttons for frames? Last time I +checked, the W3C HTML specs generally seemed to admit +that this was a very messy situation in HTML. In +Netscape, they had a HECK of a time with this. +Bookmarking was impossible, and back/forward had to be +given an ugly hack to handle frames, originally. + +In this course of thought, yet another thought has +occured to me: With so many different +languages/protocols (http, ftp, html, xml, xslt, css, +JavaScript, etc.), why not make Dillo more generic and +modular by breaking the HTML support out into a +plugin? + +Speaking of which, BTW, whatever became of the FTP plugin? + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +[Dillo-dev]Wild idea : frames + +From: Eric GAUDET <egaudet@in...> - 2000-10-24 01:23 + +The list is so sleepy, let me share with you an idea I had for +framesets rendering : (not inline frame, not tables) +Don't render frames embeding DwPages in DwPages, but create an actual +browser page for each frame of the frameset, with the correct width and +height. The user can then place the frames as he wants without being +bugged with having to read a page in a tiny window. +To make that working, we'll have to add in DwPage a target attribute : +I already did that in my href page. We'll also need to add an +identifier for the frameset (say a hash of the url ?), in case the same +target names are used in different framesets. That doesn't seem pose any +problem. +We can also render the frameset window showing a scalled-down version +of the frame map : gtk containers with buttons named after the frames +titles should fo the trick. A window-manager "pager" sort of thing. + +Any comment ? + +If you like the idea, I'll probably give it a try when next Dillo +version comes out. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 24-Oct-2000 a 10:12:56 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]BSD ports + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-18 17:46 + +Jorge Arellano Cid wrote: + +> Sammy, +> +> +> On the DNS scheme concerns. That's the expected behaviour: one +> solving thread per request (Tested with more than a hundred +> simoultaneous requests crowding 4 server channels). +> +> It seems the problem is highly related to BSD's threads +> implementation; but please note that FreeBSD 3.5 does the trick. + +it's the expected behaviour of gethostbyname() actually (that it garbles + +up it's internal data when called simultaneously in threads). i think +the thing here is that glibc might automatically use a multithread +capable +gethostbyname (which isn't one of the *_r functions specified by posix). + +i did a little research today and found out that most unices have a +gethostbyname_r function, but apparently BSD hasn't (because the +function isn't standardized yet). + +dillo runs fine when i put the max number of server channels to 1, so +i'll use that for now :) + + +> +> Hope this helps +> Jorge.- +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]BSD ports + +From: Jorge Arellano Cid <jcid@ne...> - 2000-10-18 12:30 + +Sammy, + +Kurt Lidl reported no problems using dillo with his BSD/OS +4.0.1 i386system <lidl@en...>. + +Ryan Oberlin <ryan@sc...> got it running on +FreeBSD (with some changes that I haven't got). + +tjs17@co... reported no problems with a a 32bit machine, +gcc 2.7.2.3 and FreeBSD 3.5 (with -pthread instead of -lpthread). + +Jeremy C. Reed <reed@re...> has reported some +problems trying to run dillo on NetBSD (I'm sure he'll appreciate +any helping information). + +Feel free to contact and ask them (please tell them I gave you +the addresses). + +--- + +On the DNS scheme concerns. That's the expected behaviour: one +solving thread per request (Tested with more than a hundred +simoultaneous requests crowding 4 server channels). + +It seems the problem is highly related to BSD's threads +implementation; but please note that FreeBSD 3.5 does the trick. + + +Hope this helps +Jorge.- + + + +Re: [Dillo-dev]bug with dns or .. ? + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 21:20 + +Allan Clark wrote: + +> Just tried it and it worked fine for me. +> +> + +i have found what the problem is. apparently we are doing something +quite dangerous here :) + +in Dns_server we call gethostbyname() + +from manpage gethostbyname +These functions use static data storage; if the data is needed for future + +use, it should be copied before any subsequent calls overwrite it. + +but what we do is: we run Dns_Servers (several of them) in threads. +so it is quite possible that one query starts while another one is busy and +it will garble up gethostbyname's internal data (which is what's happening) + +when i disable threading for dns i have no problems. + +the debug output i get is for example : + +a_Cache_open_url: +http://images.freshmeat.net/FreshMeat/Core/pc.gif?/index.php3,971817463 +a_Cache_open_url: http://phoenix-adrunner.mycomputer.com/b/ar/freshmeat1/1 +Dns_server: starting... +channel: 0 +Dns_server: starting... +channel: 1 +a_Cache_open_url: http://ads.freshmeat.net/egra5006en.gif?971817463 + +etc ... etc .. + +from this point no single gethostbyname function will return !! note that we +had two +requests very fast after eachother. + + + +RE: [Dillo-dev]bug with dns or .. ? + +From: Allan Clark <shark@bl...> - 2000-10-17 20:34 + +Just tried it and it worked fine for me. + +> -----Original Message----- +> From: dillo-dev-admin@li... +> [mailto:dillo-dev-admin@li...]On Behalf Of Sammy +> Mannaert +> Sent: 17 October 2000 21:14 +> To: Dillo-dev@li... +> Subject: [Dillo-dev]bug with dns or .. ? +> +> +> hi, +> +> as i don't know if this is a bug or not, i want to ask some of you who +> run dillo on linux: +> +> - go to http://www.freshmeat.net (or freshmeat.net) +> - try to click any of the links above (linux.com, slashdot, etc ..) +> - you will only see DNS resolving <domain here> and that's it .. +> +> as i am running dillo on freebsd, i'm aware this might be a freebsd +> specific +> thingie, so i'd like to see if it's also happening on a linux platform. +> +> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]bug with dns or .. ? + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 20:25 + +hi, + +as i don't know if this is a bug or not, i want to ask some of you who +run dillo on linux: + +- go to http://www.freshmeat.net (or freshmeat.net) +- try to click any of the links above (linux.com, slashdot, etc ..) +- you will only see DNS resolving <domain here> and that's it .. + +as i am running dillo on freebsd, i'm aware this might be a freebsd +specific +thingie, so i'd like to see if it's also happening on a linux platform. + + + +[Dillo-dev]Find text (quite long sorry) + +From: Allan Clark <shark@bl...> - 2000-10-17 16:10 + +Hi, +First of all I am having trouble with my network, I seem to be able to send +and recieve mail and that is about it, anyway that is why this is not a patch +but I have just included the text, there isn't much anyway and is all in one +function but sorry about that. The code below cleans up the findtext implemented +by Sam, it uses a pretty fast algorithm which will also work if we ever choose +to use unicode characters. You should be able to follow the algorithm fairly +easily but essentially it pre-computes a prefix function for the find string +this it does in linear time according to the length of the find string and only +depends on the search string and not the page's text, it then searches through +the text of the page which can also be done in linear time, and so it is pretty +fast. This will find text that is span over one or more lines, but there is one +slight known problem, this concerns moving the scroller to the correct +position, currently if the occurence of the find string is in one line then the +correct thing happens, if it spans two lines then again the correct thing +happens and the scroller is positioned as if it were only contained in the top +of the two lines, but if it spans more than two lines the scroller is placed as +if the occurence started at the second last line the the occurence spans. Other +points to note is that I have included code to enable the user to either match +the case or not, I haven't updated the rest of the code as I realised because +of my strange network problem I wouldn't be able to patch so I wanted to keep +my changes limited to one function. Also the foundAt variable gives us a little +more information than it needs but I +left it the way it is as it will make it easier to highlight the text when we +add support for that. Okay so if you're still with me, apply Sam's patch +http://www.shark.pwp.blueyonder.co.uk/patches/findtext.diff.gz +then Sebastian's patch +http://www.shark.pwp.blueyonder.co.uk/patches/findtext2.diff +and then open up dw_page.c, scroll to the bottom where you will find the +a_Dw_page_find_text(DwPage *page, char *find) function and replace it with the +one below + +/* +* Find the text in the page. +*/ +void a_Dw_page_find_text(DwPage *page, char *find) +{ + +GString *stext; +GtkDwScroller *scroller; +DwContainer *container; +gint m; +gint *prefix; +gboolean matchCase; +gint k = 0; +gint q = 1; +gint line_num = 0; +gint foundAt = -1; +gint ii = 0; +gint t = 0; +gint s = 0; +gint fromPrevious = 0; + + +matchCase = FALSE; /* Not yet implemented */ + +if ( !(container = a_Dw_find_container(&page->dw)) ){ +g_print("BUG: Dw container not found\n"); +return; +} + +m = strlen(find); +if (!m) +return; + +prefix = (gint*) g_malloc (m * sizeof(gint)); +stext = g_string_sized_new(64); + +/* First compute a static prefix function +* this can be done in linear time and +* based solely on the search string +*/ + +prefix[0] = 0; /*Must be this reguardless of the string */ + +if (!matchCase) +g_strdown (find); + +for (q = 1; q < m; q++) +{ +while (k > 0 && find[k] != find[q]) +k = prefix[k - 1]; +if (find[k] == find[q]) +k++; +prefix[q] = k; +} + +/*Go in loop searching each line until we find +the search string */ +for (line_num = 0; line_num < page->num_lines; line_num++) +{ +/* this allows us to find strings that span over two or more lines */ +if (stext->len > m) +stext = g_string_erase(stext, 0, stext->len - m); +fromPrevious = stext->len; /*might not be as long as m */ +/* Now we get the next block of text */ +for(s = 0; s < page->lines[line_num].num_words; s++) +{ +if (page->lines[line_num].words[s].content_type != DW_PAGE_CONTENT_TEXT) +continue; +stext = g_string_append(stext, page->lines[line_num].words[s].content.text); +stext = g_string_append(stext, " "); +} +if (stext->len < m) +continue; + +/* Now we search the stext for the search string */ +if(!matchCase) +stext = g_string_down(stext); +foundAt = -1; +ii = 0; +t = 0; +while (stext->str[ii]) +{ +while (t > 0 && (find[t] != stext->str[ii])) +t = prefix[t - 1]; +if (find[t] == stext->str[ii]) +t++; +ii++; +if (t == m) { +foundAt = ii - m; +break; +} +} +/* Now if we have found it then highlight the line */ +if (foundAt != -1) { +scroller = GTK_DW_SCROLLER (container->widget->parent); +if (foundAt < fromPrevious && line_num > 0) /*line_num <= 0 shouldn't ever happen if foundAt < fromPrevious*/ +a_Dw_gtk_scroller_jump_pos (scroller, +page->lines[line_num - 1].y_top); +else +a_Dw_gtk_scroller_jump_pos (scroller, +page->lines[line_num].y_top); +break; +} +} + +g_string_free(stext, TRUE); +g_free (prefix); +} + + + +Re: [Dillo-dev]Patches + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-17 12:23 + +Eric GAUDET wrote: +> I've already included in most of the pages I made if dillo v0.2.4's behavior is +> correct or not, and sometime what it should be. I planned to update this when +> next version (not cvs) will be available. +> It's an HTML-rendering testsuite only. I won't build any testsuite for cache +> behavior, http requests and other things a browser is supposed to do. +> I understood there's a bedtest for Sebastian's new Dw : I can include that. + +It's simply a main-function of 20 lines, which creates some widgets +and then calls gtk_main. It helps me testing all functions and finding +bugs. (Furthermore, most widgets aren't ported yet, although they are +mostly simple ones, like DwBullet.) This could perhaps done also for +other modules, i.e. separating the module's code and calling all of +its functions "by hand". + +Another way could be to use the existing possibilities of a server. +E.g., I already used php pages with included "<? sleep(10) ?>" to +simulate slow connections (this could also be done by a simple cgi +script), or you may create specific http headers etc. + +> It's the very first version : no one has reacted on it yet. I expect to receive +> your own pages, comments and (grammar :-/) corrections so it can be improved. +> (actually I was waiting for Jorge's green light and corrections before +> publishing it, but you guys may want to know what's happening ;-) + +I have written some test pages. I'll download your suite and look what +I might send you. + +Sebastian + + + +Re: [Dillo-dev]Patches + +From: Livio Baldini Soares <livio@li...> - 2000-10-17 01:41 + +Jorge Arellano Cid writes: +> +> Hi! +> +> The minimal consideration I expect from newcomers, is to read +> the home page before posting to this mailing list. If they don't +> or even worse, they do but decide to force their ways into this +> project, we have a bad start... +> +> Rules are there for a reason, and I want to thank Eric for +> pointing them out to the mailing list. +> + +Ok, sorry. I didn't mean to break all your "rules" and cause any +confusion. I was just trying to contribute, and not "forcing" my way +into the project. I did read the home page, and read a bunch of +previous mails from the archive list, but it wasn't clear to me that +we weren't suppossed to post patches and stuff in the mailing +list. Now it's very clear, sorry. + +(...) + +> > Sorry if I seemed annoyed, but I not. It just not nice to have +> > people effort thrown away in vain, when they could be producing lots +> > if things were a little bit more organized. +> +> Please don't blame on us the results of you not following our +> rules. You could have known that in advance. As a matter of fact, +> you knew I was working some of the bugs you tried to fix. + +Wow, I wasn't blaming anyone of anything, I was just stating my +opinion about how the project was organized. But since am a newcomer, +and don't nothing about it, you can just ignore my remarks ;-). + +> +> If you read the mailing list archives, you'll find an +> "Activity" post (by me); there you'll find a list of things that +> your patch doesn't solve, and maybe then it will become clear why +> patches are reviewed before inclusion. + +I agree with this, all patches should be reviewed. I was just +exposing an idea I had about the problem (not a total fix). I sent the +patch to show to everyone the idea I had, and wanted some feed back +about the *idea*, I know that the patch didn't solve all the problems, +and I don't expect it to be included in Dillo's next version. + + +I'm REALLY sorry that I caused all this commotion, I did not mean to +have a "bad start". Jorge, what should I do to "redeem" my situation? + +best regards, + +-- +Livio <livio@li...> + + + +Re: [Dillo-dev]how i compiled under freebsd (4.1) + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-17 00:10 + +Sammy Mannaert wrote: + +> i'm not a freebsd expert by far, but i think this explenation offers +> more detail than +> the readme in the tarball .. (for example it doesn't add the problem of +> -D_THREAD_SAFE, +> if you forget it, dillo will only load the first url you go to, the +> other ones will only +> display "resolving DNS" or something alike in the statusbar) +> + +it seems as if this isn't really fixed yet (though i used correct +compiling options ..) sometimes (quite a lot really) i get DNS +solving <host> and nothing else ... weird ... + +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]how i compiled under freebsd (4.1) + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-16 23:38 + +hi, + +i've succesfully compiled and tested dillo on freebsd (the platform i +run now) +in order to be able to compile, i had to do quite a few things which i +will explain +here. + +i'm not sure if i took the "correct" freebsd way of doing things +however .. + +first step: freebsd uses -pthread and -D_THREAD_SAFE instead of +-lpthread +and -D_REENTRANT : +type +export CFLAGS="-pthread -D_THREAD_SAFE" +or setenv CFLAGS "-pthread -D_THREAD_SAFE" +(depending on shell) + +second step: freebsd uses gtk12-config instead of gtk-config : +do +ln /usr/X11R6/bin/gtk12-config /usr/X11R6/bin/gtk-config +(as root ofcourse) + +third step: +do +./configure --with-gtk-prefix=/usr/X11R6 +--with-gtk-exec-prefix=/usr/X11R6 + + +now here is when a problem emerges. it seems our configure script +doesn't really +support the option to set the jpeg include lib directories ? (for the +record: freebsd +has jpeglib.h etc .. in /usr/local/include) .. anyways, i couldn't get +it to work :) +what i did: +in configure.in i outcommented following part: +if test "$jpeg_ok" = yes; then +AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h, +jpeg_ok=yes, jpeg_ok=no) +fi + +it then worked as suspected. (do we really need this part ? can't we +assume that +the jpeglib is correctly installed after we did the first test in +configure ? +checking for jpeg_destroy_decompress in -ljpeg (<- this one)) + + +i'm not a freebsd expert by far, but i think this explenation offers +more detail than +the readme in the tarball .. (for example it doesn't add the problem of +-D_THREAD_SAFE, +if you forget it, dillo will only load the first url you go to, the +other ones will only +display "resolving DNS" or something alike in the statusbar) + + + +[Dillo-dev]help needed: sigsuspend with new glibc + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 16:49 + +Hi all, +I've updated my glibc to 2.1.3-5mdk a few days ago, and now I'm catching a lot +of sigsuspend in gdb (I hadn't a single one before) : on sigsuspend every +pthread_create (one for each image on a page). That's really bugging me. +What can I do to avoid this ? + +Does this have anything to do with that message : +(gdb) run +Starting program: /home/eric/src/dillo-0.2.4.orig/src/./dillo +warning: Unable to find dynamic linker breakpoint function. +GDB will be unable to debug shared library initializers +and track explicitly loaded dynamic code. +dillo_dns_init: Here we go! + +Can anyone help me on this ? + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 17-Oct-2000 a 01:43:21 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Patches + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 16:34 + +-- En reponse de "RE: [Dillo-dev]Patches" de Daniel Roberts, le 16-Oct-2000 : +>> It's an HTML-rendering testsuite only. I won't build +... +> [extra deleted for brevity...] +> +> I just took a look at it. At the moment, it does look +> to me like a reasonable subset of HTML tests, given +> Dillo's current status/capabilities. When +> tables/frames support is complete, I am guessing that +> tables/frames tests will be the next thing to be +> added. :-) +> + +Sure, but Jorge already urged me *not* to bother with table testing pages, as +the first line of code for it is not even written. +But that's the next big step all right. + +> BTW, Mozilla has a *HUGE* test suite, with tests +> scattered all over the place. I suggest we might want +> to consider using some of these tests. I'd be willing +> to bring them over here and adapt them for Dillo's +> use, if you'd like to add them to your testsuite. + +That would be nice. Just focus on dillo's current/likely next capabilities for +now. + +> When the time comes, Mozilla also has XML, CSS, and +> JavaScript tests as well. They are good and complete, +> what's more. +> + +Forget it, we won't need them soon. + +> I think however that we *DO* also need things like +> http requests, cache behavior, and other things a +> browser should do. + +That's not easy to publish this as a test suite : who here has an http server +running on his machine ? Who wants to patch, say boa, for faking altered http +responses to see how dillo's handling the problem, and maintain such a +malformed monster ? How helping would it be : everyone having the same +behaviour in a tight controlled environment and make sure dillo's working ok ? + +What can be done, though, is one (or some) of us publish some results. +But the most likely guy doing that is the feature-coder himself, with his own +tests. And I'm sure he won't submit a non-fully tested patch. + +I'm not sure there's a point doing a test suite for this now. When dillo reach +v1.0 and everyone will be willing to add nigty feature, then we'll want to make +sure we won't break anything. + +For now, I mainly want to test what I'm adding, relying on others to do the +same for what they're doing. + +> For example, how about the +> bookmark bug that someone pointed out was fixed THREE +> times? A regression test on this should have helped +> point this out earlier. :-) + +The bookmark thing was always alpha code. It's a quick hack nobody wants to fix +because : +1) there's a lot to do elsewhere +2) there's a bookmark as pluggin planned since day one, better, easier to fix, +external to dillo, hopefully making obsolete the current fishy code. + +> However, since I actually +> probably know HTML and CSS better than I do XML or C, +> I will probably be able to do these most readily. +> +[2nd post] +> I would definitely be willing to perform the tests, +> given the links Eric just posted. + +If you want to maintain the Html testsuite thing, help yourself. You can take +what I made and mix it with whatever you think is relevant. Or we can both +update it. + +> Also, with Gzilla/Armadillo, I used to post Insure++ +> memory leak reports sometimes. I can do the same for +> Dillo if it helps. + +That would be great ! + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 17-Oct-2000 a 01:11:01 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Patches + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-16 15:20 + +--- Jorge Arellano Cid <jcid@ne...> wrote: + +> I've read Daniel's posts on the subject and if +> he's willing to perform the tests (or any one +> else), please contact Eric and start working from +his +> test-suite. + +I would definitely be willing to perform the tests, +given the links Eric just posted. + +Also, with Gzilla/Armadillo, I used to post Insure++ +memory leak reports sometimes. I can do the same for +Dillo if it helps. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +RE: [Dillo-dev]Patches + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-16 15:17 + +--- Eric GAUDET <egaudet@in...> wrote: + +> It's an HTML-rendering testsuite only. I won't build +> any testsuite for cache behavior, http requests and +> other things a browser is supposed to do. +> I understood there's a bedtest for Sebastian's new +> Dw : I can include that. +> It's the very first version : no one has reacted on +> it yet. I expect to receive your own pages, comments +> and (grammar :-/) +> corrections so it can be improved. +[extra deleted for brevity...] + +I just took a look at it. At the moment, it does look +to me like a reasonable subset of HTML tests, given +Dillo's current status/capabilities. When +tables/frames support is complete, I am guessing that +tables/frames tests will be the next thing to be +added. :-) + +BTW, Mozilla has a *HUGE* test suite, with tests +scattered all over the place. I suggest we might want +to consider using some of these tests. I'd be willing +to bring them over here and adapt them for Dillo's +use, if you'd like to add them to your testsuite. +When the time comes, Mozilla also has XML, CSS, and +JavaScript tests as well. They are good and complete, +what's more. + +I think however that we *DO* also need things like +http requests, cache behavior, and other things a +browser should do. For example, how about the +bookmark bug that someone pointed out was fixed THREE +times? A regression test on this should have helped +point this out earlier. :-) However, since I actually +probably know HTML and CSS better than I do XML or C, +I will probably be able to do these most readily. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +RE: [Dillo-dev]Patches + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 12:34 + +-- En reponse de "[Dillo-dev]Patches" de Jorge Arellano Cid, le 16-Oct-2000 : +> Regression tests: +> ----------------- +> +> Some time ago Eric commited to compiling a test-suite for dillo +> (we discussed several topics and its ready). I've had no time to +> test it, nor to include it in official plans (due to lack of +> time, --I sincerely apologize Eric). +> + +No problem : I much prefer you working on dillo's next version ;-) + +> I've read Daniel's posts on the subject and if he's willing to +> perform the tests (or any one else), please contact Eric and +> start working from his test-suite. +> + +I've already included in most of the pages I made if dillo v0.2.4's behavior is +correct or not, and sometime what it should be. I planned to update this when +next version (not cvs) will be available. +It's an HTML-rendering testsuite only. I won't build any testsuite for cache +behavior, http requests and other things a browser is supposed to do. +I understood there's a bedtest for Sebastian's new Dw : I can include that. +It's the very first version : no one has reacted on it yet. I expect to receive +your own pages, comments and (grammar :-/) corrections so it can be improved. +(actually I was waiting for Jorge's green light and corrections before +publishing it, but you guys may want to know what's happening ;-) + +Here's a link where anyone can visite : +http://www.rti-zone.org/dillo/Html.testsuite/ + +Here's where you can download the whole suite : +http://www.rti-zone.org/dillo/Html.testsuite.tar.gz + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 16-Oct-2000 a 21:19:43 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Patches + +From: Jorge Arellano Cid <jcid@ne...> - 2000-10-16 11:49 + +Hi! + +The minimal consideration I expect from newcomers, is to read +the home page before posting to this mailing list. If they don't +or even worse, they do but decide to force their ways into this +project, we have a bad start... + +Rules are there for a reason, and I want to thank Eric for +pointing them out to the mailing list. + + +> It would be really nice if we had an updated CVS version to patch +> to, or if someone (one of the olders guys with the project) released a +> 0.2.5 or 0.2.4-1 or something like that, with all the "pending" +> patches included, cause frankly it seems too confusing and I have no +> idea where to start programming so my works are all wasted/outdated. + +The CVS version is the most current (official). +Developers can patch 0.2.4 (or CVS). + +> Sorry if I seemed annoyed, but I not. It just not nice to have +> people effort thrown away in vain, when they could be producing lots +> if things were a little bit more organized. + +Please don't blame on us the results of you not following our +rules. You could have known that in advance. As a matter of fact, +you knew I was working some of the bugs you tried to fix. + +If you read the mailing list archives, you'll find an +"Activity" post (by me); there you'll find a list of things that +your patch doesn't solve, and maybe then it will become clear why +patches are reviewed before inclusion. + +Finally, I'll keep my schedule exactly as described in the +"Activity" post. + +--- + +Bug track engine: +---------------- + +I see one source of confussion (and a solution) here. + +I'll use the word "done" to signal a CVS commited patch. +Developers, please only use comments or a percentage. + +Example: + +MrX@so... 70% <- The guy is making some progress + +MrX@so... 100% <- The guy is finished his work and the +patch is expecting a review. + +MrX@so... 100% done <- The patch was reviewed (fixed) and +commited to the CVS. + + +---- + +Regression tests: +----------------- + +Some time ago Eric commited to compiling a test-suite for dillo +(we discussed several topics and its ready). I've had no time to +test it, nor to include it in official plans (due to lack of +time, --I sincerely apologize Eric). + +I've read Daniel's posts on the subject and if he's willing to +perform the tests (or any one else), please contact Eric and +start working from his test-suite. + + +---- + +News: +----- + +I want to thank Allan for his excellent work with dillo weekly +News. + + + +Sincerely +Jorge.- + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 11:12 + +-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +watch" de Livio Baldini Soares, le 16-Oct-2000 : +>> Looks nice. I can't really test it, because my cable modem loads pages too +>> fast +>> and I can barely see the watch ;-) I wanted to see if one can scroll in a +>> partially loaded page, but I can tell really. +>> However, it seems not to wait until all images on a page are loaded, is it +>> the expected behavior ? +> +> Err, it's suppossed to do that. The watch serves so one can control +> when the lock was ON or OFF, not when/while all the page was +> loading. I did that cause sometimes the lock would go ON and wouldn't +> go off like it should (like when a page is not found or some other +> error, which currently the lock system isn't implemented to work +> on). So if the cursor continued to be the watch for no reason, just +> hit the STOP button, and everything should go back to normal. +> + +I'm asking because it seems to segfault too when clicking a link (or the +button "back") on a page where all images are not loaded yet. Wasn't it +supposed to protect from that too ? + +>> I experienced some segfaults too. I can't reproduce them each time, but it +>> seems to occur when closing a window where a page (an image ?) is still +>> loading. +>> +> +> Yeah, I get that too, but as Sebastian said, closing windows are not +> that simple... there's a need for a little bit of cleaning up, or else +> pending requests don't have a place to go, then they get sad and crash +> Dillo ;-) +> + +Ok, makes sens. So, is the windows closing code going to be your next patch ? +;-)) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 16-Oct-2000 a 20:07:27 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Livio Baldini Soares <livio@li...> - 2000-10-16 09:28 + +Eric GAUDET writes: +> -- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +> watch " de Livio Baldini Soares, le 16-Oct-2000 : + +> ... +> Looks nice. I can't really test it, because my cable modem loads pages too fast +> and I can barely see the watch ;-) I wanted to see if one can scroll in a +> partially loaded page, but I can tell really. +> However, it seems not to wait until all images on a page are loaded, is it the +> expected behavior ? + +Err, it's suppossed to do that. The watch serves so one can control +when the lock was ON or OFF, not when/while all the page was +loading. I did that cause sometimes the lock would go ON and wouldn't +go off like it should (like when a page is not found or some other +error, which currently the lock system isn't implemented to work +on). So if the cursor continued to be the watch for no reason, just +hit the STOP button, and everything should go back to normal. + +> I experienced some segfaults too. I can't reproduce them each time, but it +> seems to occur when closing a window where a page (an image ?) is still loading. +> + +Yeah, I get that too, but as Sebastian said, closing windows are not +that simple... there's a need for a little bit of cleaning up, or else +pending requests don't have a place to go, then they get sad and crash +Dillo ;-) + +> +> please don't include the whole old messages. + +Oops, :-o forgot to cut it, sorry. + +bye, + +-- +Livio + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 09:11 + +-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +watch " de Livio Baldini Soares, le 16-Oct-2000 : +> Hi yall, +> +> I've been working on my patch, to better it. First thing I wanted to +> make the cursor change into a watch or something while the lock (which +> I mention below) was on. To do is I started messing more with the code +> and realized that the lock system which I created was starting to turn +> into a headache. So what I did was, I encapsulated the system into +> basically two calls (which I included into nav.c): +> +... +Looks nice. I can't really test it, because my cable modem loads pages too fast +and I can barely see the watch ;-) I wanted to see if one can scroll in a +partially loaded page, but I can tell really. +However, it seems not to wait until all images on a page are loaded, is it the +expected behavior ? +I experienced some segfaults too. I can't reproduce them each time, but it +seems to occur when closing a window where a page (an image ?) is still loading. + +> +> Attached is the gzipped patch, which should deprecate the previous I +> sent. I don't know if this will help in the future, maybe Jorge will +> sanitate all our problems with his new misterious Dw ;-). But until +> then, I think this is a nice working patch. What do guys think? +> + +anyway that's a nice patch : I can't speak for Jorge, and I'm not so much in +page-loading/caching stuff, but the concept seems good. + +> bye, +> +> Livio. +> +> Livio Baldini Soares writes: +>> Hi (again), +>> +... + +please don't include the whole old messages. + +bye + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 16-Oct-2000 a 18:00:54 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]File baseurl resolving behaviour + +From: Livio Baldini Soares <livio@li...> - 2000-10-16 05:15 + +Hi guys, + +again browsing in Dillo I tried to do the following; I wanted to +check the contents of my /tmp directory, so I typed in: +/tmp/ + +on the "New Url", instead of file:/tmp/. Dillo assumed that it was a +http request and tried to resolve http://tmp/. + +Im my opinion, this shouldn't happen. I think that if a user enters +an URL starting with a '/' then he wants a file not a http. What do +you guys think? + +Anyway, I've already made the patch (its really small), and am +sending along with the message. + +bye, + +-- +Livio + +--- dillo.orig/src/interface.c Sat Sep 9 21:08:36 2000 ++++ dillo.my/src/interface.c Mon Oct 16 03:06:12 2000 +@@ -654,7 +656,7 @@ Interface_openfile_ok_callback(GtkWidget +*/ +void a_Interface_entry_open_url(GtkWidget *widget, BrowserWindow *bw) +{ +- gchar *url; ++ gchar *url, *BaseUrl; +GtkEntry *entry; + +/* Find which entry to get the URL from. This is a bit of a hack. */ +@@ -666,7 +668,13 @@ void a_Interface_entry_open_url(GtkWidge +#ifdef VERBOSE +g_print(ëntry_open_url %s\n", gtk_entry_get_text(entry)); +#endif +- url = a_Url_resolve_relative("http:/", gtk_entry_get_text(entry)); ++ if ( (gtk_entry_get_text(entry))[0] == '/') /* if the first char is a slash, */ ++ BaseUrl = "file:"; /* the user wants a file. */ ++ else ++ BaseUrl = "http:/"; ++ ++ url = a_Url_resolve_relative(BaseUrl, gtk_entry_get_text(entry)); ++ +if ( url ) { +a_Nav_push(bw, url); +g_free(url); + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch cursor feature) + +From: Livio Baldini Soares <livio@li...> - 2000-10-16 03:02 + +Attachments: seg_fault2.diff.gz + +Hi yall, + +I've been working on my patch, to better it. First thing I wanted to +make the cursor change into a watch or something while the lock (which +I mention below) was on. To do is I started messing more with the code +and realized that the lock system which I created was starting to turn +into a headache. So what I did was, I encapsulated the system into +basically two calls (which I included into nav.c): + +a_Nav_lock_acquire +a_Nav_locl_release + +And except for some early BrowserWindow initilization, these are +what you should call, and never access bw->nav_lock directly (like a +private in C++). This way the code looks much better, and easier to +understand and expand. + +With this done I was able to successfully implement the little +"loading watch" which I wanted (it was getting on my nerves not +knowing what Dillo was doing, if it was loading the page or not, +etc. with this watch cursor a now the lock is acquire threfore +*should* be indicating that it's loading a root-Url). + +Attached is the gzipped patch, which should deprecate the previous I +sent. I don't know if this will help in the future, maybe Jorge will +sanitate all our problems with his new misterious Dw ;-). But until +then, I think this is a nice working patch. What do guys think? + +bye, + +Livio. + +Livio Baldini Soares writes: +> Hi (again), +> +> I know that Jorge is working on these bugs, but I *think* I've found +> a good solution to the problems (actually I'm not really sure...). It +> seems to me that the problem comes from a type of "concurrency" +> problem within the IO and html/cache modules. The http requests in +> Dillo, from what I understand, are all asynchronous, but I've seen no +> concurrency controls in the modules. I think this lack of control is +> generating the problem. +> +> For example, if I press the "Achieved Goals" link in Dillo's home +> page, don't wait for it to load and press the "Changelog" link (or any +> other, even the "Acheived Goals" repeatelly), Dillo will request ALL +> the "clicked" links pages. Up to this part everything should be ok +> (actually no, but I'll get to that later), the problem comes in when +> the requests arrive. Many requests start coming in and Dillo gets +> "confused" and can't handle them all. +> +> What I've done is prevented various (root) Url requests at the same +> time. This is what Netscape does, when you click a link on a page, the +> cursos turns into a watch and all the other links become +> "un-clickable" until the new page gets loaded. I think this is a +> "correct" behaviour and not a restriction to the user. +> +> I did this in Dillo by placing a type of LOCK in the BrowserWindow +> (browser.h) structure. Its a gboolean `nav_lock`. When someone tries +> to load a root-url, by using the `a_Nav_push` I set the nav_lock to +> TRUE. By doing this I disabled any type of user navigation. The only +> two places where `nav_lock` comes FALSE again is by pressing STOP (in +> the `a_Commands_stop_callback) and in the `a_Nav_expect_done` +> function, because here we can assume that the root url has changed +> (bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to +> navigate savely again. +> +> When I got this working I would still (very seldomly) get +> seg. faults. Studying the problem I found out that if, for example, +> you click on a link, then wait until it get "unlocked" (when the +> `a_expect_done` is called), then press BACK before the entire page +> loaded (pics and all), a few pending requests for that page are still +> coming in. With that in mind, I tought of two choices: +> +> 1) Everytime the user requested for an URL, Dillo should cancel all +> the pending requests for old URLs, so that the requests wouldn't +> arrive later "unexpectedly". +> +> 2) Don't cancel the requests since Dillo has already made then; I +> think it would be a wast of data. Instead just ignore the few pending +> requests. +> +> I chose option 2. I did this similar to what Sam Dennis did a while +> ago (when he send the patch). From what I can see applying these two +> ideas (the lock and Sam's patch) we have a pretty much clean fix to +> the problem. Of course I could be wrong and missing the "root" of the +> problem. Does anybody see any flaws in what I've described above? +> +> This lock system, if it's conceptually correct, should fix this +> bug. But what I've implemented is NOT the complete lock system, it's +> just a preview on how I tought to fix this problem. If you guys like +> the idea, I'll have to finish up the exception handling (so if there's +> an error while downloading a page, navigation doesn't become forever +> disabled, erroneously locked). +> +> I'm sending the patch that should implement this fix, included is +> Sam's patch (html_loading.diff) and the cache patch (cache_patch), so +> there's no need to apply those patches, only this one. This patch +> should be applyed against the CVS version. +> +> hope this helps, bye, +> +> -- +> Livio + + + +RE: [Dillo-dev]Where's bug #80 fix? + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 01:59 + +-- En reponse de "RE: [Dillo-dev]Where's bug #80 fix?" de Eric GAUDET, le +16-Oct-2000 : +> If you want to test all my patches, here's an (temporary, don't rely on it) +> address where you can download all of them with a txt file of explanations : +> + +Sorry, here's the address : +http://www.rti-zone.org/dillo/ + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 16-Oct-2000 a 10:58:42 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Where's bug #80 fix? + +From: Eric GAUDET <egaudet@in...> - 2000-10-16 01:28 + +-- En reponse de "[Dillo-dev]Where's bug #80 fix?" de Livio Baldini Soares, le +15-Oct-2000 : +> Hello, +> +> I saw in the Bug Engine that bug #80 (seg. fault, when right +> clicking in a text/plain page) was taken cared of. If I recall +> correctly it stated that Eric fixed it, but I can't seem to find +> anything about it in the mail archive, nor any of Allan's patches +> contain a solution for it. Anybody know how's the fix? Eric? +> +> bye, +> + +I always send my patches t directly to Jorge, not to the mailing list, because +that's what Jorge asked. +If you want to test all my patches, here's an (temporary, don't rely on it) +address where you can download all of them with a txt file of explanations : + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 16-Oct-2000 a 10:20:19 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Where's bug #80 fix? + +From: Livio Baldini Soares <livio@li...> - 2000-10-15 20:17 + +Hello, + +I saw in the Bug Engine that bug #80 (seg. fault, when right +clicking in a text/plain page) was taken cared of. If I recall +correctly it stated that Eric fixed it, but I can't seem to find +anything about it in the mail archive, nor any of Allan's patches +contain a solution for it. Anybody know how's the fix? Eric? + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Close Window command + +From: Livio Baldini Soares <livio@li...> - 2000-10-15 20:07 + +Sebastian Geerken writes: +> Livio Baldini Soares wrote: +(...) +> +> There is a function a_Interface_new_browser_window, so there should +> probably also be a function a_Interface_destroy_browser_window, which +> will do a bit more that destroying the widget. Merely destroying the +> widget could even cause crashes (AFAIK dillo), since the still active +> IO stuff could try to add text into the nonexisting page widget. + +Oops, guess your right... sorry. So we don't "forget" to do this, I +inserted this as a Bug in the Bug Engine, it's bug #87. + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Old CVS + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-15 19:56 + +--- Sam Dennis <sdennis101@ge...> wrote: +> Correct me if I'm wrong, but isn't an out of date +> cvs version an oxymoron? +> +> It seems like it's extremely difficult to avoid +> repeating work currently +> because patches have been made but the cvs version +> hasn't changed. + +I agree. Question is, why are the patches not being +committed to CVS? I would think the thing to do it +have them checked in, after undergoing a code review. +Then we wouldn't have this problem. Besides, if a +change is found later to cause problems, it can be +backed out. Again, some kind of automated regression +testing infrastructure would make this part easier, too. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +[Dillo-dev]Old CVS + +From: Sam Dennis <sdennis101@ge...> - 2000-10-15 19:32 + +Correct me if I'm wrong, but isn't an out of date cvs version an oxymoron? + +It seems like it's extremely difficult to avoid repeating work currently +because patches have been made but the cvs version hasn't changed. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark <shark@bl...> - 2000-10-15 11:43 + +This weeks Dillo Weekly News has been posted you can find it here +http://www.shark.pwp.blueyonder.co.uk/news/news151000.html + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Close Window command + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-15 10:29 + +Livio Baldini Soares wrote: +> +> Hi all, +> +> messing with Dillo, I tried to do the `Close Window` function +> (Crtl-W or Menu select `File -> Close Window`), well nothing +> happenned. I looked at commands.c, and all I found was the empty stub: +> +> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +> { +> } +> +> Below it I also saw the exit_callback and in it a commentary: +> /* There should be a close command that does this: */ +> /* gtk_widget_destroy (bw->main_window); */ +> +> So, that's exactly what I did, now close_callback looks like: +> +> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +> { +> gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +> } +> +> What gives? Am I missing something? Why wasn't this already done? I +> tried it out and it's working fine. Including when your in the last +> window (only one left) and when you `close` it (not `exit`), dillo +> exits normally. +> +> I guess I've probably missed some previous discussion... Just in case, +> I'm sending the "patch". + +There is a function a_Interface_new_browser_window, so there should +probably also be a function a_Interface_destroy_browser_window, which +will do a bit more that destroying the widget. Merely destroying the +widget could even cause crashes (AFAIK dillo), since the still active +IO stuff could try to add text into the nonexisting page widget. + +Sebastian + + + +[Dillo-dev]About bugs #74 and #69 + +From: Livio Baldini Soares <livio@li...> - 2000-10-15 08:49 + +Attachments: seg_fault.diff + +Hi (again), + +I know that Jorge is working on these bugs, but I *think* I've found +a good solution to the problems (actually I'm not really sure...). It +seems to me that the problem comes from a type of "concurrency" +problem within the IO and html/cache modules. The http requests in +Dillo, from what I understand, are all asynchronous, but I've seen no +concurrency controls in the modules. I think this lack of control is +generating the problem. + +For example, if I press the "Achieved Goals" link in Dillo's home +page, don't wait for it to load and press the "Changelog" link (or any +other, even the "Acheived Goals" repeatelly), Dillo will request ALL +the "clicked" links pages. Up to this part everything should be ok +(actually no, but I'll get to that later), the problem comes in when +the requests arrive. Many requests start coming in and Dillo gets +"confused" and can't handle them all. + +What I've done is prevented various (root) Url requests at the same +time. This is what Netscape does, when you click a link on a page, the +cursos turns into a watch and all the other links become +"un-clickable" until the new page gets loaded. I think this is a +"correct" behaviour and not a restriction to the user. + +I did this in Dillo by placing a type of LOCK in the BrowserWindow +(browser.h) structure. Its a gboolean `nav_lock`. When someone tries +to load a root-url, by using the `a_Nav_push` I set the nav_lock to +TRUE. By doing this I disabled any type of user navigation. The only +two places where `nav_lock` comes FALSE again is by pressing STOP (in +the `a_Commands_stop_callback) and in the `a_Nav_expect_done` +function, because here we can assume that the root url has changed +(bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to +navigate savely again. + +When I got this working I would still (very seldomly) get +seg. faults. Studying the problem I found out that if, for example, +you click on a link, then wait until it get "unlocked" (when the +`a_expect_done` is called), then press BACK before the entire page +loaded (pics and all), a few pending requests for that page are still +coming in. With that in mind, I tought of two choices: + +1) Everytime the user requested for an URL, Dillo should cancel all +the pending requests for old URLs, so that the requests wouldn't +arrive later "unexpectedly". + +2) Don't cancel the requests since Dillo has already made then; I +think it would be a wast of data. Instead just ignore the few pending +requests. + +I chose option 2. I did this similar to what Sam Dennis did a while +ago (when he send the patch). From what I can see applying these two +ideas (the lock and Sam's patch) we have a pretty much clean fix to +the problem. Of course I could be wrong and missing the "root" of the +problem. Does anybody see any flaws in what I've described above? + +This lock system, if it's conceptually correct, should fix this +bug. But what I've implemented is NOT the complete lock system, it's +just a preview on how I tought to fix this problem. If you guys like +the idea, I'll have to finish up the exception handling (so if there's +an error while downloading a page, navigation doesn't become forever +disabled, erroneously locked). + +I'm sending the patch that should implement this fix, included is +Sam's patch (html_loading.diff) and the cache patch (cache_patch), so +there's no need to apply those patches, only this one. This patch +should be applyed against the CVS version. + +hope this helps, bye, + +-- +Livio + + + +[Dillo-dev]Close Window command + +From: Livio Baldini Soares <livio@li...> - 2000-10-15 06:24 + +Hi all, + +messing with Dillo, I tried to do the `Close Window` function +(Crtl-W or Menu select `File -> Close Window`), well nothing +happenned. I looked at commands.c, and all I found was the empty stub: + +void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +{ +} + +Below it I also saw the exit_callback and in it a commentary: +/* There should be a close command that does this: */ +/* gtk_widget_destroy (bw->main_window); */ + +So, that's exactly what I did, now close_callback looks like: + +void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +{ +gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +} + +What gives? Am I missing something? Why wasn't this already done? I +tried it out and it's working fine. Including when your in the last +window (only one left) and when you `close` it (not `exit`), dillo +exits normally. + +I guess I've probably missed some previous discussion... Just in case, +I'm sending the "patch". + +bye, + +-- +Livio <livio@li...> + +--- dillo.orig/src/commands.c Mon Aug 28 22:25:45 2000 ++++ dillo.my/src/commands.c Sun Oct 15 04:17:31 2000 +@@ -63,10 +63,11 @@ void a_Commands_prefs_callback(GtkWidget +} + +/* +- * ? ++ * Close only the selected Window +*/ +void a_Commands_close_callback(GtkWidget *widget, gpointer +client_data) +{ ++ gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +} + +/* + + + +Re: [Dillo-dev]Archiving patches + +From: Eric GAUDET <egaudet@in...> - 2000-10-15 06:21 + +-- En reponse de "Re: [Dillo-dev]Archiving patches" de Livio Baldini Soares, le +15-Oct-2000 : +> +> With all these patches I'm starting to get a little confused... I'm +> trying to solve bug 74# (and others that arise due to the same +> problem), I believe I've found the problem and have a "clean"and +> simple fix, but I'm supposed to build it on top of what version? +> 0.2.4? CVS? CVS with all the patches applyed? +> + +You should not bother with published patches unless you want to test one (and +only one at time : it's very unlikely you can apply all without reworking most +of the diffs, which will be done by Jorge for next version) +You want to patch against v0.2.4, (or CVS version, which claims to be v0.2.5). +It's also possible you need/find handy to patch a patched version. If you don't +patch against vanilla v0.2.4, list all patches needed before yours. + +> I'm asking cause some of these changes will affect other code we +> build on top. Plus there seems to be a new Dw beeing made, and a +> testbed(?). +> + +We're not sure of what the new Dw will look like. Sebastian hasn't finished it +yet. + +> It would be really nice if we had an updated CVS version to patch +> to, or if someone (one of the olders guys with the project) released a +> 0.2.5 or 0.2.4-1 or something like that, with all the "pending" +> patches included, cause frankly it seems too confusing and I have no +> idea where to start programming so my works are all wastedøutdated. +> + +Only jorge can decide if a submitted patch will be included in the official +dillo version. It's not a good thing to have a fully patched version. For us +patchers, there's only one developper version, the lastest : 0.2.4. +CVS is to be considered experimental. + +> By the way, is the `Bug Track System` being used? More precisely is it +> valid and not outdated? +> + +The bug track system is the most up-to-date informations you'll have, because +it's automated and updated by everybody (actually I think Jorge is kind of +moderating it, but the delay is not noticably larger than one day). +Use it to report bugs you've found and things you want fixed by somebody else. +Use it to tell everybody what you are working on (to avoid duplicate efforts). + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 15-Oct-2000 a 13:07:20 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Archiving patches + +From: Livio Baldini Soares <livio@li...> - 2000-10-15 03:15 + +Allan Clark writes: +> Just to let everyone know I have started to archive most of the patches that +> get sent to the list, it was prompted by Sammy's post about looking for the +> first find text patch, anyway you can find a sort of index at +> http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes +> no attempt to explain the patches merely provides links to them. +> + +This is really helpfull! I got all the patches (ps. seems like +html_loading.diff and html_loading1.diff are the same. Anything wrong +with that?). + +With all these patches I'm starting to get a little confused... I'm +trying to solve bug 74# (and others that arise due to the same +problem), I believe I've found the problem and have a "clean"and +simple fix, but I'm supposed to build it on top of what version? +0.2.4? CVS? CVS with all the patches applyed? + +I'm asking cause some of these changes will affect other code we +build on top. Plus there seems to be a new Dw beeing made, and a +testbed(?). + +It would be really nice if we had an updated CVS version to patch +to, or if someone (one of the olders guys with the project) released a +0.2.5 or 0.2.4-1 or something like that, with all the "pending" +patches included, cause frankly it seems too confusing and I have no +idea where to start programming so my works are all wastedøutdated. + +Sorry if I seemed annoyed, but I'm not. It's just not nice to have +people's effort thrown away in vain, when they could be producing lots +if things were a little bit more organized. + +By the way, is the `Bug Track System` being used? More precisely is it +valid and not outdated? + +bye and sorry for bugging yall ;-) + +-- +Livio + + + +[Dillo-dev]Archiving patches + +From: Allan Clark <shark@bl...> - 2000-10-14 18:25 + +Just to let everyone know I have started to archive most of the patches that +get sent to the list, it was prompted by Sammy's post about looking for the +first find text patch, anyway you can find a sort of index at +http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes +no attempt to explain the patches merely provides links to them. + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Bug #85 fix + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-14 18:20 + +--- Daniel Roberts <zuperdee@ya...> wrote: + +> That's why one does QA/regression tests. :-) +> Perhaps this is a sign that Dillo needs some kind of +> QA/regression testing framework? + +BTW, this also is reason to think about open-source +philosophy... I am not ordinarily that philosophical, +but it has occured to me that ESR said in "The +Cathedral and the Bazaar," that "given enough eyes, +all bugs are shallow." + +However, seeing this bug which has regressed THREE +times now, I think, proves ESR wrong on this point. +His approach seems rather like the classic "monkeys at +typewriters" approach to Shakespeare--that is, given +enough 1000's of monkeys at enough 1000's of +typewriters, one of them somewhere will type "to be or +not to be." + +I do believe however, this proves why one needs to +think of open-source as merely the LICENSING framework +for a project, and not a specification on how the +development efforts are coordinated and managed... +Case in point: the GCC Steering Committee does +automated regression tests. I think Dillo could +benefit from this, too. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +Re: [Dillo-dev]Bug #85 fix + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-14 17:10 + +--- Sammy Mannaert <nstalkie@tv...> wrote: + +> this is a bug i once fixed ... i know the bookmarks +> have been rewritten so the old mistake might have +> come back for the THIRD time :) (it was originally +in +> gzilla/armadillo, where i fixed it, then dillo came +> into existance, where i fixed it again (i think), +and +> now again) + +> any predictions on how much it will show up again ? + +That's why one does QA/regression tests. :-) Perhaps +this is a sign that Dillo needs some kind of +QA/regression testing framework? + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +Re: [Dillo-dev]Bug #85 fix + +From: Eric GAUDET <egaudet@in...> - 2000-10-14 15:42 + +-- En reponse de "Re: [Dillo-dev]Bug #85 fix" de Sammy Mannaert, le 14-Oct-2000 +> +> strange ... +> +> this is a bug i once fixed ... i know the bookmarks have been rewritten +> so the old mistake might have come back for the THIRD time :) (it was +> originally in gzilla/armadillo, where i fixed it, then dillo came into +> existance, where i fixed it again (i think), and now again) +> +> any predictions on how much it will show up again ? :) +> + +When the bookmark plugin I'm coding will be integrated, it won't anymore : +there will be *new* bugs ;-) + +> sammy +> +> PS: i've been pretty inactive lately (though i have been following the +> mailing list), i'll try doing a few patches in the coming month ... +> + +me too :-/ + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 15-Oct-2000 a 00:39:28 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Bug #85 fix + +From: Sammy Mannaert <nstalkie@tv...> - 2000-10-14 15:13 + +Livio Baldini Soares wrote: + +> Hi again, +> +> first let me thank Eric for taking the time in answering me. I found +> out what the problem was with my glib (I had 2 glib's installed, one +> in /usr/ and the other in /usr/local, I guess they were conflicting, +> since their versions didn't match). +> +> Messing around with Dillo I wanted to bookmark Dillo's home page +> (dillo.so....net) and then Seg. Fault! +> +> I looked at the code, and I guess I got a patch working (actually just +> an tiny change, just a NULL check). Latter I found out at the Bug +> Track page that this was bug #85. Hope this helps, here's the patch. +> +> bye, +> +> PS: I read in the mail archive that someone made a patch for the `Find +> Text...' function, where can I find it? The only thing I found was +> another patch to be used afterwards so the use of anchors wouldn't be +> needed. +> +> -- +> Livio <livio@li...> +> +> $ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c +> +> --- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000 +> +++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000 +> @@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget, +> return; +> +> /* If the page has no title, lets use the URL */ +> - if (strcmp (title, ¨) == 0) +> + if ( !title || (strcmp (title, ¨) == 0)) +> title = url; +> +> #ifdef TITLE39 +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +strange ... + +this is a bug i once fixed ... i know the bookmarks have been rewritten +so the old mistake might have come back for the THIRD time :) (it was +originally in gzilla/armadillo, where i fixed it, then dillo came into +existance, where i fixed it again (i think), and now again) + +any predictions on how much it will show up again ? :) + +sammy + +PS: i've been pretty inactive lately (though i have been following the +mailing list), i'll try doing a few patches in the coming month ... + + + +RE: [Dillo-dev]Bug #85 fix + +From: Allan Clark <shark@bl...> - 2000-10-14 08:47 + +You should find the original message in the archives here +http://www.geocrawler.com/lists/3/SourceForge/702/0/4469704/ +also I put it on the site I use for the dillo news although I don't link to +it, I do that with most of the pathces just for safe keeping you can find it +here +http://www.shark.pwp.blueyonder.co.uk/findtext.diff.gz + +<snip> +> PS: I read in the mail archive that someone made a patch for the `Find +> Text...' function, where can I find it? The only thing I found was +> another patch to be used afterwards so the use of anchors wouldn't be +> needed. +<snip> + + + +[Dillo-dev]Bug #85 fix + +From: Livio Baldini Soares <livio@li...> - 2000-10-13 23:52 + +Hi again, + +first let me thank Eric for taking the time in answering me. I found +out what the problem was with my glib (I had 2 glib's installed, one +in /usr/ and the other in /usr/local, I guess they were conflicting, +since their versions didn't match). + +Messing around with Dillo I wanted to bookmark Dillo's home page +(dillo.so....net) and then Seg. Fault! + +I looked at the code, and I guess I got a patch working (actually just +an tiny change, just a NULL check). Latter I found out at the Bug +Track page that this was bug #85. Hope this helps, here's the patch. + +bye, + +PS: I read in the mail archive that someone made a patch for the `Find +Text...' function, where can I find it? The only thing I found was +another patch to be used afterwards so the use of anchors wouldn't be +needed. + +-- +Livio <livio@li...> + +$ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c + +--- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000 ++++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000 +@@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget, +return; + +/* If the page has no title, lets use the URL */ +- if (strcmp (title, ¨) == 0) ++ if ( !title || (strcmp (title, ¨) == 0)) +title = url; + +#ifdef TITLE39 + + + +RE: [Dillo-dev]Newbie questions + +From: Eric GAUDET <egaudet@in...> - 2000-10-13 11:14 + +-- En reponse de "[Dillo-dev]Newbie questions" de Livio Baldini Soares, le +13-Oct-2000 : +> Hi guys, +> +> I was looking around in Sourceforge for a new browser in constrution +> (or finished), 'cause I'm goddam sick of Netscape exiting for no +> reason at all. I found that Dillo was the best project and looks like +> it has future. I liked the project so I've decided to try to +> contribute in any way way I can. The problem is I'm still a newbie in +> Linux and Unix programming, so if I'm being out of hand or something, +> please let me know. +> + +Welcome. + +> Where are the latest versions/patches? I saw somewhere on your webpage +> (dillo.so....net/Dname.html) that there are MIME/ and URL/ +> directories undeer the src/, but when I got the 0.2.4 version, I found +> no such directories. +> + +Lastest version is 0.2.4. You can patch against it. mime and url directories, +as well as the Dname.html page look like old stuff (gzilla era), you can safely +ignore them. + +> I downloaded the cvs files by doing: +> +> $ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co +> dillo +> +> like indicated on the Sourceforge CVS page. And then couldn't compile +> it. The problem was with the `g_print()'. I don't know, but there must +> be something wrong with my system (I use Debian 2.1, aka potato, and +> have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a +> simple program like: +> +> ----------------------- +>#include <glib.h> +> +> int main(void){ +> +> g_print("Testing...\n"); +> +> return 0; +> } +> ----------------------- +> And compile it: +> $ gcc test.c -o test -lglib -I/usr/lib/glib/include/ +> $ ./test +> Segmentation fault +> + +Did you try to trace the program ? (I use xxgdb, which is an athena +front-end to gdb, crude but efficient : "xxgdb ./test", then run, then stack ) + +> Someone knows what's going on? +> +> What I did to "overcome" this problem is switched to plain `printf()' +> function: +> +> $ cd src/ +> $ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done +> +> And THEN it compiled. I'm running it fine and enjoying it! Congrats on +> the great work guys. +> + +If you want your patches included in dillo, you'll have to fix this glib +problem. + +> PS: Sorry about the stupid questions, and the long mail. + +We're here to help, you can ask. + +> PS1: Sorry for the bad english..., I'm Brazilian. +> + +No problem : most of us are not native english speaker and we won't even notice +a thing ;-) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 13-Oct-2000 a 20:02:55 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Newbie questions + +From: Livio Baldini Soares <livio@li...> - 2000-10-13 04:56 + +Hi guys, + +I was looking around in Sourceforge for a new browser in constrution +(or finished), 'cause I'm goddam sick of Netscape exiting for no +reason at all. I found that Dillo was the best project and looks like +it has future. I liked the project so I've decided to try to +contribute in any way way I can. The problem is I'm still a newbie in +Linux and Unix programming, so if I'm being out of hand or something, +please let me know. + +Where are the latest versions/patches? I saw somewhere on your webpage +(dillo.so....net/Dname.html) that there are MIME/ and URL/ +directories undeer the src/, but when I got the 0.2.4 version, I found +no such directories. + +I downloaded the cvs files by doing: + +$ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo + +like indicated on the Sourceforge CVS page. And then couldn't compile +it. The problem was with the `g_print()'. I don't know, but there must +be something wrong with my system (I use Debian 2.1, aka potato, and +have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a +simple program like: + +----------------------- +#include <glib.h> + +int main(void){ + +g_print("Testing...\n"); + +return 0; +} +----------------------- +And compile it: +$ gcc test.c -o test -lglib -I/usr/lib/glib/include/ +$ ./test +Segmentation fault + +Someone knows what's going on? + +What I did to "overcome" this problem is switched to plain `printf()' +function: + +$ cd src/ +$ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done + +And THEN it compiled. I'm running it fine and enjoying it! Congrats on +the great work guys. + +PS: Sorry about the stupid questions, and the long mail. +PS1: Sorry for the bad english..., I'm Brazilian. + +thanks for the attention, + +-- +Livio <livio@li...> + + + +[Dillo-dev]Patch to support font-loading on the iPaq handheld. + +From: Eric Christianson <echristi@ri...> - 2000-10-12 17:15 + +This patch allows one of the default fonts on the compaq iPaq +linux distribution to work. (www.handhelds.org) + + +1098,1103d1097 +< +< if (font->font == NULL) { +< /* Can't load the font - try another platform font that should be available. (iPaq) */ +< font->font = gdk_font_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1"); +< } +< + +Eric Christianson +RidgeRun, Inc. +http://www.ridgerun.com + + + +Re: [Dillo-dev]Find text patch + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-11 20:03 + +Sam Dennis wrote: +> I did think of doing something like that, but I presumed that the functions +> already in place would have been exported if that was desirable. +I wrote all these functions (from +Dw_gtk_scroller_adjustment_value_changed to the end) for anchors, and +exported only those which were necessary for them. If some functions +are useful for other purposes, they may be exported, too. + +Sebastian + + + +Re: [Dillo-dev]Find text bugs + +From: Sam Dennis <sdennis101@ge...> - 2000-10-10 17:24 + +On Tue, Oct 10, 2000 at 01:25:42AM +0000, Sam Dennis wrote: +> Er, it does segfault sometimes, I have to admit, but I'm almost certain that +> it's not my fault... + +I think that most of the crashes are happening in the html rendering, +actually. Although I have had one or two of them inside a perfectly valid +call to realloc. + +Since then I've tried to test it by searching around a nice long court +transcript and it didn't crash once. This and a number of other things makes +me begin to suspect my libc instead... + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text patch + +From: Sam Dennis <sdennis101@ge...> - 2000-10-10 17:19 + +On Tue, Oct 10, 2000 at 04:43:17PM +0200, Sebastian Geerken wrote: +> Sam Dennis wrote: +> > +> > I've implemented a find text command for the first instance of the string +> > (it shouldn't be too difficult to extend it to finding multiple instances, +> > probably just starting by looking from the line after the last instance was +> > found). +> > +> > I'm sorry about the anchor, but it seemed like the only sane way to scroll +> > to the line we found. +> +> This patch doesn't use anchors. Apply it after Sam's patch. +> +> Sebastian + +I did think of doing something like that, but I presumed that the functions +already in place would have been exported if that was desirable. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text patch + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-10 13:08 + +Attachments: findtext2.diff + +Sam Dennis wrote: +> +> I've implemented a find text command for the first instance of the string +> (it shouldn't be too difficult to extend it to finding multiple instances, +> probably just starting by looking from the line after the last instance was +> found). +> +> I'm sorry about the anchor, but it seemed like the only sane way to scroll +> to the line we found. + +This patch doesn't use anchors. Apply it after Sam's patch. + +Sebastian + + + +[Dillo-dev]Find text bugs + +From: Sam Dennis <sdennis101@ge...> - 2000-10-10 00:22 + +Er, it does segfault sometimes, I have to admit, but I'm almost certain that +it's not my fault... + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Find text patch + +From: Sam Dennis <sdennis101@ge...> - 2000-10-10 00:10 + +Attachments: findtext.diff.gz + +I've implemented a find text command for the first instance of the string +(it shouldn't be too difficult to extend it to finding multiple instances, +probably just starting by looking from the line after the last instance was +found). + +I'm sorry about the anchor, but it seemed like the only sane way to scroll +to the line we found. + +It doesn't highlight the string found in any way, partially because I don't +think that any mechanism for this is currently in place. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sam Dennis <sdennis101@ge...> - 2000-10-09 20:15 + +On Mon, Oct 09, 2000 at 10:54:32PM +0200, Sebastian Geerken wrote: +> ... +> scroller = GTK_DW_SCROLLER (bw->docwin); +> view = GTK_DW_VIEW (dw_scroller->viewport); +> border = (DwBorder*) (view->dw); +> page = (DwPage*) (border->child); + +Er, a little convoluted, isn't it? + +> +> I think border is sometimes NULL, so you may add some checks. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-09 19:21 + +Sam Dennis wrote: +> +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? + +BrowserWindow *bw; +GtkDwScroller *scroller; +GtkDwView *view; +DwBorder *border; +DwPage *page; + +scroller = GTK_DW_SCROLLER (bw->docwin); +view = GTK_DW_VIEW (dw_scroller->viewport); +border = (DwBorder*) (view->dw); +page = (DwPage*) (border->child); + +I think border is sometimes NULL, so you may add some checks. + +Sebastian + + + +[Dillo-dev]Small idea for caching + +From: Sam Dennis <sdennis101@ge...> - 2000-10-09 17:22 + +I've just discovered a note I made to myself a while ago about dillo's +caching system. There is currently a complex system of callbacks necessary, +but couldn't a lot of that be thrown away with a simple pipe between the +caching system (server) and the dillo widget (client)? + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Activity + +From: Jorge Arellano Cid <jcid@ne...> - 2000-10-09 17:07 + +Hi there! + + +Just as before, silence periods on the mailing list, signal +high activity on the background! (Well, my email box seldom stops +its flow). + +I'm very pleased for the "parallel" working the code is getting +(Several improvement and fixing patches, design on the widget +side and design on the Networking and middle layers by my side). + +Currently I have a lengthy queue of patches waiting to be +processed (from Jörgen, Eric, Agustín, Marcos, ...). And I keep +trying to solve the design issues of Networking/Middle-Layers +that result in a lot of related bugs. I think this is the highest +priority (for me to work on); Look this: + +- BUGs 74, 84, 64 and 69 are related to it. +- File images being decoded every time (not fed by the dicache) +- Fine reload functionality can't be done without it. +- The problem asked by Sean MacLennan +- Sudden crashes +- Slow downloads (it may happen) +- General browser stability. +- etc. + +I'll keep working on it all October; If I don't succeed, I'll +start reviewing/integrating every patch and make a new release +based on 0.2.4. + +The good news is that finally I got into a design model that +handles all the necessary stuff. The bad new is that it's too +complex (and we all know that maintaining such things becomes a +nightmare). So, it will be done when I devise a way to simplify +it one or two "degrees". + + +Jorge.- + +Ps: Marcos has sent me a patch with basic authentication support! + +------------------------- ooOOoo ----------------------------- +Some answers: + +> I am try to add Mosaic style remote access to dillo. From a unix signal +> handler I want to push an url. The command a_Nav_push works *once*, then +> fails from then on. + +Yes, I know. That's the right way to do it though. +I mean: a_Nav_push should not crash; that's a BUG. + +> I have a patch below that shows a very simple +> example of this, plus an attempt to set the text in the location widget. +> I can set the text correctly, but I do not know how to then signal gtk +> to process the line. + +That is part of a_Nav_push's work. You should not worry doing +it "by hand". It seems to me that you'll have to wait until the +design concerns that eliminate "the BUG" are done. + +(The only thing you need to worry about is not calling +a_Nav_push from an interrupt handler, but to generate an event +that triggers it from GTK's main loop). + +------------------------------------- + +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? + +Obvious? I don't think so! + +The top 'dw' is set by a_Dw_gtk_scroller_set_dw (you can follow +the chain from there). + +In brief: + +bw->docwin is a GtkDwScroller +bw->docwin->viewport->dw is a DwBorder +bw->docwin->viewport->dw->child is a DwPage or a DwImage + +so, something like this will get you going: + +GtkDwScroller *scroller = bw->docwin; +DwBorder *border = scroller->viewport->dw; +DwPage *page = border->child; + +Notes: you have to add type checks and things like that. +I haven't tested this but it should be very close. + +Hope this helps. + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sam Dennis <sdennis101@ge...> - 2000-10-09 16:43 + +On Mon, Oct 09, 2000 at 10:26:07AM +0900, Eric GAUDET wrote: +> -- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis, +> le 08-Oct-2000 : +> > I've been looking at implementing the find text function and had got half +> > way through mentally coding a solution (because of the DwPage{Line,Word}) +> > before I realised that all the callback has is the browser window, and I +> > could see no way of getting at a DwPage from that, which is essential for +> > searching. +> > +> > Am I missing something obvious? +> > +> +> You'll have to create a new external function in DwPage (a_Dwpage_findtext ?). +> That way you can either register it as a callback, or call it yourself from +> whatever other source (command.c ?). +> + +Even if I do that, I still need a pointer to a DwPage, and I see no way of +getting it. There is also the issue of frames and (possibly) tables here, as +both are separate pages, how do we know which to search even if we can get +pointers to them? + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +RE: [Dillo-dev]Find text implementation problems + +From: Eric GAUDET <egaudet@in...> - 2000-10-09 01:26 + +-- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis, +le 08-Oct-2000 : +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? +> + +You'll have to create a new external function in DwPage (a_Dwpage_findtext ?). +That way you can either register it as a callback, or call it yourself from +whatever other source (command.c ?). + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 09-Oct-2000 a 10:23:31 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Find text implementation problems + +From: Sam Dennis <sdennis101@ge...> - 2000-10-08 22:41 + +I've been looking at implementing the find text function and had got half +way through mentally coding a solution (because of the DwPage{Line,Word}) +before I realised that all the callback has is the browser window, and I +could see no way of getting at a DwPage from that, which is essential for +searching. + +Am I missing something obvious? + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-08 17:03 + +--- Sebastian Geerken <S.Geerken@pi...> wrote: +> DwPage doesn't bother about its parent widget +> (either at toplevel, or in a DwTable, or, as inline +> frame, in a DwPage?). It will just paint itself +where +> the parent wants it to do, and report size changes +> (incremental rendering!) to its parent. (BTW: Vice +> versa, DwTable will not bother about its children, +it +> only regards at them as DwWidget's.) + +This sounds like a VERY nice thing! I believe +Incremental reflow is what the Mozilla people call +this in Gecko, BTW. This should make Dillo better +than Netscape 4.x was at table rendering! Incidently, +Netscape's table rendering was VERY slow, inefficient, +and memory-hogging. It sized things dynamically +during multiple attempts, storing every attempt in +memory. This meant (if I understand them correctly) +that say, for tables of 10 columns by 10 rows, it +would store 100 attempted and failed trials in memory +before getting it right. Since Netscape never +implemented incremental layout of page sections, the +document state was split up and most of it used to +simulate a cell as a nested HTML document. This +allowed them to use the existing layout code to +simulate the layout of that cell multiple times until +the size was right. It was slow and wasteful of +memory. To make matters worse, their attempts to +optimize and streamline made the code difficult to +read and never really solved the problem of less than +optimal memory use and speed. + +For details, and mistakes to avoid that Netscape made, +I find this document VERY interesting reading: + +http://www.mozilla.org/classic/layodesc.html + +> This is very nice in Gtk+: all widgets have a very +> special purpose, a button is something where you can +> click on, but how it looks is determined by *its +> child*. You can even nest buttons, which is +> admittedly quite silly, but who knows. (In early +> versions of gnome, the panel menu entries had +> submenus on the right side.) This results sometimes +> in a horrible widget hierarchy, but is still +> efficient enough, and much easier to extend than if +> you have buttons with a label, buttons with a +pixmap, +> buttons with a pixmap and a label below the pixmap, +> buttons with a pixmap and a label right of the +pixmap +> etc. + +Interesting. So does this mean that you could have +say 3 distinct buttons inside each other, each +performing different actions, like so: + +------------------------ +| Button 1 | +| | +| |---------| |------| | +| |Button 2 | |Btn. 3| | +| | | | | | +| ----------- -------- | +| | +------------------------ + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-08 15:03 + +Eric GAUDET wrote: +> > As I say, I'll need to learn from the ground up on more basic +> > things first, however. :-) But I do want to see what I can do. +> > +> +> What I did for that is choose easy bugs in the bug-track engine (or some of my +> own ideas) and try to make a patch, as a skill training. You'll find most of +> the code clean and easy to understand. Some areas are still obscure to me +> (attrs ? cache ?). Even if the patches are rejected, this is still a great way +> to learn before trying hardcore table/frame coding ;-). +> May I suggest : +> - PNG transparency (bug #60) +> - GIF animations support +> - form widget jumping with tab/shift+tab (bug #86) + +This depends heavily on the Dw structure (in both cases, either if you +let Gtk+ (GtkWindow) do the work, or -- which I would prefer -- let it +do by GtkDwViewport). + +> - X clipboard support (bug #59) +> - adding "copy this link" to the popup menu +> - adding "save this image" to the popup menu +> - fix the status bar informations disapearing +> - implement "find text" +> - implement basic httpauth (see with Sean if he's not doing it already) +> - implement SUP and SUB tags +> - fix corrupted PNG segfault. + +Or: +- When jumping to an #anchor in the same page, the url should be +pushed on the navigation stack. See Nav_open_url and struct +_BrowserWindow. +- A menu of the last visited urls, like the one you get when you hold +the "Back" button pressed for a while in Netscape, or click on the +small button right on the "Back" button in MSIE. +- Implement the <link> tag, and e.g. add an menu "Related pages" or +so, with some accelerators, so the user must only press N for the next +page etc. (I hope, some authors still use this tag.) + +Sebastian + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-08 15:03 + +Eric GAUDET wrote: +> I'm thinking of 3 reasons why table and frames are different. +> [...] + +4) Tables are 2-dimensional, while frames are only aligned in one +direction, i.e. you must nest framesets to get a grid of frames. + +5) The size of a table cell is (in most cases) calculated by the +browser, the frame's size is determined by the web author. + +> [...] +> Perhaps we can come with a common page structure (ex DwPage ?), that would have +> the ability to be both a full html page (part of a frameset) or a table cell. + +DwPage doesn't bother about its parent widget (either at toplevel, or +in a DwTable, or, as inline frame, in a DwPage?). It will just paint +itself where the parent wants it to do, and report size changes +(incremental rendering!) to its parent. (BTW: Vice versa, DwTable will +not bother about its children, it only regards at them as DwWidget's.) +This is very nice in Gtk+: all widgets have a very special purpose, a +button is something where you can click on, but how it looks is +determined by *its child*. You can even nest buttons, which is +admittedly quite silly, but who knows. (In early versions of gnome, +the panel menu entries had submenus on the right side.) This results +sometimes in a horrible widget hierarchy, but is still efficient +enough, and much easier to extend than if you have buttons with a +label, buttons with a pixmap, buttons with a pixmap and a label below +the pixmap, buttons with a pixmap and a label right of the pixmap etc. + +> I'm not sure this will be the best way : most table cells contain only an image +> or a text paragraph. Building a whole html page for that will be a big waste +> (think about those >1000k tables ;-). + +(gdb) print sizeof (DwPage) +$1 = 184 + +(I admit that it will take a bit more after initialization.) + +Memory is not the problem, but perhaps time, since size negotiation +could happen to often. But currently it works very fast for normal +pages, and so I think we should look how it will work for tables, and +then eventually optimize it in detail. + +> I'd prefer to split the current DwPage in two widgets : one for the html +> rendering only (say DwRenderedHtml) which would do what the current DwPage do +> with lines, words ; one just like DwPage, but without what's done by +> DwRender : only links, gc, attrs, anchors, ... This DwPage would of course +> point to a DwRenderedHtml + +I'll bother about this, when Dw is complete. ;-) + +Sebastian + + + +[Dillo-dev]Dillo News + +From: Allan Clark <shark@bl...> - 2000-10-08 14:36 + +Hi all, the Dillo Weekly News is up and the url is +http://www.shark.pwp.blueyonder.co.uk/news081000.html + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Minor view source change + +From: Sam Dennis <sdennis101@ge...> - 2000-10-08 13:27 + +Attachments: viewsource.diff + +View source shouldn't get the url from the location widget as that isn't +necessarily the url of the page that is shown. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Eric GAUDET <egaudet@in...> - 2000-10-08 06:52 + +-- En reponse de "Re: [Dillo-dev]RE: table/frames (was:What can I do?)" de +Daniel Roberts, le 08-Oct-2000 : +>> To make frames look like this, you'll have to do +>> much more complicated things. +> +> Ah, but what about inline frames? +> + +right, iframes are like a single table cell embeding a separate page (URL). No +span tough. And you still can show the same structure as a complex table with +it. +It's kind of new too (HTML4 ?) : even my nestcape 4.72 can't render them. +Anyway, all suggestions I heard about table/frames handling can quite easily be +extended to iframe (once we've decided how to embed a page in a page). +Not a big deal. + +> +> All in all, it looks to me like tables/frames are THE +> next big thing to concentrate on in Dillo. + +Right again ! + +> As I say, I'll need to learn from the ground up on more basic +> things first, however. :-) But I do want to see what I can do. +> + +What I did for that is choose easy bugs in the bug-track engine (or some of my +own ideas) and try to make a patch, as a skill training. You'll find most of +the code clean and easy to understand. Some areas are still obscure to me +(attrs ? cache ?). Even if the patches are rejected, this is still a great way +to learn before trying hardcore table/frame coding ;-). +May I suggest : +- PNG transparency (bug #60) +- GIF animations support +- form widget jumping with tab/shift+tab (bug #86) +- X clipboard support (bug #59) +- adding "copy this link" to the popup menu +- adding "save this image" to the popup menu +- fix the status bar informations disapearing +- implement "find text" +- implement basic httpauth (see with Sean if he's not doing it already) +- implement SUP and SUB tags +- fix corrupted PNG segfault. + +As you can see, there's some big code planned (table/frames, IO engine, +unified alignment), but there's also a lot of small things to do you can +choose to improve both your skills and dillo :-) + +> BTW, I am also curious now about cross-platform +> plans... Is the plan just to support Unices, or +> others like BeOS, Mac, or Windows? I am thinking +> since it is GTK+-based, Unices would be relatively +> easy... Windows support could be added too, since +> GTK+ supports Windows, but I can see a new +> networking/IO layer being needed... Same for BeOS, +> since GTK+ supports BeOS, too. Mac I would think +> would be even harder though. +> + +AFAIR there was a big effort to make dillo compile under libc5, and I heard +somebody tryied it on BSD with some success (a little less stable than on +linux ?). +I don't know about windos and beos, but I'm sure the folks here would welcome +any volunteer. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 08-Oct-2000 a 15:02:53 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-08 04:54 + +--- Eric GAUDET <egaudet@in...> wrote: + +> I'm thinking of 3 reasons why table and frames are +> different. + +These all do seem like valid reasons, too. + +> To make frames look like this, you'll have to do +> much more complicated things. + +Ah, but what about inline frames? + + +All in all, it looks to me like tables/frames are THE +next big thing to concentrate on in Dillo. As I say, +I'll need to learn from the ground up on more basic +things first, however. :-) But I do want to see what +I can do. + +BTW, I am also curious now about cross-platform +plans... Is the plan just to support Unices, or +others like BeOS, Mac, or Windows? I am thinking +since it is GTK+-based, Unices would be relatively +easy... Windows support could be added too, since +GTK+ supports Windows, but I can see a new +networking/IO layer being needed... Same for BeOS, +since GTK+ supports BeOS, too. Mac I would think +would be even harder though. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +[Dillo-dev]RE: table/frames (was:What can I do?) + +From: Eric GAUDET <egaudet@in...> - 2000-10-08 02:31 + +-- En reponse de "RE: [Dillo-dev]What can I do?" de Allan Clark, le 07-Oct-2000 +: +> <snip> +>> How are tables that different? Netscape/Mozilla used +>> to render tables as complete HTML documents within a +>> larger one. After all, tables can also have images, +>> text, and everything else a complete HTML document +>> has. +> That's the exact point that I made, I don't see how tables and frames are +> really any different. + +I'm thinking of 3 reasons why table and frames are different. + +1) Table cell can span on several row or colomns, frames don't. +Example : +<table> +<tr><td rowspan=2>a</td><td colspan=2>b</td></tr> +<tr><td>c</td><td>d</td></tr> +<tr><td>e</td><td>f</td><td>g</td> +</table> +should be rendered like : ++---+-------+ +| | b | +| a +---+---+ +| | c | d | ++---+---+---+ +| e | f | g | ++---+---+---+ +To make frames look like this, you'll have to do much more complicated things. + +2) Frames can have sliders and be resized, tables don't. + +3) Table cells embedding an htlm page is only a convenient way of +rendering tables, but there is no actual html page (eg: file) as such. +Framesets _are_ separate html (or not) pages (in the cache) that have to be +loaded. + +That's why frames are not a subset of tables, and tables are not a subset of +frame. + +IMHO frames and table have a very different behavior, both the way they look +and their underlying implementation. +Perhaps we can come with a common page structure (ex DwPage ?), that would have +the ability to be both a full html page (part of a frameset) or a table cell. +I'm not sure this will be the best way : most table cells contain only an image +or a text paragraph. Building a whole html page for that will be a big waste +(think about those >1000k tables ;-). + +I'd prefer to split the current DwPage in two widgets : one for the html +rendering only (say DwRenderedHtml) which would do what the current DwPage do +with lines, words ; one just like DwPage, but without what's done by +DwRender : only links, gc, attrs, anchors, ... This DwPage would of course +point to a DwRenderedHtml + +For frames, we use GtkContainers with DwPages. + +For tables, a new widget DwTable would contain the structure of the table and +pointers to DwRenderedHtml widgets, one for each cell. +DwTable would be a word widget, just like an image is now. + +... that's it ;-) + +(and we should wait for Sebastian's new Dw widgets) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 08-Oct-2000 a 11:00:26 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]What can I do? + +From: Allan Clark <shark@bl...> - 2000-10-07 21:24 + +<snip> +> How are tables that different? Netscape/Mozilla used +> to render tables as complete HTML documents within a +> larger one. After all, tables can also have images, +> text, and everything else a complete HTML document +> has. +That's the exact point that I made, I don't see how tables and frames are +really any different. + + + +Re: [Dillo-dev]What can I do? + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-07 21:15 + +--- Sebastian Geerken <S.Geerken@pi...> wrote: + +> Gzw was written (afaik) mainly because of the size +> limitation for X windows (and so Gtk+ widgets), +> otherwise pure Gtk+ widgets could be used. It can +> embed Gtk+ widgets, but that does not work +perfectly, +> so there had been some discussion on eleminating Dw, +> but that will make dealing with the size limitation +> quite complicated. (This is my personal opinion. +> Jorge did not decide yet, what will be used in +> future, so I tried to implement and test my ideas.) + +Mozilla faced the same problem, both in the Motif and +the GTK+ ports. They ended up using a GTKLayout +widget instead of a GTKDrawingArea for the page layout +area, IIRC. Problem with this however, was that they +then had a constant battle to fight with the GTKLayout +widget's want to do its own layout things... So they +wrote this whole new library/widget (with the help of +Owen Tayler of GTK+ fame) set called GTKSuperWin. +Could we perhaps use this, BTW? + +> Dw embeds Dw already now, e.g. bullets and images +> are Dw widgets embedded in a DwPage. Embedding a +> DwPage in a DwPage is also possible, and if they +> share the same html document (as in tables), the +html +> parser has to be extended, e.g . by a stack. I did +> already hack something like that which worked +> halfway, it should not be too hard. + +Sounds good. + +> Tables and frames are quite different, the only +> thing they have in common is, that they contain +text, +> so IMO the simplest way should be to write them as +> containers for pages. + +How are tables that different? Netscape/Mozilla used +to render tables as complete HTML documents within a +larger one. After all, tables can also have images, +text, and everything else a complete HTML document +has. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +Re: [Dillo-dev]What can I do? + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-07 12:01 + +Daniel Roberts wrote: +> Okay. Well, for starters, does the UI need anything? +> I'd like to experiment with GTK+ a bit if I can... I +> am trying to learn GTK+, so if anyone can give some +> pointers on using it (other than the tutorial, which I +> am already actively reading), I would appreciate it. +> Translation: I might need to ask lots of questions, if +> nobody minds. (Boy I wish a class were taught on GTK+ +> somewhere.) + +There is also a reference and some mailing lists at http://www.gtk.org. A +good "tutorial" for using Gtk+ are the sources of Gimp, a good way of +learning how to write new widgets is reading the sources of Gtk+ +itself. + +Sebastian + + + +Re: [Dillo-dev]What can I do? + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-07 12:01 + +Hi, + +Daniel Roberts wrote: +> It is also interesting that dw (formerly gzw, I +> assume) is being re-writeen from scratch. Seems like +> this is rather what Mozilla did with Gecko. + +Dw is not completely rewritten, since the other widgets (mainly +DwPage) will ported to the new Dw. + +Gzw was written (afaik) mainly because of the size limitation for X +windows (and so Gtk+ widgets), otherwise pure Gtk+ widgets could be +used. It can embed Gtk+ widgets, but that does not work perfectly, so +there had been some discussion on eleminating Dw, but that will make +dealing with the size limitation quite complicated. (This is my +personal opinion. Jorge did not decide yet, what will be used in +future, so I tried to implement and test my ideas.) + +> As to tables/frames, how is it going to be done? I +> recall some discussions with Armadillo about possibly +> doing it by embedding dw within dw. Tables are +> admittedly a little bit different from frames, but I +> do think they are almost like flip sides of the same +> coin. + +Dw embeds Dw already now, e.g. bullets and images are Dw widgets +embedded in a DwPage. Embedding a DwPage in a DwPage is also possible, +and if they share the same html document (as in tables), the html +parser has to be extended, e.g . by a stack. I did already hack +something like that which worked halfway, it should not be too hard. + +Tables and frames are quite different, the only thing they have in +common is, that they contain text, so IMO the simplest way should be +to write them as containers for pages. + +Sebastian + + + +RE: [Dillo-dev]What can I do? + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-06 19:44 + +--- Allan Clark <shark@bl...> wrote: + +> Glad to hear from you, the above is kind of the +> implementation I had in mind for tables and frames, +> my suggestion is that we should have a page being +> either a list of horizontal subpages, a list of +> vertical subpages or a page as they are just now +> implemented with lines, and then each "leaf" page +can +> take care of drawing (alignment etc) by itself and +> all the parent pages need to do is tell all their +> children to re-draw, re-size etc. + +Interesting. But where I can see this getting tricky +is things like tables nested within tables, or with +things like inline frames (not to mention re-sizable +frames). How will this scheme handle those things? +For huge tables (like >1000k), won't it get a little +slow? Yes, there ARE tables >1000k. Mozilla had a +bug filed on such tables being slow to render. :-) + +> As for what you can do, well pick something you +> think dillo needs and just do it (I hope I won't get +> into trouble for nicking nike's slogan) I think +> the main thing is to get Sebastians port of dw +> working correctly, so if you can help with that it +> would be great but it is your time so do whatever +you +> enjoy the most. + +Okay. Well, for starters, does the UI need anything? +I'd like to experiment with GTK+ a bit if I can... I +am trying to learn GTK+, so if anyone can give some +pointers on using it (other than the tutorial, which I +am already actively reading), I would appreciate it. +Translation: I might need to ask lots of questions, if +nobody minds. (Boy I wish a class were taught on GTK+ +somewhere.) + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +RE: [Dillo-dev]What can I do? + +From: Allan Clark <shark@bl...> - 2000-10-06 15:42 + +> Hello all! +<snip> + +> As to tables/frames, how is it going to be done? I +> recall some discussions with Armadillo about possibly +> doing it by embedding dw within dw. Tables are +> admittedly a little bit different from frames, but I +> do think they are almost like flip sides of the same +> coin. +> + +Glad to hear from you, the above is kind of the implementation I had in mind +for tables and frames, my suggestion is that we should have a page being +either a list of horizontal subpages, a list of vertical subpages or a page +as they are just now implemented with lines, and then each "leaf" page can +take care of drawing (alignment etc) by itself and all the parent pages need +to do is tell all their children to re-draw, re-size etc. +As for what you can do, well pick something you think dillo needs and just +do it (I hope I won't get into trouble for nicking nike's slogan) I think +the main thing is to get Sebastians port of dw working correctly, so if you +can help with that it would be great but it is your time so do whatever you +enjoy the most. + +Note to Sebastian: would you like me to put up the sources of your dw on the +web page I'm using to do the dillo news, that way you wouldn't have to mail +it to everyone who asks? I can also update it pretty much when needed. + + + +[Dillo-dev]What can I do? + +From: Daniel Roberts <zuperdee@ya...> - 2000-10-06 15:26 + +Hello all! + +I am checking this out because Christopher Reid Palmer +has effectively admitted that Dillo will probably +become the real successor to Armadillo, and that +Armadillo is effectively dead, since he hasn't enough +time to dedicate to it. + +Dillo, IMHO, has definitely already surpassed both of +its predecessors (Gzilla and Armadillo) in almost +every aspect. I am hoping it is well on its way to +competing with the likes of KDE's Konquerer, or maybe +even Mozilla. Lord knows I worked on Mozilla for +quite a while (and still use it for everyday browsing, +cause there ain't any real alternative for GNOME folks +like me), but I still find Mozilla to be painfully +bloated, inefficient, slow, and memory-hogging, even +after their wonderful ground-up re-write based on +Gecko. Bottom line is, I have come to the same +conclusion that JWZ did--that is, all the open source +in the world cannot save Mozilla at this point. +Mozilla is pretty much hopeless. + +I think Mozilla's biggest problem was XUL. After +having seen what a cross-platform front-end interface +like Mozilla's XUL could be like, I am now convinced +that a native GTK+ interface would definitely be the +way to go. XUL is too bloated and far to slow for my +tastes. + +Anyway, I am happy to see some progress being made on +Dillo, and what's more, in the areas that really need +it the most, like Networking, I/O, and implementing +tables/frames. + +It is also interesting that dw (formerly gzw, I +assume) is being re-writeen from scratch. Seems like +this is rather what Mozilla did with Gecko. + +As to tables/frames, how is it going to be done? I +recall some discussions with Armadillo about possibly +doing it by embedding dw within dw. Tables are +admittedly a little bit different from frames, but I +do think they are almost like flip sides of the same +coin. + +Anyway, I unfortunately don't know too much about +Dillo internals, C/C++, or GTK+. So would somebody +like to point me to something I can do to help with +Dillo? I'd like to help if I can. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +[Dillo-dev]New Dw + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-10-06 13:53 + +Hi! + +I've been working on a new Dw, mainly written from scratch. I've given +up the idea of making all elements GtkWidget's, since any attempt to +work around the window size limit would be far to complicated, but +designed and begun to implement a new Dw, which mainly follows the +goal to be more similar to Gtk, because (i) the design of Gtk+ is +quite nice and proven to be usable, (ii) that will make embedding Gtk +widgets simpler, and (iii) it will be simpler to understand for +someone who knows Gtk. + +It's mainly a simple copy of the Gtk structures: there is a DwWidget +(sorry for the doubled "widget"), derived from GtkObject and with +similar methods as GtkWidget, a DwContainer, and structures like +DwRectangle, DwAllocation etc. with 32 bit sizes. Furthermore there is +a Gtk+ widget GtkDwViewport, which embeds a DwWidget (more directly +than the old GtkDwView), and is, from the view of Gtk+, parent of all +Gtk+ widgets that are embedded in the DwWidgets. DwContainers will +simply have to report all their children (DwWidget's as well as +GtkWidget's), and GtkDwViewport will recursively sort out the +GtkWidget's (by the GTK_IS_WIDGET macro), so implementing a +DwContainer is not more complicated than implementing a GtkContainer. + +Currently, there are still many bugs, especially severe expose +problems for embedded Gtk+ widgets, and DwWidget is still quite +incomplete. After fixing the most severe bugs, I'll try to integrate +the new Dw (which currently runs in a testbed) into dillo soon, trying +to complete it in dillo itself. There is already a halfway working +DwPage (a port of my Gtk+ port of the old DwPage, to the new Dw). + +I'll send the sources to anyone who is interested, and I would be glad +about help from someone else who knows Gtk+ good. + +Sebastian + + + +[Dillo-dev]remote url access + +From: Sean MacLennan <seanm@ne...> - 2000-10-02 15:49 + +Attachments: out + +Hi, + +I am try to add Mosaic style remote access to dillo. From a unix signal +handler I want to push an url. The command a_Nav_push works *once*, then +fails from then on. I have a patch below that shows a very simple +example of this, plus an attempt to set the text in the location widget. +I can set the text correctly, but I do not know how to then signal gtk +to process the line. + +Any help at all would be appreciated, + +Sean + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark <shark@bl...> - 2000-10-02 00:17 + +The latest weekly news has been posted, a little light on content this week +due to the lack of activity on the list and the fact that the first one was +a little late and hence this week's only has two days worth of news. +The url is +http://www.shark.pwp.blueyonder.co.uk/news021000.html +Allan Clark +allan@al... +shark@bl... + + |