- Dillo-dev - lists.mailman3.com

Re: Accept-Encoding: gzip
by jcid＠dillo.org Nov. 7, 2007

Nov. 7, 2007

Hi, On Mon, Nov 05, 2007 at 10:46:09PM +0000, place wrote: > What would you think of something like the code I have attached? I'd like to have gzip decoding in dillo2. > I had looked at the gzip portion of the i18n patch, just intending to put it > in my own copy, but it was unsatisfactory in some ways, so I ended up > changing the whole thing and this was the result. It looks quite advanced and that giving it a second pass on simplicity/elegance it'd be ready. > > Bad: 1. I stuck an awful lot of things into CacheEntry_t. Yes. IMO, having only: Dstr *EncodedData; char *Encoding; added to CacheEntry_t is cleaner. (we can add a Dstr_get_size() if necessary). > 2. During the downloading/decoding process, there is Data and > DecodedData. It gets fixed up afterward, but it means that things like > trying to view source during downloading does not work. I imagine the > fix being something like changing Data to RawData, DecodedData to Data, > freeing RawData after download is complete, and looking at all of the > current references to Data to figure out which of those they should > use. But I'll leave that for after I find out what you think of what I > have so far. From a design point of view, I'd prefer the decoding functions in a separate source file, that way, new decoders may be added easily and decoding complexity gets out of the cache part (the decoding internal state moves from the Cache entry to the decoding module, and decoding functions can be reused or extended). If we think of decoding as one part in a pipeline, null-decoding is what we have now, and gzip-decoding what we'd make for gzip. That way we can keep only one path for the data stream, and null-decode or gzip-decode into 'Data' when we need it. This solves the problem of using 'Data' while decoding naturally, because it is perceived as it always was (new-bytes from a stream), the only difference being they now come pushed from a decoder instead of the net (quite transparent). > Good: 1. Faster! > > 2. Faster! Yes. I can't wait to try it under a telephone line modem next week. :-) BTW, do you plan to make the linkblock/callback patch for html.cc (analog to plain.cc) or do you prefer me to work on it? -- Cheers Jorge.-

1 0

New CVS repository and patches
by bogus＠does.not.exist.com Nov. 6, 2007

Nov. 6, 2007

Hi There! Once again, thanks for the patches and keep them flowing. The new CVS repository is up and updated with the patches: e.g. (with "-cur" terminated directories being the working directories) alias dcvs='cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo' dcvs co dillo2 dcvs co dw2 cp -r dillo2 dillo2-cur cp -r dw2 dw2-cur ln -s dw2-cur dw-testbed find dw2-cur -name CVS -exec rm \{\} \; find dillo2-cur -name CVS -exec rm \{\} \; cd dw2-cur ./autogen.sh make cd ../dillo2-cur ./autogen.sh make Here follow my comments on the patches. Please test this CVS code and send feedback: > [Johannes wrote] > * the namespace "signal" in dw-testbed/lout/signal.hh conflicts with > the declaration in /usr/include/sys/signal.h: > __sighandler_t *signal (int, __sighandler_t *); > I renamed the namespace to loutsignal. Johannes: please send me the patch for this. > [Vincent wrote (va_list issue)] > Sure, though i'm not at all sure this is the correct way to fix this > issue. Vincent: AFAIS, the problem is looping without the va_copy, so the patch is OK. Anyway, please test the CVS code and tell us how it works. > [Andreas wrote] > Ok, then I got it to compile finally for my ipaq with familar 0.8.4 on it. > I runs with X-forwarding so that I get the window on my notebook display. > But it segfaults without x forwarding: Andreas: please let us know the procedure when you have cleaned it up. > [Alexander wrote (strndup)] > Hm, right. I had used malloc() in my replacement function, but with > calloc() it is indeed unnecessary. > > I have wrapped this in autoconf, see attached patch. I also made > autoconf in dillo and dw-testbed check for the path to the perl binary > and substitute it in dpidc and Doxyfile, respectively, see other patch. > Actually, these patches can't simply be applied: first, > dillo-f15/dpid/dpidc and dw-testbed-0.0.43j/Doxyfile have to be moved > to *.in. Alexander: as strndup is a GNU extension, and we have kept the code as portable as possible, I just added the wrapper for it based on the patch. With regard to Perl, I'd like to get rid of that dependence either with bash (if possible) or C. BTW, if Sebastian agrees it may also be a good idea to use Dlib in dw2. That way those problems could be layered down... > [Johannes wrote] > here is a new version of dillo-fltk scroll performance > improvements. This patch is against vanilla dillo-fltk. > > New in this patch: > > * Hotkey bindings for arrow keys, Home- and EndKey. > This only works when the focus is on the > display area. > > * Only unclipped area is exposed which improves performance on > large pages (e.g. http://www.w3.org/TR/xslt) > > * Limit scrolling to reasonable values. It improves not only performance on large pages but also avoids overlapped rendering. Applied. > [Matthias wrote] > Fine! Only using the arrow keys is quite slow and consumes all CPU time > on my machine. In contrast, srolling with the old Dillo was quick and > produced almost no CPU load. > > A question: Would it be difficult to add mouse wheel support as well? > On my machine that does not work. (Or is thia a configuration issue > regarding FLTK?) Dillo1 didn't render antialiased text, and was heavily optimized. The optimization phase of rendering in dillo2 has just started (thanks Johannes :). I hope we can tune it to a dillo1 similar CPU-consumtion. > [Matthias wrote] > Compilation on Debian Etch worked well. I had to use the "--x-includes" > and "--x-libraries" options when configuring FLTK, and the test glpuzzle > did not compile. I'm also using Etch here and didn't need those options. I also have a running glpuzzle. The CPU, hogs when scrolling on vanilla but not with the scrolling patch, and entities work. I also don't experience CPU-hogs from the over-link-quick-switch-from arrow-to-hand test. Maybe this is related to something not installed or not configured in your machine... (This system has: x11proto-gl-dev, freeglut3, freeglut3-dev, libxft2, libxft2-dev, libgl1-mesa-{dev,dri,glx} among others that I don't know whether relevant or not! ;). BTW, I'm testing on a fast machine. It will be interesting to see what the old one produces. > [Johannes wrote] > Mouse wheel is a matter of binding. Place your mouse pointer over the > scroll bar and use the mouse wheel (it needs to be bound to the viewport). > > It is slow, because the default linesize (the amount a scrollbar > scrolls when pushing on the arrow is 1. I could change that, but > what would be a reasonable value? The height of a word in normal text (i.e. line height). We know the font and font factor from dillorc2 (or defaults). This number is a good candidate. ---------------- Side Note to all: Have you right-clicked over the search button? :-) -- Cheers Jorge.-

5 10

Crashes on OpenBSD
by Christian.Kellermann＠nefkom.net Nov. 5, 2007

Nov. 5, 2007

Skipped content of type multipart/mixed

3 8

dillo hogs during text selection
by matthias.franz＠ujf-grenoble.fr Nov. 5, 2007

Nov. 5, 2007

Hi, I have observed that dillo2 may hog during text selection. For example, take the page http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . Go to some place in the table of contents, press the left mouse button and move the cursor around quickly so that the selected text changes all the time. After less a second, dillo becomes unresponsive and consumes all CPU time. This page also shows two additional issues: - There is no spacing between list items when the second item has less indentation than the first. (Look at the lines "mat - matrices" and "Types for affine ...".) - When the window size is increased, the vertical scroll bar suddenly disappears at a certain width and reappears below that width. (On my screen, this happens between 835 to 836 pixels.) In fact, the scroll bar is still there in the sense that line breaking leaves enough space for the bar. (I have reported this issue already before.) Cheers, -- Matthias Franz

1 0

Quick question about font_factor in dillorc2
by onepoint＠starurchin.org Nov. 5, 2007

Nov. 5, 2007

Just out of interest, is there any reason why the default dillorc2 sets font_factor to 1.5? It seems unreasonably large to me, and I personally much prefer to comment it out. Anyone else have feelings one way or the other? Regards, Jeremy Henty

2 3

Re: patch: hiding widgets
by jcid＠dillo.org Nov. 5, 2007

Nov. 5, 2007

On Sun, Nov 04, 2007 at 01:03:51AM +0000, place wrote: > I made this customize() pretty much a copy of the 0.8.x customize(). Commited. > In testing, I saw that playing with the panel_cb a lot makes things crashy > (that is, equally crashy with and without this code). Is that general area > of the UI permanent enough for there to be any point in taking notice of it? The idea was to test on-the-fly resizing. Hoping for FLTK2-savvy guys to come later with some advice on how its done. -- Cheers Jorge.-

1 0

Re: image loading from menus
by jcid＠dillo.org Nov. 4, 2007

Nov. 4, 2007

Hi, On Fri, Nov 02, 2007 at 02:32:49PM +0000, place wrote: > > > Now I have to send a linkblock ptr around. > > > > Where, what are you working on? > > Please give me more background. > > The right-click menus. I am giving them the linkblock ptr via > a_UIcmd_*_popup so that they can call Html_load_images > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > if that's the right way to route it.) After some study and a reimplentation of plain.cc with classes (getting rid of its linkblock and hooking a callback for memory handling), it looks simpler and better. It looks like the same may be done with html.cc. Please check out the CVS. Comments are welcomed. Although the patch is already in CVS, I'm attaching the dw2 patch text so Sebastian can review it easily when he has time. -- Cheers Jorge.-

2 2

Another handy patch.
by jcid＠dillo.org Nov. 2, 2007

Nov. 2, 2007

Hi, + Enabled vertical mouse wheel scrolling. -- Cheers Jorge.-

1 0

Test: are my posting problems fixed
by onepoint＠starurchin.org Nov. 1, 2007

Nov. 1, 2007

Just checking whether Jorge has fixed whatever was stopping my messages getting through. Regards, Jeremy Henty

1 0

Re: yet another patch: forms. activateReceiver
by jcid＠dillo.org Oct. 29, 2007

Oct. 29, 2007

Hi, After a rescue operation (and re-trainning of my bogofilter), there were this emails/patches in the SPAM bin: place (5.6K) patch: just the not-hooked-up image menu place (6.8K) patch: image loading toggle button + preference place (4.2K) patch: plain page menu place (2.6K) yet another patch: forms. activateReceiver All of them were commited with only minor changes. > I assumed I was going to have to _understand_ forms or resources, and here > I find out that all I have to do is hook A to B. At least to make the forms > I use regularly work... I wonder whether you guys left the easy stuff for > whoever comes along just so that it would be easy for them to feel rewarded > for their efforts... :-) We were trying with Sebastian to check that FLTK2, was providing everything we needed to complete the port. Thus, if something worked, but needed lots of hooks thorough the code, only the first one was made (and the rest left for the future), so we could advance to the next case. In the case of forms, while I was porting the html parser the resources for forms were not yet developed, so I had to comment and skip some hooks to make it compile. Later I started joining some dots... > I didn't patch the rc to mention the preference, though. I did. > A slavish copy of linkblock, which, since there certainly weren't any links > involved, ended up named 'eventdata'... In general, do you plan to make the rest of the patches (e.g. hook the image menu, the image loading toggle), or want some help here? BTW, with regard to the linkblock (and my past comments on it), I can try to check how it looks without linkblock, and decide what to make of it afterwards while you work on the part II of the above patches. Just let me know. -- Cheers Jorge.-

1 0