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

Redraw storms

by onepoint＠starurchin.org

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? Regards, Jeremy Henty

Sept. 22, 2008

PATCH: select new tabs

by onepoint＠starurchin.org

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. Regards, Jeremy Henty

Sept. 22, 2008

Tabs!!!

by corvid＠lavabit.com

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.

Sept. 22, 2008

PATCH: select new tabs

by corvid＠lavabit.com

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".

Sept. 22, 2008

Tabs!!!

by corvid＠lavabit.com

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.

Sept. 22, 2008

PATCH: select new tabs

by onepoint＠starurchin.org

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? Regards, Jeremy Henty

Sept. 22, 2008

patch: fonts, utf-8 tabs

by corvid＠lavabit.com

The ui.cc changes are so that I can make a tabs screenshot with Asian script at some point. Similarly, the dialog.cc change is so that I can see Asian characters in source. Kept forgetting to deal with that...

Sept. 21, 2008

patch: making some concessions to aesthetics...

by corvid＠lavabit.com

I've decided to admit that highlighting checkboxes and radio buttons is always hideous. I had been trying to avoid the special case, but I know the horribleness would jump right out at someone trying dillo2... (And I decreased the RELIEF_X_THICKNESS because 5 makes <button>s look weird at my low resolution)

Sept. 21, 2008

cut off word ends with italic fonts

by jcid＠dillo.org

On Fri, Sep 19, 2008 at 04:09:44PM +0200, Johannes Hofmann wrote: > Hi, > > somtimes the end of italic words get cut off e.g. in > > <html> > <body> > <i><a href="foo">FUU</a>BAR</i> > </body> > </html> > > when seen with vw_fontname="helvetica". > > This is due to a change in html.cc (I think it was introduced with > rev 1.36). This change sets the backgroundColor for all words which > means that for each word, the bounding box get's drawn before the > actual text. This obviously has a performance impact too. > > I'm not sure how to get back to the original behaviour > (backgroundColor == NULL for normal words) without breaking anything. > Can someone please have a look? I can't reproduce the problem here... -- Cheers Jorge.-

Sept. 21, 2008

[patch] minor optimization in StyleAttrs::equals()

by jcid＠dillo.org

On Fri, Sep 19, 2008 at 03:47:15PM +0200, Johannes Hofmann wrote: > Hi, > > this patch adds a missing optimization to StyleAttrs::equals(). > Similar checks are already in place in other equals() methods. Committed. -- Cheers Jorge.-

Sept. 20, 2008