From jcid@softhome.net Sat Aug 2 23:31:54 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Sat, 2 Aug 2003 18:31:54 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3-rc2 Message-ID: Hi there! Today I was decided to upload 0.8.0-pre but found some problems with one plugin. At the same time Sebastian sent me a fix for the bug that delays 0.7.3 (very simple), so most probably our current CVS holds the final 0.7.3! Please give it a hard test. If everything goes fine, it'll be released by Tuesday or Wednesday. With regard to 0.8.0-pre, please expect it to be in CVS at announce time. I know I have delayed it a lot, but it comes with much more than what was anticipated (and I believe you'd prefer it to be working right! :). Cheers Jorge.- PS: Phil, Kelson: Please be prepared to upgrade your packages before 0.7.3 is announced. That is, if testing don't say otherwise! I'll let you know one or two days before the announcement. From s.geerken@ping.de Sun Aug 3 09:24:00 2003 From: s.geerken@ping.de (Sebastian Geerken) Date: Sun, 3 Aug 2003 10:24:00 +0200 Subject: [Dillo-dev] dillo-0.7.3-rc2 In-Reply-To: References: Message-ID: <20030803082400.GA413@sg.local> On Sat, Aug 02, Jorge Arellano Cid wrote: > Today I was decided to upload 0.8.0-pre but found some problems > with one plugin. At the same time Sebastian sent me a fix for the > bug that delays 0.7.3 (very simple), so most probably our current > CVS holds the final 0.7.3! Sorry, this patch was incomplete. I tried to extract the actual code changes, without some new debugging messages, but ommitted some things. The current CVS (which has now also the new debugging messages) contains now the complete changes. > Please give it a hard test. If everything goes fine, it'll be > released by Tuesday or Wednesday. > > With regard to 0.8.0-pre, please expect it to be in CVS at > announce time. I know I have delayed it a lot, but it comes with > much more than what was anticipated (and I believe you'd prefer > it to be working right! :). Jorge, I've not yet tagged the code, please do so when uploading the 0.8.0 code. Sebastian From frank@unternet.org Mon Aug 4 23:26:32 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 00:26:32 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) Message-ID: <20030804222632.GA10969@unternet.org> Hi'all, The next version (7) of my tab patch is ready (see bottom of this message for download instructions). Most notable change is that it now also contains an experimental, not-really-ready-but-quite-entertaining implementation of frame/iframe support. The not-quite-ready part has to do with the sizing of frames (more on this later). Frame support, like tab support, is optional. It is enabled by default, but you can disable it using (frames) --disable-frames and (tabs) --disable-tabs during configure. Other new features: - title of window/tab set to url if file has no title (this can be disabled with the preference 'document_title_use_url=NO', default enabled) - navigation buttons (back, forward, stop, reload) in popup menu (can be disabled with preference 'show_popup_navigation=NO', default enabled) - duplicate page (open current page in new window, keyboard ALT-N) and, if tab support is enabled, duplicate tab (open current page in new tab, keyboard ALT-T) options in popup menu. Of course, the patch also fixes some bugs (and possibly introduces new ones). I had to back out my stopgap fix for the Gdk-CRITICAL warnings, which caused more problems than it solved. Instead, I patched dw_widget. The warnings were generated from within Dw_widget_mouse_event(dw_widget:729) when it tried to set a cursor on a non-existing window. I added a NULL-check, and made the widget generate a debug message (set DEBUG_LEVEL to 10 to see the warning). More on frame/iframe support ============================ What works: - loading (nested) framesets, displaying frames at their appropriate location (but not at their appropriate size... yet...) - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame (which is what you'd get with an unpatched version of Dillo). What does not work yet: - obeying frameset proportions. Currently all frames are allocated a default size. I have the appropriate sizes for the frames at hand, but GTK does not provide a means to size multiple widgets in a container relative to the size of that container. The 'gtk_widget_set_usize()' (or GTK2's gtk_widget_set_size_request() replacement function) are not suitable for this purpose, although they can be used to set a minimum or absolute size for rows/columns which have been specified that way (frameset rows=100,100,* is easy, frameset rows=100,20%,3*,* is not...). - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... These problems can be solved by creating a new widget for the frameset, but that might be overkill. DwTable provides some of the needed features, but is is overcomplicated for the task at hand (no colspan or rowspan in framesets, etc) and lacks direct control over the height of table cells. If anyone has any bright ideas on how to assign widgets sizes which are relative to their container, speak up... Or, if anyone has already created (or at least thought about creating) a 'frameset' widget, please let me know. No need to re-invent the wheel... If I get no response, I will probably create a new widget based on GtkTable, with some built-in sizing magic. I chose GtkTable over DwTable because the former seems to be more suitable for the purpose than the latter. I might be wrong, please tell me... Tabs, frames and browser bloat ============================== For those who wonder if all this will add much to the size of Dillo, rest assured that it does not. I did some size comparisons between CVS Dillo (unpatched) and several configurations with the patch applied. The main results are (compiled with gcc 3.2.2, binutils 2.13.90.0.18 for x86, optimisation -Os, stripped binary) CVS unpatched: 285024 bytes Patched, no tabs, no frames: 289884 bytes Patched, no tabs, with frames: 294076 bytes Patched, with tabs, no frames: 297596 bytes Patched, with tabs and frames: 301692 bytes So, some 15 Kb for tabs and frames together, bearing in mind the patch has not been optimised for size yet (premature optimisation is... well, a bad idea). Not too bad, I think. Download instructions ===================== The patch is made against 20030804 CVS. It can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically, it can be found here: http://www.geocities.com/ikbenfrank/dillo-20030804-tabs.patch.gz size: 53262 bytes (gzipped, as downloaded) 220519 bytes (uncompressed) md5sum: 5c218077382d6c6e7300f1dd7d41e024 (gzipped, as downloaded) f6242c4f01f0eed60645db91a8882b2c (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Mon Aug 4 23:40:19 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 00:40:19 +0200 Subject: [Dillo-dev] [PATCH] version 7 of tab patch is ready Message-ID: <20030804224019.GB10969@unternet.org> Oops... I seem to have messed up the subject of my last message. Anyway, as stated... the next version of my tab patch is ready, get it at http://www.geocities.com/ikbenfrank Read my last message for more info... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From melvin.hadasht@free.fr Tue Aug 5 00:36:50 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Tue, 5 Aug 2003 01:36:50 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <20030804222632.GA10969@unternet.org> References: <20030804222632.GA10969@unternet.org> Message-ID: Hi Frank, You wrote: > If anyone has any > bright ideas on how to assign widgets sizes which are relative to their > container, speak up... I don't know Dillo internal widgets, but Gtk provides the GtkFixed widget where you can specify where the widgets are to be positioned. The API reference says that in that case the size is also fixed (but it does not say how). Check also the Gtk2 reference for this widget, as it looks more complete there. HTH -- Melvin Hadasht From Andreas.Schweitzer@hs.uni-hamburg.de Tue Aug 5 08:41:04 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Tue, 5 Aug 2003 09:41:04 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <20030804222632.GA10969@unternet.org> References: <20030804222632.GA10969@unternet.org> Message-ID: <20030805074104.GA43612@hs.uni-hamburg.de> Hi, > <...> If anyone has any > bright ideas on how to assign widgets sizes which are relative to their > container, speak up... Or, if anyone has already created (or at least thought > about creating) a 'frameset' widget, please let me know. No need to re-invent > the wheel... About a week ago I decided to look into Frames with your tabs patch put was overwhelmed by my non-knowledge of GTK. Luckily I saw your note "Now working on frames" in one of your e-mails and I figured at the rate Frank produces code I will never have anything ready ;-) And the description sounds great ! Great work ! I'll try it out now. Anyways, getting to the point. What about tracking the sizes of the widgets ? E.g. putting the sizes in DilloDoc And also maybe putting the parent widget in DilloDoc ? That way one could "cascade" down the sizes. I haven't looked at the new patch though - just some ideas. The problem might be that all these sizes would only be calculated sizes and that GTK may calculate the sizes differently and hence may be getting different rounding errors. A lot of resizing may be getting the actual sizes and the calculated sizes heavily out of sync. One would have to see. > The patch is made against 20030804 CVS. It can be downloaded from the usual > (ad-happy, but...) Geocities site: > > http://www.geocities.com/ikbenfrank/ > > More specifically, it can be found here: > > http://www.geocities.com/ikbenfrank/dillo-20030804-tabs.patch.gz > size: 53262 bytes (gzipped, as downloaded) > 220519 bytes (uncompressed) > md5sum: 5c218077382d6c6e7300f1dd7d41e024 (gzipped, as downloaded) > f6242c4f01f0eed60645db91a8882b2c (uncompressed) And again at http://www.hs.uni-hamburg.de/~stcd102/dillo-20030804-tabs.patch.gz Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From Jens.Arm@gmx.de Tue Aug 5 09:04:35 2003 From: Jens.Arm@gmx.de (Jens Arm) Date: Tue, 5 Aug 2003 10:04:35 +0200 Subject: [Dillo-dev] [PATCH] version 7 of tab patch is ready In-Reply-To: <20030804224019.GB10969@unternet.org> References: <20030804224019.GB10969@unternet.org> Message-ID: <20030805100435.26d6c9f4.Jens.Arm@gmx.de> Hi Great work the tab and frame support! If I try to open the reiserfs-Homepage (www.namesys.com) only the menu-frame is shown. Here is the output of dillo: [tux@tux tux]$ dillo Setting locale to C... dillo_dns_init: Here we go! Enabling cookies as from cookiesrc... Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.namesys.com< Dns_server [0]: www.namesys.com is 0x81180b0 Connecting to 212.16.7.65 HTML warning: the TITLE element must be inside the HEAD section Nav_open_url: Url=>http://www.namesys.com/menu.html< Connecting to 212.16.7.65 HTML warning: Invalid HTML syntax: too many tags in This I get at other sites, too. Jens From frank@unternet.org Tue Aug 5 09:14:47 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 10:14:47 +0200 Subject: [Dillo-dev] [PATCH] version 7 of tab patch is ready In-Reply-To: <20030805100435.26d6c9f4.Jens.Arm@gmx.de> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> Message-ID: <20030805081447.GA6554@unternet.org> On Tue, Aug 05, 2003 at 10:04:35AM +0200, Jens Arm wrote: > Hi > > Great work the tab and frame support! Thanks... > If I try to open the reiserfs-Homepage (www.namesys.com) > only the menu-frame is shown. > Here is the output of dillo: > > [tux@tux tux]$ dillo > Setting locale to C... > dillo_dns_init: Here we go! > Enabling cookies as from cookiesrc... > Nav_open_url: Url=>about:splash< > Nav_open_url: Url=>http://www.namesys.com< > Dns_server [0]: www.namesys.com is 0x81180b0 > Connecting to 212.16.7.65 > HTML warning: the TITLE element must be inside the HEAD section > Nav_open_url: Url=>http://www.namesys.com/menu.html< > Connecting to 212.16.7.65 > HTML warning: Invalid HTML syntax: too many tags in > > > This I get at other sites, too. It works here... Did you use the latest CVS version of Dillo, did the patch aplpy without problems, do you use a filtering proxy which does weird things to the HTML? Namesys' page comes up in two frames. Size of frames is wrong (but that was to be expected), content is OK. This is what I get with 'View Page Source' on Namesys' page: NAMESYS So yes, that IS invalid HTML (TITLE tag outside of HEAD), but Dillo renders it OK here. It tells me about the errors in the page: Nav_open_url: Url=>http://www.namesys.com< Connecting to 212.16.7.65 HTML warning: the TITLE element must be inside the HEAD section Nav_open_url: Url=>http://www.namesys.com/menu.html< Nav_open_url: Url=>http://www.namesys.com/content_table.html< Are there any others out there who have problems like this? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Tue Aug 5 09:23:12 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 10:23:12 +0200 Subject: [Dillo-dev] [PATCH] version 7 of tab patch is ready In-Reply-To: <20030805100435.26d6c9f4.Jens.Arm@gmx.de> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> Message-ID: <20030805082312.GB6554@unternet.org> On Tue, Aug 05, 2003 at 10:04:35AM +0200, Jens Arm wrote: > Hi > > Great work the tab and frame support! > > If I try to open the reiserfs-Homepage (www.namesys.com) Just an addition to my previous reply... Namesys' page does show up as expected (two frames), but navigation does not work as it should yet. The current version of the frames patch ignores the tag in the left frame, so all content ends up in the left frame instead. This will be fixed in the next version of the patch. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Tue Aug 5 10:39:59 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 11:39:59 +0200 Subject: [Dillo-dev] [PATCH] version 7 of tab patch is ready In-Reply-To: <20030805082312.GB6554@unternet.org> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> <20030805082312.GB6554@unternet.org> Message-ID: <20030805093958.GE6554@unternet.org> On Tue, Aug 05, 2003 at 10:23:12AM +0200, Frank de Lange wrote: > On Tue, Aug 05, 2003 at 10:04:35AM +0200, Jens Arm wrote: > > Hi > > > > Great work the tab and frame support! > > > > If I try to open the reiserfs-Homepage (www.namesys.com) > > Just an addition to my previous reply... > > Namesys' page does show up as expected (two frames), but navigation does not > work as it should yet. The current version of the frames patch ignores the > tag in the left frame, so all content ends up in the left > frame instead. This will be fixed in the next version of the patch. Yet another addition... Namesys' page uses a tag without a href: (http://www.namesys.com/menu.html: ... ... This is in violation of the HTML specs (href is a required parameter for ). What should Dillo do in this case? Currently it only checks for the target parameter after it has found a href in the tag (literal interpretation the definition of ), but this breaks pages like Namesys' which violate the standard. I can: a) unconditionally change the code so these pages work b) add a compile option (--pedantic-mode or --quirks-mode or whatever) to disable/enable these changes c) leave it the way it is For users a and b are the best choices, for developers c is the best. It is probably infeasible to trap all the crufty HTML out there, Namesys' site alone is good for I don't know how many problems... I personally prefer b, which gives everyone a choice. Choice is good. Any thoughts? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Tue Aug 5 13:25:10 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 14:25:10 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: References: <20030804222632.GA10969@unternet.org> Message-ID: <20030805122510.GB11350@unternet.org> On Tue, Aug 05, 2003 at 02:44:08PM +0300, madis wrote: > > On Tue, 5 Aug 2003, Frank de Lange wrote: > > > http://www.geocities.com/ikbenfrank/dillo-20030804-tabs.patch.gz > > dillo with this patch shows only noframes part on some framed sites: > > http://www.hot.ee/klubipegasus/ > http://www.lamlaw.com/ That is caused by the extra tag these sites add (lamlaw has a complete body section - something a frame document should not have, http://www.hot.ee/klubipegasus/ has an extra body tag in the noframes section.) The specs say something like this: Use the tag in lieu of a tag in the frame document. You may not include any other content except valid and content in a frame document. Combining frames with a conventional document containing may result in unpredictable browser behavior. So, again (this is to the list), should Dillo follow the specs - and thus produce unwanted results - or try to work around the cruft some sites serve? Fixing this would be relatively easy, and the fix can be optional (--enable-pedantic or --enable-quirks or whatever...) By the way, some sites check the browser string to decide what type of content to send, these may also send non-frames content. Same goes for sites which use Javascript to test for browser versions. So even if Dillo has full frame support one day, it can still happen that a site does not serve it (functional) frame documents... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Tue Aug 5 16:01:04 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 5 Aug 2003 17:01:04 +0200 Subject: [Dillo-dev] Frame support in tab patch, found a bug... Message-ID: <20030805150104.GA13738@unternet.org> Hi'all, I just noted an interesting typo in the frame support code, which makes some framed sites look really weird. I'll fix in in the next patch, but (as it is a very simple thing to change) you might want to fix your copy asap. in html.c, in the function Html_tag_open_frameset():1971 change: gint col = *frame_number / html->stack[html->stack_top].frameset_cols; gint row = *frame_number % html->stack[html->stack_top].frameset_cols; to: gint col = *frame_number % html->stack[html->stack_top].frameset_cols; gint row = *frame_number / html->stack[html->stack_top].frameset_cols; So, in essence, switch the '/' and '%' operators. It will still make a mess of the layout as it does not obey frame sizing, but at least it is a geometrically correct mess... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From kelson@pobox.com Tue Aug 5 18:00:38 2003 From: kelson@pobox.com (Kelson Vibber) Date: Tue, 05 Aug 2003 10:00:38 -0700 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <20030805122510.GB11350@unternet.org> References: <20030804222632.GA10969@unternet.org> Message-ID: <5.2.1.1.0.20030805093105.01bee370@mail.speed.net> At 05:25 AM 8/5/2003, Frank de Lange wrote: >The specs say something like this: > > Use the tag in lieu of a tag in the frame document. > You may > not include any other content except valid and > content in a > frame document. Combining frames with a conventional document containing > may result in unpredictable browser behavior. > >So, again (this is to the list), should Dillo follow the specs - and thus >produce unwanted results - or try to work around the cruft some sites serve? Actually, my understanding is that, in frameset documents, it's recommended or at least allowed to put the tag inside the tag. I can name at least one well-designed HTML resource that agrees ( http://www.blooberry.com/indexdot/html/tagpages/n/noframes.htm ), and I believe it's stated in the following line from the HTML spec: <!ENTITY % noframes.content "(BODY) -(NOFRAMES)"> http://www.w3.org/TR/html4/present/frames.html#h-16.4.1 And http://validator.w3.org/ doesn't have a problem with there being a <body> tag inside (although it has a lot of other complaints about http://www.hot.ee/klubipegasus/ ) All that aside, I would argue that the <noframes><body></body> structure is a better way to produce a backwards-compatible document than simply . After all, a strict HTML 2 browser (not that I think there are many) is going to look at the latter and see no BODY element and therefore nothing to display, but it will look at the former and just see some extra code around a valid body. Kelson Vibber www.hyperborea.org From kelson@pobox.com Tue Aug 5 18:21:35 2003 From: kelson@pobox.com (Kelson Vibber) Date: Tue, 05 Aug 2003 10:21:35 -0700 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <20030805122510.GB11350@unternet.org> References: <20030804222632.GA10969@unternet.org> Message-ID: <5.2.1.1.0.20030805101120.01d3d948@mail.speed.net> At 05:25 AM 8/5/2003, Frank de Lange wrote: >That is caused by the extra tag these sites add (lamlaw has a complete >body section - something a frame document should not have, I forgot to address this case in my earlier reply. IMO, it would be better to display whichever came first, the frameset or the body. The behavior is undefined, so it could be arguably "correct" to do any of the following: display only the frameset, display only the body, display only a note saying "Sorry, this page is malformed," or bring up a dialog box with the output from fortune (I just wanted to come up with something "unpredictable!") Of the various interpretations, I think the most *useful* would be either to prefer the framest (which is what most authors intended) or to prefer the element that appears first (which will usually be the frameset). Unfortunately frames are complicated by the fact that Netscape and Microsoft had slightly differing implementations until HTML 4 came out and standardized them. As a result, a lot of pages are written with the assumption that is not necessary, or that it should be outside the <frameset> structure. Kelson Vibber www.hyperborea.org From jcid@softhome.net Tue Aug 5 18:58:31 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Tue, 5 Aug 2003 13:58:31 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 Message-ID: <Pine.LNX.4.53.0308051344070.675@infinity.cl> Hi there! Yesterday I posted an email about 0.7.3 but forgot to mention the most important part: the URL! :-) There's a tarball of 0.7.3 at: http://www.dillo.org/download/dillo-0.7.3.tar.bz2 The plan was to test it yesterday (it already passed my tests and Seb's too) and to announce it on Wednesday while letting our packagers some time to update them for announce time. So there it is, and will be announced on Thursday. Please get it and give it some hard testing. Kelson, Phil, Oliver: please make update your packages with it. Sorry for the mistake. Cheers Jorge.- Frank: after I upload 0.8.0-pre I'll have some time to look in your work. Now that 0.7.3 release is almost done, I guess Sebastian will have some time too (we were working on a plan for CSS, and then Sebastian had to make a detailed review of the incremental resizing mechanism because of some discovered bugs. I was working on 0.8.0-pre (plugins) and on the release). All this explanation is to state that it is not lack of interest, but lack of manpower. You'd be amazed to know all of the things I'm working in parallel. PS: the above note applies to all of you waiting for an answer from my side... From wdtrenker@yahoo.ca Tue Aug 5 14:12:38 2003 From: wdtrenker@yahoo.ca (William Trenker) Date: Tue, 05 Aug 2003 13:12:38 +0000 Subject: [Dillo-dev] Segfaults with png files Message-ID: <oprtfobcg6mmesbb@mail.silk.net> I built Dillo 0.7.2 from source and it works great except when there is a png file on the web page I'm browsing. In that case, Dillo segfaults with this message on the command line: Png_error_handling: Application was compiled with png.h from libpng-1.0.12 Segmentation fault What have I done wrong? Can you give me any suggestion how to fix this? Thanks, Bill From jcid@softhome.net Tue Aug 5 21:18:02 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Tue, 5 Aug 2003 16:18:02 -0400 (CLT) Subject: [Dillo-dev] Segfaults with png files In-Reply-To: <oprtfobcg6mmesbb@mail.silk.net> References: <oprtfobcg6mmesbb@mail.silk.net> Message-ID: <Pine.LNX.4.53.0308051615000.675@infinity.cl> On Tue, 5 Aug 2003, William Trenker wrote: > I built Dillo 0.7.2 from source and it works great except when there is a > png file on the web page I'm browsing. In that case, Dillo segfaults with > this message on the command line: > Png_error_handling: Application was compiled with png.h from libpng-1.0.12 > Segmentation fault > > What have I done wrong? Can you give me any suggestion how to fix this? Most probably you have old png.h headers somewhere. Check: 'libpng-config --version' or 'libpng12-config --version' and check 'libpng-config --cflags' (also png.h and libpng/png.h should be the same file) Cheers Jorge.- From madis@ats.cyber.ee Tue Aug 5 21:25:07 2003 From: madis@ats.cyber.ee (Madis Janson) Date: Tue, 5 Aug 2003 23:25:07 +0300 (EEST) Subject: [Dillo-dev] Segfaults with png files In-Reply-To: <oprtfobcg6mmesbb@mail.silk.net> References: <oprtfobcg6mmesbb@mail.silk.net> Message-ID: <Pine.LNX.4.56.0308052317470.11395@kiku.itsise> On Tue, 5 Aug 2003, William Trenker wrote: > I built Dillo 0.7.2 from source and it works great except when there is a > png file on the web page I'm browsing. In that case, Dillo segfaults with > this message on the command line: > Png_error_handling: Application was compiled with png.h from libpng-1.0.12 > Segmentation fault > > What have I done wrong? Can you give me any suggestion how to fix this? > You have multiple versions of libpng installed. Compiler used libpng-1.0.12's header files and dynamic linker found a .so file belonging to some other version (ldd `which dillo` should show it). From kelson@pobox.com Tue Aug 5 22:04:52 2003 From: kelson@pobox.com (Kelson Vibber) Date: Tue, 05 Aug 2003 14:04:52 -0700 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <Pine.LNX.4.53.0308051344070.675@infinity.cl> Message-ID: <5.2.1.1.0.20030805140005.01d3ab10@mail.speed.net> At 10:58 AM 8/5/2003, Jorge Arellano Cid wrote: > Kelson, Phil, Oliver: please make update your packages with it. I got a couple built on my lunch hour. I've already got plans for tonight, but once I get home I'll get as many done as I can. I've been starting to use User-Mode Linux ( http://user-mode-linux.sourceforge.net/ ), which basically lets me run a second copy of Linux in a virtual machine. This will save me a lot of rebooting, and eventually I'll be able to build packages for more than one distribution simultaneously! Kelson Vibber www.hyperborea.org From frank@unternet.org Wed Aug 6 06:46:19 2003 From: frank@unternet.org (Frank de Lange) Date: Wed, 6 Aug 2003 07:46:19 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <5.2.1.1.0.20030805101120.01d3d948@mail.speed.net> References: <Pine.LNX.4.53.0308051439340.3211@alien> <20030804222632.GA10969@unternet.org> <Pine.LNX.4.53.0308051439340.3211@alien> <5.2.1.1.0.20030805101120.01d3d948@mail.speed.net> Message-ID: <20030806054619.GA21653@unternet.org> On Tue, Aug 05, 2003 at 10:21:35AM -0700, Kelson Vibber wrote: > At 05:25 AM 8/5/2003, Frank de Lange wrote: > >That is caused by the extra <body> tag these sites add (lamlaw has a > >complete > >body section - something a frame document should not have, > > Of the various interpretations, I think the most *useful* would be either > to prefer the framest (which is what most authors intended) or to prefer > the element that appears first (which will usually be the frameset). In my current version, the default behaviour is tu use the frameset if it is found. I have added a compile option '--enable-strict' which turns off checks for cruddy HTML (and thus reduces code size a bit at the expense of ability to display non-standard documents). I might have misinterpreted the specs, so I will remove the '#ifndef STRICT' from the frameset code. /me goes off and finds a version of current HTML specs, mine are outdated... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From kelson@pobox.com Wed Aug 6 08:03:13 2003 From: kelson@pobox.com (Kelson Vibber) Date: Wed, 6 Aug 2003 00:03:13 -0700 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <Pine.LNX.4.53.0308051344070.675@infinity.cl> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> Message-ID: <200308060003.13382.kelson@pobox.com> On Tuesday 05 August 2003 10:58 am, Jorge Arellano Cid wrote: > Kelson, Phil, Oliver: please make update your packages with it. OK, packages are ready for: Red Hat 6.2, 7.3, 8, 9 Mandrake 8.2, 9.1, and 9.1 PPC SuSE 8.2 I'm moving the RPM download page to http://www.hyperborea.org/software/dillo/ (just replace the .html with a /). There's a server redirect in place, but it wouldn't hurt to update the link. I've updated a separate copy of the page, so all I have to do is switch it in when the release is ready. If anyone wants to check out the rpms early, go to http://www.hyperborea.org/software/dillo/index-new.shtml -- Kelson Vibber www.hyperborea.org From frank@unternet.org Wed Aug 6 10:15:18 2003 From: frank@unternet.org (Frank de Lange) Date: Wed, 6 Aug 2003 11:15:18 +0200 Subject: [Dillo-dev] Frame support, suggestion: compile-option --xhtml-dtd In-Reply-To: <20030805093958.GE6554@unternet.org> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> <20030805082312.GB6554@unternet.org> <20030805093958.GE6554@unternet.org> Message-ID: <20030806091518.GC21653@unternet.org> On Tue, Aug 05, 2003 at 11:39:59AM +0200, Frank de Lange wrote: > This is in violation of the HTML specs (href is a required parameter for > <base>). What should Dillo do in this case? Currently it only checks for the > target parameter after it has found a href in the tag (literal interpretation > the definition of <base>), but this breaks pages like Namesys' which violate > the standard. I can: > > a) unconditionally change the code so these pages work > b) add a compile option (--pedantic-mode or --quirks-mode or whatever) to > disable/enable these changes > c) leave it the way it is > > I personally prefer b, which gives everyone a choice. Choice is good. Having just worked my way through the XHTML-1.0 specifications (previous work was based on 3.2 and 4.01), I suggest the following: The next version of the patch will include a compile option '--xhtml-dtd' which can be set to 'strict', 'transitional' and 'frameset'. The 'strict' setting follows XHTML-1.0-Strict (and thus disables frames and frame-related code). With 'transitional' iframe is supported, frameset is not (leaving out the frameset-related code from the binary). Use 'frameset' for full frame support. Default setting will be 'frameset' to get the behaviour most people expect. Any suggestions/comments to my suggestion? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From manigandanv@myw.ltindia.com Wed Aug 6 12:16:39 2003 From: manigandanv@myw.ltindia.com (Manigandan) Date: Wed, 6 Aug 2003 16:46:39 +0530 Subject: [Dillo-dev] Porting Dillo to uClinux target Message-ID: <001b01c35c0c$3541bf10$1e06a8c0@linx> This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C35C3A.4ED89060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to port dillo to uClinux based coldfire target(5272). Has = some one already did this ?What should be my starting point ? Is there = some good document for porting dillo to new targets ? Thanks, Mani ------=_NextPart_000_0018_01C35C3A.4ED89060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.3700.6699" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>&nbsp; I am trying to port dillo to = uClinux based=20 coldfire target(5272). Has some one already did this ?</FONT><FONT = face=3DArial=20 size=3D2>What should be my starting point ? Is there some good document = for=20 porting dillo to new targets ?</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Mani</FONT></DIV></BODY></HTML> ------=_NextPart_000_0018_01C35C3A.4ED89060-- From paka@MyRealBox.com Wed Aug 6 13:06:10 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Wed, 6 Aug 2003 07:06:10 -0500 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <200308060003.13382.kelson@pobox.com> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> Message-ID: <20030806120610.GJ25982@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-06-03 02:07]: > On Tuesday 05 August 2003 10:58 am, Jorge Arellano Cid wrote: > > Kelson, Phil, Oliver: please make update your packages with it. > > OK, packages are ready for: > Red Hat 6.2, 7.3, 8, 9 > Mandrake 8.2, 9.1, and 9.1 PPC > SuSE 8.2 > > I'm moving the RPM download page to http://www.hyperborea.org/software/dillo/ > (just replace the .html with a /). There's a server redirect in place, but > it wouldn't hurt to update the link. > > I've updated a separate copy of the page, so all I have to do is switch it in > when the release is ready. If anyone wants to check out the rpms early, go > to http://www.hyperborea.org/software/dillo/index-new.shtml <frown> and _no_ rpm for SuSE 8.1 (which is still widely utilized)? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From madis@ats.cyber.ee Wed Aug 6 14:46:55 2003 From: madis@ats.cyber.ee (Madis Janson) Date: Wed, 6 Aug 2003 16:46:55 +0300 (EEST) Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <Pine.LNX.4.53.0308051344070.675@infinity.cl> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> Message-ID: <Pine.LNX.4.56.0308061627020.17402@kiku.itsise> On Tue, 5 Aug 2003, Jorge Arellano Cid wrote: > There's a tarball of 0.7.3 at: > > http://www.dillo.org/download/dillo-0.7.3.tar.bz2 > Some updated patches are avaible here: http://zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html The HTTPS stuff will go on top of dpi, when the dpi has enough functionality for it (i'm hoping a bit for the new dpid stuff). Possibly i'll try to hack something together in next month. PS. I'll create separate cache-control patch for current cvs, when there is a interest about merging it with the CVS (not before, because it would be to much trouble to mantain it separately). From kelson@pobox.com Wed Aug 6 17:26:40 2003 From: kelson@pobox.com (Kelson Vibber) Date: Wed, 06 Aug 2003 09:26:40 -0700 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <20030806120610.GJ25982@wahoo.no-ip.org> References: <200308060003.13382.kelson@pobox.com> <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> Message-ID: <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> At 05:06 AM 8/6/2003, Patrick Shanahan wrote: ><frown> and _no_ rpm for SuSE 8.1 (which is still widely utilized)? Does the SuSE 8.2 RPM not work on 8.1? Kelson Vibber kelson@pobox.com http://www.hyperborea.org/ Creative Writing - Photography - The Flash From o.h.a@gmx.net Wed Aug 6 17:40:49 2003 From: o.h.a@gmx.net (Oliver Haertel) Date: Wed, 6 Aug 2003 18:40:49 +0200 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <Pine.LNX.4.53.0308051344070.675@infinity.cl> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> Message-ID: <20030806184049.254bb014.o.h.a@gmx.net> Slackpacks here: http://www.linuxpackages.net/details.php?name=dillo On Tue, 5 Aug 2003 13:58:31 -0400 (CLT) Jorge Arellano Cid wrote: > > Hi there! > > Yesterday I posted an email about 0.7.3 but forgot to mention > the most important part: the URL! :-) > > There's a tarball of 0.7.3 at: > > http://www.dillo.org/download/dillo-0.7.3.tar.bz2 > > > The plan was to test it yesterday (it already passed my tests > and Seb's too) and to announce it on Wednesday while letting our > packagers some time to update them for announce time. > > So there it is, and will be announced on Thursday. > > Please get it and give it some hard testing. > > Kelson, Phil, Oliver: please make update your packages with it. > > Sorry for the mistake. > > Cheers > Jorge.- > > Frank: after I upload 0.8.0-pre I'll have some time to look in > your work. Now that 0.7.3 release is almost done, I guess > Sebastian will have some time too (we were working on a plan for > CSS, and then Sebastian had to make a detailed review of the > incremental resizing mechanism because of some discovered bugs. I > was working on 0.8.0-pre (plugins) and on the release). All this > explanation is to state that it is not lack of interest, but lack > of manpower. You'd be amazed to know all of the things I'm > working in parallel. > > PS: the above note applies to all of you waiting for an answer > from my side... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From jcid@softhome.net Wed Aug 6 18:00:12 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 6 Aug 2003 13:00:12 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <200308060003.13382.kelson@pobox.com> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> Message-ID: <Pine.LNX.4.53.0308061257560.649@infinity.cl> Kelson, > On Tuesday 05 August 2003 10:58 am, Jorge Arellano Cid wrote: > > Kelson, Phil, Oliver: please make update your packages with it. > > OK, packages are ready for: > Red Hat 6.2, 7.3, 8, 9 > Mandrake 8.2, 9.1, and 9.1 PPC > SuSE 8.2 > > I'm moving the RPM download page to http://www.hyperborea.org/software/dillo/ > (just replace the .html with a /). There's a server redirect in place, but > it wouldn't hurt to update the link. Done. > I've updated a separate copy of the page, so all I have to do is switch it in > when the release is ready. If anyone wants to check out the rpms early, go > to http://www.hyperborea.org/software/dillo/index-new.shtml Thanks a lot for your commitment! The announcement will be this Thursday's morning. Cheers Jorge.- From jcid@softhome.net Wed Aug 6 19:07:21 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 6 Aug 2003 14:07:21 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <Pine.LNX.4.56.0308061627020.17402@kiku.itsise> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> <Pine.LNX.4.56.0308061627020.17402@kiku.itsise> Message-ID: <Pine.LNX.4.53.0308061356360.649@infinity.cl> Madis, > The HTTPS stuff will go on top of dpi, when the dpi has enough > functionality for it (i'm hoping a bit for the new dpid stuff). > Possibly i'll try to hack something together in next month. I set a deadline on myself: 0.8.0-pre must be in CVS before Saturday (Aug 09, 2003). With all the delays related to 0.7.3 release, I spent some time developing a tiny https.dpi (to provide a starting point for interested people). Unfortunately there're still some things to fix (inside Dillo, not in the dpi) to make it work. Anyway, working or not, the code will be in CVS before the deadline (I feel guilty for delaying it too much). > PS. I'll create separate cache-control patch for current cvs, when > there is a interest about merging it with the CVS (not before, > because it would be to much trouble to mantain it separately). OK. Cheers Jorge.- From jcid@softhome.net Wed Aug 6 18:13:03 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 6 Aug 2003 13:13:03 -0400 (CLT) Subject: [Dillo-dev] Frame support, suggestion: compile-option --xhtml-dtd In-Reply-To: <20030806091518.GC21653@unternet.org> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> <20030805082312.GB6554@unternet.org> <20030805093958.GE6554@unternet.org> <20030806091518.GC21653@unternet.org> Message-ID: <Pine.LNX.4.53.0308061302140.649@infinity.cl> On Wed, 6 Aug 2003, Frank de Lange wrote: > On Tue, Aug 05, 2003 at 11:39:59AM +0200, Frank de Lange wrote: > > This is in violation of the HTML specs (href is a required parameter for > > <base>). What should Dillo do in this case? Just as stated in our "HTML parsing policy" inside [Project Notes]! > > Currently it only checks for the > > target parameter after it has found a href in the tag (literal interpretation > > the definition of <base>), but this breaks pages like Namesys' which violate > > the standard. I can: > > > > a) unconditionally change the code so these pages work > > b) add a compile option (--pedantic-mode or --quirks-mode or whatever) to > > disable/enable these changes > > c) leave it the way it is > > > > I personally prefer b, which gives everyone a choice. Choice is good. We never take a) -- because of our policies, neither b) -- explained at http://ometer.com/features.html (available from our [Links] section) sometimes c) -- When we don't have time! :) In a nutshell: we try to follow the standard, not to crash on bad pages, and ideally send a warning when facing bad HTML. > Any suggestions/comments to my suggestion? As stated above. Cheers Jorge.- From paka@MyRealBox.com Wed Aug 6 21:07:21 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Wed, 6 Aug 2003 15:07:21 -0500 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> References: <200308060003.13382.kelson@pobox.com> <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> Message-ID: <20030806200721.GP25982@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-06-03 11:35]: > At 05:06 AM 8/6/2003, Patrick Shanahan wrote: > ><frown> and _no_ rpm for SuSE 8.1 (which is still widely utilized)? > > Does the SuSE 8.2 RPM not work on 8.1? No, not in _most_ cases, and this is one. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From jcid@softhome.net Wed Aug 6 19:30:40 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 6 Aug 2003 14:30:40 -0400 (CLT) Subject: [Dillo-dev] Porting Dillo to uClinux target Message-ID: <Pine.LNX.4.53.0308061430270.649@infinity.cl> On Wed, 6 Aug 2003, Manigandan wrote: > Hi, > I am trying to port dillo to uClinux based coldfire > target(5272). Has some one already did this ?What should be my > starting point ? Is there some good document for porting dillo to > new targets ? Interesting: a long time ago I was almost hired to do it! AFAIR, nobody has reported how to do it yet, but I think it is possible with the required expertise. I mean it involves not only knowing Dillo internals, but also about the porting state of the libraries it depends upon: mainly glib, GTK+ and pthread. It seems that if Dillo is upgraded to use GTK+2 the task gets a bit simpler (and we have plans to do it so). This link may help: (and an email to its author) https://mailman.uclinux.org/pipermail/uclinux-dev/2003-March/015973.html Finally, if you work for a company interested enough to sponsor the port, you can contact us to make a plan. Cheers Jorge.- From jcid@softhome.net Wed Aug 6 19:25:04 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 6 Aug 2003 14:25:04 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <20030806184049.254bb014.o.h.a@gmx.net> References: <Pine.LNX.4.53.0308051344070.675@infinity.cl> <20030806184049.254bb014.o.h.a@gmx.net> Message-ID: <Pine.LNX.4.53.0308061423120.649@infinity.cl> On Wed, 6 Aug 2003, Oliver Haertel wrote: > > Slackpacks here: > http://www.linuxpackages.net/details.php?name=dillo Good! BTW, why doesn't it state i386 or i486 in the tarball name? Something like: dillo-0.7.3-i386-1.tgz Cheers Jorge.- From kelson@pobox.com Wed Aug 6 23:39:03 2003 From: kelson@pobox.com (Kelson Vibber) Date: Wed, 06 Aug 2003 15:39:03 -0700 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <20030806200721.GP25982@wahoo.no-ip.org> References: <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> <200308060003.13382.kelson@pobox.com> <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> Message-ID: <5.2.1.1.0.20030806151639.01dafe48@mail.speed.net> At 01:07 PM 8/6/2003, Patrick Shanahan wrote: >* Kelson Vibber <kelson@pobox.com> [08-06-03 11:35]: > > At 05:06 AM 8/6/2003, Patrick Shanahan wrote: > > ><frown> and _no_ rpm for SuSE 8.1 (which is still widely utilized)? > > > > Does the SuSE 8.2 RPM not work on 8.1? > >No, not in _most_ cases, and this is one. Interesting. I guess it's a different philosophy of when to break binary compatibility. I've been using Red Hat for years, and they generally only jump major library versions with the x.0 releases. The Dillo package built on RH 7.3, for instance, will also run on RH 7.2 and RH 7.1. (At least the 0.7.2 one does - I'll have to verify the new one.) I've generally figured on just aiming for the most recent point release - Red Hat 6.2, 7.3, etc., Mandrake 8.2, 9.1, and so on. Does the .src.rpm work? (Running "rpm --rebuild dillo-0.7.3-1.src.rpm" should build a valid i386 or i586 RPM.) If so, the easiest thing would be to just email me a copy of the resulting RPM (assuming it's 200-300 KB) and I'll post it. In the long run, I guess I'll have to install a SuSE 8.1 partition. Out of curiosity, what errors does it report when you try to run the 8.2 RPM on 8.1? Kelson Vibber www.hyperborea.org From netdxr@adelphia.net Thu Aug 7 01:31:23 2003 From: netdxr@adelphia.net (Tom Lisjac) Date: 06 Aug 2003 18:31:23 -0600 Subject: [Dillo-dev] Refresh tag patch... Message-ID: <1060216282.6074.52.camel@spiffy> Last Spring we deployed Dillo 7.2 for use in library lookup stations at a local elementary school. Dillo ran beautifully in our LTSP lab and on 4 CD booted, diskless P-120's with 64 megabytes of ram: http://otero.harrison.k12.co.us/Linux/lab.html For catalog searches, the librarians, teachers and kids love Dillo and prefer it to Mozilla on Linux or IE on Win98. We would like to install diskless Linux lookup stations in all the school libraries... which would replace 200+ Windows 98 installs. The *only* problem is that the card catalog server (Accent) uses sessions that require periodic client refresh. If the sessions time out, the server produces an error message that confuses the kids and frequently requires teacher intervention. I understand and respect the reasons for not supporting the refresh tag... but I was wondering if someone may have had this problem and developed a patch or some other technique to make it work. Best regards, Tom Lisjac http://theseus.sourceforge.net From paka@MyRealBox.com Thu Aug 7 02:00:04 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Wed, 6 Aug 2003 20:00:04 -0500 Subject: [Dillo-dev] dillo-0.7.3.tar.bz2 In-Reply-To: <5.2.1.1.0.20030806151639.01dafe48@mail.speed.net> References: <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> <200308060003.13382.kelson@pobox.com> <Pine.LNX.4.53.0308051344070.675@infinity.cl> <200308060003.13382.kelson@pobox.com> <5.2.1.1.0.20030806092521.01bebb38@mail.speed.net> <5.2.1.1.0.20030806151639.01dafe48@mail.speed.net> Message-ID: <20030807010004.GR25982@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-06-03 17:43]: > At 01:07 PM 8/6/2003, Patrick Shanahan wrote: > >* Kelson Vibber <kelson@pobox.com> [08-06-03 11:35]: > >> At 05:06 AM 8/6/2003, Patrick Shanahan wrote: > >> ><frown> and _no_ rpm for SuSE 8.1 (which is still widely utilized)? > >> > >> Does the SuSE 8.2 RPM not work on 8.1? > > > >No, not in _most_ cases, and this is one. >=20 > Interesting. I guess it's a different philosophy of when to break binary= =20 > compatibility. I've been using Red Hat for years, and they generally onl= y=20 > jump major library versions with the x.0 releases. The Dillo package bui= lt=20 > on RH 7.3, for instance, will also run on RH 7.2 and RH 7.1. (At least t= he=20 > 0.7.2 one does - I'll have to verify the new one.) for 'rpm -Uvh dillo-0.7.2-4.suse.i586.rpm': Dependency Problem: libc.so.6(GLIBC_2.3) is needed by dillo-0.7.2-4 libpng.so.3 is needed by dillo-0.7.2-4 libpthread.so.0(GLIBC_2.3.2) is needed by dillo-0.7.2-4 =20 > I've generally figured on just aiming for the most recent point release -= =20 > Red Hat 6.2, 7.3, etc., Mandrake 8.2, 9.1, and so on. >=20 > Does the .src.rpm work? (Running "rpm --rebuild dillo-0.7.3-1.src.rpm"= =20 > should build a valid i386 or i586 RPM.) If so, the easiest thing would be= =20 > to just email me a copy of the resulting RPM (assuming it's 200-300 KB) a= nd=20 > I'll post it. =20 for 'rpm --rebuild dillo-0.7.2-5.src.rpm': checking png.h usability... no checking png.h presence... yes configure: WARNING: png.h: present but cannot be compiled configure: WARNING: png.h: check for missing prerequisite headers? configure: WARNING: png.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for png.h... yes checking for png_check_sig in -lpng... no checking for pthread_create in -lpthread... no checking for ANSI C header files... (cached) yes checking fcntl.h usability... no checking fcntl.h presence... yes configure: WARNING: fcntl.h: present but cannot be compiled configure: WARNING: fcntl.h: check for missing prerequisite headers? configure: WARNING: fcntl.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for fcntl.h... yes checking for unistd.h... (cached) yes checking sys/uio.h usability... no checking sys/uio.h presence... yes configure: WARNING: sys/uio.h: present but cannot be compiled configure: WARNING: sys/uio.h: check for missing prerequisite headers? configure: WARNING: sys/uio.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for sys/uio.h... yes checking for socket... no configure: creating ./config.status config.status: creating Makefile sed: file ./confstat6jcZWb/subs-2.sed line 19: Unterminated =13' command config.status: creating dpi/Makefile sed: file ./confstat6jcZWb/subs-2.sed line 19: Unterminated =13' command config.status: creating doc/Makefile sed: file ./confstat6jcZWb/subs-2.sed line 19: Unterminated =13' command config.status: creating src/Makefile sed: file ./confstat6jcZWb/subs-2.sed line 19: Unterminated =13' command config.status: creating src/IO/Makefile sed: file ./confstat6jcZWb/subs-2.sed line 19: Unterminated =13' command config.status: creating config.h config.status: executing depfiles commands + make 'RPM_OPT_FLAGS=3D-O2 -march=3Di486 -mcpu=3Di686' make: *** No targets. Stop. Bad exit status from /var/tmp/rpm-tmp.22820 (%build) Where to go ?? --=20 Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From spambait@whitehouse.gov Thu Aug 7 02:19:02 2003 From: spambait@whitehouse.gov (Reid Fleming) Date: Wed, 6 Aug 2003 18:19:02 -0700 Subject: [Dillo-dev] Anti-aliasing patch for dillo-0.7.3 available Message-ID: <20030807011902.GA24971@bigredrockeater.com> Greetings, Some time ago Nicola Girardi posted an anti-aliasing patch for 0.7.1 or 0.7.2 (thanks Nicola!). Based on that patch, I have created a patch to dillo-0.7.3. This patch has only been tested on a Redhat 8.0 system. You will need to install freetype-devel, fontconfig-devel, and Xft-devel if not already installed. The patch is available at: http://www.bigredrockeater.com/dillo/dillo-0.7.3xft.diff From wang_xq@neusoft.com Thu Aug 7 07:10:20 2003 From: wang_xq@neusoft.com (ronnie) Date: Thu, 07 Aug 2003 14:10:20 +0800 Subject: [Dillo-dev] gdk_font_load & selecting and paste!! Message-ID: <001401c35caa$96f4d7d0$d41ea8c0@ronnie> This is a multi-part message in MIME format. --Boundary_(ID_dn2tYni7q2XzTxCdiHUi7g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT hi all: I replace the gdk_font_load with gdk_fontset_load for displaying the chinese .Because the API gdk_font_load can not load the muticharacter encoding .But when I select some text then dillo crash .WHY? --Boundary_(ID_dn2tYni7q2XzTxCdiHUi7g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=gb2312"> <META content="MSHTML 6.00.2600.0" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT size=2>hi all:</FONT></DIV> <DIV><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp; I replace the gdk_font_load with gdk_fontset_load for displaying the chinese .Because the API gdk_font_load can not load the muticharacter encoding .But when I select some text then dillo crash .WHY?</FONT></DIV></BODY></HTML> --Boundary_(ID_dn2tYni7q2XzTxCdiHUi7g)-- From frank@unternet.org Thu Aug 7 10:39:00 2003 From: frank@unternet.org (Frank de Lange) Date: Thu, 7 Aug 2003 11:39:00 +0200 Subject: [Dillo-dev] Frame support, suggestion: compile-option --xhtml-dtd In-Reply-To: <Pine.LNX.4.53.0308061302140.649@infinity.cl> References: <20030804224019.GB10969@unternet.org> <20030805100435.26d6c9f4.Jens.Arm@gmx.de> <20030805082312.GB6554@unternet.org> <20030805093958.GE6554@unternet.org> <20030806091518.GC21653@unternet.org> <Pine.LNX.4.53.0308061302140.649@infinity.cl> Message-ID: <20030807093900.GB27565@unternet.org> On Wed, Aug 06, 2003 at 01:13:03PM -0400, Jorge Arellano Cid wrote: > > > a) unconditionally change the code so these pages work > > > b) add a compile option (--pedantic-mode or --quirks-mode or whatever) to > > > disable/enable these changes > > > c) leave it the way it is > > > > > > I personally prefer b, which gives everyone a choice. Choice is good. > > We never take a) -- because of our policies, > neither b) -- explained at > http://ometer.com/features.html > (available from our [Links] section) > sometimes c) -- When we don't have time! :) > > In a nutshell: we try to follow the standard, not to crash on > bad pages, and ideally send a warning when facing bad HTML. The new patch adds a new compile option: --enable-xhtml-dtd, which can be set to 'strict', 'transitional' or 'frameset'. Setting it to either of these configures the parser for that xhtml-dtd. I take it this is consistent in the current practice. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From jcid@softhome.net Thu Aug 7 15:20:27 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Thu, 7 Aug 2003 10:20:27 -0400 (CLT) Subject: [Dillo-dev] dillo-0.7.3 is (finally) officially done! Message-ID: <Pine.LNX.4.53.0308071016400.649@infinity.cl> Hi there! It took a lot of time, but finally, dillo-0.7.3 is out! I just finished updating the web site and submitting the announcement to freshmeat (it usually takes some minutes to show in the fm's front page). This message is for those that haven't noticed yet. Or that have noticed too much failed attempts! :-) Enjoy Jorge.- From nicola@g-n-u.de Thu Aug 7 17:27:19 2003 From: nicola@g-n-u.de (Nicola Girardi) Date: Thu, 07 Aug 2003 18:27:19 +0200 Subject: [Dillo-dev] Anti-aliasing patch for dillo-0.7.3 available In-Reply-To: <20030807011902.GA24971@bigredrockeater.com> References: <20030807011902.GA24971@bigredrockeater.com> Message-ID: <19knbj-05J-00@sagredo.warez.linux.it> > Some time ago Nicola Girardi posted an anti-aliasing patch > for 0.7.1 or 0.7.2 (thanks Nicola!). Based on that patch, > I have created a patch to dillo-0.7.3. Please, could you also tell us what you have changed besides adapting the patch to 0.7.3? Best regards. From kelson@pobox.com Thu Aug 7 18:58:26 2003 From: kelson@pobox.com (Kelson Vibber) Date: Thu, 7 Aug 2003 10:58:26 -0700 Subject: [Dillo-dev] Dillo RPM/build on SuSE 8.1 Message-ID: <200308071058.26378.kelson@pobox.com> Patrick, =46rom what you sent me it looks like the problem with the binary RPM is ov= er=20 new libpng and glibc versions. Here's what I've gotten from SuSE's FTP site as far as library versions: SuSE 8.1: glibc 2.2 libpng 1.2.4 SuSE 8.2: glibc 2.3 libpng 1.2.5 So the glibc version conflict is explained. The libpng conflict is strange= ,=20 though, because I would expect those to be the same generation of libpng. = =20 What version does "rpm -qi libpng" report? I did some digging through the mailing list archives, and came across the=20 thread in which you were having problems compiling 0.7.2 from source. I ha= d=20 forgotten that the source needed to be patched to compile it on SuSE 8.1 (= =20 http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-April/000532.html ) Does the 0.7.3 source RPM build, or does it give you the same libpng errors= as=20 0.7.2? Can you compile 0.7.3 from source? If not, does it work after=20 applying the patch? If so, I'll add it to the SRPM and apply it for SuSE <= =3D=20 8.1 (or better yet, if I can figure out a way to do it, only on versions of= =20 libpng that need it). I'll try to find time soon to install a copy of SuSE 8.1 so I can do my own= =20 testing & building. I'm not too fond of SuSE's FTP-based installation, but= =20 the rant would be way off-topic. For now, I've renamed the SuSE RPM to mak= e=20 it clear it will only work on 8.2. =2D-=20 Kelson Vibber www.hyperborea.org From ralph@genesys.ro Thu Aug 7 20:02:46 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Thu, 7 Aug 2003 21:02:46 +0200 Subject: [Dillo-dev] Refresh shortcut? Message-ID: <20030807210246.1e197ff7.ralph@genesys.ro> --dY6hATrS/Q=.'Gcl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi there all, Just a small question: Are there any plans to implicate a keyboard shortcut for refreshing? I know the rest of them, and unless I'm mistaken, the only one missing is refresh ;-) I use dillo mainly on my laptop, and try do as much possible with keyboard shortcuts, and when using forums, the refresh is neccissary to see which posts have / have not been viewed. Many thanks Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --dY6hATrS/Q=.'Gcl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MqJZAWKxH5yWMT8RAnAkAJ4x4+r7cuRRPwl9SAIO1TVjU5GuWgCgtSOM YFrjUtKmiXF44CybwIBSsMQ= =sKVc -----END PGP SIGNATURE----- --dY6hATrS/Q=.'Gcl-- From spambait@whitehouse.gov Thu Aug 7 21:10:16 2003 From: spambait@whitehouse.gov (Reid Fleming) Date: Thu, 7 Aug 2003 13:10:16 -0700 Subject: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available Message-ID: <20030807201016.GA29432@bigredrockeater.com> > Please, could you also tell us what you have changed besides > adapting the patch to 0.7.3? There were almost no changes from your patch, aside from "src/Makefile.in" where I changed LIBS = @LIBS@ to LIBS = @LIBS@ -lXft2 -lXrender -lfontconfig so that it would correctly link on my machine. There might have been an additional instance of gdk_text_width that I changed to gdk_text_width_xft but that's it. Thanks again for your patch. Will this make it in to the next version of dillo ? From frank@unternet.org Thu Aug 7 22:37:04 2003 From: frank@unternet.org (Frank de Lange) Date: Thu, 7 Aug 2003 23:37:04 +0200 Subject: [Dillo-dev] Refresh shortcut? In-Reply-To: <20030807210246.1e197ff7.ralph@genesys.ro> References: <20030807210246.1e197ff7.ralph@genesys.ro> Message-ID: <20030807213703.GD27565@unternet.org> On Thu, Aug 07, 2003 at 09:02:46PM +0200, Ralph Slooten wrote: > Hi there all, > > Just a small question: Are there any plans to implicate a keyboard shortcut for > refreshing? I know the rest of them, and unless I'm mistaken, the only one > missing is refresh ;-) I use dillo mainly on my laptop, and try do as much > possible with keyboard shortcuts, and when using forums, the refresh is > neccissary to see which posts have / have not been viewed. Will be included in the next version of the tab patch, which is forthcoming... I'll remove it from there if it appears in CVS Dillo. I miss it as well... I'll try to add find_as_you_type as well, which is also a great time/hand saver when using keyboard navigation. Might not be in the next version though... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From nicola@g-n-u.de Fri Aug 8 00:31:04 2003 From: nicola@g-n-u.de (Nicola Girardi) Date: Fri, 08 Aug 2003 01:31:04 +0200 Subject: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available In-Reply-To: <20030807201016.GA29432@bigredrockeater.com> References: <20030807201016.GA29432@bigredrockeater.com> Message-ID: <19kuDo-04C-00@sagredo.warez.linux.it> > There were almost no changes from your patch, aside from > "src/Makefile.in" where I changed OK, thanks. (I asked only because I was considering using your patch instead of mine.) > Thanks again for your patch. Well, I think I should credit someone actually, but I don't even remember the author of the original patch... > Will this make it in to the next version of dillo ? I have been wondering for a while... =) From paka@MyRealBox.com Fri Aug 8 01:48:19 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Thu, 7 Aug 2003 19:48:19 -0500 Subject: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1 In-Reply-To: <200308071058.26378.kelson@pobox.com> References: <200308071058.26378.kelson@pobox.com> Message-ID: <20030808004818.GD10143@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-07-03 13:01]: > Patrick, > > From what you sent me it looks like the problem with the binary RPM > is over new libpng and glibc versions. > > Here's what I've gotten from SuSE's FTP site as far as library > versions: > > SuSE 8.1: > glibc 2.2 > libpng 1.2.4 > > SuSE 8.2: > glibc 2.3 > libpng 1.2.5 > > So the glibc version conflict is explained. The libpng conflict is > strange, though, because I would expect those to be the same > generation of libpng. What version does "rpm -qi libpng" report? 1.2.4 > I did some digging through the mailing list archives, and came across > the thread in which you were having problems compiling 0.7.2 from > source. I had forgotten that the source needed to be patched to > compile it on SuSE 8.1 ( > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-April/000532.html > ) dillo.configure.diff: *** configure.dist 2003-04-29 18:24:39.000000000 +0200 --- configure 2003-04-30 11:43:31.000000000 +0200 *************** *** 4227,4233 **** PNG_CONFIG="`which libpng-config || which libpng12-config`" if test -n "$PNG_CONFIG" ; then ! CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" fi --- 4227,4233 ---- PNG_CONFIG="`which libpng-config || which libpng12-config`" if test -n "$PNG_CONFIG" ; then ! CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" fi > Does the 0.7.3 source RPM build, or does it give you the same libpng > errors as 0.7.2? Can you compile 0.7.3 from source? If not, does it > work after applying the patch? If so, I'll add it to the SRPM and > apply it for SuSE <= 8.1 (or better yet, if I can figure out a way to > do it, only on versions of libpng that need it). 0.7.3 compiles fine with the patch above and works... checkinstall generated dillo-dillo-1.i586.rpm, 1674753 bytes > I'll try to find time soon to install a copy of SuSE 8.1 so I can do > my own testing & building. I'm not too fond of SuSE's FTP-based > installation, but the rant would be way off-topic. For now, I've > renamed the SuSE RPM to make it clear it will only work on 8.2. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From paka@MyRealBox.com Fri Aug 8 01:54:55 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Thu, 7 Aug 2003 19:54:55 -0500 Subject: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1 In-Reply-To: <20030808004818.GD10143@wahoo.no-ip.org> References: <200308071058.26378.kelson@pobox.com> <20030808004818.GD10143@wahoo.no-ip.org> Message-ID: <20030808005455.GE10143@wahoo.no-ip.org> * Patrick Shanahan <paka@MyRealBox.com> [08-07-03 19:52]: > and works... checkinstall generated dillo-dillo-1.i586.rpm, 1674753 bytes correction, dillo-0.7.3-1.i586.rpm, 1769215 bytes -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From kelson@pobox.com Fri Aug 8 03:47:21 2003 From: kelson@pobox.com (Kelson Vibber) Date: Thu, 7 Aug 2003 19:47:21 -0700 Subject: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1 In-Reply-To: <20030808004818.GD10143@wahoo.no-ip.org> References: <200308071058.26378.kelson@pobox.com> <20030808004818.GD10143@wahoo.no-ip.org> Message-ID: <200308071947.22074.kelson@pobox.com> OK, here's a test SRPM that includes the patch: http://www.hyperborea.org/software/dillo/rpms/dillo-0.7.3-2test1.src.rpm Right now I just have it adding the patch by default, since it won't actually change any behavior on Red Hat <= 9 or Mandrake <= 9.1. They don't include libpng-config or libpng12-config, so the line being changed never gets called. I'll have to check to make sure it doesn't cause problems for SuSE 8.2. Give it a try and let me know if it works - and what size it ends up being. That's the other mystery: how checkinstall ends up with such huge binaries. I don't do anything special to minimize the size, except calling "make install-strip" instead of "make install" - but I seem to recall that wasn't the issue in this case. -- Kelson Vibber www.hyperborea.org From ralph@genesys.ro Fri Aug 8 07:31:09 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Fri, 8 Aug 2003 08:31:09 +0200 Subject: [Dillo-dev] Refresh shortcut? In-Reply-To: <20030807213703.GD27565@unternet.org> References: <20030807210246.1e197ff7.ralph@genesys.ro> <20030807213703.GD27565@unternet.org> Message-ID: <20030808083109.608c25b5.ralph@genesys.ro> --=.Pb(7g0nu+iPtf? Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thu, 7 Aug 2003 23:37:04 +0200 Frank de Lange <frank@unternet.org> wrote: > Will be included in the next version of the tab patch, which is forthcoming... > I'll remove it from there if it appears in CVS Dillo. I miss it as well... > > I'll try to add find_as_you_type as well, which is also a great time/hand > saver when using keyboard navigation. Might not be in the next version > though... > > Cheers//Frank Super, thanks Frank! I do love your tabs/frames patch too (just thought I'd say it) ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --=.Pb(7g0nu+iPtf? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/M0OwAWKxH5yWMT8RArxmAJ4mfhZ+gRl22NFofSKqeWxR9+UCMQCg2cQJ iWyY6NWlV8MJr7e2RNgBmGM= =thI0 -----END PGP SIGNATURE----- --=.Pb(7g0nu+iPtf?-- From paka@MyRealBox.com Fri Aug 8 12:28:47 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Fri, 8 Aug 2003 06:28:47 -0500 Subject: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1 In-Reply-To: <200308071947.22074.kelson@pobox.com> References: <200308071058.26378.kelson@pobox.com> <20030808004818.GD10143@wahoo.no-ip.org> <200308071947.22074.kelson@pobox.com> Message-ID: <20030808112847.GG10143@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-07-03 21:50]: > OK, here's a test SRPM that includes the patch: > http://www.hyperborea.org/software/dillo/rpms/dillo-0.7.3-2test1.src.rpm > > Right now I just have it adding the patch by default, since it won't actually > change any behavior on Red Hat <= 9 or Mandrake <= 9.1. They don't include > libpng-config or libpng12-config, so the line being changed never gets > called. I'll have to check to make sure it doesn't cause problems for SuSE > 8.2. > > Give it a try and let me know if it works - and what size it ends up being. 239084, dillo-0.7.3-2test1.i586.rpm > That's the other mystery: how checkinstall ends up with such huge binaries. I > don't do anything special to minimize the size, except calling "make > install-strip" instead of "make install" - but I seem to recall that wasn't > the issue in this case. strip may be the answer. Checkinstall binary 3 417 690 after strip 323 176 test binary 323 208 change checkinstallrc 323 176 Edited /etc/checkinstallrc, # Automatically strip all ELF binaries? STRIP_ELF=1 # Automatically strip all ELF shared libraries? # Note: this setting will automatically be set to "0" if STRIP_ELF=0 STRIP_SO_ELF=1 'STRIP' Was originally '0', resulting rpm was 196002. The file locations in the rpms are different. Should I include them in an email to you or put them on my web site for you to download ?? tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From jcid@softhome.net Fri Aug 8 16:20:38 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 8 Aug 2003 11:20:38 -0400 (CLT) Subject: [Dillo-dev] Thanks for dillo! (fwd) Message-ID: <Pine.LNX.4.53.0308081120350.772@infinity.cl> ---------- Forwarded message ---------- Date: Thu, 7 Aug 2003 23:05:56 PDT From: Dmnz <dmnz@x-bit.org> To: jcid <jcid@softhome.net> Subject: Thanks for dillo! Jorge, Just wanted to extend thanks for coding dillo. All I have at the moment are two tadpole sparcbook 3gx's. Dillo is the only browser I can use on them with any speed. It runs off the openbsd sparbook and displays on the solaris one with 16bbp color. For us poor folks dillo is great! Thanks for your time and efforts to make a great lightweight browser! Best Regards, B. Stevens dmnz@x-bit.org ... Dammit Jim, I'm a doctor, not a tagline writer. From jcid@softhome.net Fri Aug 8 16:32:03 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 8 Aug 2003 11:32:03 -0400 (CLT) Subject: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available In-Reply-To: <19kuDo-04C-00@sagredo.warez.linux.it> References: <20030807201016.GA29432@bigredrockeater.com> <19kuDo-04C-00@sagredo.warez.linux.it> Message-ID: <Pine.LNX.4.53.0308081126090.772@infinity.cl> > > Will this make it in to the next version of dillo ? > > I have been wondering for a while... =) Sorry for not having answered before (it was on my long list of pending tasks). When reviewing the patch I noticed that it'd be very difficult to incorporate the patch and remain easy to install through the wide range of platforms we support. The alternative is to add a configuration switch, but considering that anti aliasing will come from GTK+2, I think is better to let the interested pepople to grab your patch. I owe you a link from [Project notes] or similar. BTW, It'd be really good to know who was the original author. Cheers Jorge.- From jcid@softhome.net Fri Aug 8 16:16:24 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 8 Aug 2003 11:16:24 -0400 (CLT) Subject: [Dillo-dev] Refresh tag patch... In-Reply-To: <1060216282.6074.52.camel@spiffy> References: <1060216282.6074.52.camel@spiffy> Message-ID: <Pine.LNX.4.53.0308081044260.772@infinity.cl> Tom, > Last Spring we deployed Dillo 7.2 for use in library lookup stations at > a local elementary school. Dillo ran beautifully in our LTSP lab and on > 4 CD booted, diskless P-120's with 64 megabytes of ram: > > http://otero.harrison.k12.co.us/Linux/lab.html Great! It is excellent news to know you have deployed dillo in an heterogeneous environment successfully. > For catalog searches, the librarians, teachers and kids love Dillo and > prefer it to Mozilla on Linux or IE on Win98. This is very significative and encouraging: different kinds of users, with varying degrees of expertise had a choice in your lab, and they preferred Dillo! > We would like to install > diskless Linux lookup stations in all the school libraries... which > would replace 200+ Windows 98 installs. Sounds perfect! > The *only* problem is that the > card catalog server (Accent) uses sessions that require periodic client > refresh. If the sessions time out, the server produces an error message > that confuses the kids and frequently requires teacher intervention. > > I understand and respect the reasons for not supporting the refresh > tag... but I was wondering if someone may have had this problem and > developed a patch or some other technique to make it work. Let's see: "sessions that require periodic client refresh" It sounds more like cookie sessions combined with cache control directives than HTML-embedded meta refresh tags. (if you can see our custom warning msg, it's a meta-refresh) AFAICS It'd be rare for a server to send a meta-refresh tags because it can generate the page itself. Although I also see that if the resource is elsewhere it can try to redirect the browser, but again HTTP does it better. In anycase, please explain me in more detail what the desired functionality is, to study how to make it happen for you. If it is a cache issue, Madis Janson has a patch for that (only half reviewed by me, but with a good chance to make it into the official tree). I hope this to be the case. ... and if it is the propietary meta-refresh tag, considering that it'll be deployed as a kiosk, a private patch can cut it, but let's hope that's not the case! Cheers Jorge.- From jcid@softhome.net Fri Aug 8 16:18:14 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 8 Aug 2003 11:18:14 -0400 (CLT) Subject: [Dillo-dev] About Dillo (fwd) Message-ID: <Pine.LNX.4.53.0308081118040.772@infinity.cl> ---------- Forwarded message ---------- Date: Fri, 8 Aug 2003 08:19:24 +0200 From: Mathieu <mat.hieu@netcourrier.com> To: jcid@softhome.net Subject: About Dillo Hello, I discovered dillo yesterday because I was looking for a light browser for my old laptop. I think it's a great job, and I congratulate you and the other authors. I hope this project will stay so active. Thanks a lot ! Mathieu From tomas@fabula.de Fri Aug 8 18:53:49 2003 From: tomas@fabula.de (tomas@fabula.de) Date: Fri, 8 Aug 2003 19:53:49 +0200 Subject: [Dillo-dev] [PATCH] Tentative solution of #448, #449 Message-ID: <20030808175349.GB23684@www> Hi, I've got a problem with 8 bit depth visuals (the images have the wrong palette). This is similar to bug #449 of your bug tracking database (thus I tentatively offered to fix it. Tentative patch is below. Besides, this looks very much like bug #448, so this might be related. I call the patch ``tentative'' because (a) I don't really know 100% what I'm doing here (b) I haven't tested this on other color depths yet. Nevertheless images show correctly now; the price I pay for this is Technicolor. Regards -- tomas ------------------------------------------------- diff -Naur dillo-0.7.3/src/dillo.c dillo-0.7.3-color/src/dillo.c --- dillo-0.7.3/src/dillo.c Tue Jul 22 22:51:22 2003 +++ dillo-0.7.3-color/src/dillo.c Fri Aug 8 19:01:32 2003 @@ -245,6 +245,9 @@ signal(SIGCHLD, Dillo_sigchld_handler); + gtk_widget_push_visual(gdk_rgb_get_visual()); + gtk_widget_push_colormap(gdk_rgb_get_cmap()); + /* check that ~/.dillo exists, create it if it doesn't */ dir = a_Misc_prepend_user_home(".dillo"); Dillo_check_home_dir(dir); @@ -304,6 +307,9 @@ a_Prefs_freeall(); a_Dw_freeall(); a_History_free(); + + gtk_widget_pop_colormap(); + gtk_widget_pop_visual(); g_print("Dillo: normal exit!\n"); return 0; From nicola@g-n-u.de Fri Aug 8 19:35:09 2003 From: nicola@g-n-u.de (Nicola Girardi) Date: Fri, 08 Aug 2003 20:35:09 +0200 Subject: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available In-Reply-To: <Pine.LNX.4.53.0308081126090.772@infinity.cl> References: <20030807201016.GA29432@bigredrockeater.com> <19kuDo-04C-00@sagredo.warez.linux.it> <Pine.LNX.4.53.0308081126090.772@infinity.cl> Message-ID: <19lC4z-0SE-00@sagredo.warez.linux.it> > I think is better to let the interested pepople to grab your > patch. Sounds reasonable, thanks for the response. > BTW, It'd be really good to know who was the original author. I did a quick search, it must be Tor Andersson. Greetings :-) From jcid@softhome.net Fri Aug 8 21:54:30 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 8 Aug 2003 16:54:30 -0400 (CLT) Subject: [Dillo-dev] dillo-0.8.0-pre Message-ID: <Pine.LNX.4.53.0308081631590.772@infinity.cl> Hi there! It took a lot of time and effort, but finally the base for the next release (aka. 0.8.0-pre) is in the CVS now. It comes with lots of changes and some rough edges. Check the ChangeLog for a summary. This is not polished, nor your good ole' CVS snapshot, it is more intended for people interested in playing with the new dpi stuff. The dpid (dpi daemon) still requires a manual launch, and there're several things to improve (commented inside the code). As for the new dpis: FTP: It works OK, but is silent. This means it will not tell you what is doing until it's done. This is simple to fix and is a matter of capturing the stderr from wget and sending back some messages to dillo. You can download with the downloads plugin (right click on the link and "save as"). Downloads: It uses wget in a separate process (if dillo crashes, the download will survive). It can handle multiple downloads at the same time. It's also silent by now, but there's a guy that's working on a nice GUI that will provide all the necessary interfacing (aka Bells and Whistles). I'll ask him to share the code when it gets to a more advanced stage. Https: Unfortunately it doesn't work well (only for single, trivial, documents {with no image links} or single images). The problem is not within the plugin but with internal buffering inside dillo's core. I'll look at it when I have more time. There's an interesting discussion about suitability of UDS for HTTPS. Read the comments inside the code for more details. Hello: Just an example. This is the one you're supposed to play hard with if you want to develop a new dpi! Mailto: inexistent, but quite easy to develop. Just make the bindings and fork your favorite MUA. Cookies: Still need to be made a dpi (ported). That will solve our one-instance-only restriction. Read the docs! Ah, copy all the dpis to your ~/.dillo (we haven't defined where to place them yet). You'll also need a "dpidrc" in your ~/.dillo directory. Mine looks like: <q> /home/jcid/.dillo/bookmarks.dpi 0 /home/jcid/.dillo/downloads.dpi 0 /home/jcid/.dillo/ftp.dpi 1 /home/jcid/.dillo/https.dpi 1 /home/jcid/.dillo/hello.dpi 1 </q> Don't forget to launch dpid! That's all folks. Time to pause, recess, repose, break, rest ... Cheers Jorge.- From spambait@navspecwargrp.mil Fri Aug 8 23:14:23 2003 From: spambait@navspecwargrp.mil (Reid Fleming) Date: Fri, 8 Aug 2003 15:14:23 -0700 Subject: [Dillo-dev] 0.7.3 not rendering "trade" and other small annoyances Message-ID: <20030808221423.GA7031@bigredrockeater.com> Dillo 0.7.3 is not rendering the "trade mark" HTML entity, although it is in the entity table in "src/html.c". You can see this behaviour by viewing this page: http://www.forum.nokia.com/nds_for_j2me.html You can see some strangeness by going to http://www.metafilter.com and scrolling down to the entry that begins: Canada's Supreme Court Trashes Citizens' Property Rights. where Dillo is rendering '"' sometimes as a circumflex accent. From netdxr@adelphia.net Sat Aug 9 09:18:33 2003 From: netdxr@adelphia.net (Tom Lisjac) Date: 09 Aug 2003 02:18:33 -0600 Subject: [Dillo-dev] Refresh tag patch... In-Reply-To: <Pine.LNX.4.53.0308081044260.772@infinity.cl> References: <1060216282.6074.52.camel@spiffy> <Pine.LNX.4.53.0308081044260.772@infinity.cl> Message-ID: <1060417112.7259.562.camel@spiffy> On Fri, 2003-08-08 at 09:16, Jorge Arellano Cid wrote: > > For catalog searches, the librarians, teachers and kids love Dillo and > > prefer it to Mozilla on Linux or IE on Win98. > > This is very significative and encouraging: different kinds of > users, with varying degrees of expertise had a choice in your > lab, and they preferred Dillo! Yes! I think it's also worth mentioning that Dillo's performance and small footprint made it possible to build these workstations from older equipment that the school was preparing to throw away! Many more Linux boxes have been made available to the kids as a result! :) > > The *only* problem is that the > > card catalog server (Accent) uses sessions that require periodic client > > refresh. > AFAICS It'd be rare for a server to send a meta-refresh tags > because it can generate the page itself. Although I also see that > if the resource is elsewhere it can try to redirect the browser, > but again HTTP does it better. The server embeds a meta-refresh tag to re-home the lookup station after a search. Typically, students will do their card catalog queries, get the results and then walk away from the terminal. The refresh tag works well here because it will automatically reset the station back to the main search page for the next user. The librarians said that doing these resets manually was a source of distraction for them last Spring. > In anycase, please explain me in more detail what the desired > functionality is, to study how to make it happen for you. > > If it is a cache issue, Madis Janson has a patch for that (only > half reviewed by me, but with a good chance to make it into the > official tree). I hope this to be the case. Madis and a number of others were kind enough to point me at the patch. It provides meta-refresh along with a number of other nice features. One of the goals for this application, however, is to minimized the screen complexity and number of buttons that the bright and curious 8 years olds can push... so I'm trying to extract the meta-refresh code from the patch and apply it separately. Since C is not my first language, this is proving to be something of a challenge! :) Thanks and best regards, -Tom Lisjac http://theseus.sourceforge.net From s.geerken@ping.de Sat Aug 9 12:42:08 2003 From: s.geerken@ping.de (Sebastian Geerken) Date: Sat, 9 Aug 2003 13:42:08 +0200 Subject: [Dillo-dev] Question about frames (have them working, but...) In-Reply-To: <20030804222632.GA10969@unternet.org> References: <20030804222632.GA10969@unternet.org> Message-ID: <20030809114208.GB1614@sg.local> On Tue, Aug 05, Frank de Lange wrote: > What does not work yet: > > - obeying frameset proportions. Currently all frames are allocated a default > size. I have the appropriate sizes for the frames at hand, but GTK does not > provide a means to size multiple widgets in a container relative to the > size of that container. The 'gtk_widget_set_usize()' (or GTK2's > gtk_widget_set_size_request() replacement function) are not suitable for > this purpose, although they can be used to set a minimum or absolute size > for rows/columns which have been specified that way (frameset rows=100,100,* > is easy, frameset rows=100,20%,3*,* is not...). > - the full_screen_off_button is not shown in frame documents. Use double-click > instead to toggle the full screen setting... > > These problems can be solved by creating a new widget for the frameset, but > that might be overkill. DwTable provides some of the needed features, but is is > overcomplicated for the task at hand (no colspan or rowspan in framesets, etc) > and lacks direct control over the height of table cells. If anyone has any > bright ideas on how to assign widgets sizes which are relative to their > container, speak up... Or, if anyone has already created (or at least thought > about creating) a 'frameset' widget, please let me know. No need to re-invent > the wheel... > > If I get no response, I will probably create a new widget based on GtkTable, > with some built-in sizing magic. I chose GtkTable over DwTable because the > former seems to be more suitable for the purpose than the latter. I might be > wrong, please tell me... I would not call this an overkill. Creating a new widget with a rather limited functionality (since only used for framesets) is not a big deal, at least for someone who is a bit expierienced in it, but in most cases better that working around limitations of other widgets. Furthermore, it gives us more control over extensions becoming necessary in the future. > - the full_screen_off_button is not shown in frame documents. Use double-click > instead to toggle the full screen setting... You may put the "Show Controls" button into the new widget, look at GtkScrolledWindow for inspiration. Sebastian From melvin.hadasht@free.fr Sat Aug 9 23:39:48 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Sun, 10 Aug 2003 00:39:48 +0200 Subject: [Dillo-dev] [patch] Remote Control Message-ID: <etPan.3f357834.6181ef69.2c2@freefluid> --3f35873e_710757d0_2c2 Content-Type: text/plain Content-Transfer-Encoding: 8bit Hi, I just made a patch to add remote control for Dillo. 1. Summary: 1.1 Why? To be able to command Dillo from another process. E.g.: if Dillo is used as a help doc browser of a program, the program can implement context sensitive help and associate to each widget a help URL. The same Dillo instance can then be used to show the differents help docs. Other example, which also was the motivation of this patch: Sylpheed-Claws uses Dillo to render HTML mail, but currently it has to run a new instance each time the user views an HTML mail. Having only one instance is more efficient and improve responsiveness. 1.2. HowTo To be remote controlled, a Dillo instance must be explicitly started with a special command line option (-s, --server NAME), e.g.: dillo -s server A client instance sends commands to this server by referencing it and by using the -c, --command options, e.g.: a. dillo -s server -c "open(http://www.google.com)" -c "new-window(www.av.com)" b. dillo -s server http://www.google.com amounts to: dillo -s server -c "new-window(http://www.google.com)" Hence, running dillo -s server -c "open(URL)" mutliple times will launch only one instance of dillo at the first time, and the subsequent calls will just hand the arguments to the server. This is more practical than Mozilla's current behaviour where the user has to use two different commands to start and to control a server. The list of currently known commands is provided by the -H, --help-commands option: dillo -H Commands that can be used with the -c, --command option: open(URL) Open URL in current window. new-window(URL) Open URL in a new window. Exit() Terminate browsing session and exit. Command names are case insensitive. It is allowed to have more than one command option. New commands can be added, the syntax being: command(.*) 2. Ressources In dillorc: server_socket_path by default, it is "/tmp". It is used to create the socket name which is: $server_socket_path/dillo-$USER-$NAME. where $NAME is the server name from the -s, --server NAME option. E.g.: /tmp/dillo-john-help 3. Caveat If gtk specific command lines arguments are given, arguments are messed around, due to the fact that the patch delays gtk_init() after private arguments parsing, This will be fixed in the next version If a Dillo server does not quit cleanly, the socket corresponding to the server is not removed. Subsequent attempts to run a server with the same name will fail until the socket is removed (by default: /tmp/dillo-$USER-$SERVER_NAME). A solution is currently searched. The -c "exit()" works only when used from the client side The -c commands are currently ignored if no -s option is given. Any comments are welcome. Especially use cases for the remote control. 4. Details 4.1. Becoming a server Communication between server and client is done via UNIX domain socket. The advantage between this and FIFO being that a separate connection is made for each client, so communcation are guaranteed to not mixup. FIFO, on the other hand, can mixup communication of multiple clients if the messages are larger than some value (PIPE_BUF). This patch uses dynamic allocation for the messages received by the server. When the -s, --server NAME option is given, dillo checks wether a socket correspondig to that name is available and responding. If yes, it will hand any -c, --command CMD and any URL|FILE it finds in its command line options to that running server. URL|FILE are interpreted as "-c new-window(URL|FILE)". If no server socket is responding, it turns it self into a server by creating that socket. After that, it handles the -c, --command CMD and the URL|FILE options itself. 4.2. GUI initialisation The gtk_init() function is now called after dillo options parsing to speed up client execution. Indeed, a client instance does not need to initialise the GUI. This introduces the problem of messed up args if gtk args are given. This could affect the URL|FILE arguments. A solution would be to save them in a separate list for later processing. Another solution would be to interprete the URL|FILE arguments as -c open(URL|FILE) at an early stage. This will also help fixing the problem of the -c commands being ignored if no -s option is given. 4.3. Commands Commands are simple of the form: command(arg..). Arguments are parsed by the shell, so the user must take care that the command is interpreted as a single argument by the shell. Arguments should not contain unescaped parenthesis or spaces. Therefore, the following example is incorrect: dillo -s server -c open(file:///home/user/My documents) because: 1. the shell interprets the parenthesis, and 2. there is a space in the argument. This should be escaped in the following manner by using quotes: dillo -s server -c "open(file:///home/user/My documents)" It is easy to add new commands. -- Melvin Hadasht --3f35873e_710757d0_2c2 Content-Type: text/x-c; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="remote-control.patch" Index: src/dillo.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/dillo.c,v retrieving revision 1.49 diff -p -u -r1.49 dillo.c --- src/dillo.c 8 Aug 2003 20:28:04 -0000 1.49 +++ src/dillo.c 9 Aug 2003 23:31:48 -0000 =40=40 -33,6 +33,8 =40=40 =23include <sys/wait.h> =23include <ctype.h> =23include <locale.h> +=23include <sys/socket.h> +=23include <sys/un.h> =23include <config.h> =23include =22dillo.h=22 =40=40 -66,9 +68,33 =40=40 enum =7B DILLO=5FCLI=5FHELP =3D 1 << 3, DILLO=5FCLI=5FVERSION =3D 1 << 4, DILLO=5FCLI=5FLOCAL =3D 1 << 5, + DILLO=5FCLI=5FSERVER =3D 1 << 6, + DILLO=5FCLI=5FCOMMAND =3D 1 << 7, + DILLO=5FCLI=5FHELP=5FCOMMANDS =3D 1 << 8, DILLO=5FCLI=5FERROR =3D 1 << 31 =7D; +=23define REMOTE=5FCMD=5FBU=46=5FSIZE 1024 + +typedef struct =7B + size=5Ft len; + gchar *cmd; +=7D RemoteCmd; + +typedef struct =7B + gchar *server=5Fname; + gchar *socket=5Fname; + int socket=5Ffd; + gboolean is=5Fserver; + GSList *commands; +=7D RemoteControl; + +typedef struct =7B + gchar *name; + void (*function)(gchar *arg, gpointer data); + gpointer data; +=7D RemoteCmd=46unc; + enum =7B O=5FSEARCH, O=5F=46OUND, O=5FNOT=46OUND, O=5FOK, O=5FERROR, O=5FDONE =7D; =40=40 -81,6 +107,19 =40=40 static guint32 Dillo=5Fget=5Fopt(CLI=5Foption= s char **argv, char ***opt=5Farg, gint *idx);= static void Dillo=5Fprint=5Fhelp(CLI=5Foptions *options); static void Dillo=5Fprint=5Fversion(void); +static void Dillo=5Fprint=5Fhelp=5Fcommands(void); +static void Dillo=5Fremote=5Fcontrol=5Finit(RemoteControl *rc); +static void Dillo=5Fremote=5Fcontrol=5Ffree(RemoteControl *rc); +static gboolean Dillo=5Fcheck=5Fserver(RemoteControl *rc); +static void Dillo=5Fserver=5Fset=5Fsocket=5Fname(RemoteControl *rc); +static int Dillo=5Fclient=5Fsend=5Fcmd(RemoteControl *rc, gchar *command= ); +static void Dillo=5Fserver=5Fset=5Faccept=5Fhandler(RemoteControl *rc); +static gboolean Dillo=5Fserver=5Faccept=5Fcb(GIOChannel *channel, GIOCon= dition condition, gpointer data); +static gboolean Dillo=5Fserver=5Fread=5Fcb(GIOChannel *channel, GIOCondi= tion condition, gpointer data); +static void Dillo=5Fserver=5Fexecute=5Fremote=5Fcmd(RemoteCmd *remote=5F= cmd); +static void Dillo=5Fserver=5Fexecute=5Fcmd(gchar *cmd); +static void Dillo=5Fserver=5Fexecute=5Fopen(gchar *url, gpointer data); +static void Dillo=5Fserver=5Fexecute=5Fexit(gchar *arg, gpointer data); /* * Local data =40=40 -89,15 +128,24 =40=40 static CLI=5Foptions Options=5B=5D =3D =7B =7B=22-x=22, =22--xid=22, 1, DILLO=5FCLI=5FXID, =22 -x, --xid XID Open first Dillo window in an existing=5C= n=22 =22 GtkSocket which window ID is XID (decimal= ).=22=7D, + =7B=22-f=22, =22--fullwindow=22, 0, DILLO=5FCLI=5F=46ULLWINDOW, + =22 -f, --fullwindow Start in full window mode.=22=7D, + =7B=22-l=22, =22--local=22, 0, DILLO=5FCLI=5FLOCAL, + =22 -l, --local Don't follow links for this URL(s).=22=7D= , + =7B=22-s=22, =22--server=22, 1, DILLO=5FCLI=5FSERVER, + =22 -s, --server NAME Become server NAME or send commands and U= RLs=5Cn=22 + =22 to the server NAME.=22=7D, + =7B=22-c=22, =22--command=22, 1, DILLO=5FCLI=5FCOMMAND, + =22 -c, --command CMD Execute command CMD. See -H, --help-comm= and=5Cn=22 + =22 for the available commands.=22=7D, + =7B=22-H=22, =22--help-commands=22, 0, DILLO=5FCLI=5FHELP=5FCOMMANDS,= + =22 -H, --help-commands Display the list of known commands to be = used=5Cn=22 + =22 with -c, --command option=22=7D, =7B=22-v=22, =22--version=22, 0, DILLO=5FCLI=5FVERSION, =22 -v, --version Display version info and exit.=22=7D, =7B=22-h=22, =22--help=22, 0, DILLO=5FCLI=5FHELP, =22 -h, --help Display this help text and exit.=22=7D, - =7B=22-f=22, =22--fullwindow=22, 0, DILLO=5FCLI=5F=46ULLWINDOW, - =22 -f, --fullwindow Start in full window mode.=22=7D, - =7B=22-l=22, =22--local=22, 0, DILLO=5FCLI=5FLOCAL, - =22 -l, --local Don't follow links for this URL(s).=22=7D= , - =7BNULL, NULL, 0, 0, NULL=7D + =7BNULL, NULL, 0, 0, NULL=7D =7D; =40=40 -192,50 +240,53 =40=40 gint main(int argc, char *argv=5B=5D) gint idx =3D 0; guint opt=5Fflg; gint i; - char **opt=5Fargv =3D NULL; + gchar **opt=5Fargv =3D NULL; + RemoteControl rc; - /* set locale */ - curr=5Flocale =3D g=5Fstrdup(setlocale(LC=5FALL, NULL)); - gtk=5Fset=5Flocale(); - /* Initialize GUI and parse GTK related args */ - gtk=5Finit(&argc, &argv); - gdk=5Frgb=5Finit(); + Dillo=5Fremote=5Fcontrol=5Finit(&rc); /* Handle command line options */ while ((opt=5Fflg =3D Dillo=5Fget=5Fopt(Options, argc, argv, &opt=5Fa= rgv, &idx))) =7B - options=5Fgot =7C=3D opt=5Fflg; - switch (opt=5Fflg) =7B - case DILLO=5FCLI=5FVERSION: - Dillo=5Fprint=5Fversion(); - return 0; - break; - case DILLO=5FCLI=5FHELP: - Dillo=5Fprint=5Fhelp(Options); - return 0; - break; - case DILLO=5FCLI=5FXID: - if (opt=5Fargv=5B0=5D=5B0=5D >=3D '0' && opt=5Fargv=5B0=5D=5B0=5D= <=3D '9') =7B - xid =3D strtol(opt=5Fargv=5B0=5D, NULL, 10); - =7D else =7B - g=5Fprint(=22Error: the XID must be an unsigned decimal numer= ical =22 - =22value.=5CnThe offending value was: %s=5Cn=22, opt=5F= argv=5B0=5D); - return -1; - =7D - break; - case DILLO=5FCLI=5F=46ULLWINDOW: - case DILLO=5FCLI=5FLOCAL: - break; - default: - g=5Fprint(=22Error in command line options.=5Cn=22); - return -1; - break; - =7D + options=5Fgot =7C=3D opt=5Fflg; + switch (opt=5Fflg) =7B + case DILLO=5FCLI=5FVERSION: + Dillo=5Fprint=5Fversion(); + return 0; + break; + case DILLO=5FCLI=5FHELP: + Dillo=5Fprint=5Fhelp(Options); + return 0; + break; + case DILLO=5FCLI=5FXID: + if (opt=5Fargv=5B0=5D=5B0=5D >=3D '0' && opt=5Fargv=5B0=5D=5B0=5D= <=3D '9') =7B + xid =3D strtol(opt=5Fargv=5B0=5D, NULL, 10); + =7D else =7B + g=5Fprint(=22Error: the XID must be an unsigned decimal nume= rical =22 + =22value.=5CnThe offending value was: %s=5Cn=22, opt= =5Fargv=5B0=5D); + return -1; + =7D + break; + case DILLO=5FCLI=5F=46ULLWINDOW: + case DILLO=5FCLI=5FLOCAL: + break; + case DILLO=5FCLI=5FSERVER: + g=5Ffree(rc.server=5Fname); + rc.server=5Fname =3D g=5Fstrdup(opt=5Fargv=5B0=5D); + break; + case DILLO=5FCLI=5FCOMMAND: + rc.commands =3D + g=5Fslist=5Fappend(rc.commands, g=5Fstrdup(opt=5Fargv=5B0=5D= )); + break; + case DILLO=5FCLI=5FHELP=5FCOMMANDS: + Dillo=5Fprint=5Fhelp=5Fcommands(); + return 0; + default: + g=5Fprint(=22Error in command line options.=5Cn=22); + return -1; + break; + =7D =7D - /* Send a delayed locale-related message */ - g=5Fprint(=22Setting locale to %s...=5Cn=22, curr=5Flocale); - g=5Ffree(curr=5Flocale); - /* This lets threads in the file module end peacefully when aborted * todo: implement a cleaner mechanism (in file.c) */ signal(SIGPIPE, SIG=5FIGN); =40=40 -250,6 +301,44 =40=40 gint main(int argc, char *argv=5B=5D) g=5Ffree(dir); a=5FPrefs=5Finit(); + + /* If requested, send commands to a running server, if it exists */ + if (rc.server=5Fname) =7B + if (Dillo=5Fcheck=5Fserver(&rc) && =21rc.is=5Fserver) =7B + GSList *iter; + gchar *command; + int err =3D 0; + + for (iter =3D rc.commands; + iter && err =3D=3D 0; iter =3D iter->next) =7B + command =3D (gchar *) iter->data; + err =3D Dillo=5Fclient=5Fsend=5Fcmd(&rc, command); + g=5Ffree(command); + =7D + g=5Fslist=5Ffree(rc.commands); + + for (i =3D idx; i < argc && err =3D=3D 0; i++) =7B + command =3D g=5Fstrdup=5Fprintf(=22new-window(%s)=22, argv=5B= i=5D); + err =3D Dillo=5Fclient=5Fsend=5Fcmd(&rc, command); + g=5Ffree(command); + =7D + close(rc.socket=5Ffd); + return err; + =7D + =7D + + /* set locale */ + curr=5Flocale =3D g=5Fstrdup(setlocale(LC=5FALL, NULL)); + + gtk=5Fset=5Flocale(); + /* Initialize GUI and parse GTK related args */ + gtk=5Finit(&argc, &argv); + gdk=5Frgb=5Finit(); + + /* Send a delayed locale-related message */ + g=5Fprint(=22Setting locale to %s...=5Cn=22, curr=5Flocale); + g=5Ffree(curr=5Flocale); + a=5FDns=5Finit(); a=5FHttp=5Finit(); a=5FMime=5Finit(); =40=40 -274,6 +363,18 =40=40 gint main(int argc, char *argv=5B=5D) a=5FNav=5Fpush(bw, start=5Furl); a=5FUrl=5Ffree(start=5Furl); + /* Handle the -c commands */ + if (rc.server=5Fname && rc.is=5Fserver) =7B + GSList *iter; + gchar *command; + for (iter =3D rc.commands; iter; iter =3D iter->next) =7B + command =3D (gchar *) iter->data; + Dillo=5Fserver=5Fexecute=5Fcmd(command); + g=5Ffree(command); + =7D + g=5Fslist=5Ffree(rc.commands); + =7D + for (i =3D idx; i < argc; i++) =7B /* If more than one URL/=46ILE, open in new window */ if (i > idx) =40=40 -286,6 +387,11 =40=40 gint main(int argc, char *argv=5B=5D) a=5FUrl=5Ffree(start=5Furl); =7D + /* Set the IO handler for clients connections */ + if (rc.server=5Fname && rc.is=5Fserver) =7B + Dillo=5Fserver=5Fset=5Faccept=5Fhandler(&rc); + =7D + /* Start the GTK+ cycle */ gtk=5Fmain(); =40=40 -294,6 +400,7 =40=40 gint main(int argc, char *argv=5B=5D) * (This can be left to the OS, but we'll do it, with a view to test * and fix our memory management) */ + Dillo=5Fremote=5Fcontrol=5Ffree(&rc); a=5FCookies=5Ffreeall(); a=5FCache=5Ffreeall(); a=5FDicache=5Ffreeall(); =40=40 -303,6 +410,8 =40=40 gint main(int argc, char *argv=5B=5D) a=5FDw=5Ffreeall(); a=5FHistory=5Ffree(); + + g=5Fprint(=22Dillo: normal exit=21=5Cn=22); return 0; =7D =40=40 -335,7 +444,7 =40=40 static void Dillo=5Fcheck=5Fhome=5Fdir(char *= d */ static guint32 Dillo=5Fget=5Fopt(CLI=5Foptions *options, int argc, - char **argv, char ***opt=5Fargv, gint *cli=5Fidx) + char **argv, gchar ***opt=5Fargv, gint *cli=5Fidx) =7B gint i =3D 0, opt=5Fflg =3D 0, n=5Farg, state; static int idx =3D 1; =40=40 -425,4 +534,264 =40=40 static void Dillo=5Fprint=5Fhelp(CLI=5Fopti= ons static void Dillo=5Fprint=5Fversion(void) =7B g=5Fprint(=22Dillo %s=5Cn=22, VERSION); +=7D + +/* + * Print the list of known commands to be used with the -c, --command op= tion + */ +static void Dillo=5Fprint=5Fhelp=5Fcommands(void) +=7B + g=5Fprint(=22Commands that can be used with the -c, --command option:= =5Cn=5Cn=22); + g=5Fprint(=22open(URL) Open URL in current window.=5Cn=22= ); + g=5Fprint(=22new-window(URL) Open URL in a new window.=5Cn=22= ); + g=5Fprint(=22Exit() Terminate browsing session and e= xit.=5Cn=22); + g=5Fprint(=22=5CnCommand names are case insensitive.=5Cn=22); + g=5Fprint(=22It is allowed to have more than one command option.=5Cn=22= ); +=7D + +static void Dillo=5Fremote=5Fcontrol=5Finit(RemoteControl *rc) +=7B + rc->server=5Fname =3D NULL; + rc->socket=5Fname =3D NULL; + rc->socket=5Ffd =3D -1; + rc->is=5Fserver =3D 0; + rc->commands =3D NULL; +=7D + +static void Dillo=5Fremote=5Fcontrol=5Ffree(RemoteControl *rc) +=7B + close(rc->socket=5Ffd); + unlink(rc->socket=5Fname); + g=5Ffree(rc->server=5Fname); + g=5Ffree(rc->socket=5Fname); +=7D + +/* + * Attempt to connect to a running server. + * Return value: file descriptor of the connection, or -1 if no server f= ound + */ +static gboolean Dillo=5Fcheck=5Fserver(RemoteControl *rc) +=7B + struct sockaddr=5Fun serv=5Faddr; + gboolean is=5Fok =3D =46ALSE; + + rc->is=5Fserver =3D =46ALSE; + rc->socket=5Ffd =3D socket(P=46=5FLOCAL, SOCK=5FSTREAM, 0); + if (rc->socket=5Ffd =3D=3D -1) =7B + perror(=22socket=22); + return =46ALSE; + =7D + + Dillo=5Fserver=5Fset=5Fsocket=5Fname(rc); + + memset((char *) &serv=5Faddr, 0, sizeof(serv=5Faddr)); + serv=5Faddr.sun=5Ffamily =3D A=46=5FLOCAL; + strncpy(serv=5Faddr.sun=5Fpath, rc->socket=5Fname, sizeof(serv=5Faddr= .sun=5Fpath)); + + /* Connect to a possibly existing socket or become a server */ + + if (connect(rc->socket=5Ffd, (struct sockaddr *) &serv=5Faddr, + sizeof(serv=5Faddr)) =3D=3D 0) =7B + is=5Fok =3D TRUE; + =7D else =7B + + /* Do not report =22=46ile not found=22 error */ + + if (errno =21=3D ENOENT) =7B + perror(=22connect=22); + unlink(rc->server=5Fname); + =7D + close(rc->socket=5Ffd); + + /* Try to become a server */ + + rc->socket=5Ffd =3D socket(P=46=5FLOCAL, SOCK=5FSTREAM, 0); + + if (rc->socket=5Ffd =3D=3D -1) =7B + perror(=22socket=22); + =7D else if (bind(rc->socket=5Ffd, (struct sockaddr *) &serv=5Fadd= r, + sizeof(serv=5Faddr)) =3D=3D -1) =7B + perror(=22bind=22); + =7D else if (listen(rc->socket=5Ffd, 5) =3D=3D -1) =7B + perror(=22listen=22); + =7D else =7B + g=5Fprint(=22Dillo server %s started and listening to %s=5Cn=22= , + rc->server=5Fname, rc->socket=5Fname); + rc->is=5Fserver =3D TRUE; + is=5Fok =3D TRUE; + =7D + =7D + + if (is=5Fok =3D=3D =46ALSE) =7B + g=5Ffree(rc->socket=5Fname); + rc->socket=5Fname =3D NULL; + =7D + + return is=5Fok; +=7D + +static void Dillo=5Fserver=5Fset=5Fsocket=5Fname(RemoteControl *rc) +=7B + gchar *user=5Fname; + + user=5Fname =3D g=5Fget=5Fuser=5Fname(); + rc->socket=5Fname =3D g=5Fstrdup=5Fprintf(=22%s/dillo-%s-%s=22, prefs= .server=5Fsocket=5Fpath, + user=5Fname, rc->server=5Fname); + g=5Ffree(user=5Fname); +=7D + +static int Dillo=5Fclient=5Fsend=5Fcmd(RemoteControl *rc, gchar *command= ) +=7B + size=5Ft count =3D 0; + size=5Ft len =3D strlen(command) + 1; /* Include terminating NULL cha= racter */ + ssize=5Ft n =3D 0; + + while (count < len && n >=3D 0) =7B + n =3D write(rc->socket=5Ffd, command + count, len - count); + if (n >=3D 0) + count +=3D n; + =7D + + if (n < 0) =7B + perror(=22write=22); + return -1; + =7D + + return 0; +=7D + +static void Dillo=5Fserver=5Fset=5Faccept=5Fhandler(RemoteControl *rc) +=7B + GIOChannel *accept=5Fchannel; + + accept=5Fchannel =3D g=5Fio=5Fchannel=5Funix=5Fnew(rc->socket=5Ffd); + g=5Fio=5Fadd=5Fwatch(accept=5Fchannel, G=5FIO=5FIN =7C G=5FIO=5FPRI =7C= G=5FIO=5FHUP, + Dillo=5Fserver=5Faccept=5Fcb, NULL); +=7D + +static gboolean Dillo=5Fserver=5Faccept=5Fcb(GIOChannel *channel, GIOCon= dition condition, gpointer data) +=7B + int socket=5Ffd; + int client=5Ffd; + struct sockaddr addr; + socklen=5Ft addrlen; + GIOChannel *client=5Fchannel; + RemoteCmd *remote=5Fcmd; + + socket=5Ffd =3D g=5Fio=5Fchannel=5Funix=5Fget=5Ffd(channel); + if (condition & G=5FIO=5FHUP) =7B + g=5Fio=5Fchannel=5Fclose(channel); + g=5Fio=5Fchannel=5Funref(channel); + return =46ALSE; + =7D + + if ((client=5Ffd =3D accept(socket=5Ffd, &addr, &addrlen)) =3D=3D -1)= =7B + perror(=22accept=22); + return TRUE; + =7D + + remote=5Fcmd =3D g=5Fnew(RemoteCmd, 1); + remote=5Fcmd->cmd =3D NULL; + remote=5Fcmd->len =3D 0; + + client=5Fchannel =3D g=5Fio=5Fchannel=5Funix=5Fnew(client=5Ffd); + g=5Fio=5Fadd=5Fwatch(client=5Fchannel, G=5FIO=5FIN =7C G=5FIO=5FPRI =7C= G=5FIO=5FHUP, + Dillo=5Fserver=5Fread=5Fcb, remote=5Fcmd); + + return TRUE; +=7D + +static gboolean Dillo=5Fserver=5Fread=5Fcb(GIOChannel *channel, + GIOCondition condition, + gpointer data) +=7B + gchar buf=5BREMOTE=5FCMD=5FBU=46=5FSIZE=5D; + RemoteCmd *remote=5Fcmd =3D (RemoteCmd *) data; + guint bytes=5Fread =3D 0; + + g=5Fio=5Fchannel=5Fread(channel, buf, sizeof(buf), &bytes=5Fread); + + if (bytes=5Fread > 0) =7B + remote=5Fcmd->cmd =3D g=5Frealloc(remote=5Fcmd->cmd, + remote=5Fcmd->len + bytes=5Fread); + memcpy(remote=5Fcmd->cmd + remote=5Fcmd->len, buf, bytes=5Fread); + remote=5Fcmd->len +=3D bytes=5Fread; + =7D + + if (remote=5Fcmd->len && remote=5Fcmd->cmd=5Bremote=5Fcmd->len - 1=5D= =3D=3D 0x00) + Dillo=5Fserver=5Fexecute=5Fremote=5Fcmd(remote=5Fcmd); + + if (condition & G=5FIO=5FHUP) =7B + g=5Fio=5Fchannel=5Fclose(channel); + g=5Fio=5Fchannel=5Funref(channel); + g=5Ffree(remote=5Fcmd->cmd); + g=5Ffree(remote=5Fcmd); + return =46ALSE; + =7D + + return TRUE; +=7D + +static void Dillo=5Fserver=5Fexecute=5Fremote=5Fcmd(RemoteCmd *remote=5F= cmd) +=7B + size=5Ft i =3D 0; + gchar *cmd; + + while (i < remote=5Fcmd->len && remote=5Fcmd->cmd=5Bi=5D) =7B + cmd =3D remote=5Fcmd->cmd + i; + i +=3D strlen(cmd) + 1; + Dillo=5Fserver=5Fexecute=5Fcmd(cmd); + =7D + + g=5Ffree(remote=5Fcmd->cmd); + remote=5Fcmd->cmd =3D NULL; + remote=5Fcmd->len =3D 0; +=7D + +static void Dillo=5Fserver=5Fexecute=5Fcmd(gchar *cmd) +=7B + gchar *tmp; + gchar *arg; + RemoteCmd=46unc command=5B=5D =3D =7B + =7B =22open(=22, Dillo=5Fserver=5Fexecute=5Fopen, GINT=5FTO=5F= POINTER(=46ALSE)=7D, + =7B =22new-window(=22, Dillo=5Fserver=5Fexecute=5Fopen, GINT=5FTO=5F= POINTER(TRUE)=7D, + =7B =22exit(=22, Dillo=5Fserver=5Fexecute=5Fexit, NULL=7D=7D= ; + int i; + + for (i =3D 0; i < sizeof(command)/sizeof(command=5B0=5D); i++) =7B + if (g=5Fstrncasecmp(cmd, command=5Bi=5D.name, strlen(command=5Bi=5D= .name)) =3D=3D 0) =7B + if ((tmp =3D strrchr(cmd, ')')) =3D=3D NULL =7C=7C tmp=5B1=5D =21= =3D 0x00) =7B + g=5Fprint(=22Missing closing parenthesis in command %s=5Cn=22= , cmd); + return; + =7D + cmd +=3D strlen(command=5Bi=5D.name); + arg =3D g=5Fstrndup(cmd, tmp - cmd); + command=5Bi=5D.function(arg, command=5Bi=5D.data); + g=5Ffree(arg); + return; + =7D + =7D + + g=5Fprint(=22Ignoring unknown command %s.=5Cn=22, cmd); +=7D + +static void Dillo=5Fserver=5Fexecute=5Fopen(gchar *url, gpointer data) +=7B + BrowserWindow *bw; + DilloUrl *start=5Furl; + gboolean new=5Fwindow =3D GPOINTER=5FTO=5FINT(data); + + if (new=5Fwindow) + bw =3D a=5FInterface=5Fbrowser=5Fwindow=5Fnew(prefs.width, prefs.h= eight, 0); + else + bw =3D a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow(); + + start=5Furl =3D Dillo=5Fmake=5Fstart=5Furl(url); + a=5FNav=5Fpush(bw, start=5Furl); + a=5FUrl=5Ffree(start=5Furl); +=7D + +static void Dillo=5Fserver=5Fexecute=5Fexit(gchar *arg, gpointer data) +=7B + a=5FInterface=5Fquit=5Fall(); =7D Index: src/interface.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/interface.c,v retrieving revision 1.75 diff -p -u -r1.75 interface.c --- src/interface.c 8 Aug 2003 20:28:04 -0000 1.75 +++ src/interface.c 9 Aug 2003 23:31:48 -0000 =40=40 -899,6 +899,16 =40=40 a=5FInterface=5Fbrowser=5Fwindow=5Fnew(gint = widt =7D /* + * Return the first window + * (browser=5Fwindow=5B0=5D) + */ +BrowserWindow * +a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow(void) +=7B + return browser=5Fwindow=5B0=5D; +=7D + +/* * Set the title of the browser window to start with =22Dillo: =22 * prepended to it. */ Index: src/interface.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/interface.h,v retrieving revision 1.28 diff -p -u -r1.28 interface.h --- src/interface.h 1 =46eb 2003 12:35:57 -0000 1.28 +++ src/interface.h 9 Aug 2003 23:31:48 -0000 =40=40 -31,6 +31,10 =40=40 void a=5FInterface=5Fset=5Fcursor(BrowserWindo= BrowserWindow * a=5FInterface=5Fbrowser=5Fwindow=5Fnew(gint width, gint height, guint32 = xid); +BrowserWindow * +a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow(void); + + void a=5FInterface=5Fset=5Fbutton=5Fsens(BrowserWindow *bw); void a=5FInterface=5Fscroll=5Fpopup(GtkWidget *widget); Index: src/prefs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/prefs.c,v retrieving revision 1.42 diff -p -u -r1.42 prefs.c --- src/prefs.c 3 Apr 2003 16:48:15 -0000 1.42 +++ src/prefs.c 9 Aug 2003 23:31:48 -0000 =40=40 -68,7 +68,8 =40=40 static const struct =7B =7B =22vw=5Ffontname=22, DRC=5FTOKEN=5FVW=5F=46ONT =7D, =7B =22fw=5Ffontname=22, DRC=5FTOKEN=5F=46W=5F=46ONT =7D, =7B =22generate=5Fsubmit=22, DRC=5FTOKEN=5FGENERATE=5FSUBMIT =7D, - =7B =22enterpress=5Fforces=5Fsubmit=22, DRC=5FTOKEN=5FENTERPRESS=5F=46= ORCES=5FSUBMIT =7D + =7B =22enterpress=5Fforces=5Fsubmit=22, DRC=5FTOKEN=5FENTERPRESS=5F=46= ORCES=5FSUBMIT =7D, + =7B =22server=5Fsocket=5Fpath=22, DRC=5FTOKEN=5FSERVER=5FSOCKET=5FPAT= H =7D =7D; static const guint n=5Fsymbols =3D sizeof (symbols) / sizeof (symbols=5B= 0=5D); =40=40 -233,6 +234,10 =40=40 static guint Prefs=5Fparser(GScanner *scan prefs.enterpress=5Fforces=5Fsubmit =3D (strcmp(scanner->value.v=5Fstring, =22YES=22) =3D=3D 0); break; + case DRC=5FTOKEN=5FSERVER=5FSOCKET=5FPATH: + g=5Ffree(prefs.server=5Fsocket=5Fpath); + prefs.server=5Fsocket=5Fpath =3D g=5Fstrdup(scanner->value.v=5Fstr= ing); + break; default: break; /* Not reached */ =7D =40=40 -364,6 +369,7 =40=40 void a=5FPrefs=5Finit(void) prefs.fw=5Ffontname =3D g=5Fstrdup(=22courier=22); prefs.generate=5Fsubmit =3D =46ALSE; prefs.enterpress=5Fforces=5Fsubmit =3D =46ALSE; + prefs.server=5Fsocket=5Fpath =3D g=5Fstrdup(=22/tmp=22); /* this locale stuff is to avoid parsing problems with float numbers = */ old=5Flocale =3D g=5Fstrdup (setlocale (LC=5FNUMERIC, NULL)); =40=40 -387,5 +393,6 =40=40 void a=5FPrefs=5Ffreeall(void) a=5FUrl=5Ffree(prefs.http=5Fproxy); g=5Ffree(prefs.fw=5Ffontname); g=5Ffree(prefs.vw=5Ffontname); + g=5Ffree(prefs.server=5Fsocket=5Fpath); a=5FUrl=5Ffree(prefs.home); =7D Index: src/prefs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/prefs.h,v retrieving revision 1.24 diff -p -u -r1.24 prefs.h --- src/prefs.h 9 Jul 2003 22:24:20 -0000 1.24 +++ src/prefs.h 9 Aug 2003 23:31:48 -0000 =40=40 -61,6 +61,7 =40=40 typedef enum =7B DRC=5FTOKEN=5FVW=5F=46ONT, DRC=5FTOKEN=5FGENERATE=5FSUBMIT, DRC=5FTOKEN=5FENTERPRESS=5F=46ORCES=5FSUBMIT, + DRC=5FTOKEN=5FSERVER=5FSOCKET=5FPATH, DRC=5FTOKEN=5FLAST =7D Dillo=5FRc=5FTokenType; =40=40 -105,6 +106,7 =40=40 struct =5FDilloPrefs =7B gchar *fw=5Ffontname; gboolean generate=5Fsubmit; gboolean enterpress=5Fforces=5Fsubmit; + gchar *server=5Fsocket=5Fpath; =7D; /* Global Data */ --3f35873e_710757d0_2c2-- From tomas@fabula.de Sun Aug 10 06:47:14 2003 From: tomas@fabula.de (tomas@fabula.de) Date: Sun, 10 Aug 2003 07:47:14 +0200 Subject: [Dillo-dev] [patch] Remote Control In-Reply-To: <etPan.3f357834.6181ef69.2c2@freefluid> References: <etPan.3f357834.6181ef69.2c2@freefluid> Message-ID: <20030810054714.GA3030@www> On Sun, Aug 10, 2003 at 12:39:48AM +0200, Melvin Hadasht wrote: > Hi, > > I just made a patch to add remote control for Dillo. > Terrific! Here are some comments for discussion. Take them with a grain of salt: - I'd prefer case sensitivity (the unixy environment is case sensitive, URIs are -- at least in part :-/ You know, principle of least surprise and that. - Implementation. Why not implement this as a wrapper which talks to the dpid? It would start Dillo if not already running. The advantages I see are: - the wrapper could clean up any mess Dillo might leave behind on a crash. This is one of the open issues you mention. (OK, Dillo doesn't crash, does it? but a simple wrapper is less complex and thus less likely to crash). - You could re-use the existing communication mechanism for dpi1, I think (I haven't looked deeply into this yet, though). The main disadvantage would be, of course, that you have to start dillo-wrapper instead of dillo, but may be we can convince folks in the list that this ie a Good Thing anyway (it would solve elegantly the `single dpid instance' issue, since it could look whether dpid is running before starting dillo). What do people think? Regards -- tomas From melvin.hadasht@free.fr Sun Aug 10 08:47:42 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Sun, 10 Aug 2003 09:47:42 +0200 Subject: [Dillo-dev] [patch] Remote Control In-Reply-To: <20030810054714.GA3030@www> References: <etPan.3f357834.6181ef69.2c2@freefluid> <20030810054714.GA3030@www> Message-ID: <etPan.3f35f89e.6b68079a.2b1@freefluid> Hi Tomas, You wrote: > Here are some comments for discussion. Take them with a grain > of salt: > > - I'd prefer case sensitivity (the unixy environment is case > sensitive, URIs are -- at least in part :-/ > You know, principle of least surprise and that. At first, I planned to implement mozilla-like options (which are documented as OpenURL but they are case insensitive: openurl works, too). Unix people are used to case sensitiveness, so I could switch to that, especially that there is no port to MSWindows or other case insensitive platform, yet (I have a doubt concerning VMS, though). > - Implementation. Why not implement this as a wrapper which > talks to the dpid? It would start Dillo if not already running. > > The advantages I see are: > > - the wrapper could clean up any mess Dillo might leave behind > on a crash. This is one of the open issues you mention. > (OK, Dillo doesn't crash, does it? but a simple wrapper > is less complex and thus less likely to crash). nedit comes with a small "nc" nedit-client that does something similar: if no server exist, it forks one. So you can live with just the "nc" command. I'll read more about the dpi stuff and will think about how it could be used. Thanks for your comments! -- Melvin Hadasht From dontodd@columbus.rr.com Sun Aug 10 15:21:30 2003 From: dontodd@columbus.rr.com (Todd Slater) Date: Sun, 10 Aug 2003 10:21:30 -0400 Subject: [Dillo-dev] focus on start Message-ID: <20030810142130.GA2444@clevername.homeip.net> When I launch Dillo, the content part of the window is not focused so I have to click on the content to focus it and then I can page through it using the keyboard. Is that intentional, and is there a way I can make it start with the content part focused so I can immediately start scrolling through a page? Thanks, Todd From amentia@hotpop.com Sun Aug 10 17:04:37 2003 From: amentia@hotpop.com (mattias/spikboll) Date: Sun, 10 Aug 2003 18:04:37 +0200 Subject: [Dillo-dev] focus on start In-Reply-To: <20030810142130.GA2444@clevername.homeip.net> References: <20030810142130.GA2444@clevername.homeip.net> Message-ID: <20030810180437.4a34044a.amentia@hotpop.com> On Sun, 10 Aug 2003 10:21:30 -0400 Todd Slater <dontodd@columbus.rr.com> wr= ote: > When I launch Dillo, the content part of the window is not focused so I > have to click on the content to focus it and then I can page through it > using the keyboard. Is that intentional, and is there a way I can make > it start with the content part focused so I can immediately start > scrolling through a page?=20 No need to click. Just press Tab, and you're set to go. /Mattias --=20 mattias =F6stergren | /"\ compsci student | \ / ASCII Ribbon Campaign g=E4vle, sweden | X No HTML in e-mail http://spikboll.net | / \ =20 From jahumada@usgs.gov Mon Aug 11 23:32:59 2003 From: jahumada@usgs.gov (Jorge A Ahumada) Date: Mon, 11 Aug 2003 17:32:59 -0500 Subject: [Dillo-dev] can dillo be silent? Message-ID: <C2CBA626-CC4B-11D7-BFEB-000393DEDD9C@usgs.gov> I love dillo and use it as my default browser when using help pages in R. However, everything I invoke the help dillo returns several messages clogging my R prompt...Is there any way to run dillo in 'silent' mode? thx, Jorge From jahumada@usgs.gov Mon Aug 11 23:47:49 2003 From: jahumada@usgs.gov (Jorge A Ahumada) Date: Mon, 11 Aug 2003 17:47:49 -0500 Subject: [Dillo-dev] silent dillo? revised Message-ID: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> I love dillo and use it as my default browser when using help pages in R. However, every time I invoke the help in R, dillo returns several messages clogging my R prompt...Is there any way to run dillo in 'silent' mode? thx, Jorge From Andreas.Schweitzer@hs.uni-hamburg.de Tue Aug 12 00:00:40 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Tue, 12 Aug 2003 01:00:40 +0200 Subject: [Dillo-dev] silent dillo? revised In-Reply-To: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> References: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> Message-ID: <20030811230040.GB99054@hs.uni-hamburg.de> On Mon, Aug 11, 2003 at 05:47:49PM -0500, Jorge A Ahumada wrote: > I love dillo and use it as my default browser when using help pages in > R. However, every time I invoke the help in R, dillo returns several > messages clogging my R prompt...Is there any way to run dillo in > 'silent' mode? You can lower the debug level. Search for DEBUG_LEVEL in the source and remove all occurences. That should remove a number of messages. If you know your way around you can try http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/ and look at the various patches. Most of them silence dillo, but some serve different purposes. Also, they are against 0.7.2 (at least right now), so double check. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From ivop@euronet.nl Tue Aug 12 01:55:55 2003 From: ivop@euronet.nl (Ivo) Date: Tue, 12 Aug 2003 02:55:55 +0200 Subject: [Dillo-dev] silent dillo? revised In-Reply-To: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> References: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> Message-ID: <200308120255.55962.ivop@euronet.nl> On Tuesday 12 August 2003 00:47, Jorge A Ahumada wrote: > I love dillo and use it as my default browser when using help pages in > R. However, every time I invoke the help in R, dillo returns several > messages clogging my R prompt...Is there any way to run dillo in > 'silent' mode? I don't know what you mean by 'R' and if you're running *nix, but if you are, can't you use a small wrapper script that simply redirects stderr and stdout to /dev/null ? I use that all the time, for example, while running mencoder from a cronjob. --Ivo From Andreas.Schweitzer@hs.uni-hamburg.de Tue Aug 12 09:02:36 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Tue, 12 Aug 2003 10:02:36 +0200 Subject: [Dillo-dev] silent dillo? revised In-Reply-To: <20030811230040.GB99054@hs.uni-hamburg.de> <200308120255.55962.ivop@euronet.nl> References: <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> <20030811230040.GB99054@hs.uni-hamburg.de> <D526F1E8-CC4D-11D7-BFEB-000393DEDD9C@usgs.gov> <200308120255.55962.ivop@euronet.nl> Message-ID: <20030812080236.GC17077@hs.uni-hamburg.de> On Tue, Aug 12, 2003 at 02:55:55AM +0200, Ivo wrote: > I don't know what you mean by 'R' and if you're running *nix, but if you I was bold and typed R into google, and the first hit I got was what I suspected he is running :-) > are, can't you use a small wrapper script that simply redirects stderr and > stdout to /dev/null ? I use that all the time, for example, while running > mencoder from a cronjob. That's of course easier than my solution :-) And now I have to correct myself .... On Tue, Aug 12, 2003 at 01:00:40AM +0200, Andreas Schweitzer wrote: > You can lower the debug level. Search for DEBUG_LEVEL in the source > and remove all occurences. That should remove a number of messages. That is of course "#define DEBUG_LEVEL" ONLY, not the ifdef's .... silly me ... Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From wdtrenker@yahoo.ca Tue Aug 12 10:37:09 2003 From: wdtrenker@yahoo.ca (William Trenker) Date: Tue, 12 Aug 2003 09:37:09 +0000 Subject: [Dillo-dev] Installation Problem Message-ID: <oprtscz7r4mmesbb@mail.silk.net> I'm getting the following error when installing Dillo. /packages# rpm -Uvh dillo-0.7.3-1.rh7.i386.rpm error: failed dependencies: libpng.so.2 is needed by dillo-0.7.3-1 /packages# l /usr/lib/libpng.so.2 lrwxrwxrwx 1 root root 17 May 5 21:05 /usr/lib/libpng.so.2 -> libpng.so.3.1.2.1* I'm not sure what my next step should be. I'm wondering why libpng.so.2 is linked to a file called libpng.so.3? Do you think I should try and find an RPM for the libpng.so.2 library and reinstall that? Where do you think I would find such an RPM? I have had problems with web pages that have PNG's in them ever since Dillo 7.2 but everything was fine with Dillo 7.1 so I'm not sure what I should do. Thank you for any help you can offer. Bill -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From kelson@pobox.com Tue Aug 12 18:10:37 2003 From: kelson@pobox.com (Kelson Vibber) Date: Tue, 12 Aug 2003 10:10:37 -0700 Subject: [Dillo-dev] Installation Problem (RPM) In-Reply-To: <oprtscz7r4mmesbb@mail.silk.net> Message-ID: <5.2.1.1.0.20030812095351.01d72210@mail.speed.net> At 02:37 AM 8/12/2003, William Trenker wrote: >I'm getting the following error when installing Dillo. > >/packages# rpm -Uvh dillo-0.7.3-1.rh7.i386.rpm error: failed dependencies: > libpng.so.2 is needed by dillo-0.7.3-1 >/packages# l /usr/lib/libpng.so.2 >lrwxrwxrwx 1 root root 17 May 5 21:05 >/usr/lib/libpng.so.2 -> libpng.so.3.1.2.1* Several questions: 1. What exact version of Linux are you using? 2. What version is reported by "rpm -qi libpng"? 3. Is your system up to date with all the current errata packages? (up2date or Ximian Red Carpet can help) 4. Have you manually upgraded libpng, or installed it from a source other than Red Hat? I'm going to hazard a couple of guesses: 1. If you are using Red Hat 7.something, you have probably upgraded libpng from some other source. In this case, download the .src.rpm and run "rpmbuild --rebuild dillo-0.7.3-1.src.rpm" as described on the RPM download page. 2. If you are using Red Hat 8 or 9, or another distribution that is listed on the RPM page, download the appropriate RPM instead. 3. If you are using another Linux distribution that is *not* listed, try the closest one that is (i.e. if you have Mandrake 9.0, the Mandrake 9.1 RPM might work) and, failing that, download the .src.rpm and install that as described above. Kelson Vibber www.hyperborea.org From paka@MyRealBox.com Tue Aug 12 18:33:18 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Tue, 12 Aug 2003 12:33:18 -0500 Subject: [Dillo-dev] Installation Problem (RPM) In-Reply-To: <5.2.1.1.0.20030812095351.01d72210@mail.speed.net> References: <oprtscz7r4mmesbb@mail.silk.net> <5.2.1.1.0.20030812095351.01d72210@mail.speed.net> Message-ID: <20030812173318.GK10143@wahoo.no-ip.org> * Kelson Vibber <kelson@pobox.com> [08-12-03 12:11]: > At 02:37 AM 8/12/2003, William Trenker wrote: > >I'm getting the following error when installing Dillo. > > > >/packages# rpm -Uvh dillo-0.7.3-1.rh7.i386.rpm error: failed dependencies: > > libpng.so.2 is needed by dillo-0.7.3-1 > >/packages# l /usr/lib/libpng.so.2 > >lrwxrwxrwx 1 root root 17 May 5 21:05 > >/usr/lib/libpng.so.2 -> libpng.so.3.1.2.1* > > Several questions: > > 1. What exact version of Linux are you using? > > 2. What version is reported by "rpm -qi libpng"? > > 3. Is your system up to date with all the current errata packages? > (up2date or Ximian Red Carpet can help) > > 4. Have you manually upgraded libpng, or installed it from a source > other than Red Hat? > > I'm going to hazard a couple of guesses: 1. If you are using Red Hat > 7.something, you have probably upgraded libpng from some other > source. In this case, download the .src.rpm and run "rpmbuild > --rebuild dillo-0.7.3-1.src.rpm" as described on the RPM download > page. > > 2. If you are using Red Hat 8 or 9, or another distribution that is > listed on the RPM page, download the appropriate RPM instead. > > 3. If you are using another Linux distribution that is *not* listed, > try the closest one that is (i.e. if you have Mandrake 9.0, the > Mandrake 9.1 RPM might work) and, failing that, download the .src.rpm > and install that as described above. Is this related to the install problems that I had with SuSE 8.1 and applied the config.patch ?? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From akemnade@informatik.uni-bremen.de Tue Aug 12 19:57:05 2003 From: akemnade@informatik.uni-bremen.de (Andreas Kemnade) Date: Tue, 12 Aug 2003 20:57:05 +0200 Subject: [Dillo-dev] Recovering health. In-Reply-To: <Pine.LNX.4.53.0307311307340.939@infinity.cl> References: <Pine.LNX.4.53.0307311307340.939@infinity.cl> Message-ID: <20030812205705.45c48cc9.akemnade@informatik.uni-bremen.de> On Thu, 31 Jul 2003 13:21:46 -0400 (CLT) Jorge Arellano Cid <jcid@softhome.net> wrote: > > Ah, and I received a couple of SPAM rejection notes from > external servers for SPAM delivered by our list. Is it possible > to hook SpamAssassin to dillo-dev so it filters out SPAM? > Sorry, I have not read this list intensively in the last days. I'll try to let spamassassin filter dillo-dev. Some problems I have: What to do with the spam? Drop it silently or store it into a world-readable file so you can have a look at it? The other thing is: The mailinglist alias file is auto-generated so if I change that to run spamassassin and then pipe it to mailman, the change will be deleted by the daily cronjob. So I have to do a bit of bash scripting. Greetings Andreas Kemnade (andi@auriga.wearlab.de) From dmckee@jlab.org Tue Aug 12 21:33:43 2003 From: dmckee@jlab.org (David McKee) Date: Tue, 12 Aug 2003 16:33:43 -0400 (EDT) Subject: [Dillo-dev] libc dependency in 0.8.0pre (bug 487) Message-ID: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> Folks, Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I like what I see. When I tried to do the same at work today (Redhat 6.2), I had problems building. Dpid uses mkdtemp() which was introduced in glibc 2.1.9. However, ./configure has no problems with my glibc 2.1.3. Submitted as bug 487. This constitutes a change from the 0.7 days when (according to the Compatibility web page) any glibc2 would do. Introducing (by hand) a definition of mkdtemp() I found on the web solved all my problems. Browsing the source suggests that you are not in the habit of carrying around lot of little libc bits---and the associated preprocessor code munging---for systems with variant or insufficient libc's. That is fine. It keeps the code base small and simple, but perhaps ./configure should look out for these things. So does this mean some previously working libc's are now going to be excluded, that more conditional compilation stuff will need to go in, or that dpid needs some work to increase it's universal compatibility? -- -- David McKee -- dmckee@jlab.org -- (757) 269-7492 (Office) From jcid@softhome.net Tue Aug 12 23:06:06 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Tue, 12 Aug 2003 18:06:06 -0400 (CLT) Subject: [Dillo-dev] [patch] Remote Control In-Reply-To: <etPan.3f357834.6181ef69.2c2@freefluid> References: <etPan.3f357834.6181ef69.2c2@freefluid> Message-ID: <Pine.LNX.4.53.0308121801160.689@infinity.cl> Melvin, > Hi, > > I just made a patch to add remote control for Dillo. > > 1. Summary: > > 1.1 Why? > > To be able to command Dillo from another process. E.g.: if Dillo is used > as a help doc browser of a program, the program can implement context > sensitive help and associate to each widget a help URL. The same Dillo > instance can then be used to show the differents help docs. Other example, > which also was the motivation of this patch: Sylpheed-Claws uses Dillo > to render HTML mail, but currently it has to run a new instance each time the > user views an HTML mail. Having only one instance is more efficient and > improve responsiveness. I agree. > 1.2. HowTo > [...] I think this will be better handled with a dpi. It solves several problems and also add flexibility (you accurately mention some of them in: > 3. Caveat > [...] So please give a study to the framework, isolate the needed commands (mostly done it seems) and I'll answer when time allows me. Sorry for the short answer. :( Best Jorge.- From melvin.hadasht@free.fr Wed Aug 13 09:40:51 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Wed, 13 Aug 2003 10:40:51 +0200 Subject: [Dillo-dev] [patch] Remote Control In-Reply-To: <Pine.LNX.4.53.0308121801160.689@infinity.cl> References: <etPan.3f357834.6181ef69.2c2@freefluid> <Pine.LNX.4.53.0308121801160.689@infinity.cl> Message-ID: <etPan.3f39f993.628c895d.1b5d@freefluid> Hi Jorge, > > 1.2. HowTo > > [...] > > I think this will be better handled with a dpi. It solves > several problems and also add flexibility (you accurately mention > some of them in: Yes, I already started to read the dpi/dpid docs and sources. As Tomas already suggested, PI infrastructure can be handy, at least on the server side. For a moment; I was even thinking about using Dillo itself as a plugin. > > 3. Caveat > > [...] > > So please give a study to the framework, isolate the needed > commands (mostly done it seems) and I'll answer when time allows > me. > > Sorry for the short answer. :( Thanks for your comments. -- Melvin Hadasht From frank@unternet.org Wed Aug 13 15:39:57 2003 From: frank@unternet.org (Frank de Lange) Date: Wed, 13 Aug 2003 16:39:57 +0200 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out Message-ID: <20030813143957.GE23742@unternet.org> Hi'all, The next version (8) of my tab patch is ready (see bottom of this message for download instructions). Frameset support has been upgraded to an 'almost usable' level. The major missing feature is manual frame resize support, which will come in a later version. Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. Other new features (since the last version): - CTRL-R will reload a page (or frameset) Of course, the patch also fixes some bugs (and possibly introduces new ones). Please, test this patch and tell me what breaks. Or what works. Or whatever. More on frame/iframe support ============================ Frameset support is based on a new widget (GtkFrameset) which implements <frameset> as specified in xhtml-dtd-frameset. This widget is not Dillo-specific, so it can in theory be used in any GTK program. It is a pure GTK widget, not rooted in Dw. It does not provide any special support for Dw-specific features (eg. the full-screen-off-button is not displayed in the widget). I might make a special version for Dillo, which does implement these features. What works: - loading (nested) framesets, displaying frames at their appropriate location and appropriate size, including margin width/height. - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame. Same for 'Show only this Frameset'. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - manual frame resize is not supported yet. - the noresize and scrolling attributes are not supported yet Tabs, Frames and browser bloat ============================== 0.7.3 unpatched: 285152 bytes Patched, no tabs, no frames: 289356 bytes Patched, no tabs, with frames: 303052 bytes Patched, with tabs, no frames: 297100 bytes Patched, with tabs and frames: 310828 bytes The frameset implementation has grown about 10 Kb since the last patch. This is mainly due to the implementation of frame size support and the shift to a new widget (which has to be included in the binary, as it is not part of GTK (yet?)). Anyway, tabs alone cost about 12 Kb, frameset alone approximately 18 Kb, both together about 25 Kb. Bear in mind that the code has not been optimized for size yet. Download instructions ===================== There are now two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030813 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically, the CVS version can be found here: http://www.geocities.com/ikbenfrank/dillo-20030813-tabs.patch.gz size: 64875 bytes (gzipped, as downloaded) 272722 bytes (uncompressed) md5sum: a1315001bff22326b33a96b3828341b3 (gzipped, as downloaded) eed9681876272e81f161e254b684fd85 (uncompressed) The 0.7.3 version is here: http://www.geocities.com/ikbenfrank/dillo-0.7.3-tabs.patch.gz size: 117970 bytes (gzipped, as downloaded) 544402 bytes (uncompressed) md5sum: 93b55564ad4b18367f9632c4616e5890 (gzipped, as downloaded) c84a87687950d0e6670e01ea377d3ee7 (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From Andreas.Schweitzer@hs.uni-hamburg.de Wed Aug 13 16:48:43 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Wed, 13 Aug 2003 17:48:43 +0200 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813143957.GE23742@unternet.org> References: <20030813143957.GE23742@unternet.org> Message-ID: <20030813154843.GB36259@hs.uni-hamburg.de> > Please, test this patch and tell ... <snip> ... Or whatever. Woohoo !!!! :-) > http://www.geocities.com/ikbenfrank/dillo-20030813-tabs.patch.gz > size: 64875 bytes (gzipped, as downloaded) > 272722 bytes (uncompressed) > md5sum: a1315001bff22326b33a96b3828341b3 (gzipped, as downloaded) > eed9681876272e81f161e254b684fd85 (uncompressed) > > The 0.7.3 version is here: > http://www.geocities.com/ikbenfrank/dillo-0.7.3-tabs.patch.gz > size: 117970 bytes (gzipped, as downloaded) > 544402 bytes (uncompressed) > md5sum: 93b55564ad4b18367f9632c4616e5890 (gzipped, as downloaded) > c84a87687950d0e6670e01ea377d3ee7 (uncompressed) Or, as usual, on http://www.hs.uni-hamburg.de/~stcd102/dillo-20030813-tabs.patch.gz http://www.hs.uni-hamburg.de/~stcd102/dillo-0.7.3-tabs.patch.gz Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From paka@MyRealBox.com Wed Aug 13 17:40:02 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Wed, 13 Aug 2003 11:40:02 -0500 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813143957.GE23742@unternet.org> References: <20030813143957.GE23742@unternet.org> Message-ID: <20030813164002.GF118@wahoo.no-ip.org> * Frank de Lange <frank@unternet.org> [08-13-03 10:06]: [snip ...] > Tabs, Frames and browser bloat > ============================== > > 0.7.3 unpatched: 285152 bytes > Patched, no tabs, no frames: 289356 bytes > Patched, no tabs, with frames: 303052 bytes > Patched, with tabs, no frames: 297100 bytes > Patched, with tabs and frames: 310828 bytes I have 'Patched, with tabs & frames: 352776 bytes SuSE 8.1 > > http://www.geocities.com/ikbenfrank/ > > More specifically, the CVS version can be found here: > > http://www.geocities.com/ikbenfrank/dillo-20030813-tabs.patch.gz > size: 64875 bytes (gzipped, as downloaded) > 272722 bytes (uncompressed) > md5sum: a1315001bff22326b33a96b3828341b3 (gzipped, as downloaded) > eed9681876272e81f161e254b684fd85 (uncompressed) > > The 0.7.3 version is here: > http://www.geocities.com/ikbenfrank/dillo-0.7.3-tabs.patch.gz > size: 117970 bytes (gzipped, as downloaded) > 544402 bytes (uncompressed) > md5sum: 93b55564ad4b18367f9632c4616e5890 (gzipped, as downloaded) > c84a87687950d0e6670e01ea377d3ee7 (uncompressed) > > As always, check the site for the most recent version: Seems to be working fine. I can provide a SuSE 8.1 rpm w/tabs&frames on request. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From frank@unternet.org Wed Aug 13 17:33:37 2003 From: frank@unternet.org (Frank de Lange) Date: Wed, 13 Aug 2003 18:33:37 +0200 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813164002.GF118@wahoo.no-ip.org> References: <20030813143957.GE23742@unternet.org> <20030813164002.GF118@wahoo.no-ip.org> Message-ID: <20030813163337.GF23742@unternet.org> On Wed, Aug 13, 2003 at 11:40:02AM -0500, Patrick Shanahan wrote: > * Frank de Lange <frank@unternet.org> [08-13-03 10:06]: > [snip ...] > > Tabs, Frames and browser bloat > > ============================== > > > > 0.7.3 unpatched: 285152 bytes > > Patched, no tabs, no frames: 289356 bytes > > Patched, no tabs, with frames: 303052 bytes > > Patched, with tabs, no frames: 297100 bytes > > Patched, with tabs and frames: 310828 bytes > > I have 'Patched, with tabs & frames: 352776 bytes > SuSE 8.1 Which optimisation did you use? Any processor-specific options (-march= and/or -mcpu=)? Did you strip the binary? Most importantly, did it work? Hope so... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From c_bauer@informatik.uni-kl.de Wed Aug 13 17:59:59 2003 From: c_bauer@informatik.uni-kl.de (Christoph Bauer) Date: Wed, 13 Aug 2003 18:59:59 +0200 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813143957.GE23742@unternet.org> (Frank de Lange's message of "Wed, 13 Aug 2003 16:39:57 +0200") References: <20030813143957.GE23742@unternet.org> Message-ID: <m3znid8pdc.fsf@diebuntekuh.de> Hi, this is too cool...Thanks for your work! Christoph BTW: http://www.spiegel.de -> The image on the left looks very stange. -- proc self {} {foreach c [split [info body self] ""] d {14 -7 0 0 4 -67 4 73 11 69 24 -83 -15 6 -4 -84 78 20 11 -78 -1 -1 79 19 -8 4} { binary scan $c c c if {[catch {append r [format %c [expr $c+$d]]}]} {return $r};}};puts [self] From paka@MyRealBox.com Wed Aug 13 18:24:25 2003 From: paka@MyRealBox.com (Patrick Shanahan) Date: Wed, 13 Aug 2003 12:24:25 -0500 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813163337.GF23742@unternet.org> References: <20030813143957.GE23742@unternet.org> <20030813164002.GF118@wahoo.no-ip.org> <20030813163337.GF23742@unternet.org> Message-ID: <20030813172425.GG118@wahoo.no-ip.org> * Frank de Lange <frank@unternet.org> [08-13-03 11:57]: > On Wed, Aug 13, 2003 at 11:40:02AM -0500, Patrick Shanahan wrote: > > * Frank de Lange <frank@unternet.org> [08-13-03 10:06]: > > [snip ...] > > > Tabs, Frames and browser bloat > > > ============================== > > > > > > 0.7.3 unpatched: 285152 bytes > > > Patched, no tabs, no frames: 289356 bytes > > > Patched, no tabs, with frames: 303052 bytes > > > Patched, with tabs, no frames: 297100 bytes > > > Patched, with tabs and frames: 310828 bytes > > > > I have 'Patched, with tabs & frames: 352776 bytes > > SuSE 8.1 > > Which optimisation did you use? Any processor-specific options (-march= and/or > -mcpu=)? Did you strip the binary? i586, yes, I stripped the binary. > Most importantly, did it work? Everything appears to work. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org From kelson@pobox.com Wed Aug 13 18:59:17 2003 From: kelson@pobox.com (Kelson Vibber) Date: Wed, 13 Aug 2003 10:59:17 -0700 Subject: [Dillo-dev] RPM now available for SuSE 8.1! Message-ID: <5.2.1.1.0.20030813104727.01bf6898@mail.speed.net> With the assistance of Patrick Shanahan, a Dillo 0.7.3 RPM suitable for SuSE 8.1 is now available! http://www.hyperborea.org/software/dillo/ Kelson Vibber www.hyperborea.org From salan@myrealbox.com Wed Aug 13 17:18:57 2003 From: salan@myrealbox.com (Victor Sahlstedt) Date: Wed, 13 Aug 2003 18:18:57 +0200 Subject: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out In-Reply-To: <20030813143957.GE23742@unternet.org> References: <20030813143957.GE23742@unternet.org> Message-ID: <20030813181857.017565c0.salan@myrealbox.com> On Wed, 13 Aug 2003 16:39:57 +0200 Frank de Lange <frank@unternet.org> wrote: > The next version (8) of my tab patch is ready (see bottom of this message for > download instructions). Frameset support has been upgraded to an > 'almost usable' level. The major missing feature is manual frame resize > support, which will come in a later version. Great work, Frank! Actually, i'm out of suggestions for the patch, now when you've fixed the switch-to-NEXT-tab-on-delete-instead-of-previous and the locbar-focus. I wonder when your patch is going to be merged with the CVS.. (hint Jorge ;-) - Victor From frank@unternet.org Wed Aug 13 21:47:39 2003 From: frank@unternet.org (Frank de Lange) Date: Wed, 13 Aug 2003 22:47:39 +0200 Subject: [Dillo-dev] Version 8 of tab+frame patch: smallproblemwithwhitespaceinmultilength Message-ID: <20030813204739.GG23742@unternet.org> Hi'all, I just noticed that the current version of my tab+frames patch does not handle multilengths with whitespace correctly. I already fixed it in my version, will include the fix in the next version of the patch. If you encounter framesets which look weird, it may be caused by this problem. As the multilength parser was based on the one found in html.c, this problem is also present in anything which uses Html_parse_multi_length_list(), or which feeds length strings with leading whitespace to Html_parse_length_or_multi_length(). So, a multilength like "*,*" works fine, as does "* ,*", but "*. *" does not work correctly. As far as I can see, these functions are used in tables and embedded widgets. My fix in gtkframeset.c was to rewrite the parser into something slightly more robust (using g_strsplit and g_strstrip). Something similar is needed for html.c. I might include this in my patch, but unpatched Dillo also needs a fix so it is better solved in CVS. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From ming@sunmoon.dyndns.org Thu Aug 14 02:14:49 2003 From: ming@sunmoon.dyndns.org (Siu Kam Ming) Date: Thu, 14 Aug 2003 09:14:49 +0800 Subject: [Dillo-dev] Dillo hang as use chinese font Message-ID: <20030814011449.GA14943@ming.homelinux.net> --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi , I was using the attached patch to show chinese character in dillo. It worked fine. I can use a very fast browser to browse my favorite chinese webpage. Since 0.7.2, dillo become unstable after applying this patch. As I selected any text in the rendered area, dillo hang. Does someone know the reason or the solution? Best Regards, Ming --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="chinese.patch" diff -ru dillo-0.7.3/src/dw_style.c dillo-0.7.3-patched/src/dw_style.c --- dillo-0.7.3/src/dw_style.c 2003-07-07 23:40:13.000000000 +0800 +++ dillo-0.7.3-patched/src/dw_style.c 2003-08-14 09:01:37.000000000 +0800 @@ -245,20 +245,20 @@ char fontname[256], *ItalicChar; ItalicChar = prefs.use_oblique ? "o" : "i"; - sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1", + sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1,-eten-fixed-medium-r-normal--16-150-75-75-c-160-big5-0", font->name, font->bold ? "bold" : "medium", font->italic ? ItalicChar : "r", font->size); - font->font = gdk_font_load (fontname); + font->font = gdk_fontset_load (fontname); if (font->font == NULL && font->italic) { - sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1", + sprintf (fontname, "-*-%s-%s-%s-*-*-%d-*-75-75-*-*-iso8859-1,-eten-fixed-medium-r-normal--16-150-75-75-c-160-big5-0", font->name, font->bold ? "bold" : "medium", (*ItalicChar == 'o') ? "i" : "o", font->size); - font->font = gdk_font_load (fontname); + font->font = gdk_fontset_load (fontname); } if (try_all) { --wac7ysb48OaltWcw-- From Scorpio Rising" <dude@scorpiorising.ca Fri Aug 15 06:44:23 2003 From: Scorpio Rising" <dude@scorpiorising.ca (Scorpio Rising) Date: 14 Aug 2003 22:44:23 PDT Subject: [Dillo-dev] Dillo configure cannot find zlib, jpeglib not libpng Message-ID: <20030815054008.GKBU4612.priv-edtnes27.telusplanet.net@debian> Hello, just joined. I have a configuration problem in Debian stable. The configure file cannot find/use the z, jpeg or png libs that are in /usr/include. *** cannot locate***......disabling jpeg/png/libz I have tried the command line options and even hardcoding the paths in configure.in to no avail. I have installed the dev-headers for these packages. Other programs (GIMP, ShowIMG, etc) find and use them just fine. Dillo works, but no images :-\ Thanks, -- Gregg From jcid@softhome.net Mon Aug 18 21:41:30 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Mon, 18 Aug 2003 16:41:30 -0400 (CLT) Subject: [Dillo-dev] Dillo hang as use chinese font In-Reply-To: <20030814011449.GA14943@ming.homelinux.net> References: <20030814011449.GA14943@ming.homelinux.net> Message-ID: <Pine.LNX.4.53.0308181637310.643@infinity.cl> On Thu, 14 Aug 2003, Siu Kam Ming wrote: > Hi , > > I was using the attached patch to show chinese character in dillo. It > worked fine. I can use a very fast browser to browse my favorite > chinese webpage. > Since 0.7.2, dillo become unstable after applying this patch. As I selected > any text in the rendered area, dillo hang. Does someone know the reason or > the solution? Reason: dillo is currently designed to _only_ handle latin1 characters right. If you picked up a patch and the author didn't warn you it's not our fault. You can find more information on the subject in the [Project Notes] link. Cheers Jorge.- From jcid@softhome.net Mon Aug 18 21:42:40 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Mon, 18 Aug 2003 16:42:40 -0400 (CLT) Subject: [Dillo-dev] dillo - my favorite browser (fwd) Message-ID: <Pine.LNX.4.53.0308181642360.643@infinity.cl> ---------- Forwarded message ---------- Date: Thu, 14 Aug 2003 20:57:41 +0200 From: Mario Moder <clay-man@freenet.de> To: jcid@softhome.net Subject: dillo - my favorite browser Hi! Congratulations! I have been using Mozilla Firebird 0.6.1 and it is very disappointing that it takes half a minute to start on my good old P1-200 with 64 MB RAM. Even when it is running, it runs really slow and uses a lot of memory. I tried the new dillo 0.7.3 and, wow, it started in one second and it renders 90% of the pages I visit everyday quite good and fast. I really look forward to watch this browser grow more mature but stay small and fast. Best wishes, Mario From jcid@softhome.net Mon Aug 18 22:08:07 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Mon, 18 Aug 2003 17:08:07 -0400 (CLT) Subject: [Dillo-dev] Re: Another review of Dillo 0.7.2 Message-ID: <Pine.LNX.4.53.0308181707580.643@infinity.cl> On Sun, 17 Aug 2003, Pete Spicer wrote: > Hi there! > > There was a review of Dillo 0.7.2 in Linux Format issue 42 (July 2003) which > featured it in their "Hot Picks" section (it got a half-page review with > screenshot browsing Slashdot.org on page 41) Good! Thanks for the information. > It was written by Mike Saunders, and quotes it as "starting up amazingly > quickly" and "works marvellously well for simple browsing tasks and the > rendering engine rivals Links for pure speed". It'd be very nice to have a link to it, but I don't know whether LinuxFormat has it online. Does anyone know the link? > Oh, and by the way, I use it myself on my machine when administering my > database with phpMyAdmin (just because it uses frames doesn't mean it can't > cope... provided you pick the right frame to be displayed, Dillo is fine > with PMA!) This is also very good to know. We may surprise you again soon! > Thanks for a great browser, > Pete :-) Cheers Jorge.- From Andreas.Schweitzer@hs.uni-hamburg.de Mon Aug 18 23:33:53 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Tue, 19 Aug 2003 00:33:53 +0200 Subject: [Dillo-dev] Some points about the dpi's Message-ID: <20030818223353.GA13314@hs.uni-hamburg.de> Hi, All right, I did it. I made my first dpi ! :-) (heavily based on the hello dpi, though). I will poilsh it a bit and release it soon. It can handle finger URLs. Two caveats : there is no standard for finger URL's, only some drafts http://www.watersprings.org/pub/id/draft-ietf-uri-url-finger-00.txt http://www.watersprings.org/pub/id/draft-ietf-uri-url-finger-01.txt http://www.watersprings.org/pub/id/draft-ietf-uri-url-finger-02.txt http://ftp.ics.uci.edu/pub/ietf/uri/draft-ietf-uri-url-finger-03.txt I implemented version 01 and 03 (if you check the documents you'll know why). However, I did find real finger URL's in the wild. The second caveat : dillo does not automatically call this plugin upon such a URL. It is easy to patch dillo, though. However, this brings me to my questions : 1) will there be a generic URL->dpi mapping ? I could imagine that dpid could actually handle that. I think, one would need to only modify IO/Url.c and capi.c to simply pass through EVERYTHING to the dpi framework. However, some "core URL handling dpi's" that will become part of the dillo package can probably stay hardcoded in dillo. 1b) Either way, I am planing on writing a "catch-all-URL handler" or "fallback handler" or "univeral URL handler" or the like. It will give the user the possibility to start an external program for handling certain URL's. In fact, with my current dpi, this is quite easy to do :-). 2) Does it make sense to write a library for all the dpi's ? I, for myself, did start simply collecting all the functions that I found in dpi/ and are used by many dpi's and put them in a library. Like the various send_stream functions or the get_attr_value function, or the encoding and decoding functions. 3) About configuration (and I think I read comments about this in the code), shouldn't there be only one config file ? and not dpidrc and possibly different configs for all the dpis ? maybe even merge cookiesrc with dillorc ? I guess some of this (or all of it ?) is being worked on by some of you. Maybe this mail helps to avoid duplication :-) Cheers, Andreas P.S.: I also have some ideas about improving the ftp plugin. There is a pretty simple ftp library, and I think it does make sense to actually log in an ftp server and stay logged in for all the operations. (unlike wget which logs in and out for every file). This is not only faster but helps with busy ftp sites, too ! -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From ferdif@optusnet.com.au Wed Aug 20 02:45:35 2003 From: ferdif@optusnet.com.au (Ferdi Franceschini) Date: Wed, 20 Aug 2003 11:45:35 +1000 Subject: [Dillo-dev] Some points about the dpi's In-Reply-To: <20030818223353.GA13314@hs.uni-hamburg.de> References: <20030818223353.GA13314@hs.uni-hamburg.de> Message-ID: <20030820014535.GA1858@ultra.turing> On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote: > Hi, > > All right, I did it. I made my first dpi ! :-) (heavily That's great, I hope to make a new patch for dpid available soon. > > The second caveat : dillo does not automatically call this plugin > upon such a URL. It is easy to patch dillo, though. Creating a new dpi still requires more effort than it should. > However, this brings me to my questions : > 1) will there be a generic URL->dpi mapping ? > I could imagine that dpid could actually handle that. Yes, but I think you mean URL->SERVICE, a dpi is just an implementation of a service. > I think, one would need to only modify IO/Url.c and > capi.c to simply pass through EVERYTHING to the dpi framework. > However, some "core URL handling dpi's" that will become > part of the dillo package can probably stay hardcoded in dillo. > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > or "fallback handler" or "univeral URL handler" or the like. > It will give the user the possibility to start an external > program for handling certain URL's. > In fact, with my current dpi, this is quite easy > to do :-). OK, but I think we should hold off on 1 and 1b until I make the next dpid patch available. > 2) Does it make sense to write a library for all the dpi's ? > I, for myself, did start simply collecting all the functions > that I found in dpi/ and are used by many dpi's and put them > in a library. Like the various send_stream functions or the > get_attr_value function, or the encoding and decoding functions. Yes, that would be very useful. Your strategy of creating a library of functions which are actually used by many dpis is a good one. > 3) About configuration (and I think I read comments about this > in the code), shouldn't there be only one config file ? > and not dpidrc and possibly different configs for all the dpis ? > maybe even merge cookiesrc with dillorc ? Yes, my next dpid patch gets rid of dpidrc. > I guess some of this (or all of it ?) is being worked on > by some of you. Maybe this mail helps to avoid duplication :-) > > Cheers, > Andreas > > P.S.: I also have some ideas about improving the ftp plugin. There > is a pretty simple ftp library, and I think it does make sense to > actually log in an ftp server and stay logged in for all the operations. > (unlike wget which logs in and out for every file). This is not only > faster but helps with busy ftp sites, too ! Developing the ftp plugin is a high priority and your help here would be appreciated. Best regards Ferdi From jcid@softhome.net Wed Aug 20 17:56:16 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 20 Aug 2003 12:56:16 -0400 (CLT) Subject: [Dillo-dev] [PATCH] Tentative solution of #448, #449 In-Reply-To: <20030808175349.GB23684@www> References: <20030808175349.GB23684@www> Message-ID: <Pine.LNX.4.53.0308201248440.929@infinity.cl> Thomas, On Fri, 8 Aug 2003 tomas@fabula.de wrote: > Hi, > > I've got a problem with 8 bit depth visuals (the images have the > wrong palette). This is similar to bug #449 of your bug tracking > database (thus I tentatively offered to fix it. Tentative patch > is below. Yes, we've received reports of the same problem before. > > Besides, this looks very much like bug #448, so this might be > related. > > I call the patch ``tentative'' because > > (a) I don't really know 100% what I'm doing here > > (b) I haven't tested this on other color depths yet. > > Nevertheless images show correctly now; the price I pay for this > is Technicolor. The fact of dillo working perfectly without the explicit visual and colormap push in a wide variety of platforms, and it not being documented in the GTK+ docs, makes me at least suspect the bug may be elsewhere. Anyway, if you (or someone else) can ask to the gtk+ mailing list about whether this is required, it'd be great. Don't be shy, they've answered us in the past! :-) Ah, don't forget to point that we're using GTK+ 1.2.x. Cheers Jorge.- PS: Sorry for the late answer. > ------------------------------------------------- > > diff -Naur dillo-0.7.3/src/dillo.c dillo-0.7.3-color/src/dillo.c > --- dillo-0.7.3/src/dillo.c Tue Jul 22 22:51:22 2003 > +++ dillo-0.7.3-color/src/dillo.c Fri Aug 8 19:01:32 2003 > @@ -245,6 +245,9 @@ > signal(SIGCHLD, Dillo_sigchld_handler); > > > + gtk_widget_push_visual(gdk_rgb_get_visual()); > + gtk_widget_push_colormap(gdk_rgb_get_cmap()); > + > /* check that ~/.dillo exists, create it if it doesn't */ > dir = a_Misc_prepend_user_home(".dillo"); > Dillo_check_home_dir(dir); > @@ -304,6 +307,9 @@ > a_Prefs_freeall(); > a_Dw_freeall(); > a_History_free(); > + > + gtk_widget_pop_colormap(); > + gtk_widget_pop_visual(); > > g_print("Dillo: normal exit!\n"); > return 0; From jcid@softhome.net Wed Aug 20 18:02:40 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 20 Aug 2003 13:02:40 -0400 (CLT) Subject: [Dillo-dev] libc dependency in 0.8.0pre (bug 487) In-Reply-To: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> References: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> Message-ID: <Pine.LNX.4.53.0308201258570.929@infinity.cl> David, On Tue, 12 Aug 2003, David McKee wrote: > Folks, > Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I > like what I see. When I tried to do the same at work today (Redhat 6.2), I > had problems building. Dpid uses mkdtemp() which was introduced in glibc > 2.1.9. However, ./configure has no problems with my glibc 2.1.3. > > Submitted as bug 487. > > This constitutes a change from the 0.7 days when (according to the > Compatibility web page) any glibc2 would do. > > Introducing (by hand) a definition of mkdtemp() I found on the web solved > all my problems. > > Browsing the source suggests that you are not in the habit of carrying > around lot of little libc bits---and the associated preprocessor code > munging---for systems with variant or insufficient libc's. That is fine. It > keeps the code base small and simple, but perhaps ./configure should look > out for these things. > > So does this mean some previously working libc's are now going to be > excluded, that more conditional compilation stuff will need to go in, or > that dpid needs some work to increase it's universal compatibility? Don't panic! The mkdtemp() issue needs to be solved. Thanks for reporting the problem. If configure has a way to deal with it, we'd need to find it out how. If not, just to think of something else (as implementing a custom function as you did, or see if there's a wrapper in glib etc.) I'm open to suggestions. Cheers Jorge.- From jcid@softhome.net Wed Aug 20 18:48:23 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 20 Aug 2003 13:48:23 -0400 (CLT) Subject: [Dillo-dev] Some points about the dpi's In-Reply-To: <20030820014535.GA1858@ultra.turing> References: <20030818223353.GA13314@hs.uni-hamburg.de> <20030820014535.GA1858@ultra.turing> Message-ID: <Pine.LNX.4.53.0308201312450.929@infinity.cl> Andreas, Here go my comments... > On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote: > > Hi, > > > > All right, I did it. I made my first dpi ! :-) (heavily > That's great, I hope to make a new patch for dpid available soon. Good! That means it's understandable now! :-) > > > > The second caveat : dillo does not automatically call this plugin > > upon such a URL. It is easy to patch dillo, though. > Creating a new dpi still requires more effort than it should. Eventually there'll be a mechanism for automating the inclusion of new URL-handling plugins. We're working on it with Ferdi. > > > However, this brings me to my questions : > > 1) will there be a generic URL->dpi mapping ? > > I could imagine that dpid could actually handle that. > Yes, but I think you mean URL->SERVICE, a dpi is just an implementation > of a service. Ditto!. The distinction is relevant because there may be several different dpi programs that implement the same service. The user makes a choice and uses _one_ of them. > > > I think, one would need to only modify IO/Url.c and > > capi.c to simply pass through EVERYTHING to the dpi framework. > > However, some "core URL handling dpi's" that will become > > part of the dillo package can probably stay hardcoded in dillo. And attached to a service name... If there's a dpi for handling it, no problem. If not, warn that is not an available service. > > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > or "fallback handler" or "univeral URL handler" or the like. > > It will give the user the possibility to start an external > > program for handling certain URL's. > > In fact, with my current dpi, this is quite easy > > to do :-). > OK, but I think we should hold off on 1 and 1b until I make the next > dpid patch available. Me too. > > > 2) Does it make sense to write a library for all the dpi's ? > > I, for myself, did start simply collecting all the functions > > that I found in dpi/ and are used by many dpi's and put them > > in a library. Like the various send_stream functions or the > > get_attr_value function, or the encoding and decoding functions. > Yes, that would be very useful. Your strategy of creating a library > of functions which are actually used by many dpis is a good one. > > > 3) About configuration (and I think I read comments about this > > in the code), shouldn't there be only one config file ? > > and not dpidrc and possibly different configs for all the dpis ? > > maybe even merge cookiesrc with dillorc ? > Yes, my next dpid patch gets rid of dpidrc. This is the only point I have some doubts. I've always thought that it is a good idea to keep separate configuration files for dillo, and its dpis (and dpid). One file with a lengthy collection of not tightly-related configuration directives sounds to me as low-cohesion and high-coupling (I'm not sure about what are the words in english for those technical terms. In spanish it is: cohesi=F3n y acoplamiento). The idea of having a preferences plugin providing an HTML GUI for: dillo, dpid, and each dpi, is what I picture in the long term. Something like: .-------. | Dillo | Dpid | ftp | https | .... | ---------------------------------------------------. | | | <dillo's preferences here> | | ... | | '-----------------------------------------------------------' Restore Apply Save I think that is easier and cleaner with separate configuration files. Also, the rc for each dpi would be located in its own dpi directory tree (available in next dpid patch). Note that the task of the preferences dpi is to change the rc file providing a nice GUI, not to make the changes effective. Taking the changes into account is a thing that each program knows better. The preferences dpi will "tell" that program to reread the rc and update its state, probably through dpidc or dpip. > > > I guess some of this (or all of it ?) is being worked on > > by some of you. Maybe this mail helps to avoid duplication :-) Yes it is! > > > > Cheers, > > Andreas > > > > P.S.: I also have some ideas about improving the ftp plugin. There > > is a pretty simple ftp library, Which one? > > and I think it does make sense to > > actually log in an ftp server and stay logged in for all the operations= =2E > > (unlike wget which logs in and out for every file). This is not only > > faster but helps with busy ftp sites, too ! > Developing the ftp plugin is a high priority and your help here would be > appreciated. Just as hinted in the comments inside ftp.c! Note that you only need to provide the HTML output for FTP directories. Downloads are to be bounced back to dillo for it to forward them to the downloads plugin (that way the whole downloading is centralized in a single place, stats can be provided etc.). I left some code inside ftp.c that shows a beautiful trick to tell whether an FTP URL is a directory when using wget (it probably can be re-used). The most time consuming task with this approach is to parse the ASCII from the ftp server into HTML (easy in theory but you'll find different layouts). In fact that's what I did with and ancient FTP plugin I wrote. If the library you think of using writes HTML itself, great! If not, just tell me to dig in for my old FTP code, and to send it to you. Cheers Jorge.- From joerg@britannica.bec.de Thu Aug 21 10:24:19 2003 From: joerg@britannica.bec.de (Joerg Sonnenberger) Date: Thu, 21 Aug 2003 11:24:19 +0200 Subject: [Dillo-dev] libc dependency in 0.8.0pre (bug 487) In-Reply-To: <Pine.LNX.4.53.0308201258570.929@infinity.cl> References: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> <Pine.LNX.4.53.0308201258570.929@infinity.cl> Message-ID: <20030821092419.GA943@britannica.bec.de> On Wed, Aug 20, 2003 at 01:02:40PM -0400, Jorge Arellano Cid wrote: [snip] > Don't panic! > > The mkdtemp() issue needs to be solved. Thanks for reporting > the problem. > > If configure has a way to deal with it, we'd need to find it > out how. If not, just to think of something else (as implementing > a custom function as you did, or see if there's a wrapper in glib > etc.) > > I'm open to suggestions. Well, you could add a portable implementation e.g. from the *BSD libc to dillo and a AC_CHECK_FUNCS to autoconf to conditionally include that code. This is the way coreutils and other GNU packages work. I'll send you a working copy if you want. Joerg > > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From frank@unternet.org Thu Aug 21 15:06:35 2003 From: frank@unternet.org (Frank de Lange) Date: Thu, 21 Aug 2003 16:06:35 +0200 Subject: [Dillo-dev] [PATCH] version 9 of tab+frame patch, frame support 'complete' (?) Message-ID: <20030821140635.GD32605@unternet.org> Hi'all, The next version (9) of my tab patch is ready (see bottom of this message for download instructions). Frameset support is now almost complete, manual resize has been added, targeted link functionality has been improved, most frame-related attributes actually work, try it I'd say... Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. Other new features (since the last version): - CTRL-U pops up the view source window - CTRL-B bookmarks the current page - CTRL-S pops up save page window New preferences frame_blank_in_tab=([NO]/YES): show frames with "_blank" target in new tab (instead of new window) (read the Browser_Frames.txt and Browser_Tabs.txt documents (in the doc/ directory) and the dillorc file for more info on tab- and frame-related preferences (after applying the patch, of course...)) Of course, the patch also fixes some bugs (and possibly introduces new ones). More on frame/iframe support ============================ Frameset support is based on a new widget (GtkFrameset) which implements <frameset> as specified in xhtml-dtd-frameset. This widget is not Dillo-specific, so it can in theory be used in any GTK program. It is a pure GTK widget, not rooted in Dw. It does not provide any special support for Dw-specific features (eg. the full-screen-off-button is not displayed in the widget). I might make a special version for Dillo after the GTK-version has been debugged sufficiently. What works: - loading (nested) framesets, displaying frames at their appropriate location and appropriate size, including margin width/height and scrolling. - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - manual frame resize (row, column or both at the same time (drag border crossing - this does not work between nested framesets) - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame. Same for 'Show only this Frameset'. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This makes it impossible to draw frames seamlessly. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20030821-tabs.patch.gz unpatched: 285536 bytes patched, no tabs, no frames: 290444 bytes patched, with tabs, no frames: 298092 bytes patched, no tabs, with frames: 307116 bytes patched, with tabs, with frames: 314892 bytes version: 0.7.3 patch: dillo-0.7.3-20030821-tabs.patch.gz unpatched: 284416 bytes patched, no tabs, no frames: 289708 bytes patched, with tabs, no frames: 297324 bytes patched, no tabs, with frames: 305708 bytes patched, with tabs, with frames: 313452 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Judge for yourself if the features are worth their weight in bytes... Download instructions ===================== There are now two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030820 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically for both versions: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz size: 66661 bytes (gzipped, as downloaded) 281416 bytes (uncompressed) md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) c3b6ee3095d4b230a78cf836516e0023 (uncompressed) Dillo 0.7.3 (release) ===================== http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz size: 93929 bytes (gzipped, as downloaded) 399156 bytes (uncompressed) md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From Andreas.Schweitzer@hs.uni-hamburg.de Fri Aug 22 12:29:51 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Fri, 22 Aug 2003 13:29:51 +0200 Subject: [Dillo-dev] Some points about the dpi's In-Reply-To: <Pine.LNX.4.53.0308201312450.929@infinity.cl> References: <20030818223353.GA13314@hs.uni-hamburg.de> <20030820014535.GA1858@ultra.turing> <Pine.LNX.4.53.0308201312450.929@infinity.cl> Message-ID: <20030822112951.GA8204@hs.uni-hamburg.de> Hi, This e-mail account was cut off the net (literally ...) for 2 days, hence the delay in answering. > > > However, this brings me to my questions : > > > 1) will there be a generic URL->dpi mapping ? > > > I could imagine that dpid could actually handle that. > > Yes, but I think you mean URL->SERVICE, a dpi is just an implementati= on > > of a service. >=20 > Ditto!. I understand. I think my original wording was not the best. But in the end, if the user can easily manage and configure URL->(via services)->dpi-program w/o compiling dillo, (s)he will be happy :-) > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > > or "fallback handler" or "univeral URL handler" or the like. > > > It will give the user the possibility to start an external > > > program for handling certain URL's. > > > In fact, with my current dpi, this is quite easy > > > to do :-). > > OK, but I think we should hold off on 1 and 1b until I make the next > > dpid patch available. >=20 > Me too. I'll put it on hold :-) > > > 3) About configuration (and I think I read comments about this > > > in the code), shouldn't there be only one config file ? > > > and not dpidrc and possibly different configs for all the dpis ? > > > maybe even merge cookiesrc with dillorc ? > > Yes, my next dpid patch gets rid of dpidrc. >=20 > This is the only point I have some doubts. >=20 > I've always thought that it is a good idea to keep separate > configuration files for dillo, and its dpis (and dpid). >=20 > One file with a lengthy collection of not tightly-related > configuration directives sounds to me as low-cohesion and > high-coupling (I'm not sure about what are the words in english > for those technical terms. In spanish it is: cohesi=F3n y > acoplamiento). OTOH, for a user (like myself) who likes editing configuration files by hand, it is more convenient to have it in one place ... just an opinion though :-) ... but ... as you say : > The idea of having a preferences plugin providing an HTML GUI > for: dillo, dpid, and each dpi, is what I picture in the long > term. Something like: >=20 > .-------. > | Dillo | Dpid | ftp | https | .... > | ---------------------------------------------------. ^^^^^ should be named "Plugin Management" or the like :-) this is of course also acceptable. Thinking a bit longer ... I think Mozilla is very much like that. You can configure Mozilla from within and it puts its config files scattered thorugh ~/.mozilla/ within a maze of directories. Every time I look inside that directory trying to fix things by hand, I am completely lost ... hence my desire for a one stop config file :-) =20 > > > P.S.: I also have some ideas about improving the ftp plugin. There > > > is a pretty simple ftp library, >=20 > Which one? http://nbpfaus.net/~pfau/ftplib/ seems to be relatively old, but the ftp protocol hasn't really changed that much :-) I *think* it is also used in some other applications. > > > and I think it does make sense to > > > actually log in an ftp server and stay logged in for all the operat= ions. > > > (unlike wget which logs in and out for every file). This is not onl= y > > > faster but helps with busy ftp sites, too ! > > Developing the ftp plugin is a high priority and your help here would= be > > appreciated. >=20 > Just as hinted in the comments inside ftp.c! >=20 > Note that you only need to provide the HTML output for > FTP directories. and for files the user clicks on, like text files, images and even html files that exist in the ftp directory. > Downloads are to be bounced back to dillo for it > to forward them to the downloads plugin (that way the whole > downloading is centralized in a single place, stats can be > provided etc.). I have been thinking back and forth about that point.=20 I think what I will end up doing is at least implementing the actual download from within the ftp plugin. Weather it will be included in the "official" one, or if I make 2 versions (a basic one and a fancy one), or whatever, remains to be seen. I guess one could also think about sending the data from the ftp plugin directly to the download plugin w/o relaying it via dillo. > I left some code inside ftp.c that shows a beautiful trick to > tell whether an FTP URL is a directory when using wget (it > probably can be re-used). I saw it, and this is indeed a problem. I checked the ftp rfc and there is no command that will tell me if something is a regular file or a directory. Also, after checking the ftp rfc and the url syntax rfc (rfc 1738) especially, section 3.2.4 and 3.2.5 makes the logging into ftp sites somewhat problematic. Essentially, it says, unless you actually travel an ftp site like within an interactive client, there is no way of telling how to get from ftp://site.com/foo/bar/ (which could be one link in an html page) to ftp://site.com/foo2/bar2/ (which could be a 2nd link in an html page) =20 > The most time consuming task with this approach is to parse the > ASCII from the ftp server into HTML (easy in theory but you'll > find different layouts). In fact that's what I did with and > ancient FTP plugin I wrote. >=20 > If the library you think of using writes HTML itself, great! If > not, just tell me to dig in for my old FTP code, and to send it > to you. I think either way it could be useful to look at :-) Cheers, Andreas --=20 **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From Andreas.Schweitzer@hs.uni-hamburg.de Fri Aug 22 13:09:07 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Fri, 22 Aug 2003 14:09:07 +0200 Subject: [Dillo-dev] [PATCH] version 9 of tab+frame patch, frame support 'complete' (?) In-Reply-To: <20030821140635.GD32605@unternet.org> References: <20030821140635.GD32605@unternet.org> Message-ID: <20030822120907.GB8204@hs.uni-hamburg.de> Hi, > http://www.geocities.com/ikbenfrank/ > > More specifically for both versions: > > Dillo 0.8.0-pre (CVS) > ===================== > http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz > size: 66661 bytes (gzipped, as downloaded) > 281416 bytes (uncompressed) > md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) > c3b6ee3095d4b230a78cf836516e0023 (uncompressed) > > Dillo 0.7.3 (release) > ===================== > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > size: 93929 bytes (gzipped, as downloaded) > 399156 bytes (uncompressed) > md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) > 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) or again from my mirror. This time : http://www.hs.uni-hamburg.de/~stcd102/dillo/ Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From Andreas.Schweitzer@hs.uni-hamburg.de Fri Aug 22 13:20:41 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Fri, 22 Aug 2003 14:20:41 +0200 Subject: [Dillo-dev] finger plugin Message-ID: <20030822122041.GC8204@hs.uni-hamburg.de> Hi, as promised in a previous mail. Here is the still quite rough finger dpi intended for interested developers : http://www.hs.uni-hamburg.de/~stcd102/dillo/ http://www.hs.uni-hamburg.de/~stcd102/dillo/adpi-0.1.tar.gz It's configure.in is essentially dillo's configure.in :-) you could actually just put finger.c in the ./dpi/ subdirectory of dillo and adjust Makefile.am accordingly. but now I have an actual distribution :-) In the tarball is also what I call so far a library ... well, or at least the routines that have been re-used over and over. Lastly, there is also an experiment : a term plugin, which lets you call arbitrary programs from within dillo (read the source, though !) Installation: just copy the created .dpi files to ~/.dillo/ and edit ~/.dillo/dpidrc (as long as this file exists), then go to dpi:/finger/ If you want dillo to actually recognize the finger URL you will have to edit src/IO/Url.c and sr/capi.c. Search for the string "ftp" inside these two files and duplicate the relevant part for the finger protocol. Or await how dillo evolves :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From melvin.hadasht@free.fr Fri Aug 22 22:30:47 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Fri, 22 Aug 2003 23:30:47 +0200 Subject: [Dillo-dev] [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <Pine.LNX.4.53.0308201352140.929@infinity.cl> References: <20030819193319.18046.qmail@skywalker.bsws.de> <Pine.LNX.4.53.0308201352140.929@infinity.cl> Message-ID: <etPan.3f468b87.38a5d054.2df@freefluid> --3f469477_4a10b4e8_2df Content-Type: text/plain Content-Transfer-Encoding: 8bit [Henning, you may be interested: the patch implements a --reload option] Hi, To implement the server and remote commands feature in Dillo, I'm going to go step by step. First, I'll implement commands to control Dillo at startup time, then I'll implement the server mode (where a Dillo instance can send the aforementioned commands to another Dillo instance). This is because I may try two differents approaches for the server mode part and because the commands are just a generalization of the command line options and can be implemented separately. Here is my first step: implement commands (like -c "open(URL)"). Patch is attached and is against CVS version. This is a generalization of the command line interface, and in fact, most of the old command line options are translated to a Dillo -c command. The advantage of such approach is that the commands can take optional parameters, like in: dillo -c "open(URL newwindow reload=10 fullwindow=yes)" which is approximately equivalent to: dillo -f -r 10 URL The commands are passed to Dillo as arguments to the -c, --command command line option: dillo -c "open(http://www.google.com)" 1. Command Syntax The argument to the -c command line option is of the form: CMD([STRING][ PARAM=VALUE]...) CMD: command name STRING: first and generic argument: in general a URL or yes|no PARAM: name of optional parameter VALUE: value of optional parameter. Currently, only booleans (yes|no) and integer values are supported. Boolean value can be omitted, in which case the value is considered to be "yes". Integer value cannot be omitted. Parameters are separated with a single space (no commas, to simplify the parser) Commands can be divided into two groups: actions commands, and options commands 2. Action Commands: They do some action: currently implemented commands: open(URL [ fullwindow[=yes|no]] [ reload=SECONDS] [ spamsafe[=yes|no]] [ xid=XID]) parameters speak for themselves. The "reload" parameter is a new feature: it allows to reload the URL each SECONDS seconds. The reload is halted when the page is not viewed and restarted if the user comes back to it. exit() exit the instance. This will be useful when passed to another Dillo instance running as a server. Other commands can be added. The framework is quite flexible and extensible. 3. Options Commands These commands set some options that will affect the following commands. For example, the parameters used in the open() command act only on that particular URL. But it can be useful to be able to set some defaults values. The currently implemented commands that influence these defaults are: fullwindow([yes|no]) reload(SECONDS) spamsafe([yes|no]) xid(XID) all open() commands that come after these options commands will have these default values, unless explicitly overridden. 4. Examples: dillo -c "open(http://www.google.com)" -c "open(file:///home/mhadasht/test.html newwindow spamsafe)" will open two windows: the first with google, and the second with the local file opened in spamsafe mode. dillo -c "reload(10)" -c "open(http://www.freshmeat.net)" -c "open(http://news.google.com newwindow)" will open 2 windows and will reload both URLs each 10s. This is equivalent to: dillo --reload 10 http://www.freshmeat.net http://news.google.com 5. Implementation details: 5.1. Command Line Parsing Command line options other than the help/version options are translated into a -c command and stored in a list. The list of commands is then executed (or, when the server mode will is implemented, sent to another Dillo instance) 5.2. Reload Function a URL can be set to auto-reload itself if it is currently viewed. For that, a new member (reload_interval [milliseconds]) to DilloUrl is added and set with a_Url_set_reload(). Each BrowserWindow can trigger a timer function if the viewed URL (Nav_open_url()) has a non-zero reload_interval. (As soon as another URL is viewed, or when the BrowserWindow is destroyed, the eventually pending timeout function is removed.) The timer is of the one-shot type: when it is triggered, it requests its BrowserWindow to reload the URL, then it stops itself. There is currently no UI to start/stop an auto-reload of a URL, but it is just a matter of using a_Url_set_reload() to a non-zero or a zero reload interval. 6. Remark The -c command and the normal command line options can be seen as two ways of doing the same thing: passing commands to Dillo. But the -c command is more generic and flexible and has a more powerful syntax. 7. Future Plans I plan to implement the server mode. After reading the dpi doc and source, I found that it cannot be used to make Dillo act as a plugin unless we accept to have only one Dillo server. This is because the socket names are tightly linked to the service name. Each service has only one socket. Whereas Dillo servers must have a distinct socket. If the we add another argument to the "start_plugin" cmd: <dpi cmd="start_plugin" msg="dillo" param="SERVER_NAME"> and if we modify the socket naming scheme, then it could be possible. I have to think about that again. But I may still use the communication infrastructure of the dpi. If I find this overkill, I'll revert to the straightforward approach I used before, that is, I won't use the dpi framework. OK, it's late, I hope I managed to be somewhat clear... Cheers. -- Melvin Hadasht --3f469477_4a10b4e8_2df Content-Type: text/x-c; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="commands.patch" Index: src/browser.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/browser.h,v retrieving revision 1.37 diff -p -u -r1.37 browser.h --- src/browser.h 14 Mar 2003 19:14:49 -0000 1.37 +++ src/browser.h 22 Aug 2003 22:06:27 -0000 =40=40 -123,6 +123,13 =40=40 struct =5FBrowserWindow /* The tag for the idle function that sets button sensitivity. */ guint sens=5Fidle=5Ftag; + + /* The tag for the timeout function that reloads URLs that + * must be refreshed periodically */ + guint reload=5Ftimeout=5Ftag; + + /* If the window is embedded, remember its XID in case we need to reu= se it */ + guint32 xid; =7D; Index: src/dillo.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/dillo.c,v retrieving revision 1.49 diff -p -u -r1.49 dillo.c --- src/dillo.c 8 Aug 2003 20:28:04 -0000 1.49 +++ src/dillo.c 22 Aug 2003 22:06:27 -0000 =40=40 -66,6 +66,10 =40=40 enum =7B DILLO=5FCLI=5FHELP =3D 1 << 3, DILLO=5FCLI=5FVERSION =3D 1 << 4, DILLO=5FCLI=5FLOCAL =3D 1 << 5, + DILLO=5FCLI=5FRELOAD =3D 1 << 6, + DILLO=5FCLI=5FSERVER =3D 1 << 7, + DILLO=5FCLI=5FCOMMAND =3D 1 << 8, + DILLO=5FCLI=5FHELP=5FCOMMANDS =3D 1 << 9, DILLO=5FCLI=5FERROR =3D 1 << 31 =7D; =40=40 -73,6 +77,54 =40=40 enum =7B O=5FSEARCH, O=5F=46OUND, O=5FNOT=46OUND, O=5FOK, O=5FERROR, O=5FDONE =7D; +/*=21 Commands parameters + * Commands have the following syntax: + * name(=5BSTRING=5D=5B PARAM=3DVALUE=5D...) + * parameters are separated by a space. + * =46irst argument (STRING) is a generic parameter + * The other parameters have a name and a value. They are separated by + * a space. + * Parameters can have a boolean value (yes=7Cno). + * A missing boolean value is interpreted as yes. + * Parameters which value is not boolean are considered to have an inte= ger + * value. This value must be present. + */ +typedef struct =7B + gchar *string; /**< first and generic parameter */ + gboolean fullwindow; + gboolean newwindow; + guint reload; /**< auto-reload interval (seconds) */ + gboolean spamsafe; + guint32 xid; /**< the X-Window ID to embed in */ +=7D CommandParams; + +/* =46lags identifying a -c command parameter */ +enum =7B + DILLO=5FCMD=5FPARAM=5FSTRING =3D 1 << 0, /**< command's generic = parameter */ + DILLO=5FCMD=5FPARAM=5F=46ULLWINDOW =3D 1 << 1, /**< fullwindow param= eter (boolean) */ + DILLO=5FCMD=5FPARAM=5FNEWWINDOW =3D 1 << 2, /**< new window paramat= er (boolean) */ + DILLO=5FCMD=5FPARAM=5FRELOAD =3D 1 << 3, /**< auto-reload interv= al (seconds) */ + DILLO=5FCMD=5FPARAM=5FSPAMSA=46E =3D 1 << 4, /**< spamsafe (boolea= n) */ + DILLO=5FCMD=5FPARAM=5FXID =3D 1 << 5, /**< xid parameter (gui= nt32) */ +=7D; + +/* Structure describing a single parameter of a -c command */ +typedef struct =7B + const gchar *name; /**< parameter name */ + gint param=5Fflag; /**< flag identifying the parameter */ + gint is=5Fboolean; /**< whether the parameter value is boolean (or = int) */ + void **store; /**< pointer to a pointer to store parameter value= */ +=7D CommandParamSyntax; + +/* Structure describing a -c command */ +typedef struct =7B + gchar *name; /**< command name */ + guint params=5Fmask; /**< parameters accepted by the command (ORed f= lags) */ + void (*function)(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams); /**< function that executes the c= ommand */ + gchar *help; /**< help text associated with the command */ +=7D Command; + /* * =46orward declarations */ =40=40 -81,7 +133,22 =40=40 static guint32 Dillo=5Fget=5Fopt(CLI=5Foption= s char **argv, char ***opt=5Farg, gint *idx);= static void Dillo=5Fprint=5Fhelp(CLI=5Foptions *options); static void Dillo=5Fprint=5Fversion(void); - +static void Dillo=5Fprint=5Fhelp=5Fcommands(void); +static void Dillo=5Fcommands=5Fexecute(GSList *commands); +static gboolean Dillo=5Fcommands=5Fparse=5Fparams(Command *dillo=5Fcmd, = gchar *cmd, + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Fopen(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Fexit(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Ffullwindow(CommandParams *default=5Fparams= , + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Freload(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Fspamsafe(CommandParams *default=5Fparams, = + CommandParams *cmd=5Fparams); +static void Dillo=5Fcommand=5Fxid(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams); /* * Local data */ =40=40 -97,9 +164,60 =40=40 static CLI=5Foptions Options=5B=5D =3D =7B =22 -f, --fullwindow Start in full window mode.=22=7D, =7B=22-l=22, =22--local=22, 0, DILLO=5FCLI=5FLOCAL, =22 -l, --local Don't follow links for this URL(s).=22=7D= , + =7B=22-r=22, =22--reload=22, 1, DILLO=5FCLI=5FRELOAD, + =22 -r, --reload SECONDS Reload the given URLs each SECONDS.=22=7D= , + =7B=22-s=22, =22--server=22, 1, DILLO=5FCLI=5FSERVER, + =22 -s, --server NAME Become server NAME or send commands and U= RLs=5Cn=22 + =22 to the server NAME.=22=7D, + =7B=22-c=22, =22--command=22, 1, DILLO=5FCLI=5FCOMMAND, + =22 -c, --command =5C=22CMD=5C=22 Execute command CMD. See -H, -= -help-command=5Cn=22 + =22 for the available commands.=22=7D, + =7B=22-H=22, =22--help-commands=22, 0, DILLO=5FCLI=5FHELP=5FCOMMANDS,= + =22 -H, --help-commands Display the list of known commands to be = used=5Cn=22 + =22 with -c, --command option=22=7D, =7BNULL, NULL, 0, 0, NULL=7D =7D; +static Command dillo=5Fcmds=5B=5D =3D =7B + =7B + =22open(=22, + DILLO=5FCMD=5FPARAM=5FSTRING =7C DILLO=5FCMD=5FPARAM=5F=46ULLWINDO= W =7C + DILLO=5FCMD=5FPARAM=5FNEWWINDOW =7C DILLO=5FCMD=5FPARAM=5FRELOA= D =7C + DILLO=5FCMD=5FPARAM=5FSPAMSA=46E =7C DILLO=5FCMD=5FPARAM=5FXID,= + Dillo=5Fcommand=5Fopen, + =22open(URL=5B fullwindow=5B=3Dyes=7Cno=5D=5D=5B newwindow=5B=3Dye= s=7Cno=5D=5D=5B reload=3DSECONDS=5D=5B spamsafe=5B=3Dyes=7Cno=5D=5D=5B xi= d=3DXID=5D)=22 + =7D, + =7B + =22exit(=22, + 0, + Dillo=5Fcommand=5Fexit, + =22exit()=22 + =7D, + =7B + =22fullwindow(=22, + DILLO=5FCMD=5FPARAM=5FSTRING, + Dillo=5Fcommand=5Ffullwindow, + =22fullwindow(=5Byes=7Cno=5D)=22 + =7D, + =7B + =22reload(=22, + DILLO=5FCMD=5FPARAM=5FSTRING, + Dillo=5Fcommand=5Freload, + =22reload(SECONDS)=22 + =7D, + =7B + =22xid(=22, + DILLO=5FCMD=5FPARAM=5FSTRING, + Dillo=5Fcommand=5Fxid, + =22xid(XID)=22 + =7D, + =7B + =22spamsafe(=22, + 0, + Dillo=5Fcommand=5Fspamsafe, + =22spamsafe(=5Byes=7Cno=5D)=22 + =7D +=7D; /* * Return the maximum number of option arguments =40=40 -185,14 +303,12 =40=40 void Dillo=5Fsigchld=5Fhandler(int signum) gint main(int argc, char *argv=5B=5D) =7B gchar *dir, *curr=5Flocale; - DilloUrl *start=5Furl; - BrowserWindow *bw; - guint32 xid =3D 0; guint32 options=5Fgot =3D 0; gint idx =3D 0; guint opt=5Fflg; gint i; char **opt=5Fargv =3D NULL; + GSList *commands =3D NULL; /* set locale */ curr=5Flocale =3D g=5Fstrdup(setlocale(LC=5FALL, NULL)); =40=40 -203,35 +319,56 =40=40 gint main(int argc, char *argv=5B=5D) /* Handle command line options */ while ((opt=5Fflg =3D Dillo=5Fget=5Fopt(Options, argc, argv, &opt=5Fa= rgv, &idx))) =7B - options=5Fgot =7C=3D opt=5Fflg; - switch (opt=5Fflg) =7B - case DILLO=5FCLI=5FVERSION: - Dillo=5Fprint=5Fversion(); - return 0; - break; - case DILLO=5FCLI=5FHELP: - Dillo=5Fprint=5Fhelp(Options); - return 0; - break; - case DILLO=5FCLI=5FXID: - if (opt=5Fargv=5B0=5D=5B0=5D >=3D '0' && opt=5Fargv=5B0=5D=5B0=5D= <=3D '9') =7B - xid =3D strtol(opt=5Fargv=5B0=5D, NULL, 10); - =7D else =7B - g=5Fprint(=22Error: the XID must be an unsigned decimal numer= ical =22 - =22value.=5CnThe offending value was: %s=5Cn=22, opt=5F= argv=5B0=5D); - return -1; - =7D - break; - case DILLO=5FCLI=5F=46ULLWINDOW: - case DILLO=5FCLI=5FLOCAL: - break; - default: - g=5Fprint(=22Error in command line options.=5Cn=22); - return -1; - break; - =7D + options=5Fgot =7C=3D opt=5Fflg; + switch (opt=5Fflg) =7B + case DILLO=5FCLI=5FVERSION: + Dillo=5Fprint=5Fversion(); + return 0; + break; + case DILLO=5FCLI=5FHELP: + Dillo=5Fprint=5Fhelp(Options); + return 0; + break; + case DILLO=5FCLI=5FXID: + if (opt=5Fargv=5B0=5D=5B0=5D >=3D '0' && opt=5Fargv=5B0=5D=5B= 0=5D <=3D '9') =7B + commands =3D g=5Fslist=5Fappend(commands, + g=5Fstrdup=5Fprintf(=22xid(%s)=22, opt=5Fargv=5B0=5D= )); + =7D else =7B + g=5Fprint(=22Error: the XID must be an unsigned decimal n= umerical =22 + =22value.=5CnThe offending value was: %s=5Cn=22, op= t=5Fargv=5B0=5D); + return -1; + =7D + break; + case DILLO=5FCLI=5F=46ULLWINDOW: + commands =3D g=5Fslist=5Fappend(commands, strdup(=22fullwind= ow()=22)); + break; + case DILLO=5FCLI=5FLOCAL: + commands =3D g=5Fslist=5Fappend(commands, strdup(=22spamsafe= ()=22)); + break; + case DILLO=5FCLI=5FRELOAD: + commands =3D g=5Fslist=5Fappend(commands, + g=5Fstrdup=5Fprintf(=22reload(%s)=22, opt=5Fargv=5B0=5D= )); + break; + case DILLO=5FCLI=5FSERVER: + printf(=22Not implemented yet=5Cn=22); + break; + case DILLO=5FCLI=5FCOMMAND: + commands =3D g=5Fslist=5Fappend(commands, strdup(opt=5Fargv=5B= 0=5D)); + break; + case DILLO=5FCLI=5FHELP=5FCOMMANDS: + Dillo=5Fprint=5Fhelp=5Fcommands(); + return 0; + break; + default: + g=5Fprint(=22Error in command line options.=5Cn=22); + return -1; + break; + =7D =7D + for (i =3D idx; i < argc; i++) =7B + commands =3D g=5Fslist=5Fappend(commands, g=5Fstrdup=5Fprintf(=22o= pen(%s newwindow)=22, argv=5Bi=5D)); + =7D /* Send a delayed locale-related message */ g=5Fprint(=22Setting locale to %s...=5Cn=22, curr=5Flocale); g=5Ffree(curr=5Flocale); =40=40 -243,7 +380,6 =40=40 gint main(int argc, char *argv=5B=5D) /* This avoids making zombies when dpi-programs finish. */ signal(SIGCHLD, Dillo=5Fsigchld=5Fhandler); - /* check that =7E/.dillo exists, create it if it doesn't */ dir =3D a=5FMisc=5Fprepend=5Fuser=5Fhome(=22.dillo=22); Dillo=5Fcheck=5Fhome=5Fdir(dir); =40=40 -259,32 +395,9 =40=40 gint main(int argc, char *argv=5B=5D) a=5FDw=5Finit(); a=5FCookies=5Finit(); - /* -f overrides dillorc */ - if (options=5Fgot & DILLO=5FCLI=5F=46ULLWINDOW) - prefs.fullwindow=5Fstart =3D TRUE; - - /* a=5FNav=5Finit() has been moved into this call because it needs to= be - * initialized with the new browser=5Fwindow structure */ - bw =3D a=5FInterface=5Fbrowser=5Fwindow=5Fnew(prefs.width, prefs.heig= ht, xid); - a=5FBookmarks=5Finit(); - /* Send dillo startup screen */ - start=5Furl =3D a=5FUrl=5Fnew(=22splash=22, =22about:=22, 0, 0); - a=5FNav=5Fpush(bw, start=5Furl); - a=5FUrl=5Ffree(start=5Furl); - - for (i =3D idx; i < argc; i++) =7B - /* If more than one URL/=46ILE, open in new window */ - if (i > idx) - bw =3D a=5FInterface=5Fbrowser=5Fwindow=5Fnew(prefs.width, pref= s.height, 0); - - start=5Furl =3D Dillo=5Fmake=5Fstart=5Furl(argv=5Bi=5D); - if (options=5Fgot & DILLO=5FCLI=5FLOCAL) - a=5FUrl=5Fset=5Fflags(start=5Furl, URL=5F=46LAGS(start=5Furl) =7C= URL=5FSpamSafe); - a=5FNav=5Fpush(bw, start=5Furl); - a=5FUrl=5Ffree(start=5Furl); - =7D + Dillo=5Fcommands=5Fexecute(commands); /* Start the GTK+ cycle */ gtk=5Fmain(); =40=40 -425,4 +538,231 =40=40 static void Dillo=5Fprint=5Fhelp(CLI=5Fopti= ons static void Dillo=5Fprint=5Fversion(void) =7B g=5Fprint(=22Dillo %s=5Cn=22, VERSION); +=7D + +/* + * Print the list of known commands to be used with the -c, --command op= tion + */ +static void Dillo=5Fprint=5Fhelp=5Fcommands(void) +=7B + int i; + + g=5Fprint(=22Commands that can be used with the -c, --command option:= =5Cn=5Cn=22); + + for (i =3D 0; i < sizeof(dillo=5Fcmds)/sizeof(dillo=5Fcmds=5B0=5D); i= ++) =7B + g=5Fprint(=22%s=5Cn=22, dillo=5Fcmds=5Bi=5D.help); + =7D + g=5Fprint(=22=5CnIt is allowed to have more than one command option.=5C= n=22); +=7D + +/* + * Execute the list of commands + */ +static void Dillo=5Fcommands=5Fexecute(GSList *commands) +=7B + GSList *iter; + gchar *cmd; + CommandParams default=5Fparams =3D =7B + NULL, /* not used in default=5Fparams */ + =46ALSE, /* =46ullwindow mode (disabled by default) */ + =46ALSE, /* Spamsafe mode (disabled by default) */ + 0, /* Gtk-Socket Window X-ID (none, i.e. root window by defaul= t) */ + 0=7D; + CommandParams cmd=5Fparams; + gint i; + + for (iter =3D commands; iter && iter->data; iter =3D iter->next) =7B + cmd =3D (gchar *) iter->data; + cmd=5Fparams =3D default=5Fparams; + + for (i =3D sizeof(dillo=5Fcmds)/sizeof(dillo=5Fcmds=5B0=5D) - 1; i= >=3D 0; i--) =7B + if (=21strncmp(cmd, dillo=5Fcmds=5Bi=5D.name, strlen(dillo=5Fcm= ds=5Bi=5D.name))) =7B + if (Dillo=5Fcommands=5Fparse=5Fparams(&dillo=5Fcmds=5Bi=5D, = cmd, &cmd=5Fparams)) + dillo=5Fcmds=5Bi=5D.function(&default=5Fparams, &cmd=5Fpa= rams); + else + g=5Fprint(=22Syntax error in command: %s=5Cn=22, cmd); + break; + =7D + =7D + if (i < 0) + g=5Fprint(=22Unknown command: %s=5Cn=22, cmd); + + g=5Ffree(cmd=5Fparams.string); + g=5Ffree(cmd); + =7D + g=5Fslist=5Ffree(commands); + + /* If no window was opened, open the default about: window */ + if (a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow() =3D=3D NULL) =7B= + BrowserWindow *bw; + DilloUrl *start=5Furl; + + bw =3D a=5FInterface=5Fbrowser=5Fwindow=5Fnew(prefs.width, prefs.h= eight, + default=5Fparams.xid); + start=5Furl =3D a=5FUrl=5Fnew(=22splash=22, =22about:=22, 0, 0); + a=5FNav=5Fpush(bw, start=5Furl); + a=5FUrl=5Ffree(start=5Furl); + =7D +=7D + +static gboolean Dillo=5Fcommands=5Fparse=5Fparams(Command *dillo=5Fcmd, = gchar *cmd, + CommandParams *cmd=5Fparams) +=7B + gint i; + gchar *start; + gchar *end; + gchar *param; + const gchar *yes =3D =22=3Dyes=22; + const gchar *no =3D =22=3Dno=22; + CommandParamSyntax param=5Fsyntax =5B=5D =3D =7B + =7B=22fullwindow=22, DILLO=5FCMD=5FPARAM=5F=46ULLWINDOW, TRUE, (v= oid **) &cmd=5Fparams->fullwindow=7D, + =7B=22newwindow=22, DILLO=5FCMD=5FPARAM=5FNEWWINDOW, TRUE, (voi= d **) &cmd=5Fparams->newwindow=7D, + =7B=22reload=22, DILLO=5FCMD=5FPARAM=5FRELOAD, =46ALSE, (v= oid **) &cmd=5Fparams->reload=7D, + =7B=22spamsafe=22, DILLO=5FCMD=5FPARAM=5FSPAMSA=46E, TRUE, (v= oid **) &cmd=5Fparams->spamsafe=7D, + =7B=22xid=22, DILLO=5FCMD=5FPARAM=5FXID, =46ALSE, (v= oid **) &cmd=5Fparams->xid=7D + =7D; + + /* Check for closing parenthesis */ + end =3D cmd + strlen(cmd) - 1; + if (end=5B0=5D =21=3D ')') + return =46ALSE; + + /* Point to first char after the opening parenthesis */ + start =3D cmd + strlen(dillo=5Fcmd->name); + + /* If DILLO=5FCMD=5FPARAM=5FSTRING is set, then the command needs + * one mandatory parameter */ + if (start =21=3D end && dillo=5Fcmd->params=5Fmask & DILLO=5FCMD=5FPA= RAM=5FSTRING) =7B + param =3D strchr(start, ' '); + if (param =3D=3D NULL) + param =3D end; + cmd=5Fparams->string =3D g=5Fstrndup(start, param - start); + printf(=22cmd=5Fparams->string %s=5Cn=22, cmd=5Fparams->string); + if (param =21=3D end) + param++; /* Skip separator */ + start =3D param; + =7D + + /* The rest of the parameters are optional and separated by a single = space */ + while (start =21=3D end) =7B + param =3D strchr(start, ' '); + if (param =3D=3D NULL) + param =3D end; + else + param++; + for (i =3D sizeof(param=5Fsyntax)/sizeof(param=5Fsyntax=5B0=5D) - = 1; i >=3D 0; i--) =7B + if (dillo=5Fcmd->params=5Fmask & param=5Fsyntax=5Bi=5D.param=5F= flag && + =21strncmp(start, param=5Fsyntax=5Bi=5D.name, strlen(para= m=5Fsyntax=5Bi=5D.name))) =7B + start +=3D strlen(param=5Fsyntax=5Bi=5D.name); + if (param=5Fsyntax=5Bi=5D.is=5Fboolean) =7B + /* A boolean parameter with no value is considered to be = 'yes' */ + if (start =3D=3D param =7C=7C strncmp(start, yes, strlen(= yes)) =3D=3D 0) + *param=5Fsyntax=5Bi=5D.store =3D (void *) TRUE; + else if (strncmp(start, no, strlen(no)) =3D=3D 0) + *param=5Fsyntax=5Bi=5D.store =3D (void *) =46ALSE; + else + return =46ALSE; + =7D else =7B + /* If parameter type is not boolean, then it is + * an unsigned int */ + if (start=5B0=5D =21=3D '=3D') + return =46ALSE; + start++; + if (start =3D=3D param) + *param=5Fsyntax=5Bi=5D.store =3D (void *) 0; + else =7B + *param=5Fsyntax=5Bi=5D.store =3D (void *) strtoul(star= t, NULL, 0); + =7D + =7D + break; + =7D + =7D + if (i < 0) =7B + g=5Fprint(=22Unknown parameter in command: %s=5Cn=22, cmd); + return =46ALSE; + =7D + start =3D param; + =7D + return TRUE; +=7D + +static void Dillo=5Fcommand=5Fopen(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams) +=7B + DilloUrl *start=5Furl; + BrowserWindow *bw; + + if (cmd=5Fparams->string =3D=3D NULL) + return; + + prefs.fullwindow=5Fstart =3D cmd=5Fparams->fullwindow; + + bw =3D a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow(); + if (bw =3D=3D NULL =7C=7C cmd=5Fparams->newwindow) + bw =3D a=5FInterface=5Fbrowser=5Fwindow=5Fnew(prefs.width, prefs.h= eight, + cmd=5Fparams->xid); + + start=5Furl =3D Dillo=5Fmake=5Fstart=5Furl(cmd=5Fparams->string); + if (cmd=5Fparams->spamsafe) + a=5FUrl=5Fset=5Fflags(start=5Furl, URL=5F=46LAGS(start=5Furl) =7C = URL=5FSpamSafe); + if (cmd=5Fparams->reload) + a=5FUrl=5Fset=5Freload(start=5Furl, cmd=5Fparams->reload * 1000); + + a=5FNav=5Fpush(bw, start=5Furl); + a=5FUrl=5Ffree(start=5Furl); +=7D + +static void Dillo=5Fcommand=5Fexit(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams) +=7B + if (gtk=5Fmain=5Flevel()) + a=5FInterface=5Fquit=5Fall(); + else + exit(0); +=7D + +static void Dillo=5Fcommand=5Ffullwindow(CommandParams *default=5Fparams= , + CommandParams *cmd=5Fparams) +=7B + if (cmd=5Fparams->string =3D=3D NULL =7C=7C strcmp(cmd=5Fparams->stri= ng, =22yes=22) =3D=3D 0) + default=5Fparams->fullwindow =3D TRUE; + else if (strcmp(cmd=5Fparams->string, =22no=22) =3D=3D 0) + default=5Fparams->fullwindow =3D =46ALSE; + else + g=5Fprint(=22Invalid argument for fullwindow command: %s=5Cn=22, + cmd=5Fparams->string); +=7D + +static void Dillo=5Fcommand=5Fspamsafe(CommandParams *default=5Fparams, = + CommandParams *cmd=5Fparams) +=7B + if (cmd=5Fparams->string =3D=3D NULL =7C=7C strcmp(cmd=5Fparams->stri= ng, =22yes=22) =3D=3D 0) + default=5Fparams->spamsafe =3D TRUE; + else if (strcmp(cmd=5Fparams->string, =22no=22) =3D=3D 0) + default=5Fparams->spamsafe =3D =46ALSE; + else + g=5Fprint(=22Invalid argument for spamsafe command: %s=5Cn=22, + cmd=5Fparams->string); +=7D + +static void Dillo=5Fcommand=5Freload(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams) +=7B + if (cmd=5Fparams->string && + cmd=5Fparams->string=5B0=5D >=3D '0' && cmd=5Fparams->string=5B= 0=5D <=3D '9') + default=5Fparams->reload =3D strtoul(cmd=5Fparams->string, NULL, 0= ); + else + g=5Fprint(=22Invalid argument for reload command: %s=5Cn=22, + cmd=5Fparams->string); +=7D + +static void Dillo=5Fcommand=5Fxid(CommandParams *default=5Fparams, + CommandParams *cmd=5Fparams) +=7B + if (cmd=5Fparams->string && + cmd=5Fparams->string=5B0=5D >=3D '0' && cmd=5Fparams->string=5B= 0=5D <=3D '9') + default=5Fparams->xid =3D strtoul(cmd=5Fparams->string, NULL, 0); = + else + g=5Fprint(=22Invalid argument for xid command: %s=5Cn=22, + cmd=5Fparams->string); =7D Index: src/interface.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sfhome/cvs/dillo/dillo/src/interface.c,v retrieving revision 1.75 diff -p -u -r1.75 interface.c --- src/interface.c 8 Aug 2003 20:28:04 -0000 1.75 +++ src/interface.c 22 Aug 2003 22:06:30 -0000 =40=40 -295,6 +295,9 =40=40 static gboolean Interface=5Fquit(GtkWidget if (bw->sens=5Fidle=5Ftag) gtk=5Fidle=5Fremove(bw->sens=5Fidle=5Ftag); + if (bw->reload=5Ftimeout=5Ftag) + gtk=5Ftimeout=5Fremove(bw->reload=5Ftimeout=5Ftag); + for (i =3D 0; i < num=5Fbw; i++) if (browser=5Fwindow=5Bi=5D =3D=3D bw) =7B browser=5Fwindow=5Bi=5D =3D browser=5Fwindow=5B--num=5Fbw=5D; =40=40 -655,6 +658,16 =40=40 static void Interface=5Fadd=5Ffull=5Fscreen=5F= bu =7D /* + * Return the first window if at least one exists, NULL otherwise. + * (the first window being browser=5Fwindow=5B0=5D) + */ +BrowserWindow * +a=5FInterface=5Fget=5Fdefault=5Fbrowser=5Fwindow(void) +=7B + return (browser=5Fwindow =3F browser=5Fwindow=5B0=5D : NULL); +=7D + +/* * Create a new browser window and return it. * (the new window is stored in browser=5Fwindow=5B=5D) */ =40=40 -666,6 +679,16 =40=40 a=5FInterface=5Fbrowser=5Fwindow=5Fnew(gint = widt BrowserWindow *bw; char buf=5B64=5D; + /* If we are to embed the window, first check whether we already have= + * an embedded window with the same XID, in which case just re-use it= From melvin.hadasht@free.fr Sat Aug 23 00:20:36 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Sat, 23 Aug 2003 01:20:36 +0200 Subject: [Dillo-dev] [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <etPan.3f468b87.38a5d054.2df@freefluid> References: <20030819193319.18046.qmail@skywalker.bsws.de> <Pine.LNX.4.53.0308201352140.929@infinity.cl> <etPan.3f468b87.38a5d054.2df@freefluid> Message-ID: <etPan.3f46a544.71c1af98.2df@freefluid> --3f46a58d_4f38f265_2df Content-Type: text/plain Content-Transfer-Encoding: 8bit Sorry, it looks the attachment was truncated. Here it is again, gzipped. --3f46a58d_4f38f265_2df Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="commands.patch.gz" H4sICESURj8AA2NvbW1hbmRzLnBhdGNoAMQ8e1PbyJN/L59ilqpN/JCNzfsRcj8WSEKtAylINluV UCrZHmMdsuSTZAy74T77dfc8NKMHBpLsuXaJrZnp7unu6cdMa07CIb/dZUk8WOnH0TzhcXu8tP/9 n6Xzwws28gO+y1aS0Tia8JXBTbIy9IMgkn8tnM7NUszT2Oc3fnjFYvgn8aOQddtrW0tDfzRirSlr zVgrxicsI7XVatnE/9JdZ++9mK12Omusu7PbXd9d32GtDnx+IWjNZjM3YnWVHcyuxIjV1d3O5u7q lhix9J//sFZ3dc3ZZE38p7vG4EmSxrNBytzfBYTPfjiM5ktsicFnpcE+jjlLvSs2imKWwnd/GHA2 moWDFGeUjr2UJTxNWH+WpvAg4WHip/6Nn961WWOFoFzN/DClFhdHuwBub6m51CxHkPoTHs3SHI6Y B5E3TNin815CT2g4a7DJLElZn0OHUcyTMR+yKY/9aOgPvCC4QxKamgQBxJUYiA5GzYqWkxGRMCce MD9hfNLnwyEfOjB2gj9i5sNk/zo5Yn7IBl4CnTkLOaBNI+gzgwd+amFdW2W3/nBvid3vIVeXTjId Jc1pD/5FDZUYK/VzfSevn6BuikylnfL3L9uGonV2V7d3O+taNQGQUk3VfYFibm6iXsLfbgfVkoez CfuH9OfopNc7cw97J+67494Hpj/7rMtevWJrTq7Xn8fnFydnp3av9Xyv3tnhQS8Pa8MhwWW9zo97 ZwdHuV6b+V4Xx+eANNdrK9/r8Oz9+4PTI7vXdr4XzlF1vVC9dvLUH5+fn53nqV/rSi1Dfm7ROt/a cjbWc/w8A3oPzg/fOfDtzdmn0yP8cnr2UX8/+wP/Egr8cnR2eiwBN1cav7LDaDLxQliMUy/2Jjzl cYIrqMGylrF3w2kpjSIQ/hy1LLkLU+92V3QMYVzty8XH85PTt5df2IeD84P3+38e9D4dX7bb7bro ZID3Yg4GBB+ksNT6d8xjydQb8LZE/MaPwQx48dVswmGh1wTkOi5hj13xEEzCIIMnxqDhiYDG2ERE hHtEH4OZwNcbL5gBHuh9VyBDAFK0iF8fMmADL1QA+1EUcPhJ0FjtjiffwqiuyD9gEz9JkEt2PyAf LAiPp7BaAaGXMBhYxDMf+4NxNiSMUg0HKR5EYJOHPBZGShAUEuArxQs9SRgu4Ci7CqjBcqeEFKxa ejflQz5SXuMfYecGY/BRDXgGU9jLFuhKo/EKjBKJBnhZkIO2k4ra0SwIhPHdsxtCPreeG+bcwCcQ erM0aok2wT2YEKslHNgwTOoFnCC7SeKN+F7BZLM8ZFTov1rCQzJwAcBNchDoCxDsvVoAJJuEnBx4 lTeBdwWCHAIb/dEdStljrQGIhfpa7AB9kAvVMArvj1xaIK7QanPFdxxJmgT2Mqnmch7am0+93ueT 06OzzwpaV0HL5GCAqUmO1asAnh5/lvAUwFUFEOTHTIDeowAaxlfb+icJucDADwfvLw7eHJtuQQJU arCYKnT+ea8hgYDWmAyTyiQg3St1uKClM4OFOeTJIPb7QiNw+UNolQ2PRraeVC4/XN+pWoRoufYE NRkoMmdK8XHpUJM7CjxarkLm8MNSUtT24lLF0X7iSibp0fMxJ1NqD9ImSS22GgR5AEHz9iYCjjXA ckQx3zNW2jQioeIK88wf1LGAoLj2LsjZLOD4Y3hrcdW0BWqkxdqZ5m3iTrzkeo/lJAHuaDDgU+nE kFkKTu3sHB6iEBKbO7WGioTrNcu8sAZQ682C1BUYRSAhPrmOg8lQdqrvqRVuRtf8lg9mKU8sitSk BAfGPJjaHMAnLOW3YNyTJBr45BPnfjouQNGyQYHA4CUM3N9E8dyLhyCSQYAOFYhJsGGFopftrrMF WcramgNhI2Up0GOgzfMRxpTuFU/daJrWMCCCfyWEhz5iLg0IFG4c9aMBQ1144gjlbvjD2zrEOhIj yUCgm4J7S12ctomRNeSXhwbdgOihTw0boF9rqfkQeFcyL1H9S3qrLq6UXe3tRc8HM9BQDcYw7ety Q0ElEi4VQ+kWaJXoNIGkR8oevyvlekCzHiATmMXDBerLvhMFv/XTn4wi84s/GZHwbD8ZiXJ5PxkN OMUfgUHZjV4EmT0beqmXWYudLWcHrMXmurPZMayFuUrPxL9fLsFpizSILTPWGjms1TLCHfpcpF6c YlCHDSpumURD3l6+F4nYP8utYNlhy61WgOTAV/pAOJZLMJ0MVYCoqLthkI6i8GUqsyQW+OF1IjdC fNrrqCV1wtkUOGOBU2iHRNp1CumqXKyINEakMk66OD48w5ySnYvfaKav/Bseil0V7kESIfsgUrkt AmgTgTaBKIvHZWhF/mugTRCt6M9OD94f05DfITqbYAKVPYapQnYxVN4ioTwBqfkaLmto5R+IBnAC BjSTUwNBsoQraLZIlhm2QfMAaVZu6+syBHxfEfmxsK/aocHzNqgI56z1DkegwVbDFlOtdrm8G88P vH6g4SYm9e8E9SZolIGlXtY+gTGNAlEJqpmfTANPRBwBugkILq/DaB5mnAd+Qro3S/gjZkFe3maY WGd6fZxCcuEw8bdD/+H3e7WNoBaoHKxdjlqfxAdlFZbJeSxrF1SRFn17KMP5ZgRH1XlLEYRMQR4a rpOK4mhIFTKqC/4ws3tihqD3X4zU68u+2CW4vPyS5b/mQ7Gs9+WShQfKoJudwPruAxmXdSFTpWMa M3nNjLedCnqxm2MPqoJoOMlFMqtAlkFwyqB+kbOrIkA6z2ciF6OdPDTJ5Sqc6OSeiRCGOhYcEFcV Gu2yF0tMdXWKg/MMpOSUaQ97ziFXCslWTLxbfzKbsHBGe99gNcQ611ttiThU2N5wuuusudZZc7oU rxtxQOJDGBkM3TFQFfC4RocB/hWArC+JkHvi+SE9BqgDFZdjjP7lEroIby1D0aEPHq0xmMWxS66U QzCtpv4pDnATCny3O4sD0WCdarBGfy4eG9s8YG86e9k5BTyUIYN7FaVGIyW+w9tcd+wMefSV2Ul8 l9mFTC5uYBxaQLHLlI/VdaM+dkl4ysQE1SmKMWfofuVCmjqcTWvQUTys9Q7dA2V06xAwoWBWQSBr GyCY7o6zsYmCeQTDFQ3vSGDa8UF0wplOegRR87EPPWo1yQUgzM7MZNTlSEQi73qheAJfMdmq10HG LdJRk/Xf9jPmitYE/A7EKApbNowOYgoHALuyVS8NOxer72XtsVD5jvGoH3Pveq8cAfreCuiUHp7p jPC5GMAGGAj8kZg0iahzCf+x1/vsZecle/GC5RpeQcPOy4w34iMUHXQmjQITlPLR3Y5J7D3jAZBj g7gSM6wtH8dxFO+K3dCTI71TDPnlLMSFzSmp9ycQ6MIix81I+LZswVKfZbHx/DWkzfjRCGJB3JsR 2zpzL9llv2Eo6JiTNAnNGNvqmvQ/jslZfLBb3oFC+N0KYDKJMZptDtEJYcnagdkul2iGNQEL0b2y 4FWrQzaXLI8saqlaIlkPVrlMrD6ZIluPJcWVCMWSqcSWWzY/AiMtIWvE85aRBQLRZEYbrDBG0643 hfhtWFMtTmGM+CijLeY8qpG3/y2p5/Q7P3+9GvNQv3dFllP5zDWZB2aotT2bp0nRXKPWwEeIgUkf aQaP9eUCfxeRIK3As7HruOsZuEX+8XTkZbItqJ8MbRdr4CIqRf6fo1JhOQVr5U+mAcd4ETTxjqfC Aj4Jhcx0ny+G75mflWsvsGLZ5u1z7Zh2LFa3JzmXMryFlWgjvl+Sf+kB7lPUfGArBGh7zGevKIKD b82mYRMfw/6C1lGu+1uS5bSofSQZX0vmXsWgF5wO4Yc88O5Ad0SoixtadNow4UniXekQWbPogqcp 2iwZLqcRmKx2u01Wy4ij6zJqd0cx5zW7gaLn9TU8hVjb7jiPjZ2ZrGnCwgPMgRLof42k/B1N+j7H s3oesuHUb03j6Iq2OUd+6CdjXS2F9toLahcnbw/f9Y6c8iQKKV9qKXSDMR9ci5Oc/11p02YKgxQ9 SYH9AxBySkVJ4P3g7zDiCW45SmyQT4HwPPe9nwyAexyF584gY3Kxhqi2LKAtS07JDBPRUbsLw2vw v+LXxo4D+VNzbWfD2Xk8wzz3aO4CE9KaROO5h1F0DdzKnlIoBFNtQQYKkUnsD4GXRFs8wLlgs3Tv OkR6UepG6irKgtmOknbmGlxKHYEbH88/HeMZjUTpuafejaSEjb0EPCuIcAJk0NFzJDZrsdwMWgae LAHDmjC5qSYQNhiC8L3A/9s8J8OTcVm858qd5kQfV8qJ9eckoxM8BR15A+7aA1yAUROzmfvDdOzI qY25fzVOHYz96cxJsPZ3YO3Ei69LmEuLTagP8WI2ZQnoDw8VITq5Jnog3ybUy7i3mIxxz9LrR7N0 V2xVqoxC8G86S8a1/tzJYOhmhEMr0GqixgVmSEpSVO5N8GgYFkHIIrCHn857K29Oesfo2DhWu5g1 CHI6Umd89hrh14204js53tETyDFNLCAwCdzVj2vK9u2ZRFUpMgUjJqmCfwlP6Tg/yZjoIA/cN72D txcGZ9k3enwBMckFxCQZ0gViekBSTAV1FSeTxomk3lsQRyy4AN5+/KPJBneDbKfjKr12yWhIs7K+ uuGss+bG2razutY1zncWns0+8kBW7zEp/0E9VZgrUyX0TPeioABrodgH7Pq4DfVstZftmS+Jyqon HAgvNYUHlrtN+FUc1Sv6dR0e+QQsQ3sUJbtfwyx8sMOAjlh9CRivaFTL9uvrK4VHlA7kAgVNmeSp 0du/bOMUteO3JvI1PEmpiA/Px4z6NXut27NQIZApLHWIY4pL8bSS/4uP2JUgVIMP5mLPrJqAGYrf 9smmff6pTzzgI3ZjcIVgFR+JDExXrr+szIDPm4PeBZg4LDLLzjDxpJKBQBI8X6JCEzm+XjryQlU+ PWpcx1Em92163bqIBtc8ZXJ79a8WJJ+1EETiML/N2yyOYBKSqgpw92X8yQ5+JTcNTbdVE4uA9rUo Qe3wAWTz+G/rNZ4Sy2f78lHIb1Mzgp3gvlhNiqtujjO6ZIKyJaHK2M2V8tglwlqsi4vqtVhcrZa9 14A+4FeIBMLBZFqjYgx7zWDdEeU2AUTTxSaxqVrY/XioAOSFBcVhhPSFcQZfLySVNl5VUwSQcuf7 L+xaARMEbm1Ub2yIOi7GcymP3oIAuAtzOb3hoL8Ip/8K3LTRTeP8FFqGPI8rM2kia9Aza4v614ye rEfOuIlMSTQa1TrUKmKZMFLLZg4BJ0Yw+A4CRTJowiR/mQi3jKimKWdnhi64F68EYocxEM/ui5MH Q1lKTkzM86X8IYvmx/eFTLYMbf1piwBW7XI+NQaV4x6Ib3SP0vhGHZHhVH9gQdUjil6UezHNn661 BgKtJzwcWr8JhnhiFYjecbRjy3hEvFzSDJpHzWG0XLTMcjmK6lFR0M+ME3uGxQtZQrXsPHAi71Ca Bc6kJmtA66aVaL3OwNw7GXC9Z4AVHZXn+ND2MHANxoRtVdWU1wGINuk6K2ALMCZgtf9HoKuqB7Dt YaIVGBM0rAxVe1RaqKzbHqYZwAjbdG/7WDBGh7S3gN5tEET0igIM4iFYocTXkQjmjfvkS5vKJaHV IxenbRJ0wo31X/fZy/pLbXnl5hTRZ9jADxFF15F8fYB00xulssIYDWEFKSqJt4jRKxBEj87RiHCF va0oKQGwkFg5iDO0qlpFdi/m0KAYFB97aRTfFWumcfKCLJg7sgriE4Mio144y/RylBj2mbqLs7zB OBaAHfYSmKplhwhlN2neDfOqxmt7wcwQB9SMvJg6Yg7pjFngECNbgsUZNrWvVwIk85y5ljJaBXMK pDabexSlXvtT9e5NFBsRpBK4Ye/uLfHiMUbMRcxvlaeL14pE0uAFVHqWf8dI1OTT6z0KpTzyNgX6 k6WTC5EUV6oiT9M669jTfPjI6LNSRS1YEPdlLxOAZhdiOR3EmlpkjLYC2bLGklBWML+5/+CwXFyo 2W70y15kKDvoA9050G8uZKuaUmhwk/rlBvv9Ksi0X4JvfWmoqEWD1FepsOzbN5ZjEAzW/IDvdQrS OsXgGz6N/ITE+xH7ys7X5V5mfiidJwpiLNRhpDGH0fchVga9BHMZwJwbMJsqjz+F6c4Egy9w5N5/ k6Ybd7+TItqGdUJKxf8PyEw5r/2XpSx5YAZMaqyxaIvgtUo8k+H5YyXGqvj2KHBUKjILlGbISs6S c97cee6i492HsjGL1kI+lgn6EYlgqTQ0ykqfIYfJVWOG/D/tnQYV5JdnV6w8IdNxRZnnznkVMSc1 qPLUozz4VsMK2d1DWWUW8+EwQQ4autIQXNP5IxPIXHCrs+uFe/GVoUqB2TIa1+R/9z58GRaRTJTg kEf3BpLiMLBv3U6noye/IAOuSn8XrIIf89qN3tIGBqj9fzfgNzyo1Y3pZ8rxPzM/db0gUNpmOhYi qfMI2n/k+zzmDKpXpfT3clMv18lhy5iV5/yuTYq5OPVZpWKA8umV4CGrfwp0w3ya/NWm+SSEIAi4 ql+8x1jUgJCz0tVrVC01tlBkP+6lpX9NYPrV4p8gLgP2s4Slx/8EUf2ol9gWCAqyaYPaYge7zK+8 XVb7VXFZ2tN9HRWVSUuHSOyJMpDQf4IEfsird///7DeKl3807xH0MxgP4aJxj4+vvNK/epePgbXy Pp+tjfx9PlsbzCRX3eljPHvwXh8AqO71MYcU7/ZZ6xh3+6zubOBlNKuqLii/jW679drb9PqzP4QI k07lRRwJ3DcvkKqrF70xWKCHMceSnJKee7KkTcEp3gKlFQ+BqecGvJIRGFPhiPwBeTibuBCh0/G3 IpEQW7EsZFxo1vvzunoXlT4lnfLPWi2B4VKURmxuEGM3N7ad7ma+MiLjqjcUsY4rynnc/myJKv2Y PB433vgR+63qBqwR81IGIsLds5DrojJyjHR3ztxP5MU3tcLoPqcbbewJdC7pdh/Is3N5zVLzkemF VQIhE7Ycf9l/FdGyXZEWGZUBuANwKOrjPLMQS00AdwQlAj9tU/eaqtnK7gij1JmO6XM4qbxNvqG8 Ka+32tqRglqQ6NCRD+Y5pB4lKSDZJtwV789GXzbXL5WWi02ROae9TX1BTXarmaN31HFfX13bgf0D 4MTwjuor1MY2LE11A5o+j1QFJAlefEFHDDBzcQMRVc3+Nxafx7wl6uDaElS2E56TFPgETNCMUhH7 rP/BBWZvWJKbKKwY/1KkgLZZl2It9NWbAapQ6TMVzoAXAal0anVk6d88Fu8eT8BExHeqbInyV9nP EpjDurqwsUc1ssNhjg2OnJf6F/KfW1n9tLm1Tpqzs+VsP1lxVsyqQxZC+gcGAuQu7zgp6KxqkFMy Sh/BVhkq9tm47iVbCWL3U2sMQPdCccOWfUKNNlX4dHEznpTfryQmbQyhE2WBOhtB62zM9O3HP1xx 3ud+PPvQO/7zuCfZTO6fbhHZXEXebW9vOVtP5h0RwMOZO42ms2kby05d0MZ59rJesZPYWbCbLW8k Xh9UTCg6Fvl6oR58OIuTKP6IO5v7VMHNygOPf/OaSwNrZeCxup0PPFa3mUluMfAY/9Jlb3hf3nW5 uru2sbuxpQMPAFgMPMpuu8wFHiLuEEuHvKKpA3i3GYSZWInNk8Tte3GCS3ep2BPixfiOdvxom0hH KKwxp3+doo1GZSzAQXwDkmmtMMBhb4fXhsCzrwjqu9zlXtHdPnoxjOXFOKq41Xh3VlR0lk5S3Afq ovIXZwrjDC0Gs/SvBs6E72lXYAoSlc7Sr19WN7KrWTtdipPXyu6/lL0fVtQ1MlTwF+3UgvuRrCAP DbRMtMvYrCtWUIJZX21yBv3albpfy7N0FjsPvHDAA5ffTvkgLYXP5G2T3Y0tulYWA9G1fCCKoPTS KeihXXpr9t1ln+Jg//VvySva46f90o/nbg03Jk1vdJFGU5VF48Ssk/eKAL6kNvUcI366+UxeQfvb kPBWpwDPyBoy51Zl/HMByFsuqozRtcgTbHxThdNNY9m7LzhVKTVy8e40jdFp45FVq8u0X42CoS6e eudj7HpH1gNFc3rwJ7pSHKbfHye9XO12nixW8aF3O5BBkHlEQcCHysSgjQDtGoMhNDIg9OlHn92L w/OzXu/4SPp3YucwGsDQutxNPz94+/749GOmC5JpWQgM3TAmwVcd8GI1CCONOwNp00C+GgOJTSsZ R6lQnTY7QbMXBCoG7ovqAS+mGzhTcU2OVDYpDwqFEV9jhWW5JlCmhayuKDTUrlIFTHXCSLEMTm6T onRho+Jmr1OpdI+MzTZljeudjrO6XibVKoOiXhG7F1fBUt730bizGV+C6WN8CRyb4qk4XnCTbXHR tXuhdXcjcG3Jqr9+rKFSCWCBRjzEzD38v96upadhGAafy6+IdkBs4rCMTqhMHCbBgesQZ8SjiIqN TqOV2GH8dvxK4qQdIA7bAW1NnKSu/dnBjjtEijjnp3fVVC02FYcF+giNFER0QtHz4FBmzFtZrjUH h+ZlU68ClQBM1UgaCQWmOc1b+cY/IYOK5MTo7B+2mt5fc7e9aDFjfrmFPyGjRZ1L3PkiIDfuxCZJ uJTBkSLfLtEXdhXNVvbFsE/CnSMeLQNHpKKAeoNnPc1sqI09SPNBjT3Nt78ee96px54bXqIz9vQr s1MzX4c67JP8Ih+HOuy5N/bc+zdjX7C1L9jc+9DvSGJwmHPFSZkhKFxvKsZwgoOHZWOSj6oJAn2p i+AiUVQfq4c1IvX9snx3FNQxalEUjNjAMNjbYE13YJhQdFtAdLI+nFLTJC1ukyPCR9FuwBU675OT 155PAZ7Gym93sU+4s5PAmPbUJ7AqQyK51z6xv9UMwTtkHiqmheZdfHbktlTPQWDL1ZgH+Rf4StYo Chgt0znO3hgQhmVkK8gwZFnb5eClCSyDHpQt4a0JXsnSyHOrI86tizRfT6657tuQxqH405/Ij81X l15ZlES5D7kTpfn2KrftePK2MLxErdyw7zw3V+UTquvE2LMLcObPpl65bREp969bTmstecLWsnK7 9yt4UeD/+EZJ1yB7UbVpBusBXB5whdUTMhGPW1Ot0OcDheUqsSTqXJJXK3E60p1QS7E8zFZTI0UD 9ei2Gsi/BcFDArhAyHB0jmB2n4brZD3VejXWwnsA2qcKgi/FnGl1O7XTmOT8Aosp85dWzTJMcdQI N0dm7uDhKIURlvZYQ3EsrsE76/THQ0FJd6lJBQ09/ffClHvkqEj/gY3uVPA0em4Ervb0ZUl5quvN c0okhxOwCVERid1qiZyPN7yWn/Ctee2YqBYIvgF3rhUIgmUAAA== --3f46a58d_4f38f265_2df-- From jcid@softhome.net Sat Aug 23 15:20:30 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Sat, 23 Aug 2003 10:20:30 -0400 (CLT) Subject: [Dillo-dev] libc dependency in 0.8.0pre (bug 487) In-Reply-To: <20030821092419.GA943@britannica.bec.de> References: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> <Pine.LNX.4.53.0308201258570.929@infinity.cl> <20030821092419.GA943@britannica.bec.de> Message-ID: <Pine.LNX.4.53.0308231019490.740@infinity.cl> On Thu, 21 Aug 2003, Joerg Sonnenberger wrote: > On Wed, Aug 20, 2003 at 01:02:40PM -0400, Jorge Arellano Cid wrote: > [snip] > > Don't panic! > > > > The mkdtemp() issue needs to be solved. Thanks for reporting > > the problem. > > > > If configure has a way to deal with it, we'd need to find it > > out how. If not, just to think of something else (as implementing > > a custom function as you did, or see if there's a wrapper in glib > > etc.) > > > > I'm open to suggestions. > > Well, you could add a portable implementation e.g. from the *BSD libc > to dillo and a AC_CHECK_FUNCS to autoconf to conditionally include > that code. This is the way coreutils and other GNU packages work. > > I'll send you a working copy if you want. Of course! It'd be of great help. Cheers Jorge.- From jcid@softhome.net Sat Aug 23 15:41:51 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Sat, 23 Aug 2003 10:41:51 -0400 (CLT) Subject: [Dillo-dev] Re: Re: dillo / time-controlled reloads In-Reply-To: <etPan.3f43d516.519b500d.ec5@freefluid> References: <20030819193319.18046.qmail@skywalker.bsws.de> <Pine.LNX.4.53.0308201352140.929@infinity.cl> <20030820194041.28849.qmail@skywalker.bsws.de> <etPan.3f43d516.519b500d.ec5@freefluid> Message-ID: <Pine.LNX.4.53.0308231021170.740@infinity.cl> On Wed, 20 Aug 2003, Melvin Hadasht wrote: > > Hi Jorge & Melvin, > > Hi Henning & Jorge, > > (Is there a reason why this is not on the ML?) The only reason is that I pressed "reply" on a mail sent to my personal address. :-) > > > > > there's one bit missing. there is NO concept at all about time-based > > > > reloads. the meta refresh header would be reasonably close, but even > > > > better would be something like > > > > > > > > dillo -reload-every 60 http://blah/cgi-bin/blubb.cgi > > > > > > > > it should reload that URL every 60 seconds in that case no matter what. > > > > > > I think reloading it if upon display is also a good choice. I > > > mean, let the user browse other pages without reloading the > > > special URL, and reload it when it's back on display and the > > > timeout has been reached. > > I don't see why a browser should reload an URL if it is not currently viewed, but > I'm not a web expert. > > > > > I looked into adding a sigalrm handler an solving it this way, but > > > > then it turned out that is more complicated > > We can use the glib timeout functions for that. Yes, timeouts are simpler. > > Here is how I would implement the feature: > > - an internal Dillo function to mark/unmark a URL with > "reload periodically when viewed", A simple flag, maybe in the DilloUrl or in the cache entry. > it will also create a timeout > callback that will reload the URL if it is currently viewed. A periodiciy of 0 will > stop reloading. For that, I need to take a look on the browser history/cache, too. Don't worry, I can do that easily (I know pretty well the cache). I'd prefer you to focus on the dpi part. I mean, this dpi will end asking dillo to do the job. For instance: <dpi cmd='set_reload_URL' url='...' always='true'> > > - add a "-r, --reload-every" command line option that calls that function. > In fact, when I finish implementing the "(remote-)command" option, it would be > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > supporting commands with more than one argument is worth the work). Hmmm, I think a simple cli switch to tell dillo to listen to the reloads.dpi is enough: dillo -reloads (or something like it) Then, the client communicates with the dpi socket. All this API is what needs to be designed. I'd appreciate you to work on this part. > > > The first duty is to define what is required for a good, > > > general purpose, kind of reloading dpi. The next one is to reduce > > > the features to a minimum working set, then implement! > > parameters: URL, periodicity (seconds), when (visible|always). This is a good start! For instance: fprintf(reloads_dpi_socket, "push http://localhost/someurl visible\n"); may be all the client program needs to know. Of course it could also be something like: fprintf(reloads_dpi_socket, "<dpi cmd='reloads' url='http://localhost/someurl' visible>" * The first example makes more clear that it goes trough reloads.dpi who parses it and then sends a dpip tag to dillo to request the job done. This may also be handy: "<dpi cmd='reloads' url='http://localhost/someurl' stop>" Note that it may be good to integrate the remote control functionality into the same dpi (and maybe call it remote.dpi?). This means adding a simple and useful API for help programs to use. For instance to let them push new URLs into the same instance of dillo (and not having to start a new dillo per requested page). Ex: The client app. asks the remote control dpi whether there's a running instance of dillo. YES -> send new to-be-pushed URL NO -> start "dillo -rc" (remote control) send new to-be-pushed URL Please polish along these lines. Cheers Jorge.- From henning@openbsd.org Sun Aug 24 00:37:59 2003 From: henning@openbsd.org (Henning Brauer) Date: Sun, 24 Aug 2003 01:36:59 +0159 Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <etPan.3f468b87.38a5d054.2df@freefluid> References: <20030819193319.18046.qmail@skywalker.bsws.de> <Pine.LNX.4.53.0308201352140.929@infinity.cl> <etPan.3f468b87.38a5d054.2df@freefluid> Message-ID: <20030823233721.26812.qmail@skywalker.bsws.de> On Fri, Aug 22, 2003 at 11:30:47PM +0200, Melvin Hadasht wrote: > [Henning, you may be interested: the patch implements a --reload option] guys, you rock. it's just two days ago that I asked for that. It works great on OpenBSD/i386 and OpenBSD/sparc, all OpenBSD -current (3.4-beta atm). there are two small problems: -if you specify a small reload time, and by that time is over before the page is actually loaded -> coredump -on sparc, using the "void" input drivers for keyboard and mouse -> coredump that must be the visibility check? both issues are unfortunaltely pretty much showstoppers in my application :-(( From henning@openbsd.org Sun Aug 24 02:24:11 2003 From: henning@openbsd.org (Henning Brauer) Date: Sun, 24 Aug 2003 03:24:11 +0200 Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <etPan.3f468b87.38a5d054.2df@freefluid> References: <20030819193319.18046.qmail@skywalker.bsws.de> <Pine.LNX.4.53.0308201352140.929@infinity.cl> <etPan.3f468b87.38a5d054.2df@freefluid> Message-ID: <20030824012433.9126.qmail@skywalker.bsws.de> On Fri, Aug 22, 2003 at 11:30:47PM +0200, Melvin Hadasht wrote: > [Henning, you may be interested: the patch implements a --reload option] hmm, I have one more issue. dillo caches the images too well. try looking at any mrtg-generated page. the mrtg graphs are usually rebuilt every N minutes, where N=5 in my case. tho, now, at 3:20h, it still shows the images from ~ 1:30h. old data is not relevant in this case :-( From ferdif@optusnet.com.au Sun Aug 24 15:18:37 2003 From: ferdif@optusnet.com.au (Ferdi Franceschini) Date: Mon, 25 Aug 2003 00:18:37 +1000 Subject: [Dillo-dev] New dpid patch Message-ID: <20030824141837.GA1181@ultra.turing> There is a new dpid patch for dillo-0.8-pre available from http://www.geocities.com/ferdif2003/ Plugins are now stored in a directory structure under libdir/dillo/dpi. You need to put dpi_dir=/usr/local/lib/dillo/dpi in ~/.dillo/dpidrc so that dpid can find the plugins, there should be no other entries in this file. Dpid now uses a .filter suffix in the plugin name to identify plugins which read and write to stdio (eg hello.filter.dpi). The following changes affect the CVS repository: Renamed dpiddir.[ch] to dpi_socket_dir.[ch] New files dpi_service.[ch] Cheers, Ferdi From frank@unternet.org Tue Aug 26 08:38:06 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 26 Aug 2003 09:38:06 +0200 Subject: [Dillo-dev] Frameset & lanlaw.org Message-ID: <20030826073805.GA1003@unternet.org> I just noticed that my current version of the tab+frame patch still has problems with sites like lamlaw.com, which put body content outside of frameset content. Even though this is against the spec, I've changed my current version of the patch so it displays the right (frameset) content for sites like this. BTW, lamlaw.com is really weird... The sequence of tags is html - head - frameset - /frameset - noframes - /head - body - /body - /noframes - /frameset - /html. So, it has frameset inside head (wrong), /head inside noframes, an extra /frameset, etc. The document claims to be html-4.0-transitional. Sure. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From frank@unternet.org Tue Aug 26 10:44:23 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 26 Aug 2003 11:44:23 +0200 Subject: [Dillo-dev] On-line demonstration against software patents in Europe Message-ID: <20030826094423.GC1003@unternet.org> Hi'all, As you might know, the European Parliament will vote on software patents in the EU on the 1st of september 2003. I have added a notice to my patch page (http://www.geocities.com/ikbenfrank) about this. Maybe the main Dillo page can do the same? For more info on this issue, go to http://swpat.ffii.org Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From joerg@britannica.bec.de Tue Aug 26 16:16:47 2003 From: joerg@britannica.bec.de (Joerg Sonnenberger) Date: Tue, 26 Aug 2003 17:16:47 +0200 Subject: [Dillo-dev] libc dependency in 0.8.0pre (bug 487) In-Reply-To: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> References: <Pine.SOL.4.10.10308121615000.8712-100000@jlabs2.jlab.org> Message-ID: <20030826151647.GA15945@britannica.bec.de> --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 12, 2003 at 04:33:43PM -0400, David McKee wrote: > Folks, > Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I > like what I see. When I tried to do the same at work today (Redhat 6.2), I > had problems building. Dpid uses mkdtemp() which was introduced in glibc > 2.1.9. However, ./configure has no problems with my glibc 2.1.3. > > Submitted as bug 487 Could you try the attached patch and report success or failure? Esp. whether the included mkdtemp.c compiles clean and dpiddir.c gets the prototype. Thanks, Joerg --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dillo.diff" --- dillo/dpid/dpiddir.c.orig Fri Aug 8 22:28:02 2003 +++ dillo/dpid/dpiddir.c Tue Aug 26 17:04:09 2003 @@ -1,6 +1,10 @@ #include <errno.h> #include "dpi.h" +#ifndef HAVE_MKDTEMP_H +#include "mkdtemp.h" +#endif + extern int errno; /*! Writes socket directory to DPID_DIR */ @@ -43,9 +47,15 @@ username = g_get_user_name(); template = g_strconcat(ROOTDIR, "/tmp/", username, "-", "XXXXXX", NULL); - mkdtemp(template); - printf("mk_sockdir: socket dir = %s\n", template); - return template; + if(mkdtemp(template)) + { + printf("mk_sockdir: socket dir = %s\n", template); + return template; + } + else + { + printf("mk_sockdir: failed\n"); + } } /*! Creates socket directory if it does not exist and writes its name to @@ -71,6 +81,8 @@ return (sockdir); } else { sockdir = mk_sockdir(); + if(!sockdir) + return (NULL); if ((w_dpid_dir(dpid_dir, sockdir)) == -1) { fprintf(stderr, "init_sockdir: failed to save %s\n", sockdir); if (sockdir) --- dillo/dpid/Makefile.am.orig Fri Aug 8 22:28:02 2003 +++ dillo/dpid/Makefile.am Tue Aug 26 17:05:04 2003 @@ -1,3 +1,4 @@ +INCLUDES = -I../lib bin_PROGRAMS = dpid @@ -11,3 +12,4 @@ dpiddir.c \ misc_new.c \ main.c +dpid_LDADD = -L../lib -ldillo --- dillo/Makefile.am.orig Fri Aug 8 22:27:57 2003 +++ dillo/Makefile.am Tue Aug 26 17:01:22 2003 @@ -1,4 +1,4 @@ -SUBDIRS = doc src dpid dpi +SUBDIRS = lib doc src dpid dpi EXTRA_DIST = ChangeLog.old dillorc --- dillo/configure.in.orig Fri Aug 8 22:27:57 2003 +++ dillo/configure.in Tue Aug 26 17:05:25 2003 @@ -215,10 +215,11 @@ fi AC_CHECK_FUNCS(socket) +AC_REPLACE_FUNCS(mkdtemp) AC_SUBST(LIBJPEG_LIB) AC_SUBST(datadir) AC_SUBST(src doc bin util lib) -AC_OUTPUT(Makefile dpid/Makefile dpi/Makefile doc/Makefile src/Makefile src/IO/Makefile) +AC_OUTPUT(Makefile lib/Makefile dpid/Makefile dpi/Makefile doc/Makefile src/Makefile src/IO/Makefile) --- dillo/lib/Makefile.am.orig Tue Aug 26 17:01:22 2003 +++ dillo/lib/Makefile.am Tue Aug 26 17:06:20 2003 @@ -0,0 +1,8 @@ +noinst_LIBRARIES = libdillo.a +noinst_HEADERS = mkdtemp.h + +libdillo_a_SOURCES = +libdillo_a_LIBADD = @LIBOBJS@ +libdillo_a_DEPENDENCIES = $(libdillo_a_LIBADD) + +EXTRADIST = mkdtemp.c --- dillo/lib/mkdtemp.c.orig Tue Aug 26 17:01:22 2003 +++ dillo/lib/mkdtemp.c Tue Aug 26 17:01:22 2003 @@ -0,0 +1,113 @@ +/* + * Copyright (c) 1987, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include <sys/types.h> +#include <sys/stat.h> +#include <ctype.h> +#include <errno.h> +#include <stdlib.h> +#include <unistd.h> + +char * +mkdtemp(char *path) +{ + char *start, *trv; + pid_t pid; + int rval; + struct stat sbuf; + + if (!path) + return (char*)NULL; + + for (trv = path; *trv; ++trv) + ; + trv--; + if (trv < path) + return (char*)NULL; + pid = getpid(); + while (trv >= path && *trv == 'X' && pid != 0) { + *trv-- = (pid % 10) + '0'; + pid /= 10; + } + while (trv >= path && *trv == 'X') { + char c; + pid = rand() % (26+26); + if (pid < 26) + c = pid + 'A'; + else + c = (pid - 26) + 'a'; + *trv-- = c; + } + start = trv + 1; + + /* + * check the target directory; if you have six X's and it + * doesn't exist this runs for a *very* long time. + */ + for (;; --trv) { + if (trv <= path) + break; + if (*trv == '/') { + *trv = '\0'; + rval = stat(path,&sbuf); + *trv = '/'; + if (rval != 0) + return (char*)NULL; + if (!S_ISDIR(sbuf.st_mode)) { + errno = ENOTDIR; + return (char*)NULL; + } + break; + } + } + + for (;;) { + if (mkdir(path,0700) == 0) + return path; + if (errno != EEXIST) + return (char*)NULL; + for (trv = start;;) { + if (!*trv) + return (char*)NULL; + if (*trv == 'Z') + *trv++ = 'a'; + else { + if (isdigit(*trv)) + *trv = 'a'; + else if (*trv == 'z') /* inc from z to A */ + *trv = 'A'; + else { + ++*trv; + } + break; + } + } + } + /*NOTREACHED*/ +} --- dillo/lib/mkdtemp.h.orig Tue Aug 26 17:06:04 2003 +++ dillo/lib/mkdtemp.h Tue Aug 26 17:01:22 2003 @@ -0,0 +1,6 @@ +#ifndef Mkdtemp_Header +#define Mkdtemp_Header + +char * mkdtemp(char*); + +#endif --FCuugMFkClbJLl1L-- From frank@unternet.org Tue Aug 26 18:54:27 2003 From: frank@unternet.org (Frank de Lange) Date: Tue, 26 Aug 2003 19:54:27 +0200 Subject: [Dillo-dev] [lmettler@lamlaw.com: Re: A few remarks on your site layout...] Message-ID: <20030826175427.GB2479@unternet.org> ----- Forwarded message from Lewis Mettler <lmettler@lamlaw.com> ----- >Thanks for the corrected index.html page for my site. > >You are correct. Some of those tags did appear to be out of place. > >I first wrote that page 5-6 years ago using a program from Corel. It is >not surprising that it was put up incorrectly. Most likely I was trying >several different formats and then stopped screwing with it. I noticed >it still had the NT label embedded. I have not used NT for many years. > >In any event, I edited the version you provided to replace the NT >reference and updated a few of the tags. > >Thanks again. > >And, good fortune with the Dillo browser. > >Let me know if my site now formats correctly using Dillo. Well, it seems to... If only all sites responded as quickly... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] From rower@MovieEditor.com Wed Aug 27 07:10:17 2003 From: rower@MovieEditor.com (Robin Rowe) Date: Tue, 26 Aug 2003 23:10:17 -0700 Subject: [Dillo-dev] CinePaint and Windows port Message-ID: <00c101c36c61$e7dbe000$0200a8c0@tbird> Hi. I'm the project leader for CinePaint, an open source paint program used mainly by the motion picture industry. Our code was branched from GIMP in 1998. How would the Dillo project feel about Dillo being embedded in another application as a help browser? We're looking for a new help system browser and considering Dillo. We are impressed how compact your implementation is. We only need a limited set of HTML features: links, images, tables, bullet lists, number lists, headings, ordinary text, bold, and italic. In these features we need the browser to be absolutely stable. Any issues there? We support all platforms, including Windows. One of the first things I would intend to do is port Dillo to Windows. I saw in your archives that you had made some effort in that direction, but it seemed to peter out. What are the problems? Thanks! Robin --------------------------------------------------------------------------- Robin.Rowe@MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software From Jewen_Luo@163.com Wed Aug 27 07:17:28 2003 From: Jewen_Luo@163.com (ÂÞ½¨ÎÄ) Date: Wed, 27 Aug 2003 14:17:28 +0800 Subject: [Dillo-dev] tab and frames in webmail Message-ID: <20030827061930.CC48A1C730693@sm205.163.com> hi, Frank de Lange: =09I apply you dillo tab frame patch,and it seem very cool. But= when I go to the www.163.com and www.163.net, I found I can't go= into my mailbox.It only says that "This page uses frames, but= your browser doesn't support them."And the statusbar shows= "Contacting host", for ever. In windows IE I can see the= soursecode of that page as following: <!-- CoreMail Version 2.0(Build sol7-x86-030416) Copyright (c)= 2000 Tebie Limited --><html><head> <title>=CD=F8=D2=D7=D3=CA=BC=FE=CF=B5=CD=B3</title> <meta http-equiv=3D"Content-Type" content=3D"text/html;= charset=3Dgb2312"> </head> <frameset frameborder=3DNO rows=3D80,* border=3D0 framespacing=3D0> <frame name=3D"2" src=3D"/newtop.htm" target=3Dcontents scrolling=3DNO= marginwidth=3D0 marginheight=3D0 frameborder=3DNO > <frameset border=3D0 cols=3D160,* framespacing=3D0 marginheight=3D0= marginwidth=3D0 frameborder=3DNO> <frame name=3D"folder"= src=3D"/cgi/ldapapp?funcid=3Dsimplefdr&sid=3DDBTpkvElTAQAKUwf"= target=3Drtop marginwidth=3D0 marginheight=3D0 frameborder=3DNO= scrolling=3Dyes> <!-- frame name=3D"folder"= src=3D"/cgi/ldapapp?funcid=3Dfolder&amp;funcid=3Dmain&amp;sid=3DDBTpkvEl= TAQAKUwf&amp;websid=3DDBTpkvElTAQAKUwf&amp;unfolded=3D0," target=3Drtop= marginwidth=3D0 marginheight=3D0 frameborder=3DNO scrolling=3Dyes --> <frame name=3D"main"= src=3D"/cgi/ldapapp?funcid=3Dfoldmain&amp;sid=3DDBTpkvElTAQAKUwf"= target=3Drbottom marginwidth=3D0 marginheight=3D0 scrolling=3DAUTO= frameborder=3DNO> </frameset> </frameset> <noframes> <body bgcolor=3D"#FFFFFF"><p>This page uses frames, but your= browser doesn't support them.</p> </body> What's wrong? =09=09=09best reguards =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Jewen_Luo@163.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-08-27 From melvin.hadasht@free.fr Wed Aug 27 14:38:24 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Wed, 27 Aug 2003 15:38:24 +0200 Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <20030827130253.29149.qmail@skywalker.bsws.de> References: <20030819193319.18046.qmail@skywalker.bsws.de> <20030824012433.9126.qmail@skywalker.bsws.de> <20030827130253.29149.qmail@skywalker.bsws.de> Message-ID: [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to the list and will respond when I have time and when I have something to respond.] Hi, > ok, dillo never reloads the images, not even on manual reloads - still > showing days old stats. > you think that is fixeable soon, for some value of "soon"? I don't always have time for Dillo. Maybe this weekend, maybe the next. Concerning the reload time, I should be able to fix it when I have time. Concerning the cached images, I will need more time. Concerning the "void" input driver, is the coredump due to my patch? -- Melvin Hadasht From madis@ats.cyber.ee Wed Aug 27 15:02:51 2003 From: madis@ats.cyber.ee (Madis Janson) Date: Wed, 27 Aug 2003 17:02:51 +0300 (EEST) Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: References: <20030819193319.18046.qmail@skywalker.bsws.de> <20030824012433.9126.qmail@skywalker.bsws.de> <20030827130253.29149.qmail@skywalker.bsws.de> Message-ID: On Wed, 27 Aug 2003, Melvin Hadasht wrote: > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > the list and will respond when I have time and when I have something to respond.] > > Hi, > > > ok, dillo never reloads the images, not even on manual reloads - still > > showing days old stats. > > you think that is fixeable soon, for some value of "soon"? > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > This patch (although not up-to-date for current dillo version) has capability to reload things, when it has been requested with expires/no-cache/cache-control headers. http://www.zone.ee/myzz/dillo/dillo-cache-control.diff Since the dillo cache has not changed much lately, it probably applies with minor conflicts. Version for dillo 0.7.3+tabs is part of patch described here: http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html But it doesn't make dillo reload images, when reload button has been pressed. imho mozilla/ie doesn't do it eighter by default (you have to press shift-reload to make them reload images). From jcid@softhome.net Wed Aug 27 15:31:37 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Wed, 27 Aug 2003 10:31:37 -0400 (CLT) Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: References: <20030819193319.18046.qmail@skywalker.bsws.de> <20030824012433.9126.qmail@skywalker.bsws.de> <20030827130253.29149.qmail@skywalker.bsws.de> Message-ID: On Wed, 27 Aug 2003, Madis Janson wrote: > > On Wed, 27 Aug 2003, Melvin Hadasht wrote: > > > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > > the list and will respond when I have time and when I have something to respond.] > > > > Hi, > > > > > ok, dillo never reloads the images, not even on manual reloads - still > > > showing days old stats. > > > you think that is fixeable soon, for some value of "soon"? > > > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > > > > This patch (although not up-to-date for current dillo version) has > capability to reload things, when it has been requested with > expires/no-cache/cache-control headers. > > http://www.zone.ee/myzz/dillo/dillo-cache-control.diff > > Since the dillo cache has not changed much lately, it probably applies > with minor conflicts. > > Version for dillo 0.7.3+tabs is part of patch described here: > http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html > > But it doesn't make dillo reload images, when reload button has been > pressed. imho mozilla/ie doesn't do it eighter by default (you have to > press shift-reload to make them reload images). Believe it or not I've being reviewing the patch these days and it's in my short-term list of duties! A lot of project managing (meetings, conversations, emails, projection requests, etc, etc, etc.) workload has come my way. I expect to be more coding-active next month. Some very good news may happen. Cross fingers! Jorge.- From jcid@softhome.net Thu Aug 28 13:52:03 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Thu, 28 Aug 2003 08:52:03 -0400 (CLT) Subject: [Dillo-dev] Running external Gtk programs under Tabs (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 27 Aug 2003 23:48:14 -0700 From: t To: Jorge Arellano Cid Subject: Running external Gtk programs under Tabs Jorge, Please forward this to the dillo/dev mailing list unless you think it is not appropriate. Nice job on dillo, guys! Have been using it since at least 0.2.1. Nice work on the tabs, Frank. They have added a whole new dimension to dillo. Recently, while working on a multi-media project, noticed that I had way too many instances of a text editor open. Couldn't easily find the desired file. About then Frank put up the tab/frame patch. Spent a day or so getting external Gtk apps to run in a tabbed window. This turned dillo into an MDI interface with built-in file picker and HTML help file viewer. This has been working for me in a stable manner, e.g. no seg faults, for about two weeks under heavy use. Which means it will only take someone else about 5 minutes to induce a failure:-). Have modified a file manager, my personal text editor and the erwin HTML editor to run as client Gtk apps, just like dillo. As a matter of fact, dillo can run itself as an external Gtk app in a tabbed window. The patch file for the tab/frame patched version of dillo is set up to do this as a working example. You can download it from: http://www.users.qwest.net/~loveall/xid8-patch.gz !!!! NOTE !!!! This patch is valid only on dillo-0.7.3 patched with Franks version 9 tab/frame patch: http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz To modify a typical Gtk app to act as a client requires just the following: In function main(), add these lines at the beginning just after the data declarations: guint32 xid = 0; int i = 1; if (i < argc-1 && !strcmp(argv[i++],"-x")){ xid = strtol(argv[i], NULL, 10); argc -= 2; argv += 2; if(xid == LONG_MIN || xid == LONG_MAX) xid = 0; } This requires that the first two args when calling dillo be '-x '. Find and replace the (typically) single line: main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); with: if(!xid) main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); else main_window = gtk_plug_new (xid); See also the working source which references 'xid' in dillo.c and interface.c. Thanks again, to the dillo crew. You guys are awesome. Regards, Terry Loveall From jcid@softhome.net Thu Aug 28 14:53:08 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Thu, 28 Aug 2003 09:53:08 -0400 (CLT) Subject: [Dillo-dev] CinePaint and Windows port In-Reply-To: <00c101c36c61$e7dbe000$0200a8c0@tbird> References: <00c101c36c61$e7dbe000$0200a8c0@tbird> Message-ID: On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.- From rower@MovieEditor.com Thu Aug 28 16:40:02 2003 From: rower@MovieEditor.com (Robin Rowe) Date: Thu, 28 Aug 2003 08:40:02 -0700 Subject: [Dillo-dev] Dillo Windows port References: <00c101c36c61$e7dbe000$0200a8c0@tbird> Message-ID: <019b01c36d7a$a86588d0$0200a8c0@tbird> Jorge, I have Dillo built now as a native Windows VC++ 6 project and am debugging it. Seems to be my unstable 1.14 version of GTK for Windows that is causing Dillo to hang on load. By the way, I'm the new GTK1 for Windows maintainer. Tor and GIMP for Windows are moving to GTK2, but CinePaint is staying with GTK1. Can we talk about Dillo design portability a bit? Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process API? Shouldn't it be all pthreads? Of course, there is no fork under Windows. There isn't any pthreads either, but I've written a light emulation library (as yet untested) that calls Windows threads instead. You are using mutex and conditional pthreads together, which seems redundant. Are both needed? Could you use just a mutex? What is that code supposed to do and why? Another call unavailable in Windows is fcntl(). I've conditionally compiled those out, and don't know yet what that may effect. Although Berkeley sockets are available in Windows, the AF_LOCAL protocol doesn't seem to be. I've faked that out to get Dillo to compile but more work may be needed there. Why are you using AF_LOCAL? What does that code do and why? Can you tell me about your internationalization support in Dillo? How is that set up? What is it designed to handle? Thanks, Robin --------------------------------------------------------------------------- Robin.Rowe@MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software From superluser@frontiernet.net Thu Aug 28 17:57:36 2003 From: superluser@frontiernet.net (Andrew A. Gill) Date: Thu, 28 Aug 2003 12:57:36 -0400 (EDT) Subject: [Dillo-dev] Rendering problem Message-ID: I've been having a problem with dillo rendering some portions of text. For instance, the Google sponsored links always take up vertical space before the results. Normally, this isn't something that I really care about, but now it's causing slashdot to be rendered as black-on-black text, thus depriving me of my ability to read about the new MD5 sums that the RIAA is using. (bug 493) -- |Andrew A. Gill |I posted to Silent-Tristero and| | |all I got was this stupid sig! | |alt.tv.simpsons CBG-FAQ author | | | (Report all obscene mail to Le Maitre Pots)| |Nothing here yet: Temporary sig: -- But thanks for everything else. From melvin.hadasht@free.fr Thu Aug 28 16:34:46 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Thu, 28 Aug 2003 17:34:46 +0200 Subject: [Dillo-dev] [Long] dillo server mode/remote control (was: Re: dillo / time-controlled reloads) In-Reply-To: References: <20030819193319.18046.qmail@skywalker.bsws.de> <20030820194041.28849.qmail@skywalker.bsws.de> Message-ID: Hi, > A simple flag, maybe in the DilloUrl or in the cache entry. In the posted patch, I just added a reload_timeout in DilloUrl and a reload_timeout_tag in BrowserWindow. When viewing a DilloUrl with a non-zero DilloUrl::reload_timeout, BrowserWindow will start a single shot timer which tag is saved in BrowserWindow::reload_timeout_tag. This timer will trigger a reload (as if the user hit the reload button). The reload will restart the timer. If another DilloUrl is viewed, any pending timer is stopped (and the new DilloUrl is again tested for a non-zero DilloUrl::reload_timeout). I also added a_Url_set_reload() to set/unset that reload_timeout. > > - add a "-r, --reload-every" command line option that calls that function. > > In fact, when I finish implementing the "(remote-)command" option, it would be > > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > > supporting commands with more than one argument is worth the work). > > Hmmm, I think a simple cli switch to tell dillo to listen to > the reloads.dpi is enough: > > dillo -reloads Internally, the command line options are translated to a linked list of commands, which are executed by the running instance, or sent to a running server. So I implemented both. The advantage of the "-c" option is that commands could support parameters as in: "open(URL newwindow reload=50)". It adds flexibility. > > > > The first duty is to define what is required for a good, > > > > general purpose, kind of reloading dpi. The next one is to reduce > > > > the features to a minimum working set, then implement! I think it is easier to implement a remote command dpi than implementing a "reload dpi". The "reload" should only be one of the remote commands that a server must understand. > fprintf(reloads_dpi_socket, > "push http://localhost/someurl visible\n"); > > may be all the client program needs to know. Unfortunatly, fprintf does not work with Unix Domain Sockets but with pipes. Pipes have a limitation: if more than a client access to the pipe, the server could get mixed-up commands if the clients commands are larger than a system specific buffer size. For robustness, I will use UDS. If a client program wants to use dillo server capability, then we'd better provide a lib or a small C file. > Note that it may be good to integrate the remote control > functionality into the same dpi (and maybe call it remote.dpi?). Yes, I agree, the reload (and other functions) should be served by the remote control functionality. Whether it should be a plugin, I am not completly convinced, because it adds a little more complexity: At the current state of the dpid, we cannot run more than one dillo server (if we make exclusive use of the dpid framework). This is because for each service, there is only one socket. I think it is more flexible to have the possibility to have different dillo servers, each one with a distinct name provided by the user (or the application). For that, dpid should accept an additional parameter which is used to parametrize the socket name, e.g.: dpid will then look if a socket named: "/tmp/$USER-$RAND/dillo-server-$PARAM" ($PARAM being the value of the param tag) exist. If it does not exist, it would start the plugin with a special command line option: dillo -s $PARAM. This will require a way to tell the dpid how to call a parametrized plugin. Thus, relying on dpid to create the socket and run the server plugin would need some changes to dpid. An alternative solution, is to not rely on dpid but on dillo itself to start a server and to create the socket. The socket will be independent from the dpi_dir, and would be /tmp/dillo-$USER-$SERVERNAME. Subsequent communications could still use dpid's I/O functions. > This means adding a simple and useful API for help programs to > use. For instance to let them push new URLs into the same > instance of dillo (and not having to start a new dillo per > requested page). (if the application never starts a dillo instance, then there is no guarantee that there is a dpid running. Or you meant the API should take care of this, too?) >From the client side, running a new dillo instance per requested page is the most easy implementation. It just runs "dillo -s SERVERNAME URL" for each URL it needs. It would not care about non-existing instances or sockets: if the user closed the dillo server, the new instance will be the server, and the next instance will just be the client. Of course, this does not prevent the application to directly connect to the server's socket and push URLs into it, but then it will need to handle socket interruptions and server start-ups if no server is already running (of course, we could provide a library that will take care of that, but that would also mean the application should adapt itself to dillo. Whereas, the simple new-client-instance per requested URL can be beneficial to any app that allow the user to set the browser (for example: pan, gaim...)) > Ex: > > The client app. asks the remote control dpi whether there's a > running instance of dillo. > > YES -> send new to-be-pushed URL > > NO -> start "dillo -rc" (remote control) > send new to-be-pushed URL We should provide a lib (API) for this. Here is a summary of my idea about this feature: Dillo Side (Client or Server): - each dillo server has a distinct name which defines the socket name - when dillo is run with -s SERVER_NAME and no such server exist, it becomes this server. If the server exists, it will supply it with the command line options it had. The way the socket is named and created is the core of the problem: - The dpid approach: I already mentioned above the dpid should be extended for that. I think this approach introduces a level of complexity that is not really worth, in my opinion. Indeed, each Dillo client will 1. make sure dpid runs, 2. access to a resource file to find the dpid socket, 3. send the request to the dpid 4. get the socket name of the server from the dpi 5. send commands to the server socket. Dpid is then responsible for starting the dillo server instance, if none existed before. An application that wants to access directly to the server, must also make sure that dpid is running. - The straightforward approach: Each dillo instance launched with -s SERVERNAME checks if the socket /tmp/dillo-$USER-$SERVERNAME already exist. If yes, it sends the commands to it and exists. If no, it creates the socket and executes the commands itself. Each dillo client instance will not need to read any ressources file. An application that wants to access directly to the server must just run one instance of dillo once, and then connect to the socket. If the socket connection fails, it has to rerun dillo. Of course, I rely on the fact that /tmp is an available directory, but IIRC, dpid also relies on this fact. Application Side: Two possibilities: a) it just run simply "dillo -s SERVERNAME URL" for each URL it wants. b) it uses some kind of lib which starts once 'dillo -s SERVERNAME' and then uses directly the socket: the API would be something like: /* Create a handle to a dillo server. This will run "dillo -s servername" and will retrieve the socket name and connect to it (using a private DilloServer_connect()). dillo -s servername is responsible for creating the socket */ DilloServer *a_DilloServer_new(char *servername); /* Send some command to the server. If the socket is interrupted, it calls DilloServer_connect()) */ a_DilloServer_send(DilloServer *server, char *cmd); /* We can add some wrapper function for the easiest commands: */ a_DilloServer_open(DilloServer *server, char *url); /* (which uses a_DilloServer_send()) */ a_DilloServer_fullwindow(DilloServer *server); /* hide control UI */ a_DilloServer_maximize(DilloServer *server); /* Make the window bigger */ a_DilloServer_exit(DilloServer *server); /* stops the running server */ /* Disconnect and free ressources. It should not stop the server instance */ a_DilloServer_free(DilloServer *server); Obviously, option a) does not need any changes to the application, if it provides a way for the user to define the command line to start a browser. Option b) is more intrusive (but more efficient). From nigel@waspz.plus.com Thu Aug 28 20:35:27 2003 From: nigel@waspz.plus.com (Nigel Wilkinson) Date: Thu, 28 Aug 2003 20:35:27 +0100 Subject: [Dillo-dev] Problems with tab patch Message-ID: <20030828203527.314a103f.nigel@waspz.plus.com> Evenin' all I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch Cheers Nigel From frank@unternet.org Thu Aug 28 21:10:26 2003 From: frank@unternet.org (Frank de Lange) Date: Thu, 28 Aug 2003 22:10:26 +0200 Subject: [Dillo-dev] Rendering problem In-Reply-To: References: Message-ID: <20030828221026.37196b09.frank@unternet.org> --9MSIOJY=.3p/8AFD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) "Andrew A. Gill" wrote: > I've been having a problem with dillo rendering some portions of text. > For instance, the Google sponsored links always take up vertical space > before the results. > > Normally, this isn't something that I really care about, but now it's > causing slashdot to be rendered as black-on-black text, thus depriving me > of my ability to read about the new MD5 sums that the RIAA is using. Off Topic, but... slashdot on Dillo works best when you use Slashdot's 'light' mode... No more annoying pictures, colors or other crap, just the 'facts' (if facts and slashdot can be named in the same sentence...). You need to be logged in to use light mode. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] --9MSIOJY=.3p/8AFD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TmG6Hix/Y3iPAgcRArZVAKC6ggMU3XqwlNO1PTsWDfwcSHzGkQCeIsu/ Hqqcn7t0IZT4KwmLx6nK1t0= =Hmcl -----END PGP SIGNATURE----- --9MSIOJY=.3p/8AFD-- From frank@unternet.org Thu Aug 28 21:19:29 2003 From: frank@unternet.org (Frank de Lange) Date: Thu, 28 Aug 2003 22:19:29 +0200 Subject: [Dillo-dev] Problems with tab patch In-Reply-To: <20030828203527.314a103f.nigel@waspz.plus.com> References: <20030828203527.314a103f.nigel@waspz.plus.com> Message-ID: <20030828221929.59c0b641.frank@unternet.org> --=..z8Lv(CWw)gj7g Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 28 Aug 2003 20:35:27 +0100 Nigel Wilkinson wrote: > > Evenin' all > > I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch You need to cd to the dillo directory before applying the patch: Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) % cd dillo_tabs (go to the new dir) % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) % ./autogen.sh (generate configure and Makefile.in) % ./configure (with whatever options you prefer) % make % make install Easy, not? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] --=..z8Lv(CWw)gj7g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TmPWHix/Y3iPAgcRAutLAJ0XPjEJnsfJIKhf7OY/9771G8ciQwCgsGqB 8pvetExj03eOfiFtaezpLro= =IpEt -----END PGP SIGNATURE----- --=..z8Lv(CWw)gj7g-- From nigel@waspz.plus.com Thu Aug 28 22:00:26 2003 From: nigel@waspz.plus.com (Nigel Wilkinson) Date: Thu, 28 Aug 2003 22:00:26 +0100 Subject: [Dillo-dev] Problems with tab patch In-Reply-To: <20030828221929.59c0b641.frank@unternet.org> References: <20030828203527.314a103f.nigel@waspz.plus.com> <20030828221929.59c0b641.frank@unternet.org> Message-ID: <20030828220026.71aa1f26.nigel@waspz.plus.com> On Thu, 28 Aug 2003 22:19:29 +0200 Frank de Lange wrote: > You need to cd to the dillo directory before applying the patch: > > Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): > > % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) > % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) > % cd dillo_tabs (go to the new dir) > % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) > % ./autogen.sh (generate configure and Makefile.in) > % ./configure (with whatever options you prefer) > % make > % make install > Great, worked a treat but just for my info where was I going wrong in the following 1. I was gunzipping the patch file 2. I was useing 'patch < dillo-20030821-tabs.patch' if my CVS source was in ~/Source/dillo I tried this from ~/Source, ~/Source/dillo, and ~/Source/dillo/src I also tried the above as 'patch -p1 < dillo-20030821-tabs.patch' as well as -p2, -p3 etc The command 'patch < dillo-20030821-tabs.patch' came from the man page so I just wondered why it didn't work. If I understand things correctly in the command 'zcat dillo-20030821-tabs.patch.gz | patch -p1' that worked zcat decompresses the zipped dillo patch and pipes it to patch. Why is this different from 'patch -p1 < dillo-20030821-tabs.patch' Cheers Nigel From ralph@genesys.ro Thu Aug 28 22:19:44 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Thu, 28 Aug 2003 23:19:44 +0200 Subject: [Dillo-dev] Rendering problem In-Reply-To: References: Message-ID: <20030828231944.52c8582a.ralph@genesys.ro> --=.Tkqozi9uv2Ib1+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) "Andrew A. Gill" wrote: > I've been having a problem with dillo rendering some portions of text. > For instance, the Google sponsored links always take up vertical space > before the results. > > Normally, this isn't something that I really care about, but now it's > causing slashdot to be rendered as black-on-black text, thus depriving me > of my ability to read about the new MD5 sums that the RIAA is using. Yes, I'm getting this too since today. It's probably a small html error somewhere, but it's totally skrewed up dillo's rendering to the fullest here. Since about 2 weeks ago I'm also getting a black border on the right (with exception to today of course where most of the page is black) which just takes up valuable space ;-) Tried the light mode too like Frank suggests, but I prefer the default layout myself. Anyway, it's not a dillo problem I think, as I get a total of 530 errors just on the index page itself!!!!! Check now too if ya want: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org%2F Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --=.Tkqozi9uv2Ib1+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TnHzAWKxH5yWMT8RAoslAKC7owiL3ljzorUqCp8K+49mrEr8iQCgqldb s7JH5GaV3KgNAMjpXkv6KQI= =vLkW -----END PGP SIGNATURE----- --=.Tkqozi9uv2Ib1+-- From rower@MovieEditor.com Thu Aug 28 22:23:52 2003 From: rower@MovieEditor.com (Robin Rowe) Date: Thu, 28 Aug 2003 14:23:52 -0700 Subject: [Dillo-dev] Dillo Windows port IO_submit References: <00c101c36c61$e7dbe000$0200a8c0@tbird> <019b01c36d7a$a86588d0$0200a8c0@tbird> Message-ID: <033d01c36daa$af725740$0200a8c0@tbird> Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows offers only blocking io on pipes. The usual way to deal with this is to spin off read or write into another thread where it can block without hanging the program. Your io scheme is complicated enough that it isn't immediately obvious how best to do that. Can somebody offer more insight into the code below or offer any suggestions? How long does an IO_submit operation stay open and what data is transmitted normally? What dialog is expected across the pipe? Thanks, Robin /* * Receive an IO request (IORead | IOWrite | IOWrites), * Set the GIOChannel and let it flow! */ static void IO_submit(IOData_t *r_io) { /* Insert this IO in ValidIOs */ IO_ins(r_io); #ifdef WIN32 /* Launch thread? */ #else /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, O_NONBLOCK | fcntl(r_io->FD, F_GETFL)); fcntl(r_io->FD, F_SETFD, FD_CLOEXEC | fcntl(r_io->FD, F_GETFD)); #endif if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } else if ( r_io->Op == IOWrite || r_io->Op == IOWrites ) { g_io_add_watch(r_io->GioCh, G_IO_OUT | G_IO_ERR, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } } --------------------------------------------------------------------------- Robin.Rowe@MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software From melvin.hadasht@free.fr Thu Aug 28 23:31:32 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Fri, 29 Aug 2003 00:31:32 +0200 Subject: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads) In-Reply-To: <20030823233721.26812.qmail@skywalker.bsws.de> References: <20030819193319.18046.qmail@skywalker.bsws.de> <20030823233721.26812.qmail@skywalker.bsws.de> Message-ID: > there are two small problems: > -if you specify a small reload time, and by that time is over before > the page is actually loaded -> coredump Does not core dump for me. Where does it core dump? I tried "dillo -r 1 http://freshmeat.net" and it reloads the page before it is finished loading. Or by "actually loaded" you mean "did not *start* to load" ? From Andreas.Schweitzer@hs.uni-hamburg.de Fri Aug 29 00:52:39 2003 From: Andreas.Schweitzer@hs.uni-hamburg.de (Andreas Schweitzer) Date: Fri, 29 Aug 2003 01:52:39 +0200 Subject: [Dillo-dev] Dillo Windows port In-Reply-To: <019b01c36d7a$a86588d0$0200a8c0@tbird> References: <00c101c36c61$e7dbe000$0200a8c0@tbird> <019b01c36d7a$a86588d0$0200a8c0@tbird> Message-ID: <20030828235238.GA3538@hs.uni-hamburg.de> Hi, although I'm not a main developer, I think I can answer a bit. > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. cool ! > Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process > API? Shouldn't it be all pthreads? Of course, there is no fork under In the current CVS version I only found one reference to fork and it was to start a plugin. Currently, this is no longer used and is dead code. However, some way of starting the dpid automatically will most likely return - for the current CVS version this dpid has to be started manually. But either way, the plugins and the dpid are totally seperate programs. dpid is designed to only be started once. This functionality should be reproducable in Windows, I'd say :-) The other fork's are within the plugin framework when the dpid actually starts the requested plugin. You probably can delay that framework. Dillo will still work - with limited functionality. > Although Berkeley sockets are available in Windows, the AF_LOCAL protocol > doesn't seem to be. I've faked that out to get Dillo to compile but more > work may be needed there. Why are you using AF_LOCAL? What does that code do > and why? It's again related to plugins :-) ... dillo talks to its plugins via unix domain sockets. And that's what this code relates to. If you only need a help browser, you can ignore the plugin framework I would say. That way you will get no bookmarks, though. And the preferences are also planned to be done via a plugin. Or at least delay the plugin stuff until it matured. That's the cool part about the plugin design :-) I hope that helps, Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 From madis@ats.cyber.ee Fri Aug 29 00:58:49 2003 From: madis@ats.cyber.ee (Madis Janson) Date: Fri, 29 Aug 2003 02:58:49 +0300 (EEST) Subject: [Dillo-dev] Dillo Windows port IO_submit In-Reply-To: <033d01c36daa$af725740$0200a8c0@tbird> References: <00c101c36c61$e7dbe000$0200a8c0@tbird> <019b01c36d7a$a86588d0$0200a8c0@tbird> <033d01c36daa$af725740$0200a8c0@tbird> Message-ID: On Thu, 28 Aug 2003, Robin Rowe wrote: > Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows > offers only blocking io on pipes. The usual way to deal with this is to spin > off read or write into another thread where it can block without hanging the > program. Your io scheme is complicated enough that it isn't immediately > obvious how best to do that. > > Can somebody offer more insight into the code below or offer any > suggestions? How long does an IO_submit operation stay open and what data is > transmitted normally? What dialog is expected across the pipe? Use two connected sockets instead of the pipe. You can create such pair for example by listening random port (bind to port 0) and connecting to address found out using getsockname. From frank@unternet.org Fri Aug 29 07:07:57 2003 From: frank@unternet.org (Frank de Lange) Date: Fri, 29 Aug 2003 08:07:57 +0200 Subject: [Dillo-dev] Problems with tab patch In-Reply-To: <20030828220026.71aa1f26.nigel@waspz.plus.com> References: <20030828203527.314a103f.nigel@waspz.plus.com> <20030828221929.59c0b641.frank@unternet.org> <20030828220026.71aa1f26.nigel@waspz.plus.com> Message-ID: <20030829080757.5a6de2f0.frank@unternet.org> --=.UM+t,lpdLxVnS6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 28 Aug 2003 22:00:26 +0100 Nigel Wilkinson wrote: > Great, worked a treat but just for my info where was I going wrong in the following > > 1. I was gunzipping the patch file > 2. I was useing 'patch < dillo-20030821-tabs.patch' > if my CVS source was in ~/Source/dillo I tried this from ~/Source, ~/Source/dillo, and ~/Source/dillo/src > I also tried the above as 'patch -p1 < dillo-20030821-tabs.patch' as > well as -p2, -p3 etc > > The command 'patch < dillo-20030821-tabs.patch' came from the man page > so I just wondered why it didn't work. Well, this should also work: (on a clean, non-patched, not even partly patched source tree) cd ~/Source/dillo patch -p1 < /path/to/dillo-20030821-tabs.patch If it did not, either your source or uncompressed patch is not what it should be. Or you forgot to give the exact path to the patch file? > If I understand things correctly in the command 'zcat > dillo-20030821-tabs.patch.gz | patch -p1' > that worked zcat decompresses the zipped dillo patch and pipes it to > patch. Why is this different from > 'patch -p1 < dillo-20030821-tabs.patch' There is no real difference (zcat is more practical, as you do not have to uncompress the patch). Both commands should have the same results. If not, something weird is happening. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] --=.UM+t,lpdLxVnS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Tu3GHix/Y3iPAgcRAqBuAJsGQlzYJd5OQQLdoydSceu1DqGs6QCfdjI7 Lv1WOozetb4Sm+VvpLEs0ds= =z6lq -----END PGP SIGNATURE----- --=.UM+t,lpdLxVnS6-- From lars.segerlund@comsys.se Fri Aug 29 08:51:52 2003 From: lars.segerlund@comsys.se (Lars Segerlund) Date: Fri, 29 Aug 2003 09:51:52 +0200 Subject: [Dillo-dev] Running external Gtk programs under Tabs (fwd) In-Reply-To: References: Message-ID: <3F4F0618.4010201@comsys.se> very cool ! :-D BIG SMILEY Jorge Arellano Cid wrote: > > ---------- Forwarded message ---------- > Date: Wed, 27 Aug 2003 23:48:14 -0700 > From: t > To: Jorge Arellano Cid > Subject: Running external Gtk programs under Tabs > > Jorge, > > Please forward this to the dillo/dev mailing list unless you think it is not > appropriate. > > Nice job on dillo, guys! Have been using it since at least 0.2.1. > > Nice work on the tabs, Frank. They have added a whole new dimension to dillo. > > Recently, while working on a multi-media project, noticed that I had way too > many instances of a text editor open. Couldn't easily find the desired > file. > > About then Frank put up the tab/frame patch. Spent a day or so getting > external Gtk apps to run in a tabbed window. This turned dillo into an MDI > interface with built-in file picker and HTML help file viewer. > > This has been working for me in a stable manner, e.g. no seg faults, for about > two weeks under heavy use. Which means it will only take someone else about 5 > minutes to induce a failure:-). > > Have modified a file manager, my personal text editor and the erwin HTML > editor to run as client Gtk apps, just like dillo. As a matter of fact, dillo > can run itself as an external Gtk app in a tabbed window. The patch file for > the tab/frame patched version of dillo is set up to do this as a working > example. You can download it from: > http://www.users.qwest.net/~loveall/xid8-patch.gz > > !!!! NOTE !!!! > This patch is valid only on dillo-0.7.3 patched with Franks version 9 > tab/frame patch: > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > > To modify a typical Gtk app to act as a client requires just the following: > > In function main(), add these lines at the beginning just after the data > declarations: > > guint32 xid = 0; > int i = 1; > > if (i < argc-1 && !strcmp(argv[i++],"-x")){ > xid = strtol(argv[i], NULL, 10); > argc -= 2; > argv += 2; > if(xid == LONG_MIN || xid == LONG_MAX) xid = 0; > } > > This requires that the first two args when calling dillo be '-x '. > > Find and replace the (typically) single line: > > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > > with: > if(!xid) > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > else > main_window = gtk_plug_new (xid); > > See also the working source which references 'xid' in dillo.c and interface.c. > > Thanks again, to the dillo crew. You guys are awesome. > > Regards, > Terry Loveall > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From jcid@softhome.net Fri Aug 29 15:34:28 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 29 Aug 2003 10:34:28 -0400 (CLT) Subject: [Dillo-dev] Rendering Message-ID: Hi Sebastian! Hope you're not under a pile of workload... Please review this site: http://cocoon.apache.org/index2.html When loaded slowly (dialup speed) it renders the leftmost column too wide (almost a screen), but Back&Forward fixes it. I you can also give a look at the slashdot problem it'd be great. I'm much more interested in the first though. Regards Jorge.- From jcid@softhome.net Fri Aug 29 15:31:29 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Subject: [Dillo-dev] Rendering problem Message-ID: On Thu, 28 Aug 2003, Ralph Slooten wrote: > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > "Andrew A. Gill" wrote: > > > I've been having a problem with dillo rendering some portions of text. > > For instance, the Google sponsored links always take up vertical space > > before the results. > > > > Normally, this isn't something that I really care about, but now it's > > causing slashdot to be rendered as black-on-black text, thus depriving me > > of my ability to read about the new MD5 sums that the RIAA is using. > > Yes, I'm getting this too since today. It's probably a small html error > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. Unfortunately slashdot is sending awful HTML-like content. The black text can be explained because they explicitly set the background, textcolor and visited links to black! (). Probably it changes with CSS. > > Since about 2 weeks ago I'm also getting a black border on the right (with > exception to today of course where most of the page is black) which just takes > up valuable space ;-) > > Tried the light mode too like Frank suggests, but I prefer the default layout > myself. Anyway, it's not a dillo problem I think, as I get a total of 530 errors > just on the index page itself!!!!! Check now too if ya want: > http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org%2F Try with "force_my_colors=YES". Now, it still shows several rendering problems. If those are because of lack of implementation of "floats" we should fix it someday. If it's because of bad HTML, you know our policy. OTOH, I believe slashdot webmasters will not pose major problems to fix their HTML if they're emailed with the facts... Please investigate those and report to them. Cheers Jorge.- From jcid@softhome.net Fri Aug 29 15:31:48 2003 From: jcid@softhome.net (Jorge Arellano Cid) Date: Fri, 29 Aug 2003 10:31:48 -0400 (CLT) Subject: [Dillo-dev] Re: Tab + frame patch, any progress? Message-ID: On Wed, 27 Aug 2003, Frank de Lange wrote: > Any progress on the CSS front by the way? Sometime ago we concluded with Sebastian that it may take near three months of work of both of us. We're focusing on other priorities now. I hope we can review your patch soon with him. Cheers Jorge.- From melvin.hadasht@free.fr Fri Aug 29 17:11:37 2003 From: melvin.hadasht@free.fr (Melvin Hadasht) Date: Fri, 29 Aug 2003 18:11:37 +0200 Subject: [Dillo-dev] [PATCH] Server Mode (was: commands & auto-reload) In-Reply-To: References: <20030819193319.18046.qmail@skywalker.bsws.de> Message-ID: --3f4f840b_5db70ae5_5d6 Content-Type: text/plain Content-Transfer-Encoding: 8bit Hi, I previously posted a "command" patch as a preliminary for the server mode patch for Dillo. It was about handling the list of commands to be sent to the server. The hereby attached patch already contains that patch slightly modified and adds the ability to eventually switch to server mode or to connect and send the commands to a server This patch does not solve the "reload" bugs. I have a web page (user oriented) at: http://melvin.hadasht.free.fr/home/dillo/server/index.html I finally chose the "straightforward" approach instead of the dpid approach. Two reasons for that: i) I felt it'd introduce more complexity, especially for a client instance that needs to connect to a server and ii) the current dpid allows only one socket per service while it would be needed to have more than one Dillo server. I already explained in another mail that the socket name would need to be parametrized (by the server name, for example). Of course, this patch of mine is just a suggestion, if others feels that the dpid approach is better and more efficient, I'd be happy to see how they implemented it. The "commands" patch could still be used. They just need to handle the server/client connection. The hereby attached patch has the following characteristics: - gtk_init() is never called by a client instance - if the XID option is given, and if the server already has an embedded window with that XID, it will reuse it. - an application can still directly access to the server socket and can keep the connection open until it really does not need it. It has to check whether /tmp/dillo-$USER-$SERVERNAME exists. If not, it should launch "dillo -s $SERVERNAME". Then it should open that Unix Domain Socket. Then it just need to send commands to it, the syntax of the commands being that of the -c options. The commands that are to be sent through the socket must be of the following format: ([COMMAND][NUL])*[CRLF] That is, each COMMAND string must be followed by the terminal NUL byte. The list of commands are buffered by the server command until a [CRLF] ("\r\n" without the terminal \NUL) is sent or until the socket is closed. Then, the list of buffered commands are executed. I'll provide a simple library that could be used by an application to directly use the socket, but for the moment, the most easy and straighforward approach is to set the browser command line to "dillo -s SERVERNAME URL". On a PII266Mhz, starting a dillo client with a single open() command needs only ~0.04 seconds (if gtk_init() were executed before command line parsing and thus if each dillo client had to init the display, it would have needed more than 0.1 seconds). My next plans are to provide a simple library to connect (and eventually start) a server and to sent it commands. Then I will try to fix the "reload" bug when the reload time is too short. -- Melvin Hadasht --3f4f840b_5db70ae5_5d6 Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dillo-server-mode-CVS-2003-08-29.patch.gz" H4sICON2Tz8AA2RpbGxvLXNlcnZlci1tb2RlLUNWUy0yMDAzLTA4LTI5LnBhdGNoAMQ8a1MbubKf l1+h9akFP8bGPPIAQu5hwSTUEkhBOLt1k9TUMJbxFOMZ35kxj7Ph/vbbrZY00jyMQ8i5rlQYa6Tu VqvfknwUDfndNksTf/UyiW9TnvTGS7s//lk62z9noyDk22w1HY3jCV/1b9LVYRCGsfzfwuncLCU8 SwJ+E0RXLIE/aRBHbK238WppGIxGrDtl3RnrJtjCclK73a5N/C9rm+yDl7D1fn+DrW1tr21ub26x bh8+vwhonU6nMGJ9i+3NruSIF9B9e22NRiz985+su7a+4bxkHfyztsGgJc2SmZ8x93eC8GcQDePb JbbE4LPaZp/GnGXeFRvFCcvgORiGnI1mkZ/hjLKxl7GUZym7nGUZNKQ8SoMsuAmy+x5rrwooV7Mg ysQbF0e7AG5nqbPUqUaQBRMez7ICjoSHsTdM2cXZcSpaxHDWZpNZmrFLDh1GCU/HfMimPAniYeB7 YXiPJHQ0CQTElRgEHUy8VrQcjQQJt4IHLEgZn1zy4ZAPHRg7wS8JC2Cyfx0dsCBivpdCZ84iDmiz GPrMoCHILKwb6+wuGO4ssYcd5OrSUS6jQnJ6/n9QQiXGWvnc3CrKJ4ibIlNJp/z+y+tc0Nb72+uv t/ubWjQBkBJN1b1CMDcMwdwQcgn/vwapXGL/CCI/nA05e5Pep6u3XpD1xm/NZj+7n/JCWxjDqovG jj0+jf1rnlW8mEUChAU4jkbBlQ25QZMYNwSpL18iqS9fO2t91CAezSbsbyHqB0fHx6fu/vGR+35w /JHpzy5bY2/esA2n0Otfg7Pzo9MTu9dmsdfx6f7ecRHWC0fIWN7rbHB8undQ6PWy2Ot8cAZIC71e FXvtn374sHdyYPd6XeyFc1Rdz1WvrSL1g7Oz07Mi9RtrUiGQn6/E0r/acl5tFvh5CvTune2/d+Dp 8PTi5AAfTk4/6efTP/B/gQIfDk5PBhJwZ7X9K9uPJxMvArsx9RJvwjOepKjsbZa/GXs3XGj9KIYl vkWFSO+jzLvbpo4RjGt+Pv90dnTy7utn9nHvbO/D7r/2ji8GX3u9Xos6GeC9hIOtw4YMrMLlPfNY OvV83pOID4MELJaXXM0mHGxSkyC30Np47IpHYL38HB6NQRsZA42JiUgQ7gn6GMwEHm+8cAZ4oPd9 iQwCpGihbx9zYL4XKYCXcRxy+CqgseY9T79FcUuRv8cmQZoil+x+QD4YO55MwbAAQi9lMLCM53Yc +ON8SBRnGg5SDLqXBkOekD0lgiIB+ErxQk8ShhMc5QIANTiZTCAFA4z2YchHysH9TSbZH4M7bUMb TGEnV9DVdvsN2E+xNMDL0jpok66oHc3CkPzEjv0i4rdWu+F5DHyE0JtlcZfeEfdgQqyZcmDDMG2V cMLaTVJvxHdK3oUVIaNA/9UlZ87AWwE3hS9Dt4VgH5QCiLVJhT8GB3gYelewkENgYzC6x1X2WNeH ZRF9LXaAPEhFNYzChwNXKIhLUm1qfN+RpElgK2k9l4vQDi+Oj/88Ojk4/VNBW1PQ8nUwwDQlx1p1 AE8Gf0p4CuC6Agjrx0yA3kIADeOrbf13LXKJgR/3PpzvHQ5MtyABKjF4nCqMU4peQwIBqTEZJoWJ ID0ocTgXqjMDxRzy1E+CS5IIVH+IAvPh8ciWk1r1Q/3OlBKi5dohanJQwpwpwUfVEa/cUegJdaU1 hy+WkKK0l1UVRwepK5mkR9+OuTCl9iBtkpSyNSEeBQiatzcxcKwNliNO+I6hadNYLCpqmGd+ER1L CMq6dy6czSMcX4S3FldNW6BGWqydad6m7sRLr3dYYSXAHfk+n0onhsxScJqnZ9CIi5Da3Gm2VdDe alrmhbWBWm8WZi5hpECCPoWO/mQoO7V2lIabiQC/4/4s46lFkZoUcWDMw6nNAWxhGb8D455CKBgI n3gbZOMSFL02jyzIAcaD4GCTG1haii4XWxmzYeplY2rAxRgN6dmwqlqlKWpzP5weDBz7DURYg5NP VW/OP0FYtncMEZF4K14+sEk8RCIeaAbngnLCK0ImdsYnccbz8Gh4D2SDjb6cjUZSt+bNEZbP9Hsh jwQygro/Ibb+A0YHEWdngw+nnwbCXv1+ceieH/33gK311zehD6zbEqZ3h3Fy6yVDYL4fYiwDcpDi i1UROL5ec15BLvvihbMhc1no4WvPKKboXvHMjadZE2NR+CshzPvQVNoQo9046ksbhrrQ4pBdaQfD uxaEmRKjEH9CN4XIInNR4kyMrC0f5g0CWcI8rIkvoF93qTMPvCvlNlX9K3qrLq5Um+a78+MALHBb vXCYEpq5CmtA19FIAQN0TLnsrrQfwFCnCWTQuYQ4NThN3Z8zG+Apjx4xMHXTWhQFvwuyn4wij1x+ MiKKPX4yEhWU/GQ0ELY8CwaNA5WZUJAxd8mYu0EEAmDYSCXK9LqaSAlhlHDuheFCo3P0fhhAQAMw YJZas2tBaBUqKvRcylKY2Bh6hWBoFiKvoOwSDAUGrn/ZfHd0ug8AIx6ytmql7zmB0AUi3UC4cF89 gTlQsdLQy7xHUSbcGxYRSo49FaFyMcdYNBKNuWPZeuVsgWOBPy/7hmMxDfop/f38FUJrKlawBmPd kcO6XSMpEZ/zzEsyTL3whcou0BP3Gg9ULvm70Q0bDmt0u6KGBY/iA0lToQzk5KhCRCW6G77rII5W MlnLYGEQXaeyshqI4mkzbQmcHcKZEE6yEBLpmlMqKkneItIEkcps5nywf4qVH3Dv4jsGU1fBDY+o TMs9SPVlH0Qq66yANiW0tLZVaCneMdCmiFaGWyd7HwZiyO+QQ004M5thqqhBKqZLRTaP1HyJGhpa 9QdidpyAAc3klE8kS7hEs0WyrIMZNPtIswouvzQgzPmCyAfkinXYCe09EBHOWfc9jkDfroY9TrUq m3s3XhB6l6GGm5rUvyfqTdC4BpZ4WdU8YxololIUsyCdhh7lBSEaIEgBr6P4Nso5D/y85GyW8gVm IWJxm2GkZ1o/Ti6Ojx1G//fFP3x+UMU+paBysA47lH4KPigL0RABRKMYSReLF9/m1SG+GSlMfXWh DEIWCuYN16l/eTQk9DnVpZgo9300Q5D7z0aB5PMu1fK+fv2cV6nMRlLrXamy0KCcutkJPPAukPG1 RWuqZExjFpFTztt+Db3YzbEH1UE0AqXH1qwGWQ7BqYL6Wc6ujgAZQD0ROY12itAkl+twYqDzRIQw 1LHgwHLVodFh2+Mrpro65cFFBooSEtMe9oxDAh0JWzHx7oIJ5LeQ415S4Yj0XBfEU9qlfP3CefEK t4NeOlsitTODmQBSiXCoIpmm2F0MrgBka4mys4kXRKIZoPoqhcN07vNX6ELeWqYjwwA8WtufJYlL u0eQd6mpXyQhlorBd7uzJKQX1jYpa1/eUrNRjAV709/JNz6hUYYM7lWcGS9FeWp4V+iOnd1ReGV2 omeZiMo89AbGoQXENBEJgNQdojtGc8AwBhuNaUH3Kxcy9uFs2oSO1Ng83nf3lF1tteRUsmsRKMou shV3RyEkDrww+Ddn7y6OmCwIp/Dt0x9oO0RVBUhLFXqEJOLoZVoH/HOjsAyv3eTqkt63qGZQjGX1 FPGlHc7bQb828fAhF4H04uYCuh8MvAr9ZcEIPod7x+cDB7sf5kEbhmasOQxSdKii/iXHtypHnquC 7ELj+hTvwLh32XVXBuBSnv7qHh2wZhRH3GFBj/dYEsMkJFU14EjliElmTG+G9MggZrrQro5dCmUi Ulyi771QMB2ohFiz0fUM2tu/HQfQo9mUUgt47KKLjJIdqYlUUllWMgyPWEdptWD5umI2pqp8282V gd6mECdATKmw5cPETnxpW3VbvtWmzC6ztHby9wmZqL7RdAk5x/VONQKMlWqgi8rPqS72PBUD2GwD QTCiSQsb1v8K/9jbXbbSX2HLy6zw4g282FrJeUMfMkxgALI4NEEpgVjrm8Q+MB4COTaIK5phszFI kjjZpj0mkFe1/wY52yxCQ8xFvS6YQGICRhm3eOCpYcFSnwZt532JxBbnaASxOxZYqVh+66Xb7DcM 3R1zkiahOWO7ayb9izE5j+e2qzuIlGu7BphURuO1zSFxRKRCd2C2jQrJsCZgIXpQul6nHfJ1hXrk UWadiuQ9WK2aWH1yQbaaJcW1CEllarEV1OY5MAoVskY8TY0sEIgmd0/gUjH7cb0pxNvDpq6qlsbQ R3lgmvOoKaKz39JWQb6L89faWIT6oxpZTeUTdbIIzBBrezbft4qmjloDF1gGJgMeM9hvNUr8fYwE aQWejF3HyU/ATfni9yOvWtuS+MlU5HEJfIxKqtcUqLwSldCmGYf0cA+sCLzUwYxV58jYY0TJWsbT F+5HOGJVUx6xe3m996mWT7siqxuEcKD7uA09ixLuX8dXEQTveXGsZ4SRVYAfVDYn/mKlqRkA2yBk 22EBeyNiOnjqdAwr+d2iWRRKQPFW5EX/JasYv6V5taLVYNu6GbQJYP3yC0IRyxToZVI0o8Gvre4v W0Vvtrtb3lI1JiaO8WjWJDrSrazbW6AdzZR8eSs3DJaLVXjqK4ojSYuywAcIz2U+ds7Fqa8hZF73 sKqUr3VVIjbhaepd6Q3/Un6Ijd+dH4qd3VJ+SMsoXdE5zzJ0FxJsFoO36PV6wmEY+PQwYSMKLxTF 35VxKtqqMk7xrphx5kecg5SFeIg5G+M+A55koxOBmNtATjeDP8jrKfd8jq7kHg+RRMy7jBOggCry bZjqMN5mwWQacnG0z2M+bmTwBNYCNymCdAIKFAmwPb+lUij0z17YPD969/HoIySU8OAevTsBCrES sr65gXvcmxt95yXWQRaobxiz8rBskkL/a1ySf8eTy4CnRPxwGnSnSXwl8uERMCUd98ok7b8/PnCq 6y5ioboKnT8GA0NHNP53tScEGQU3zcCc+sDVTByMBn2E/4cxT3GXQmIbBqhNnvshSH2QIo7WwoXE PXHxHHOzQdAaUmKk1iE68d6F4eBjEsWvF1t4GKCzufnCWX+xOMc89+BWiwY17MfxNbArb1WK1x2x GPQ2CYbATEFc4quahwwxdZi+XBnKtFSkD9Mdpb08PHFFuQnY8ensYmDUdjz3xLuRlLCxl0J0B2s4 ATLEobKYNnjwzDu88T15Dh0PpstCPCEEh6BVyjgBg2fe5A0CVxYbUn3uRU7s8lYs0hFuoY1AD1x7 gAswmjSb22CYjR05tTEPrsZgAu/kkQZi7e/A2omXXFcwV1g1kh/Bi9mUpSBAPFKE6IKcoOciCQXq Bu5HpGPc5wC1nGXbtL2hslri33SWjpuXt04OQ79GOMIUma86rFAEzQ9S5MHCcumoBM3lEX/Z1T76 aAQLmeAhZIjXY8gTL86OVw+PjgcYk3E8/moeSpRckKImnWXLyIh/cKEExxQ4k9fECDAl3NXNTeV3 d0yi6uRfxNEmqcR2dCbiNFnOewd54B4e7707NxaEfRPNWG47h3BaLhBxMIoVgyBDEXzDWxuCfyjh co0YyYbBSxUlmAzD4pXNtKa9xj2UZgwYhF/MY4SK4rDp74v15I56+2NLVoimy5TmBYLvVR29TrXa Y61kSYFUxKK4bIX6olqqoy7jiFurMkqyDi+UQiXlh2irHZccYoQO8+99CneYjA6EI2ipmwfrW5t4 9WDz1bq4drKgrwAz2vxE9jbCNDvko0xtH5+eO3gXit3yFbDFwxjMsEOG1mM3Aagx9uNppgCJoGYU 3LF4hnECGIJ7ICCCyA1jCIVv9Vk4WBdn2u5O9cpfeOBty80HgV98gSzdXH/hbLLOyz786W8ahyce PSO34ME4vYGjIk46iylrErKuhSLxQEc4l/DawEfsuthude4Wqzakl+hywXcczFvqkH2QWzn4SPGo ol+ftRTRk5SpxynZ/hJRIVFD1B6nT/4mBS8fj5r5ZnhrtdQk8upCDqcpkzw1egdfezjFPM0yu3+J jjJxjwUPnxhXOGzvZs9CFkOtxVInJMzlUjyt5f+zHXVU66XGB2CUrWO7+oyrDSc/YCZ7GwturxAe QtrVMwLuY8PysvjbfYsnkWTbrmyK+F1m5tgTrOU3JTktc5zRJd8bK8zQcDxaYhYVFdZlayhcb0nI ul27QIoW6lcIHSN/Mm2KU5+27GB1R5RXQsjgy69oJ6hUsp130nTZguIwgXTZOOzXsuExViBJHS9v Fs8RLtsnBk0IWI6tL8bSiX7GC3sAumwKcB+tJukiqX6gaO8NuGWjm8Z5EVn2rIgr12xKt/XMenQT Kqcn71HQcarl0EujnPFgnKV8jqPBCxzfVApqKpi+1wXe32rh0dD6LmBQi3UZ5Z6jpjTwoEuj4jWE l+J1FDfKui8XnG6q0OVBZpw7YngEK0/xGs6cc0WOSPwcxpryvknLlMPu2xzMg5MD1/UxPJdWexoJ 3s0HrsGYsK2zgdWnmeid3A+vgU1gTMCqKi5A152BwnfziVZgTNAQ9KoTlJWXovS7+TQDmAdzd53l N8X3RbkDzacfxuI6JAyCgG3M00BXozCT3RXWuqNsHuqVsKE6oINOuN306y5baa1o3ZaFX0GfcVn+ YyzCmFheVRSy6Y0yeZsJs50aUlRZwSJGayAsfV6XN5KqmoNxADbFsmY2ltmVvmEk6g00h7Zw9tjs ZRjUlu5n4eSJLJg7sgo8oEGRcTcpTyILlBjeQnSnHW5/nBBgh60AU3dMCyq7yczNsKRqvLYXzHSi IGbCTqoqaSTKpISDRnaJxVXYaHolZJ3OjkhYroOpuqkbJ0ZFXi2ZYbEerAXC7bmEU3hkXWajS8gU X3mhyDCKN5LpBp+4DKxQyqMc5pL8ZP4W3KjiSl1wYtpXHZ6YjQsGKLVCZsGC0CC/egiyWfL3Os4x 5cAYbcU6VS8roh1ifmd37rBC7KDZbvTLrz1WbWCD7Ozpe465XopsAxydvgpp38aGpGQFvONKadOI mbq8KwWWffvGCgyCwZof8NwSFZR+OT6DT7s4IbpNuassdUvWR4tDxT45EWOhjmKNOYp/DLEyyRWY qwAWDLn5qnZbn4xvvjB44a5wW14aXyypp2W0bWvnX9xXm7Nmyv3srlSyZM4MmJRYQ2nL4LVIPJHh xc1Pxur4thA4cQRqFirJkCfKK84vFM4pPHZsYV7EbtFaitnzhV4gWahcDY2y1mfIYVJrzKD9p92v U2F6demTVVdLdWRQ5XsLXoXmpAbV7qRUh89qWKn0WlH8LcSErTx4w9FEFdq7ylhak/ucRd4KivIw b169vsxWYzZVYbUm/1lq9UUslBVU4JAnUwwk5WFg5tb6/b6e/JwqdYfV7/E8ogzPcxNUFwGBAaoM 7Yb8hofNljH9XDj+ZxZkriyrilzC8C+CpP4CtD/nFVNzBvXKKd2+LP8UOjmsgel1wf3apJg6qrdB FQOUa68FD+n590A3rKjJX22hjyKIhYJh/ms9GJIaEArGul5HlaqxR5fs+e7R/scWTP8eyU9YLgP2 kxZLj/8JS/Vc96ofWShIiw1qyx3sU6zV7+Vh1jouS3u6q4OjqtXSkRL7zjWQ0H/CCjzLbfD/f/Yb Z/Ofm/cI+kcZ/8Qr8oqv8mdCsNUbDhN3Fok7ti5+sUqz4siP/JEUu84W4I+NYCUpFDUl3PWUCY2J sfuW9kOrL7aYwaU9io6cVgaXFfAN4j4l94yO/+U0aRwFJCOxxOJL8+OhvMvNzk/3/8Ba1mDvAy6v MIbdNbPsInYRmg0a2chTgXn0sfwApOapqFxhbKtbVGRhg8DfpDHOAuqjwqvZZEo/5dj9LYV/kJpo SI6pIWXeqvN3FHvpUTpum/AJhHzNptrOWtbiIc4hyEKPblTnEHVDL51F7sibBOE9UL4nmbujhC/y p/dNuzNO0qmYeBmZ7m4cADaXP4uxShJxXx8AMH4MSBkV6lASCEc4R1M3CrMv1IZKfCDXmQvLHGUw zrRKASkk0aIUnSRRjKWAwckp9LbTViWJcjYNKyudRfhTA80yR/NeOkfFgjkvMcPcpcL6VGpp1sgL QjzPkxHL8WqDuqifVzaeT+vmKd5DHtpcQhT4o6tau7B1BCHSanJwg05X9U2CXswFSMPKICtrFlW/ e0UAxKFfL9OFi3myMF9WjXMsBelRVm2e8asJGRb+bRa9u1i+vVBlzmqnWfYzIIxvzVi3XhGqve9z /ULM4gccEDdICV1R7khRdTMwebMos1roh77wu2yISudSqk49/PA5B8DLdq3NtQ7LLxxFOeUIDqm2 WuSWh5gitIsATnR6IwDD14iWzFIGhHqbADEVqkb7awKII2B06Ysl+ygakS0LJoWdXcU9+lRVO/+v vWNbauOGPsNXqJlpYhM7eI2NuTSZySSUMqVJhpDmoWV2fFmCG+P1rO0QOqXfXp2LpCOt1kA65al+ AHtX16Nzk3QuhnhxHD4vhhq4Zr7nVfl88r5X/ST3Nivn/uj3Aim/bQtXY7gjYj3WW6n2jnGLLGJX RiWyR0XeU9R3xrn5qTXU8Vc8jqsYORbWnDq96i+GF7Ug8JE6TI/epkdv1F/07d3Jkfn604d3kv3H gyqxt8Vq24r/LhKTNFfjhs4FO2AmZB6Foo5fO90e3mg60BwBnlk2UR3Hid7bgIFqo8CvqWVKUq/i yTy24PWs2MSSEib6gJFGL97qF9l5ZdHy+fuNj1OocpTRCVTv81G8WVRcLGDhlBhL1WyLYIzkAAtu LQTLFRsGqlveMLgTGidMDXxx4ID3FvoNlVhqNaWaL6ioC80g3xFDbjkOINe2ktDs5OMUFkT6+kYK 4xhiDTFey6mq70ceKB6ZVTtQ2A2W579FomOerSAOkJTiRV05OUmBRQbXi2yOA3cy8P+gGrcF1XDo aJAWIFjCSL1gdvOov9c1jTp4WyzDTYNbhheeZlGmsE9QTCPdsBa8C/YQIf09VX7fVEpvs2EnHHbz NKzOk4k1UerouSjmcxXiaVEO/ZcMflUL29RqUTs4dAtB81tYp6naZ8AJn/xePAlMNW6vmnDV6RNp j8Fq7NjTF0P9WN0Ss0ZZFRPugcOu9STD0Y3PgqANiAflJXNmxQBqYTBSUoGVCk7hjZ4WGsbexS/a eohCN5GtPWuUwXjj+BMKkQh6SdB/gxtWiI731xd8Kl+pL1QXDUByF1XCk0b6qcgZMzY3hA+aN0b0 Wpk7ptcNc8f0ukoO1+SPEc9W5pDRDZocMrLKLXlk2rtdcOmBf7syJrQR4/4Va02Li4/jkdbO1g2p DK6aL7xkRXXj5ITexfAQVvNLFim5L3yd4G0545ClOmjMPBftRWrss3dT6N4xXV6mgyty3jBDxI49 uwLNU4C/Da7qJkwpfiKFwmfNJvVwRo49210E7HZ3p9Eu+fU4qILWBlekKXltpoPlOrqAKXbuEMHg yIjVqAeg6QFKQfg6uprElCdX4znnK6m9yadNk5GJq9k0KH9mRQ5VKSOLFuSBdcn601uMPEQEN6uM VfjzhZ48ZaDbVV65Zj6LLq0IXww95yFJZs0MolQlUGeZuxrfGjAMe0W+2H3p82uWAAxFueZ48QyL 14x7sMuJhRZVqP8F3aN3HAfQ3TY5knqNBP3WbzF8QVt+sHtBFI3AHUWUUY23O2cySsA5JOECk1eb 5cRl8WpYU2m4SDK5H6D8BJSWa8QfAi5azQX45Vyw5nCJgrbjeuaUxgZDfvwBsXaKrEku18+4qc0K xAChj86jTuz4bkL3QBjGjjje3B1hWO4oAuZHdD2jfWCrVgeQImlh8EZyT2RvSrRn4nLegtGmEYr0 02PUI0ajAAwNnpf5n172v7L/4HYPXTJ7rS65ZN4LcTalg7ua9r+A6ZNedz6mKOGsecFTEl72ml8K FPsocoY4SqCbCIsxuvX+lNI0+f7FwNfpjpcywfH6fYfLZBmyLoRWQdY6BSSEmOnh6c8pOXKkp2/f HR/8enDMYMbrYMyHsN0G2O1o2de7N+xwANl0mc7y2XL2LMfj8ry4slpapBBZmvmvPYnodLi4cOPo l7byq2Uxz4tTMHilA0wVV34eMq2j6LVS+WnvhMpPe0fJ4ZaVn4u1RP2YDViRae9tdfe6Pav86AbL yk80u6Ov/JDuQ6SDklniACTI0goyRP3I5vN00C/mQLrr5ZJaly2u0RAUzQatlqQ2rvB/o8yjARlL 7UB/Q1zTWqlCQx2OPosFd1+hqX8jv/fL4v/OtHDBGT5MPAS/XVUxR0p/CXcz8/JEdT2BxJorPaju jv3dL+MjDdGgLP5aa3ddJtJWgqr6VizdI5e+Jdkj8in9t4fJHlcmevH0TODPbHcVA7M9tIMVdGUt xxkOavbYre+hLBQe9qdDvaHLvs7guj6K4Bw3IOn2MIuq1oWTrVAXhqYs5ZTw0Pddl2X31Idi8vzF 9/Mf8BoFzWdPT9Ia2KlKYfR+kc+MURVMzPOoqthDRJy74bAQscFkXP1+hP1W70K+YePiZFsV7w/0 j8OM3PRBsrBfEwSHyjBb1ScbygGmyquGEj6dLQqQ2WC90EyUFav5ZGTjXfw0BtX1mqxg9NK8efkr SFKoZoIHtRAv20nr3stKH4wihAGyhkU+mWQjw2KAR2jsutB8UGzCQKS//pi+f3Xy9vj44DWLdwTn KB/qqnU2rj55efgL2G9YXFDusIA0YF0MVBIIqgPJubQWKfLOoQ0ZR2HKp1lzfpEvCHWeqSNge5OJ UYEH5FPWLzC01oKSODCy8XqgJgz9bWyKDZAemV1kk+ZOoF0lCkh0AkUx1k5w3hklbEBce+hjd5zI bHZw49pptSIb11UMxYQvuaF0orgJPRUpiiHc0gDUSw2xGfhKQfoFZ/GIBhFTL/+fhtq6F8Dgroyq ckcKx/7BwzrUENvTzYpRY8bREB1OQEVYcFI9gxSRhQOcUZ+zbCYhWFfnRX7pajGDGS/4GBTdlej6 QKjGqzgD3axFuLNdbNG9fWamfbKEkBOTa/3H+TmKmIo3NkT9kY3aBhjOSRo4p7WJEKA3FYtr3hbr bRJsHCGKGSUzG8HkrjXz2q9LYa+x+UGFPfZXnX68U0o/3lE0RCPs8dda0lUvZy7teLuz12m5tOMd K+ypdETYd6Sw3yVpv0vi3joEbbBLBh4oo7O9cxXKizHxcGQH/clCBR8ZIrQYYxHmi1hjPL/sz4BT p3CQzDWwoPdG1CCOrQGmtzZzOibmGuU3GnXWYnxKdBO8MXscRj70gdJ8BQPmdFBp73Q1e2oJtd24 wuiZ1Rxglg0bmEAIEj5ltqYySwkQmCHBUADNvb7xg6+8z8Q6MNsyKdU1/jP7CsbIBOgN0yjOVhgg D1tDWYGCYW1tWYbgc+VApkugD52VJvBkLXREWkoHpKVxPDpoH1BWojq2gzY0d6r+WP1dri8kSkDc D7kRxf4qiTspafLJrqIhSuLW286eep0NgVzbKtna08r8VtcSd7LrEXd0xymJO0kS1ISThIibD1RS iwp06OwF09C452UsJmb9SD9+RFk6aygiBtdqfAk6nybYuQ2XyWldJRGHLX3g2sZMcTzKREteQxHa Fg1pCZZhnhLLErQKBAAH5Uj37uKOMq6HVC/aOrEagNSpHOJzQmAc3Y3YabTxOCxp85EOjppwGC/0 PL65oV4a9rAeshHCdp9CoS3K47pfKg/mA0FxzpjC6dPuyqbMkgMhfQvbKHelVyMyEf00UpYwZZjn xSisxJe58Aq4IlQ2o8XqFLbmIvuKBuAlEbXUFf4Bi0UbmHGEAAA= --3f4f840b_5db70ae5_5d6-- From nigel@waspz.plus.com Fri Aug 29 21:46:50 2003 From: nigel@waspz.plus.com (Nigel Wilkinson) Date: Fri, 29 Aug 2003 21:46:50 +0100 Subject: [Dillo-dev] Problems with tab patch In-Reply-To: <20030829080757.5a6de2f0.frank@unternet.org> References: <20030828203527.314a103f.nigel@waspz.plus.com> <20030828221929.59c0b641.frank@unternet.org> <20030828220026.71aa1f26.nigel@waspz.plus.com> <20030829080757.5a6de2f0.frank@unternet.org> Message-ID: <20030829214650.3c901a06.nigel@waspz.plus.com> Thanks Frank Nigel From ralph@genesys.ro Sat Aug 30 12:47:13 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Sat, 30 Aug 2003 13:47:13 +0200 Subject: [Dillo-dev] Rendering problem In-Reply-To: References: Message-ID: <20030830134713.1b227c51.ralph@genesys.ro> --=.G?lTQ(SIbmvv,, Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid wrote: > Try with "force_my_colors=YES". Yes, this works, althought the rendering is totally shit ;-) ... definitly not a dillo problem in this case. The problem with Slashdot is that there are just so many tables / blocks that it makes it almost impossible to locate the precise bug (although if I am correct the page is filled with bugs). > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. Yes, Dillo's policy is good... if the html is wrong then that's too bad. BUT... but but but, instead of manually running through all the code, I tried it with "tidy", which found a grand total of 254 warnings and 0 errors... Well, as for 0 errors, I would say 254 warnings should be more than enough to validate one big error ;-) After running the saved page through tidy, it actualy renders, and renders well! > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... > > Please investigate those and report to them. Yes, I have reported a bug about bad HTML on the sourceforge site. It's not really a matter of bad HTML, as the HTML seems resonable, but they are using terms and codes which are definitely not HTML compliant I would say. If you are interested in the output I have put up the origional page with the "fixed" version, and output of warnings / errors here: http://members.rott.chello.nl/r.slooten2/dillo/ You will see here that it appears as if I'm still logged in.. for some reason I cannot log out, LOL .. but that's not the issue.. you can just see how many invalid html commands they seem to be using, and that after the removal of this, and the insertion of several and attributes fixes the whole page which then renders perfectly in Dillo. Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --=.G?lTQ(SIbmvv,, Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UI7EAWKxH5yWMT8RAq/rAKDUhBviYeK+NbbRynuDWHMVc3tOjwCg6euv SrrO4tBCcOzulp5UQVbXIOE= =oq/5 -----END PGP SIGNATURE----- --=.G?lTQ(SIbmvv,,-- From ralph@genesys.ro Sat Aug 30 19:12:14 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Sat, 30 Aug 2003 20:12:14 +0200 Subject: [Dillo-dev] Rendering problem In-Reply-To: <20030830134713.1b227c51.ralph@genesys.ro> References: <20030830134713.1b227c51.ralph@genesys.ro> Message-ID: <20030830201214.635e43ab.ralph@genesys.ro> --=.o8hfBvvfkgdurP Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Sat, 30 Aug 2003 13:47:13 +0200 Ralph Slooten wrote: > After running the saved page through tidy, it actualy renders, and renders > well! Umm, just discovered that this only works for me when logged in. If I move my cookies somewhere else, re-open slashdot with dillo, save that page and try with tidy, it fails... Just thought I would let you all know before you go blue in the face trying ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --=.o8hfBvvfkgdurP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UOkAAWKxH5yWMT8RAuaXAJ0Sw/k7c+wLtWmTT9eV6m9EoZu7iACeOGgN /bOHGqvcZxah2Hgll5tG/6c= =z3Qt -----END PGP SIGNATURE----- --=.o8hfBvvfkgdurP-- From madis@ats.cyber.ee Sun Aug 31 09:56:16 2003 From: madis@ats.cyber.ee (Madis Janson) Date: Sun, 31 Aug 2003 11:56:16 +0300 (EEST) Subject: [Dillo-dev] Rendering problem In-Reply-To: References: Message-ID: On Fri, 29 Aug 2003, Jorge Arellano Cid wrote: > On Thu, 28 Aug 2003, Ralph Slooten wrote: > > > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > > "Andrew A. Gill" wrote: > > > > > Normally, this isn't something that I really care about, but now it's > > > causing slashdot to be rendered as black-on-black text, thus depriving me > > > of my ability to read about the new MD5 sums that the RIAA is using. > > > > Yes, I'm getting this too since today. It's probably a small html error > > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. > > Unfortunately slashdot is sending awful HTML-like content. > > The black text can be explained because they explicitly set the > background, textcolor and visited links to black! (). > > Probably it changes with CSS. > No, slashdot does not use CSS. The white background is created by tables and is still visible, but articles now seem to be on the side of it, not on it (talking about main page). Probably some table/tr tags are in wrong order and screw up the push/pop parsing. Reason why i think so is that the slashdot page can be seen quite ok in dillo with this patch: @@ -1139,6 +1146,8 @@ static void Html_pop_tag(DilloHtml *html Html_eventually_pop_dw(html); return; } + if (Html_match_tag(html->stack[tag_index].tag, "table>", 6)) + break; } /* Not found, just ignore. */ } But yes, its a workaround for buggy html (not invented for slashdot) and a fact that it helps just quite proves that the slashdot page has problems with tables (along other bad html). I tried to find the problem from slashdot index page, but it was such a bloody mess that my sleepy brain could not parse it at all... From ralph@genesys.ro Sun Aug 31 13:40:16 2003 From: ralph@genesys.ro (Ralph Slooten) Date: Sun, 31 Aug 2003 14:40:16 +0200 Subject: [Dillo-dev] Rendering problem (temp-solution.. no patch) In-Reply-To: <20030830201214.635e43ab.ralph@genesys.ro> References: <20030830134713.1b227c51.ralph@genesys.ro> <20030830201214.635e43ab.ralph@genesys.ro> Message-ID: <20030831144016.61c229e5.ralph@genesys.ro> --6hCQLCRs10Hv=.w6 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit It seems slashdot.org has serious issues with it's code, so bad that it makes it impossible, hard, or just a PITA to view with Dillo. Instead of patching dillo to render these pages despite obvious errors, I did a bit of simple PHP coding to do the following: I wrote a small php script to download a current working version of slashdot using a Mozilla cookie, wget, tidy and sed. It seems to work fine now with dillo, but probably will skrew up from time to time if 2 users at exactly the same time try refresh the page (I can't be bothered to make this into a full-blown project). It's only ment as a temp solution, and also _only_ supports the main page, linking goes directly to /.'s site, where the rendering is messed up again. http://axljab.homelinux.org:8080/slashdot/ Yeah, this is only for you /. junkies that love using Dillo, and although my internet connection may not be the best in the world, who knows, it may even work for you ;-) Also the page I created will not parse the page like in your own cookies, but is simply the default page using a cokkie of my own, but heck, it's the main page that's most interesting isn't it. Another note, each time the page is refreshed, the php downloads a new copy of/. .... so please don't abuse by continuously refreshing as it will kill my bandwidth, and possibly get me banned from slashdot altogether. Enjoy, and let me know if it works for you ... I love success stories ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux" --6hCQLCRs10Hv=.w6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UeyyAWKxH5yWMT8RAp+2AKCoKjn58wrg1mJWvJdopj+NGwZmDwCg8FpS NYu7V8LQMo+aon25E4gwxKk= =bPBF -----END PGP SIGNATURE----- --6hCQLCRs10Hv=.w6--