- Dillo-dev - lists.mailman3.com

[patch] avoid complete redraws for child widget updates

by jcid＠dillo.org

Hi, On Fri, Nov 16, 2007 at 04:19:42PM +0100, Johannes Hofmann wrote: > Hello, > > here comes a patch that avoids complete redrawing if only a child > widget (button or form input) requests redrawing. Committed. > 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. Yes. AFAIR we talked about this with Sebastian. IIRC he also didn't like much the mixed approach, and if he found a simpler way to do it, it'd be changed. The complex button stuff, and the fltk embedding could be avoided by re-implementing those in dw, but it looks like overkill. > In the long run, I would propose to add a mechanism similar to > fltk DAMAGE_CHILD to dw. If you find a simpler/better way, it's more than welcomed. -- Cheers Jorge.-

Nov. 17, 2007

[PATCH]: fix occasional segfault in dw::Table::reallocChildren

by jcid＠dillo.org

Hi Jeremy, On Fri, Nov 16, 2007 at 03:02:37PM +0000, Jeremy Henty wrote: > > 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. Yes it is. Committed! BTW, thanks for the excellent explanation. > 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"> -- Cheers Jorge.-

Nov. 17, 2007

patch: text search

by place＠gobigwest.com

> On Fri, Nov 16, 2007 at 08:12:17PM +0000, place wrote: > > Johannes wrote: > > > On Fri, Nov 16, 2007 at 07:10:48PM +0000, place wrote: > > > > Johannes wrote: > > > > > Very nice! I was text search a lot. > > > > > What about incremental searching as you type? > > > > > I don't mind the title bar... > > > > > > > > Hmm... I'd have to modify findtext.cc some... > > > > I may get around to it at some point here, though I'm > > > > feeling the need to look into what's going on with > > > > redirection and gzip, so if anybody else gets there > > > > first, it'll be fine with me! :) > > > > > > I was thinking about something like: > > > > > > > > > diff -r f18e37a8e3ac src/dialog.cc > > > --- a/src/dialog.cc Fri Nov 16 20:25:11 2007 +0100 > > > +++ b/src/dialog.cc Fri Nov 16 20:27:18 2007 +0100 > > > @@ -141,14 +141,6 @@ static void findtext_search_cb(Widget *, > > > const char *key = tf->i->value(); > > > bool case_sens = tf->cb->value(); > > > > > > - /* > > > - * Somehow fltk even regards the first loss of focus for the > > > - * window as a WHEN_ENTER_KEY_ALWAYS event. > > > - */ > > > - int e = event_key(); > > > - if ((e != ReturnKey) && (e != LeftButton)) > > > - return; > > > - > > > if (key[0] != '\0') > > > a_UIcmd_findtext_search(tf->bw, key, case_sens); > > > > > > @@ -176,7 +168,7 @@ TextFinder::TextFinder(int ww, int wh, B > > > > > > begin(); > > > i = new Input(0, 0, ww, ih); > > > - i->when(WHEN_ENTER_KEY_ALWAYS); > > > + i->when(WHEN_CHANGED); > > > i->callback(findtext_search_cb, this); > > > > > > cb = new CheckButton(0, ih, ww, wh-ih-bh, "Case-sensitive"); > > > > > > > > > on top of your patch of course. Works for me. > > > > I had tried that before replying earlier, and I was happy at > > first, but then after I hit Enter a few times on the final > > string, I was disappointed when I found backspace made the > > search go to the top of the page again. To me it felt like it > > should've been relative to where I found myself the last time > > I hit enter. I don't make much use of anything with incremental > > search, though, so I don't know what the standard behavior is. > > Though I think the current behaviour is consistent, I understand > your concern. Firefox never goes back when you shorten the > search string even if you have not yet hit enter. But I think that's > bad if you just mistyped the search string and want to correct it. That's true. I guess it just caught me by surprise.

Nov. 16, 2007

patch: text search

by Johannes.Hofmann＠gmx.de

On Fri, Nov 16, 2007 at 08:12:17PM +0000, place wrote: > Johannes wrote: > > On Fri, Nov 16, 2007 at 07:10:48PM +0000, place wrote: > > > Johannes wrote: > > > > Very nice! I was text search a lot. > > > > What about incremental searching as you type? > > > > I don't mind the title bar... > > > > > > Hmm... I'd have to modify findtext.cc some... > > > I may get around to it at some point here, though I'm > > > feeling the need to look into what's going on with > > > redirection and gzip, so if anybody else gets there > > > first, it'll be fine with me! :) > > > > I was thinking about something like: > > > > > > diff -r f18e37a8e3ac src/dialog.cc > > --- a/src/dialog.cc Fri Nov 16 20:25:11 2007 +0100 > > +++ b/src/dialog.cc Fri Nov 16 20:27:18 2007 +0100 > > @@ -141,14 +141,6 @@ static void findtext_search_cb(Widget *, > > const char *key = tf->i->value(); > > bool case_sens = tf->cb->value(); > > > > - /* > > - * Somehow fltk even regards the first loss of focus for the > > - * window as a WHEN_ENTER_KEY_ALWAYS event. > > - */ > > - int e = event_key(); > > - if ((e != ReturnKey) && (e != LeftButton)) > > - return; > > - > > if (key[0] != '\0') > > a_UIcmd_findtext_search(tf->bw, key, case_sens); > > > > @@ -176,7 +168,7 @@ TextFinder::TextFinder(int ww, int wh, B > > > > begin(); > > i = new Input(0, 0, ww, ih); > > - i->when(WHEN_ENTER_KEY_ALWAYS); > > + i->when(WHEN_CHANGED); > > i->callback(findtext_search_cb, this); > > > > cb = new CheckButton(0, ih, ww, wh-ih-bh, "Case-sensitive"); > > > > > > on top of your patch of course. Works for me. > > I had tried that before replying earlier, and I was happy at > first, but then after I hit Enter a few times on the final > string, I was disappointed when I found backspace made the > search go to the top of the page again. To me it felt like it > should've been relative to where I found myself the last time > I hit enter. I don't make much use of anything with incremental > search, though, so I don't know what the standard behavior is. Though I think the current behaviour is consistent, I understand your concern. Firefox never goes back when you shorten the search string even if you have not yet hit enter. But I think that's bad if you just mistyped the search string and want to correct it. Johannes > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 16, 2007

patch: text search

by place＠gobigwest.com

Johannes wrote: > On Fri, Nov 16, 2007 at 07:10:48PM +0000, place wrote: > > Johannes wrote: > > > Very nice! I was text search a lot. > > > What about incremental searching as you type? > > > I don't mind the title bar... > > > > Hmm... I'd have to modify findtext.cc some... > > I may get around to it at some point here, though I'm > > feeling the need to look into what's going on with > > redirection and gzip, so if anybody else gets there > > first, it'll be fine with me! :) > > I was thinking about something like: > > > diff -r f18e37a8e3ac src/dialog.cc > --- a/src/dialog.cc Fri Nov 16 20:25:11 2007 +0100 > +++ b/src/dialog.cc Fri Nov 16 20:27:18 2007 +0100 > @@ -141,14 +141,6 @@ static void findtext_search_cb(Widget *, > const char *key = tf->i->value(); > bool case_sens = tf->cb->value(); > > - /* > - * Somehow fltk even regards the first loss of focus for the > - * window as a WHEN_ENTER_KEY_ALWAYS event. > - */ > - int e = event_key(); > - if ((e != ReturnKey) && (e != LeftButton)) > - return; > - > if (key[0] != '\0') > a_UIcmd_findtext_search(tf->bw, key, case_sens); > > @@ -176,7 +168,7 @@ TextFinder::TextFinder(int ww, int wh, B > > begin(); > i = new Input(0, 0, ww, ih); > - i->when(WHEN_ENTER_KEY_ALWAYS); > + i->when(WHEN_CHANGED); > i->callback(findtext_search_cb, this); > > cb = new CheckButton(0, ih, ww, wh-ih-bh, "Case-sensitive"); > > > on top of your patch of course. Works for me. I had tried that before replying earlier, and I was happy at first, but then after I hit Enter a few times on the final string, I was disappointed when I found backspace made the search go to the top of the page again. To me it felt like it should've been relative to where I found myself the last time I hit enter. I don't make much use of anything with incremental search, though, so I don't know what the standard behavior is.

Nov. 16, 2007

patch: text search

by Johannes.Hofmann＠gmx.de

On Fri, Nov 16, 2007 at 07:10:48PM +0000, place wrote: > Johannes wrote: > > Very nice! I was text search a lot. > > What about incremental searching as you type? > > I don't mind the title bar... > > Hmm... I'd have to modify findtext.cc some... > I may get around to it at some point here, though I'm > feeling the need to look into what's going on with > redirection and gzip, so if anybody else gets there > first, it'll be fine with me! :) I was thinking about something like: diff -r f18e37a8e3ac src/dialog.cc --- a/src/dialog.cc Fri Nov 16 20:25:11 2007 +0100 +++ b/src/dialog.cc Fri Nov 16 20:27:18 2007 +0100 @@ -141,14 +141,6 @@ static void findtext_search_cb(Widget *, const char *key = tf->i->value(); bool case_sens = tf->cb->value(); - /* - * Somehow fltk even regards the first loss of focus for the - * window as a WHEN_ENTER_KEY_ALWAYS event. - */ - int e = event_key(); - if ((e != ReturnKey) && (e != LeftButton)) - return; - if (key[0] != '\0') a_UIcmd_findtext_search(tf->bw, key, case_sens); @@ -176,7 +168,7 @@ TextFinder::TextFinder(int ww, int wh, B begin(); i = new Input(0, 0, ww, ih); - i->when(WHEN_ENTER_KEY_ALWAYS); + i->when(WHEN_CHANGED); i->callback(findtext_search_cb, this); cb = new CheckButton(0, ih, ww, wh-ih-bh, "Case-sensitive"); on top of your patch of course. Works for me. Cheers, Johannes

Nov. 16, 2007

patch: text search

by place＠gobigwest.com

Johannes wrote: > Very nice! I was text search a lot. > What about incremental searching as you type? > I don't mind the title bar... Hmm... I'd have to modify findtext.cc some... I may get around to it at some point here, though I'm feeling the need to look into what's going on with redirection and gzip, so if anybody else gets there first, it'll be fine with me! :) If nothing else, it would be nice to change the behavior so that changing the search key doesn't restart the search from the top of the document.

Nov. 16, 2007

patch: text search

by Johannes.Hofmann＠gmx.de

Very nice! I was text search a lot. What about incremental searching as you type? I don't mind the title bar... Cheers, Johannes 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. > > - 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... > > diff -pur dillo2/src/dialog.cc dillo2-cur/src/dialog.cc > --- dillo2/src/dialog.cc 2007-11-07 05:03:53.000000000 +0000 > +++ dillo2-cur/src/dialog.cc 2007-11-16 03:30:20.000000000 +0000 > @@ -11,22 +11,26 @@ > > // UI dialogs > > +#include <fltk/events.h> // for the unfortunate (temporary?) event key testing > #include <fltk/Window.h> > #include <fltk/ask.h> > #include <fltk/file_chooser.h> > #include <fltk/TextBuffer.h> > +#include <fltk/Input.h> > +#include <fltk/CheckButton.h> > #include <fltk/ReturnButton.h> > #include <fltk/TextDisplay.h> > > #include "dialog.hh" > #include "misc.h" > +#include "uicmd.hh" > > using namespace fltk; > > /* > - * Callback for the text window dialog. > + * Close dialog window. > */ > -void text_window_cb(Widget *, void *vwin) > +static void window_close_cb(Widget *, void *vwin) > { > Window *window = (Window*)vwin; > > @@ -107,10 +111,91 @@ void a_Dialog_text_window(const char *tx > td->buffer(text_buf); > > ReturnButton *b = new ReturnButton (0, wh-bh, ww, bh, "Close"); > - b->callback(text_window_cb, window); > + b->callback(window_close_cb, window); > > window->resizable(window); > window->end(); > window->show(); > } > > +/* > + * Dialog to find text in page. > + */ > +class TextFinder : public Window { > +public: > + TextFinder(int ww, int wh, BrowserWindow *bw); > + BrowserWindow *bw; > + Input *i; > + CheckButton *cb; > + ReturnButton *findb; > + Button *clrb; > + Button *clsb; > +}; > + > +/* > + * Find next occurrence of input key > + */ > +static void findtext_search_cb(Widget *, void *vtf) > +{ > + TextFinder *tf = (TextFinder *)vtf; > + const char *key = tf->i->value(); > + bool case_sens = tf->cb->value(); > + > + /* > + * Somehow fltk even regards the first loss of focus for the > + * window as a WHEN_ENTER_KEY_ALWAYS event. > + */ > + int e = event_key(); > + if ((e != ReturnKey) && (e != LeftButton)) > + return; > + > + if (key[0] != '\0') > + a_UIcmd_findtext_search(tf->bw, key, case_sens); > + > +} > + > +/* > + * Reset search state > + */ > +static void findtext_clear_cb(Widget *, void *vtf) > +{ > + TextFinder *tf = (TextFinder *)vtf; > + tf->i->value(""); > + a_UIcmd_findtext_reset(tf->bw); > +} > + > +/* > + * Construct text search window > + */ > +TextFinder::TextFinder(int ww, int wh, BrowserWindow *bw) : > + Window(ww, wh, "unwanted title") > +{ > + int button_width = 70, ih = 35, bh = 30, gap = 10; > + > + this->bw = bw; > + > + begin(); > + i = new Input(0, 0, ww, ih); > + i->when(WHEN_ENTER_KEY_ALWAYS); > + i->callback(findtext_search_cb, this); > + > + cb = new CheckButton(0, ih, ww, wh-ih-bh, "Case-sensitive"); > + > + findb = new ReturnButton(gap, wh-bh, button_width, bh, "Find"); > + findb->callback(findtext_search_cb, this); > + > + clrb = new Button(button_width+2*gap, wh-bh, button_width, bh, "Clear"); > + clrb->callback(findtext_clear_cb, this); > + > + clsb = new Button(2*button_width+3*gap, wh-bh, button_width, bh, "Close"); > + clsb->callback(window_close_cb, this); > + end(); > + > + hotspot(i); // place input widget beneath the cursor > +} > + > +void a_Dialog_findtext(BrowserWindow *bw) > +{ > + TextFinder *tf = new TextFinder(250, 90, bw); > + tf->show(); > +} > diff -pur dillo2/src/dialog.hh dillo2-cur/src/dialog.hh > --- dillo2/src/dialog.hh 2007-11-08 19:50:20.000000000 +0000 > +++ dillo2-cur/src/dialog.hh 2007-11-16 03:00:01.000000000 +0000 > @@ -1,6 +1,8 @@ > #ifndef __DIALOG_HH__ > #define __DIALOG_HH__ > > +#include "bw.h" > + > #ifdef __cplusplus > extern "C" { > #endif /* __cplusplus */ > @@ -14,7 +16,7 @@ const char *a_Dialog_save_file(const cha > char *a_Dialog_open_file(const char *msg, > const char *pattern, const char *fname); > void a_Dialog_text_window(const char *txt, const char *title); > - > +void a_Dialog_findtext(BrowserWindow *bw); > > #ifdef __cplusplus > } > diff -pur dillo2/src/menu.cc dillo2-cur/src/menu.cc > --- dillo2/src/menu.cc 2007-11-14 22:07:49.000000000 +0000 > +++ dillo2-cur/src/menu.cc 2007-11-16 02:09:24.000000000 +0000 > @@ -115,7 +115,8 @@ static void Menu_add_bookmark_cb(Widget* > */ > static void Menu_find_text_cb(Widget* ) > { > - a_UIcmd_fullscreen_toggle(popup_bw); > +// a_UIcmd_fullscreen_toggle(popup_bw); > + a_UIcmd_findtext_dialog(popup_bw); > } > > /* > diff -pur dillo2/src/uicmd.cc dillo2-cur/src/uicmd.cc > --- dillo2/src/uicmd.cc 2007-11-14 22:07:49.000000000 +0000 > +++ dillo2-cur/src/uicmd.cc 2007-11-16 03:03:19.000000000 +0000 > @@ -696,3 +696,43 @@ void a_UIcmd_fullscreen_toggle(BrowserWi > BW2UI(bw)->fullscreen_toggle(); > } > > +/* > + * Open the text search dialog. > + */ > +void a_UIcmd_findtext_dialog(BrowserWindow *bw) > +{ > + a_Dialog_findtext(bw); > +} > + > +/* > + * Search for next occurrence of key. > + */ > +void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens) > +{ > + Layout *l = (Layout *)bw->render_layout; > + > + switch (l->search(key, case_sens)) { > + case FindtextState::RESTART: > + a_UIcmd_set_msg(bw, "No further occurrences of \"%s\". " > + "Restarting from the top.", key); > + break; > + case FindtextState::NOT_FOUND: > + a_UIcmd_set_msg(bw, "\"%s\" not found.", key); > + break; > + case FindtextState::SUCCESS: > + default: > + a_UIcmd_set_msg(bw, ""); > + } > +} > + > +/* > + * Reset text search state. > + */ > +void a_UIcmd_findtext_reset(BrowserWindow *bw) > +{ > + Layout *l = (Layout *)bw->render_layout; > + l->resetSearch(); > + > + a_UIcmd_set_msg(bw, ""); > +} > + > diff -pur dillo2/src/uicmd.hh dillo2-cur/src/uicmd.hh > --- dillo2/src/uicmd.hh 2007-11-14 22:07:49.000000000 +0000 > +++ dillo2-cur/src/uicmd.hh 2007-11-16 02:37:32.000000000 +0000 > @@ -27,6 +27,9 @@ void a_UIcmd_search_dialog(void *vbw); > void a_UIcmd_book(void *vbw); > void a_UIcmd_add_bookmark(BrowserWindow *bw, const DilloUrl *url); > void a_UIcmd_fullscreen_toggle(BrowserWindow *bw); > +void a_UIcmd_findtext_dialog(BrowserWindow *bw); > +void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens); > +void a_UIcmd_findtext_reset(BrowserWindow *bw); > void a_UIcmd_page_popup(void *vbw, const DilloUrl *url, > const char *bugs_txt, int prefs_load_images); > void a_UIcmd_link_popup(void *vbw, const DilloUrl *url); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 16, 2007

[patch] avoid complete redraws for child widget updates

by Johannes.Hofmann＠gmx.de

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

Nov. 16, 2007

[PATCH]: fix occasional segfault in dw::Table::reallocChildren

by onepoint＠starurchin.org

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">

Nov. 16, 2007

patch: text search

by place＠gobigwest.com

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...

Nov. 16, 2007

[patch] delete the phantom widgets

by Johannes.Hofmann＠gmx.de

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);

Nov. 15, 2007

Re: patch: base url page menu

by place＠gobigwest.com

Jorge wrote: > The "Load images" via page menu patch was committed. Are you seeing the menus popping up with the load images option under the pointer? What I get looks suspiciously like the previous option clicked plus the height of the control panel. *resizes control panel* Yes, _very_ suspiciously.

Nov. 15, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

On Wed, Nov 14, 2007 at 07:55:03PM +0000, place wrote: > Now that I'm on gcc4, let's get rid of the embarrassing signedness warnings: Committed. -- Cheers Jorge.-

Nov. 14, 2007

Re: patch: base url page menu

by jcid＠dillo.org

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.-

Nov. 14, 2007

Re: Accept-Encoding: gzip

by place＠gobigwest.com

Now that I'm on gcc4, let's get rid of the embarrassing signedness warnings: diff -pur dillo2/src/decode.c dillo2-cur/src/decode.c --- dillo2/src/decode.c 2007-11-14 11:40:05.000000000 +0000 +++ dillo2-cur/src/decode.c 2007-11-14 19:40:29.000000000 +0000 @@ -32,10 +32,10 @@ static Dstr *Decode_gzip(Decode *dc, con Dstr *output = dStr_new(""); while ((rc == Z_OK) && (inputConsumed < inLen)) { - zs->next_in = (char *)inData + inputConsumed; + zs->next_in = (Bytef *)inData + inputConsumed; zs->avail_in = inLen - inputConsumed; - zs->next_out = dc->buffer; + zs->next_out = (Bytef *)dc->buffer; zs->avail_out = bufsize; rc = inflate(zs, Z_SYNC_FLUSH); @@ -69,7 +69,7 @@ static Dstr *Decode_charset(Decode *dc, Dstr *input, *output; char *inPtr, *outPtr; - int inLeft, outRoom; + size_t inLeft, outRoom; output = dStr_new("");

Nov. 14, 2007

Re: patch: TransferSize

by jcid＠dillo.org

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.-

Nov. 14, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

On Tue, Nov 13, 2007 at 09:10:08PM +0100, Johannes Hofmann wrote: > On Tue, Nov 13, 2007 at 11:11:29AM -0300, Jorge Arellano Cid wrote: > > 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. > > Is decode.h perhaps missing in cvs? Ooops! Yes, sorry... Committed both: decode.[ch] -- Cheers Jorge.-

Nov. 14, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

On Mon, Nov 12, 2007 at 04:13:49PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote: > > > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > > > > Hi, > > > > > > > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > > > > [...] > > > > > > > As a side effect of flickering, I noticed several times how some > > > > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > > > > > > > [...] > > > > > > > > > > > > For instance, enable flickering (disable double-buffer and > > > > > > internal buffer), then go to: > > > > > > > > > > > > 1. www.google.com //and then to > > > > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > > > > > > > While loading the second URL you'll see the phantom-rendering > > > > > > of the text input and the two buttons that google uses. > > > > > > > > > > > > > > > Although now we have memory-freeing hooked, the phantom > > > > > rendering still occurs... > > > > > > > > Yes, maybe it has to do with how dillo widgets must be deleted. > > > > There was recently a discussion about this in the fltk forums. > > > > I will try to figure out what happens. But at the moment I get > > > > various sorts of crashes with this patch immediately when I load a > > > > page with forms. > > > > > > Here it doesn't crash, but it's sure the phantom widgets are referencing > > > freed memory (it get garbage labels). > > > > > > You can comment: > > > > > > dw->setDeleteCallback(a_Html_free, this); > > > > > > and test as it was before the patch (with no memory freeing). > > > > just a short update on this issue. There seems to be something more > > fundamentally wrong on my system. > > > > #include "../dlib.h" > > > > int main (char **argv, int argc) { > > Dstr *ds = dStr_new(""); > > > > dStr_sprintfa(ds, "Hello %s", "foo"); > > dStr_sprintfa(ds, "World %d", 42); > > } > > > > > > crashes here, but it runs fine on Linux and even valgrind does not > > complain on Linux. > > If vsnprintf(), when called alone, works on your system, > try adding the extra: > > va_copy(argp2, argp); > > to dStr_sprintfa() as in dStr_vsprintfa(). > > Just an idea. Thanks, but I think the culprit is a weird bug when libc was compiled with a special gcc-version. Anyway, I now have a system again on which current dillo-fltk runs pretty stable. So I can now attack the phantom widgets - at least I will try :-) cheers, Johannes

Nov. 13, 2007

Re: Accept-Encoding: gzip

by Johannes.Hofmann＠gmx.de

On Tue, Nov 13, 2007 at 11:11:29AM -0300, Jorge Arellano Cid wrote: > 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. Is decode.h perhaps missing in cvs? cheers, Johannes

Nov. 13, 2007

Re: Accept-Encoding: gzip

by place＠gobigwest.com

Jorge wrote: > 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 Perhaps along these same lines, I did manage to break my image-loading code once when I clicked a few times on an image that wanted to redirect. I couldn't get it to crash again, though. > 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. You had mentioned once before that you wanted to keep the original in cache, and I agree completely.

Nov. 13, 2007

Re: is the visited_color pref somehow deprecated?

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 07:42:56PM +0000, place wrote: > Jorge 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! :-) > > I've had it set for weeks now, and it seems to work fine for me. > > Oh, speaking of colors, what do you consider to be the proper behavior > for buttons? My text color is set to white, so buttons have white > text on a nearly-white background. Should the button not use the text color, > or should the button background color be some sort of modification of the > page background color, or...? I haven't thought much of this. The idea was to apply a CSS stylesheet given by the user, but this may take a long while... Given that you are using a black background, you'll probably experience better what the problems are with this. If we need to provide a button_bg preference or similar, it's no problem. Just try to get them into a kind. For instance if the same color can be used for selection widgets and checkboxes, it could be "form_element_bg" instead. -- Cheers Jorge.-

Nov. 13, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

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.-

Nov. 13, 2007

forms related segfault

by jcid＠dillo.org

On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote: > > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > > > [...] > > > > > > As a side effect of flickering, I noticed several times how some > > > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > > > > > [...] > > > > > > > > > > For instance, enable flickering (disable double-buffer and > > > > > internal buffer), then go to: > > > > > > > > > > 1. www.google.com //and then to > > > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > > > > > While loading the second URL you'll see the phantom-rendering > > > > > of the text input and the two buttons that google uses. > > > > > > > > > > > > Although now we have memory-freeing hooked, the phantom > > > > rendering still occurs... > > > > > > Yes, maybe it has to do with how dillo widgets must be deleted. > > > There was recently a discussion about this in the fltk forums. > > > I will try to figure out what happens. But at the moment I get > > > various sorts of crashes with this patch immediately when I load a > > > page with forms. > > > > Here it doesn't crash, but it's sure the phantom widgets are referencing > > freed memory (it get garbage labels). > > > > You can comment: > > > > dw->setDeleteCallback(a_Html_free, this); > > > > and test as it was before the patch (with no memory freeing). > > just a short update on this issue. There seems to be something more > fundamentally wrong on my system. > > #include "../dlib.h" > > int main (char **argv, int argc) { > Dstr *ds = dStr_new(""); > > dStr_sprintfa(ds, "Hello %s", "foo"); > dStr_sprintfa(ds, "World %d", 42); > } > > > crashes here, but it runs fine on Linux and even valgrind does not > complain on Linux. If vsnprintf(), when called alone, works on your system, try adding the extra: va_copy(argp2, argp); to dStr_sprintfa() as in dStr_vsprintfa(). Just an idea. -- Cheers Jorge.-

Nov. 12, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Nov 11, 2007 at 03:58:43PM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 11, 2007 at 02:22:39PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > The big patch for html.cc getting rid of the linkblock and html > > > structures, merging them in a single class with link-receiver inside, > > > and also enabling freeing of the resources formerly stored in the > > > linkblock, is commited! :-) > > > > > > The amazing thing is that it seems to work. ;) > > > > Wow, that's a huge cleanup! > > Yes it was! 8-P > > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > > [...] > > > > > As a side effect of flickering, I noticed several times how some > > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > > > [...] > > > > > > > > For instance, enable flickering (disable double-buffer and > > > > internal buffer), then go to: > > > > > > > > 1. www.google.com //and then to > > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > > > While loading the second URL you'll see the phantom-rendering > > > > of the text input and the two buttons that google uses. > > > > > > > > > Although now we have memory-freeing hooked, the phantom > > > rendering still occurs... > > > > Yes, maybe it has to do with how dillo widgets must be deleted. > > There was recently a discussion about this in the fltk forums. > > I will try to figure out what happens. But at the moment I get > > various sorts of crashes with this patch immediately when I load a > > page with forms. > > Here it doesn't crash, but it's sure the phantom widgets are referencing > freed memory (it get garbage labels). > > You can comment: > > dw->setDeleteCallback(a_Html_free, this); > > and test as it was before the patch (with no memory freeing). just a short update on this issue. There seems to be something more fundamentally wrong on my system. #include "../dlib.h" int main (char **argv, int argc) { Dstr *ds = dStr_new(""); dStr_sprintfa(ds, "Hello %s", "foo"); dStr_sprintfa(ds, "World %d", 42); } crashes here, but it runs fine on Linux and even valgrind does not complain on Linux. Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 12, 2007

Re: image loading from menus

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 10:26:57PM +0000, place wrote: > > 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. > > I misremembered what you wrote and instead, like the void *vbw going into > a_UIcmd_*_popup(), gave it a void *vpage. Seems to be working and loading > images. Do you think there'd be a good reason to put the html pointer inside > the bw anyway? Yes. It may be useful for handling frames (having access to the DilloHtml object of each URL), or for hooking a menu into a plain image URL (e.g. zoom). > PS The fact that page url != base_url means that various items on the page > menu do not work if a base url is specified. I'll deal with that separately... Ok. -- Cheers Jorge.-

Nov. 12, 2007

Re: image loading from menus

by place＠gobigwest.com

> 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. I misremembered what you wrote and instead, like the void *vbw going into a_UIcmd_*_popup(), gave it a void *vpage. Seems to be working and loading images. Do you think there'd be a good reason to put the html pointer inside the bw anyway? PS The fact that page url != base_url means that various items on the page menu do not work if a base url is specified. I'll deal with that separately...

Nov. 11, 2007

Re: image loading from menus

by jcid＠dillo.org

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.-

Nov. 11, 2007

Re: is the visited_color pref somehow deprecated?

by place＠gobigwest.com

Jorge 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! :-) I've had it set for weeks now, and it seems to work fine for me. Oh, speaking of colors, what do you consider to be the proper behavior for buttons? My text color is set to white, so buttons have white text on a nearly-white background. Should the button not use the text color, or should the button background color be some sort of modification of the page background color, or...?

Nov. 11, 2007

forms related segfault

by jcid＠dillo.org

On Thu, Nov 08, 2007 at 07:01:40PM +0000, place wrote: > Johannes wrote: > > 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: > > > It might not be the same problem, and I don't know whether it's > a reasonable fix, but I used to have a lot of trouble with forms crashing > until I did the following: > > > diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc > --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 > +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 > @@ -40,6 +40,7 @@ > #include <fltk/Symbol.h> > #include <fltk/Item.h> > #include <fltk/ItemGroup.h> > +#include <fltk/events.h> > > namespace dw { > namespace fltk { > @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( > void *data) > { > printf ("when = %d\n", widget->when ()); > - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) > + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && > + (::fltk::event_key() == ::fltk::ReturnKey)) > ((FltkEntryResource*)data)->emitActivate (); > } I didn't remember why I made it long ago for ui.cc, fortunately some testing showed the reason. Patch committed with the following comment: /* The (::fltk::event_key() == ::fltk::ReturnKey) test * is necessary because WHEN_ENTER_KEY also includes * other events we're not interested in. For instance pressing * The Back or Forward, buttons, or the first click on a rendered * page. BUG: this must be investigated and reported to FLTK2 team */ -- Cheers Jorge.-

Nov. 11, 2007

forms related segfault

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 02:22:39PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > The big patch for html.cc getting rid of the linkblock and html > > structures, merging them in a single class with link-receiver inside, > > and also enabling freeing of the resources formerly stored in the > > linkblock, is commited! :-) > > > > The amazing thing is that it seems to work. ;) > > Wow, that's a huge cleanup! Yes it was! 8-P > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > [...] > > > > As a side effect of flickering, I noticed several times how some > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > [...] > > > > > > For instance, enable flickering (disable double-buffer and > > > internal buffer), then go to: > > > > > > 1. www.google.com //and then to > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > While loading the second URL you'll see the phantom-rendering > > > of the text input and the two buttons that google uses. > > > > > > Although now we have memory-freeing hooked, the phantom > > rendering still occurs... > > Yes, maybe it has to do with how dillo widgets must be deleted. > There was recently a discussion about this in the fltk forums. > I will try to figure out what happens. But at the moment I get > various sorts of crashes with this patch immediately when I load a > page with forms. Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels). You can comment: dw->setDeleteCallback(a_Html_free, this); and test as it was before the patch (with no memory freeing). -- Cheers Jorge.-

Nov. 11, 2007

Re: is the visited_color pref somehow deprecated?

by jcid＠dillo.org

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.-

Nov. 11, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote: > Hi, > > The big patch for html.cc getting rid of the linkblock and html > structures, merging them in a single class with link-receiver inside, > and also enabling freeing of the resources formerly stored in the > linkblock, is commited! :-) > > The amazing thing is that it seems to work. ;) Wow, that's a huge cleanup! > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > [...] > > > As a side effect of flickering, I noticed several times how some > > > non existent inputs (text entries and buttons) were phantom-rendered > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > [...] > > > > For instance, enable flickering (disable double-buffer and > > internal buffer), then go to: > > > > 1. www.google.com //and then to > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > While loading the second URL you'll see the phantom-rendering > > of the text input and the two buttons that google uses. > > > Although now we have memory-freeing hooked, the phantom > rendering still occurs... Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms. Here are two stacks, but I don't think they are very useful. Program received signal SIGBUS, Bus error. 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 493 if (!*p || *p == '\n') { (gdb) bt #0 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 #1 0x08097c74 in fltk::drawtext ( textfunction=0x80a3756 <fltk::drawtext_transformed(char const*, int, float, float)>, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>, str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff288, flags=262656) at drawtext.cxx:571 #2 0x08098296 in fltk::drawtext ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r1=@0xbfbff348, flags=262656) at drawtext.cxx:544 #3 0x080e38af in fltk::LabelType::draw (this=0x8127b14, label=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff348, flags=262656) at Widget_draw.cxx:58 #4 0x080e3575 in fltk::Widget::draw_label (this=0x2878ecc0, ir=@0xbfbff40c, flags=262656) at Widget_draw.cxx:234 #5 0x08094089 in fltk::Button::draw (this=0x2878ecc0, glyph_width=0) at Button.cxx:237 #6 0x080940df in fltk::Button::draw (this=0x2878ecc0) at Button.cxx:247 #7 0x080a4441 in fltk::Group::draw_child (this=0x284efc04, w=@0x2878ecc0) at Group.cxx:750 #8 0x080a4634 in fltk::Group::draw (this=0x284efc04) at Group.cxx:682 #9 0x0807ebad in dw::fltk::FltkViewBase::draw (this=0x284efc00) at fltkviewbase.cc:53 #10 0x0807c560 in dw::fltk::FltkViewport::draw_area (data=0x284efc00, cr=@0xbfbff5a0) at fltkviewport.cc:164 #11 0x0807c67f in dw::fltk::FltkViewport::draw (this=0x284efc00) at fltkviewport.cc:189 #12 0x080a4319 in fltk::Group::update_child (this=0x284f1c00, w=@0x284efc04) at Group.cxx:769 #13 0x080a46d6 in fltk::Group::draw (this=0x284f1c00) at Group.cxx:697 #14 0x080e4d14 in fltk::Window::draw (this=0x284f1c00) at Window.cxx:80 #15 0x080c228e in fltk::Window::flush (this=0x284f1c00) at run.cxx:2611 #16 0x080c1366 in fl_window_flush (window=0x284f1c00) at run.cxx:651 #17 0x080c13e6 in fltk::flush () at run.cxx:685 #18 0x080c7708 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:480 #19 0x080c7758 in fltk::run () at run.cxx:393 #20 0x0804e6d4 in main (argc=Error accessing memory address 0x40200: Bad address. ) at dillo.cc:107 dillo-fltk in realloc(): error: junk pointer, too high to make sense Program received signal SIGABRT, Aborted. 0x2838863c in kill () from /usr/lib/libc.so.6 (gdb) bt #0 0x2838863c in kill () from /usr/lib/libc.so.6 #1 0x283d6bc9 in abort () from /usr/lib/libc.so.6 #2 0x283a49a2 in reallocf () from /usr/lib/libc.so.6 #3 0x283a49d9 in reallocf () from /usr/lib/libc.so.6 #4 0x283a6420 in realloc () from /usr/lib/libc.so.6 #5 0x08068ad9 in dRealloc (mem=0xd0d0d0d0, size=676212922) at dlib.c:44 #6 0x08068d6d in dStr_resize (ds=0x284e3400, n_sz=676212922, keep=Variable "keep" is not available. ) at dlib.c:189 #7 0x08068db7 in dStr_vsprintfa (ds=0x284e3400, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n", argp=0xbfbfd348 "??????\005\bB\205\002") at dlib.c:361 #8 0x0805a5cc in Html_msg (html=0x28535b00, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n") at html.cc:176 #9 0x0805f8f2 in Html_write_raw (html=0x28535b00, buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., bufsize=1122, Eof=0) at html.cc:4645 #10 0x0805fac5 in DilloHtml::write (this=0x28535b00, Buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., BufSize=1122, Eof=0) at html.cc:649 #11 0x0805fb3e in Html_callback (Op=0, Client=0x28548900) at html.cc:4971 #12 0x08057032 in Cache_process_queue (entry=0x2853bda0) at cache.c:802 #13 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850cec0, Data1=0x28542d40, Data2=0x80f824e) at chain.c:86 #14 0x0806b1aa in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x2850cec0, Data1=0x28542ea0, Data2=0x0) at dpi.c:224 #15 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850c040, Data1=0x28542ea0, Data2=0x0) at chain.c:86 #16 0x0806b925 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x2850c040, Data1=0x285487a0, Data2=0x0) at IO.c:398 #17 0x0806bb26 in IO_callback (fd=Variable "fd" is not available. ) at IO.c:190 #18 0x0806bbf3 in IO_fd_read_cb (fd=6, data=0x4) at IO.c:269 #19 0x080c75a6 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #20 0x080c7641 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #21 0x080c7758 in fltk::run () at run.cxx:393 I will try to run in with valgrind when I have access to a Linux machine. Cheers, Johannes

Nov. 11, 2007

Re: patch: save filename/dir

by jcid＠dillo.org

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.-

Nov. 11, 2007

[patch] fix bug in new scrolling code

by jcid＠dillo.org

On Sat, Nov 10, 2007 at 10:51:29AM +0100, Johannes Hofmann wrote: > Hi, > > when scrolling using the down arrow key I saw occasionally > screen corruptions. The patch below fixes this for me. Committed. > 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 (;;); } "Unfortunately" my CFS-patched scheduler does a good job with this... :) -- Cheers Jorge.-

Nov. 10, 2007

forms related segfault

by jcid＠dillo.org

Hi, The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-) The amazing thing is that it seems to work. ;) On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > [...] > > As a side effect of flickering, I noticed several times how some > > non existent inputs (text entries and buttons) were phantom-rendered > > during updates (i.e. appeared on screen for a few jiffies). > > > > [...] > > For instance, enable flickering (disable double-buffer and > internal buffer), then go to: > > 1. www.google.com //and then to > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > While loading the second URL you'll see the phantom-rendering > of the text input and the two buttons that google uses. Although now we have memory-freeing hooked, the phantom rendering still occurs... > > Now, I thought this was to be deleted from the call in web.cc > (as a children of the top widget or something), but there's > another way to do it that looks like the original idea. Actually, it doesn't look like a good idea. What seems proper is that Dw internally deletes its widget tree, and DilloHtml deletes its non-dw state (as now). > In html parsing we have a structure called the linkblock. This > contains all the data that is needed after the page is parsed and > rendered (mainly forms data), and also dw widgets! > > In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's > a vector of DilloHtmlForm, which has a vector of DilloHtmlInput > which holds widgets. > > The linkblock is designed to be freed when the displayed dw is > deleted, but this hook is not currently operative! (this is the > warning you get at html.cc compile time about Html_lb_free not > being called). Well, now there's no linkblock, and everything is inside the DilloHtml class (much cleaner). Memory handling is hooked and it works. > Anyway, when the linkblock-free callback is hooked, those > widgets can be destroyed from Html_lb_free(). Which is mainly > implemented but not yet tested. My mistake: this part is for freeing non-dw data. What _seems_ to happen is that the "Embed" widgets are not being deleted (not yet confirmed though). Feel free to investigate! :-) -- Cheers Jorge.-

Nov. 10, 2007

[patch] fix bug in new scrolling code

by Johannes.Hofmann＠gmx.de

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;

Nov. 10, 2007

[patch] make partial redraw requests work

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 10:51:11PM +0100, Johannes Hofmann wrote: > Argh, forget about my last patch please. It was much too complicated. > fltk does all that for us! > The following looks much simpler, doesn't it :-) Yes! > Sorry for the confusion, It looked quite nice! ;-) Reverted and applied in CVS. -- Cheers Jorge.-

Nov. 10, 2007

[patch] make partial redraw requests work

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 08:22:41PM +0100, Johannes Hofmann wrote: > Hi, > > this patch adds set(), isEmpty(), and merge() methods to > core::Rectangle. > These methods are then used to maintain a rectangle that contains > all screen areas for which a redraw was requested. > When fltk really draws to the screen, the drawing is limited to this > area. > The most obvious improvement is visible on pages with very large > images that take some time to load. While the image is loaded the > rest of the page is no longer flickering - at least if there is no > other stuff that requests complete redraws. Committed! -- Cheers Jorge.-

Nov. 10, 2007

[patch] enable partial image drawing

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 08:14:47PM +0100, Johannes Hofmann wrote: > 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. Yes, I wrote that code, and it worked most of the time. It had problems when scrolling an image that was still loading. Now with the new scrolling it showed no problems in my quick tests. > I added some additional checks. With these checks I did not see any > negative effects. Commited. If somebody can test scrolling a downloading image over a slow line (e.g. phone) it'd be welcomed. -- Cheers Jorge.-

Nov. 9, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Argh, forget about my last patch please. It was much too complicated. fltk does all that for us! The following looks much simpler, doesn't it :-) --- a/dw/fltkviewbase.cc Wed Nov 07 22:39:38 2007 +0100 +++ b/dw/fltkviewbase.cc Fri Nov 09 22:40:14 2007 +0100 @@ -223,9 +223,13 @@ void FltkViewBase::finishDrawing (core:: void FltkViewBase::queueDraw (core::Rectangle *area) { - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + redraw(::fltk::Rectangle( + translateCanvasXToViewX(area->x), + translateCanvasYToViewY(area->y), + area->width, + area->height)); + } Sorry for the confusion, Johannes

Nov. 9, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

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.-

Nov. 9, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Hi, this patch adds set(), isEmpty(), and merge() methods to core::Rectangle. These methods are then used to maintain a rectangle that contains all screen areas for which a redraw was requested. When fltk really draws to the screen, the drawing is limited to this area. The most obvious improvement is visible on pages with very large images that take some time to load. While the image is loaded the rest of the page is no longer flickering - at least if there is no other stuff that requests complete redraws. Johannes diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -42,6 +42,7 @@ FltkViewBase::FltkViewBase (int x, int y canvasWidth = 1; canvasHeight = 1; bgColor = WHITE; + redrawArea.set (0, 0, 0, 0); } FltkViewBase::~FltkViewBase () @@ -50,9 +51,18 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { - Group::draw (); + int d = damage(); + ::fltk::Rectangle rect (x(), y(), w(), h()); - ::fltk::Rectangle rect (x(), y(), w(), h()); + //Group::draw (); + + if (d == DAMAGE_VALUE) { + ::fltk::push_clip( + translateCanvasXToViewX(redrawArea.x), + translateCanvasYToViewY(redrawArea.y), + redrawArea.width, + redrawArea.height); + } /* fltk-clipping seems not to use widget coordinates */ ::fltk::intersect_with_clip(rect); @@ -68,6 +78,12 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (d == DAMAGE_VALUE) { + ::fltk::pop_clip(); + } + + redrawArea.set (0, 0, 0, 0); } core::ButtonState getDwButtonState () @@ -223,9 +239,9 @@ void FltkViewBase::finishDrawing (core:: void FltkViewBase::queueDraw (core::Rectangle *area) { - /** \bug Inefficient */ + redrawArea.merge (area); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_VALUE); } void FltkViewBase::queueDrawTotal () diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -14,6 +14,7 @@ class FltkViewBase: public FltkView, pub { private: int bgColor; + core::Rectangle redrawArea; protected: core::Layout *theLayout; diff --git a/dw/types.cc b/dw/types.cc --- a/dw/types.cc +++ b/dw/types.cc @@ -27,10 +27,7 @@ namespace core { Rectangle::Rectangle (int x, int y, int width, int height) { - this->x = x; - this->y = y; - this->width = width; - this->height = height; + set (x, y, width, height); } /** @@ -111,6 +108,35 @@ bool Rectangle::isPointWithin (int x, in x >= this->x && y >= this->y && x < this->x + width && y < this->y + height; } + +/** + * \brief Enlarge the rectangle so that it also includes otherRect. + * If a rectangle has zero size, it is ignored. + */ +void Rectangle::merge (Rectangle *otherRect) +{ + if (otherRect->isEmpty()) { + return; + } + + if (isEmpty()) { + x = otherRect->x; + y = otherRect->y; + width = otherRect->width; + height = otherRect->height; + return; + } + + width = ::misc::max(x + width, otherRect->x + otherRect->width); + height = ::misc::max(y + height, otherRect->y + otherRect->height); + + x = ::misc::min(x, otherRect->x); + y = ::misc::min(y, otherRect->y); + + width -= x; + height -= y; +} + // ---------------------------------------------------------------------- diff --git a/dw/types.hh b/dw/types.hh --- a/dw/types.hh +++ b/dw/types.hh @@ -68,9 +68,18 @@ public: inline Rectangle () { } Rectangle (int x, int y, int width, int height); + void set (int x, int y, int w, int h) { + this->x = x; + this->y = y; + this->width = w; + this->height = h; + } + bool intersectsWith (Rectangle *otherRect, Rectangle *dest); + void merge (Rectangle *otherRect); bool isSubsetOf (Rectangle *otherRect); bool isPointWithin (int x, int y); + bool isEmpty() {return width == 0 && height == 0;}; }; /**

Nov. 9, 2007

[patch] enable partial image drawing

by Johannes.Hofmann＠gmx.de

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);

Nov. 9, 2007

forms related segfault

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 01:15:19PM +0000, place wrote: > > > [Jorge wrote] > > > BTW, I asked on the linkblock/callback patch, because if I look at it, > > > you can devote your time to gzip decoding. > > > > > [place wrote] > > > All right. > > > > :-) > > > > So maybe this means he's expecting me to do it. > > > > Place, would you mind confirm? > > Yes, I thought you were doing it... > > What I had meant about page url and base_url was that I'd started, screwed > it up badly, and happily scrapped it when I saw your message. Good. I'll make it ASAP then and let Johannes know so we can solve the forms problem too. -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by place＠gobigwest.com

> > [Jorge wrote] > > BTW, I asked on the linkblock/callback patch, because if I look at it, > > you can devote your time to gzip decoding. > > > [place wrote] > > All right. > > :-) > > So maybe this means he's expecting me to do it. > > Place, would you mind confirm? Yes, I thought you were doing it... What I had meant about page url and base_url was that I'd started, screwed it up badly, and happily scrapped it when I saw your message.

Nov. 9, 2007

forms related segfault

by jcid＠dillo.org

Hi, On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote: > > 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: > > Yes, it happens here too. > > > I think it has to do with the input form of the previous page > > somehow still being activ. > > Me too. > > As a side effect of flickering, I noticed several times how some > non existent inputs (text entries and buttons) were phantom-rendered > during updates (i.e. appeared on screen for a few jiffies). > > I'm investigating. More later. For instance, enable flickering (disable double-buffer and internal buffer), then go to: 1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses. Now, I thought this was to be deleted from the call in web.cc (as a children of the top widget or something), but there's another way to do it that looks like the original idea. In html parsing we have a structure called the linkblock. This contains all the data that is needed after the page is parsed and rendered (mainly forms data), and also dw widgets! In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's a vector of DilloHtmlForm, which has a vector of DilloHtmlInput which holds widgets. The linkblock is designed to be freed when the displayed dw is deleted, but this hook is not currently operative! (this is the warning you get at html.cc compile time about Html_lb_free not being called). A few days ago we were working on another issue with "place", and I made the necessary bindings for freeing the analog of DilloHtmlLB when parsing plain text. This is why when you leave a plain text page in dillo to render another one (anything) you'll see a message like this: a_Plain_free! 0x8177860 Now, making the binding for html.cc is not hard but takes some time and "place" is about to send it to me soon. But, maybe I understood it wrong: > [Jorge wrote] > BTW, I asked on the linkblock/callback patch, because if I look at it, > you can devote your time to gzip decoding. > [place wrote] > All right. :-) So maybe this means he's expecting me to do it. Place, would you mind confirm? Anyway, when the linkblock-free callback is hooked, those widgets can be destroyed from Html_lb_free(). Which is mainly implemented but not yet tested. Hope this helps. -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by jcid＠dillo.org

Hi, On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote: > 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: Yes, it happens here too. > > 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) > [...] > I think it has to do with the input form of the previous page > somehow still being activ. Me too. As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies). I'm investigating. More later. > Jorge, do you know what happens to the fltk widgets like buttons or > inputs, when a new page gets loaded? They should be deleted, but my guess is that they don't. > Are the deleted, and if so > where in the code does this happen? I should hapen from: a_Web_dispatch_by_type /* This method frees the old dw if any */ layout->setWidget(dw); -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by place＠gobigwest.com

Johannes wrote: > 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: It might not be the same problem, and I don't know whether it's a reasonable fix, but I used to have a lot of trouble with forms crashing until I did the following: diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 @@ -40,6 +40,7 @@ #include <fltk/Symbol.h> #include <fltk/Item.h> #include <fltk/ItemGroup.h> +#include <fltk/events.h> namespace dw { namespace fltk { @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( void *data) { printf ("when = %d\n", widget->when ()); - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && + (::fltk::event_key() == ::fltk::ReturnKey)) ((FltkEntryResource*)data)->emitActivate (); }

Nov. 8, 2007

fltk dead key problem

by matthias.franz＠ujf-grenoble.fr

On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > - 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. The following patch fixes this. (It's not against the latest version of fltk, but the relevant file hasn't changed since.) ### start patch ### --- fltk-2.0.x-r5917/src/compose.cxx 2006-06-25 08:11:31.000000000 +0200 +++ fltk-new/src/compose.cxx 2007-11-08 07:38:01.000000000 +0100 @@ -345,19 +345,8 @@ bool fltk::compose(int& del) { for (const char *p = compose_pairs; *p; p += 2) if (p[0] == ascii || p[1] == ascii) { compose_state = ascii; - // prefer the single-character versions: - if (p[1] == ' ') { - int code = (p-compose_pairs)/2+0xA0; - // convert code to utf8: - e_text = textbuffer; - textbuffer[0] = 0xc0 | code>>6; - textbuffer[1] = 0x80 | (code & 0x3f); - textbuffer[2] = 0; - plen = e_length = 2; - return true; - } + return true; } - if (compose_state != 1) return true; #if 0 // The right-hand ctrl and any letter "quotes" the control character: @@ -386,6 +375,24 @@ bool fltk::compose(int& del) { } } + // prefer the single-character versions: + if (ascii == ' ') { + e_text = textbuffer; + if (c1 & 0x80) { + // convert c1 to utf8: + textbuffer[0] = 0xc0 | c1>>6; + textbuffer[1] = 0x80 | (c1 & 0x3f); + textbuffer[2] = 0; + plen = e_length = 2; + } else { + textbuffer[0] = c1; + textbuffer[1] = 0; + plen = e_length = 1; + } + compose_state = 0; + return true; + } + } #if USE_X11 ### end patch ### > 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. I'm getting more and more convinced of this opinion. Why does one specify key mapping in XKB files if each application processes them on its own? BTW, I've noticed another bug in fltk compose key processing: I use the Windoze menu key for composing. Although it has the right keysym (0xff20), it is ignored, probably because it is also considered to be a META key, and these keys are handled by fltk in a special way. I'll send an email to fltk-bugs as well. Cheers, -- Matthias Franz

Nov. 8, 2007