[Dillo-dev]Dillo weekly news From: Allan Clark - 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 - 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 - 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 - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]Not again From: Sam Dennis - 2000-09-24 01:24 Getting tired of repeating. Check archives for messages. Re: [Dillo-dev]Missing mails again From: Sam Dennis - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]Missing mails again From: Sam Dennis - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." Re: [Dillo-dev]Repeated patch From: Sam Dennis - 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 "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 - 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 - 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 Le 23-Sep-2000 a 13:56:14 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Repeated patch From: Jorge Arellano Cid - 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 - 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 - 2000-09-22 19:39 Sebastian, > 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). 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. 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. Allan Re: [Dillo-dev]new here From: Sebastian Geerken - 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
'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 - 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 Le 22-Sep-2000 a 12:39:40 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]email problems From: Jorge Arellano Cid - 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 - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev](no subject) From: Allan Clark - 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 - 2000-09-19 13:11 RE: [Dillo-dev]horizontal rules From: Eric GAUDET - 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 Le 19-Sep-2000 a 21:54:46 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]horizontal rules From: Jörgen Viksell - 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 - 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 - 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 - 2000-09-18 20:30 Just testing, haven't received any mails back from this thing, oddly. -- Sam Dennis "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]Actual fix From: Sam Dennis - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]new here From: Allan Clark - 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 - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." Re: [Dillo-dev]cache patch From: Sean 'Shaleh' Perry - 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 - 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 - 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 "The strstr() function finds the first occurrence of the substring needle in the string haystack." [Dillo-dev]Sizes in html From: Sebastian Geerken - 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
'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 - 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 Le 13-Sep-2000 a 15:26:12 "Le verbe inexister ... inexiste !" ----------------------------------- RE: [Dillo-dev]Plugins design From: Sean 'Shaleh' Perry - 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 - 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 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'. > > My text > > 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 - 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 parameters, and waits for an http-like answer, most of the time being Content-Type=text/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 Le 12-Sep-2000 a 10:38:04 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Misc. From: Eric GAUDET - 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 Le 12-Sep-2000 a 10:35:42 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]Misc. From: Luca Rota - 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: - 2000-09-11 01:19 >From: "Jorge Arellano Cid" >> 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 - 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'. My text 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 - 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: > > > > 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 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 - 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 - 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 - 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 - 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 - 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 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 - 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 - 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 . 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 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 - 2000-09-10 06:00 I am working on . 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: 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 - 2000-09-10 05:45 So, was reading the recent freshmeat editorial when i noticed that freshmeat's html creation software likes to leave '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 "

", i.e. back to back tags. freshmeat was doing "". 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 - 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 - 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: - 2000-09-10 02:27 >From: Eric GAUDET >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 - 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 Le 10-Sep-2000 a 11:12:05 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]idea: embed Perl5 in Dillo From: - 2000-09-10 02:14 >From: "Sean 'Shaleh' Perry" >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 - 2000-09-10 02:11 --- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian Kluft, le 09-Sep-2000 : > 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. > 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:///", 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 Le 10-Sep-2000 a 10:45:10 "Le verbe inexister ... inexiste !" ----------------------------------- RE: [Dillo-dev]on the subject of SCRIPT tags From: Eric GAUDET - 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 Le 10-Sep-2000 a 10:17:46 "Le verbe inexister ... inexiste !" ----------------------------------- RE: [Dillo-dev]News From: Sean 'Shaleh' Perry - 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 - 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 - 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: - 2000-09-09 18:49 >From: Eric GAUDET >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 - 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 Le 09-Sep-2000 a 22:04:07 "Le verbe inexister ... inexiste !" ----------------------------------- Re: [Dillo-dev]idea: embed Perl5 in Dillo From: - 2000-09-09 12:42 >From: Eric GAUDET >"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 - 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 Le 09-Sep-2000 a 20:17:40 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]idea: embed Perl5 in Dillo From: - 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: - 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 - 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 - 2000-09-09 09:35 I have initial working of the FONT tag functional. I can say Hi there 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 - 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 - 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 - 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 Le 08-Sep-2000 a 22:25:38 "Le verbe inexister ... inexiste !" ----------------------------------- [Dillo-dev]News From: Jorge Arellano Cid - 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...