November 2007 - Dillo-dev - lists.mailman3.com

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

Nov. 14, 2007

Hi, [gzip decoder] On Mon, Nov 12, 2007 at 02:52:43PM +0000, place wrote: > Hmm, how unfortunate. It had been working just fine for me, though I took it > out yesterday so that I could have a clean tree... I wonder whether > we're constantly going to see timing problems or something, where the > people with fast machines write things that work on fast machines and > the person with a slow machine will write things that work on a slow machine. Good news! Committed. I found a workaround for the segfault and decided to commit to allow further investigation and polishing from in-CVS code. It doesn't look like a race condition, but a problem of handling redirections and the null_decoder in cache.c (redirections is a somewhat ad-hoc code, not well designed yet). Attached goes a page to reproduce the segfault (without the patch in CVS). For instance: 1- save the attached page in /tmp 2- dillo-fltk /tmp 3- click on the page 4- go back 5- go forward (segfault) // you may need to repeat this 4 and 5 BTW, the workaround is mainly: - dStr_append_l(entry->Data, buf, (int)buf_size); + /* Assert we have a Decoder. + * BUG: this is a workaround, more study and a proper design + * for handling redirects is required */ + if (entry->Decoder != NULL) { + decodedBuf = a_Decode_process(entry->Decoder, buf, buf_size); + dStr_append_l(entry->Data, decodedBuf->str, decodedBuf->len); + dStr_free(decodedBuf, 1); + } else { + dStr_append_l(entry->Data, buf, buf_size); + } With regard to: // Doesn't work. I could make TotalSize into something like BytesRemaining, // seeing whether it goes precisely to 0. I'd prefer TransferSize (this is the whole http transfer size minus the Header length --i.e. Content-Length). With regard to the iconv decoder: Please note that we may still need the original data, to be able to save verbatim. This is, if the original page is encoded in latin2 (with a <meta http-equiv charset line in the source), and it is saved translated to UTF-8 we have two problems (the misleading "meta" and that the user will get a page that's not a verbatim copy of the original). One way to solve this is to re-encode into the original charset at save time. This is not 8bit clean but could work most of the time. Another way is to keep a copy of the verbatim data. In this case we're 8bit clean and it would only take more memory when the original is not UTF-8. I *feel* 8bit clean is the correct path, and here there're lots of ways to optimize. For instance, with UTF-8 pages we don't need an extra buffer. For pages that need one, we can deallocate the UTF-8 encoded one when leaving the page (and re-create it if the page is visited again). This is just some food for thought. -- Cheers Jorge.-

3 5

Re: patch: TransferSize
by jcid＠dillo.org Nov. 14, 2007

Nov. 14, 2007

On Tue, Nov 13, 2007 at 09:07:48PM +0000, place wrote: > > I'd prefer TransferSize (this is the whole http transfer size minus the > > Header length --i.e. Content-Length). > Committed with some minor changes: s/TotalSize/ExpectedSize/g e.g.: + int ExpectedSize; /* Goal size of the HTTP transfer (0 if unknown)*/ + int TransferSize; /* Actual length of the HTTP transfer */ I also decided to remove this line: entry->Flags |= CA_GotData; entry->Flags &= ~CA_Stopped; /* it may catch up! */ - entry->TotalSize = entry->Data->len; if (entry->Decoder) { a_Decode_free(entry->Decoder); ... and now the transfer-size mismatch messages, shed more light on the redirection bug! For instance if you take the same "mm1.html" test case, going back and forward, it's clear that the image is being reloaded, but the HTTP header is not re-parsed. This is a problem with the cache_null_client. I haven't investigated it further, but this hint should be enough. -- Cheers Jorge.-

1 0

forms related segfault
by Johannes.Hofmann＠gmx.de Nov. 13, 2007

Nov. 13, 2007

Hello, when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault: Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) at Input.cxx:1469 #5 0x080ac66b in fltk::Input::handle (this=0x28661280, event=8) at Input.cxx:1384 #6 0x080dfac2 in fltk::Widget::send (this=0x28661280, event=8) at Widget.cxx:805 #7 0x080be6dd in fltk::handle (event=8, window=0x28540000) at run.cxx:1287 #8 0x080c4bf4 in fltk::handle () at run.cxx:1947 #9 0x080c4c38 in do_queued_events () at run.cxx:396 #10 0x080c4f52 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #11 0x080c4fed in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #12 0x080c5104 in fltk::run () at run.cxx:393 #13 0x0804e714 in main (argc=Error accessing memory address 0x0: Bad address. ) at dillo.cc:107 I think it has to do with the input form of the previous page somehow still being activ. Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded? Are the deleted, and if so where in the code does this happen? Cheers, Johannes

3 12

Re: is the visited_color pref somehow deprecated?
by jcid＠dillo.org Nov. 13, 2007

Nov. 13, 2007

On Sun, Nov 11, 2007 at 05:04:59PM +0000, place wrote: > dillorc2 doesn't list it, but if you have force_my_colors set and you > don't know to add visited_color to the rc, you get stuck with purple, > which is not optimal on a black background... No it's not deprecated. I tried to add the working options in dillorc2 only. Patch is welcomed! :-) -- Cheers Jorge.-

2 2

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

Nov. 12, 2007

On Sun, Nov 11, 2007 at 01:05:30AM +0000, place wrote: > > > 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. > > Has the new html.cc made my problem go away? So far as I can tell, > things will be the same: a_UIcmd_page_popup() will need a DilloHtml*, > so uicmd.hh will include html.hh. When IO/http.c includes uicmd.hh, > it will see #include "dw/core.hh" and #include "lout/misc.hh" in html.hh, > and it will not compile. You can use a void* inside the bw structure (as with render_layout). It may end being a list in the future. For instance, if we ever implement frames, this list could contain the DilloHtml objects for each component URL, of a framed page. The design is not clear yet, but this is one way to implement it. -- Cheers Jorge.-

2 2

Re: patch: save filename/dir
by jcid＠dillo.org Nov. 11, 2007

Nov. 11, 2007

On Sat, Nov 10, 2007 at 11:09:26PM +0000, place wrote: > When I went to save a file, the suggested filename still had the > anchor suffix. Saw from my old tree that URL_PATH() was what I wanted. > Changed that. > > Since I was right there already and there was a comment about a > save dir pref, I added one to prefs.*. > Committed! -- Cheers Jorge.-

1 0

[patch] fix bug in new scrolling code
by Johannes.Hofmann＠gmx.de Nov. 10, 2007

Nov. 10, 2007

Hi, when scrolling using the down arrow key I saw occasionally screen corruptions. The patch below fixes this for me. BTW. the following little program helped me debugging this and might be useful for others with too fast machines. It hogs the CPU, so dillo redraws are much slower and easier to follow: int main(int argc, char **argv) { for (;;); } Cheers, Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -311,8 +311,11 @@ void FltkViewport::scroll (int dx, int d { int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; - int oldScrollX = scrollX; - int oldScrollY = scrollY; + /* multiple calls to scroll can happen before a redraw occurs. + * scrollDX / scrollDY can therefore be non-zero here. + */ + int oldScrollX = scrollX - scrollDX; + int oldScrollY = scrollY - scrollDY; if (dx == 0 && dy == 0) { return;

2 1

[patch] enable partial image drawing
by Johannes.Hofmann＠gmx.de Nov. 9, 2007

Nov. 9, 2007

Hi, here is a first patch to reduce redrawing in dillo-fltk. It just enables code that already existed but was commented out and allows drawing of parts of an image only. I added some additional checks. With these checks I did not see any negative effects. Cheers, Johannes diff --git a/dw/fltkimgbuf.cc b/dw/fltkimgbuf.cc --- a/dw/fltkimgbuf.cc +++ b/dw/fltkimgbuf.cc @@ -334,7 +334,19 @@ void FltkImgbuf::draw (::fltk::Widget *t // xRoot, x, yRoot, y, width, height, this->width, this->height); //{ -#if 0 +#if 1 + if (x > this->width || y > this->height) { + return; + } + + if (x + width > this->width) { + width = this->width - x; + } + + if (y + height > this->height) { + height = this->height - y; + } + // almost OK for rows. For some unknown reason it trims the bottom and // rightmost parts when scrolling. ::fltk::Rectangle rect (xRoot + x, yRoot + y, width, height);

2 1

Re: new browser windows slower than first one
by jcid＠dillo.org Nov. 9, 2007

Nov. 9, 2007

Hi, On Fri, Nov 09, 2007 at 08:59:22PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Nov 07, 2007 at 06:56:22PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Wed, Nov 07, 2007 at 09:46:25PM +0100, Johannes Hofmann wrote: > > *snip* > > > > > > The last point is more difficult to improve. For example think of a > > > long page containing just text. Every time a new chunk comes in over > > > the net, dillo creates a redraw request for the whole screen, > > > even though there is already enough text to fill the screen so > > > that the new data does not actually change the layout of the part > > > that is currently visible. > > > > > > But how can we know, whether new data changes the layout of the > > > currently visible part or not? > > > > Please excuse me if I'm naive on this subject (it's not my main > > area of expertise). > > > > I think that if the visible widgets don't change their size, > > and the just-added widgets are out of sight, we can delay the > > redraw (maybe setting a damage flag or whatever it is that works > > on the out-of-sight widgets), and not request a full redraw. > > I think we would not even need to mark them. They get redrawn > anyway when they come back in sight. Great. > I see one problem however. > Many pages just consist of one large textblock. And part of this > textblock is obviously visible while loading the page. > But with every chunk of data from the net the size of this textblock > will change and we would redraw it, even though the part of it that > is visible did not change. > I think we need a solution for this common case. Yes, it's true. > I already thought > about checking whether something changed at a word by word level, > but this feels a bit like overkill. But it could work. Let's say we keep the convas coordinate of the last line in a textblock in a state variable of the object instance. If that line is out of sight we can leave: mustQueueResize = false and be more careful about calling Textblock::flush(). > > If that approach is too complex to implement, then maybe it's > > not worth the effort. > > > > What do you think? > > Maybe. The actual redraws are done when fltk is idle otherwise. > So many redraw request are collapsed into one already. > > However redraws are much more expensive with antialiased text than > they were in dillo1, so we should at least try to reduce them. I agree, and it looks like the right thing to do. > > > The only rather simple improvement I can think of is that we could > > > use the image sizes provided in the <img/> tags and only issue a > > > Layout::queueResize() if the image proves to be of a different size. > > > Currently there is a Layout::queueResize() for every image as it > > > gets loaded. > > > > A simple way to throttle redraws is to make it in the html > > parser, and parse at let's say at 3 seconds intervals and at EOF. > > I've done that before on prototypes. > > Yes, but I actually like dillos behaviour to show incoming content > immediately in contrast to firefox and friends. Me too. ;) -- Cheers Jorge.-

1 0

some more bugs
by matthias.franz＠ujf-grenoble.fr Nov. 8, 2007

Nov. 8, 2007

Hi everybody, here are some more bugs I've discovered. (I'm sorry that testing usually leads to postings about problems ... Thanks to all who have volunteered to fix them so far!) - The tag <hr> does not produce a horizontal line, but only a small dot. - Pressing "@" anytime quits Dillo immediately. (I guess that was made on purpose during development.) - The bookmark page looks very funny. The columns for the sections and the bookmarks are much to narrow and together use only about one third of the window width. - A problem which is already present in the fltk2 program test/input: Pressing a dead key and then a letter (e.g., "^" and "o") works fine. Pressing a dead key followed by space only sometimes gives the accent (as it should) and sometimes just a space. What you get seems to be random; it changes even while the program is running. I understand that fltk2 processes dead keys on its own. For us, it would probably be easier if the keyboard was used in a "cooked" mode based on the X keyboard settings. Cheers, -- Matthias Franz

3 5

PATCH: adds the ' entity
by onepoint＠starurchin.org Nov. 7, 2007

Nov. 7, 2007

Is it dillo's policy to include *only* HTML 4.01 entities. If not, here's a patch to add the ' entity, which appears all over the place despite not being official HTML 4.01. Regards, Jeremy Henty Only in dillo2: CVS Only in dillo2-cur: Makefile Only in dillo2-cur: Makefile.in Only in dillo2-cur: aclocal.m4 Only in dillo2-cur: autom4te.cache Only in dillo2-cur: config.guess Only in dillo2-cur: config.h Only in dillo2-cur: config.log Only in dillo2-cur: config.status Only in dillo2-cur: config.sub Only in dillo2-cur: configure Only in dillo2-cur: d_size.h Only in dillo2-cur: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2/dlib: CVS Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/dlib: dlib.o Only in dillo2-cur/dlib: libDlib.a Only in dillo2/doc: CVS Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2/dpi: CVS Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpi: bookmarks.dpi Only in dillo2-cur/dpi: bookmarks.o Only in dillo2-cur/dpi: cookies.dpi Only in dillo2-cur/dpi: cookies.o Only in dillo2-cur/dpi: datauri.filter.dpi Only in dillo2-cur/dpi: datauri.o Only in dillo2-cur/dpi: downloads.dpi Only in dillo2-cur/dpi: downloads.o Only in dillo2-cur/dpi: dpiutil.o Only in dillo2-cur/dpi: file.dpi Only in dillo2-cur/dpi: file.o Only in dillo2-cur/dpi: ftp.filter.dpi Only in dillo2-cur/dpi: ftp.o Only in dillo2-cur/dpi: hello.filter.dpi Only in dillo2-cur/dpi: hello.o Only in dillo2-cur/dpi: https.filter.dpi Only in dillo2-cur/dpi: https.o Only in dillo2-cur/dpid: .deps Only in dillo2/dpid: CVS Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpid: dpi.o Only in dillo2-cur/dpid: dpi_service.o Only in dillo2-cur/dpid: dpi_socket_dir.o Only in dillo2-cur/dpid: dpid Only in dillo2-cur/dpid: dpid.o Only in dillo2-cur/dpid: dpid_common.o Only in dillo2-cur/dpid: main.o Only in dillo2-cur/dpid: misc_new.o Only in dillo2-cur/dpip: .deps Only in dillo2/dpip: CVS Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/dpip: dpip.o Only in dillo2-cur/dpip: libDpip.a Only in dillo2-cur: install-sh Only in dillo2-cur: missing Only in dillo2-cur/src: .deps Only in dillo2/src: CVS Only in dillo2-cur/src/IO: .deps Only in dillo2/src/IO: CVS Only in dillo2-cur/src/IO: IO.o Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src/IO: about.o Only in dillo2-cur/src/IO: dpi.o Only in dillo2-cur/src/IO: http.o Only in dillo2-cur/src/IO: iowatch.o Only in dillo2-cur/src/IO: libDiof.a Only in dillo2-cur/src/IO: mime.o Only in dillo2-cur/src/IO: proto.o Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-cur/src: bitvec.o Only in dillo2-cur/src: bookmark.o Only in dillo2-cur/src: bw.o Only in dillo2-cur/src: cache.o Only in dillo2-cur/src: capi.o Only in dillo2-cur/src: chain.o Only in dillo2-cur/src: colors.o Only in dillo2-cur/src: cookies.o Only in dillo2-cur/src: dialog.o Only in dillo2-cur/src: dicache.o Only in dillo2-cur/src: dillo-fltk Only in dillo2-cur/src: dillo.o Only in dillo2-cur/src: dir.o Only in dillo2-cur/src: dns.o Only in dillo2-cur/src: dpiapi.o Only in dillo2-cur/src: form.o Only in dillo2-cur/src: gif.o Only in dillo2-cur/src: history.o diff -pru -- dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2007-11-03 22:16:26.000000000 +0000 +++ dillo2-cur/src/html.cc 2007-11-04 08:44:02.000000000 +0000 @@ -814,7 +814,7 @@ typedef struct { int isocode; } Ent_t; -#define NumEnt 252 +#define NumEnt 253 static const Ent_t Entities[NumEnt] = { {"AElig",0306}, {"Aacute",0301}, {"Acirc",0302}, {"Agrave",0300}, {"Alpha",01621},{"Aring",0305}, {"Atilde",0303}, {"Auml",0304}, @@ -833,7 +833,9 @@ static const Ent_t Entities[NumEnt] = { {"Yacute",0335},{"Yuml",0570}, {"Zeta",01626}, {"aacute",0341}, {"acirc",0342}, {"acute",0264}, {"aelig",0346}, {"agrave",0340}, {"alefsym",020465},{"alpha",01661},{"amp",38}, {"and",021047}, - {"ang",021040}, {"aring",0345}, {"asymp",021110},{"atilde",0343}, + {"ang",021040}, + {"apos",39}, /* not in HTML 4.01 */ + {"aring",0345}, {"asymp",021110},{"atilde",0343}, {"auml",0344}, {"bdquo",020036},{"beta",01662}, {"brvbar",0246}, {"bull",020042},{"cap",021051}, {"ccedil",0347}, {"cedil",0270}, {"cent",0242}, {"chi",01707}, {"circ",01306}, {"clubs",023143}, Only in dillo2-cur/src: html.o Only in dillo2-cur/src: image.o Only in dillo2-cur/src: jpeg.o Only in dillo2-cur/src: klist.o Only in dillo2-cur/src: menu.o Only in dillo2-cur/src: misc.o Only in dillo2-cur/src: nav.o Only in dillo2-cur/src: plain.o Only in dillo2-cur/src: png.o Only in dillo2-cur/src: prefs.o Only in dillo2-cur/src: timeout.o Only in dillo2-cur/src: ui.o Only in dillo2-cur/src: uicmd.o Only in dillo2-cur/src: url.o Only in dillo2-cur/src: web.o Only in dillo2-cur: stamp-h1

2 3

new browser windows slower than first one
by Johannes.Hofmann＠gmx.de Nov. 7, 2007

Nov. 7, 2007

Hello, just noticed a scroll performance-related problem: When I create many browser windows (e.g. using the middle mouse button), srolling in these created windows causes more Xorg CPU usage than in the first one. Maybe, scrolling in the new windows causes redraws from the old ones? Johannes

5 13

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