- Dillo-dev - lists.mailman3.com

Who among you values standard_widget_colors? (was Re: [Dillo-dev] cut off word ends with italic fonts)

by corvid＠lavabit.com

Jorge encouraged me to add that preference in case anyone wanted it back when the, ahh, 'nonstandard' widget colors came along some months ago, but I have no idea whether anyone uses it.

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

Replying to myself: > On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann wrote: > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > Yes, this also works for the fltk2 tabs example, just add > > fltk::TabGroup::default_pager (fltk::PAGER_SHRINK); > > But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as > above, select tab4 and narrow the window then the text of "very long > tab text" appears at the other side of tab4 and obscures tab3! I'm sorry for being so negative. Thanks, Johannes, for confirming that it's a FLTK bug and finding a workaround. I would prefer the default pager if it worked because it gives a list of all tabs, but at the moment this bug makes the shrink pager far better. > Time for a visit to the FLTK bug tracker. I've raised reports for the redraw storm and tab text display issues: http://www.fltk.org/str.php?L2047 http://www.fltk.org/str.php?L2048 Regards, Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann wrote: > Yes, I can reproduce it with the tabs example from the fltk2 tarball > (after adding an w->clear_double_buffer() to see the redraws). Confirmed. > It seems to be related to the MenuTabPager that is used by default. > Switching to ShrinkTabPager solves the problem for me (see patch). Yes, this also works for the fltk2 tabs example, just add fltk::TabGroup::default_pager (fltk::PAGER_SHRINK); But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as above, select tab4 and narrow the window then the text of "very long tab text" appears at the other side of tab4 and obscures tab3! Time for a visit to the FLTK bug tracker. Regards, Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 03:12:46PM +0000, corvid wrote: > I begin to wonder how long it'll be before we end up on fltk 1.3. Me too. It seems to me that FLTK-2 is not stabilising within any reasonable time and the developers are now giving most of their effort to FLTK-1.3. (They're even devoting lots of time to <gasp> the documentation!!!) Does/will FLTK-1.3 have tabs? Regards, Jeremy Henty

Sept. 23, 2008

Redraw storms

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 03:12:46PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > > > Johannes wrote: > > > > > Yes, I can reproduce it with the tabs example from the fltk2 > > > > tarball (after adding an w->clear_double_buffer() to see the > > > > redraws). > > > > It seems to be related to the MenuTabPager that is used by default. > > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > > > And I like the new look :-) > > > > > > If I hold down ^N until it fills up completely with shrunken tabs, > > > fltk segfaults. > > > > > > > Here it busy loops :-( > > I begin to wonder how long it'll be before we end up on fltk 1.3. Looking at TabGroup.cxx it has a hard limit of 128 tabs :-( For the release, we could simply limit the number of tabs too. There is also a disturbing static array static int p[128]; that makes me wonder if we will run into trouble with multiple TabGroup widgets (one per window) but I might be wrong. Cheers, Johannes

Sept. 23, 2008

Redraw storms

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > > Johannes wrote: > > > Yes, I can reproduce it with the tabs example from the fltk2 > > > tarball (after adding an w->clear_double_buffer() to see the > > > redraws). > > > It seems to be related to the MenuTabPager that is used by default. > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > > And I like the new look :-) > > > > If I hold down ^N until it fills up completely with shrunken tabs, > > fltk segfaults. > > > > Here it busy loops :-( I begin to wonder how long it'll be before we end up on fltk 1.3.

Sept. 23, 2008

Redraw storms

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > Johannes wrote: > > On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > > > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > > > opening a new tab every movement of the mouse triggers a redraw. It > > > > doesn't seem to depend on the number of tabs. Usually it will go away > > > > eventually (just after a tab is closed). I upgraded to the latest > > > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > > > this? > > > > > > I saw something similar while developing it. When opening more > > > tabs than the horizontal space, a menu appears to the right. > > > It seldom happened that activating the menu started a "redraw > > > storm" (full CPU usage on mouse MOVE event). > > > > > > I "disappeared" somehow until now... > > > > > > Most probably this is a bug in FLTK2, but it would be good to > > > track it down. Discovering a way to reproduce it reliably would > > > be a big step forward. > > > > Yes, I can reproduce it with the tabs example from the fltk2 > > tarball (after adding an w->clear_double_buffer() to see the > > redraws). > > It seems to be related to the MenuTabPager that is used by default. > > Switching to ShrinkTabPager solves the problem for me (see patch). > > And I like the new look :-) > > If I hold down ^N until it fills up completely with shrunken tabs, > fltk segfaults. > Here it busy loops :-(

Sept. 23, 2008

Redraw storms

by corvid＠lavabit.com

Johannes wrote: > On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > > opening a new tab every movement of the mouse triggers a redraw. It > > > doesn't seem to depend on the number of tabs. Usually it will go away > > > eventually (just after a tab is closed). I upgraded to the latest > > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > > this? > > > > I saw something similar while developing it. When opening more > > tabs than the horizontal space, a menu appears to the right. > > It seldom happened that activating the menu started a "redraw > > storm" (full CPU usage on mouse MOVE event). > > > > I "disappeared" somehow until now... > > > > Most probably this is a bug in FLTK2, but it would be good to > > track it down. Discovering a way to reproduce it reliably would > > be a big step forward. > > Yes, I can reproduce it with the tabs example from the fltk2 > tarball (after adding an w->clear_double_buffer() to see the > redraws). > It seems to be related to the MenuTabPager that is used by default. > Switching to ShrinkTabPager solves the problem for me (see patch). > And I like the new look :-) If I hold down ^N until it fills up completely with shrunken tabs, fltk segfaults.

Sept. 23, 2008

release packaging

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080923 15:57]: > On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > > The dw package is an awkward case. I think we should bite the bullet > and either move it inside dillo2 or make it an independent package > that the user installs and have dillo2 find and use the installed dw > (and lose the dw-testbed symbolic link). > Sorry for this interruption but what is the reason dw exists? I never understood that. Thanks for your time, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Sept. 23, 2008

Redraw storms

by Johannes.Hofmann＠gmx.de

On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > opening a new tab every movement of the mouse triggers a redraw. It > > doesn't seem to depend on the number of tabs. Usually it will go away > > eventually (just after a tab is closed). I upgraded to the latest > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > this? > > I saw something similar while developing it. When opening more > tabs than the horizontal space, a menu appears to the right. > It seldom happened that activating the menu started a "redraw > storm" (full CPU usage on mouse MOVE event). > > I "disappeared" somehow until now... > > Most probably this is a bug in FLTK2, but it would be good to > track it down. Discovering a way to reproduce it reliably would > be a big step forward. Yes, I can reproduce it with the tabs example from the fltk2 tarball (after adding an w->clear_double_buffer() to see the redraws). It seems to be related to the MenuTabPager that is used by default. Switching to ShrinkTabPager solves the problem for me (see patch). And I like the new look :-) Cheers, Johannes

Sept. 23, 2008