The css tree and the widget tree are not in sync, so we need
to explicitly set the parent of the css node before inserting
the widget, or else we end up with critical warnings and a
non-working popover.
This can be seen in the print dialog, when moving the focus
to the printer list.
Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
In the presence of attached children, the css tree and the
widget tree are not in sync, so we need to explicitly set
the parent of the css node before inserting the widget, or
else we end up with critical warnings and a non-working
menu.
This can be seen in testtextview.
If we use "text" for the children that are attached to the
text view, they end up rendering the same background as the
main text content, causing that content to be covered up.
Fixes: #2729
The conditions to queue and dequeue a CSS validation
are different; while queueing checks if the widget is
a root, dequeueing checks that AND if the widget is
a container.
GtkWindow is not a GtkContainer anymore, and that is
causing validations to be queued, but never dequeued.
Don't require the widget to be a GtkContainer for
dequeuing.
The leave signal should not take any arguments,
don't pass the GdkDrop. Update the documentation,
fix the emission and update users to match.
This was showing up as crash when dragging files
over the places sidebar.
Since GtkWindowHandle and GtkHeaderBar do it now, it can be removed from
GtkWindow, along with GTK_WINDOW_REGION_TITLE which at this point doesn't
differ from GTK_WINDOW_REGION_CONTENT.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2689, since
GtkWindowHandle doesn't do that anymore.
We switched from returning a list to returning a C array, which means we
need to update the introspection annotation and the documentation to
match the implementation.
When setting a clear function on a GArray, unlike
most other places, this free func is expected to
*not* free the array element itself -- only its
contents.
Don't free the array element.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2717
This signal is mainly used for bad things, and we
don't want to emit signals during layout if we can
avoid it.
If you are subclassing, you should either use a
layout manager or override the size_allocate vfunc.
If you are using a GtkDrawingArea or GtkGLArea,
use their ::resize signals to learn about size
changes.
Fixes: #2705
Add private gtk_tooltip_maybe_allocate() function
and use it from GtkWindow and GtkPopover.
This will let us stop using the ::size-allocate signal,
without having to redo all the tooltip management first.
That will happen later.
