- Dillo-dev - lists.mailman3.com

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

PATCH: select new tabs

by bf2006a＠yahoo.com

--- On Mon, 9/22/08, corvid <corvid(a)lavabit.com> wrote: > From: corvid <corvid(a)lavabit.com> > Subject: Re: [Dillo-dev] PATCH: select new tabs > To: dillo-dev(a)dillo.org > Date: Monday, September 22, 2008, 11:41 AM > Jeremy wrote: > > On Mon, Sep 22, 2008 at 12:06:27AM +0000, corvid > wrote: > > > Jeremy wrote: > > > > > > > This patch is more of a call for > discussion than a fix as it > > > > fiddles with the UI. It makes Dillo > select the new tab after > > > > creating it. As a special case, > middle-clicking a link does not > > > > select the new tab unless the Shift key > is down. (This is the > > > > same behaviour as Firefox which saves > learning a new set of > > > > reflexes.) What do people think? > > > > > > It does seem that "I want to see this in a > new tab/window now" has > > > been more common for me than "I want to > look at this in a different > > > tab/window later". > > > > So do you think that a middle button click on a > link should always > > select the new tab? I often go down a list opening > up new tabs to > > look at later so I get frustrated when I have to > switch back each > > time. On the other hand when I create a new blank > tab I always want > > to switch to it immediately so I prefer Dillo to do > that for me. > > Well, I've never been in the habit of using tabs, so I > don't have too much > of an opinion about the particulars yet. I will agree that > allowing > both "see this now" and "see this > later" in some way is good. > Yes, please make it possible for users to choose both via keyboard or mouse -- I find it very useful to alternate between both behaviors -- sometimes I want to switch immediately to new content in a new tab, and other times I want to open a new tab, but remain in the current tab, and look at the new tab "in a minute". You don't want to have to either backtrack in a webpage or navigate back to a tab unnecessarily. Some other glitches(?) I've noticed: -- opening the "find text" bar prevents keyboard tab switching via Shift+{left,right}, although Ctrl+(Shift +)Tab still works (a variant of the lack of focus/tab-switching problems Johannes described) -- the keyboard shortcuts listed to the right of the choices in the "File" menu no longer correspond to those choices when tabs are open, although the choices mostly still function as expected: for instance, one can no longer "Exit dillo" via Alt+Q with tabs, and of course "Ctrl+Q" no longer closes the dillo window, just the current tab. On the other hand, "New Browser" doesn't work as before: it only opens a new tab. -- when opening a large number of tabs, so that the tab titles exceed the amount of horizontal space, the earlier tab titles "pile up" on the left hand-side, and, when navigating through the earlier tabs, the highlighted tab title of the current tab is simply pulled to the top on the left, while the titles to the right of it remain the titles of the last few tabs, and aren't shifted to become the immediate right-hand neighbors of the current tab, as they would normally be if there weren't so many tabs. -- the dillo panels/icons are tab-dependent, rather than remaining the same across all tabs in a given window -- a consequence, I suppose, of the one UI-per-tab design Jorge described -- but is it desirable? Just a few cosmetic details... The new version of the browser is shaping up nicely, and I'm sure people will be excited about using it when you release. Regards, b.

Sept. 22, 2008

source window's reluctance to show end of file

by corvid＠lavabit.com

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.

Sept. 22, 2008