The node draws a solid CSS border, which can be used to cover everything
but dashed and dotted borders (double, groove, inset, ...).
For different border styles, we overlay multiple nodes and set their
colors to transparent for sides with non-matching styles.
It turns out, some simple getters - such as
gdk_drawing_context_get_clip() - love copying things before returning
them.
I guess somebody has to burn cycles...
When the background-clip of the background is smaller than the
background-clip of blended images, not pushing a group is wrong.
Test testing exactly that included.
This uses the new push()/pop() mechanism to its fullest extent when
implementing transitions. It's fun to inspect the results in the
inspector.
Crossfades don't work yet, they continue using a Cairo fallback.
A side effect of the stack conversion is that widget-factory now uses
snapshots for a lot more things.
It is now possible to call push() subfunctions for simple container
nodes with just a single child. So you can for example
gtk_snapshot_push_clip() a clip region that all the nodes that get
appended later will then obey.
gtk_snapshot_pop() will then not return a container node, but a clip
node containing the container node (and similar for the transform
example).
This is implemented internally by providing a "collect function" when
pushing that is called when popping to collects all the accumulated
nodes and combine them into the single node that gets returned.
To simplify things even more, gtk_snapshot_pop_and_append() has been
added, which pops the currently pushed node and appends it to the
parent.
The icon rendering code has been converted to this approach.
Instead of appending a container node and adding the nodes to it as they
come in, we now collect the nodes until gtk_snapshot_pop() is called and
then hand them out in a container node.
The caller of gtk_snapshot_push() is then responsible for doing whatever
he wants with the created node.
Another addigion is the keep_coordinates flag to gtk_snapshot_push()
which allows callers to keep the current offset and clip region or
discard it. Discarding is useful when doing transforms, keeping it is
useful when inserting effect nodes (like the ones I'm about to add).
Instead of having a setter for the transform, have a GskTransformNode.
Most of the oprations that GTK does do not require a transform, so it
doesn't make sense to have it as a primary attribute.
Also, changing the transform requires updating the uniforms of the GL
renderer, so we're happy if we can avoid that.
I'm about to move children handling to the container node, which means
the generic code can no longer assume children APIs existing.
So rewrite the treemodel to work without it.
gsk_render_node_get_bounds() still exists and is computed via vfunc
call:
- containers dynamically compute the bounds from their children
- surface and texture nodes get bounds passed on construction
We want to split nodes into containers and nodes that do actual drawing.
So pushing nodes that do drawing is exactly the wrong thing.
Also fix up GtkPopover. There's no need for it to push anything.
When running uninstalled tests with GtkApplication on an autobuilder with
a fake session bus, warnings will cause the tests to abort. The GNOME
session manager, the Xfce session manager, and the Inhibit portal are all
not needed for normal operation of GTK, so we should not log warnings if
they are not found.
As well as not being present on a fake session bus, it's also not
expected that they'll be present on all platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=774784
... with gtk_list_box_get_row_at_y. It would be nice to avoid the
'find' versus 'get' discrepancy since we are planning to expose it as
public API.
https://bugzilla.gnome.org/show_bug.cgi?id=776187
It does weird clipping that
(a) nobody likes
(b) is hard to support in the new rendering world.
So we take the easy way out.
The actual frame is now drawn by the frame node around the label.
GtkCellView has a gadget, so peopl can do all their shenanigans with
CSS.
And the original use case (overriding the background so that the
cellview's GdkWindow shares the background color of the combobox) is
outdated since we have transparent backgrounds.
It's using a GtkCssPositionValue, even though that name is wrong. But
the functionality of managing 2 lengths is exactly what we want.
Nobody is using this yet.
These only exist for the window dragging which does not exist anymore
currently. It will be reintroduced later in a form that does not require
these handlers.
That way we can capture both the actual changes (clip region) and the
area that was redrawn (render region), which in OpenGL might not be
identical.
Nothing shows the render region yet though...
