- Dillo-dev - lists.mailman3.com

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

Dillo configure cannot find zlib, jpeglib not libpng

by Scorpio Rising

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

Aug. 15, 2003

Dillo hang as use chinese font

by Siu Kam Ming

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

Aug. 14, 2003

Version 8 of tab+frame patch: smallproblemwithwhitespaceinmultilength

by Frank de Lange

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

Aug. 13, 2003

RPM now available for SuSE 8.1!

by Kelson Vibber

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

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [08-13-03 11:57]: > On Wed, Aug 13, 2003 at 11:40:02AM -0500, Patrick Shanahan wrote: > > * Frank de Lange <frank(a)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

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Christoph Bauer

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]

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Patrick Shanahan

* Frank de Lange <frank(a)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

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Frank de Lange

On Wed, Aug 13, 2003 at 11:40:02AM -0500, Patrick Shanahan wrote: > * Frank de Lange <frank(a)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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Victor Sahlstedt

On Wed, 13 Aug 2003 16:39:57 +0200 Frank de Lange <frank(a)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

Aug. 13, 2003

Re: [Dillo-dev] [PATCH] Version 8 of tab+frame patch is out

by Andreas Schweitzer

> 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

Aug. 13, 2003

[PATCH] Version 8 of tab+frame patch is out

by Frank de Lange

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

Aug. 13, 2003

Re: Re: [Dillo-dev] [patch] Remote Control

by Melvin Hadasht

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

Aug. 13, 2003

Re: [Dillo-dev] [patch] Remote Control

by Jorge Arellano Cid

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

Aug. 12, 2003

libc dependency in 0.8.0pre (bug 487)

by David McKee

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(a)jlab.org -- (757) 269-7492 (Office)

Aug. 12, 2003

Re: [Dillo-dev] Recovering health.

by Andreas Kemnade

On Thu, 31 Jul 2003 13:21:46 -0400 (CLT) Jorge Arellano Cid <jcid(a)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(a)auriga.wearlab.de)

Aug. 12, 2003

Re: [Dillo-dev] Installation Problem (RPM)

by Patrick Shanahan

* Kelson Vibber <kelson(a)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

Aug. 12, 2003

Re: [Dillo-dev] Installation Problem (RPM)

by Kelson Vibber

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

Aug. 12, 2003

Installation Problem

by William Trenker

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/

Aug. 12, 2003

Re: [Dillo-dev] silent dillo? revised

by Andreas Schweitzer

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

Aug. 12, 2003

Re: [Dillo-dev] silent dillo? revised

by Ivo

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

Aug. 12, 2003

Re: [Dillo-dev] silent dillo? revised

by Andreas Schweitzer

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

Aug. 11, 2003

silent dillo? revised

by Jorge A Ahumada

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

Aug. 11, 2003

can dillo be silent?

by Jorge A Ahumada

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

Aug. 11, 2003

Re: [Dillo-dev] focus on start

by mattias/spikboll

On Sun, 10 Aug 2003 10:21:30 -0400 Todd Slater <dontodd(a)columbus.rr.com> wrote: > 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? No need to click. Just press Tab, and you're set to go. /Mattias -- mattias östergren | /"\ compsci student | \ / ASCII Ribbon Campaign gävle, sweden | X No HTML in e-mail http://spikboll.net | / \

Aug. 10, 2003

focus on start

by Todd Slater

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

Aug. 10, 2003

Re: Re: [Dillo-dev] [patch] Remote Control

by Melvin Hadasht

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

Aug. 10, 2003

Re: [Dillo-dev] [patch] Remote Control

by tomas＠fabula.de

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

Aug. 10, 2003

[patch] Remote Control

by Melvin Hadasht

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

Aug. 9, 2003

Re: [Dillo-dev] Question about frames (have them working, but...)

by Sebastian Geerken

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

Aug. 9, 2003

Re: [Dillo-dev] Refresh tag patch...

by Tom Lisjac

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

Aug. 9, 2003

0.7.3 not rendering "trade" and other small annoyances

by Reid Fleming

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.

Aug. 8, 2003

dillo-0.8.0-pre

by Jorge Arellano Cid

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

Aug. 8, 2003

Re: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available

by Nicola Girardi

> 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 :-)

Aug. 8, 2003

[PATCH] Tentative solution of #448, #449

by tomas＠fabula.de

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;

Aug. 8, 2003

Re: [Dillo-dev] re: Anti-aliasing patch for dillo-0.7.3 available

by Jorge Arellano Cid

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

Aug. 8, 2003

Thanks for dillo! (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Thu, 7 Aug 2003 23:05:56 PDT From: Dmnz <dmnz(a)x-bit.org> To: jcid <jcid(a)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(a)x-bit.org ... Dammit Jim, I'm a doctor, not a tagline writer.

Aug. 8, 2003

About Dillo (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Fri, 8 Aug 2003 08:19:24 +0200 From: Mathieu <mat.hieu(a)netcourrier.com> To: jcid(a)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

Aug. 8, 2003

Re: [Dillo-dev] Refresh tag patch...

by Jorge Arellano Cid

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

Aug. 8, 2003

Re: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1

by Patrick Shanahan

* Kelson Vibber <kelson(a)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

Aug. 8, 2003

Re: [Dillo-dev] Refresh shortcut?

by Ralph Slooten

On Thu, 7 Aug 2003 23:37:04 +0200 Frank de Lange <frank(a)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"

Aug. 8, 2003

Re: [Dillo-dev] Re: Dillo RPM/build on SuSE 8.1

by Kelson Vibber

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

Aug. 8, 2003