When a root is set on a widget, the style context may
already exist. We need to make sure that the style context
has the right display set.
This was showing up as "css spillover" in the inspector.
Closes: #https://gitlab.gnome.org/GNOME/gtk/issues/1817
Keep only the software gl setting for GL, and put it together
with the simulate touchscreen setting in a 'misc' box. This
keeps all the 'show' options nicely grouped.
We don't want to render focus rectangles on everything. With
the way focus is propagated nowadays, the theme has to selectively
render focus on certain widgets.
At the same time, we always want to render focus for this
theme, so use the focus pseudoclass, not focus(visible).
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1815
After we stopped untranslatable delivering events, menus stopped
working 'the second time'. After some painful debugging, it appears
that this is caused by the menushell code deliberately grabbing
on the menubar *after* grabbing on the menu, causing events to
be deleivered to the wrong toplevel. This did not use to matter,
but now we drop these events.
Absent a more thorough rewrite of menus, just don't grab on
the menubar. This makes menu activation work again and does not
appear to have ill effects, on either Wayland or X.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1796
Getting the layout manager instance out of GtkGrid, and then querying
all layout properties can be tedious, especially for code that was
usually calling gtk_container_child_get().
To replace that, we can add a simple query function that returns the two
attach points and the spans.
We may avoid setting it on the paned widget depending on the pointer
position altogether, since the handle is now a widget. Also is more
likely to be correct as the implicitly grabbed widget will probably
be that one.
Fixes the paned losing the resize cursor after button press.
Instead of handle_event(), use set_key_capture_widget().
Also, use the fact that we now propagate key events throughout the
stage, and connect to the GtkInspectorPropList instead of the toplevel.
We only want the search bar to be active while that widget is mapped
and able to receive events.
And also, handle the "search bar" visibility on ::search-started.
Users of search entries usually handled visibility (when initially hidden)
by checking the return value of gtk_search_entry_handle_event(). This does
not pan out with gtk_search_entry_set_key_capture_widget() since the return
value is not directly seen by the caller.
Add a ::search-started signal to cater for it, which gets emitted when the
search entry went from empty to non-empty.
The hand-rolled stack combo we were using before
was looking at the visibility of the page itself
to show or hide items. Other stack switchers
expect us to use the GtkStackPage::visible
property for this.
