- Dillo-dev - lists.mailman3.com

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Ooops test program was missing in my last mail. Here it comes: #include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk; Widget *test; class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {}; void draw() { Rectangle rect(x(), y(), w(), h()); intersect_with_clip(rect); fprintf(stderr, "damage 0x%x clip %d %d %d %d\n", damage(), rect.x(), rect.y(), rect.w(), rect.h()); } }; void button_cb() { test->redraw(DAMAGE_SCROLL); test->redraw(Rectangle(10, 10, 10, 10)); } int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); Button *b = new Button(0, 0, 60, 30, "redraw"); b->callback((Callback*) button_cb); window->end(); window->show(argc, argv); return run(); }

Nov. 21, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

On Tue, Nov 20, 2007 at 08:11:35PM +0100, Sebastian Geerken wrote: > On Mon, Nov 19, Johannes Hofmann wrote: > > 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 is actually a bit more complicated, as I remember. Indeed. fltk2 tries to be smarter here than fltk1 was. Not sure yet whether this is good or bad. The attached test program shows how in fltk2 a redraw(<flag>) and a redraw(<rectangle>) results in two separate drawing operations with different damage flags and clip rectangles set. > A widget > redraw is referred in canvas coordinates, but FLTK referres to > viewport coordinates. I once described this in a mail (unfortunately > not in the code), which I cannot find now, so here again an example: > > 1. A widget requests a redraw for the canvas region > (100, 100, 100 x 100) [x, y, w x h]. If the viewport position > is at (50, 50), this is translated to (50, 50, 100 x 100). > > Notice, that the drawing is not done immediately at this time. > > 2. The viewport is scrolled to (50, 100) (i.e. scrolled down 50px). > > 3. Now, the idle function is activated, and draws the region > (50, 50, 100 x 100). This is, since the viewport position has > changed, the canvas region (100, 150, 100 x 100). This means, > that the upper half of the originally requestet *canvas* > region is not drawn (it has been scrolled out of the original > viewport region, so to speak). > > So, Dw (or the FLTK part of Dw) has to do some work on its own. See > Dw_gtk_viewport_queue_draw in dw_gtk_viewport.c (old code) for > details. Do you think this is worth the effort? Why not just do a complete redraw whenever a partial redraw request and a scroll movement collide and must be dealt with within a single draw operation? Alternatively we could store the region that needs redraw separately in canvas coordinates and do the translation to viewport coordinates at draw time. No problem, but more complex code. Johannes > > I'm not currently aware of all implications of it, I'll have to take > another deeper look at the old code. > > Sebastian > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 21, 2007

Re: patch: images: working menu, deferred loading; page menu works

by place＠gobigwest.com

Jorge wrote: > Yes, a place holder is the next step (sometimes image size is > provided as attributes in the IMG element, some others not; in > which case we can use a standard size). I made an image placeholder in place of a placeholder image... I'm not sure whether I offer this in jest or in earnest, but it's simple, anyway. And suffices for me.

Nov. 21, 2007

Scrolling patch!

by jcid＠dillo.org

Hi, On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > On Mon, Oct 22, 2007 at 07:12:28PM -0300, Jorge Arellano Cid wrote: > > Hi > > > > I see this in two parts: > > > > 1.- Remembering the scroll position in each bw's nav_stack > > 2.- Making fragments push a new page (and not just jump like now). > > > > Number 1.- is cooking here... :-) > > Number 1.- is commited! Number 2.- is committed! -- Cheers Jorge.-

Nov. 21, 2007

[patch] make partial redraw requests work

by sgeerken＠dillo.org

On Mon, Nov 19, Johannes Hofmann wrote: > 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 is actually a bit more complicated, as I remember. A widget redraw is referred in canvas coordinates, but FLTK referres to viewport coordinates. I once described this in a mail (unfortunately not in the code), which I cannot find now, so here again an example: 1. A widget requests a redraw for the canvas region (100, 100, 100 x 100) [x, y, w x h]. If the viewport position is at (50, 50), this is translated to (50, 50, 100 x 100). Notice, that the drawing is not done immediately at this time. 2. The viewport is scrolled to (50, 100) (i.e. scrolled down 50px). 3. Now, the idle function is activated, and draws the region (50, 50, 100 x 100). This is, since the viewport position has changed, the canvas region (100, 150, 100 x 100). This means, that the upper half of the originally requestet *canvas* region is not drawn (it has been scrolled out of the original viewport region, so to speak). So, Dw (or the FLTK part of Dw) has to do some work on its own. See Dw_gtk_viewport_queue_draw in dw_gtk_viewport.c (old code) for details. I'm not currently aware of all implications of it, I'll have to take another deeper look at the old code. Sebastian

Nov. 20, 2007

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