because if there's a tooltip visible then popups fail to show
with the following warning:
"Gdk-WARNING **: Tried to map a popup with a non-top most parent"
This bug affect popups of the form:
1) popups from gtk_menu_popup_{at_widget|at_rect|for_device}()
This can be reproduce with a normal GtkComboBox that has a
tooltip attached (eg. via GtkBuilder 'tooltip_text' attribute).
Also see GtkLabel reproducer from gtk3-demo mentioned in #1785
2) custom popups created with gtk_window_new (GTK_WINDOW_POPUP)
A reproducer that shows this case is a GtkComboBox with
the property 'appears-as-list'[1] set to TRUE (default is FALSE).
Fixes issue #1785
[1] https://developer.gnome.org/gtk3/stable/GtkComboBox.html#GtkComboBox--s-appears-as-list
Before the recent rework of positioning in GtkTooltip, the widget always
used the cursor_size of the GdkDisplay. That work redid this to instead
take GtkSettings::gtk-cursor-theme-size. But that property's doc says:
> Size to use for cursors, or 0 to use the default size.
and has 0 as its default. This is quite a likely scenario for anyone
whose desktop or settings.ini does not explicitly provide a cursor size,
which is the case for XFCE and win32, to name just two common platforms.
Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
and hide/show itself at a very rapid speed, thus making it unusable.
So, we should check whether the Settings return 0 and, if so, still use
gdk_display_get_default_cursor_size (display) to ensure we get a size.
https://gitlab.gnome.org/GNOME/gtk/issues/1371
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134Closes: #432Closes: #574Closes: #579Closes: #878
Otherwise in GC-ed environments the `g_source_remove` call during
disposal might be called on an already removed source, which results in
unnecessary console output.
https://bugzilla.gnome.org/show_bug.cgi?id=778301
has_tooltip_widget was assigned twice in immediate succession.
return_value is not used anywhere else in this function since commit
14a864c8b5 and does not need a default
value anymore, so move it to the inner scope and don't init to NULL.
hide_tooltip gets overriden in any case 2 lines down, and return_value
isn't used later in that function. The second assignment was introduced
in ef1da5f6c2, directly below the first
assignment.
In https://bugzilla.gnome.org/show_bug.cgi?id=601425 the annotations
were changed to int as they not only take the predefined enum values
but also user defined values registered through gtk_icon_size_register()
As a result the typelib doesn't contain any information about
GtkIconSize for those arguments and the Python docstring only
shows the corresponding Python type "int".
This changes the argument docs to mention the type explicitly
so the Python doc generator can add a link to Gtk.IconSize
which contains the most useful predefined values.
https://bugzilla.gnome.org/show_bug.cgi?id=757411
(gnome-shell-extension-prefs:22382): GLib-GObject-WARNING **: invalid cast from 'GtkInvisible' to 'GtkWindow'
(gnome-shell-extension-prefs:22382): Gtk-CRITICAL **: gtk_window_set_transient_for: assertion 'parent == NULL || GTK_IS_WINDOW (parent)' failed
#1 0x00007fffeeb81a12 in g_log (log_domain=log_domain@entry=0x7fffeeea3464 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fffeeeaa878 "invalid cast from '%s' to '%s'") at gmessages.c:1079
#2 0x00007fffeee9c2a9 in g_type_check_instance_cast (type_instance=0xb314c0, iface_type=iface_type@entry=9020048) at gtype.c:4021
#3 0x00007ffff0a06e25 in gtk_tooltip_set_last_window (tooltip=tooltip@entry=0xbb8c10, window=<optimized out>) at gtktooltip.c:910
#4 0x00007ffff0a08dfd in _gtk_tooltip_handle_event (event=event@entry=0xbf72c0) at gtktooltip.c:1538
#5 0x00007ffff090d7a9 in gtk_main_do_event (event=0xbf72c0) at gtkmain.c:1785
#6 0x00007ffff0496ab2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:364
#7 0x00007fffeeb7a8c3 in g_main_dispatch (context=0x807300) at gmain.c:3067
https://bugzilla.gnome.org/show_bug.cgi?id=736131
The toplevel_window was never set, and the only place where it
was used was causing us to hide tooltips needlessly. So removing
it is a double win.
https://bugzilla.gnome.org/show_bug.cgi?id=733321
When placing tooltips, the csd shadow will get 'pushed up' and
may end up underneath the pointer. We don't want this to cause
the tooltip to be hidden, because that leads to flickering, so
ignore the shadow when finding the widget under the pointer.
This is old code from dating back many years. Nowadays, we can
just use css drawing and csd windows to achieve much the same
effect.
Themes will need some adjustment for this change.
https://bugzilla.gnome.org/show_bug.cgi?id=731187
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.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
Usually, educated GtkContainers' forall() implementation returns children
in an order that's safe for the default draw() implementation in GtkContainer.
So for widgets with some stacking notions (eg. GtkOverlay),
_gtk_widget_find_at_coords() needs to recurse within containers in reverse
order so it finds the topmost widget.
As this function is used in both tooltips and DnD code, this improves behavior
of "floating" widgets wrt those two. This could for example be seen in the
"Transparent" GTK+ demo, where dropping text on the entry results on the text
going to the textview.
https://bugzilla.gnome.org/show_bug.cgi?id=699239
