If there is no secondary text, then the primary text is just a message,
not a title, and should not use title style.
This partially reverts 1e3ec7c1f9. The
message dialog nown looks like it used to in GTK 3. However, it's still
styled only using a style class rather than using pango markup, as in
GTK 3.
Fixes#3509
We were not aligning model button labels with nesting
submenus with indicators in their containing menu.
This was visible in the application demo of gtk4-demo.
Motion history coordinates are based on GdkSurface coordinates. Transform
the coordinates from the GtkNative they are received on, accounting for the
possible transforms (e.g. due to window borders and shadows).
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3491
If set to TRUE, does not call the free func for the removed items.
This can be used to move items between arrays without having to do the
refcounting dance.
We only need this to render shapes and trapezoids, i.e. only when
falling back to cairo. Remove code to measure the layout and convert the
ink_rect to a graphene_rect_t from gtk_snapshot_append_layout() and do
it when drawing shapes and trapezoids instead.
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
We let smooth scroll events that don't trigger a ::scroll signal through.
This is unintended, these are handled, even if just accumulated.
This fixes cases like GtkSpinButton inside GtkScrolledWindow, where both
would handle events, until the GtkSpinButton eventually shifts away from
underneath the pointer.
Brought up at https://gitlab.gnome.org/GNOME/gtk/-/issues/593
This code was here in gtk3 to cater for the completion window being
positioned. That was only to meant once as long as the completion window
was shown.
This doesn't work as well for gtk4, ::size-allocate gets propagated from
the toplevel, so happens much more often for the completion window, this
ends up with the completion position being reset to the first row
frequently.
Do this simply once when popping up the completion, instead.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3083
The coordinates are already widget-local here, not transformed by the
adjustment positions. Using the adjustment value here ends up pushing
the entry far from the left border.
The correct minimum value here is 0, which matches the treeview left
border.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3009
Let model buttons handle unpaired releases, these may happen indirectly
e.g. due to other child menus being opened at the time. Clicking would
dismiss the menu, but the menu item beneath the pointer would not get
activated.
We can handle that button release though via ::unpaired-release, so
there's no second click required.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3463
Tracking it through the GtkGestureClick becomes a bit cumbersome for
handling of simultaneously pressed buttons. We can track ::stopped,
but that also emits for a number of situations where we want drag to
continue.
However, the GtkGestureDrag is grouped with the click gesture, and
knows better when to finish the drag gesture (not just because of a
button release), so hook drag and zoom mode finalization there.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3426
Having a property with the same name of a method makes some languages
which put properties and method names in the same flat namespace not
really happy about our choices. To avoid collisions, let's put the the
"fullscreen" property into the past, alongside the "maximized" property.
Drop the "don't write code that crashes" folksy bit; don't start
sentences with conjunctions; remove copy-pasted references to
"iconified" states; point to the corresponding property notification in
a consistent manner.
