This drops the pixbuf property and the pixbuf getters. We keep
gtk_image_new/set_from_pixbuf, but these are small helpers that
immediately convert to a surface, and there is no way to later get
back the pixbuf you passed in.
The from file/resource codepaths are also changed to load a surface
instead of a pixbuf.
Rename the surface getter to peek, following other render
node getters, and make the surface-based constructor private,
since it is not something we want to encourage.
Update all callers.
GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.
‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().
Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note that if we do this then, as before, we set the ListStore on the
ComboBox before appending to it, that produced runtime warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
The ComboBoxes were initially empty, rather than reflecting the initial
values of the properties. The CheckButtons were only correct by chance.
Fix this by setting the initial values on the widgets and binding them
to the properties using SYNC_CREATE, so the two are always synced up.
https://bugzilla.gnome.org/show_bug.cgi?id=786209
Just to test tooltips in all cases; what was already here
should have been sufficient, but this doesn't hurt.
While here, also add some instructive placeholder text.
https://bugzilla.gnome.org/show_bug.cgi?id=780938
Replace uses of VLAs (variable-length arrays) using g_newa(), since
Visual Studio builds will unlikely ever support VLAs (which became optional
in C11).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
gdk and gsk are no longer separate libs but part of gtk now, so any
Gtk+ user should just link to gtk, there's no need to additionally
link against all those static helper libs that go into the gtk lib.
This means we need to specifically add confinc to include_directories
in more places to make sure the right config.h (i.e. ours) gets
included and not a subproject's like graphene's config.h.
Not dragging in static libs also fixes the issue of all executables
having to be relinked for any and all changes. With this change
it's super-fast now and can be skipped for most changes that don't
touch the external ABI.
