Display changes now happen exclusively through
the ::root and ::unroot vfuncs. Third parties
can observe display changes by listening
for notify::root.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
The default widget is mostly a dialog concept,
and does not really need this generic api.
If you need to mark a widget as default,
use gtk_window_set_default() directly.
We used to handle has-default specially in ui
files. It was awkward, so stop doing that. If you
need to influence the default widget in a window,
you can just set the default-widget property.
We used to handle has-focus in ui files specially.
It was awkward, so stop doing that. If you need
to influence the initial focus of a window, you
can just set the focus-widget property.
Added two new private GtkWidget API:
* gtk_widget_add_surface_transform_changed_callback()
* gtk_widget_remove_surface_transform_changed_callback()
The intention is to let the user know when a widget transform relative
to the surface changes. It works by calculating the surface relative
transform during allocation, and notifying the callbacks if it changed
since last time. Each widget adds itself as a listener to its parent
widget, thus will be triggered if a parents surface relative transform
changes.
This will be used to let the inspector and other users
pick insensitive widgets again. For now, update all
callers to pass no flags, preserving the current
behavior.
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
The GtkWidget::parent-set signal was removed in ff6cd8f7.
Instead of removing GtkLayoutChild instances associated to a widget
using notifications when the widget's parent changes, we can have
gtk_widget_unparent() call a method on GtkLayoutManager to remove any
eventual GtkLayoutChild instances associated to the widget.
- Rename GtkLegacyLayout to GtkCustomLayout
- Use for() to iterate over children in GtkBinLayout
- Whitespace fixes for code imported from GtkBox
- Store the GtkLayoutChild instances inside LayoutManager
- Simplify the GtkLayoutManager API by dropping unnecessary arguments
- Fix the ownership model of GtkLayoutManager
If a widget has a LayoutManager instance, then we want to parse layout
properties in UI description files; the grammar is similar to packing
properties in GtkContainer:
<child>
<object ...>
<property name="...">...</property>
<layout>
<property name="pname">value</property>
</layout>
</object>
</child>
The properties are applied after a child has been added to its parent,
to the parent's layout manager property should be set.
We can use a constructor property for existing container widgets with
a layout policy, and move the layout policy implementation out of the
widget itself and into a LayoutManager subclass.
We delegate the size request mode, the measuring, and the allocation of
a widget through a GtkLayoutManager instance, if one has been attached
to the widget; otherwise, we fall back to the widget's own implementation.
We basically don't have child surfaces anymore (the last
use in popovers is on the way out). This really needs
to be done in terms of widgets, not surfaces. For now,
just stop walking parent surfaces.
GtkWindow has a focus_widget that points to the current input focus.
GtkWidget has a focus_child that points to the child that contains
the input focus. Following the focus_child chain from the toplevel
always leads to the focus_widget. We never unset focus_child, we only
set it. We bubble focus change events.
Make the function that determines initial visibility
look at whether the class implements GtkRoot. That is
the eventual goal for this check. For now, allow
popovers in here as well.
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
Picking is done by drawing a line along the parent's z axis and picking
at the intersection with the child's z=0 plane.
However, the previous code was casting a ray along the child's z axis.
This patch actually transforms the line to pick into the target's
coordinate system and then computes the corrrect intersection with the
z=0 plane.
Using graphene_point3d_interpolate() to compute the final intersection
point is a bit of abuse of that function, but I found no better way in
Graphene to achieve the same thing.
Change gdk_surface_get/set_user_data to private
API and rename them to get/set_widget.
Also remove an unused associated function.
The last two places where the surface API is used
are in gtkroot.c and gtkwidget.c. Make them
use the private api.
This was broken by the change in 01f7f255b5 which
caused the inspector to not get any events anymore.
Revert that part, even though it may be technically
correct.
This avoids invalidating the size of all widgets when updating CSS
transforms.
In theory, we don't even have to allocate the widget itself, because we
didn't change its size. But we have no way to track that.
Don't leave memory in an unitinialized case when returning FALSE from
gtk_widget_compute_transform().
We both know that people are going to call that function without
checking the return value.
This is the same as the old code since the transformation only contains
teh offset right now, but it will be different later where arbitrary
transformations are possible per widget.
The transform matrix is a translation matrix from the parent's origin to
the widget origin. We will later allow more transformations than just
translations.
Instead of style + rect_of_one_box, pass the new GtkCssBoxes object.
This has the nice side effect that when drawing background + border +
outline, we only compute all the boxes we need once.
Previously, those numbers stored the values relative to the margin box
of the widget. Now they store values relative to the content box,
thereby getting rid of the last remains of weird coordinate systems.
