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

Re: fullscreen/maximize question

by sgeerken＠dillo.org

Hi, On Sun, Nov 18, Johannes Hofmann wrote: > actually I would propose to use a PackedGroup and let fltk do > all the resizing/repositioning. I have attached a patch to dillo2 > and dw2 that does this. It's a bit radical, so I think it needs some > discussion before it can be applied :-) As an answer to this and an other mail (Johannes?): hiding scrollbars is actually intended, if they are not used. That is, e.g. a vertical scrollbar should be invisible, when the text is short enough, and this saved space should be used for the text. If the latter is not the case, this is actually a bug. (More on this later.) Sebastian

Nov. 20, 2007

Re: Cache_parse_header()

by jcid＠dillo.org

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

Nov. 20, 2007

patch: text search

by jcid＠dillo.org

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

Nov. 19, 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). > > - If you hit ^Q on this window or the page source or page > bugs windows, dillo will crash because it assumes it's > closing a bw. Already fixed. > - I didn't want a title bar, and I didn't want it to be able > to outlive its bw, but I didn't know what to do about it. > > - If searching scrolls the window, highlighting isn't undone > properly. (If you search for something like "a", the last > instance on each line will remain highlighted) Well, my idea was to make the Find-text widget similar to what Firefox has (a row above the status bar that appears on request). With Enter bound to "search next", Shift-Enter to "search prev" and a few buttons/widgets for the usual "case insensitive" option & friends. As it was taking too much time (and I didn't find a way to do it either with or without Johannes patch), I decided to commit the patch "as is", and not to delay anymore. The above-status-bar widget solves some problems, for instance: - the dialog window covering the highlighted word. - dependencies (as including uicmd.hh and bw.hh from dialog) It looks like the FltkViewport is not behaving as a native FLTK widget and that either some ad-hoc bindings are required, or to make it behave as native FLTK, at least for parent Group resizes. BTW, formerly "full screen" was bound to Ctrl-F (which is the shortcut for find text), now it's bound to Ctrl-Space. Why? Because I haven't found how to detect and handle the double-click event, cleanly from the UI. :-) Any help is appreciatted! :) -- Cheers Jorge.-

Nov. 19, 2007

[PATCH] improved image load button graphics

by jcid＠dillo.org

On Mon, Nov 19, 2007 at 08:31:08AM +0000, Jeremy Henty wrote: > On Sun, Nov 18, 2007 at 05:39:33PM +0000, place wrote: > > Jeremy wrote: > > > I thought that the graphics for the image load toggle button looked > > > rather scrappy, so I have made some new ones that I think are a little > > > smarter. > > > > Good, I was hoping that somebody would fix the ugly thing that I drew :) > > I glad to see my criticism was taken in good spirit. Mind you, Jorge > hasn't committed it yet, maybe he prefers it ugly? :) Committed. -- Cheers Jorge.-

Nov. 19, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Nov 18, 2007 at 11:37:45PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, Nov 18, 2007 at 10:50:59PM +0100, Johannes Hofmann wrote: > > Hi, > > > > actually I would propose to use a PackedGroup and let fltk do > > all the resizing/repositioning. I have attached a patch to dillo2 > > and dw2 that does this. It's a bit radical, so I think it needs some > > discussion before it can be applied :-) > > For me this is very good. I remember long ago coding the UI with > a less predictable FLTK2; once a way for it to work as desired was > found, that was it. > > If a simpler approach works today, great. > > It even solves some problems where current scrollbars don't appear. > If Sebastian agrees on having them this way, great (maybe there's a need > of finer control though, I don't know). The problem might be that the scrollbars are currently children of TopGroup and not of FltkViewport. They are created in the FltkViewport constructor but never added to the FltkViewport widget. Instead they get added to TopGroup (accidentally?) because of TopGroup->begin() in void set_render_layout_begin(). Is this intended? If yes, they would need to be replaced too. I really prefer direct calls to add() instead of this begin()/end() stuff. It makes things much clearer. Cheers, Johannes > > Sebastian? > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 19, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Hi Sebastian, this patch is obsolete, as fltk does all that for us: The void Widget::redraw(const Rectangle& r) method marks a rectangle for later redraw. See my followup mail for a much shorter patch that does the same thing. It's already in cvs. I will try to summarize how fltk handles redraws (as I have understood it so far): * Redraw requests from the program itself or from the outside (expose events) are accumulated by fltk and will result in a later call to the draw() methods of the various widgets. Information about what is to be drawn is passed via a bitmap that can be accessed using Widget::damage() and via the current clipping region. * A program can require redraws using void Widget::redraw(const Rectangle& r). In this case fltk ensures, that r will not be clipped during a subsequent draw(). * A program can require redraws using void Widget::redraw(uchar c). In this case fltk ensures, that at least the bits that are on in c will be turned on in the damage() bitmap during a subsequent draw(). This pretty simple mechanism is used by fltk code itself to avoid unnecessary redraws. Here are some examples: * The void Group::draw_child(Widget& w) method looks at the current clip region and returns immediately if w is clipped. * If a widget notices that it needs redrawing (e.g. a button that has been pushed) it will set a flag in its own damage() bitmap and then call redraw(DAMAGE_CHILD). If then at drawing time just the DAMAGE_CHILD bit is on in the global damage() bitmap, Group calls the draw() methods of all those child widgets that have indicated that they need a redraw in their on damage() bitmap. All other widgets will not redraw. * ScrollGroup uses the DAMAGE_SCROLL bit in damage() to indicate that a redraw is necessary because of a scroll movement. If this is the only bit in damage() at drawing time, an optimized aproach is used for redrawing: The part of the screen that was already visible before the scroll movement will be copied to the new position and only the rest is actually redrawn. Some of these methods are already used in the current cvs-version of dw2: * void FltkViewBase::draw () only calls theLayout->expose () for the not clipped area. * If just DAMAGE_CHILD is on in damage(), FltkViewBase::draw () lets Group::draw() draw those child widgets that have requested a redraw. * void FltkViewBase::queueDraw (core::Rectangle *area) uses void Widget::redraw(const Rectangle& r) to request redrawing only for a specific area. * void FltkViewport::draw () uses the same mechanism as ScrollGroup to optimize redraws that are necessary because of scroll movements. Cheers, Johannes On Sun, Nov 18, 2007 at 09:22:43PM +0100, Sebastian Geerken wrote: > Hi Johannes, > > I'm glad that someone is dealing with this problem. I'll write more > about it, here just some first remarks, after only taking a glance at > this and other patches. > > On Fri, Nov 09, 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. > > You may take a look at the old implementation (gtk-based, somewhere > in dw_viewport.c), combining the areas of different redraw requests > is already implemented there. Perhaps it is better to adopt the old > code, which has been working for a while. > > Some notes on the general problem. There are several cases when areas > are to be redrawn, I hope this list is complete: > > 1. to react on expose events, > 2. if a widget redraws itself, and > 3. when scrolling. > > Regarding the problem, how to restrict drawing to a minimum, case 1 > is probably neglectable, since the number of expose events is > mostly rather small (only when moving windows, changing there order > etc.). It seems that the following code: > > > + ::fltk::Rectangle rect (x(), y(), w(), h()); > > + if (d == DAMAGE_VALUE) { > > may be used to distinguish it from the critical cases 2 and 3. For > case 1, still the whole viewport is drawn, optimization should be > secondary. > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 19, 2007

[PATCH] improved image load button graphics

by onepoint＠starurchin.org

On Sun, Nov 18, 2007 at 05:39:33PM +0000, place wrote: > Jeremy wrote: > > I thought that the graphics for the image load toggle button looked > > rather scrappy, so I have made some new ones that I think are a little > > smarter. > > Good, I was hoping that somebody would fix the ugly thing that I drew :) I glad to see my criticism was taken in good spirit. Mind you, Jorge hasn't committed it yet, maybe he prefers it ugly? :) Jeremy Henty

Nov. 19, 2007

duplicate enter/leave notification

by place＠gobigwest.com

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

Nov. 19, 2007

Re: fullscreen/maximize question

by jcid＠dillo.org

Hi, On Sun, Nov 18, 2007 at 10:50:59PM +0100, Johannes Hofmann wrote: > Hi, > > actually I would propose to use a PackedGroup and let fltk do > all the resizing/repositioning. I have attached a patch to dillo2 > and dw2 that does this. It's a bit radical, so I think it needs some > discussion before it can be applied :-) For me this is very good. I remember long ago coding the UI with a less predictable FLTK2; once a way for it to work as desired was found, that was it. If a simpler approach works today, great. It even solves some problems where current scrollbars don't appear. If Sebastian agrees on having them this way, great (maybe there's a need of finer control though, I don't know). Sebastian? -- Cheers Jorge.-

Nov. 19, 2007