These pieces were added in commit 8d2f81cca4, but are no longer
necessary since there's no capture_button_press special behavior
toggle.
This can be simplified again.
Do not get a GdkEvent first and foremost, and only do that in the
parts where the GdkEvent is absolutely necessary (i.e. popping up
the WM menu for the window).
We can abstract widgets about the specific ongoing sequences that
are triggering a GtkGesture. This used to be more necessary in
GTK3 world where complex widgets might have required handling
different events in different areas, but in GTK4 world that would
be done with multiple widgets.
This is no longer necessary to carry forward.
It does not require special knowledge about the ongoing event
sequences, and it can instead trust the event controller. Make
it use gtk_gesture_set_state() generically.
The design patterns using statusbar are no longer popular,
and it is pretty easy to make a statusbar yourself with boxes
and labels, if you need one. The only thing special about
GtkStatusbar was its window resize handle, but that has
been gone for a long time.
When checking characteristics of the context
for downloading, we were using self->context,
even though we are using a possibly different
context for downloading.
Pass the right context along and use it.
It does not make sense to sync and wait in the
same context, that is just a no-op. The intention
of this code clearly was to sync in the gst
context, and wait in the gdk one.
That also matches what the gtk sink implementation
in gstreamer does.
Set the label to expand, so it actually fills
the width that we allocated for it, instead
of shrinking back to the minimum width for
its height.
Fixes: #5521
Setting max-width-chars to the number of characters
in the string works ok only as long as the average
char width we get from Pango matches reality. Sadly
that seems not always the case, and this code was
causing short Chinese tooltips to always be broken
into two lines.
Fixes: #4470
At the moment, GTK applications search for "desktop-startup-id" in the
platform data on Wayland , but desktop environments such as plasma set
"activation-token" property instead as indicated in the spec:
activation-token: This should be a string of the same value as would
be stored in the XDG_ACTIVATION_TOKEN environment variable, as specified
by the XDG Activation protocol for Wayland.
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
