- Dillo-dev - lists.mailman3.com

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

release packaging

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > Currently you need to download three tarballs to compile dillo > (fltk,dw,dillo). I doubt that any linux distribution has fltk2 > packages at the moment. (and also not openembedded) What's the plan > about that? FLTK2's API is still not frozen, and its ABI does change quite often so we will have to supply the tarball ourselves. It would be simplest just to keep a copy of the right FLTK2 snapshot on the dillo site under a link saying "use *this* version". The problem is not that distros won't supply packages, the problem is that they *will* and it might be the wrong version. (Expect "I upgraded FLTK2 and Dillo crashed" reports!) 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). Thoughts? Regards, Jeremy Henty

Sept. 23, 2008

release packaging

by bf2006a＠yahoo.com

--- On Tue, 9/23/08, Andreas Kemnade <akemnade(a)tzi.de> wrote: > Currently you need to download three tarballs to compile > dillo (fltk,dw,dillo). > I doubt that any linux distribution has fltk2 packages at > the moment. > (and also not openembedded) > What's the plan about that? Make one big tarball of > everything > (with some selected fltk snapshot) or do you expect the > distributions > to include a fltk2 package as soon as they see dillo-fltk? fltk2 has been in both FreeBSD Ports: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/fltk2/ (but unfortunately you won't be able to view that with dillo2: "HTTP warning: Content-Type 'text/html' doesn't match the real data." -- fixes?) and NetBSD pkgsrc: http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/fltk2/README.html for some time. I don't see it in Debian's package system or Gentoo portage at the moment, although I'm sure that they, and the other large packaging systems, would add it if asked. I'd prefer to see a separate, smaller tarball containing just dw2 and dillo2, unless fltk2 begins changing more rapidly than the other components, and repeatedly breaks builds or causes the browser to malfunction, in which case it would make sense to bundle a fltk2 snapshot that is known to work with dillo. Regards, b.

Sept. 23, 2008

Redraw storms: the trigger

by onepoint＠starurchin.org

I think the redraw storms start whenever the main window is resized horizontally and there are too many tabs to fit in the horizontal space (so that the tab menu button has appeared). Vertical resizes do not cause the problem. It is also safe to resize horizontally or vertically before the tab menu button appears. Once the storm has started it stops whenever the tab menu button disappears, whether this is due to closing some tabs or widening the window. The storm starts again whenever the tab menu button reappears, whether or not there has been any more resizing. Do other people see this? Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > 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). Yes, this is exactly what I'm seeing. Once the redraw storm starts you can stop it by closing tabs or widening the window until all the tabs fit into the horizontal space. But there's got to be more to it than that because the menu usually works OK. Also, sometimes the contents of the tabs stop resizing with the main window once redraw storm starts. Not always, though. Regards, Jeremy Henty

Sept. 23, 2008

release packaging

by akemnade＠tzi.de

Hi, I have a question about release packaging: Currently you need to download three tarballs to compile dillo (fltk,dw,dillo). I doubt that any linux distribution has fltk2 packages at the moment. (and also not openembedded) What's the plan about that? Make one big tarball of everything (with some selected fltk snapshot) or do you expect the distributions to include a fltk2 package as soon as they see dillo-fltk? The question came to during thinking how to make bitbake files for openembedded. Regards, ndreas Kemnade

Sept. 23, 2008

source window's reluctance to show end of file

by corvid＠lavabit.com

Jorge wrote: > On Mon, Sep 22, 2008 at 04:00:59PM +0000, corvid wrote: > > I've been assuming all along that everyone sees this problem, > > but then I don't think anyone has ever mentioned it, so I > > wonder whether it only shows up on my slow machine. > > > > Thus far it's always been easier for me to resize the > > window -- thereby causing whatever refiguring is > > necessary -- than to dig through TextDisplay to find > > out what goes wrong when line numbers are turned on. > > Yes, I've noticed this and use the same trick to get to the page > bottom! ;) > > Most probably a bug in fltk::TextDisplay. > > It also makes me think of making "View source" display from within > dillo as modified plain text (line numbers + text lines) to get > "find text" for free as we discussed some time ago. > > Unfortunately now the priority is with Tabs and the near release. Playing around without too much of an idea of what I'm doing, I find that sticking a td->relayout(LAYOUT_WH); after the line number calculations seems to make the problem go away, so if (as seems overwhelmingly likely) we don't have a nice solution by release, we could do something like that as a workaround.

Sept. 22, 2008

Redraw storms

by onepoint＠starurchin.org

On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > Most probably this is a bug in FLTK2, That's what I thought so I upgraded FLTK2 to see if that helped. It didn't. :-( > Discovering a way to reproduce it reliably would be a big step > forward. I'll post anything I find. I also noticed that once the redraw storm started it could happen even if the current tab was static but some of the other hidden tabs were still loading. Regards, Jeremy Henty

Sept. 22, 2008

source window's reluctance to show end of file

by jcid＠dillo.org

On Mon, Sep 22, 2008 at 04:00:59PM +0000, corvid wrote: > I've been assuming all along that everyone sees this problem, > but then I don't think anyone has ever mentioned it, so I > wonder whether it only shows up on my slow machine. > > Thus far it's always been easier for me to resize the > window -- thereby causing whatever refiguring is > necessary -- than to dig through TextDisplay to find > out what goes wrong when line numbers are turned on. Yes, I've noticed this and use the same trick to get to the page bottom! ;) Most probably a bug in fltk::TextDisplay. It also makes me think of making "View source" display from within dillo as modified plain text (line numbers + text lines) to get "find text" for free as we discussed some time ago. Unfortunately now the priority is with Tabs and the near release. -- Cheers Jorge.-

Sept. 22, 2008