- Dillo-dev - lists.mailman3.com

[Dillo-dev]compile problems on AIX + gcc

by Riccardo Mottola

Hello, I'm trying to compile 0.8.1-pre1 on AIX 4.1 : One never knows, maybe som4e progress was made :) I had still to use CFLAGS="-lpthreads" to have configure pthread working at configure. I notice the following warnings gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/u sr/local/include -I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2 -I/u sr/local/lib/glib/include -lpthreads -D_REENTRANT -D_THREAD_SAFE -Wall -Waggreg ate-return -c `test -f 'dw_bullet.c' || echo './'`dw_bullet.c gcc: -lpthreads: linker input file unused since linking not done should I have used LDFLAGS or something else? isn't there a more elegant solution to work around this pthread regnition problem? like a configure option? Cheers, Riccardo

May 7, 2004

[Dillo-dev]Re: about gtk on solaris 2.6

by Jorge Arellano Cid

Riccardo, On Thu, 6 May 2004, Riccardo Mottola wrote: > > Hey Jorge, > > just a quick precisation. On the box where i have the old 0.7.3 dillo > which gives GTK errors, I have GIMP installed and that one works fine, I > have edited quite some images. > > SO I suspect it is something in the way dillo calls GTK that could > trigger the error, before saying GTK is bugged on that platform totally. There may be some good news for you: Try this patch: diff -pru dillo/src/dillo.c dillo-0.8.0/src/dillo.c --- dillo/src/dillo.c 2004-04-21 16:47:34.000000000 -0400 +++ dillo-0.8.0/src/dillo.c 2004-05-06 11:11:31.000000000 -0400 @@ -216,6 +216,8 @@ gint main(int argc, char *argv[]) /* Initialize GUI and parse GTK related args */ gtk_init(&argc, &argv); gdk_rgb_init(); + gtk_widget_set_default_colormap (gdk_rgb_get_cmap()); + gtk_widget_set_default_visual (gdk_rgb_get_visual()); /* Handle command line options */ while ((opt_flg = Dillo_get_opt(Options, argc, argv, &opt_argv, &idx))) { It fixes the colormap and visual detection/settings on some systems. The documentation is a bit vague about this calls, they are deprecated now, formerly suggested as initialization for most cases and removed from theGTK+2.0 API (with compatibility defines). If you're lucky, it may help with AIX too. Please test it and report. Note: The patch is in CVS now, but use a "pre1" patched tarball for the test. That asserts the use of the same configure script. Cheers Jorge.-

May 6, 2004

[Dillo-dev]downloads and pre2

by Jorge Arellano Cid

On Tue, 4 May 2004, Yves de Champlain wrote: > Hi > [...] > Everything works fine except for this : > > av_open_url: Url=>http://ftp.gnu.org/gnu/ddd/ddd-3.2.1.tar.gz< > Connecting to 199.232.41.7 > warning: Unhandled MIME type: <application/x-tar> > > ** CRITICAL **: file web.c: line 57 (a_Web_dispatch_by_type): assertion > `dw != NULL' failed. > > Of course, this does not start any download but after this, > I still get messages in the shell but I will > not have those from wget once I do "save link as" > like I have if I do "save link as" before. Effectively, a left click on a non-dillo-viewable MIME type URL triggers this error message. The code inside dillo assigns it to a "null-client" which means it continues to download but it's "ignored". This has some side effects, one of them is the transfer not being aborted (so it continues wasting bandwidth and memory). It also keeps a cache entry, so when a dpi download is requested it hits and gets fed from the cache! (not from a dpi). That's clearly a bug. This days I've been reviewing the code with a view to patch it, but it seems that a full patch (aborting the transfer, cleaning the cache entry, stopping the clients and offering a download dialog) may be too complex to debug in this pre-release testing stage. Aborting the download (which would allow for the later dpi download) looks simpler. I'm currently working on this. That, plus the two patches in CVS seem to round "pre2" and most probably become 0.8.1. Cheers Jorge.-

May 6, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by Riccardo Mottola

Hello, > > Using > > pre 0.8.1 I saw the first two text boxes render and then all stopped. > > The console said: > > Dns_server [1]: www.newmobilecomputing.com is 112488 > > Gdk-ERROR **: BadMatch (invalid parameter attributes) > > serial 8039 error_code 8 request_code 72 minor_code 0 > > > > visiting my own website at http://carduus.chanet.de yields the same > > problem, the first text lines appear and then: > > Dns_server [0]: carduus.chanet.de is 112598 > > Connecting to 217.110.112.61 > > Gdk-ERROR **: BadMatch (invalid parameter attributes) > > serial 4012 error_code 8 request_code 72 minor_code 0 > > > > Unfortunatly, I installed the new dillo over the old one so I cannot > > test the old anzmroe, but I bet it wasn't so bad. Now I can't visit any > > site at all basically. > > Definitely those sites work with 081. It looks like a > machine-specific problem. Unfortunately I don't have a Solaris > 2.6 at hand to test. BTW, I know dillo works on Solaris 8, > and frankly Solaris version numbers are confusing to me. Which > SunOS number is given for 2.6? The bad news have yet to come. On another solaris box I have, I discovered today to have a 0.7.3 version of dillo compiled but not installed. accessing www.osnews.com I get with that Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 4992 error_code 8 request_code 72 minor_code 0 Interstingly enough, here too the built-in start page of dillo displays correctly Both boxes run solaris 2.6 which reports itself as SunOS 5.6 I wonder how can I know the version of gtk I installed? I have on this box (the one with 0.7.3 dillo) /usr/local/lib/libgtk-1.2.so.0.9.1 grr, how much do I hate GTK :) An multiple back-end that includes openmotif and others would be extremely nice! Cheers, Riccardo PS: any new hopes for AIX 4.2?

May 6, 2004

Re: [Dillo-dev]CVS renamed ?

by Thorben Thuermer

On Wed, May 05, 2004 at 09:20:11AM +0200, Jens Arm wrote: > Hi > > If I try to do a CVS checkout I get: > > [tux@tux dillo]$ cvs -z9 update -dP > /sfhome/cvs/dillo: no such repository > > What happend ? apt-get upgrade overwrote the modified cvs binary that is normally used which broke the path mapping. - this is permanently fixed now. > Jens Greetings, Thorben

May 5, 2004

[Dillo-dev]CVS renamed ?

by Jens Arm

Hi If I try to do a CVS checkout I get: [tux@tux dillo]$ cvs -z9 update -dP /sfhome/cvs/dillo: no such repository What happend ? Jens

May 5, 2004

Re: [Dillo-dev]libpng-1.2.4 detection

by Jim Nutt

On Tue, 4 May 2004 09:19:49 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Is anyone here using libpng-1.2.4? > > Rubén sent me a bug report and effectively we were not detecting > libpng-1.2.4 right (this only happens with 1.2.4). If it's any help, you seem to be detecting 1.2.5 ok... -- jim nutt home: jim(a)nuttz.org jabber: jimnutt(a)jabber.com work: jimnutt(a)vestek.com ms msg: jim(a)nuttz.org pgp id: 1ECBCC78

May 4, 2004

[Dillo-dev]libpng-1.2.4 detection

by Jorge Arellano Cid

Hi, Is anyone here using libpng-1.2.4? Rubén sent me a bug report and effectively we were not detecting libpng-1.2.4 right (this only happens with 1.2.4). A patch for this is in CVS, and it will appear in "pre2". I'll keep expecting more feedback from "pre1" because the png lib detection is the only change so far (it's minor and doesn't affect the work of the browser, just compilation). If anyone is using libpng-1.2.4, please let me know. Cheers Jorge.-

May 4, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by Jorge Arellano Cid

On Mon, 3 May 2004, robert w hall wrote: > FWIW - an apparent blemish > www.samknows.com has lists of UK exchanges in various stages of getting > broadband (see RH margin eg ' 'triggered waiting for RFS or similar) > Both Netscape 4.7 and Dillo show page 1/first 50 of these exchange > lists, but when you try to access page 2, throw you back to the main > screen. Dillo and Netscape are right! > Firefox however, renders the table pages correctly. Ok, here's the explanation: From RFC2396, [C., C.1]: <q> C. Examples of Resolving Relative URI References Within an object with a well-defined base URI of http://a/b/c/d;p?q the relative URI would be resolved as follows: C.1. Normal Examples [...] ?y = http://a/b/c/?y [...] </q> That is, instead of making an href with "?blah" it MUST be "league.php?blah". Feel free to tell Sam and Firefox fellows ;) Cheers Jorge.-

May 4, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by robert w hall

In article <Pine.LNX.4.58.0405031538190.32191(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >On Mon, 3 May 2004, robert w hall wrote: > BTW, mime.c:161 reads: > > /* Type not handled (todo: offer download) */ > > :) > > Jorge.- > Jorge Thanks FWIW - an apparent blemish www.samknows.com has lists of UK exchanges in various stages of getting broadband (see RH margin eg ' 'triggered waiting for RFS or similar) Both Netscape 4.7 and Dillo show page 1/first 50 of these exchange lists, but when you try to access page 2, throw you back to the main screen. Firefox however, renders the table pages correctly. Bob (also copied to Sam Crawford) -- robert w hall

May 3, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by Jorge Arellano Cid

On Mon, 3 May 2004, robert w hall wrote: > In article <Pine.LNX.4.58.0405030916110.32191(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)dillo.org> writes > > > > > >> (- still can't get the default installation to do downloads properly > >> (dpid starts, but I get messages about 'unhandled MIME types on bz2 > >> files...) - but this may well be finger trouble on my part.) > > > > When you left-click a link, the remote resource is requested for > >viewing; that's why dillo complains about an unhandled MIME type > >(it can't display it). > > > > If you choose "Save Link As..." from the link menu, the URL will > >be passed to the downloads dpi and retrieved and saves as a local > >file. > > > > > My bad - too much using Firebird with brain out of gear! Works fine. BTW, mime.c:161 reads: /* Type not handled (todo: offer download) */ :) Jorge.-

May 3, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by robert w hall

In article <Pine.LNX.4.58.0405030916110.32191(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >> (- still can't get the default installation to do downloads properly >> (dpid starts, but I get messages about 'unhandled MIME types on bz2 >> files...) - but this may well be finger trouble on my part.) > > When you left-click a link, the remote resource is requested for >viewing; that's why dillo complains about an unhandled MIME type >(it can't display it). > > If you choose "Save Link As..." from the link menu, the URL will >be passed to the downloads dpi and retrieved and saves as a local >file. > > My bad - too much using Firebird with brain out of gear! Works fine. -- robert w hall

May 3, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by Jorge Arellano Cid

On Mon, 3 May 2004, Riccardo Mottola wrote: > Jorge Arellano Cid wrote: > > > > > The "pre1" tarball can be found at: > > > > http://www.dillo.org/download/dillo-0.8.1-pre1.tar.bz2 > > > > When testing it, please pay special attention to the new > > detection routine for socklen_t (at ./configure time), and give > > the downloads server a hard test. > > I'm testing the pre on solaris 2.6. > > on Solaris 2.6 it says "int" > > > > Feedback is very important now, because I want to remove the > > "alpha software" label from dillo and name it as stable (beta). > > I was visiting osnews.com which I regularly visit with dillo 0.80. Are you saying that 0.8.0 worked OK on the same machine? > Using > pre 0.8.1 I saw the first two text boxes render and then all stopped. > The console said: > Dns_server [1]: www.newmobilecomputing.com is 112488 > Gdk-ERROR **: BadMatch (invalid parameter attributes) > serial 8039 error_code 8 request_code 72 minor_code 0 > > visiting my own website at http://carduus.chanet.de yields the same > problem, the first text lines appear and then: > Dns_server [0]: carduus.chanet.de is 112598 > Connecting to 217.110.112.61 > Gdk-ERROR **: BadMatch (invalid parameter attributes) > serial 4012 error_code 8 request_code 72 minor_code 0 > > Unfortunatly, I installed the new dillo over the old one so I cannot > test the old anzmroe, but I bet it wasn't so bad. Now I can't visit any > site at all basically. Definitely those sites work with 081. It looks like a machine-specific problem. Unfortunately I don't have a Solaris 2.6 at hand to test. BTW, I know dillo works on Solaris 8, and frankly Solaris version numbers are confusing to me. Which SunOS number is given for 2.6? > I will test other platforms. Thanks Cheers Jorge.-

May 3, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by Jorge Arellano Cid

On Sun, 2 May 2004, robert w hall wrote: > In article <Pine.LNX.4.58.0405012200030.1900(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)dillo.org> writes > > > > Yes, but the tarball is recommended because it tests the "configure" > >script (otherwise it is generated by the local auto* tools). > > > on playstation2-linux, tarball compiles and runs OK (socklen_t test went > by without demur) > (- still can't get the default installation to do downloads properly > (dpid starts, but I get messages about 'unhandled MIME types on bz2 > files...) - but this may well be finger trouble on my part.) When you left-click a link, the remote resource is requested for viewing; that's why dillo complains about an unhandled MIME type (it can't display it). If you choose "Save Link As..." from the link menu, the URL will be passed to the downloads dpi and retrieved and saves as a local file. Cheers Jorge.-

May 3, 2004

Re: [Dillo-dev]GTK FLTK and other Render

by 阿贵

Hi, If you want a browser in FB/DirectFB, try <b>links</b>: http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/download.html Hope this might help regards Hansom Young shuishuila wrote: >Hi, dillo-dev， > > I want to port dillo to set-top box as menu(OSD). But it don't have >X11,GTK. How many work need to do if I have to write widget myself? > > I think it's a pity that dillo combine tightly with glib/gtk, so it >is hard to port to X,FrameBuffer,DirectFB etc. > > If dillo have it's own widget and event handle, it is a excellent >broswer for embedded system. > >Regards, >　　　　　　　　shuishuila >　　　　　　　　shuishuila(a)hotmail.com >　　　　　　　　　　2004-04-30 > > > >

May 3, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by Riccardo Mottola

Jorge Arellano Cid wrote: > > The "pre1" tarball can be found at: > > http://www.dillo.org/download/dillo-0.8.1-pre1.tar.bz2 > > When testing it, please pay special attention to the new > detection routine for socklen_t (at ./configure time), and give > the downloads server a hard test. I'm testing the pre on solaris 2.6. on Solaris 2.6 it says "int" > Feedback is very important now, because I want to remove the > "alpha software" label from dillo and name it as stable (beta). I was visiting osnews.com which I regularly visit with dillo 0.80. Using pre 0.8.1 I saw the first two text boxes render and then all stopped. The console said: Dns_server [1]: www.newmobilecomputing.com is 112488 Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 8039 error_code 8 request_code 72 minor_code 0 visiting my own website at http://carduus.chanet.de yields the same problem, the first text lines appear and then: Dns_server [0]: carduus.chanet.de is 112598 Connecting to 217.110.112.61 Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 4012 error_code 8 request_code 72 minor_code 0 Unfortunatly, I installed the new dillo over the old one so I cannot test the old anzmroe, but I bet it wasn't so bad. Now I can't visit any site at all basically. I will test other platforms. -Riccardo

May 3, 2004

Re: Re: [Dillo-dev]GTK FLTK and other Render

by shuishuila

Hi,Jorge, Thank you for your reply. FLTK need X, so I need to port microwindows at least. Why no let dillo's render engine more scalable? And I think that few desktop system have FLTK. Regards, shuishuila(a)hotmail.com 　　　　　　　　　　2004-05-03 ======= 2004-05-02 10:41:00 You Wrote：======= >On Fri, 30 Apr 2004, shuishuila wrote: > >> Hi, dillo-dev， > > Hi. > >> >> I want to port dillo to set-top box as menu(OSD). But it don't have >> X11,GTK. How many work need to do if I have to write widget myself? > > That's a lot of work, but... > >> >> I think it's a pity that dillo combine tightly with glib/gtk, so it >> is hard to port to X,FrameBuffer,DirectFB etc. >> >> If dillo have it's own widget and event handle, it is a excellent >> broswer for embedded system. > > We're almost done with a plan to port Dillo to FLTK. > > You can read about it in our mailing list archives. Start here: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-April/001882.html > > > If you have FLTK knowledge and are willing to help us doing the >port it'd be great. > > Cheers > Jorge.- = = = = = = = = = = = = = = = = = = = =

May 3, 2004

[Dillo-dev]dillo-0.8.1-pre1.tar.bz2 on ps2

by robert w hall

In article <Pine.LNX.4.58.0405012200030.1900(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Yes, but the tarball is recommended because it tests the "configure" >script (otherwise it is generated by the local auto* tools). > on playstation2-linux, tarball compiles and runs OK (socklen_t test went by without demur) (- still can't get the default installation to do downloads properly (dpid starts, but I get messages about 'unhandled MIME types on bz2 files...) - but this may well be finger trouble on my part.) >>FAIK, you'll have to! (do the test). > > As for the kids, no problem, it could be tomorrow too :-) > the sun came out so they're down the skate-park... :-) -- robert w hall

May 2, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by Jorge Arellano Cid

On Sat, 1 May 2004, robert w hall wrote: > In article <Pine.LNX.4.58.0405011313350.1900(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)dillo.org> writes > > > > Feedback is very important now, because I want to remove the > >"alpha software" label from dillo and name it as stable (beta). > > > > > > Thanks in advance > > Jorge.- > > > > > 1) Is this also current cvs? Yes, but the tarball is recommended because it tests the "configure" script (otherwise it is generated by the local auto* tools). > 2) Is anyone else going to test on a playstation-2 - or do I have to > boot the kids off the machine on a British (wet!) bank-holiday! AFAIK, you'll have to! (do the test). As for the kids, no problem, it could be tomorrow too :-) Cheers Jorge.-

May 2, 2004

[Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by Jorge Arellano Cid

Hi there, It took a long time to prepare the pre1 tarball for the next release. Mainly because complex problems were discovered in the last minute. For instance, a race condition in the dpi chain that produced segfaults (it took three days to find and fix), and several problems with the downloads server (it had troubles when saving unnamed pages as "index.html" when the file already existed, it was also not renaming those pages, etc). The "pre1" tarball can be found at: http://www.dillo.org/download/dillo-0.8.1-pre1.tar.bz2 When testing it, please pay special attention to the new detection routine for socklen_t (at ./configure time), and give the downloads server a hard test. Feedback is very important now, because I want to remove the "alpha software" label from dillo and name it as stable (beta). Thanks in advance Jorge.-

May 1, 2004

Re: [Dillo-dev]dillo-0.8.1-pre1.tar.bz2

by robert w hall

In article <Pine.LNX.4.58.0405011313350.1900(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Feedback is very important now, because I want to remove the >"alpha software" label from dillo and name it as stable (beta). > > > Thanks in advance > Jorge.- > > 1) Is this also current cvs? 2) Is anyone else going to test on a playstation-2 - or do I have to boot the kids off the machine on a British (wet!) bank-holiday! -- robert w hall

May 1, 2004

[Dillo-dev]is anyone planning to add SpiderMonkey (JavaScript-C) Engine to Dillo?

by Miernik

Is any work going on to add SpiderMonkey (JavaScript-C) Engine to Dillo? http://www.mozilla.org/js/spidermonkey/ I once saw a post of somebody who planned to do something like that, but heard of no progress later. I would be very interested in such implementation. -- Miernik _________________________ xmpp:miernik@amessage.info ___________________/__ tel: +48888299997 __/ mailto:miernik@ctnet.pl http://www.miernik.ctnet.pl/

May 1, 2004

[Dillo-dev]dillo interface and motif, athena etc

by Riccardo Mottola

Hello. I have never looked at dillo's source code directly, so I am asking some general questions here I have always liked dillo's speed and use of system resources because it brings back the fun of browsing and works on older workstations too, as every browser should. But I never liked dillo's interface too much. I'd like to make it a proper interface, more like other browsers have, taking inspiration for example from Mosaic's bar and bookmarks, from chimera's simplicity, from HotJava cutsomization, etc. Also, I dislike GTK: they are slow and don't work well on 256 color screens. I would use Motif for writing the interface with having an eye on LessTif of course. Motif/Lesstif is extremely fast and works like a charm on my old 20Mhz IBM RS6k witha 256 color card. Also, most free OS users have one of the either installed too, to run stuff like the excellent NEdit. Being able to install dillo on AIX, Solaris, IRIX, HP-UX without having to install an additional toolkit would just be nice. Athena is also present everywhere, but let's say it is a bit primitve. Of course, super-fast :) So I ask: how much of dillo's code is GTK dependent and how difficult would it be to port it to another toolkit? I have quite little experience with toolkits and since I don't know GTK it seems impossible to me alone. One of the nicest things, IMHO, would be a toolkit-independent dillo. Have a look at what the excellet GVIM does or at what amaya does (or, at least, did). Choose your toolkit! I don't know how they structured their code and their graphic drawing, but it would be interesting to investigate. -Riccardo

May 1, 2004

[Dillo-dev]GTK FLTK and other Render

by shuishuila

Hi, dillo-dev， I want to port dillo to set-top box as menu(OSD). But it don't have X11,GTK. How many work need to do if I have to write widget myself? I think it's a pity that dillo combine tightly with glib/gtk, so it is hard to port to X,FrameBuffer,DirectFB etc. If dillo have it's own widget and event handle, it is a excellent broswer for embedded system. Regards, 　　　　　　　　shuishuila 　　　　　　　　shuishuila(a)hotmail.com 　　　　　　　　　　2004-04-30

April 30, 2004

Re: [Dillo-dev]Re: Test for socklen_t in configure.in

by Jorge Arellano Cid

Hi, Sorry, I just realized that a "pre" tarball is required to test the socklen_t detection (else it depends on the local machine's installed auto* tools). I'm preparing it, stay tuned. Cheers Jorge.-

April 30, 2004

Re: [Dillo-dev]Re: Test for socklen_t in configure.in

by Johannes Hofmann

Hi, works fine here on a pretty current DragonFly BSD machine. Relevant lines from config.log: configure:3666: checking for socklen_t configure:3692: gcc -c -g -O2 -I/usr/local/include conftest.c >&5 configure:3695: $? = 0 configure:3698: test -s conftest.o configure:3701: $? = 0 configure:3754: result: socklen_t <snip> ac_cv_prog_make_make_set=yes ac_cv_socklen_t=socklen_t ac_cv_target= Cheers, Johannes On Fri, Apr 30, 2004 at 08:30:37AM -0400, Jorge Arellano Cid wrote: > > > On Wed, 28 Apr 2004, Jorge Arellano Cid wrote: > > > > > Hi there, > > > > Our configure.in is in need of a test for socklen_t. I thought > > this one could be a good one: > > > > dnl ------------------- > > dnl Check for socklen_t > > dnl ------------------- > > dnl > > [...] > > > but my autoheader complains... > > > > Can someone please complete the patch, I'm currently chasing a > > segfault bug I found... > > > Fixed, and commited. It only requires testing, specially on non > GNU/Linux environments, specially the *BSD ones. > > Please tell me how it works. > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 30, 2004

[Dillo-dev]Re: Test for socklen_t in configure.in

by Jorge Arellano Cid

On Wed, 28 Apr 2004, Jorge Arellano Cid wrote: > > Hi there, > > Our configure.in is in need of a test for socklen_t. I thought > this one could be a good one: > > dnl ------------------- > dnl Check for socklen_t > dnl ------------------- > dnl > [...] > but my autoheader complains... > > Can someone please complete the patch, I'm currently chasing a > segfault bug I found... Fixed, and commited. It only requires testing, specially on non GNU/Linux environments, specially the *BSD ones. Please tell me how it works. Cheers Jorge.-

April 30, 2004

[Dillo-dev]Test for socklen_t in configure.in

by Jorge Arellano Cid

Hi there, Our configure.in is in need of a test for socklen_t. I thought this one could be a good one: dnl ------------------- dnl Check for socklen_t dnl ------------------- dnl AC_MSG_CHECKING(for socklen_t) AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> socklen_t x; ], [], [AC_MSG_RESULT(yes)], [ AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> int accept(int, struct sockaddr *, size_t *); ], [], [ AC_MSG_RESULT(size_t) AC_DEFINE(socklen_t, size_t)], [ AC_MSG_RESULT(int) AC_DEFINE(socklen_t, int)])]) but my autoheader complains... Can someone please complete the patch, I'm currently chasing a segfault bug I found... TIA Jorge.-

April 28, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Jorge Arellano Cid

Hi Francis, First of all, thanks for your research and well backed answer. Here I go: On Tue, 27 Apr 2004, Francis Daly wrote: > On Mon, Apr 26, 2004 at 07:48:11PM -0400, Jorge Arellano Cid wrote: > > On Thu, 22 Apr 2004, Jens Arm wrote: > > > > > Please test our current CVS hardly, and tell us how it did. > > > > > > Directories like > > > > > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > > > > > or others are not rendered correctly > > > > Yes. This is a complex problem. > > > > Apache (the web server), generates bad HTML for directory > > listings (at least 1.3.x series): > > > > <PRE> is an inline container excluding: > > > > {IMG, OBJECT, APPLET, BIG, SMALL, SUB, SUP, FONT, BASEFONT} > > > > Also, it can't hold block elements (e.g. HR). > > > > > > So there's a bug in having <HR> inside <PRE> and one bug per > > directory entry because <PRE> can't contain <IMG>. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9307 and <q from above URL> Yes, it's a known issue. In 2.0 and later, tables can be enabled by configuration. 1.3 will stick with the <pre> stuff, also because of backwards compat, sorry. <q> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13351 suggest that > the apache developers know, and it's not going to change in the 1.3 > series. Well, they know the bad HTML issue and made a tables version for the directory listing (that was also faulty but that as of the bug entry should be corrected now). > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10880 suggests that > the default won't change in the 2.0 series, <q from above URL> Item 1 has been fixed in 2.1 and is proposed for backport. Item 2 ... ehm? what standard? html? agreed. ;-) As said you can use IndexOptions to fix that issues. For backwards compat we should stick with the current defaults. Item 3 doesn't appear in the current tree so I'm assuming it fixed already. </q> The backwards compatibility is a point that was easy to foresee. Although the developer above doesn't seem to be much concerned about the standards, and this surprises me. A simple solution woud be to replace: -<HR> +</PRE><HR><PRE> and replece the <IMG> tag with its alt text, and make _that_ the default in apache. They could provide an option to produce the old directory listing, and thus, leave the responsibility of deciding whether to serve bad HTML to every webmaster, but the default should be valid HTML (IMHO). In brief, the webmaster would have: - Good HTML by default (no images) based on <PRE> - The option to serve bad HTML with images based on <PRE> - The option to serve good HTML with images based on <TABLE> > > > After analizing the produced HTML for directory listings, I > > found that isolating the <HR> outside <PRE> is a trivial fix that > > helps keeping the block element outside. > > > > That is: > > > > - <HR> > > + </PRE><HR><PRE> > > > > Very simple. It would allow for violations of the type "inline > > container with excluded inline element within" (instead of > > "inline container with a block inside"). > > > > Does anyone know an apache developer? It seems that sending the > > patch through bugzilla could take years to be noticed... > > It can be a bit hit and miss. If one of the core team is directly > interested and not otherwise engaged, they can get things done quickly. I got a bit discouraged to make the patch and submit it because it's a toilsome work that I don't know will have a warm reception ;) If you feel like doing it, please go ahead, but I'd suggest first to contact one of the developers and explain the idea before making a patch. It's reasonable, unless they have to support some scripts that rely on the directory listing source being served exactly the old way... > > Their most recent attempt not to lose patches seems to be described in > http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108012889313136&w=2 > which suggests that bugzilla may be being watched closely. This is good news. But the whole issue is more a "backwards compatibilty" problem than "valid HTML". This is better to be asked in advance. > > > OTOH, I don't like very much breaking our policies with code to > > handle bad HTML, and yes I know this is the most used web server. > > Maybe a dillorc option to enable a workaround for apache could do > > it, but I'd really like to talk with one of the developers. > > > > Comments? > > As others have said, any future change to apache won't change current > servers for years to come. Sigh, I suppose this is right. Even under the pressure of a security-fix release... > So rendering it usefully, if not ideally, would be prudent. And a big > black mark in the bug meter is in order, too. > > Correctness vs usefulness... Yes Francis, I think the same as you, but I'd appreciate if someone asks them if serving good HTML without the images for the directory listing is a good default (providing the alternatives described above). For those that read this far: the CVS contains the patch I made for this issue. Cheers Jorge.-

April 28, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Pete

On Tue, Apr 27, 2004 at 04:11:19PM +0100, Francis Daly wrote: > > > I may be missing something with this. What I think I am reading is > > that this is an Apache issue as far as why the page isnt rendering > > well. I am running Thttp for a server. I copied the source and stuck > > it on my server. It then will not render well with Dillo either. > > The fact is that the html is invalid, and therefore renders funny. > Saving the html and serving it from another web server, or fetching it > from a file, won't change that it is invalid. > > The reason it is an apache problem is that the html is generated by > apache, not that it is served by apache. > Ok, that is what I was thinking but wasnt sure. Seeing all these webservers serve up the html incorrectly, do you make them correct the issue or do you have Dillo also 'render incorrectly'? I know there are a lot of sites that are not rendered correctly with Dillo. Whether these issues would be the reason or not I am not educated enough to know. Thanks for the explination though. -- Pete http://milneweb.com http://nomorevirus.com

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Francis Daly

On Tue, Apr 27, 2004 at 08:44:45AM -0600, Pete wrote: > On Tue, Apr 27, 2004 at 12:19:51PM +0100, Francis Daly wrote: > > On Mon, Apr 26, 2004 at 07:48:11PM -0400, Jorge Arellano Cid wrote: > > > On Thu, 22 Apr 2004, Jens Arm wrote: > > > > Directories like > > > > > > > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > > > > > > > or others are not rendered correctly > > > > > > Yes. This is a complex problem. > > > > > > Apache (the web server), generates bad HTML for directory > > > listings (at least 1.3.x series): > I may be missing something with this. What I think I am reading is > that this is an Apache issue as far as why the page isnt rendering > well. I am running Thttp for a server. I copied the source and stuck > it on my server. It then will not render well with Dillo either. The fact is that the html is invalid, and therefore renders funny. Saving the html and serving it from another web server, or fetching it from a file, won't change that it is invalid. The reason it is an apache problem is that the html is generated by apache, not that it is served by apache. > I sense I am still missing part of this discussion but thought I would > add my 2 cents anyways. *;o) Does that fill in the missing bit? As it happens, thttpd (2.25b) has a very similar problem, in that its default directory listing, if enabled, looks like === <H2>Index of /</H2> <PRE> mode links bytes last-changed name <HR>dr-x 2 4096 Mar 23 12:23 <A HREF="/./">.</A>/ === which current dillo will also recognise as invalid, and render not as the server author presumably hoped. Cheers, f -- Francis Daly francis(a)daoine.org

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Pete

On Tue, Apr 27, 2004 at 12:19:51PM +0100, Francis Daly wrote: > On Mon, Apr 26, 2004 at 07:48:11PM -0400, Jorge Arellano Cid wrote: > > On Thu, 22 Apr 2004, Jens Arm wrote: > > > > > Please test our current CVS hardly, and tell us how it did. > > > > > > Directories like > > > > > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > > > > > or others are not rendered correctly > > > > Yes. This is a complex problem. > > > > Apache (the web server), generates bad HTML for directory > > listings (at least 1.3.x series): > > > > <PRE> is an inline container excluding: > > > > {IMG, OBJECT, APPLET, BIG, SMALL, SUB, SUP, FONT, BASEFONT} > > > > Also, it can't hold block elements (e.g. HR). > > > > I may be missing something with this. What I think I am reading is that this is an Apache issue as far as why the page isnt rendering well. I am running Thttp for a server. I copied the source and stuck it on my server. It then will not render well with Dillo either. I sense I am still missing part of this discussion but thought I would add my 2 cents anyways. *;o) -- Pete http://milneweb.com http://nomorevirus.com

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Francis Daly

On Mon, Apr 26, 2004 at 07:48:11PM -0400, Jorge Arellano Cid wrote: > On Thu, 22 Apr 2004, Jens Arm wrote: > > > Please test our current CVS hardly, and tell us how it did. > > > > Directories like > > > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > > > or others are not rendered correctly > > Yes. This is a complex problem. > > Apache (the web server), generates bad HTML for directory > listings (at least 1.3.x series): > > <PRE> is an inline container excluding: > > {IMG, OBJECT, APPLET, BIG, SMALL, SUB, SUP, FONT, BASEFONT} > > Also, it can't hold block elements (e.g. HR). > > > So there's a bug in having <HR> inside <PRE> and one bug per > directory entry because <PRE> can't contain <IMG>. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9307 and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13351 suggest that the apache developers know, and it's not going to change in the 1.3 series. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10880 suggests that the default won't change in the 2.0 series, but there may be IndexOptions settings that the web server administrator can use to make it valid. > Parhaps the 2.x.x Apache series produces XML. Does anyone know? http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#indexoptions says that it can (2.0.49 and later) if the admin configures it that way. (I haven't verified it, though.) > After analizing the produced HTML for directory listings, I > found that isolating the <HR> outside <PRE> is a trivial fix that > helps keeping the block element outside. > > That is: > > - <HR> > + </PRE><HR><PRE> > > Very simple. It would allow for violations of the type "inline > container with excluded inline element within" (instead of > "inline container with a block inside"). > > Does anyone know an apache developer? It seems that sending the > patch through bugzilla could take years to be noticed... It can be a bit hit and miss. If one of the core team is directly interested and not otherwise engaged, they can get things done quickly. Their most recent attempt not to lose patches seems to be described in http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108012889313136&w=2 which suggests that bugzilla may be being watched closely. > OTOH, I don't like very much breaking our policies with code to > handle bad HTML, and yes I know this is the most used web server. > Maybe a dillorc option to enable a workaround for apache could do > it, but I'd really like to talk with one of the developers. > > Comments? As others have said, any future change to apache won't change current servers for years to come. So rendering it usefully, if not ideally, would be prudent. And a big black mark in the bug meter is in order, too. Correctness vs usefulness... f -- Francis Daly francis(a)daoine.org

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Riccardo Mottola

Jorge Arellano Cid wrote: > > OTOH, I don't like very much breaking our policies with code to > handle bad HTML, and yes I know this is the most used web server. > Maybe a dillorc option to enable a workaround for apache could do > it, but I'd really like to talk with one of the developers. > > Comments? Yes, I think dillo should render those pages. Even if a new 1.3 version comes out many people won't upgrade immediatly, old evrsions of apache are aorund for a very very long time and I woudl respect this. I think we should have an option like iCab which allows "strict" rendering and then options to make it more and more tolerant. After all we have to use dillo in the real world, not in an ideal one. -R

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Kelson Vibber

On Monday 26 April 2004 4:48 pm, Jorge Arellano Cid wrote: > OTOH, I don't like very much breaking our policies with code to > handle bad HTML, and yes I know this is the most used web server. > Maybe a dillorc option to enable a workaround for apache could do > it, but I'd really like to talk with one of the developers. No offense, but you have *got* to be kidding about (a) not working around this in some way, (b) expecting a program with an install base orders of magnitude higher than Dillo to change immediately, and (c) actually adding an "unbreak my application" preference. Even if Apache is fixed next week, how long will it take for the millions of sites using it to upgrade? What about all those installations using an OS distribution that keeps using the same old 1.3.10 or whatever, just backporting security patches? I see little harm in working around this bug, but if you prefer not to cater to it, perhaps a compromise would be to discard the invalid HR, rather than end the PRE block early. -- Kelson Vibber www.hyperborea.org

April 27, 2004

[Dillo-dev]what should do after the window is scrolled?

by Lei Jin

After the window is scrolled, should the new contents of the window be redrawed by the code written by human? Can we output the whole contents to a place, then when the window is scrolled, we only need to updated the visible rectangle parameter? --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！

April 27, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Jorge Arellano Cid

On Thu, 22 Apr 2004, Jens Arm wrote: > > Please test our current CVS hardly, and tell us how it did. > > Directories like > > http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ > > or others are not rendered correctly Yes. This is a complex problem. Apache (the web server), generates bad HTML for directory listings (at least 1.3.x series): <PRE> is an inline container excluding: {IMG, OBJECT, APPLET, BIG, SMALL, SUB, SUP, FONT, BASEFONT} Also, it can't hold block elements (e.g. HR). So there's a bug in having <HR> inside <PRE> and one bug per directory entry because <PRE> can't contain <IMG>. As usual, the problem is not black or white, because producing valid HTML for the directory listing would require tables (if you want to keep the image). Probably, a long time ago, they considered the situation and found that bad HTML using PRE was more portable than one based on TABLE. I don't know for sure. Parhaps the 2.x.x Apache series produces XML. Does anyone know? After analizing the produced HTML for directory listings, I found that isolating the <HR> outside <PRE> is a trivial fix that helps keeping the block element outside. That is: - <HR> + </PRE><HR><PRE> Very simple. It would allow for violations of the type "inline container with excluded inline element within" (instead of "inline container with a block inside"). Does anyone know an apache developer? It seems that sending the patch through bugzilla could take years to be noticed... OTOH, I don't like very much breaking our policies with code to handle bad HTML, and yes I know this is the most used web server. Maybe a dillorc option to enable a workaround for apache could do it, but I'd really like to talk with one of the developers. Comments? Cheers Jorge.- PS: Patching Dillo to render it is trivial. Though it could break other pages...

April 26, 2004

Re: [Dillo-dev]install-dpi-local missing?

by Jorge Arellano Cid

On Fri, 23 Apr 2004, Livio Baldini Soares wrote: > Hello everyone, Oi Livio! > > Long time no see, I know, I know... My life has been a (wonderful) > big roller-coaster for the last 1 to 2 years, and it seems that the > remainder of this year will be the same. Is good to know you're still there!, and just in time: > [on Fri, 31 Jan 2003 Livio wrote:] > > Bom, e tenho até março de 2004 para terminar o mestrado. Então esse > ano devo estar trabalhando bastante nesse projeto, mas eu creio que > terei um tempinho para ir ajudando o nosso querido Dillo. (Sloppy translation: Well, I have until March 2004 to finish the (Magister or Master). Then that year I must be working hard on that project, but I believe I'll have some time to help our dear Dillo. ) It'd be great if you can have the time to be back on Dillo. As usual there're plenty of things to do. Just let me know a plausible workload. > Anyways, just wanted to try to report that reading the README file, > one gets the impression that an "install-dpi-local" script should > exist to install the dpis in your ~/.dillo/ directory for you. I have > googled for it, and tried searching in the CVS ATTIC with no > success. Things are working for me just fine, because I know how/where > to copy the dpi files, but I can imagine that some of our users might > be frustated, or require additional assistance. > > So, before releasing 0.8.1 it might be a good idea to fix the > README, explaining what is needed for a "local" install, or even > better, resurrect the install-dpi-local script. Fixed. Actually the script exists inside the 0.8.0 tarball, but I forgot to add it into the CVS. > best regards to all! Um abraço! Jorge.-

April 26, 2004

[Dillo-dev]About porting Dillo to FLTK.

by Jorge Arellano Cid

Hi there, We've had long email threads (between our core developers and some FLTK core devs.) dicussing about how the port of dillo to FLTK could be done. We've explored different paths (in abstract) and posting all the threads to dillo-dev would add more to confussion than clarity because each one was explored as it were the chosen one. For simplicity and to keep all the developers in dillo-dev well informed (and certainly inviting the interested ones to take part in the process), I prepared this recapitulation about the more relevant issues. It's a long document with a lot of information. Cheers Jorge.- PS: Previous background on this topic can be found at dillo-dev's archives: http://www.dillo.org/search-dillo-dev.html. For instance: search for "FLTK" by "jcid" sorted by "Relevance". This will not only bring my posts but also the ones from Michael Sweet that I forwarded to dillo-dev. ---------------------------------------------------------------- > [Sebastian] > Furthermore, I have plans to extract at least the core of Dw, and make > an own library of it. The package is already finished, I'm just > polishing another package, which uses Dw. (This is "rtfl", the program > for which the macros in "debug.h" are for.) > > Perhaps it is at least possible, to make Dw itself independent of the > widget toolkit (Gtk/FLTK), ... > [Sebastian] > Dw can be rather simply extracted, and probably it is the best to > start with a testbed. I've attached a test program (I searched > for it somewhere in the mailing list, therefore the french > identifiers :-), you have to build dillo first, to run > it. Perhaps it is simpler to include it into the dillo tarball > itself. > [Sebastian] > Another aspect is portability: When using other toolkits than Gtk, > GtkDwViewport may be replaced. > > For archieving this, the following new design will be sufficient: > > +--------------------+ 1 * +-------------------+ > | DwRenderingContext |---------->| DwRenderingWindow | > +--------------------+ +-------------------+ > 1 ^ | 1 > | | > viewport | | child (the top-level DwWidget) > | | > * | V 0..1 > +----------+ 0..1 > | DwWidget |--. parent > +----------+ | > * | | > `-------' > (children) > [Sebastian] > As for the actual porting, I'm currently working on two topics, which > should make porting simpler, since they reduce the Gtk/Gdk specific > stuff into single modules: > > 1. I'm currently changing the design of image handling as I > described in doc/DwImage.txt in the tarball, section "Future > Extensions". As I've seen now, this is also necessary for > topic 2. > > 2. After this, I'll implement the ideas I wrote before (abstraction > of the actual drawing), in the best case, it should be a simple > matter to write a replacement for the viewport, plus some > changes in dw_style.[ch]. (Dependance of the GtkObject model not > yet considered.) > [Matt] > Abstraction is definitely the best thing to do here. I am pretty sure > we can cross reference between the a-layer and whatever FLTK has to > offer. Spontaneously I see the need for buttons and input fields, line, > box, text and image drawing, image scaling and the dreaded 16-bit vs. > 32-bit coordinates. > > [Jorge] > > Once again, I'd wish to know how a seasoned FLTK developer > > foresees the merging path (from their point of view). With regard > > to Dw, you're the authoritative source! ;) > > [Matt] > At this point - if you guys are still interested - I guess I should > take an extensive tour through the Dw code and see, which parts map > directly onto FLTK, and which parts would need modifications or even > rewriting. ------------------ 32 bit coordinates ------------------ > [Jorge] > > Hi Michael, > > We have been extensively discussing how to port Dillo to FLTK > with Mattias M. and Sebastian. One of the key points is how to > provide for a widget that overcomes the problem of 16 bit > coordinates (GtkLayout currently solves this). > > In a formar email you told me that FLTK2.0 had 32 bit > coordinates, but suggested me to use 1.2.x release that would > also come with 32 bit coordinates. > > Matt was somewhat surprised by this... > [Matt] > I talked to Mike. He changed the coordinates to 32 bit in his local > version already. So in short, fltk 1.2 will have 32 bit coordinates. > Versions 1.1 and 1.0 will not be changed anymore, however 1.2 should > become the standard as soon as we release it, since it is source code > compatible to 1.1. > [Matt] > I went through the current CVS code yesterday, and it seems like we had > a mixup between 1.1 and 1.2. Not a biggie, but I re-merged with a > previous CVS version. The current CVS is now fully 32 bit. tested and > working. > [Jorge] > So we have to use 1.2.x CVS, but which docs are recommended for it? > > [Matt] > The 1.2 cvs contains the full 1.1 documentation and is beeing corrected > to reflect 1.2 changes and additions. I am in the process of adding > doxygen style comments to all fltk classes and methods (95% done), so > simply running the command 'doxygen' will create a second, more > 'techie' documentation in docs/html/index.html. ------- Signals ------- > [Jorge] > Appart from that, the 32 bit issue and the signals (perhaps > solved with Fl_Signal). > [Sebastian] > As for signals: This should be rather simple to re-implement. I just > hacked a prototype of very simple framework for signals, which can be > downloaded at <http://www.dillo.org/misc_files/signals-0.0.1.tar.gz>. > It lacks events returning boolean (which we need), and some more > features (which we do not need), but shows that signals aren't really > a problem. ------- Plugins ------- >> OK, there's no plugin API in FLTK. > > Do you mean what GtkPlug/GtkSocket does? There protocol has been (or > is currently?) standardized at freedesktop.org, if an implemtation is > possible (and why should it not?), this is certainly a candidate for > merging into FLTK. > > > [Matt] > > Yeah, I talked to Bill, and we decided that we will create an Fl > > utility library that offers cross platform access to files and sockets, > > provides threads and locks, and also some standardised plugin > > interface. We will be smarter this time and write it in FLTK2 with an > > FLTK1 compatibility layer... . ------------------------------ About how to approach the port ------------------------------ > > >> [Sebastian] > > >> I'm more > > >> than ever convinced that this was the right decision, especially since > > >> then, incremental resizing has been added, what would have been very > > >> difficult in Gtk. Furthermore, this shows the benefit of having an own > > >> widget set, which can be infinitively changed to our needs. > > > > > > [Jorge] > > > In that case, it seems that the path to go is to port Dw to > > > FLTK, and maybe get rid of some widgets (as DwImage) when they > > > can be replaced by an FLTK embedded one. > > > > > > In anycase, Matt is better qualified than me to comment on > > > this. > > > > [Matt] > > All images in FLTK can be resized at any point. > > > > I understand that you prefer to have your own widget set, and I surely > > don't want to convince you different (because we wanted the same thing > > and that's why we wrote FLTK in the first place). However, should you > > decide to go with FLTK, then all the source code is available to you, > > so you can do the same modifications that you would do in your code. If > > those changes (or additions) are useful for the FLTK toolkit, I'll be > > happy to do them for you (ah, that's where the benefit is for you). > > [Jorge] > This is a very interesting collaboration scenery. I believe we > could start as Sebastian suggests, and merge those features you > see could benefit FLTK. (as for images, and maybe the "complex > resize" widget using size hints to name two). > > [Sebastian] > To make this clear again: What we currently have is an own widget > toolkit within Gtk, i.e. Dw widgets, from which the page is build, are > not Gtk widgets, but instead, for Gtk, a tree of Dw widgets is a just > _one_ huge Gtk widget. (With the exception of Gtk widgets embedded > into Dw.) > > I'd like to stick with the same design (with FLTK instead of Gtk), > also on the long run. For this, there are rather few requirements for > the GUI toolkit, mainly only the 32 bit issue. Integrating both > toolkits, in the way that Dw widgets will become FLTK widgets, will > however make things generally more complicated, we will have a hybrid > which has to deal with both rendering HTML (and other) documents on > one hand and GUIs on the other hand. The duplicate code in the current > design (like event handling), is rather minimal, but integrating would > mean one of the following possibilities: > > 1. Making FLTK as abstract as possible: This would make Dw as > complex as it is now, but instead add an unneccessary > dependency, where the development of dillo will often have to > deal with the limits which any GUI toolkit has. > > 2. Incorperating stuff from Dw into FLTK: This would IMO a very bad > decision of the FLTK team. Dw was designed for rendering > documents etc., and its layout mechanism has several ad hoc > features (size hints, width extremes, incremental resizing), > which should not be in a toolkit for GUIs. Actually, the design > is quite ugly at some points. > > Furthermore, the design often changes, some historical examples: > > - Dw widgets had baselines from the beginning, but they were > fist used much later. (I was indeed hesitating at the > beginning.) > - Tables made it neccessary to introduce width extremes. > (Very ad hoc: Why not height extremes? Because texts are -- > in most languages -- written horizontally, and then > vertically split into lines.) > > - Also with tables (although noticed some time later), it > became clear that the current resizing mechanism was > inefficient and had to be extended. (Notice that Dw > requires that several resizes per second must be handled, > much more what is neededfor GUIs.) > > These were certainly not the last changes, e.g. for CSS, we will > have some other requirements, which are yet not specified. Also, > this shows that most requirements are not obvious before they > are first needed. > > If FLTK wants to adopt Dw features, it will be neccecary to > change FLTK often, and since it is not part of dillo, the > development of dillo will be slowed down, until new FLTK > releases. > > 3. We move stuff from Dw into our own version of FLTK: This would > probably the worst possible desicion, we would fork FLTK and > have to maintain it, also the parts which deal with pure GUI > aspects. > > Dw will work fine with FLTK in the way analogue to the current way, > and the problems with this split are really not as dramatic as Jorge > describes it. The FLTK developers should not make the mistake to take > just one (probably rather prominent) project and change their work so > that it just fits within it. And dillo should keep it dependencies as > low as neccessary. ------------ Porting Plan ------------ > [Sebastian] > I'd suggest the following: > > 1. Finish the planned abstractions. The general idea is to have the > Gtk/FLTK specific code in small modules, which may be rewritten in > a simple way. > > 2. Extract Dw from dillo, and write a test program for several aspects > of Dw. > > 3. Rewrite those modules mentioned in 1, and adjust the test > program. This step will still make Gtk necessary, because of the > Gtk object model, but UI control, event handling etc. will be done > by FLTK. > > AFAIS, the affected modules are the new GtkDwViewport, ImgBuf, and > DwStyle. The abstraction in step 1 may taken a bit more extreme, by > splitting up the latter two into toolkit-dependant and -independant > parts, we'll see. The dillo widgets themselves should not be > modified, if this is really necessary, this is a fault of the said > abstraction. > > After this, we will have a version of Dw, which works with FLTK. The > next step is to see how the parts we take from Gtk (object model with > signals) and GLib (several utilities) can be replaced, so that we can > get rid of the Gtk dependencies. Another topic it the port of the > actual UI; AFAIS, there should be no major problems. Appendix -------- -------------- About printing -------------- > > [Jorge] > > Is printing lost because the widget tree is not native FLTK, or > > is it assured by using FLTK's drawing primitives? > > [Sebastian] > Some remarks on this. First, we still have a "native" FLTK widget, > just that we have one large, complex FLTK widget (which complexity is > manages by Dw), instead of multiple smaller and simpler FLTK > widgets. The reimplementation of the viewport should use FLTK methods > for drawing, so there is no problem at all. > > Second, the abstraction described above should make this possible with > any toolkit, it should be simple to write a printing "viewport". > > Third, printing will anyway become more complex, for several > reasons. For one reason, I quote myself from a mail I sent Jorge, this > may also be interesting for Matt: > > <q> > I'm very sceptical about the idea to use the current rendering for > printing, for two reasons: First, the current rendering is designed > for dealing with viewports, not for pages. Pages are in some ways > different, e.g. you must break pages (instead of having one page of > unlimited height), and you cannot widen the page, you must break a > word, when it does not fit into the line, while it is more > reasonable to let the user scroll to the right, when this is > possible. (Furthermore, from a typographic point of view, dillo's > typesetting quality is sufficient for screen rendering, but rather > poor for printing, especially page breaking cannot be done as > simply as line breaking.) > > Second, most of the complexity has its roots in the requirement of > incremental rendering, which is neither needed, nor desired for > printing. Actually, it makes use for printing more complicated and > inefficient. (Although one rendering iteration has a nearly > constant time, it is as a whole still slower than a simple > non-iterative run.) > > [...] > </q> > > Furthermore, even if we would use Dw for printing (with ugly page > breaks etc.), we would need another widget tree, with the same content > of the current one, but with a state, which is different, e.g. the > top-level available width, which is the window width for the screen, > but the standard paper width for the printer.

April 24, 2004

Re: [Dillo-dev]Can't start dpid

by Barry Kauler

On Wed, 14 Apr 2004 13:20:42 -0600 Barry Kauler <bkauler(a)goosee.com> wrote: > > > > the problem is dpid won't start in my custom Puppy Linux > > > distro. > > Jorge, > Thanks for the feedback. > Now that I have dillorc file, dpid does load, but it still isn't > working. > If I start dillo from the commandline, and enter a url https://www.paypal.com, > nothing at all happens in the browser, no error msg even. > I get this output from dillo on the stdout/errout: > > Nav_open_url: Url=>https://www.paypal.com< > url_str = https://www.paypal.com > Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] > Dpi: [Dpi_process_io] IOClose > > The paypal site is working, I just checked with Mozilla. > > If I right-click on a link to a file on a webpage and choose to > "Save link as...", the destination choice window comes up, but > after pressing OK button, the stdout/errout is this: > > ERROR: [Dpi_get_token] Can't find token start > ERROR: [Dpi_get_token] Can't find token start > ERROR: [Dpi_get_token] Can't find token start > ERROR: [Dpi_get_token] Can't find token start > Dpi: [Dpi_process_io] IOClose > Ok, I have used the modified file out of cvs, downloads.c, and yes, it does make a difference. Now I have downloading, except that there is something peculiar about the receive buffer. My file does not immediately see the file. I have only tried very small files. Refreshing ROX-Filers view of the directory does not help, but I mess around downloading some other file, and the previous one suddenly appears. But, ftp and https are still non-functional, as earlier reported. The https attempt is shown above, my report on trying ftp was in an earlier email. Maybe it is something to do with uClibc. Note, I've released Puppy version 0.8.5, with Dillo 0.8.0 with the modified downloads.c. It's a 45M iso, live-CD. www.goosee.com/puppy www.goosee.com/puppy/news.htm www.goosee.com/puppy/download/downpage.htm You should look at the code for the Light web browser. It brings up wget with a nice little window, with a progress bar. Light is also in Puppy, also my developer page has a link to the source. Regards, Barry Kauler

April 24, 2004

[Dillo-dev]install-dpi-local missing?

by Livio Baldini Soares

Hello everyone, Long time no see, I know, I know... My life has been a (wonderful) big roller-coaster for the last 1 to 2 years, and it seems that the remainder of this year will be the same. Anyways, just wanted to try to report that reading the README file, one gets the impression that an "install-dpi-local" script should exist to install the dpis in your ~/.dillo/ directory for you. I have googled for it, and tried searching in the CVS ATTIC with no success. Things are working for me just fine, because I know how/where to copy the dpi files, but I can imagine that some of our users might be frustated, or require additional assistance. So, before releasing 0.8.1 it might be a good idea to fix the README, explaining what is needed for a "local" install, or even better, resurrect the install-dpi-local script. best regards to all! Livio

April 23, 2004

Re: [Dillo-dev]CVS logs / was: Preparing the 0.8.1 release

by Andreas Kemnade

On Fri, 23 Apr 2004 15:47:18 +0200 Nicolas Pouillon <nipo(a)ssji.net> wrote: > Actually "-S" is in my cvs manpage but is refused by auriga.wearlab.de's > cvs server.. Quite a pain as it should restrict display to files with > modifications. > Unless server handles this option, you'll have to find out the > interesting parts by hand. Maybe grepping... That option is afaik only available in more recent versions of cvs. Greetings Andreas Kemnade

April 23, 2004

Re: [Dillo-dev]CVS logs / was: Preparing the 0.8.1 release

by Jorge Arellano Cid

On Fri, 23 Apr 2004, Nicolas Pouillon wrote: > [Fri, 23 Apr 2004 09:00:24 -0400 (CLT)] > Jorge Arellano Cid <jcid(a)dillo.org> eut le bonheur d'écrire: > > > BTW, I still don't know how to recover the last commit-log entries > > from CVS (by date if possible). Any CVS wizard here? > > I'm not too much of CVS wizard, but do you mean something like > cvs log -N -S -d ">= 2004-04-12 00:00:00" ? Yes, but that's too large. Based on it, I'd recommend: cvs log -N -d ">= 2004-04-21 00:00:00" ChangeLog > Or du you wish to sort log entries by date across multiple files ? I was thinking of a way to recover the last commit-log entries by date, and the respective diff file. It's not important though, I can do it very well using diff between the CVS and my tree. > > Hoping it helps Sure, thanks Jorge.-

April 23, 2004

[Dillo-dev]FTP

by Pete

Morning all, Seeing as someone has mentioned 'FTP', I thought I would get in here. I cant seem to FTP with dillo. If I type is ftp://ftp.somewhere.com it will just hang there. If I type in ftp.somewhere.com it will take me to http://ftp.somewhere.com. So tell me, how do you FTP with Dillo? I am using CVS build. Thanks, -- Pete http://milneweb.com http://nomorevirus.com

April 23, 2004

Re: [Dillo-dev]CVS logs / was: Preparing the 0.8.1 release

by Nicolas Pouillon

[Fri, 23 Apr 2004 09:00:24 -0400 (CLT)] Jorge Arellano Cid <jcid(a)dillo.org> eut le bonheur d'écrire: > BTW, I still don't know how to recover the last commit-log entries > from CVS (by date if possible). Any CVS wizard here? I'm not too much of CVS wizard, but do you mean something like cvs log -N -S -d ">= 2004-04-12 00:00:00" ? Or du you wish to sort log entries by date across multiple files ? Actually "-S" is in my cvs manpage but is refused by auriga.wearlab.de's cvs server.. Quite a pain as it should restrict display to files with modifications. Unless server handles this option, you'll have to find out the interesting parts by hand. Maybe grepping... Hoping it helps -- Nipo

April 23, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Jorge Arellano Cid

On Fri, 23 Apr 2004, Jeremy Henty wrote: > > Jorge Arellano Cid wrote > > > Please test our current CVS hardly, and tell us how it did. > > Hi, I have been using dillo CVS since a day or so after you announced > the improved HTML bug detection and error recovery. It is certainly a > great improvement over 1.8.0 . No more occasional crashes (I notice > the "aborts on HTML table inside <sup>" bug I reported is fixed, which > is well cool). Slashdot renders OK now (though I suspect this is > partially due to them cleaning up their cruddy HTML a little). > > Have there been any more improvements in CVS? If so I'll update and > check them out! Sure there are. You can check the change entries here: http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dillo/dillo/ChangeLog BTW, I still don't know how to recover the last commit-log entries from CVS (by date if possible). Any CVS wizard here? > Kudos to the dillo project for a great tool! Thanks a lot. Cheers Jorge.-

April 23, 2004

Re: [Dillo-dev]About proxy authorization && password storing

by Jorge Arellano Cid

On Fri, 23 Apr 2004, Ivan Daniluk wrote: > > [...] > > - renamed a_Http_use_proxy_passwd() to a_Http_set_proxy_passwd(). > > - Made the password not visible when typed. > > - Added a commented entry for "http_proxyuser" in dillorc. > > > > This patch is now in CVS, but is not tested because I don't > > have a proxy at hand! :-) > I've tested - it seems to be ok. Good. > And one correction from Francis Daly: > ------------------------------------------- > > From: "Francis Daly" <francis(a)daoine.org> > > To: "Ivan Daniluk" <Ivan.Daniluk(a)ucl.com.ua> > > > > On Thu, Apr 08, 2004 at 06:49:45PM +0300, Ivan Daniluk wrote: > > Hi there, > > One small thing: > > > + static const char *base64_hex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > > > + "abcdefghijklmnopqrstuvwxyz" > > > + "0123456789._"; > > > > RFC 2068 (HTTP/1.1) defers to RFC 2045 (MIME), which uses "+/" as the > > final two elements, instead of "._". > > > > RFC 1945 (HTTP/1.0) defers to RFC 1521 (MIME, obsoleted by 2045) which > > uses the same. Done! > PS. I've sent a letter to Madis, but have got no reply yet. Yes, he's under too much work now (we were working on the SSL plugin and he had to stop because of his duties). Please allow him some time. BTW, we have a new SSL dpi prototype (not for the next release though). More on this later. I'll send a recapitualtion about the FLTK port first... Cheers Jorge.-

April 23, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Daniel Fairhead

Sorry, forgot to mention platform, Latest CVS (11:30am - Fri 23 Apr 2004), x86 Gentoo Linux System, gcc version 3.3.3 20040217 compiled with CFLAGS='-pipe -O2 -mcpu=pentium2 -march=pentium2 -mmmx -fomit-frame-pointer' Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

April 23, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Daniel Fairhead

Hi, > That is, the new parser (going to lots of sites and asserting > there're no crashes), and the recently found problems with puppy > linux and downloading and FTP (has anyone experienced trouble > with these dillo plugins on their systems?). New renderer seems good. Improvements on some sites. No crashes or anything like that. The FTP plugin seems to be working too, for directories. It doesn't seem to handle files though, it gives me "Illegal Seek" errors. A simple example is ftp.sf.net, and then clicking on index-sf.html or robots.txt. One question... if I go to an invalid ftp URL, it doesn't say in the statusbar "not a directory" or whatever, it only says so in the console, is this correct behaviour? Thanks all, Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

April 23, 2004

Re: [Dillo-dev]Preparing the 0.8.1 release

by Jeremy Henty

Jorge Arellano Cid wrote > Please test our current CVS hardly, and tell us how it did. Hi, I have been using dillo CVS since a day or so after you announced the improved HTML bug detection and error recovery. It is certainly a great improvement over 1.8.0 . No more occasional crashes (I notice the "aborts on HTML table inside <sup>" bug I reported is fixed, which is well cool). Slashdot renders OK now (though I suspect this is partially due to them cleaning up their cruddy HTML a little). Have there been any more improvements in CVS? If so I'll update and check them out! Kudos to the dillo project for a great tool! Regards, Jeremy Henty

April 23, 2004