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
This reverts commit 6d545b6d03.
Reverting as this broke multi DPI systems, where a client is expected to
render at scale = 1 if it is only visible on a scale = 1 monitor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2129
The xdg_output.done event is deprecated in xdg-output v3, so clients
need to rely on the wl_output.done event instead.
However, applying the changes on the fist wl_output.event when using
xdg-output v3 may lead to an incomplete change, as following xdg-output
updates may follow.
Make sure we apply xdg-output events on wl_output.done events with
xdg-output v3.
https://gitlab.gnome.org/GNOME/gtk/issues/2128
Popovers have special handling to restablish
the previous 'default' and 'focused' widget,
that code it's in the map() unmap() handlers
in gtk/popover.c .
But, at the same time, GtkWindow also does
automatic restablishing of previous 'default' and
'focused' widgets, that's in _gtk_window_unset_focus_and_default()
function in gtk/gtkwindow.c which is called from
gtk_widget_hide() in gtk/gtkwidget.c .
So, when a popover is closed, both code-paths are
executed, conflicting with each other and resulting
in the popover failing to properly restablish the
default widget.
The commit that introduced _gtk_window_unset_focus_and_default()
to gtkwindow.c is from 2002 (commit ff9c2c5669) so
it predates by far the popover.c implementation,
therefore the rationale thing to do here is to exempt
popovers from being handled in _gtk_window_unset_focus_and_default()
(as that function is oblivion to the fact that
popovers have their own handling).
So, this commit exempts popovers from being handled
in the aforementioned function, but only for
the 'default' widget part atm, because although
by the previous rationale we should exempt it
from the 'focused' widget part too, I could not
find a bug in the issue tracker about that, so
instead we just exempt the 'default' widget part
that we know for sure it fixes issue #2125
Fixes issue #2125
Fix popovers to properly gain focus when clicked
inside an unfocused window.
We use the GTK_PHASE_CAPTURE of the 'pressed' event
to early detect that the popover is being clicked
inside an inactive window, this allow us to present
the window (and be focused) before the normal signal
handlers for the popover click/pressed events are run
which would ultimately give focus to popover widget.
This fix works for both modal and 'non modal' popovers
when being clicked inside unfocused windows.
Fixes issue #1871
With the switch to meson we no longer built with _FILE_OFFSET_BITS which
results in fstat being the 32 bit variant, not matching GStatBuf, which is
_stat64 on 64bit mingw builds.
This makes things use _fstat64 in this case, to match GStatBuf.
I was not getting any gtk+ profile markers output from the frame clock
when I was profiling an OpenGL app (gnome-hexgl). I debugged this and
it turns out that the profiling depends on getting the _NET_WM_FRAME_TIMINGS
event from the compositor, and once we switched to OpenGL rendering
this never appeared.
It turns out the reason it didn't is that the compositor only does
so if the client increases the counter tied to the window, and the
x11 gdk code has this optimization where if we do a draw pass
but nothing is actually drawn we don't update the counter.
Unfortunately the detection of whether something was draw or not
is based on some cairo surface hack that breaks when we render with
OpenGL instead. The fix is to just always update the counter if
we're drawing with OpenGL.
This was added with https://bugzilla.gnome.org/show_bug.cgi?id=148032
to make gtk compile against X11R5, see commit 3b9a31df0
That release is >20 years old now, so we can safely remove it.
The motivation for this is to remove any checks that we don't have in the
meson build.
This fixes an issue where stylus proximity in/out events emulate enter/leave events.
The emulated events didn't contain the correct slave device and therefore the
resulting device class was set incorrectly. Crossing event emulation now also
works with slave devices.
Closes#2070Fixes#2070
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2070
