- Dillo-dev - lists.mailman3.com

[PATCH] version 9 of tab+frame patch, frame support 'complete' (?)

by Frank de Lange

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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 21, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Joerg Sonnenberger

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(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 21, 2003

Re: [Dillo-dev] Some points about the dpi's

by Jorge Arellano Cid

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ón 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. > > (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.-

Aug. 20, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Jorge Arellano Cid

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.-

Aug. 20, 2003

Re: [Dillo-dev] [PATCH] Tentative solution of #448, #449

by Jorge Arellano Cid

Thomas, On Fri, 8 Aug 2003 tomas(a)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;

Aug. 20, 2003

Re: [Dillo-dev] Some points about the dpi's

by Ferdi Franceschini

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

Aug. 20, 2003

Some points about the dpi's

by Andreas Schweitzer

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

Aug. 19, 2003

Re: Another review of Dillo 0.7.2

by Jorge Arellano Cid

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.-

Aug. 18, 2003

dillo - my favorite browser (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Thu, 14 Aug 2003 20:57:41 +0200 From: Mario Moder <clay-man(a)freenet.de> To: jcid(a)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

Aug. 18, 2003

Re: [Dillo-dev] Dillo hang as use chinese font

by Jorge Arellano Cid

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.-

Aug. 18, 2003