Hi, I'm giving a look into the old dragging-tooltip bug: e.g. show an HTML image's tooltip, then scroll out of it with keyboard or mousewheel, and the tooltip will not be erased. Funny how FltkTooltip::onLeave() is called, but the tooltip window stays anyway. Has anybody looked into this one? BTW, does anyone know how to debug into FLTK with gdb? (FWIW, this bug is ancient; from the 2.x series). -- Cheers Jorge.-
Jorge wrote:
BTW, does anyone know how to debug into FLTK with gdb?
For me, as long as the debugging symbols are there, it's the same as anything in dillo. PS I put a small amount of effort into hidden inputs with the input's name to the left of the box yesterday. Modifying requisition/allocation to add the room was easy, but I haven't figured out how to trigger the label drawing.
On Fri, Jul 01, 2011 at 05:02:41PM -0400, Jorge Arellano Cid wrote:
Hi,
I'm giving a look into the old dragging-tooltip bug: e.g. show an HTML image's tooltip, then scroll out of it with keyboard or mousewheel, and the tooltip will not be erased.
Funny how FltkTooltip::onLeave() is called, but the tooltip window stays anyway.
Has anybody looked into this one?
I looked into this a few times. When scrolling the moved content just gets copied server side and only the newly exposed part is actually drawn. That's how the tooltip moves up or down. However the disappearing tooltip should request the area to be redrawn that it had covered. For some reason it redraws not the right rectangle. I think redraws the area where the tooltip had been before the scroll or something like that. You can see what's going on like this: diff -r 86cc8fe82da0 dw/fltkviewbase.cc --- a/dw/fltkviewbase.ccMon Jun 27 21:01:21 2011 -0400 +++ b/dw/fltkviewbase.ccSun Jul 03 21:20:54 2011 +0200 @@ -182,6 +182,8 @@ fl_rectf (X, Y, W, H); theLayout->expose (this, &r); } +fl_color(FL_RED); +fl_rect(X, Y, W, H); exposeArea = NULL; } Cheers, Johannes
On Sun, Jul 03, 2011 at 09:22:22PM +0200, Johannes Hofmann wrote:
On Fri, Jul 01, 2011 at 05:02:41PM -0400, Jorge Arellano Cid wrote:
Hi,
I'm giving a look into the old dragging-tooltip bug: e.g. show an HTML image's tooltip, then scroll out of it with keyboard or mousewheel, and the tooltip will not be erased.
Funny how FltkTooltip::onLeave() is called, but the tooltip window stays anyway.
Has anybody looked into this one?
I looked into this a few times. When scrolling the moved content just gets copied server side and only the newly exposed part is actually drawn. That's how the tooltip moves up or down. However the disappearing tooltip should request the area to be redrawn that it had covered. For some reason it redraws not the right rectangle. I think redraws the area where the tooltip had been before the scroll or something like that. You can see what's going on like this:
diff -r 86cc8fe82da0 dw/fltkviewbase.cc --- a/dw/fltkviewbase.ccMon Jun 27 21:01:21 2011 -0400 +++ b/dw/fltkviewbase.ccSun Jul 03 21:20:54 2011 +0200 @@ -182,6 +182,8 @@ fl_rectf (X, Y, W, H); theLayout->expose (this, &r); } +fl_color(FL_RED); +fl_rect(X, Y, W, H);
exposeArea = NULL; }
Thanks a lot for the tip! I've digged into it. Hopefully close enough to a bugfix... -- Cheers Jorge.-
On Mon, Jul 04, 2011 at 03:27:18PM -0400, Jorge Arellano Cid wrote:
On Sun, Jul 03, 2011 at 09:22:22PM +0200, Johannes Hofmann wrote:
On Fri, Jul 01, 2011 at 05:02:41PM -0400, Jorge Arellano Cid wrote:
Hi,
I'm giving a look into the old dragging-tooltip bug: e.g. show an HTML image's tooltip, then scroll out of it with keyboard or mousewheel, and the tooltip will not be erased.
Funny how FltkTooltip::onLeave() is called, but the tooltip window stays anyway.
Has anybody looked into this one?
I looked into this a few times. When scrolling the moved content just gets copied server side and only the newly exposed part is actually drawn. That's how the tooltip moves up or down. However the disappearing tooltip should request the area to be redrawn that it had covered. For some reason it redraws not the right rectangle. I think redraws the area where the tooltip had been before the scroll or something like that. You can see what's going on like this:
diff -r 86cc8fe82da0 dw/fltkviewbase.cc --- a/dw/fltkviewbase.ccMon Jun 27 21:01:21 2011 -0400 +++ b/dw/fltkviewbase.ccSun Jul 03 21:20:54 2011 +0200 @@ -182,6 +182,8 @@ fl_rectf (X, Y, W, H); theLayout->expose (this, &r); } +fl_color(FL_RED); +fl_rect(X, Y, W, H);
exposeArea = NULL; }
Thanks a lot for the tip!
I've digged into it. Hopefully close enough to a bugfix...
BTW, I'm testing a patch that works so far! :) -- Cheers Jorge.-
On Mon, Jul 04, 2011 at 03:27:18PM -0400, Jorge Arellano Cid wrote:
On Sun, Jul 03, 2011 at 09:22:22PM +0200, Johannes Hofmann wrote:
On Fri, Jul 01, 2011 at 05:02:41PM -0400, Jorge Arellano Cid wrote:
Hi,
I'm giving a look into the old dragging-tooltip bug: e.g. show an HTML image's tooltip, then scroll out of it with keyboard or mousewheel, and the tooltip will not be erased.
Funny how FltkTooltip::onLeave() is called, but the tooltip window stays anyway.
Has anybody looked into this one?
I looked into this a few times. When scrolling the moved content just gets copied server side and only the newly exposed part is actually drawn. That's how the tooltip moves up or down. However the disappearing tooltip should request the area to be redrawn that it had covered. For some reason it redraws not the right rectangle. I think redraws the area where the tooltip had been before the scroll or something like that. You can see what's going on like this:
diff -r 86cc8fe82da0 dw/fltkviewbase.cc --- a/dw/fltkviewbase.ccMon Jun 27 21:01:21 2011 -0400 +++ b/dw/fltkviewbase.ccSun Jul 03 21:20:54 2011 +0200 @@ -182,6 +182,8 @@ fl_rectf (X, Y, W, H); theLayout->expose (this, &r); } +fl_color(FL_RED); +fl_rect(X, Y, W, H);
exposeArea = NULL; }
Thanks a lot for the tip!
I've digged into it. Hopefully close enough to a bugfix...
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones). Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v). Committed. -- Cheers Jorge.-
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:) Will you use similar code for the UI tooltips, since they're often shown over the rendering area? PS If you're still feeling tooltippishly ambitious, there are the big tooltips on lkml.org to do something about...
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:)
Will you use similar code for the UI tooltips, since they're often shown over the rendering area?
Personally I don't see a problem with it... (and it was *much* more work than anticipated, so I am a bit tired ;)
PS If you're still feeling tooltippishly ambitious, there are the big tooltips on lkml.org to do something about...
Yes, I knew you worked on something like that (and saw an STR). Now that we have full control over the tooltip, it became quite simple, just look at this line in fltkplatform.cc: ww = 800; // max width; That is a suggested max width (i.e. fltk makes it wider when necessary), but we have full control of the tooltip string in the constructor, so it can be chopped to fit the desired width. BTW, what page are you looking at as test case? -- Cheers Jorge.-
On Sat, Jul 09, 2011 at 09:17:51AM -0400, Jorge Arellano Cid wrote:
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:)
Will you use similar code for the UI tooltips, since they're often shown over the rendering area?
Personally I don't see a problem with it...
(and it was *much* more work than anticipated, so I am a bit tired ;)
PS If you're still feeling tooltippishly ambitious, there are the big tooltips on lkml.org to do something about...
Yes, I knew you worked on something like that (and saw an STR). Now that we have full control over the tooltip, it became quite simple, just look at this line in fltkplatform.cc:
ww = 800; // max width;
That is a suggested max width (i.e. fltk makes it wider when necessary), but we have full control of the tooltip string in the constructor, so it can be chopped to fit the desired width.
BTW, what page are you looking at as test case?
Ah, sorry, lkml.org shows the problem. It looks simple as we also control the tooltip placement. -- Cheers Jorge.-
Jorge wrote:
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:)
Will you use similar code for the UI tooltips, since they're often shown over the rendering area?
Personally I don't see a problem with it...
If I scroll, they stick to their original spot on the rendering area.
On Sat, Jul 09, 2011 at 03:45:07PM +0000, corvid wrote:
Jorge wrote:
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:)
Will you use similar code for the UI tooltips, since they're often shown over the rendering area?
Personally I don't see a problem with it...
If I scroll, they stick to their original spot on the rendering area.
You're right, I never noticed. -- Cheers Jorge.-
On Sat, Jul 09, 2011 at 03:45:07PM +0000, corvid wrote:
Jorge wrote:
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
:)
Will you use similar code for the UI tooltips, since they're often shown over the rendering area?
Personally I don't see a problem with it...
If I scroll, they stick to their original spot on the rendering area.
Patch committed. -- Cheers Jorge.-
On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote:
[...] PS If you're still feeling tooltippishly ambitious, there are the big tooltips on lkml.org to do something about...
WRT tooltip escaping removal patch, I was thinking of filtering out some HTML from the tooltips (for lkml's sake)... <br/> would be enough, but a few more elements could be better. I'll send you a a patch. -- Cheers Jorge.-
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
BTW, it looks like we can rip out the @-escaping again...
On Sat, Jul 09, 2011 at 04:30:32AM +0000, corvid wrote:
Jorge wrote:
Well, it's really complex and I only got partial workarounds with Fl_Tooltip (which "fixed" the problem but creating new ones).
Finally I went for a custom tooltip implementation. The patches are commented in the code and in hg (hg log -v).
FWIW, if not clear from the above message: the committed patch solves all the problems seen so far. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de