- Dillo-dev - lists.mailman3.com

[PATCH] Ctrl-R reloads

by onepoint＠starurchin.org

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

Nov. 18, 2007

Re: patch: base url page menu

by place＠gobigwest.com

Jorge wrote: > 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". I'm wondering whether the image list should live in the bw or something. Now that we keep a list of images around, reload should be able to do a proper full reload...

Nov. 18, 2007

Re: space bar to page

by jcid＠dillo.org

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

Nov. 17, 2007

patch: text search

by jcid＠dillo.org

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). Good, I'm giving it a review. > - 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. Fixed in CVS. Funny how Ctrl+n from a search window produced a small dialog-sized 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... Checking patch now... -- Cheers Jorge.-

Nov. 17, 2007

Re: patch: base url page menu

by jcid＠dillo.org

On Wed, Nov 14, 2007 at 11:18:17PM +0000, place wrote: > 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. I'm experiencing the same as you. With the offset being exactly the panel height. No problem at all when the whole panel is hidden. It's possible to workaround by adding an offset inside the a_Menu_*_popup functions, but probably the proper solution is to get the event in window coordinates instead of viewport-based ones. AFAIU the popup offset is OK with pure-fltk2 widgets, so maybe there's a problem in how FLTK2 perceives the viewport or the panel... I haven't investigated further along these lines though... -- Cheers Jorge.-

Nov. 17, 2007

[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