September 2008 - Dillo-dev - lists.mailman3.com

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

PATCH: select new tabs

by corvid＠lavabit.com

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.

Sept. 22, 2008

Tabs!!!

by corvid＠lavabit.com

Johannes wrote: > On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote: > > I wrote: > > > Johannes wrote: > > > > On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote: > > > > > I wrote: > > > > > > Sometimes the window closes when I click on a page. > > > > > > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > > > > > > and then HIDE. > > > > > > (I only had one tab, in case that matters.) > > > > > > > > > > Okay, that was not accurate. > > > > > It looks like PUSH and FOCUS_CHANGE is from clicking > > > > > and HIDE is from pressing Space to page down. > > > > > > > > I'm also seeing that. No idea yet... > > > > > > I finally sat down and worked out what the problem is. > > > It's not only click-space, but that's the most common case. > > > > > > <title>...&[character]...</title> > > > > > > causes click-[character] to close it. > > > > > > So fltk must think that's a shortcut in > > > the tab text, and it tries to do whatever > > > it does with shortcuts -- but there's a > > > shortcut-handling piece missing, so it > > > just closes the window. > > > > It doesn't care about the tab text. > > It's the UI->window() label stuff that's causing the problem. > > It appears that you can escape &-as-shortcut in general > > by doubling them, but I end up with doubled && in the > > title bar. > > Why wasn't this a problem in the past? I don't know; maybe it > > _was_ regarded as a shortcut but handle() took care of it. > > > > Thanks for tracking this down! > I could also reproduce it with pre-tabs versions. I have a dillo from Sept. 5 around, and space doesn't close the window for me. > Please try attached patch. It works! RAW_LABEL is so much better than trying to escape &.

Sept. 22, 2008

Redraw storms

by jcid＠dillo.org

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. -- Cheers Jorge.-

Sept. 22, 2008

Tabs!!!

by Johannes.Hofmann＠gmx.de

On Mon, Sep 22, 2008 at 05:06:35AM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > On Fri, Sep 19, 2008 at 03:21:58PM +0000, corvid wrote: > > > > I wrote: > > > > > Sometimes the window closes when I click on a page. > > > > > A quick fprintf() says PUSH causing a recursive FOCUS_CHANGE, > > > > > and then HIDE. > > > > > (I only had one tab, in case that matters.) > > > > > > > > Okay, that was not accurate. > > > > It looks like PUSH and FOCUS_CHANGE is from clicking > > > > and HIDE is from pressing Space to page down. > > > > > > I'm also seeing that. No idea yet... > > > > I finally sat down and worked out what the problem is. > > It's not only click-space, but that's the most common case. > > > > <title>...&[character]...</title> > > > > causes click-[character] to close it. > > > > So fltk must think that's a shortcut in > > the tab text, and it tries to do whatever > > it does with shortcuts -- but there's a > > shortcut-handling piece missing, so it > > just closes the window. > > It doesn't care about the tab text. > It's the UI->window() label stuff that's causing the problem. > It appears that you can escape &-as-shortcut in general > by doubling them, but I end up with doubled && in the > title bar. > Why wasn't this a problem in the past? I don't know; maybe it > _was_ regarded as a shortcut but handle() took care of it. > Thanks for tracking this down! I could also reproduce it with pre-tabs versions. Please try attached patch. Cheers, Johannes PS: We will need to set RAW_LABEL for all widgets that get their labels fom html...

Sept. 22, 2008