This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
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 claimed the gesture previously to keep it from propagating to the
underlying entry, but now that the entry is in a box with the two
buttons, we can do this properly and restore the previous long-press
behavior.
always initialize clips to the (content) allocation, don't walk up the
widget hierarchy in gtk_widget_set_clip, implement
gtk_widget_size_allocate in GtkSeparator. This way we don't end up using
uninitialized clip values.
The entire clip handling is up for major rework since we can't and don't
want to force every single widget to call _set_clip in size-allocate
implementations.
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.
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.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
We only keep one align flag per child, so it seems odd to
keep separate h/v expand flags. Just keep one expand flag
and interpret it according to orientation. Allow setting
the expand flag for child widgets too, though, so we can
make widget expand without interfering with the recursive
widget expand flag.
Update all callers.
Use the new possibility of expanding child widgets to make
the label of check and radio buttons expand. This fixes
unexpected behavior of these widgets in RTL in some places.
https://bugzilla.gnome.org/show_bug.cgi?id=765742
When opening the value editor for any GtkAdjustment properties
in the inspector, the popover stretches out for miles, since
it reserves enough space to draw MAXDOUBLE. This is not useful.
Limit the space we reserve to 8 digits.
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
When the spinbutton grows larger, distribute horizontal size to the
entry and vertical size to the buttons.
Obviously, horizontal size only matters for horizontal spinbuttons and
vertical for vertical spinbuttons.
