The center widget in GtkBox was only introduced to use it in
GtkActionBar. However, the implementation there is much more complex
than it needs to be, so move the center widget into GtkActionBar instead
and later remove it from GtkBox.
The :label-widget is drawn before the child, so put the controls that
set the alignment of the :label-widget before those that pad the child.
We set (horizontal|vertical) padding, not "[xy]thickness". Also change
to "label [xy]align" & use grid spacing, not spaces at end of Labels.
This was ruined, with only 1 of the 8 subwindows rendering any content.
This commit fixes the responsible errors in the embedded GtkBuilder UIs:
• Fix broken replace by commit fb3d9022ad
of HBox with a Box having a broken orientation <property>
• Replace VBox and [HV]Paned with GtkOrientable successors (properly!)
• Remove use of Button:use_action_appearance, as this no longer exists
This commit also adds error reporting, in case other errors creep into
the GtkBuilder UI definitions, plus cleanup for the Builders and Windows
Since GtkTreeMenu became a private class only used by GtkComboBox, all
this test actually did was to show a ComboBox constructed with a custom
CellArea. Now that the latter is no longer possible, the test just shows
a handful of settings that do nothing. Just test GtkComboBox directly.
Little tool that creates a bunch of test files to throw add the
rendernode binary.
They should really be part of a testsuite, but we have none, so OI just
put them here.
Only keep the version that calls gsk_render_node_draw() if people
specify the --fallback option.
The actual renderer selection works just as for regular GTK. The easiest
way to influence it is setting the GSK_RENDERER environment variable.
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.
The tests read a nonexisting colorprofile, try to convert stuff read
from the window into it, do things that gdk-pixbuf should test and
then aren't even integrated into the testuite.
Sheesh.
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
This merged gtk, gdk and gsk into one library, making it possible to
have internal private APIs between gtk them, as well as producing more
efficient code.
https://bugzilla.gnome.org/show_bug.cgi?id=773100
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
This commit changes the way GskRenderer and GskRenderNode interact and
are meant to be used.
GskRenderNode should represent a transient tree of rendering nodes,
which are submitted to the GskRenderer at render time; this allows the
renderer to take ownership of the render tree. Once the toolkit and
application code have finished assembling it, the render tree ownership
is transferred to the renderer.
GSK is conceptually split into two scene graphs:
* a simple rendering tree of operations
* a complex set of logical layers
The latter is built on the former, and adds convenience and high level
API for application developers.
The lower layer, though, is what gets transformed into the rendering
pipeline, as it's simple and thus can be transformed into appropriate
rendering commands with minimal state changes.
The lower layer is also suitable for reuse from more complex higher
layers, like the CSS machinery in GTK, without necessarily port those
layers to the GSK high level API.
This lower layer is based on GskRenderNode instances, which represent
the tree of rendering operations; and a GskRenderer instance, which
takes the render nodes and submits them (after potentially reordering
and transforming them to a more appropriate representation) to the
underlying graphic system.
