GNOME Bugzilla – Bug 698730
[PATCH] tooltip: Fix possible wrong placement
Last modified: 2018-03-30 14:57:16 UTC
Created attachment 242321 [details] [review] tooltip: Fix possible wrong placement When showing a tooltip on the edge of a monitor, the tooltip could be wrongly placed and be shown going from one monitor to the next. This happened because the current_window wasn't set visible, and when it wasn't the returned allocated size would be 1, hence wrong calculations. (See b495ce5446a0 for why the allocated size is 1 when not visible.) With GTK 3.8: it seems the tooltip would be correctly placed at first, but if moving the mouse (hiding it) and waiting a bit (re-showing it) it would then always be wrongly placed. I'm guessing this might be a bug in the fix for #696882, that made it return a wrong size the first time (since current_window isn't visible then either). (I use my patch to fix #696882, and I'd always have the tooltip wrongly placed.)
Created attachment 257359 [details] [review] tooltip: Fix possible wrong placement Updated patch.
Attachment 257359 [details] pushed as 1922b7d - tooltip: Fix possible wrong placement
Hi, This appears to be causing trouble with GtkTreeViews and GtkIconViews - what seems to occur with them is tooltips have an initial position of X0,Y0, and are shown in the upper left corner of the screen briefly before being positioned correctly. Removing this line prevents this from occurring.
Created attachment 259950 [details] [review] tooltip: Fix possibly briefly appearing at 0x0 Ok, coudln't reproduce it but I think this should fix it. Instead of making the window visible, the natural size is used when the allocation isn't available/was reset.
This regression affects Mageia linux installer: https://bugs.mageia.org/show_bug.cgi?id=11893 I confirm the patch in comment #4 fixes the issue for Mageia
I confirm it fix a bug on Gedit too.
The patch that was committed in comment #2 is also causing application launcher tooltips to flicker on gnome-panel, but the patch in comment #4 fixes this regression.
Actually while this patch fixes most misplacements, I still see some tooltips misplaced (but not at top, rather at full left) with Mga installer
Created attachment 269631 [details] on every twice try, tooltip is not centered on the window but is placed far left, half outside
Created attachment 269632 [details] another misplacement example with drakx (Mageia installer)
Any update on this? I realize this does not occur in gnome-shell, and have been trying to nail down why this is the case. I'm assuming it has to do with the frame sync implementation that was implemented in Gtk and mutter, but even injecting those changes into my wm has not solved the issue. Obviously I'm not seeing the full picture, or am missing something critical and/or basic - perhaps something not directly related to frame syncing. I know I could apply this second proposed patch here and solve my problem in my distro, but I'd rather learn, understand things correctly, and do the proper fix (and maintain a well-behaved wm in the process). Thanks a lot.
I've discussed this bug with Benjamin, and here is an outline of how we want to address this: 1) Add _gtk_window_set_position_func which us set a callback for determining a position 2) Call it in gtk_window_constrain_position when it is set 3) Make use of this for positioning tooltips 4) For extra credit, convert menus to use it too Note that we want to keep this API private, since it won't work on Wayland
*** Bug 733887 has been marked as a duplicate of this bug. ***
As a quick hack, your application can use a custom tooltip widget and move it down to the bottom right hand corner of the screen to avoid seeing the flashing and to avoid a collision with the pointer location.
Could we have this in for GTK+ 3.15.x? I accidentally dropped the patch we were carrying in Mageia and that mistake took quite a while to sort out.
Yes, this broke tooltips in matchbox window manager, it seems matchbox uses the window position when the map is requested, but ignores any move_resize donde afterwards. I also confirm patch in comment #4 fixes the issue.
Also happens in Pitivi with the tooltips for the clips in the timeline.
*** Bug 721583 has been marked as a duplicate of this bug. ***
FYI - I've suggested another workaround (patch) for this bug on my duplicate report: Bug 754109 https://bugzilla.gnome.org/show_bug.cgi?id=754109
*** Bug 754109 has been marked as a duplicate of this bug. ***
(In reply to mi from comment #19) > FYI - > I've suggested another workaround (patch) for this bug on my duplicate > report: > Bug 754109 > https://bugzilla.gnome.org/show_bug.cgi?id=754109 Can you please reattach here your patch from there? It's better to keep a single report open and do review in one place.
Review of attachment 259950 [details] [review]: Just cosmetic comments, in case this is ever picked back up. ::: gtk/gtktooltip.c @@ +1104,3 @@ width = gtk_widget_get_allocated_width (GTK_WIDGET (tooltip->current_window)); height = gtk_widget_get_allocated_height (GTK_WIDGET (tooltip->current_window)); + /* if window was hidden, it's allocation was reset to { -1, -1, 1, 1 } and Substitute to "If" and "its" @@ +1107,3 @@ + * using such invalid width/height might lead to wrong placement. + * In such a case, get the natural size instead to perform calculation. + * See bug #698730 */ Afaict, bug refs are only included if the fix is a kludge or otherwise temporary. If not, i.e. if the patch is the ideal code and will not need changed, no reference should be included in the diff, only in the commit message, and users who want to know why the code was added will git blame and get to this bug that way. @@ +1113,3 @@ + + gtk_widget_get_preferred_size (GTK_WIDGET (tooltip->current_window), + NULL, &requisition); GTK+'s coding style keeps arguments either on one line or left-aligned below the first argument; not hanging like this
*** This bug has been marked as a duplicate of bug 703460 ***