- Dillo-dev - lists.mailman3.com

Re: Cache_parse_header()
by jcid＠dillo.org Nov. 20, 2007

Nov. 20, 2007

On Mon, Nov 19, 2007 at 07:33:16PM +0000, place wrote: > for a while, I'd wondered how > > if (HdrLen < 12) { > /* Not enough info. */ > > } if (header[9] == '3' && header[10] == '0') { > > > is supposed to prevent anything -- this is just like with camp the other day -- > and now it occurs to me it's probably just missing the 'else'. Funny code, isn't it? 8-) Fixed. -- Cheers Jorge.-

1 0

patch: text search
by jcid＠dillo.org Nov. 19, 2007

Nov. 19, 2007

On Mon, Nov 19, 2007 at 07:08:38PM +0100, Johannes Hofmann wrote: > On Mon, Nov 19, 2007 at 03:01:08PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Nov 16, 2007 at 04:22:01AM +0000, place wrote: > > > I'm not much of a drawing/gui person, but it's hard not being > > > able to search pages, so I gave it a try (attached). > > > > > > - If you hit ^Q on this window or the page source or page > > > bugs windows, dillo will crash because it assumes it's > > > closing a bw. > > > > Already fixed. > > > > > - I didn't want a title bar, and I didn't want it to be able > > > to outlive its bw, but I didn't know what to do about it. > > > > > > - If searching scrolls the window, highlighting isn't undone > > > properly. (If you search for something like "a", the last > > > instance on each line will remain highlighted) > > > > Well, my idea was to make the Find-text widget similar to what > > Firefox has (a row above the status bar that appears on request). > > With Enter bound to "search next", Shift-Enter to "search prev" > > and a few buttons/widgets for the usual "case insensitive" > > option & friends. > > > > As it was taking too much time (and I didn't find a way to do > > it either with or without Johannes patch), I decided to commit > > the patch "as is", and not to delay anymore. > > > > The above-status-bar widget solves some problems, for instance: > > > > - the dialog window covering the highlighted word. > > - dependencies (as including uicmd.hh and bw.hh from dialog) > > > > It looks like the FltkViewport is not behaving as a native FLTK > > widget and that either some ad-hoc bindings are required, or to > > make it behave as native FLTK, at least for parent Group resizes. > > > > BTW, formerly "full screen" was bound to Ctrl-F (which is the > > shortcut for find text), now it's bound to Ctrl-Space. > > Why? Because I haven't found how to detect and handle the > > double-click event, cleanly from the UI. :-) > > > > Any help is appreciatted! :) > > have you tried something like > > if (event == PUSH && event_clicks() >= 1) { > fprintf(stderr, "===> double click\n"); > } > > in UI::handle() already? Yes, lots of combinations of PUSH/RELEASE tests, return values, event_is_click(), event_clicks(), event_clicks(0)... I got confused bacause to get a RELEASE event you need to return non zero from PUSH, and then you can capture double-click from RELEASE, but that way fast clicks over Back or Forward buttons are seen as double-click. With other combinations, sometimes the event is not passed to the child widgets, etc. So I tried to cpture from PUSH alone... Finally, I thought that if after: ret = Window::handle(event); ret was zero, it was safe to make the PUSH/RELEASE dance, but, to my surprise, ret was non zero from double-click event though it wasn't handled. What I got, was a lot of ways to make it half-work. :-P but, maybe it's just me being tired. -- Cheers Jorge.-

1 0

patch: text search
by place＠gobigwest.com Nov. 19, 2007

Nov. 19, 2007

I'm not much of a drawing/gui person, but it's hard not being able to search pages, so I gave it a try (attached). - If you hit ^Q on this window or the page source or page bugs windows, dillo will crash because it assumes it's closing a bw. - I didn't want a title bar, and I didn't want it to be able to outlive its bw, but I didn't know what to do about it. - If searching scrolls the window, highlighting isn't undone properly. (If you search for something like "a", the last instance on each line will remain highlighted) *plays with it a bit more* Maybe it's good to have a title bar after all. It's easier to move out of the way than the 0.8.x one was...

3 8

[PATCH] improved image load button graphics
by onepoint＠starurchin.org Nov. 19, 2007

Nov. 19, 2007

I thought that the graphics for the image load toggle button looked rather scrappy, so I have made some new ones that I think are a little smarter. You can compare them at http://starurchin.org/dillo/img_load.html . The patch is appended here. Regards, Jeremy Henty 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-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpid: .deps Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpip: .deps Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/: install-sh Only in dillo2-cur/: missing Only in dillo2-cur/src: .deps Only in dillo2-cur/src/IO: .deps Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in diff -pru -- dillo2-ref/src/pixmaps.h dillo2-cur/src/pixmaps.h --- dillo2-ref/src/pixmaps.h 2007-11-03 09:30:39.000000000 +0000 +++ dillo2-cur/src/pixmaps.h 2007-11-18 14:49:51.000000000 +0000 @@ -1497,44 +1497,44 @@ static char * mini_ok_xpm[] = { /* XPM */ static char * imgload_on_xpm[] = { "15 15 2 1", -" c #00000000CF3C", -". c #FFFFFFFFFFFF", -" . . .........", -" . ... ..", -" . . ... ....", -" . ... .. .....", -" ..... . .. .", -"......... .. .", -".......... .", -"...............", -". ...........", -". . . .. ....", -". .. . ....", -". .. . . .....", -". . . .....", -"...............", -"..............."}; +" c #FFFFFFFFFFFF", +". c #00000000CF3C", +" ", +" ... . . .. ", +" . .. .. . . ", +" . . . . . ", +" . . . . . ", +" . . . . . ", +" ... . . .. ", +" ", +" .. . . ", +" . . .. . ", +" . . . . . ", +" . . . .. ", +" . . . . ", +" .. . . ", +" "}; /* XPM */ static char * imgload_off_xpm[] = { "15 15 2 1", -" c #CF3C00000000", -". c #FFFFFFFFFFFF", -" .. . .........", -" . .. ...", -" . . ......", -" . . . . .. ..", -" . ... .. ..", -" ........ ..", -"...............", -"...............", -"...............", -" .. . ....", -" . .. ..", -" . . .... .....", -" . . ...", -" .. ... ...", -".... .... ....."}; +" c #FFFFFFFFFFFF", +". c #CF3C00000000", +" ", +" ... . . .. ", +" . .. .. . . ", +" . . . . . ", +" . . . . . ", +" . . . . . ", +" ... . . .. ", +" ", +" .. ... ... ", +" . . . . ", +" . . ... ... ", +" . . . . ", +" . . . . ", +" .. . . ", +" "}; /* XPM */ static char *left_i_xpm[] = { Only in dillo2-cur/: stamp-h1

3 3

duplicate enter/leave notification
by place＠gobigwest.com Nov. 19, 2007

Nov. 19, 2007

If I have an xterm or something overlapping an image, when I move the pointer between the two, I get two enters or two leaves. A gdb backtrace on entry showed that Layout::enterNotify() first notifies the image by way of moveToWidgetAtPoint -> moveToWidget, and then comes back and notifies it "personally".

1 0

Re: patch: copy image/link location
by jcid＠dillo.org Nov. 18, 2007

Nov. 18, 2007

On Sun, Nov 18, 2007 at 06:46:51PM +0000, place wrote: > patch: copy image/link location Committed. -- Cheers Jorge.-

1 0

on copy and paste
by place＠gobigwest.com Nov. 18, 2007

Nov. 18, 2007

The bottom of dw/selection.cc goes: /** \todo Actual Selection is platform dependant. */ printf ("Selected text:\n"); printf ("--------------------------------------------------\n"); printf (strbuf.getChars ()); printf ("\n--------------------------------------------------\n"); Now, suppose we violate the principles of dw, sticking #include <fltk/events.h> in the top of the file, and put const char *buf = strbuf.getChars(); fltk::copy(buf, strlen(buf), false); in place of the above printf()s. Works. So if anyone knows the structure of dw well enough to know how to go about making a proper little platform-independent interface, there's nothing difficult here in principle...

2 2

[PATCH] Ctrl-R reloads
by onepoint＠starurchin.org Nov. 18, 2007

Nov. 18, 2007

This patch amkes Ctrl-R reload the page. Just like Dillo Classic! Regards, Jeremy Henty 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-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpid: .deps Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpip: .deps Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/: install-sh Only in dillo2-cur/: missing Only in dillo2-cur/src: .deps Only in dillo2-cur/src/IO: .deps Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-ref/src: html.cc.orig diff -pru -- dillo2-ref/src/ui.cc dillo2-cur/src/ui.cc --- dillo2-ref/src/ui.cc 2007-11-18 07:36:55.000000000 +0000 +++ dillo2-cur/src/ui.cc 2007-11-18 08:10:08.000000000 +0000 @@ -56,7 +56,8 @@ public: }; /* - * Disable: UpKey, DownKey, PageUpKey, PageDownKey and CTRL+{o,HomeKey,EndKey} + * Disable: UpKey, DownKey, PageUpKey, PageDownKey and + * CTRL+{o,r,HomeKey,EndKey} */ int NewInput::handle(int e) { @@ -64,7 +65,7 @@ int NewInput::handle(int e) bool ctrl = event_state(CTRL); _MSG("NewInput::handle event=%d", e); - if (ctrl && (k == 'o' || k == HomeKey || k == EndKey)) + if (ctrl && (k == 'o' || k == 'r' || k == HomeKey || k == EndKey)) return 0; if ((e == KEY || e == KEYUP) && k == UpKey || k == DownKey || k == PageUpKey || k == PageDownKey) { @@ -666,6 +667,9 @@ int UI::handle(int event) } else if (event_key() == 'q') { a_UIcmd_close_bw(user_data()); ret = 1; + } else if (event_key() == 'r') { + a_UIcmd_reload(user_data()); + ret = 1; } else if (event_key() == 's') { a_UIcmd_search_dialog(user_data()); ret = 1; Only in dillo2-cur/: stamp-h1

2 1

Re: patch: base url page menu
by jcid＠dillo.org Nov. 18, 2007

Nov. 18, 2007

On Mon, Nov 12, 2007 at 04:59:34PM +0000, place wrote: > Considering how all of the arguments are bw, do you think > the control should go html -> bw -> uicmd -> menu? The "Load images" via page menu patch was committed. I also made a big cleanup of html.hh. It was exporting data no module besides html.cc was using. With regard to your question, currently we have this dependency graph: ,-------------> menu | ^ -----> timeout | | / | v / | ui <-----> uicmd <-----> nav | ^ ^ \ | | / | \ | | / v \ v '-> html ----' bw ----> dialog ^ | form I don't like the double relation between "html" and "menu". It could be "html" calling "menu" only. For instance if we implement setting a callback function in menu's API for "Load Images". Maybe there's a better way, and I'm not sure, but a least the committed cleanup makes it look much cleaner. ;-) BTW, I also added premliminar activate/deactivate to this menu item. -- Cheers Jorge.-

2 3

Re: space bar to page
by jcid＠dillo.org Nov. 17, 2007

Nov. 17, 2007

On Tue, Nov 13, 2007 at 10:18:48PM +0000, place wrote: > I like hitting the space bar to page down. I've been carrying this code > along for a couple of weeks now, and the take_focus() hasn't caused anything > horrible to happen yet, so far as I can tell, anyway... + Added shortcuts: PgDn=Spc PgUp=b Back=BackSpace|, Forw=Shift+Backspace|. Committed. -- Cheers Jorge.-

1 0

[patch] avoid complete redraws for child widget updates
by Johannes.Hofmann＠gmx.de Nov. 17, 2007

Nov. 17, 2007

Hello, here comes a patch that avoids complete redrawing if only a child widget (button or form input) requests redrawing. I don't really like the fact, that fltk widgets are sometimes drawn via Group::draw() and sometimes via theLayout->expose(), but this is already the case without my patch, so I just leave it as it is for now. In the long run, I would propose to add a mechanism similar to fltk DAMAGE_CHILD to dw. To test go to google and type in some text. Cheers, Johannes

2 1

[PATCH]: fix occasional segfault in dw::Table::reallocChildren
by onepoint＠starurchin.org Nov. 17, 2007

Nov. 17, 2007

This patch fixes an occasional segfault when adding columns to a table that contains cells that span multiple rows or columns. This was reported to the list last month by Matthias Franz. I've been bitten by this on several web sites (see the details below), so it's a useful fix. Regards, Jeremy Henty Only in dw2-cur/: Makefile Only in dw2-cur/: Makefile.in Only in dw2-cur/: aclocal.m4 Only in dw2-cur/: autom4te.cache Only in dw2-cur/: config.guess Only in dw2-cur/: config.log Only in dw2-cur/: config.status Only in dw2-cur/: config.sub Only in dw2-cur/: configure Only in dw2-cur/: depcomp Only in dw2-cur/doc: Makefile Only in dw2-cur/doc: Makefile.in Only in dw2-cur/dw: .deps Only in dw2-cur/dw: Makefile Only in dw2-cur/dw: Makefile.in diff -pru -- dw2-ref/dw/table.cc dw2-cur/dw/table.cc --- dw2-ref/dw/table.cc 2007-10-06 23:03:01.000000000 +0100 +++ dw2-cur/dw/table.cc 2007-11-16 13:02:59.000000000 +0000 @@ -357,7 +357,7 @@ void Table::reallocChildren (int newNumC break; case Child::SPAN_SPACE: if (children->get(children->get(n)->spanSpace.startRow - * newNumCols + + * numCols + children->get(n)->spanSpace.startCol) ->cell.colspanOrig == 0) { colspan0Col = children->get(n)->spanSpace.startCol; Only in dw2-cur/: install-sh Only in dw2-cur/lout: .deps Only in dw2-cur/lout: Makefile Only in dw2-cur/lout: Makefile.in Only in dw2-cur/: missing Only in dw2-cur/test: .deps Only in dw2-cur/test: Makefile Only in dw2-cur/test: Makefile.in Analysis of the bug: A dillo table stores its children in a single vector that is the concatenation of the rows. This means that when the number of columns increases the contents of the vector must be rearranged. The code does this in place, starting at the end and working backwards. When the code reaches a point that corresponds to a multi-row/column cell, it finds a placeholder that stores the row/column of the actual cell. The important point is that the actual cell is stored in the vector *before* any placeholders that refer to it. Therefore the cell has not yet been moved when the code reaches the placeholder (because it works backwards from the end). The code must calculate the index of the actual cell from the row/column in the placeholder based on the *old* number of columns. Unfortunately the code uses the *new* number of columns, so it may retrieve a cell from the wrong place. Sometimes it retrieves a NULL and segfaults when it tries to dereference it. Test cases: <html><head></head><body><table><tbody> <tr><td colspan="2"></td></tr> <tr><td rowspan="2"></td></tr> <tr><td colspan="2"></td></tr> </tbody></table></body></html> [NB: the next one is from Matthias Franz.] <html> <table> <tr></tr> <tr><td colspan="3"></td></tr> <td colspan="3"> </table> </html> Online pages that trigger the bug: <a href="http://legacyeditorial.gettyimages.com/source/search/details_pop.aspx?iid=7…"> <a href="http://www.eweek.com/article2/0,1759,2216435,00.asp"> <a href="http://www.possible-area.org/bad_timing161107.php"> <a href="http://www.eweek.com/article2/0,1895,2216978,00.asp"> <a href="http://www.nostalgia.com/nf_moreinfo.html?sku=10576">

2 1

[patch] delete the phantom widgets
by Johannes.Hofmann＠gmx.de Nov. 15, 2007

Nov. 15, 2007

Hello, here is a patch to really delete the fltk widgets when we leave a page. I hope there are no references to the deleted widgets left, but I'm not 100% sure, so please test it carefully. Also if someone has an idea for a more elegant implementation of FltkWidgetView::removeFltkWidget(), that would be great. Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -90,6 +90,10 @@ void FltkView::prepareCreateFltkWidget ( void FltkView::addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation) +{ +} + +void FltkView::removeFltkWidget (::fltk::Widget *widget) { } diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -43,6 +43,7 @@ public: virtual void prepareCreateFltkWidget (); virtual void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); + virtual void removeFltkWidget (::fltk::Widget *widget); virtual void allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); virtual void drawFltkWidget (::fltk::Widget *widget, core::Rectangle *area); diff --git a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -77,6 +77,21 @@ FltkResource::~FltkResource () FltkResource::~FltkResource () { platform->detachResource (this); + for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); + it.hasNext(); ) { + ViewAndWidget *viewAndWidget = it.getNext (); + + if (viewAndWidget->widget) { + if (viewAndWidget->view) { + viewAndWidget->view->removeFltkWidget(viewAndWidget->widget); + } + if (viewAndWidget->widget->parent()) { + viewAndWidget->widget->parent()->remove(viewAndWidget->widget); + } + delete viewAndWidget->widget; + } + + } delete viewsAndWidgets; if(style) style->unref (); diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -364,6 +364,19 @@ void FltkWidgetView::addFltkWidget (::fl allocateFltkWidget (widget, allocation); } +void FltkWidgetView::removeFltkWidget (::fltk::Widget *widget) +{ + for(Iterator <TypedPointer < ::fltk::Widget> > it + = canvasWidgets->iterator (); + it.hasNext (); ) { + TypedPointer < ::fltk::Widget> *wp = it.getNext(); + + if (widget == wp->getTypedValue ()) { + canvasWidgets->remove(wp); + } + } +} + void FltkWidgetView::allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation) { diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -83,6 +83,7 @@ public: bool usesFltkWidgets (); void prepareCreateFltkWidget (); void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); + void removeFltkWidget (::fltk::Widget *widget); void allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); void drawFltkWidget (::fltk::Widget *widget, core::Rectangle *area);

1 0

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

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

Test (for posting problems), please ignore
by onepoint＠starurchin.org Oct. 27, 2007

Oct. 27, 2007

Lets see if Jorge has has fixed whatever it was that stopped my posts getting through... Jeremy Henty

1 0

directory listings?
by hans＠stare.cz Oct. 22, 2007

Oct. 22, 2007

On Oct 19 19:33:56, dillo-dev-bounces(a)dillo.org wrote: > On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > > Hi all, > > > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > > listing as it should. It's full of subdirectories, and they > > are all the same (just contain JPEGs). > > > > Now when I click on _some_ of the links, I get a correct directory > > listing again (of the subdirectory). When I click on _some_ others > > I get nothing, just a blank page (gray). > > > > [...] > > Please try the CVS code on this. With current code, I cannot even test it, because dillo keeps "Connecting to server" forever, giving the following message: $ dillo-fltk http://stare.cz/~hans/foto/ prefs: Can't open dillorc2 file: /home/hans/.dillo/dillorc2 prefs: Can't open dillorc2 file: /usr/local/etc/dillorc prefs: Using internal defaults. dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: Url=>http://stare.cz/~hans/foto/< Dns_server [0]: stare.cz is 0x7f7b8640 Connecting to 88.208.90.43 ** ERROR **: IO_fd_write_cb: call on already closed io! a_UIcmd_close_bw ... until I kill it. (The server is acessible, the same URL can be browsed with lynx.) Jan

2 1

drag scrolling as in good old dillo1
by Johannes.Hofmann＠gmx.de Oct. 21, 2007

Oct. 21, 2007

Hi, here is a patch to enable drag scrolling with the middle mouse button as in dillo1. For me from now only the "Backspace" hotkey is missing for daily browsing - apart from the occasional crashes of course :-) Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -47,6 +47,7 @@ FltkViewport::FltkViewport (int x, int y vscrollbar->callback (vscrollbarCallback, this); scrollX = scrollY = 0; + dragScrolling = 0; gadgetOrientation[0] = GADGET_HORIZONTAL; gadgetOrientation[1] = GADGET_HORIZONTAL; @@ -202,6 +203,34 @@ int FltkViewport::handle (int event) /** \bug Undraw focus box. */ return 1; + case ::fltk::PUSH: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 1; + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + /* pass event so that middle click can open link in new window */ + FltkWidgetView::handle (event); + return 1; + } + break; + + case ::fltk::DRAG: + if (::fltk::event_button() == ::fltk::MiddleButton) { + if (dragScrolling) { + scroll(dragX - ::fltk::event_x(), dragY - ::fltk::event_y()); + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + return 1; + } + } + break; + + case ::fltk::RELEASE: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 0; + } + break; + case ::fltk::SHORTCUT: switch (::fltk::event_key()) { case PageUpKey: @@ -236,12 +265,9 @@ int FltkViewport::handle (int event) scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ return 1; } + } - return FltkWidgetView::handle (event); - - default: - return FltkWidgetView::handle (event); - } + return FltkWidgetView::handle (event); } // ---------------------------------------------------------------------- diff --git a/dw/fltkviewport.hh b/dw/fltkviewport.hh --- a/dw/fltkviewport.hh +++ b/dw/fltkviewport.hh @@ -21,6 +21,7 @@ private: int scrollX, scrollY; int scrollDX, scrollDY; + int dragScrolling, dragX, dragY; ::fltk::Scrollbar *vscrollbar, *hscrollbar;

2 1

bug: non-ascii characters not displayed correctly in the title bar
by matthias.franz＠ujf-grenoble.fr Oct. 20, 2007

Oct. 20, 2007

Hi, by default, I use Latin1 encoding on my machine, not UTF-8. Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. Here is an example: <title>dillô</title> <body> dillô </body> You don't get "dill?" in the title bar, but "dill??". Cheers, -- Matthias Franz

2 2

directory listings?
by hans＠stare.cz Oct. 20, 2007

Oct. 20, 2007

Hi all, dillo-fltk http://stare.cz/~hans/foto/ gives me a directory listing as it should. It's full of subdirectories, and they are all the same (just contain JPEGs). Now when I click on _some_ of the links, I get a correct directory listing again (of the subdirectory). When I click on _some_ others I get nothing, just a blank page (gray). Dillo obviously knows the page source, because it shows nonzero bugs in the bug button, consistently saying ([num of jpegs in the subdirectory] + 3); for example, clicking on http://stare.cz/~hans/foto/20071010-Barunka gives HTML warning: line 8, <pre> is not allowed to contain <img> HTML warning: line 9, <pre> is not allowed to contain <hr>. -- closing <pre> HTML warning: line 10, <pre> is not allowed to contain <img> HTML warning: line 11, <pre> is not allowed to contain <img> HTML warning: line 12, <pre> is not allowed to contain <img> HTML warning: line 13, <pre> is not allowed to contain <img> (for other subdirs of http://stare.cz/~hans/foto/ the number of bug lines just differs by the number of JPEGs); but the content of the page itself is blank. Then again, for some other subdir (which just contains different JPEGs and has a different name, but is otherwise equivalent), dillo shows the correct listing (including two spacing "dots" and a "parent directory" icon, which probably make for the +3 bugs; which is another dillo bug possibly :-) A listing of subdirectory such as http://stare.cz/~hans/foto/20071010-Barunka/ is always displayed correctly if I just issue $ dillo-fltk http://stare.cz/~hans/foto/20071010-Barunka on the command line. The above only happens when I _click_ on a (sub)directory link in a (parent)directory listing. Also, listings of _some_ of the subdirectories (if they get listed at all) jump to the very bottom of the page, as when clicking on http://stare.cz/~hans/foto/2005-Metheny/ (obviously, this can only be seen if the directory listing is long enough). Again, this never happens when I acccess the listing directly from commandline. Jan

2 2

dillo crashes on (incorrect) tables
by matthias.franz＠ujf-grenoble.fr Oct. 19, 2007

Oct. 19, 2007

Hi, the following (syntactically incorrect) HTML code makes dillo2 crash on my machine. Dillo1 is fine. <html> <table> <tr></tr> <tr><td colspan="3"></td></tr> <td colspan="3"> </table> </html> Cheers, -- Matthias Franz

1 0

Re: receiver patch: html page menu working, image menu present but not called.
by place＠gobigwest.com Oct. 19, 2007

Oct. 19, 2007

Jorge wrote: > On Thu, Oct 18, 2007 at 10:56:39PM +0000, place wrote: > > > The fact of the linkblock not being freed in current code (see warning > > > from compiling html.cc) is just because I haven't found the clean & proper > > > place to hook Html_lb_free() (to widget destruction probably). IIRC there > > > was a ...connect_after() hook in GTK that worked ok after deletion of the > > > object (which I haven't yet found an analog in FLTK2). > > > > So I should regard "linkblock" as "the bag of event handling stuff"? Okay. > > It's a bag for links, form data etc... > > I've longed to get rid of it several times, but I don't see a > much cleaner approach. This may be the time, or maybe not. > > For instance, if the linkblock data is put inside the html > struct, and the whole turned into a class, it would look much > cleaner. It would also be clearer in the case of plain text (it > also receives the signal for page menu), and having a separate > linkblock or receiver for it seems odd. > > OTOH, the data that now belongs to the html-struct is freed > when parsing finishes, and it would remain inside the class, > which is a bit untidy, but if we make this part a pointer inside > the shiny new class, it could go NULL at freeing time. This looks > cleaner. Indeed. > > I now have new code for image signals. In an effort not to add an extra argument > > to the signals (which seemed hacky -- either an image_vs_link sort of argument, > > or an image_number sort of argument), I ended up making a vector of image > > receivers, one per image. I can't decide whether that is bad or reasonably > > sensible. If a better solution is obvious to you, please let me know. > > Not obvious, but I think of the case of pages with hundreds or > thousands of images (e.g.): > > http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… > > Memory consumption for this vector may grow too much. A single > int value working as an index to the proper URL/data from within > a single image signal receiver looks cleaner (from a distance :-) All right. > > So the image menu works, an ugly little button toggles image loading, and > > click-to-load works, though I don't have any placeholder image. > > More than enough for a start! And an opportunity for people who say "I'd love to help dillo, but don't know how to write code" to make a little tiny button... I was going to try having a single patch for all of that, but it was already teetering on the edge between small-enough and too-much. I think I'll try to pull out the menu and the button to send you first, since they're harmless, and then the rest after I redo it. > > (if only forms worked well enough to perform search queries, > > I just about wouldn't need my old dillo around anymore!) > > I know what you mean. Given that, plus the scrolling bug, > search text inside pages and anchors, it'd looks very sexy to me! > > > > BTW, not that it really matters at present, but I discovered that > > in Html_write_raw(), you can get token_start to be greater than bufsize. > > Go through the verbatim part at the top until token_start = buf_index = bufsize, > > then have the isspace() test right below it be true. > > It looks like this is why my iconv buffer code crashed often on me. > > Thanks for the report, I'll look at it when I find some time. > > > BTW, this duscussion is more than worth to have in dillo-dev. > Can I take it there? *cc:s dillo-dev, resists urge to trim quotes*

1 0

./configure confused about FLTK version
by hans＠stare.cz Oct. 19, 2007

Oct. 19, 2007

Hi all, it seems that the ./configure script as generated by ./autogen.sh of current cvs tree will happily go with fltk < 2, giving compilation errors later. Jan $ uname -a OpenBSD dell.stare.cz 4.1 GENERIC#0 i386 $ pkg_info | grep fltk fltk-1.1.7 Fast-Light Tool Kit $ pwd /home/hans/src $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo2 cvs checkout: Updating dillo2 [...] $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dw2 cvs checkout: Updating dw2 [...] $ ln -s dw2 dw-testbed $ cd dw-testbed $ export AUTOCONF_VERSION=2.61 $ export AUTOMAKE_VERSION=1.9 $ ./autogen.sh aclocal found autoheader found autoconf found automake found [Checks passed] Generating... [...] $ ./configure [...] checking FLTK2... yes [...] config.status: executing depfiles commands $ $ gmake [...] if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I. -I/usr/local/include -O2 -pipe -I/usr/local/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -MT libDw_fltk_a-fltkcomplexbutton.o -MD -MP -MF ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" -c -o libDw_fltk_a-fltkcomplexbutton.o `test -f 'fltkcomplexbutton.cc' || echo './'`fltkcomplexbutton.cc; \ then mv -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" ".deps/libDw_fltk_a-fltkcomplexbutton.Po"; else rm -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo"; exit 1; fi fltkcomplexbutton.cc:23:25: fltk/events.h: No such file or directory fltkcomplexbutton.cc:24:25: fltk/damage.h: No such file or directory fltkcomplexbutton.cc:25:24: fltk/Group.h: No such file or directory fltkcomplexbutton.cc:26:22: fltk/Box.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:28:24: fltk/Group.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:34: error: `fltk' is not a class or namespace fltkcomplexbutton.hh:35: error: `Group' is not a class or namespace fltkcomplexbutton.hh:35: error: invalid base-class specification fltkcomplexbutton.hh:43: error: syntax error before `&' token fltkcomplexbutton.hh:45: error: syntax error before `::' token [...]

3 5

[patch] CPU usage when moving mouse on large page
by Johannes.Hofmann＠gmx.de Oct. 19, 2007

Oct. 19, 2007

Hi, here is another patch regarding the performance of dillo-fltk. It addresses the high CPU usage when moving the cursor on a large page especially if it contains many links and images. See http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… as an example. Note, that also dillo1 uses quite some CPU when moving the mouse on that page. The patch moves Layout::getWidgetAtPoint0() to Widget::getWidgetAtPoint() and makes it virtual so that widgets can provide an own optimzed version of that method. For the Textblock widget an optimized version is implemented that uses findLineIndex(). This patch is a bit more invasive than the scroll-patch, so I would appreciate comments from the dw author(s). Johannes diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -703,47 +703,6 @@ void Layout::leaveNotify (View *view, Bu } } -/** - * \brief Search recursively through widget. - * - * Used by dw::core::Layout:getWidgetAtPoint. - */ -Widget *Layout::getWidgetAtPoint0 (Widget *widget, int x, int y, int level) -{ - Iterator *it; - Widget *childAtPoint; - - //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", - // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, - // widget->allocation.x, widget->allocation.y, - // widget->allocation.width, widget->allocation.ascent, - // widget->allocation.descent); - - if (x >= widget->allocation.x && - y >= widget->allocation.y && - x <= widget->allocation.x + widget->allocation.width && - y <= widget->allocation.y + widget->getHeight ()) { - //_MSG ("%*s -> inside\n", 3 * level, ""); - /* - * Iterate over the children of this widget. Test recursively, whether - * the point is within the child (or one of its children...). If there - * is such a child, it is returned. Otherwise, this widget is returned. - */ - childAtPoint = NULL; - it = widget->iterator (Content::WIDGET, false); - - while (childAtPoint == NULL && it->next ()) - childAtPoint = getWidgetAtPoint0 (it->getContent()->widget, - x, y, level + 1); - - if (childAtPoint) - return childAtPoint; - else - return widget; - } else - return NULL; -} - /* * Return the widget at position (x, y). Return NULL, if there is no widget. */ @@ -752,7 +711,7 @@ Widget *Layout::getWidgetAtPoint (int x, //_MSG ("------------------------------------------------------------\n"); //_MSG ("widget at (%d, %d)\n", x, y); if (topLevel) - return getWidgetAtPoint0 (topLevel, x, y, 0); + return topLevel->getWidgetAtPoint (x, y, 0); else return NULL; } diff --git a/dw/layout.hh b/dw/layout.hh --- a/dw/layout.hh +++ b/dw/layout.hh @@ -87,7 +87,6 @@ private: enum ButtonEventType { BUTTON_PRESS, BUTTON_RELEASE, MOTION_NOTIFY }; - Widget *getWidgetAtPoint0 (Widget *widget, int x, int y, int level); Widget *getWidgetAtPoint (int x, int y); void moveToWidget (Widget *newWidgetAtPoint, ButtonState state); diff --git a/dw/textblock.cc b/dw/textblock.cc --- a/dw/textblock.cc +++ b/dw/textblock.cc @@ -1730,6 +1730,50 @@ void Textblock::addLinebreak (core::styl wordWrap (words->size () - 1); } + +/** + * \brief Search recursively through widget. + * + * This is an optimized version of the general + * dw::core::Widget::getWidgetAtPoint method. + */ +core::Widget *Textblock::getWidgetAtPoint(int x, int y, int level) +{ + int lineIndex, wordIndex; + Line *line; + + if (x < allocation.x || + y < allocation.y || + x > allocation.x + allocation.width || + y > allocation.y + getHeight ()) { + return NULL; + } + + lineIndex = findLineIndex (y - allocation.y); + + if (lineIndex < 0 || lineIndex >= lines->size ()) { + return this; + } + + line = lines->getRef (lineIndex); + + for (wordIndex = line->firstWord; wordIndex < line->lastWord; wordIndex++) { + Word *word = words->getRef (wordIndex); + + if (word->content.type == core::Content::WIDGET) { + core::Widget * childAtPoint; + childAtPoint = word->content.widget->getWidgetAtPoint (x, y, + level + 1); + if (childAtPoint) { + return childAtPoint; + } + } + } + + return this; +} + + /** * This function "hands" the last break of a page "over" to a parent * page. This is used for "collapsing spaces". diff --git a/dw/textblock.hh b/dw/textblock.hh --- a/dw/textblock.hh +++ b/dw/textblock.hh @@ -366,6 +366,7 @@ public: void addParbreak (int space, core::style::Style *style); void addLinebreak (core::style::Style *style); + core::Widget *getWidgetAtPoint (int x, int y, int level); void handOverBreak (core::style::Style *style); void changeLinkColor (int link, int newColor); void changeWordStyle (int from, int to, core::style::Style *style, diff --git a/dw/widget.cc b/dw/widget.cc --- a/dw/widget.cc +++ b/dw/widget.cc @@ -676,6 +676,48 @@ Widget *Widget::getNearestCommonAncestor } +/** + * \brief Search recursively through widget. + * + * Used by dw::core::Layout:getWidgetAtPoint. + */ +Widget *Widget::getWidgetAtPoint (int x, int y, int level) +{ + Iterator *it; + Widget *childAtPoint; + + //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", + // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, + // allocation.x, allocation.y, + // allocation.width, allocation.ascent, + // allocation.descent); + + if (x >= allocation.x && + y >= allocation.y && + x <= allocation.x + allocation.width && + y <= allocation.y + getHeight ()) { + //_MSG ("%*s -> inside\n", 3 * level, ""); + /* + * Iterate over the children of this widget. Test recursively, whether + * the point is within the child (or one of its children...). If there + * is such a child, it is returned. Otherwise, this widget is returned. + */ + childAtPoint = NULL; + it = iterator (Content::WIDGET, false); + + while (childAtPoint == NULL && it->next ()) + childAtPoint = it->getContent()->widget->getWidgetAtPoint (x, y, + level + 1); + + if (childAtPoint) + return childAtPoint; + else + return this; + } else + return NULL; +} + + void Widget::scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height) { diff --git a/dw/widget.hh b/dw/widget.hh --- a/dw/widget.hh +++ b/dw/widget.hh @@ -405,6 +405,8 @@ public: inline Layout *getLayout () { return layout; } + virtual Widget *getWidgetAtPoint (int x, int y, int level); + void scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height);

1 0

Dillo FLTK2 alpha release for developers
by None Oct. 18, 2007

Oct. 18, 2007

Hi there, This is an alpha release of the next generation of the Dillo web browser. The code underwent a major rewrite: significant parts of the codebase were ported to C++, and the rendering engine now uses the FLTK2 library instead of GTK1. Please read the README inside dillo's tarball. Developers willing to join the project and contribute are highly encouraged. Sebastian did an excellent work documenting the new dillo widget engine (just run doxygen inside DW tree). This is a good milestone in the project's history, we hope to be able to continue working on it. This is one step ahead, and we need other developers help. Please note that this code is under GPL3! BTW, if you want to know what antialiased utf-8 is, just go to: http://www.gnu.org/home.fa.html after compiling dillo-fltk. Here are the instructions on how to get it working: --------------- Get these files --------------- wget http://www.dillo.org/dillo2/fltk-2.0.x-r5917.tar.bz2 wget http://www.dillo.org/dillo2/dw-testbed-0.0.43j.tar.bz2 wget http://www.dillo.org/dillo2/dillo-f15f.tar.bz2 ----- FLTK2 ----- tar jxvf fltk-2.0.x-r5917.tar.bz2 cd fltk-2.0.x-r5917 make // Should compile cleanly if you have the // necessary development packages... cd test; ./demo // You can play with it too! cd .. su make install // Install FLTK2 libraries exit cd .. ---------- dw-0.0.43j ---------- tar jxvf dw-testbed-0.0.43j.tar.bz2 cd dw-testbed-0.0.43j ./configure make cd test // You can test it from here cd ../.. doxygen // Excellent documentation in html cd html; dillo index.html // (start browsing docs here) cd ../.. ln -s dw-testbed-0.0.43j dw-testbed // Don't forget this link ---------- dillo f15j ---------- tar jxvf dillo-f15f.tar.bz2 cd dillo-f15 ./configure make su make install // Needed for dpis exit cd src ./dillo-fltk // This is is it! cd .. -------- dillorc2 -------- There's a "dillorc2" file inside the tarball's top directory: cp dillorc2 ~/.dillo/ that will let you use the new and old dillo without trouble. -- Cheers Jorge.-

10 22

[patch] improve scroll performance of dillo-fltk
by Johannes Hofmann Oct. 16, 2007

Oct. 16, 2007

Hi, below is an initial patch that improves scrolling performance of dillo-fltk by copying screen data instead of rerendering it. It's based on Scroll.cxx from fltk. The difference is noticeable mostly when scrolling large images especially within a remote X11 session. The newly introduced scrollDX / scrollDY could probabely be combined with the existing oldScrollX / oldScrollY variables. Regards, Johannes diff --git a/dw-testbed-0.0.43j/dw/fltkviewbase.cc b/dw-testbed-0.0.43j/dw/fltkviewbase.cc --- a/dw-testbed-0.0.43j/dw/fltkviewbase.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewbase.cc @@ -54,18 +54,16 @@ void FltkViewBase::draw () Group::draw (); - if (damage () & DAMAGE_EXPOSE) { - setcolor (bgColor); - ::fltk::Rectangle rect (0, 0, w(), h()); - fillrect (rect); - - core::Rectangle area; - area.x = translateViewXToCanvasX (0); - area.y = translateViewYToCanvasY (0); - area.width = translateViewXToCanvasX (0 + w ()) - 0; - area.height = translateViewYToCanvasY (0 + h ()) - 0; - theLayout->expose (this, &area); - } + setcolor (bgColor); + ::fltk::Rectangle rect (0, 0, w(), h()); + fillrect (rect); + + core::Rectangle area; + area.x = translateViewXToCanvasX (0); + area.y = translateViewYToCanvasY (0); + area.width = translateViewXToCanvasX (0 + w ()) - 0; + area.height = translateViewYToCanvasY (0 + h ()) - 0; + theLayout->expose (this, &area); } core::ButtonState getDwButtonState () diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.cc b/dw-testbed-0.0.43j/dw/fltkviewport.cc --- a/dw-testbed-0.0.43j/dw/fltkviewport.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewport.cc @@ -131,8 +131,8 @@ void FltkViewport::hscrollbarChanged () { int oldScrollX = scrollX; scrollX = hscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + scrollDX = scrollX - oldScrollX; + redraw (DAMAGE_SCROLL); updateCanvasWidgets (oldScrollX, scrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); } @@ -141,8 +141,8 @@ void FltkViewport::vscrollbarChanged () { int oldScrollY = scrollY; scrollY = vscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + scrollDY = scrollY - oldScrollY; + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); } @@ -163,6 +163,25 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); +} + +void FltkViewport::draw_area (void *data, const Rectangle& cr ) +{ + FltkViewport *vp = (FltkViewport*) data; + push_clip(cr); + + vp->FltkWidgetView::draw (); + + //draw_child (*hscrollbar); + //draw_child (*vscrollbar); + + for(Iterator <TypedPointer < ::fltk::Widget> > it = vp->gadgets->iterator (); + it.hasNext (); ) { + ::fltk::Widget *widget = it.getNext()->getTypedValue (); + vp->draw_child (*widget); + } + + pop_clip(); } void FltkViewport::draw () @@ -170,20 +189,16 @@ void FltkViewport::draw () int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; Rectangle cr (0, 0, w () - hdiff, h () - vdiff); - push_clip(cr); - - FltkWidgetView::draw (); - - //draw_child (*hscrollbar); - //draw_child (*vscrollbar); - - for(Iterator <TypedPointer < ::fltk::Widget> > it = gadgets->iterator (); - it.hasNext (); ) { - ::fltk::Widget *widget = it.getNext()->getTypedValue (); - draw_child (*widget); - } - - pop_clip(); + int d = damage(); + + if (d == DAMAGE_SCROLL) { + scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); + } else { + draw_area(this, cr); + } + + scrollDX = 0; + scrollDY = 0; } int FltkViewport::handle (int event) @@ -205,8 +220,9 @@ int FltkViewport::handle (int event) case PageUpKey: oldScrollY = scrollY; scrollY -= vscrollbar->pagesize (); + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); return 1; @@ -214,8 +230,9 @@ int FltkViewport::handle (int event) case PageDownKey: oldScrollY = scrollY; scrollY += vscrollbar->pagesize (); + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); return 1; @@ -254,12 +271,13 @@ void FltkViewport::scrollTo (int x, int void FltkViewport::scrollTo (int x, int y) { int oldScrollX = scrollX; - //int oldScrollY = scrollY; + int oldScrollY = scrollY; scrollX = x; scrollY = y; + scrollDX = scrollX - oldScrollX; + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (oldScrollX, scrollY); } diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.hh b/dw-testbed-0.0.43j/dw/fltkviewport.hh --- a/dw-testbed-0.0.43j/dw/fltkviewport.hh +++ b/dw-testbed-0.0.43j/dw/fltkviewport.hh @@ -20,6 +20,7 @@ private: enum { SCROLLBAR_THICKNESS = 15 }; int scrollX, scrollY; + int scrollDX, scrollDY; ::fltk::Scrollbar *vscrollbar, *hscrollbar; @@ -35,6 +36,7 @@ private: static void vscrollbarCallback (Widget *vscrollbar, void *viewportPtr); void updateCanvasWidgets (int oldScrollX, int oldScrollY); + static void draw_area (void *data, const Rectangle& cr); protected: int translateViewXToCanvasX (int x);

6 11

Fwd: Re: [Dillo-dev] New CVS directions page
by 4winter＠informatik.uni-hamburg.de Oct. 16, 2007

Oct. 16, 2007

On Fri, 12 Oct 2007 17:41:41 -0400, dillo-dev-bounces(a)dillo.org wrote: > Please let me know if this time the directions work! :-P I would suggest the following changes: - find dw2-cur -name CVS -exec rm \{\} \; - find dillo2-cur -name CVS -exec rm \{\} \; + find dw2-cur dillo2-cur -name CVS | xargs rm -R - cd dw2-cur; ./autogen.sh; ./configure; make + cd dw2-cur; ./autogen.sh && ./configure && make cd .. - cd dillo2-cur; ./autogen.sh; ./configure; make + cd dillo2-cur; ./autogen.sh && ./configure && make Hummel Hummel, Justus

3 2

Re: character entity references produce garbage
by matthias.franz＠ujf-grenoble.fr Oct. 15, 2007

Oct. 15, 2007

On Tue, Oct 09, 2007 at 11:08:21PM +0200, Johannes Hofmann wrote: > I can now reproduce this on a debian system without libxft-dev > installed. > Do you still see this after installing libxft-dev? No. Now it's gone, even if I comment out "freetype" and "type1" in my xorg.conf. (I understand that Xft has something to do with font rasterizing.) But it should work without Xft as well, shouldn't it? -- Matthias Franz

2 3

New CVS and newwest FLTK2 release
by bogus＠does.not.exist.com Oct. 14, 2007

Oct. 14, 2007

Hi there, I just updated the CVS so it can use the latest stable FLTK2. Get FLTK2 from www.fltk.org (r5941), or from here: wget http://www.dillo.org/dillo2/fltk-2.0.x-r5941.tar.bz2 You'll have to configure, compile and install this new version, and to rebuild the whole dw2 and dillo2. That way we stay more current. -- Cheers Jorge.-

1 0

Re: [patch] improve scroll performance of dillo-fltk
by Johannes.Hofmann＠gmx.de Oct. 14, 2007

Oct. 14, 2007

Hi Matthias, I just made a xtrace (http://packages.debian.org/unstable/x11/xtrace) when scrolling the http://www.w3.org/TR/xslt page with patched dillo (result below). I think this is pretty good already. Just the newly exposed glyphs get rendered. Each word is sent to the X-Server seperately. This might be an area for improvement. Could you try the same on your system, so that we find out, whether the patch does not work for you or whether scrolling is still too CPU consuming even with the working patch? Here is what I did to get the trace: xtrace > /tmp/xtrace.out export DISPLAY=:9 dillo-fltk http://www.w3.org/TR/xslt Then scroll using the triangle of the scrollbar for a while and stop dillo. The resulting file is huge but I am only interested in the repeating sections that result from the scrolling and start with CopyArea. Gruss, Johannes 000:<:c474: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00000000} 000:<:c475: 28: Request(62): CopyArea src-drawable=0x01c00008 dst-drawable=0x01c00008 gc=0x01c00009 src-x=0 src-y=93 dst-x=0 dst-y=73 width=765 height=467 000:>:c475: Event NoExposure(14) drawable=0x01c00008 minor-opcode=0x0000 major-opcode=0x3e 000:<:c476: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c477: 20: RENDERRequest(154): RenderSetPictureClipRectangles picture=0x01c00036 xOrigin=0 yOrigin=0 rectangles={x=0 y=540 w=765 h=20}; 000:<:c478: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c479: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00e0e0e0} 000:<:c47a: 20: Request(70): PolyFillRectangle drawable=0x01c00008 gc=0x01c00009 rectangles={x=0 y=0 w=780 h=580}; 000:<:c47b: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c47c: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00dcd1ba} 000:<:c47d: 20: Request(70): PolyFillRectangle drawable=0x01c00008 gc=0x01c00009 rectangles={x=0 y=540 w=765 h=20}; 000:<:c47e: 60: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00063 xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=530 glyphs=0x1f,0x5b,0x56,0x4f,0x1d,0x44,0x5 3,0x53,0x4f,0x5c,0x10,0x57,0x48,0x50,0x53,0x4f,0x44,0x57,0x48,0x56,0x12,0x21; }; 000:<:c47f: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=554 glyphs=0x5a,0x4b,0x48,0x51; }; 000:<:c480: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=38 deltay=554 glyphs=0x4c,0x57; }; 000:<:c481: 44: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=47 deltay=554 glyphs=0x5a,0x44,0x51,0x57,0x56; }; 000:<:c482: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=82 deltay=554 glyphs=0x57,0x52; }; 000:<:c483: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=95 deltay=554 glyphs=0x46,0x52,0x53,0x5c; }; 000:<:c484: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=124 deltay=554 glyphs=0x57,0x4b,0x48; }; 000:<:c485: 44: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00063 xSrc=0 ySrc=0 glyphcmds={deltax=144 deltay=554 glyphs=0x5b,0x50,0x4f,0x1d,0x4f,0x44,0 x51,0x4a; }; 000:<:c486: 48: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=203 deltay=554 glyphs=0x44,0x57,0x57,0x55,0x4c,0x45,0 x58,0x57,0x48,0x11; };

3 8