We cannot bubble up ::insert-text and ::delete-text signals from the
delegate to the wrapper editable without causing an infinite recursion,
due to how the signals are designed; ideally, we would have decoupled
signal emission from virtual functions *before* releasing GTK4, but now
that we have, we can't break the contract.
The GtkEntryBufferClass.deleted_text() behaviour changed between GTK3
and GTK4, which means any subclass of GtkEntryBuffer is now responsible
for emitting the "notify" signal for the "text" and "length" properties.
Without this, the GtkText delegate widget used by GtkPasswordEntry would
not be able to communicate changes in the contents of its buffer.
Fixes: #3484
- normally lighter (on bg_color)
- darker for headerbar
- undecorated checked buttons were never style properly (even gtk3)
see page2 volume buttons
Finetunes https://gitlab.gnome.org/GNOME/gtk/-/issues/3427
Float properties can not be read from keyfiles. This was causing changes
to this property in settings.ini to be ignored. Fix this by changing it
to a double.
Technically this change could be considered an API break, but there are
no users of this property as float yet and it is early enough to expect
there to never be any.
Also document this change in the 3 to 4 migration guide since in gtk 3
this setting will be kept a float.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
../gdk/gdktoplevellayout.c:217: Warning: Gdk: gdk_toplevel_layout_get_maximized:
unknown parameter 'maximized' in documentation comment, should be 'maximize'
100% symbol docs coverage.
833 symbols documented.
0 symbols incomplete.
0 not documented.
What's left are just type system macros and windowing system opaque
structures.
Depending on the input driver, we will get XI_Motion based scroll
events for regular mouse wheels. These are intended to be handled
as discrete scroll, so detect smooth scroll events that move by
exactly 1.0 in either direction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3459
When being fullscreen, and wanting to unfullscreen but not caring about
whether to go unmaximized or maximized (as this information is lost), if
the GdkToplevelLayout represents the full intended state, we won't be
able to do the right thing.
To avoid this issue, make the GdkToplevelLayout API intend based, where
if one e.g. doesn't call gdk_toplevel_set_maximized() with anything, the
backend will not attempt to change the maximized state.
This means we can also remove the old 'initially_maximized' and
'initially_fullscreen' fields from the private GtkWindow struct, as we
only deal with intents now.
When deciding whether to call gdk_toplevel_present(), check the
mappedness of GtkWidget instead of the mapped-ness of GdkSurface, as the
latter is mapped asynchronously, while the former is direct state of the
GtkWindow itself.
This fixes an issue where calling e.g. gtk_window_maximize() shortly
after showing it didn't take effect, as hadn't been mapped yet. While
maximizing after showing is racy, and will likely glitch from time to
time, the correct thing to do is still to maximize and handle whatever
state the compositor configured the window to be in.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3466
