- Dillo-dev - lists.mailman3.com

another tooltip bug

by corvid＠lavabit.com

With the attached page, I put the cursor on the first image and let the tooltip appear (and don't have the cursor too far over to the left of the window or screen). Then I move the cursor down into the second image and let go of the mouse. For a second, the tooltip for the second image shows up in the proper position, but then it moves to the right so that not all of it is visible.

March 2, 2012

DNS code changes

by mailbox＠georgpotthast.de

Could you please leave the configure option " --disable-threaded-dns" in the code since I use that for my DOS version? I cannot use dpi. Georg

Feb. 25, 2012

make fail on OS X 10.6.8

by phildobbin＠gmail.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all. I'm trying to install Dillo v.3.0.2 from source on OS X 10.6.8 & after successfuly installing fltk-1.3.0 into /usr/local & running configure & make I get this error: `ld: duplicate symbol Fl_Printer::class_id in /usr/local/lib/libfltk.a(Fl_Printer.o) and ../dw/libDw-fltk.a(libDw_fltk_a-fltkplatform.o) collect2: ld returned 1 exit status make[3]: *** [dillo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2` I've tried Googling it (this is where I got the email address for this list. Apologies if I should've sent it to dillo-users. If that's the case, please let me know & I'll make amends) but no luck. Any help appreciated. Cheers, Phil... - -- But masters, remember that I am an ass. Though it be not written down, yet forget not that I am an ass. Wm. Shakespeare - Much Ado About Nothing -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: ??auto-key-locate cert pka ldap hkp://keys.gnupg.net Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPSHARAAoJEKpMeDHWT5AD/hMIAInZu2mC96q3ZmYniyrnFJ+p hyNs8ELSsDOxzzeIps5XjiRzAto92l37ey+u0m3Ykt7rtv/vLaVj4zo+Bq0zaVDp 3znKMhIriaYzw4d7lRaTfLjxMETniZrh575/yXNpkQoCaBS7qSFWbYcRq/OCtuxE zbkHA+C7W9XPX3nyDZ6DWpCAXWDH68U/NECEksSqeNYmGUOHojhzun7/HOFkXXsT 1O2vFZY3PmNV4KdHQnedqnF4iEOBamNZS1sCU2DtSZUd3FUrhR9Pb3ImGovmtCFx vSGdZOL7/UYDtULCEHxxFB+8FoZgSm2UU42/+ac0PGKNcTOOjoBikjEBokf3Fvs= =YBHD -----END PGP SIGNATURE-----

Feb. 25, 2012

[exprimental patch] wakeup instead of polling for dns

by johannes.hofmann＠gmx.de

On Sun, Feb 19, 2012 at 01:53:13PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > Please excuse the delayed answer. > > On Tue, Feb 14, 2012 at 09:44:24PM +0100, Johannes Hofmann wrote: > > On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached experimental patch replaces the polling for DNS answers > > > > > with the wakeup mechanism fltk provides. > > > > > What do you think? > > > > > > > > Well dns resolving is delicate, but not sacred ;) > > > > > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > > > average when displaying non dns-cached pages, (0.2 best case). > > > > Which is significative. > > > > > > > > Please let me know if there's another advantage I miss. > > > > > > Well, I don't like the polling :-) > > > There might be an increased power consumption related to the > > > 5 times/s timer, but I'm not sure whether it really matters. > > > > > > > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > > > the rest of the code. > > > > > > Yes, plus we need to switch on locking for all fltk just for the dns > > > thing. That's the major drawback I think. > > > > > > > > > > > It looks clean. It should be tested on different platforms/OS. > > > > > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > > > this awake() call work OK when called from the same main thread? > > > > Is this by design or by chance? Maybe it would be safer to avoid > > > > calling awake() in this case. > > > > > > I didn't test it yet. I still want to try other approaches that > > > would avoid switching on the fltk threading stuff with the > > > Fl::lock() call. > > > > Ok, attached is another approach that avoids the Fl::lock() and > > instead uses a Fl::add_fd() which is already used in src/IO. > > Let me know what you think. > > I just re-read the patch, this time from HG, and it looks clean. > The pipe trick is very well tested within dpi so it should work > as well as it looks. Ok good. I just committed it as it no longer has the drawbacks of the initial patch I sent. Cheers, Johannes

Feb. 20, 2012

[exprimental patch] wakeup instead of polling for dns

by jcid＠dillo.org

Hi Johannes, Please excuse the delayed answer. On Tue, Feb 14, 2012 at 09:44:24PM +0100, Johannes Hofmann wrote: > On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > attached experimental patch replaces the polling for DNS answers > > > > with the wakeup mechanism fltk provides. > > > > What do you think? > > > > > > Well dns resolving is delicate, but not sacred ;) > > > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > > average when displaying non dns-cached pages, (0.2 best case). > > > Which is significative. > > > > > > Please let me know if there's another advantage I miss. > > > > Well, I don't like the polling :-) > > There might be an increased power consumption related to the > > 5 times/s timer, but I'm not sure whether it really matters. > > > > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > > the rest of the code. > > > > Yes, plus we need to switch on locking for all fltk just for the dns > > thing. That's the major drawback I think. > > > > > > > > It looks clean. It should be tested on different platforms/OS. > > > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > > this awake() call work OK when called from the same main thread? > > > Is this by design or by chance? Maybe it would be safer to avoid > > > calling awake() in this case. > > > > I didn't test it yet. I still want to try other approaches that > > would avoid switching on the fltk threading stuff with the > > Fl::lock() call. > > Ok, attached is another approach that avoids the Fl::lock() and > instead uses a Fl::add_fd() which is already used in src/IO. > Let me know what you think. I just re-read the patch, this time from HG, and it looks clean. The pipe trick is very well tested within dpi so it should work as well as it looks. -- Cheers Jorge.-

Feb. 19, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > attached experimental patch replaces the polling for DNS answers > > > with the wakeup mechanism fltk provides. > > > What do you think? > > > > Well dns resolving is delicate, but not sacred ;) > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > average when displaying non dns-cached pages, (0.2 best case). > > Which is significative. > > > > Please let me know if there's another advantage I miss. > > Well, I don't like the polling :-) > There might be an increased power consumption related to the > 5 times/s timer, but I'm not sure whether it really matters. > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > the rest of the code. > > Yes, plus we need to switch on locking for all fltk just for the dns > thing. That's the major drawback I think. > > > > > It looks clean. It should be tested on different platforms/OS. > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > this awake() call work OK when called from the same main thread? > > Is this by design or by chance? Maybe it would be safer to avoid > > calling awake() in this case. > > I didn't test it yet. I still want to try other approaches that > would avoid switching on the fltk threading stuff with the > Fl::lock() call. ... and here comes the patch.

Feb. 14, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > attached experimental patch replaces the polling for DNS answers > > > with the wakeup mechanism fltk provides. > > > What do you think? > > > > Well dns resolving is delicate, but not sacred ;) > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > average when displaying non dns-cached pages, (0.2 best case). > > Which is significative. > > > > Please let me know if there's another advantage I miss. > > Well, I don't like the polling :-) > There might be an increased power consumption related to the > 5 times/s timer, but I'm not sure whether it really matters. > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > the rest of the code. > > Yes, plus we need to switch on locking for all fltk just for the dns > thing. That's the major drawback I think. > > > > > It looks clean. It should be tested on different platforms/OS. > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > this awake() call work OK when called from the same main thread? > > Is this by design or by chance? Maybe it would be safer to avoid > > calling awake() in this case. > > I didn't test it yet. I still want to try other approaches that > would avoid switching on the fltk threading stuff with the > Fl::lock() call. Ok, attached is another approach that avoids the Fl::lock() and instead uses a Fl::add_fd() which is already used in src/IO. Let me know what you think. Cheers, Johannes

Feb. 14, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > Hi, > > > > attached experimental patch replaces the polling for DNS answers > > with the wakeup mechanism fltk provides. > > What do you think? > > Well dns resolving is delicate, but not sacred ;) > > AFAIS the main advantage would be a near 0.1 second speedup on > average when displaying non dns-cached pages, (0.2 best case). > Which is significative. > > Please let me know if there's another advantage I miss. Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters. > > The cost is using an FLTK mechanism (awake) which we don't in > the rest of the code. Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think. > > It looks clean. It should be tested on different platforms/OS. > > BTW, dns.c has code for a blocking server (not threaded). Does > this awake() call work OK when called from the same main thread? > Is this by design or by chance? Maybe it would be safer to avoid > calling awake() in this case. I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call. Cheers, Johannes

Feb. 12, 2012

[exprimental patch] wakeup instead of polling for dns

by jcid＠dillo.org

Hi Johannes, On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > Hi, > > attached experimental patch replaces the polling for DNS answers > with the wakeup mechanism fltk provides. > What do you think? Well dns resolving is delicate, but not sacred ;) AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative. Please let me know if there's another advantage I miss. The cost is using an FLTK mechanism (awake) which we don't in the rest of the code. It looks clean. It should be tested on different platforms/OS. BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case. -- Cheers Jorge.-

Feb. 10, 2012

Other protocol handler dpi for mailto etc

by dennisn＠dennisn.dyndns.org

What ever happened to the (idea of a) general protocol handler for mailto: and irc: and other such links? It was mentioned once upon a time, at least, in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002404.html

Feb. 7, 2012