Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
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
