Tooltip bugs revisited

[Jorge Arellano Cid]

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

[corvid]

Post by Jorge Arellano Cid
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?

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
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;
+
+ 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.

[corvid]

Post by Jorge Arellano Cid

Post by corvid

Post by Jorge Arellano Cid
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;
+
+ 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.

[Jorge Arellano Cid]

Hi,

After some more testing I decided to commit the custom tooltip
handler patchset for you to try. I has worked very well here so
far.

Please see details with: $hg log -v

:-)

[corvid]

Post by Jorge Arellano Cid
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 :) ).

I see that this code is derived from the code at
http://seriss.com/people/erco/fltk/#SliderTooltip
I think we should mention that at the tops of the tipwin files and
in AUTHORS.

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
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 :) ).

I see that this code is derived from the code at
http://seriss.com/people/erco/fltk/#SliderTooltip
I think we should mention that at the tops of the tipwin files and
in AUTHORS.

Yes, I wrote to Greg and got his answer stating that all the code
there is public domain, and that he'll soon add some lines declaring
it so in his "Cheat Page".