- Dillo-dev - lists.mailman3.com

Re: dillo bug 916

by jcid＠dillo.org

On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > Scott wrote: > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > Scott had reported: > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > of letting the window manager do its job. > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > Apps should not try to do their own window management." > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > that a partially hidden Dillo window raises upon clicking it. > > > > I hesitate because Firefox and even terminals here behave that > > > > way. Please explain. > > > > > > Other windows don't for me. Dillo does if it's > > > a new window/new tab or if I'm clicking below the bottom > > > of the text when the page is very short. > > > I imagine your WM must be set to do it... > > > > Oh, now I see it (with TWM). > > Please commit. > > Yes, but we should mark it as a workaround for an FLTK issue and > report it to FLTK. Exactly! (even though I have more hope for their 1.3 branch). -- Cheers Jorge.-

Aug. 3, 2009

Re: dillo bug 916

by Johannes.Hofmann＠gmx.de

On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > Scott wrote: > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > Scott had reported: > > > > "Dillo sometimes raises its window when clicked, instead > > > > of letting the window manager do its job. > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > Apps should not try to do their own window management." > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > that a partially hidden Dillo window raises upon clicking it. > > > I hesitate because Firefox and even terminals here behave that > > > way. Please explain. > > > > Other windows don't for me. Dillo does if it's > > a new window/new tab or if I'm clicking below the bottom > > of the text when the page is very short. > > I imagine your WM must be set to do it... > > Oh, now I see it (with TWM). > Please commit. Yes, but we should mark it as a workaround for an FLTK issue and report it to FLTK.

Aug. 3, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > Scott wrote: > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > Scott had reported: > > > "Dillo sometimes raises its window when clicked, instead > > > of letting the window manager do its job. > > > Usually if I have a window partially hidden, I don't want it raised... > > > Apps should not try to do their own window management." > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > that a partially hidden Dillo window raises upon clicking it. > > I hesitate because Firefox and even terminals here behave that > > way. Please explain. > > Other windows don't for me. Dillo does if it's > a new window/new tab or if I'm clicking below the bottom > of the text when the page is very short. > I imagine your WM must be set to do it... Oh, now I see it (with TWM). Please commit. -- Cheers Jorge.-

Aug. 3, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > Scott wrote: > > > As far as I can tell, it works correctly with the patch applied. :) > > > > Scott had reported: > > "Dillo sometimes raises its window when clicked, instead > > of letting the window manager do its job. > > Usually if I have a window partially hidden, I don't want it raised... > > Apps should not try to do their own window management." > > Sorry, I don't get the idea of the bug. IIUC the problem is > that a partially hidden Dillo window raises upon clicking it. > I hesitate because Firefox and even terminals here behave that > way. Please explain. Other windows don't for me. Dillo does if it's a new window/new tab or if I'm clicking below the bottom of the text when the page is very short. I imagine your WM must be set to do it...

Aug. 2, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > Scott wrote: > > As far as I can tell, it works correctly with the patch applied. :) > > Scott had reported: > "Dillo sometimes raises its window when clicked, instead > of letting the window manager do its job. > Usually if I have a window partially hidden, I don't want it raised... > Apps should not try to do their own window management." Sorry, I don't get the idea of the bug. IIUC the problem is that a partially hidden Dillo window raises upon clicking it. I hesitate because Firefox and even terminals here behave that way. Please explain. -- Cheers Jorge.-

Aug. 2, 2009

limit number of concurrent connections

by jcid＠dillo.org

Hi, Here's a prototype patch that does the work. It's not yet optimized nor polished nor throughly tested, and it leaks Web structures, but it illustrates very well the idea, and finishing it shouldn't be hard. As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-) -- Cheers Jorge.-

Aug. 2, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Scott wrote: > As far as I can tell, it works correctly with the patch applied. :) Scott had reported: "Dillo sometimes raises its window when clicked, instead of letting the window manager do its job. Usually if I have a window partially hidden, I don't want it raised... Apps should not try to do their own window management." fltk's Window::handle() has: #if USE_X11 case PUSH: // Unused clicks should raise the window. Windows unfortunatly // raises the window on *all* clicks so we don't bother except on X. if (shown()) XMapRaised(xdisplay, i->xid); #endif Aforementioned patch attached.

Aug. 2, 2009

experimental patch: Re: dillo2 wrapping Chinese

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 01:04:26AM +0000, corvid wrote: > I made yet another version of this patch the other day, > and furaisanjin was kind enough to run on it a bit and > ensure it's doing what we want. > > With the previous version, compiling without optimization, > gprof showed 3-4% loss of speed on a page that's mostly > English text. > > - I removed the strdup/free from the common case. > - For nonideographic, it goes character by character instead of > checking every byte. This should help for, e.g., Russian, > but means some 'unnecessary' length-checking in the > mostly-ASCII case. > > And gprof suggested the slowdown might be 3% now, although > at this point, unless someone is paying you to perform a > lot of careful, drudgery-filled runs, it gets hard to pick the > signal out of the noise when examining the time spent in relevant > functions. I wouldn't go with complex code for 1% gain. > I tried adding in some code to bypass the ideographic call for > ASCII, but 1) it made the code a little messy 2) it looked like > it might be saving a few tenths of a percent 3) the compiler > might perform optimizations under certain circumstances making > my efforts unnecessary or counterproductive. > I could definitely be talked into this one, though. Please leave the messy part out. > I tried adding an addText() with a length argument and thought > it might help by saving me the trouble of writing NULL bytes into > the strings and saving the trouble of some strlen()ning in dw. > I couldn't see any difference in speed, although it did make > things cleaner and I would want to add it in eventually if this > all makes it into the repository. Considering it makes things cleaner I'm for it. > There will be a duplicated ideographic() test, for instance, if > a word starts with digits and ends with some Japanese characters. > 1) uncommon 2) complexity Not worth the trouble of. > This patch is really two patches because it also handles the > case where whitespace numeric character references are > inside a word, but I wanted to see the effects of both > and they are each an excuse for the overhead of the loop. > I'd split it into two pieces if committing it. OK. (i.e. please consider the above comments, split and commit). BTW: I'm working on the limit concurrent connections patch prototype. -- Cheers Jorge.-

Aug. 2, 2009

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

I made yet another version of this patch the other day, and furaisanjin was kind enough to run on it a bit and ensure it's doing what we want. With the previous version, compiling without optimization, gprof showed 3-4% loss of speed on a page that's mostly English text. - I removed the strdup/free from the common case. - For nonideographic, it goes character by character instead of checking every byte. This should help for, e.g., Russian, but means some 'unnecessary' length-checking in the mostly-ASCII case. And gprof suggested the slowdown might be 3% now, although at this point, unless someone is paying you to perform a lot of careful, drudgery-filled runs, it gets hard to pick the signal out of the noise when examining the time spent in relevant functions. I tried adding in some code to bypass the ideographic call for ASCII, but 1) it made the code a little messy 2) it looked like it might be saving a few tenths of a percent 3) the compiler might perform optimizations under certain circumstances making my efforts unnecessary or counterproductive. I could definitely be talked into this one, though. I tried adding an addText() with a length argument and thought it might help by saving me the trouble of writing NULL bytes into the strings and saving the trouble of some strlen()ning in dw. I couldn't see any difference in speed, although it did make things cleaner and I would want to add it in eventually if this all makes it into the repository. There will be a duplicated ideographic() test, for instance, if a word starts with digits and ends with some Japanese characters. 1) uncommon 2) complexity This patch is really two patches because it also handles the case where whitespace numeric character references are inside a word, but I wanted to see the effects of both and they are each an excuse for the overhead of the loop. I'd split it into two pieces if committing it.

Aug. 2, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote: > > Jorge wrote: > > > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > I don't see any mention of a limit on concurrent connections > > > > that was proposed earlier, and as far as I know it hasn't been > > > > implemented. In addition to the reasons given earlier, it is very > > > > frustrating to have to implement your own traffic-shaping just to > > > > avoid being blocked by a rate/connection-limiting firewall, or to > > > > avoid being blocklisted by a site you had hoped to visit. I'd > > > > hate to see dillo gain a reputation as a problematic UserAgent, > > > > and perhaps be blocked by some heavy-handed administrators. > > > > If I had magical make-Jorge-do-my-bidding powers, this would be on the > > top of my list. > > Interesting... > > I'll give it a look, try to come up with raw patch and > send it to you for polish. Would you? I can try. It would be nice if we could have Keep-Alive. (Conceivably pipelining someday, but there might be too many annoying failure modes to recover from.) > > > * Document CCC, dlib and dillo in doxygen format. > > > > The situation seems to me as follows: > > pre-doxygen: easy-to-read code, useless documentation > > post-doxygen: hard-to-read code, useless documentation > > Oh, sounds harsh! > > For me Dw docs have been a bless. Without them I would not be > able to rewrite the table-formating algorithms. The conceptual dw docs (doc/*.doc) have helped me understand some things at times (but not due to their doxygenicity), but the doxygen stuff in the source makes it harder for me to read comments. > Non-dw documents under doc/ are outdated and I have to agree > they are of little use. I'll try to write one about CCC that will > hopefully help you with the limit on concurrent connections. Yeah, I should dig through some of doc/*.txt and update some things in the areas I'm familiar with.

July 31, 2009