Use the same helper function to determine if a widget
can be made the focus-widget in all the places where
it is what we want to know.
The helper function takes into account can-focus,
sensitive and child-focusable.
Handle key-pressed ourselves to maintain the intra-label
focus location for links. This works almost as well as
it did previously. One issue is that our ::focus-in
handler does not know which direction the focus is coming
from, so we always select the first link, whereas previously
we would select the last link for Shift-Tab.
GtkText was handling this just on grab_focus, which is
not the only way anymore that focus can reach it. Instead,
shift this to focus-in, and add a property that can be
used to override the select-on-focus setting. Remove
the gtk_text_grab_focus_without_selecting(), but keep
the GtkEntry variant of the function, reimplemented
to use the properties. GtkSearchEntry sets the select-on-focus
property of its text to FALSE, to match expectations.
The color chooser switches from the palette to
the editor by just showing and hiding. Use
child-focusable to ensure that focus does not
wander off into the hidden parts.
We no longer call the ::focus vfunc, so remove
all existing implementations. This needs careful
review to determine how to bring the functionality
in these handlers back.
Move things around to make the focus chain introspectable.
Use the next-focus-child api in the move-focus and
focus implementations.
We add a next_focus_child vfunc that containers can
override to tweak the behavior.
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.
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.
Since we can do partial redraws, dropping every shadow that's been
unused for one frame happens too fast. This is also a problem when a
shadow gets drawn on a texture for a few frames.
This can happen for certain transform nodes. The transform node's
child's bounds are fine, but the transform node bounds are all nan.
Just ignore those bounds since we can't meaningfully render them anyway.
If the given matrix is explicitly of category IDENTITY, we don't need to
do anything, and in the 2D_TRANSLATE case, just offset the child bounds.
Those are the two most common cases.
