- Dillo-dev - lists.mailman3.com

fill in that little square that the scrollbars form

by corvid＠lavabit.com

I don't know this drawing/damage code well enough to know whether this is the best way to go about it, but it appears to work.

Nov. 14, 2012

Tooltip bugs revisited

by corvid＠lavabit.com

Jorge wrote: > On Sun, Nov 11, 2012 at 09:18:08PM +0000, corvid wrote: > > Jorge wrote: > > > Testing revealed the workaround concealed another problem, > > > which I don't remember whether it was detected before, and this > > > is that viewport mouse events get "through" the panel UI!. > > > > > > How?, placing the mouse pointer over the panel (e.g. to the > > > right of the Tools button, or even inside the Location), and > > > scrolling a page full of links under it, will make the mouse > > > pointer change to a hand, and the destination link appear in the > > > status bar area. > > > > > > This bug is revealed by disabling the workaround: just apply > > > the small attached patch. > > > > > > Clearly there's a viewport offset problem somewhere. Correcting > > > it may save us lots of headaches in the future. > > > > > > Does anybody know or has a clue of where this may be happening? > > > > > > TIA. > > > > Does this work for you? > > > diff -r 8b4259cdc6da dw/fltkviewport.cc > > --- a/dw/fltkviewport.cc Sat Nov 10 17:55:34 2012 +0000 > > +++ b/dw/fltkviewport.cc Sun Nov 11 21:14:40 2012 +0000 > > @@ -318,6 +318,10 @@ > > mouse_y = Fl::event_y(); > > positionChanged(); > > break; > > + > > + case FL_LEAVE: > > + mouse_x = mouse_y = -1; > > + break; > > } > > > > return FltkWidgetView::handle (event); > > Yes! It works. > > Please elaborate a bit. > > Some history: FLTK2 had widget coordinates relative to the > parent. When we ported dillo to FLTK-1.3 which has absolute > coords, a bunch of offset problems sprung here and there. I > remember hunting/fixing most of them. > > I thought this bug could be related to widget offsets, although > that's just one possibility, not a certainty. I had removed that code in the recent text selection / scrolling changes because I no longer thought I had any need for it, but: FltkViewport::scrollTo() calls positionChanged(), and it still remembered old mouse_x,mouse_y values from when the pointer was in the viewport.

Nov. 12, 2012

Tooltip bugs revisited

by jcid＠dillo.org

On Sun, Nov 11, 2012 at 09:18:08PM +0000, corvid wrote: > Jorge wrote: > > Testing revealed the workaround concealed another problem, > > which I don't remember whether it was detected before, and this > > is that viewport mouse events get "through" the panel UI!. > > > > How?, placing the mouse pointer over the panel (e.g. to the > > right of the Tools button, or even inside the Location), and > > scrolling a page full of links under it, will make the mouse > > pointer change to a hand, and the destination link appear in the > > status bar area. > > > > This bug is revealed by disabling the workaround: just apply > > the small attached patch. > > > > Clearly there's a viewport offset problem somewhere. Correcting > > it may save us lots of headaches in the future. > > > > Does anybody know or has a clue of where this may be happening? > > > > TIA. > > Does this work for you? > diff -r 8b4259cdc6da dw/fltkviewport.cc > --- a/dw/fltkviewport.cc Sat Nov 10 17:55:34 2012 +0000 > +++ b/dw/fltkviewport.cc Sun Nov 11 21:14:40 2012 +0000 > @@ -318,6 +318,10 @@ > mouse_y = Fl::event_y(); > positionChanged(); > break; > + > + case FL_LEAVE: > + mouse_x = mouse_y = -1; > + break; > } > > return FltkWidgetView::handle (event); Yes! It works. Please elaborate a bit. Some history: FLTK2 had widget coordinates relative to the parent. When we ported dillo to FLTK-1.3 which has absolute coords, a bunch of offset problems sprung here and there. I remember hunting/fixing most of them. I thought this bug could be related to widget offsets, although that's just one possibility, not a certainty. -- Cheers Jorge.-

Nov. 12, 2012

tab state

by corvid＠lavabit.com

How much trouble would it be to make tabs show whether they are - waiting for reply - receiving data - done It'd be quite useful...

Nov. 11, 2012

Tooltip bugs revisited

by corvid＠lavabit.com

Jorge wrote: > Testing revealed the workaround concealed another problem, > which I don't remember whether it was detected before, and this > is that viewport mouse events get "through" the panel UI!. > > How?, placing the mouse pointer over the panel (e.g. to the > right of the Tools button, or even inside the Location), and > scrolling a page full of links under it, will make the mouse > pointer change to a hand, and the destination link appear in the > status bar area. > > This bug is revealed by disabling the workaround: just apply > the small attached patch. > > Clearly there's a viewport offset problem somewhere. Correcting > it may save us lots of headaches in the future. > > Does anybody know or has a clue of where this may be happening? > > TIA. Does this work for you?

Nov. 11, 2012

Tooltip bugs revisited

by jcid＠dillo.org

Hi there, These days I've devoted some more effort to the tooltips bug [1] and its workaround patch [2]. The motivation is that the current workaround involves a full UI and viewport expose (i.e. a full erase/redraw) that produces annoying flickering when the mouse is in the UI but outside the viewport (e.g. over the panel). Over time I've learnt to move the mouse pointer outside the panel and into the viewport to scroll without flickering (but probably I'm among the few that know this trick). So far (and despite the warning inside FLTK), I've experimented with a custom tooltip handling class, and a couple custom UI widgets, that seem to work well together (i.e. solve the problem without the workaround :) ). Testing revealed the workaround concealed another problem, which I don't remember whether it was detected before, and this is that viewport mouse events get "through" the panel UI!. How?, placing the mouse pointer over the panel (e.g. to the right of the Tools button, or even inside the Location), and scrolling a page full of links under it, will make the mouse pointer change to a hand, and the destination link appear in the status bar area. This bug is revealed by disabling the workaround: just apply the small attached patch. Clearly there's a viewport offset problem somewhere. Correcting it may save us lots of headaches in the future. Does anybody know or has a clue of where this may be happening? TIA. [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-July/008494.html [2] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-July/008515.html -- Cheers Jorge.-

Nov. 11, 2012

fltk linkage

by corvid＠lavabit.com

Jorge wrote: > On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > > > In September 2011, I wrote: > > > Do we still have a reason for telling people to stick with > > > static linkage when building fltk? > > > > I was thinking about what our installation instructions should look like > > these days, and how everyone has a decent chance of having a fltk-1.3 > > package available and it may not be best to tell them to run off and > > compile fltk unless fltk-config --version doesn't tell them any good news > > and they can't get a pkg... and this led me to wonder about the > > necessity/appropriateness of static linking. > > > > All that I found in the archive was me wondering about it last year and > > no one replying to me. Well, except this now. I'm replying to me, if that > > counts. > > FWIW, I build in a Debian system now and: > > $ ldd dillo > [...] > libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) > libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) > [...] > > I thought this meant it was linked with a shared version of FLTK. > What am I missing? *digs through fltk for a minute* So it's a matter of whether fltk is configured with --enable-shared, then? The main page of the website still says "statically-linked by default!", and all along I've had the impression that it had to do with the form of how we link in the Makefile. I guess it makes sense to rm that mention from the website, then. I could've sworn that it was in our documentation somewhere, too, but I don't see it anywhere at the moment. PS I think we will be able to get rid of the warning about --enable-cairo , since it doesn't seem to do anything bad with fltk-1.3.

Nov. 10, 2012

fltk linkage

by jcid＠dillo.org

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. FWIW, I build in a Debian system now and: $ ldd dillo [...] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) [...] I thought this meant it was linked with a shared version of FLTK. What am I missing? -- Cheers Jorge.-

Nov. 10, 2012

fltk linkage

by Johannes.Hofmann＠gmx.de

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. I would leave the decision to link statically or not to the package maintainers of the various distros. They will do anyway what they consider best.

Nov. 10, 2012

fltk linkage

by corvid＠lavabit.com

In September 2011, I wrote: > Do we still have a reason for telling people to stick with > static linkage when building fltk? I was thinking about what our installation instructions should look like these days, and how everyone has a decent chance of having a fltk-1.3 package available and it may not be best to tell them to run off and compile fltk unless fltk-config --version doesn't tell them any good news and they can't get a pkg... and this led me to wonder about the necessity/appropriateness of static linking. All that I found in the archive was me wondering about it last year and no one replying to me. Well, except this now. I'm replying to me, if that counts.

Nov. 10, 2012