- Dillo-dev - lists.mailman3.com

DPI infrastructure patches (2nd try)

by darkspirit5000＠gmail.com

Skipped content of type multipart/alternative

Nov. 24, 2007

Re: (and the space bar) Re: horizontal scrolling

by jcid＠dillo.org

Hi, On Fri, Nov 23, 2007 at 04:13:36PM +0000, place wrote: > Certain pages would exit when I hit space, so that list > in UI::handle() needs ' ' as well. I guess it was unhandled > and eventually found its way into the close_window_cb. > > An example of a page that would do it: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-July/000829.html > Maybe it had to do with clicking on a PRE. I don't know. Fixed in CVS (AFAIS). > PS Following the topic of that page, do you have any interest in a User-Agent > string preference in dillo? I made one for myself, but managed to become very > confused when I temporarily pretended to be firefox and google started sending > me these big, broken pages. Took me a while to remember why it was suddenly > doing this... Yes, that's the problem. I don't use User-Agent spoofing, but if somebody finds some good use for it, why not. -- Cheers Jorge.-

Nov. 24, 2007

DPI infrastructure patches

by darkspirit5000＠gmail.com

Skipped content of type multipart/alternative

Nov. 24, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

On Tue, Nov 20, 2007 at 08:11:48PM +0100, Sebastian Geerken wrote: > 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. Yes, the hiding of the scrollbar when it is not needed is a feature. A very useful one :-) However I think view and layout should not care about scrollbars. Attached is a patch (a proof of concept only) that * moves scrollbar creation to ui.cc * uses a PackedGroup for TopGroup and lets this PackedGroup do the layout of Panel, Main, StatusBar _and_ the scrollbars. * a reference to the scrollbars is passed to FltkViewport so that it can adjust their sizes and hide()/show() them as needed. That way view and layout only need to be able to deal with size changes whether they are caused by the user that modifies the window size, or by TopGroup that rearranges things, because a scrollbar becomes visible or gets hidden. This would make all the scrollbar handling in layout unneccessary. But as I do not completely understand the current code for scrollbars in layout, I am probabely missing something... Johannes PS: As a side effect standard fltk replace() can be used again in UI::set_render_layout().

Nov. 21, 2007

[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

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

[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