Rename a few local variables to be clearer about whether they belong to
the widget or to the layout.
Remove a workaround for an old bug that is no longer valid. We don't
underallocate the layout anymore. Aways center vertically, with respect
to the yalign.
We have a region for the border here, but the color is defined as
transparent black because we don't want to render anything for it.
This way, the generated .node file for the listbox demo in gtk4-demo
with enabled layout borders is 3.5MB instead of 3.8MB.
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
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
- Add borders around the main scrollable content, like most other
places.
- Set padding and spacing on .emoji-searchbar and .emoji-toolbar in a
more proper way.
- Remove unused button.emoji-section label styles.
These ended up square in the various refactors. Make them again L-shaped
by extending these along the edge being checked. This means we have to
check for corner positions in all edges, though.
In order to do this, leverage smooth scroll handling into the capture
phase scroll controller, controlled by ::scroll-begin in the propagation
phase controller.
There's 2 cases here:
- A child widget handles scroll. The scrolled window does not get
::scroll-begin, the child widget handles the full scroll sequence.
- No child handles scroll, the scrolled window gets ::scroll-begin,
and transfers control of scrolling to the capture phase controller.
As scrolling is performed, the pointer may fall into scrollable children,
but the scrolled window will be capturing the scroll events, so these
won't be seen by the child widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/593
