- Dillo-dev - lists.mailman3.com

Icon for Dillo window

by onepoint＠starurchin.org

On Thu, Sep 25, 2008 at 04:14:48PM +0200, Johannes Hofmann wrote: > On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > > That doesn't work on my system (my window manager is icewm). For > > me test/image gets the standard X icon in its window frame and in > > its taskbar box when miminised (icewm doesn't use desktop icons). > > Does it work with any other window managers? > > It worked for me with fvwm. OK, then it's worth doing even if it doesn't work everywhere (especially since the FLTK docs make it clear that nothing will work everywhere). > > If we're concerned about dillo2 playing properly with X11 and > > window managers then I'd say that it should set WM_CLASS to > > '"Dillo2", "dillo2"' on general principle. > > Yes that sounds right. I'll propose a patch later today for comments. > > Also, the _NET_WM_ICON hint has the advantage that it can provide > > a list of icons of different sizes so that window managers can use > > a larger icon eg. when switching between applications with > > Alt+Tab. > > Hm, no idea what is currently the best way to do this. > Any X11 specialists here? I already have code to set the _NET_WM_ICON hint. It's very straightforward (I just modified the sample code from one of the bug reports I linked to earlier). I can verify (using xprop) that the hint is but I can't check that it will actually affect the icon (because icewm ignores the hint), and I haven't figured out how to translate images into the right format. The freedesktop.org documentation is not completely specific about this. Regards, Jeremy Henty

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 03:16:30PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Sep 25, 2008 at 03:24:55AM +0000, corvid wrote: > > > Johannes wrote (way back in June!): > > > > * The cursor is not always updated properly when over a link. This > > > > happens while page is rendered and also when drag-scrolling with > > > > the middle mouse button. > > > > > > How about updating it from layout()? > > > > > > > Yes, I think something like that is necessary. I also worked a bit on > > that problem (see attached patch), but got confused about how > > to handle multiple views. > > The mouse could be over a link in one view and somewhere else in > > another one (with overlapping windows). > > Is the mouse pointer a per view or a per platform thing? > > Oh yeah, multiple views... > Multiple views are hard to think about when we don't know how they're > supposed to behave, can't make them, and don't know whether there's > any real need/use for them. Maybe we should enable that fltkpreview stuff somehow - just to verify that we don't break the multiple view feature. And making a Postscript view for printing could be fun! Cheers, Johannes

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by corvid＠lavabit.com

Johannes wrote: > On Thu, Sep 25, 2008 at 03:24:55AM +0000, corvid wrote: > > Johannes wrote (way back in June!): > > > * The cursor is not always updated properly when over a link. This > > > happens while page is rendered and also when drag-scrolling with > > > the middle mouse button. > > > > How about updating it from layout()? > > > > Yes, I think something like that is necessary. I also worked a bit on > that problem (see attached patch), but got confused about how > to handle multiple views. > The mouse could be over a link in one view and somewhere else in > another one (with overlapping windows). > Is the mouse pointer a per view or a per platform thing? Oh yeah, multiple views... Multiple views are hard to think about when we don't know how they're supposed to behave, can't make them, and don't know whether there's any real need/use for them.

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 03:24:55AM +0000, corvid wrote: > Johannes wrote (way back in June!): > > * The cursor is not always updated properly when over a link. This > > happens while page is rendered and also when drag-scrolling with > > the middle mouse button. > > How about updating it from layout()? > Yes, I think something like that is necessary. I also worked a bit on that problem (see attached patch), but got confused about how to handle multiple views. The mouse could be over a link in one view and somewhere else in another one (with overlapping windows). Is the mouse pointer a per view or a per platform thing? Anyway, attached patch solves the problem with the mouse pointer ending up over a link after loading has finished. Other corner cases do not yet work. Cheers, Johannes

Sept. 25, 2008

Icon for Dillo window

by Johannes.Hofmann＠gmx.de

On Thu, Sep 25, 2008 at 03:11:55PM +0100, Jeremy Henty wrote: > On Thu, Sep 25, 2008 at 12:12:26PM +0200, Johannes Hofmann wrote: > > -------- Original-Nachricht -------- > > > Datum: Thu, 25 Sep 2008 08:03:52 +0100 > > > Von: Jeremy Henty <onepoint(a)starurchin.org> > > > An: dillo-dev(a)dillo.org > > > Betreff: Re: [Dillo-dev] Icon for Dillo window > > > > > On Wed, Sep 24, 2008 at 06:48:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > I was thinking it'd be good to provide an icon for the WM to > > > > use. Does anybody know how to do it with FLTK2? > > > > > > It appears not to be possible. In X Windows you set the > > > _NET_WM_ICON hint > > > > test/image.cxx has from the fltk2 tarball shows how to do it. > > That doesn't work on my system (my window manager is icewm). For me > test/image gets the standard X icon in its window frame and in its > taskbar box when miminised (icewm doesn't use desktop icons). Does it > work with any other window managers? It worked for me with fvwm. > > Icewm sets icons by reading the WM_CLASS hint, interpreting it as the > root of the icon file names and searching for the files in its icon > directories. Unfortunately dillo2 sets WM_CLASS to '"Fltk", "fltk"'. > If it set it to '"Dillo2", "dillo2"' I could configure its icons. > > If we're concerned about dillo2 playing properly with X11 and window > managers then I'd say that it should set WM_CLASS to '"Dillo2", > "dillo2"' on general principle. Yes that sounds right. > > (The weird thing is that my icewm finds the right Firefox icons, yet I > can't find any Firefox icon files in the icon directories. I'm still > trying to figure out where it gets them from.) > > Also, the _NET_WM_ICON hint has the advantage that it can provide a > list of icons of different sizes so that window managers can use a > larger icon eg. when switching between applications with Alt+Tab. Hm, no idea what is currently the best way to do this. Any X11 specialists here? Regards, Johannes

Sept. 25, 2008

Icon for Dillo window

by onepoint＠starurchin.org

On Thu, Sep 25, 2008 at 12:12:26PM +0200, Johannes Hofmann wrote: > -------- Original-Nachricht -------- > > Datum: Thu, 25 Sep 2008 08:03:52 +0100 > > Von: Jeremy Henty <onepoint(a)starurchin.org> > > An: dillo-dev(a)dillo.org > > Betreff: Re: [Dillo-dev] Icon for Dillo window > > > On Wed, Sep 24, 2008 at 06:48:17PM -0400, Jorge Arellano Cid wrote: > > > > > I was thinking it'd be good to provide an icon for the WM to > > > use. Does anybody know how to do it with FLTK2? > > > > It appears not to be possible. In X Windows you set the > > _NET_WM_ICON hint > > test/image.cxx has from the fltk2 tarball shows how to do it. That doesn't work on my system (my window manager is icewm). For me test/image gets the standard X icon in its window frame and in its taskbar box when miminised (icewm doesn't use desktop icons). Does it work with any other window managers? Icewm sets icons by reading the WM_CLASS hint, interpreting it as the root of the icon file names and searching for the files in its icon directories. Unfortunately dillo2 sets WM_CLASS to '"Fltk", "fltk"'. If it set it to '"Dillo2", "dillo2"' I could configure its icons. If we're concerned about dillo2 playing properly with X11 and window managers then I'd say that it should set WM_CLASS to '"Dillo2", "dillo2"' on general principle. (The weird thing is that my icewm finds the right Firefox icons, yet I can't find any Firefox icon files in the icon directories. I'm still trying to figure out where it gets them from.) Also, the _NET_WM_ICON hint has the advantage that it can provide a list of icons of different sizes so that window managers can use a larger icon eg. when switching between applications with Alt+Tab. Regards, Jeremy Henty

Sept. 25, 2008

Icon for Dillo window

by Johannes.Hofmann＠gmx.de

-------- Original-Nachricht -------- > Datum: Thu, 25 Sep 2008 08:03:52 +0100 > Von: Jeremy Henty <onepoint(a)starurchin.org> > An: dillo-dev(a)dillo.org > Betreff: Re: [Dillo-dev] Icon for Dillo window > On Wed, Sep 24, 2008 at 06:48:17PM -0400, Jorge Arellano Cid wrote: > > > I was thinking it'd be good to provide an icon for the WM to > > use. Does anybody know how to do it with FLTK2? > > It appears not to be possible. In X Windows you set the _NET_WM_ICON > hint (as described at > > http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2523482 > > example at > > http://lists.kde.org/?m=115435217715650 > > but there is no mention of _NET_WM_ICON anywhere in the FLTK source > (in fact no use of WM hints anywhere except in Window_fullscreen.cxx > and once in Window::show() to set the command string). The FLTK docs > for Window::iconize() say > > Currently there are only X and Win32 system-specific ways to > control what is drawn in the icon. You should not rely on window > managers displaying the icons. > > So I think we would have to write X11-specific code. :-( > test/image.cxx has from the fltk2 tarball shows how to do it. It's X11-only though. Cheers, Johannes -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Sept. 25, 2008

Icon for Dillo window

by onepoint＠starurchin.org

On Wed, Sep 24, 2008 at 06:48:17PM -0400, Jorge Arellano Cid wrote: > I was thinking it'd be good to provide an icon for the WM to > use. Does anybody know how to do it with FLTK2? It appears not to be possible. In X Windows you set the _NET_WM_ICON hint (as described at http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2523482 example at http://lists.kde.org/?m=115435217715650 but there is no mention of _NET_WM_ICON anywhere in the FLTK source (in fact no use of WM hints anywhere except in Window_fullscreen.cxx and once in Window::show() to set the command string). The FLTK docs for Window::iconize() say Currently there are only X and Win32 system-specific ways to control what is drawn in the icon. You should not rely on window managers displaying the icons. So I think we would have to write X11-specific code. :-( Regards, Jeremy Henty

Sept. 25, 2008

patch: Re: [Dillo-dev] what's next

by corvid＠lavabit.com

Johannes wrote (way back in June!): > * The cursor is not always updated properly when over a link. This > happens while page is rendered and also when drag-scrolling with > the middle mouse button. How about updating it from layout()?

Sept. 25, 2008

Icon for Dillo window

by jcid＠dillo.org

Hi, I was thinking it'd be good to provide an icon for the WM to use. Does anybody know how to do it with FLTK2? -- Cheers Jorge.-

Sept. 25, 2008

release packaging

by onepoint＠starurchin.org

On Wed, Sep 24, 2008 at 02:16:22PM -0400, Jorge Arellano Cid wrote: > OK, dw2 is now inside the dillo2 tree. > > CVS updated and also the directions in cvs.html. > > Please check and test. It works fine! Jeremy Henty

Sept. 25, 2008

release packaging

by Johannes.Hofmann＠gmx.de

On Wed, Sep 24, 2008 at 02:16:22PM -0400, Jorge Arellano Cid wrote: > On Wed, Sep 24, 2008 at 05:44:51PM +0200, Johannes Hofmann wrote: > > On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > > > > 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? > > > > > > I'd move dw2 inside dillo2's tree (as it was before), > > > and have a recommended FLTK2 tarball in our site. > > > > That sounds good! > > OK, dw2 is now inside the dillo2 tree. > > CVS updated and also the directions in cvs.html. > > Please check and test. Yes, it works fine! Cheers, Johannes

Sept. 24, 2008

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

by corvid＠lavabit.com

Jeremy wrote: > On Wed, Sep 24, 2008 at 07:16:16PM +0200, Johannes Hofmann wrote: > > On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote: > > > > > > I've been surfing with the default so I just tried switching to > > > standard_widget_colors=YES and... I don't see much difference. > > > What does it affect? So far I'm indifferent to it. > > > > Check the form inputs at the top of www.freshmeat.net for example. > > They should have the current background color with > > standard_widget_colors=NO. > > OK, I see. In this case I slightly prefer standard_widget_colors=YES, > but I wouldn't make a fuss about it. So, I am still pretty > indifferent at the moment. Are we proposing to remove this > preferences option? What behaviour will we get if we do? I was trying to speak neutrally so that no one would feel like they're standing in the way of anything if they prefer it. (Don't want to take care of code if it isn't being used.) So, all right, I have nothing to propose, then. [off topic: I realized yesterday that, in my mind, dillo has a three-dimensional shape. I think part of that comes from where different files appear when src/ is ls'ed. Weird.]

Sept. 24, 2008

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

by onepoint＠starurchin.org

On Wed, Sep 24, 2008 at 07:16:16PM +0200, Johannes Hofmann wrote: > On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote: > > > > I've been surfing with the default so I just tried switching to > > standard_widget_colors=YES and... I don't see much difference. > > What does it affect? So far I'm indifferent to it. > > Check the form inputs at the top of www.freshmeat.net for example. > They should have the current background color with > standard_widget_colors=NO. OK, I see. In this case I slightly prefer standard_widget_colors=YES, but I wouldn't make a fuss about it. So, I am still pretty indifferent at the moment. Are we proposing to remove this preferences option? What behaviour will we get if we do? Regards, Jeremy Henty

Sept. 24, 2008

release packaging

by jcid＠dillo.org

On Wed, Sep 24, 2008 at 05:44:51PM +0200, Johannes Hofmann wrote: > On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > > > 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? > > > > I'd move dw2 inside dillo2's tree (as it was before), > > and have a recommended FLTK2 tarball in our site. > > That sounds good! OK, dw2 is now inside the dillo2 tree. CVS updated and also the directions in cvs.html. Please check and test. If it works you can get rid of the old dw2, dw2-cur directories and the dw-testbed symbolic link. (It worked here). -- Cheers Jorge.-

Sept. 24, 2008

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

by Johannes.Hofmann＠gmx.de

On Wed, Sep 24, 2008 at 06:18:02PM +0100, Jeremy Henty wrote: > On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote: > > > I'm running with standard_widget_colors=NO all the time and like it. > > I've been surfing with the default so I just tried switching to > standard_widget_colors=YES and... I don't see much difference. What > does it affect? So far I'm indifferent to it. > Check the form inputs at the top of www.freshmeat.net for example. They should have the current background color with standard_widget_colors=NO. Regards, Johannes

Sept. 24, 2008

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

by onepoint＠starurchin.org

On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote: > I'm running with standard_widget_colors=NO all the time and like it. I've been surfing with the default so I just tried switching to standard_widget_colors=YES and... I don't see much difference. What does it affect? So far I'm indifferent to it. Regards, Jeremy Henty

Sept. 24, 2008

release packaging

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 07:11:03PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > > 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? > > I'd move dw2 inside dillo2's tree (as it was before), > and have a recommended FLTK2 tarball in our site. That sounds good! Cheers, Johannes

Sept. 24, 2008

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

by jcid＠dillo.org

On Wed, Sep 24, 2008 at 04:36:48PM +0200, Johannes Hofmann wrote: > On Tue, Sep 23, 2008 at 09:17:28PM +0000, corvid wrote: > > 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. > > I'm running with standard_widget_colors=NO all the time and like it. Me too! -- Cheers Jorge.-

Sept. 24, 2008

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

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 09:17:28PM +0000, corvid wrote: > 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. I'm running with standard_widget_colors=NO all the time and like it. Cheers, Johannes

Sept. 24, 2008

patch: Re: [Dillo-dev] release packaging

by jcid＠dillo.org

On Wed, Sep 24, 2008 at 06:09:44AM +0000, corvid wrote: > bf wrote: > > 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?) > > "gzip" has been registered with the IANA since...since trilobites stalked > the seas, and I explicitly said "gzip" for Accept-Encoding, not "x-gzip", > but rfc2616 does state: > For compatibility with previous implementations of HTTP, > applications SHOULD consider "x-gzip" and "x-compress" to be > equivalent to "gzip" and "compress" respectively. > Committed. -- Cheers Jorge.-

Sept. 24, 2008

patch: Re: [Dillo-dev] release packaging

by corvid＠lavabit.com

bf wrote: > 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?) "gzip" has been registered with the IANA since...since trilobites stalked the seas, and I explicitly said "gzip" for Accept-Encoding, not "x-gzip", but rfc2616 does state: For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

Sept. 24, 2008

release packaging

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > > 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? > > I'd move dw2 inside dillo2's tree (as it was before), > and have a recommended FLTK2 tarball in our site. > > Please somebody send me a patch with this code move. > That way I can focus on Tabs... I will.

Sept. 24, 2008

release packaging

by jcid＠dillo.org

On Tue, Sep 23, 2008 at 04:15:01PM +0200, Christian Kellermann wrote: > * 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. Dw2 can also be used for other projects. Sometime ago, having independent trees allowed Sebastian and me to work comfortably. but now, AFAIS, dw2 fits better inside dillo2's tree. -- Cheers Jorge.-

Sept. 24, 2008

release packaging

by jcid＠dillo.org

On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > 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? I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site. Please somebody send me a patch with this code move. That way I can focus on Tabs... -- Cheers Jorge.-

Sept. 24, 2008

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

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

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

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