diff options
Diffstat (limited to 'old/oldmail/200009.txt')
| -rw-r--r-- | old/oldmail/200009.txt | 2365 |
1 files changed, 2365 insertions, 0 deletions
diff --git a/old/oldmail/200009.txt b/old/oldmail/200009.txt new file mode 100644 index 0000000..c12cd17 --- /dev/null +++ b/old/oldmail/200009.txt @@ -0,0 +1,2365 @@ +[Dillo-dev]Dillo weekly news + +From: Allan Clark <shark@bl...> - 2000-09-28 16:10 + +The first Dillo weekly news has been posted. +The url for those interested is +http://www.shark.pwp.blueyonder.co.uk/news240900.html + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Developer News + +From: Allan Clark <shark@bl...> - 2000-09-29 10:18 + +(Sorry if this is a repeat but I didn't get one back and there isn't one in +the archives.) +The first Dillo weekly news has been posted. +The url for those interested is +http://www.shark.pwp.blueyonder.co.uk/news240900.html + +Allan Clark +allan@al... +shark@bl... + + + +RE: [Dillo-dev]Repeated patch + +From: Allan Clark <shark@bl...> - 2000-09-24 14:46 + +Jorge, have you applied this patch? you're right the problem is deeper +routed, the fact is we shouldn't be getting the null pointer there, however +we should probably check for them just incase, so although this doesn't +solve the problem I think the patch should go in, alternatively in the mean +time use an assert there to assert that there is not a null pointer, this +way we know where it is failing and why and don't just get a crash. + +> -----Original Message----- +> From: dillo-dev-admin@li... +> [mailto:dillo-dev-admin@li...]On Behalf Of Jorge +> Arellano Cid +> Sent: 22 September 2000 19:19 +> To: dillo dev list +> Subject: Re: [Dillo-dev]Repeated patch +> +> +> +> Sam, +> +> > ... here's the patch I +> > sent again, as I never received a copy back (sorry if this is a repeat). +> +> Yes, the problem has very deep roots, and I'm still trying to +> find out a design solution that gets rid of all related problems. +> +> Whether to apply the "patch" is a matter of pragmatism. +> +> I'll keep trying to solve the problems behind... +> +> Jorge.- +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]Sorry + +From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:43 + +Sorry if any of my last mails have got to you: they haven't got to me. + +Check the archives if they haven't, however. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Not again + +From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:24 + +Getting tired of repeating. Check archives for messages. + + + +Re: [Dillo-dev]Missing mails again + +From: Sam Dennis <sdennis101@ge...> - 2000-09-24 01:01 + +Argh! Why is it that only the important mails disappear? + +Well, they seem to be appearing on the archives, so if you're not receiving +them, best to check there. + +On the other hand, it could just be me. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Missing mails again + +From: Sam Dennis <sdennis101@ge...> - 2000-09-24 00:50 + +I think it's done it to me again. Did anyone receive my reply to the comments +on the segfaults? + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Repeated patch + +From: Sam Dennis <sdennis101@ge...> - 2000-09-24 00:08 + +On Fri, Sep 22, 2000 at 02:19:16PM -0400, Jorge Arellano Cid wrote: +> +> Sam, +> +> > ... here's the patch I +> > sent again, as I never received a copy back (sorry if this is a repeat). +> +> Yes, the problem has very deep roots, and I'm still trying to +> find out a design solution that gets rid of all related problems. +> +> Whether to apply the "patch" is a matter of pragmatism. +> +> I'll keep trying to solve the problems behind... + +Obviously I've been looking for the root causes, too. I get the impression +that this is some how to do with widgets that don't (or shouldn't) exist +receiving data from the caching system, but I'm probably completely wrong. + +As for applying the patch, I know that covering up the problem is generally +speaking a bad thing, but when it causes the program to crash extremely +frequently in normal usage unless the user is extremely cautious I think +that some soft of temporary measure is needed. Besides, there's another +problem that just occurs in images that I think is related, where the +structure that parent points to is filled with garbage, so the problem isn't +really covered up. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Dw (was new here) + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-23 15:45 + +Hi Allan! + +I've still some doubts if the port is really a good thing, because: + +1. Gtk+ was designed for GUIs, but not for size negotiation e.g. +needed for tables. This could be solved by a Gtk+ widget set, see my +post to the list (subject "[Dillo-dev]Dw -> Gtk"). + +2. Gtk+ adopts the limitation of 32k pixels for an X window even for +windowless widgets, so you have a limited height for pages (when only +a part of DwPage is seen in a viewport), or at least for tables (when +the DwPage is itself the viewport). + +I've included my thoughts, which I sent Jorge, at the end of this +mail. + +Allan Clark wrote: +> [...] +> This all sounds great, if you need any help porting Dw just let me know what +> needs to be done. + +Send your ideas and comments on this topic. If you have an idea how to +solve the problem with the height limitation, without a new widget +set, that would be great. + +> I realised after I had sent the patch to the list that it was going to be a +> little obsolete as you were working on the port of Dw. I think the cvs +> version of the tree should be kept more up to date, I sent an e-mail to +> Jorge about that, below is part of that e-mail (which discussed a number of +> things) it is just an idea for dw_page which I think might help us with +> table and frame support, and you may be in a better position to decide. + +Currently, the ported DwPage is only on my local harddisk, according +to Jorge's philosophy of long holded patches, and since no one else +showed interest in it, before. If you are interested, I may send you +what I've done yet. + +Sebastian + +My mail to Jorge: + +I now think that is indeed not a good idea to use Gtk+ for the layout +of the html elements, but to continue using a much improved Dw. +Improvements coming currently to mind, are: + +- Include Dw into the Gtk+ object model, i.e. derive it from +GtkObject. So, Dw can use the strengths of Gtk+ objects. + +- Write a Gtk+ Widget GtkDwEmbed for embedding a Dw widget, replacing +GtkDwView, and probably best derived from GtkLayout. This widget must +first handle all embedded Gtk+ widgets (see below), and second wrap +the events for the Dw widgets. + +- Dw (or a derived class DwContainer) must strictly distinguish +between Dw widgets and Gtk+ widgets. E.g., the forall "method" of +GtkDwEmbed (defined by GtkContainer) should only work on the Gtk+ +widgets. Embedding Gtk+ widgets should be a mechanism of Dw itself, +not of DwEmbedGtk. + +An incomplete "class" hierarchy could look like this: + + +[GtkObject] +___________|_______________ +/ \ +Dw [GtkWidget] +__________|___________ | +/ | \ | +DwBullet DwImage DwContainer GtkDwEmbed +___|___ +/ \ +DwPage DwTable + + +Dw and DwContainer should be similar to GtkWidget and GtkContainer, +but with a few modifications, e.g. in size negotiation. An idea from +Gtk+, that containers are (partly) responsible for resising their +children, could also be adopted (see my post to the list). + + + +RE: [Dillo-dev]Dw (was new here) + +From: Eric GAUDET <egaudet@in...> - 2000-09-23 05:08 + +-- En reponse de "RE: [Dillo-dev]Dw (was new here)" de Allan Clark, le +22-Sep-2000 : +> Lastly (bet you're glad) how far are we with tables/frames support, if the +> answer is "still discussing design options" then I would like to add my idea +> into the arena, I'm sure someone has probably suggested this, but, why don't +> we extend dw_page so that it can be one of the following +> 1)Contain a number of horizontal sub pages +> 2)Contain a number of vertical sub pages +> 3)Be a page as they are now, stored as lines. + +That should do it for frames, but tables are more complex than that : one can +colspan and rowspan a cell. Table implementation is difficult to be done with +the current line/word page structure. + +> Or we could have a wrapper, say dw_frame which could either contain +> horizontal subframes or vertical subframes or contain one dw_page, either +> way it is the same principle. + +Do we really need a whole dw_page for a frameset ? I don't think so. I think it +would be fairly easy to implement frames as a frameset (gtk) widget being mostly +a gtk containers tree, each containing a dw_page. + +> Also a page could be divided up for other things such as alignment, eg if +> you have two paragraphs the top is left aligned, and the bottom is center +> aligned, then we just divide it into two horizontal sub frames and all that +> would be needed would be coding to render a page whose lines are +> center/right alligned. + +This is intereseting. It looks like an extension of the current line/word page +construction. This probably can be done without the frame idea, though. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 23-Sep-2000 a 13:56:14 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Repeated patch + +From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 20:09 + +Sam, + +> ... here's the patch I +> sent again, as I never received a copy back (sorry if this is a repeat). + +Yes, the problem has very deep roots, and I'm still trying to +find out a design solution that gets rid of all related problems. + +Whether to apply the "patch" is a matter of pragmatism. + +I'll keep trying to solve the problems behind... + +Jorge.- + + + +Re: [Dillo-dev]Plugins design + +From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 20:09 + +Eric, + + +> Hi all, +> I'm currently working for plugins support in dillo, and I feel the need +> for a communication protocol between the plugin and dillo. + +Yes, but please try to make as much as possible with the +current scheme (bookmarks). + +I also see the need for a second plugin scheme, with +communication protocol, and better integration. The problem is +that currently we're trying to design the future widget scheme +and until that's done, the second scheme will have to wait. + +Jorge.- + + + +RE: [Dillo-dev]Dw (was new here) + +From: Allan Clark <shark@bl...> - 2000-09-22 19:39 + +Sebastian, + + +<snip> +> It is planned to port Dw to Gtk+, and I'm currently working on DwPage. +> DwHruler will then not used anymore (at least, unless all attributes +> will be supported), but simply GtkHSeparator. +> +> (I've some general doubts on the port, and wrote Jorge about it, but +> didn't get an anser yet.) +> +> I thought that size negotiation should be similar as in Gtk+, i.e. +> containers should (mainly) be responsible for it, plus a few +> extensions (look into the list archives). This is just your idea, +> except that all parameters are stored in the container. For this I +> defined: +> +> struct _DwPageChild +> { +> GtkWidget *widget; +> gfloat rel_width; /* 0: do not resize, +> otherwise: relative to DwPage's width */ +> gfloat rel_height; /* analogue */ +> }; +> +> /* ... */ +> +> void a_Dw_page_add_widget (DwPage *page, +> GtkWidget *widget, +> gfloat rel_width, +> gfloat rel_height, +> gint attr); +> +> Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start. +> +> I tested it with GtkHSeparator (setting rel_width to 1.0), and it +> (mainly) works. This also makes rules with other widths simple (as +> soon as centered text is implemented). +<snip> + +This all sounds great, if you need any help porting Dw just let me know what +needs to be done. +I realised after I had sent the patch to the list that it was going to be a +little obsolete as you were working on the port of Dw. I think the cvs +version of the tree should be kept more up to date, I sent an e-mail to +Jorge about that, below is part of that e-mail (which discussed a number of +things) it is just an idea for dw_page which I think might help us with +table and frame support, and you may be in a better position to decide. + +<part of e-mail I sent to Jorge> +Next is the topic of the dillo widget, it says that on the dillo homepage +http://dillo.so....net/Notes.txt that the dillo widget needs a +revision, I gather from the list that Sebastian Geerken is porting the Dw to +plain GTK+ just like to say that this solution gets my vote, I don't see why +we should re-implement stuff that has already been done and tested and will +be further tested and updated for us. +Lastly (bet you're glad) how far are we with tables/frames support, if the +answer is "still discussing design options" then I would like to add my idea +into the arena, I'm sure someone has probably suggested this, but, why don't +we extend dw_page so that it can be one of the following +1)Contain a number of horizontal sub pages +2)Contain a number of vertical sub pages +3)Be a page as they are now, stored as lines. +Or we could have a wrapper, say dw_frame which could either contain +horizontal subframes or vertical subframes or contain one dw_page, either +way it is the same principle. +This as far as I can tell should be capable of coping with frames and +tables, even nested frames or tables, also it shouldn't be to difficult to +code the support for both tables and frames as frames are already divide a +page either horizontally or vertically, a table as well is just a divided +horizontally, with each horizontal division (ie a row) being divided up +vertically, so the html already lends itself to this kind of design. Also a +page could be divided up for other things such as alignment, eg if you have +two paragraphs the top is left aligned, and the bottom is center aligned, +then we just divide it into two horizontal sub frames and all that would be +needed would be coding to render a page whose lines are center/right +alligned. +<end of the part of e-mail I sent to Jorge> + +Allan + + + +Re: [Dillo-dev]new here + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-22 18:06 + +Allan Clark wrote: +> +> Hi +> As the subject says I'm new here, + +Welcome! + +> but I would like to submit a patch, +> which I *think* fixes bug number 62 where the horizontal rules mean that +> when Dillo reformats after being down-sized it gives the user an +> unneccesary horizontal slider. +> I defined a new flag in dw.c which is set when a widget is a set to fill +> all the horizontal space available, then dw_hruler.c is changed to set +> this flag and then dw_page.c is changed so that we check for the flag +> when reformating and deal with it accordingly. +> The way I have dealt with it means that the hrule will be as long as the +> text of the page is, this means that it won't be as long as an image +> which may be longer (check with dillo on the dillo homepage to see +> this), this is the way Netscape renders it, but would be easy to change +> if you don't like it. + +It is planned to port Dw to Gtk+, and I'm currently working on DwPage. +DwHruler will then not used anymore (at least, unless all attributes +will be supported), but simply GtkHSeparator. + +(I've some general doubts on the port, and wrote Jorge about it, but +didn't get an anser yet.) + +I thought that size negotiation should be similar as in Gtk+, i.e. +containers should (mainly) be responsible for it, plus a few +extensions (look into the list archives). This is just your idea, +except that all parameters are stored in the container. For this I +defined: + +struct _DwPageChild +{ +GtkWidget *widget; +gfloat rel_width; /* 0: do not resize, +otherwise: relative to DwPage's width */ +gfloat rel_height; /* analogue */ +}; + +/* ... */ + +void a_Dw_page_add_widget (DwPage *page, +GtkWidget *widget, +gfloat rel_width, +gfloat rel_height, +gint attr); + +Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start. + +I tested it with GtkHSeparator (setting rel_width to 1.0), and it +(mainly) works. This also makes rules with other widths simple (as +soon as centered text is implemented). + +> Also I think it mucks up slightly if the horizontal rule is not directly +> after a hard break, (that is the hrule isn't on a line all by itself, again +> this should be easy to fix) it seems to render slightly further than it should. +> Anyway see what you think. + +Since <hr>'s are allways the only widget on a line, it is probably the +best to insert hard breaks before and after them. + +> [...] + +Sebastian + + + +Re: [Dillo-dev]email problems + +From: Eric GAUDET <egaudet@in...> - 2000-09-22 03:59 + +-- En reponse de "Re: [Dillo-dev]email problems" de Jorge Arellano Cid, le +20-Sep-2000 : +> +> Eric, +> +>> Jorge, +>> I'm having the hardest time with my ISP loosing email for some domains. +>> Please +>> confirm you have received my patches. +> +> I haven't received a single one! +> + +Damn ! I haven't even got a non-delivery warning ! + +> (and I wrote to your address reporting that some time ago...) +> +> Shame I can't suggest you a good email provider. I switch +> between nettaxi and ematic :-). (Maybe you can try ematic as an +> alternative account). +> + +Actually, I tried 2 different smpt in 2 different countries with the same +(no-)result. +Do you mind if I try to send you some test emails to nettaxi and ematic ? + +Anyway, I posted all my patches and some explanations at : +http://www.rti-zone.org/dillo/ + +I'll try to fix these email problems soon. + +> Jorge.- +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 22-Sep-2000 a 12:39:40 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]email problems + +From: Jorge Arellano Cid <jcid@ne...> - 2000-09-22 01:58 + +Eric, + +> Jorge, +> I'm having the hardest time with my ISP loosing email for some domains. Please +> confirm you have received my patches. + +I haven't received a single one! + +(and I wrote to your address reporting that some time ago...) + +Shame I can't suggest you a good email provider. I switch +between nettaxi and ematic :-). (Maybe you can try ematic as an +alternative account). + +Jorge.- + + + +[Dillo-dev]Repeated patch + +From: Sam Dennis <sdennis101@ge...> - 2000-09-19 15:59 + +Attachments: html_loading.diff + +I think the mail server is eating my messages... anyway, here's the patch I +sent again, as I never received a copy back (sorry if this is a repeat). + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev](no subject) + +From: Allan Clark <allan@al...> - 2000-09-19 13:16 + +Attachments: hrule2.diff + +Sorry about the empty e-mail I pressed the wrong button. +Here is the newer patch for the hrules which differ slightly from the original +and takes into account the feedback from Jorgen and Eric. + + + +[Dillo-dev](no subject) + +From: Allan Clark <allan@al...> - 2000-09-19 13:11 + + + + + +RE: [Dillo-dev]horizontal rules + +From: Eric GAUDET <egaudet@in...> - 2000-09-19 13:01 + +-- En reponse de "[Dillo-dev]horizontal rules" de Allan Clark, le 19-Sep-2000 : +> Quick question for you all. +> Should horizontal rules always be on a line by themeselves or should they be +> allowed to follow text. +> eg +> allan------ +> is that correct or should it be forced to be +> allan +> ----------- +> + +The latter is correct (html spec). +Stop worrying about hrulers, I sent a patch for HR full rendering and +correcting this behavior a few weeks ago (against 0.2.4, not published yet, but +likely due for next version) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 19-Sep-2000 a 21:54:46 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]horizontal rules + +From: Jörgen Viksell <vsksga@ho...> - 2000-09-19 12:54 + +>Quick question for you all. +>Should horizontal rules always be on a line by themeselves or should they +>be +>allowed to follow text. +>eg +>allan------ +>is that correct or should it be forced to be +>allan +>----------- + +The w3 recommendation defines it as a divider of sections of text. So I'd +say that it should be on its own line. + +// Jörgen + + +_________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. + +Share information about yourself, create your own public profile at +http://profiles.msn.com. + + + +Re: [Dillo-dev]cache patch + +From: Luca Rota <drake@it...> - 2000-09-19 12:32 + +Il sab, 16 set 2000, hai scritto: + +> actually. i have placed all released versions of dillo in cvs. Jorge is now +> using cvs. So cvs is newer than the release. + +Wow! Thank you, I didn't know. + +Ciao, +Luca + + + +[Dillo-dev]horizontal rules + +From: Allan Clark <shark@bl...> - 2000-09-19 11:37 + +Quick question for you all. +Should horizontal rules always be on a line by themeselves or should they be +allowed to follow text. +eg +allan------ +is that correct or should it be forced to be +allan +----------- + +Let me know what you think I can do it either way but I'm not sure which is +correct. +p.s. I realise the formatting of the above example might not work on some +e-mail clients but I kept it small so that it should on most. + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Test + +From: Sam Dennis <sdennis101@ge...> - 2000-09-18 20:30 + +Just testing, haven't received any mails back from this thing, oddly. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Actual fix + +From: Sam Dennis <sdennis101@ge...> - 2000-09-18 16:10 + +Attachments: html_loading.diff + +Sorry about the last patch, I didn't have a version of gdb that worked with +dillo so diagnosing the problem was difficult. It turns out that to fix bugs +#74 and #69, all that is needed is two simple checks. I'm sure that there's +a deeper problem, but it doesn't hurt to check for null pointers, which is +what we are currently getting, and this *does* solve the problem. + +Patch enclosed. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]new here + +From: Allan Clark <allan@al...> - 2000-09-18 10:52 + +Attachments: hrule.diff + +Hi +As the subject says I'm new here, but I would like to submit a patch, +which I *think* fixes bug number 62 where the horizontal rules mean that +when Dillo reformats after being down-sized it gives the user an +unneccesary horizontal slider. +I defined a new flag in dw.c which is set when a widget is a set to fill +all the horizontal space available, then dw_hruler.c is changed to set +this flag and then dw_page.c is changed so that we check for the flag +when reformating and deal with it accordingly. +The way I have dealt with it means that the hrule will be as long as the +text of the page is, this means that it won't be as long as an image +which may be longer (check with dillo on the dillo homepage to see +this), this is the way Netscape renders it, but would be easy to change +if you don't like it. +Also I think it mucks up slightly if the horizontal rule is not directly +after a hard break, (that is the hrule isn't on a line all by itself, again +this should be easy to fix) it seems to render slightly further than it should. +Anyway see what you think. +I am also hoping that the new flag defined might help us in frames and tables, +where the frame or table cell width is not an absolute value but is given as +"whatever space is left after drawing the previous frames/table cells. +Also I don't think I have made the patch correctly, it says in the docs to use +diff -pru but when I did cvs came back with an error saying no such option, in +the end I used cvs diff > hrule.diff, please tell me if this is wrong and what +I should be doing. + +Allan + + + +[Dillo-dev]Debugging problems + +From: Sam Dennis <sdennis101@ge...> - 2000-09-17 23:48 + +Has anyone else had problems debugging dillo with gdb? I'm getting unkown +signals soon after I run or attach. + +Admittedly, I am using a gdb release from '96... + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]cache patch + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-16 17:04 + +> Please, sends your patches to Jorge. But before takes the new dillo's version +> from download.so....net/dillo/ the cvs version is quite outdated. +> + +actually. i have placed all released versions of dillo in cvs. Jorge is now +using cvs. So cvs is newer than the release. + + + +Re: [Dillo-dev]cache patch + +From: Luca Rota <drake@it...> - 2000-09-16 13:42 + +Il sab, 16 set 2000, hai scritto: + +Welcome, + +> Hi, I'm new to dillo development, although I worked with armadillo for a +> while, I've been looking at your cache system and have made a change which + +Oh, yes. I remember a justification patch and the html stack patch. Right? + +> seems to cause less segfaults when moving around without waiting for things +> to finish downloading (which has crashed dillo many times for me). It's +> probably not correct, but it does seem to improve the situation. + +Please, sends your patches to Jorge. But before takes the new dillo's version +from download.so....net/dillo/ the cvs version is quite outdated. + +Ciao, +Luca + + + +[Dillo-dev]cache patch + +From: Sam Dennis <sdennis101@ge...> - 2000-09-16 04:15 + +Attachments: cache_patch.gz + +Hi, I'm new to dillo development, although I worked with armadillo for a +while, I've been looking at your cache system and have made a change which +seems to cause less segfaults when moving around without waiting for things +to finish downloading (which has crashed dillo many times for me). It's +probably not correct, but it does seem to improve the situation. + +-- +Sam Dennis <sdennis101@ge...> + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Sizes in html + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-14 12:07 + +Hi! + +While porting the DwPage, I'm thinking about how widgets in the page +should be resized. (Anything except text will be a widget, even +probably <div>'s with align=left/right (a new DwPage), but alignments +are far away from an implementation.) + +DwPage is derived from GtkContainer, and Gtk+ containers typically are +responsible on positioning and resizing of their children. (An +exception is, of course, when widgets resize thereselves, then the +container has to react on this.) E.g., if you want to add a widget to +a GtkBox, you use gtk_box_pack_start and set the arguments expand, +fill and padding to the appropriate values, and anything else is done +by the GtkBox. + +So, which parameters should be used by a_Dw_page_add_widget? My +current idea is based on relative width and height, or zero to prevent +resizing by DwPage. It the latter case, the widget's size has to be +set otherwise (e.g. by the html parser). This is quite obvious for +images, but it is also suitable for tables: they should (in most +cases) be added with a relative width of 100%, since they should be +resized when the page is resized, but then can calculate the size they +really need. + +Send any comments, about this idea in general, or if you find that my +idea is not suitable for a specified html elemtent. + +Another point is positioning. The only thing which comes currently to +mind, is the "align" attribute of some tags. But this will be done +later. + +Sebastian + + + +[Dillo-dev]email problems + +From: Eric GAUDET <egaudet@in...> - 2000-09-13 06:27 + +Jorge, +I'm having the hardest time with my ISP loosing email for some domains. Please +confirm you have received my patches. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 13-Sep-2000 a 15:26:12 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Plugins design + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-13 00:30 + +> I have two options : +> - use a special Content-Type=x-dillo-command. What if we need to send +> both commands and a document in a single answer ? Either I'll have to +> dirty-hack the header parsing function to ignore and redirect +> x-dillo-command content until it finds an other content-type, or +> I'll have to add support for multipart-mime, which seems an overkill. +> - use special http header fields. Pragma seems to be an application +> specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be +> understood by dillo to be a command sent by the plugin for him. +> Alternatively, we can use a non-http field (X-Dillo-Command:), as +> fields begining with X- can't exist in future http implementations, and +> it's a local communication anyway. +> + +If you must use http, you definately want to use X- headers. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-12 09:35 + +Sean 'Shaleh' Perry wrote: +> [...] +> > (Although the implementation looks a bit strange: 1. I think there +> > should be a global font list; 2. The Gdk fonts are not removed? But +> > this is a separate problem.) +> > +> +> yes, a global list would be nice, also, a global size array. I have font +> size=2 or font size=+3 working, but i had to implement a local size list +> because the open_h() function need a list in descending order and I wanted a +> list in ascending order. + +I think, it is not very important, where the fonts are stored, when +you have a simple interface to access them. This is an implementian +detail, which does not effect the code outside. + +BTW: Other widgets (e. g. buttons) use fonts, too. Currently, there +fonts are given by Gtk, but may the html author change them? + +> > I remember that there are a few more attributes (e.g. underlining, +> > backgrounds), which I will add perhaps, after my Gtk port of DwPage is +> > running correctly. +> > +> +> I am trying to implement the <u> tag now. It looks like all I have to do is +> modify dw_page_expose_line(), this is where the link is underlined. However my +> boolean is not surviving into the function call. Most confusing. If I don't +> get it in a day or so, would you mind taking a peek? + +The best way will be to extend the DwPageAttr structure. Then any +attributes can be simply set by filling an DwPageAttr structure, and +DwPage will be responsible for render them. (I can do the last, but +first I want to finish the Gtk+ port to DwPage.) + +> > a_Dw_page_init_attr (DW_PAGE (page), &attr); +> > attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +> > attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); +> > +> +> but a_Dw_page_find_font() does not actually check to see if a font can be +> rendered. What if your system lacked 'times new roman'. +> +> <font face="Lucida,Verdana,Helvetica,Arial">My text</font> +> +> I have to decide which in that list of fonts I can use. In this case, Lucida +> and Helvetica are known to work, I am sure Arial will. But I have no way to +> query dillo to find out if font 'foo' can be loaded. +> +> Perhaps find_font should try to look up the font via gdk and give back a "could +> not find it" error? Or perhaps we need a query_system_font() to see if a font +> is valid, then find_font() to load it into dillo. + +The font is loaded in Dw_page_realize_font. Perhaps this function +could be modified, so that you may specify alternatives, when calling +a_Dw_page_find_font. As I wrote above, the interface should be as +simple as possible, so a query function is probably not a good idea. + +Sebastian + + + +[Dillo-dev]Plugins design + +From: Eric GAUDET <egaudet@in...> - 2000-09-12 01:58 + +Hi all, +I'm currently working for plugins support in dillo, and I feel the need +for a communication protocol between the plugin and dillo. + +So far, dillo calls a plugin, sends a bunch of <name=value> parameters, +and waits for an http-like answer, most of the time being +Content-Type=text/html <html> ... </html> + +Now, say the Bookmarks plugin wants to ask dillo to ask an "Add +Bookmark" menu, and also an "Edit Bookmarks" menu. How can it do that ? +Say the Ftp plugin wants to tell dillo he can handle "ftp://" urls, as +well as the "Mailto" plugin want to tell dillo he can handle "mailto:" +urls. How can it do that ? + +I have two options : +- use a special Content-Type=x-dillo-command. What if we need to send +both commands and a document in a single answer ? Either I'll have to +dirty-hack the header parsing function to ignore and redirect +x-dillo-command content until it finds an other content-type, or +I'll have to add support for multipart-mime, which seems an overkill. +- use special http header fields. Pragma seems to be an application +specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be +understood by dillo to be a command sent by the plugin for him. +Alternatively, we can use a non-http field (X-Dillo-Command:), as +fields begining with X- can't exist in future http implementations, and +it's a local communication anyway. + +What do you think ? + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 12-Sep-2000 a 10:38:04 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Eric GAUDET <egaudet@in...> - 2000-09-12 01:36 + +--- En reponse de "Re: [Dillo-dev]Misc." de Luca Rota, le 11-Sep-2000 : +> Il dom, 10 set 2000, hai scritto: +> +> > If you'd like to know some of the reasons of current goals in +> > dillo, may I suggest: +> > +> > - Cathedral & the Bazaar (ESR) +> > - Homesteading the noosphere (ESR) +> > - http://www.levien.com/free/decommoditizing.html (Raph Levien) +> > - http://www.mcsr.olemiss.edu/~mudws/font.html +> > - http://www.tuxedo.org/~esr/html-hell.html +> +> May I suggest: +> http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7) +> + +All these links deserve to be in dillo's home page. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 12-Sep-2000 a 10:35:42 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Luca Rota <drake@it...> - 2000-09-11 16:55 + +Il dom, 10 set 2000, hai scritto: + +> If you'd like to know some of the reasons of current goals in +> dillo, may I suggest: +> +> - Cathedral & the Bazaar (ESR) +> - Homesteading the noosphere (ESR) +> - http://www.levien.com/free/decommoditizing.html (Raph Levien) +> - http://www.mcsr.olemiss.edu/~mudws/font.html +> - http://www.tuxedo.org/~esr/html-hell.html + +May I suggest: +http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7) + +I'd like focus your attention on: +levien> the main design goals were that Gzilla be small, simple, and fast. I +had a few other goals. For one, I wanted Gzilla to be really good at +incremental rendering. + +levien> the Gzw (Gzilla Widget) framework was in place, providing a much more +powerful infrastructure for future development such as tables. + +Please, read the GZW section carefully. + +Note: Dillo is based on gzilla code and GZW is the original name of Dw. + +Ciao, +Luca + + + +Re: [Dillo-dev]Misc. + +From: <ikluft@th...> - 2000-09-11 01:19 + +>From: "Jorge Arellano Cid" <jcid@ne...> +>> Embbeding Perl 5... +> +> Although not a bad idea "per se", this is not the project for +>trying it. Dillo can't even render HTML by now, a module API is +>inexistent, and the Dw (dillo widget) is migrating to GTK+ in an +>effort to overcome a bunch of rendering-related problems. +> +> May I suggest galeon? It uses gecko, has an API, is smaller +>than mozilla and it's also free. + +Thanks for the pointer. I didn't see them on Freshmeat since they got +categorized under GNOME instead of with the other web browsers. + +I'll go look over there. Consider the patch that I sent for using glib +hash tables on the About menus to be a gift from an Open Source supporter +who was "passing through". (But I can understand if you'll want to +pull my personal URL out of there - I was planning on sticking around +when I put that there. :-) For future reference, that kind of patch +can also serve as an example of replacing linear searches with hash +lookups to build future scalability into your project. That's experience +I've gotten from 10 years working in the industry, including on OS's from +a mainframe Unix to an embedded OS for large routers. I hope it helps. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 23:19 + +> +> a_Dw_page_init_attr (DW_PAGE (page), &attr); +> attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +> attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); +> + +but a_Dw_page_find_font() does not actually check to see if a font can be +rendered. What if your system lacked 'times new roman'. + +<font face="Lucida,Verdana,Helvetica,Arial">My text</font> + +I have to decide which in that list of fonts I can use. In this case, Lucida +and Helvetica are known to work, I am sure Arial will. But I have no way to +query dillo to find out if font 'foo' can be loaded. + +Perhaps find_font should try to look up the font via gdk and give back a "could +not find it" error? Or perhaps we need a query_system_font() to see if a font +is valid, then find_font() to load it into dillo. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 23:04 + +> +> It's quite simple, but I think, you should only use the +> a_Dw_page_find_font function: Fill out a DwPageFont structure, then +> call this function, and you will get an index you can use in the +> DwPageAttr structure. I wrote something like the following, and it +> worked: +> +> <code snipped> +> +> Only as an example. You don't have to bother about loading and +> removing of fonts. +> +> (Although the implementation looks a bit strange: 1. I think there +> should be a global font list; 2. The Gdk fonts are not removed? But +> this is a separate problem.) +> + +yes, a global list would be nice, also, a global size array. I have font +size=2 or font size=+3 working, but i had to implement a local size list +because the open_h() function need a list in descending order and I wanted a +list in ascending order. + +> I remember that there are a few more attributes (e.g. underlining, +> backgrounds), which I will add perhaps, after my Gtk port of DwPage is +> running correctly. +> + +I am trying to implement the <u> tag now. It looks like all I have to do is +modify dw_page_expose_line(), this is where the link is underlined. However my +boolean is not surviving into the function call. Most confusing. If I don't +get it in a day or so, would you mind taking a peek? + +> PS2: Two wishes: 1. Give the user the possibility to turn off any +> loading of non-standard fonts (except the user's style sheet), 2. A +> factor for size would be nice, i.e. the user should specify that dillo +> should use x times the font size specified by the author of the page. +> + +these are both great options. + +Once my font patch is accepted, I would also like a standard size list created +as mentioned above. I just winged it. + +Once I get underline working, I have all of the font modifying tags implemented. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sebastian Geerken <S.Geerken@pi...> - 2000-09-10 22:55 + +Sean 'Shaleh' Perry wrote: +> +> > +> > However, this is widely used. If you can do it easily, why not ? +> > +> +> it can be done fairly easily. style sheets also allow for aribitrary fonts to +> be used. +> +> My initial question was: how do we want to implement this? My experience with +> gtk is minimal, fonts even less. + +It's quite simple, but I think, you should only use the +a_Dw_page_find_font function: Fill out a DwPageFont structure, then +call this function, and you will get an index you can use in the +DwPageAttr structure. I wrote something like the following, and it +worked: + +DwPageFont font; +DwPageAttr attr; +gint attr_i; + +/* ... */ + +font.name = "times"; +font.size = 14; +font.bold = FALSE; +font.italic = FALSE; + +a_Dw_page_init_attr (DW_PAGE (page), &attr); +attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); + +a_Dw_page_add_text (DW_PAGE (page), "Some text.", attr_i); + +Only as an example. You don't have to bother about loading and +removing of fonts. + +(Although the implementation looks a bit strange: 1. I think there +should be a global font list; 2. The Gdk fonts are not removed? But +this is a separate problem.) + +I remember that there are a few more attributes (e.g. underlining, +backgrounds), which I will add perhaps, after my Gtk port of DwPage is +running correctly. + +Sebastian + +PS1: I'm currently porting DwPage to Gtk, but the interface will be +the same (except adding widgets), so I hope, your changes will run +with both versions of DwPage. + +PS2: Two wishes: 1. Give the user the possibility to turn off any +loading of non-standard fonts (except the user's style sheet), 2. A +factor for size would be nice, i.e. the user should specify that dillo +should use x times the font size specified by the author of the page. + + + +RE: [Dillo-dev]Misc. + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 22:22 + +> +> Gentleman, please, there's no CSS support in dillo by now, it's +> NOT a near future concern, and it can't cope with preferences +> like: +> +> "don't allow cookies" +> "download directory = ~/download" +> "discard animated gifs" +> "Don't load images" +> "Start with 600x400" +> etc... +> + +indeed, but it does handle: + +"no white backgrounds" +"use font "blah" for tag foo" +and just about any form of "I want html to look like" + +> -------------------------------------------------------------- +> +>> Badly written HTML... +> +> Well, certainly an arguable topic, but the current position is +> NOT to support badly written HTML. +> + +dillo should support the "oops" as much as possible. Simply forgetting to +close a tag should not ruin the rest of the page. Users will see this as a bug +in dillo. + +> - If the publisher wants to reach a broad spectrum, he'll +> strive for correct HTML. + +Web sites that allow users to post responses with embedded html have no means +to control what users enter. Letting a fellow open a font or bold tag and +making the rest of the page look horrid just seems wrong. It is trivial to get +tags like bold to clean up after previous bold tags. + +> -------------------------------------------------------------- +> +>> The question is do we want to actually make dillo display +>> html like the web author intended? +> +> Quite interesting question! +> +> The answer is: NO! +> +> Ideally, in dillo, the html should be displayed the way the +> user wants, not the author. +> + +back to CSS here. Load YOUR sheet last, and you override the author. + + + +[Dillo-dev]Misc. + +From: Jorge Arellano Cid <jcid@ne...> - 2000-09-10 21:59 + +Hi! + + +Lots of email lately, hmmmm... + +Let's clarify some things: + +- Dillo is a lean, small and fast web client. +- Dillo still can't render HTML (This is the main goal) +- Dillo is very far away from supporting scripting languages. +- CSS is NOT a priority, nor a concern by now. +- Dillo aims to be a usable HTML web browser. + +The "fully standards compliant" browser project is mozilla, a +better start for scripting languages is galeon (uses the gecko +engine), if you also want to "get&feel" M$ content, you should go +with the latest flavour of IE (probably on Windoze!;), and if you +don't like Win* and also want the as-full-as-possible Internet +experience, you'd probably should keep with Netscape. + +If you'd like to know some of the reasons of current goals in +dillo, may I suggest: + +- Cathedral & the Bazaar (ESR) +- Homesteading the noosphere (ESR) +- http://www.levien.com/free/decommoditizing.html (Raph Levien) +- http://www.mcsr.olemiss.edu/~mudws/font.html +- http://www.tuxedo.org/~esr/html-hell.html + +-------------------------------------------------------------- + +> I have one problem that I can't seem to get around. Our site uses a SSL +> (security socket layer) that the standard http_proxy setting doesn't allow +> for. I would like some help regarding this issue if possible! + +Probably the easiest way around it is to grab the https pages +with 'curl' and sending them to dillo using dillo's simple plugin +scheme (currently in alpha, but working). +Sean's idea is also a good starting point (libssl). + +> Thanks again for making Dillo such a great product! + +Thanks to you for greeting us +(Would you believe that aprox. only 1 of 8 persons take time to +write a gentle comment at first post?) + +-------------------------------------------------------------- + +> Embbeding Perl 5... + +Although not a bad idea "per se", this is not the project for +trying it. Dillo can't even render HTML by now, a module API is +inexistent, and the Dw (dillo widget) is migrating to GTK+ in an +effort to overcome a bunch of rendering-related problems. + +May I suggest galeon? It uses gecko, has an API, is smaller +than mozilla and it's also free. + +-------------------------------------------------------------- +> ... +> as I mentioned in a previous mail, user preferences could easily +> be stored as a local style sheet which was added to the end of the style +> sheet reading. + +Gentleman, please, there's no CSS support in dillo by now, it's +NOT a near future concern, and it can't cope with preferences +like: + +"don't allow cookies" +"download directory = ~/download" +"discard animated gifs" +"Don't load images" +"Start with 600x400" +etc... + +-------------------------------------------------------------- + +> Badly written HTML... + +Well, certainly an arguable topic, but the current position is +NOT to support badly written HTML. + +Mainly due to: + +* http://www.levien.com/free/decommoditizing.html +- If the publisher wants to reach a broad spectrum, he'll +strive for correct HTML. + +Note: I'm sure there're different opinions on this. + +-------------------------------------------------------------- + +> The question is do we want to actually make dillo display +> html like the web author intended? + +Quite interesting question! + +The answer is: NO! + +Ideally, in dillo, the html should be displayed the way the +user wants, not the author. + +One of the things a dislike more about Netscape is to have to +see the page's as the author wants. No matter how hard I try to +set my preferences to use certain fonts and sizes, they seem to +always find the trick to get over my settings. +Not to mention scaled fonts that look trembling & tiny, etc. + +Finally, I definitively agree that those pages have, by far, a +better looking result when looked from a distance :-). Personally +I do prefer dillo's rendering for reading HTML documentation. + +-------------------------------------------------------------- + +Jorge.- + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 19:46 + +> +> However, this is widely used. If you can do it easily, why not ? +> + +it can be done fairly easily. style sheets also allow for aribitrary fonts to +be used. + +My initial question was: how do we want to implement this? My experience with +gtk is minimal, fonts even less. + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Eric GAUDET <egaudet@in...> - 2000-09-10 09:38 + +--- En reponse de "RE: [Dillo-dev]implementation question: how to +decide if a font" de Sean 'Shaleh' Perry, le 10-Sep-2000 : +> > +> > A good thing would be to load 2 fonts (proportionnal and mono) from +> > dillorc and use only these everywhere in dillo. +> > I'm not sure you want to load fonts on request. You probably can do +> > it, +> > it's even possible other browsers do it, but I'm not sure it's +> > needed. +> > +> +> dillo currently uses: courier and lucida for special tags and +> helvetica for everything else. The question is do we want to +> actually make dillo display html like the web author intended? I +> can understand not wanting to load each and every font asked for, +> but requests for items like arial or in the case of +> freshmeat lucida, which we are already using, why not allow it? + +The html author is not supposed to ask for a font (even if he can) : +only if it's proportionnal or fixed width. He's not even supposed to +specify B(old), I(talic) or any style, but use instead STRONG, EM tags. +That's the same thing of using special chars instead of entities. + +However, this is widely used. If you can do it easily, why not ? + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Sep-2000 a 18:32:45 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 06:56 + +> +> A good thing would be to load 2 fonts (proportionnal and mono) from +> dillorc and use only these everywhere in dillo. +> I'm not sure you want to load fonts on request. You probably can do it, +> it's even possible other browsers do it, but I'm not sure it's needed. +> + +dillo currently uses: courier and lucida for special tags and helvetica for +everything else. The question is do we want to actually make dillo display +html like the web author intended? I can understand not wanting to load each +and every font asked for, but requests for items like arial or in the case of +freshmeat lucida, which we are already using, why not allow it? + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Eric GAUDET <egaudet@in...> - 2000-09-10 06:46 + +--- En reponse de "[Dillo-dev]implementation question: how to decide if +a font is v" de Sean 'Shaleh' Perry, le 10-Sep-2000 : +> I am working on <font face="foo,bar">. There is no central list of +> fonts dillo +> is willing to support or a way to query them. Html_page_check +> declares an array +> of 4 font names, but only helvetica ([0]) is used from that array. +> + +teletype style and PRE use courier, but hard-coded, not from this array +(which is local anyway). + +... +> +> can dillo load font 'foo'? +> +> Suggestions? I suspect this will require code in dw_page.c. +> + +A good thing would be to load 2 fonts (proportionnal and mono) from +dillorc and use only these everywhere in dillo. +I'm not sure you want to load fonts on request. You probably can do it, +it's even possible other browsers do it, but I'm not sure it's needed. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Sep-2000 a 15:34:09 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]implementation question: how to decide if a font is valid + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 06:00 + +I am working on <font face="foo,bar">. There is no central list of fonts dillo +is willing to support or a way to query them. Html_page_check declares an array +of 4 font names, but only helvetica ([0]) is used from that array. + +the face attribute of font is a comma separated list of the fonts the html +author wanted to use, in order of preference. To continue with freshmeat: + +<FONT FACE="Lucida,Verdana,Helvetica,Arial"> + +so, try Lucida, then Verdana, then Helvetica, then settle for Arial. + +What I need is a way to say: + +can dillo load font 'foo'? + +Suggestions? I suspect this will require code in dw_page.c. + + + +[Dillo-dev]handling poorly written html + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 05:45 + +So, was reading the recent freshmeat editorial when i noticed that freshmeat's +html creation software likes to leave <b>'s open. So I tried to make bold +close any open bold tags. First I tried Html_cleanup_tag(), which was already +in use and thus documented. However cleanup_tag only handles the case of +"<p><p>", i.e. back to back tags. freshmeat was doing "<b><font></font><b>". +So I looked at pop_tag. This function appears to properly handle the case +where there are extra tags between the tag in question and the one I want +removed. my dillo can now read html that has dangling b tags. Will probably +add more of this type code as we discover other bad html. + +Point of this letter is this: Html_cleanup_tag is redundant considering the +power of Html_pop_tag. Html_cleanup_tag also fails miserably on many pieces of +html. I have a patch prepared which removes this function and replaces all +calls to it with Html_pop_tag. + +Comments? + +P.S. Html_pop_tag has a todo comment, handle the case where tags dont nest. As +I have stated above, it seems to do so. Can anyone point to cases where it +fails? + + + +RE: [Dillo-dev]on the subject of SCRIPT tags + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 02:41 + +> +> I guess the events (onClick in a A tag,...) are to be done yet. +> + +yep, setup the events and then make it so they call the interpeter. + + + +RE: [Dillo-dev]News + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-10 02:40 + +> +> I remember that. Do we support style sheets now ? (or are we about to ?) +> Good idea anyway. +> + +no, but it is on my todo list. As I mentioned we can inch our way in by +storing prefs in style sheet format. This gets the style sheet parser working. + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: <ikluft@th...> - 2000-09-10 02:27 + +>From: Eric GAUDET <egaudet@in...> +>Embeding perl in dillo would probably never go into dillo's main +>distribution. But that doesn't mean it's not interesting nor you +>shouldn't do it. Find your way doing it as a side project for dillo +>using dillo's standard interfaces (plugin or module). + +Well, it's too big an effort to undertake unless it's likely the +project will embrace it to a greater degree than that. + +I fully respect that the volunteers who have contributed to the project +should determine its direction. And I think Dillo looks promising. + +But I'm sure it won't be a surprise if I continue looking for a place +where the browser-side perl idea would have a stronger acceptance. I'm +willing to do this work but I most certainly don't want it to disturb +volunteers who have already contributed. Maybe the idea's time just +hasn't come yet. + +In any case, I appreciate the time you've taken to help me consider what +the options were for this idea. I wish you success. I'll mention this +project to anyone who sounds like they might be interested in volunteering. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +RE: [Dillo-dev]News + +From: Eric GAUDET <egaudet@in...> - 2000-09-10 02:14 + +--- En reponse de "RE: [Dillo-dev]News" de Sean 'Shaleh' Perry, le +09-Sep-2000 : +> > +> > I'm working on the Bookmarks plugin right now, and I've got lots of +> > ideas fo plugins things. I'm willing to make a Preferences plugin +> > too, as I saw the project is suspended and drake is most likely +> > out of dillo. +> > +> +> as I mentioned in a previous mail, user preferences could easily be +> stored as a local style sheet which was added to the end of the +> style sheet reading. This way user prefers override the author's +> prefs. Or maybe an option "override web author?". If no, the +> style would be read first. +> +> style sheets let the user specifiy almost anything about the look of +> a web page +> -- bg color, image, text colors by tag, etc. +> +> If you could make the preference item output a style sheet formatted +> file, we can only load it and ignore style sheets for right now. + +I remember that. Do we support style sheets now ? (or are we about to ?) +Good idea anyway. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Sep-2000 a 11:12:05 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: <ikluft@th...> - 2000-09-10 02:14 + +>From: "Sean 'Shaleh' Perry" <shaleh@vi...> +>And here I was thinking the point of dillo was not to be the next mozilla. +> +>Guys, just once could a project do its job and only its job. I want a lean, +>mean, web browser. It should support whatever the w3c says a web browser +>should support and that is about it. Maybe some little tweaks to make a user's +>life happier. + +OK, I understand. + +That was why I asked. I didn't know the opinions out there. You're all +the ones who have done the work so far and that must be respected in +any volunteer effort. The polite thing to do was bring it up for +discussion and actually listen to the answers. + +Well, I'm listening and it's 0 for 2 right now. One more makes it +a trend. :-) Oh well. It was worth the try. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET <egaudet@in...> - 2000-09-10 02:11 + +--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian +Kluft, le 09-Sep-2000 : +<snip snip> +> Those examples were looking further out in the future, assuming this +> feature were accepted by the group and had time to build out +> access to lots of Dillo's APIs. I'm thinking of starting with a +> module, adding perl interfaces to existing Dillo module APIs one +> at a time, and seeing where it goes from +> there. The idea of a plugin could be explored as a follow-on. +> +<snip snip> + +Ok, as you seem quite excited by this idea, here are your options: + +- If you don't feel the need for constant interaction with dillo, go +for a plugin. You can do that without any dillo-dev consensus : this is +an external program (a project outside of dillo) launched in a shell by +dillo when clicking on a fake url "dpi://<plugin-name>/<parameters>", +doing his job (such as saving a file), sending datas to dillo (such as +an html page), then exit. Plugins are being implemented now (I did a +plugin-lib and I'm studying dillo's side calls), you'll be able to test +your plugin quite soon, and you'll have support (by me at least ;-) + +- If you can live without dillo's interactions, you'll need a module. +There's no module interface planned for now : you'll have to design it, +and it will be accepted only if it's a generic module interface (not +perl-specific) so others can benefit your work and do other modules. +You'll have to work alone because we don't want to bloat dillo with a +bunch of modules, and we don't feel immediate use of modules (you've +heard Sean : I believe he doesn't want modules at all, I'm not sure I +want that myself). + +Embeding perl in dillo would probably never go into dillo's main +distribution. But that doesn't mean it's not interesting nor you +shouldn't do it. Find your way doing it as a side project for dillo +using dillo's standard interfaces (plugin or module). + +ciao + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Sep-2000 a 10:45:10 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]on the subject of SCRIPT tags + +From: Eric GAUDET <egaudet@in...> - 2000-09-10 01:19 + +--- En reponse de "[Dillo-dev]on the subject of SCRIPT tags" de Sean +'Shaleh' Perry, le 09-Sep-2000 : +> One of the patches I have given Jorge is to have script tags use the +> stash. +> So, now all of the script code is stored somewhere, you just have to +> get +> it to the interpreter and add support for script hooks in html tags. + +I guess the events (onClick in a A tag,...) are to be done yet. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 10-Sep-2000 a 10:17:46 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]News + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:12 + +> +> I'm working on the Bookmarks plugin right now, and I've got lots of +> ideas fo plugins things. I'm willing to make a Preferences plugin too, +> as I saw the project is suspended and drake is most likely out of dillo. +> + +as I mentioned in a previous mail, user preferences could easily be stored as a +local style sheet which was added to the end of the style sheet reading. This +way user prefers override the author's prefs. Or maybe an option "override web +author?". If no, the style would be read first. + +style sheets let the user specifiy almost anything about the look of a web page +-- bg color, image, text colors by tag, etc. + +If you could make the preference item output a style sheet formatted file, we +can only load it and ignore style sheets for right now. + + + +[Dillo-dev]on the subject of SCRIPT tags + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:08 + +One of the patches I have given Jorge is to have script tags use the stash. +So, now all of the script code is stored somewhere, you just have to get +it to the interpreter and add support for script hooks in html tags. + + + +RE: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 19:07 + +And here I was thinking the point of dillo was not to be the next mozilla. + +Guys, just once could a project do its job and only its job. I want a lean, +mean, web browser. It should support whatever the w3c says a web browser +should support and that is about it. Maybe some little tweaks to make a user's +life happier. + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: <ikluft@th...> - 2000-09-09 18:49 + +>From: Eric GAUDET <egaudet@in...> +>I'm not really against the idea : I know perl, I like perl, I don't +>know javascript. If you think you can achieve that fast and _as_a_ +>_dillo_module_, good for you and for us. (I don't see immediate +>applications, though, but if you do it, I'll most likely use it ;-) + +OK, thank for that note. :-) + +Yes, as I re-read the docs for the difference between a module and a plug-in, +I think a module is what I had in mind. The intent behind it could also +be thought of as a way to write new Dillo modules in perl. + +It's something that I've thought since the dawn of the web that someone +should do with a browser. Nearly all my web software development over +that time has been on the server side. Over the years, work on several +closed-source web servers has occasionally prevented me from contributing +to projects like Apache. Although I did take one opportunity to contribute +a module (mod_mime_magic) that Apache accepted in 1997. + +In the meantime, perl never happened on the browser side. So I'm looking +around for a project which would be receptive to the idea. Dillo is the +first choice after a quick survey because it uses GTK with no Motif legacy, +it's GPL, it's relatively new, etc. Admittedly, I'm in no political +position to push this on any project so this idea completely depends on +others liking it too. If I can't convince anyone, the idea goes nowhere. + +>But we need to keep dillo's priorities in mind : dillo's still lacking +>a lot of important features for a browser, and we sure can use some +>extra coders. (If you know gtk+ and you want to help with tables and +>frames support, contact Jorge) + +Sorry - I've been on the server side of the web. I don't have that +kind of experience. + +I can understand that the project needs to have priorities. Even if this +idea doesn't (yet) serve a higher priority, I'll accept the repsonsibility +to make sure it doesn't get in the way of them. I think after some of the +implementation is started, it could actually help implement some of the +priorities. + +>Having an embeded language would be nice, but IMHO the criterias for +>such a thing in dillo are : +>- either a quick-hack, very lightweight, non-standard language (ie: not +>javascript) : no wasting our time doing that, just add some dillo-only +>dynamic html pages. +>- or javascript, with all the efforts it needs. +> +>My main concern is : why perl ? If you spend a lot of time glueing perl +>with dillo, I'd prefer you do it in a way other languages can be +>interfaced too. I know you link about embeding perl in a C program, but +>it's too much perl-specific to my taste. + +Well, yeah, it's still in the thinking/proposal stage. But the idea looks +like the perl-specific code would have to be kept to its own separate module. +On the surface of it, except for occasional additional functions in some +API's to make information available to other modules (like the perl module), +I don't yet see any reason why it can't be contained in its own module +much like mod_perl contains all the perl-specific code in Apache. + +As I continue to form the idea with your input, this Dillo module would +be glue code between the Dillo APIs and Perl APIs. Each would view the +other as a module, and access to their APIs. + +>> The thought I had for Dillo was not to replace any existing C code +>> in Perl. But rather it should allow access to as many as possible +>> of the APIs so that some new features can be prototyped or +>> implemented as an embedded perl script calling Dillo API functions. +>> It could also customize things like menus by putting embedded +>> perl scripts behind some of the callbacks that handle them. +>> (Imagine having live Slashdot headlines in a pulldown menu. :-) +> +>This has been discussed in this list a few weeks ago (check the +>archives), under the name of "modules", and rejected (for now) because +>it seemed too much work and second priority. + +OK, sorry. Then that wasn't a good example. :-) Time to go through +the archives... (So far I've gone through the web site and been watching +the mail list for a couple weeks.) + +But the point is that such extensions could be possible to write in perl, +not just in C. + +>Some of your examples let me think you might want to implement a perl +>"plugin", which is not a "module", much more like a local CGI (check +>the archives for that too, or ask me, as I'm the one working on +>plugins). I like _this_ idea : you could put together and maintain your +>perl plugin without bothering patching/linking with dillo, because it +>would be an _external_ program called by dillo. + +Those examples were looking further out in the future, assuming this feature +were accepted by the group and had time to build out access to lots of +Dillo's APIs. I'm thinking of starting with a module, adding perl interfaces +to existing Dillo module APIs one at a time, and seeing where it goes from +there. The idea of a plugin could be explored as a follow-on. + +>Anyway, embeding whatever in dillo will be Jorge's decision eventually: +>wait for his answer before you begin something big ;-) + +:-) Yup, don't worry. I did read the authors page. I haven't written +any code for this yet. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET <egaudet@in...> - 2000-09-09 13:37 + +--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian +Kluft, le 09-Sep-2000 : +> The main question is whether people want it. I clearly understand +> your first impression was against the idea, and respect your +> opinion. If you're still open for some more technical info, take +> a look at +... + +I'm not really against the idea : I know perl, I like perl, I don't +know javascript. If you think you can achieve that fast and _as_a_ +_dillo_module_, good for you and for us. (I don't see immediate +applications, though, but if you do it, I'll most likely use it ;-) +But we need to keep dillo's priorities in mind : dillo's still lacking +a lot of important features for a browser, and we sure can use some +extra coders. (If you know gtk+ and you want to help with tables and +frames support, contact Jorge) +Having an embeded language would be nice, but IMHO the criterias for +such a thing in dillo are : +- either a quick-hack, very lightweight, non-standard language (ie: not +javascript) : no wasting our time doing that, just add some dillo-only +dynamic html pages. +- or javascript, with all the efforts it needs. + +My main concern is : why perl ? If you spend a lot of time glueing perl +with dillo, I'd prefer you do it in a way other languages can be +interfaced too. I know you link about embeding perl in a C program, but +it's too much perl-specific to my taste. + +> The thought I had for Dillo was not to replace any existing C code +> in Perl. But rather it should allow access to as many as possible +> of the APIs so that some new features can be prototyped or +> implemented as an embedded perl script calling Dillo API functions. +> It could also customize things like menus by putting embedded +> perl scripts behind some of the callbacks that handle them. +> (Imagine having live Slashdot headlines in a pulldown menu. :-) + +This has been discussed in this list a few weeks ago (check the +archives), under the name of "modules", and rejected (for now) because +it seemed too much work and second priority. + +Some of your examples let me think you might want to implement a perl +"plugin", which is not a "module", much more like a local CGI (check +the archives for that too, or ask me, as I'm the one working on +plugins). I like _this_ idea : you could put together and maintain your +perl plugin without bothering patching/linking with dillo, because it +would be an _external_ program called by dillo. + +Anyway, embeding whatever in dillo will be Jorge's decision eventually: +wait for his answer before you begin something big ;-) + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 09-Sep-2000 a 22:04:07 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: <ikluft@th...> - 2000-09-09 12:42 + +>From: Eric GAUDET <egaudet@in...> +>"Embeding" perl can be done in two ways : you can merge perl in dillo, +>or link to perl dynamically. +>IMHO, the fist is not doable : perl is too much heavy and I think we +>want to keep dillo's light weight. + +I'm sure it's doable. But I'd have to implement it one API function +at a time. It can also be done so that it's optional and you could +leave it out at compile time. + +The main question is whether people want it. I clearly understand your +first impression was against the idea, and respect your opinion. If you're +still open for some more technical info, take a look at +http://www.cpan.org/doc/manual/html/pod/perlembed.html +http://www.cpan.org/doc/manual/html/pod/perlguts.html +That's how a Perl5 interpreter can be embedded into any C program, or +vice versa. A number of performance-critical Perl modules have been +reimplemented in C too. + +So the embedding can go both ways. The perl interpreter can be a shared +library. Or it can accept any module as a shared library. + +The counterpart to this idea on the server side is mod_perl for Apache. +Perl and Apache each think the other is a module. :-) The perl interpreter +runs inside the Apache process. I've used mod_perl on the job or on +my personal web servers almost as long as it's been out. + +The thought I had for Dillo was not to replace any existing C code in Perl. +But rather it should allow access to as many as possible of the APIs so +that some new features can be prototyped or implemented as an embedded perl +script calling Dillo API functions. It could also customize things like +menus by putting embedded perl scripts behind some of the callbacks that +handle them. (Imagine having live Slashdot headlines in a pulldown menu. :-) + +Also, depending on what access there might be to control the display +window, it could be possible to have some kinds of local forms and pages +controllable within the browser, and feed responses directly into +browser-side perl code instead of a remote web server. So it could be a +kind of scriptable local GUI in addition to a remote web browser. But it +would take a lot of incremental API support before enough internal APIs +could be covered to allow that. + +If the consensus is not to do this on Dillo, I can look around for another +browser to try this on. But I like Dillo so far and think it has good +potential. So I'm still holding out hope that some others will like +the idea. + +>The latter seems better, adding support for the SCRIPT tag (a script in +>an html page can actually be in any language, albeit javascript is the +>only one used). But that's a lot of work : adding event calls on each +>widget (links, images, words, almost all javascript's Document calls), +>then figure out an interface between perl and dillo. +>Though perl is quite an interesting language, my advice would be to +>support javascript first (there's 2 open sourced javascript engines +>around), because this will be immediatly usefull. Then you can add perl +>with the same scripting interface. +> +>A few days ago, I tried to evaluate how hard it would be to embed a +>tiny scripting language in dillo (10KB max), dillo-specific, so I can +>add dynamic behavior to my dillo-plugins-generated pages. I suspended +>this project for now, but if you dillo guys think that can be an +>interesting add-on, tell me. +> +>Ian, if you want to add SCRIPT tag to dillo, I can help. + +Well, the SCRIPT tag will be needed for future Javascript support anyway. +No doubt about that. + +But I'd be hesitant to allow it to use Perl. There is a Perl5 SAFE module +which is intended to act as a kind of sandbox. But it doesn't have wide +enough testing or trust to confidently use as downloadable code in a +browser. I can almost see the CERT advisories already... + +Besides, there's no support among current web sites or browsers for such +functionality right now. + +Though you would probably still have needed to use the perlembed interface +to link a perl interpreter in for the SCRIPT tag. So I don't think it +would have turned out any better on your concerns of a larger program size. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +RE: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET <egaudet@in...> - 2000-09-09 11:35 + +"Embeding" perl can be done in two ways : you can merge perl in dillo, +or link to perl dynamically. +IMHO, the fist is not doable : perl is too much heavy and I think we +want to keep dillo's light weight. +The latter seems better, adding support for the SCRIPT tag (a script in +an html page can actually be in any language, albeit javascript is the +only one used). But that's a lot of work : adding event calls on each +widget (links, images, words, almost all javascript's Document calls), +then figure out an interface between perl and dillo. +Though perl is quite an interesting language, my advice would be to +support javascript first (there's 2 open sourced javascript engines +around), because this will be immediatly usefull. Then you can add perl +with the same scripting interface. + +A few days ago, I tried to evaluate how hard it would be to embed a +tiny scripting language in dillo (10KB max), dillo-specific, so I can +add dynamic behavior to my dillo-plugins-generated pages. I suspended +this project for now, but if you dillo guys think that can be an +interesting add-on, tell me. + +Ian, if you want to add SCRIPT tag to dillo, I can help. + +--- En reponse de "[Dillo-dev]idea: embed Perl5 in Dillo" de Ian Kluft, +le 09-Sep-2000 : +> Part of my intent behind the just-submitted about-URL-hashing +> experiment was +> to dig around the sources to check what it might take to embed Perl5 +> in +> Dillo. I envision this as an optional feature, not a requirement, +> since +> it would fit Dillo's goal of extensibility very well but would also +> add +> to its size. Such compromises should be weighed by group +> discussion. +> (I haven't been on the list long enough to know the Dillo developer +> community well.) +> +> I've wanted for a long time to try to embed Perl in a web browser. +> The +> possibilities for local user interface control seem very powerful. +> But it +> would be better to work on such changes with a relatively new +> browser where +> the concept can grow with the project if it's accepted by other +> participants. +> I'll watch the following discussion for everyone's opinions... +> -- +> Ian Kluft KO6YQ PP-ASEL sbay.org +> coordinator +> ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San +> Jose, CA +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 09-Sep-2000 a 20:17:40 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]idea: embed Perl5 in Dillo + +From: <ikluft@th...> - 2000-09-09 11:03 + +Part of my intent behind the just-submitted about-URL-hashing experiment was +to dig around the sources to check what it might take to embed Perl5 in +Dillo. I envision this as an optional feature, not a requirement, since +it would fit Dillo's goal of extensibility very well but would also add +to its size. Such compromises should be weighed by group discussion. +(I haven't been on the list long enough to know the Dillo developer +community well.) + +I've wanted for a long time to try to embed Perl in a web browser. The +possibilities for local user interface control seem very powerful. But it +would be better to work on such changes with a relatively new browser where +the concept can grow with the project if it's accepted by other participants. +I'll watch the following discussion for everyone's opinions... +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +[Dillo-dev]patch: add hashing to "about:" handler + +From: <ikluft@th...> - 2000-09-09 11:00 + +Attachments: dillo-about-patch + +Hello. This is a simple patch while I'm learning my way around Dillo. +It changes the "about:" URL handler to use a hash table. It also adds an +a_About_add() function so other parts of Dillo can dynamically add their +own about-string/URL pairs on the fly. + +Though I submit to the editorial authority of the project coordinators, +I used the patch to show how this can more easily and scalably add +about-URLs for developer resources (like the Dillo, gtk and glib home pages) +or for project participants to add their own URLs (with two of mine shown +as an example.) Hopefully that will be viewed as a "perk" for contributing +source code and add to the popularity of the project. + +The patch is submitted to the project as an attachment to this message. +Or if you want to give me permission to commit it myself, my SourceForge +user name is ikluft. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +[Dillo-dev]seen this a couple of times + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 10:03 + +***** BUG found! (buffer needs allocation) ***** +Width = 1, Height = 1 + +I can not reproduce it. + + + +[Dillo-dev]word of caution and my status + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 09:35 + +I have initial working of the FONT tag functional. I can say <font +color="blue">Hi there</font> and get blue text. Will code the rest. + +The warning is that html_push_tag has to be called as early in a function as +possible. I was having problems with open_font() because I was calling +html_push_tag() at the end and thus pushing myself too far onto the stack it +seems. the close font tag would not reset the text color. simply moving the +function call fixed it. + + + +RE: [Dillo-dev]Great Product! + +From: Sean 'Shaleh' Perry <shaleh@vi...> - 2000-09-09 03:29 + +> +> I have one problem that I can't seem to get around. Our site uses a SSL +> (security socket layer) that the standard http_proxy setting doesn't allow +> for. I would like some help regarding this issue if possible! +> + +dillo could use ssl support -- feel free to help us code it. Or find someone +else to contribute the code to us. + +start with libssl. + + + +[Dillo-dev]Great Product! + +From: Bill Brooks <wdbrooksiii@ea...> - 2000-09-09 02:52 + +To all concerned! + +Dillo is a great tool! I am working on a project that involves kiosk web +browsing on thin clients with Linux RH61. We need to keep the operation +simple and lock the user down to a limited range of use. Dillo seems to be +the best browser that I have come across. It is simple (if browsers can be +termed simple), fast, and can be extensible with knowledge of C and gtk+ +programming. + +I have one problem that I can't seem to get around. Our site uses a SSL +(security socket layer) that the standard http_proxy setting doesn't allow +for. I would like some help regarding this issue if possible! + +Thanks again for making Dillo such a great product! +Bill Brooks +MIS Anaylst +Lowe's Companies, Inc. + + + +RE: [Dillo-dev]News + +From: Eric GAUDET <egaudet@in...> - 2000-09-08 19:00 + +06-Sep-2000, Jorge said : +> Personally, I gave a look to reload and double-click bugs, and +> noted that they're most the same problem. +... +> As a matter of fact, I'm currently working on it. +... + +Shouldn't you register in the bug tracking database accordingly ? + +Anyway, I had email sending problems lately, and I was wondering if +you've received my patches. + +I'm working on the Bookmarks plugin right now, and I've got lots of +ideas fo plugins things. I'm willing to make a Preferences plugin too, +as I saw the project is suspended and drake is most likely out of dillo. + +----------------------------------- +Eric GAUDET <egaudet@in...> +Le 08-Sep-2000 a 22:25:38 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]News + +From: Jorge Arellano Cid <jcid@ne...> - 2000-09-06 13:58 + +Hi! + +The list has been quiet for some time, and that's a good sign! +(we are diligently working on the code by now). + +Personally, I gave a look to reload and double-click bugs, and +noted that they're most the same problem. There're also a several +more problems related to this that are not recorded in the +bug-track. The main problem is the lack of implementation of a +consistent error control and abort systems between different +layers in dillo. This is a design concern. + +I also noted that it deserves a high priority on my list, +because new developers don't know the internals of the browser +and perceive dillo as crash-prone, and get discouraged, instead +of knowing that this is just a lack of implementation that's to +be overcomed soon. + +As a matter of fact, I'm currently working on it. + +I checked and fixed the cache clients scheme to handle not only +concurrent clients on the same connection, but also to provide a +handler for error control and aborting (This means that +concurrent download functionality is working). + +As a mentioned above, the problem is among middle layers. For +instance: do you remember Sebastian's post about image +backgrounds? Yes, current scheme handles image transfers directly +to rendering image widgets. I'm also working on that. + +Note that this is not a patching task, but a design one, that +takes time and key decisions have to be made, so I'll take some +time in trying to get it right. + + +Jorge.- + + +PS: I wander if some among the new memebers are experienced GTK+ +developers... + |