August 2009 - Dillo-dev - lists.mailman3.com

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