There are two ways GTK can add a headerbar to a dialog:
- the dialog is constructed with the :use-header-bar property
- all windows should use client-side decorations
In the first case, the headerbar is added by GtkDialog with no
dedicated style class, and in the latter by GtkWindow with the
"default-decoration" style.
As a result, dialogs with plain titlebars can end up with clearly
distinct and inconsistent styles.
To address this, allow headerbars to track whether they should use
the "default-decoration" style and enable it for dialogs.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/836
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.
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The event is not useful at all, so we are better off
with a signal that doesn't have it, and it is only
relevant on toplevel windows, so we don't need it on
GtkWidget.
With this commit, delete events no longer go through the
::event, ::delete-event, ::event-after widget signals,
but just cause the ::close-request signal on GtkWindow to be
emitted.
GtkButtonBox adds the "linked" class to its style context when its
layout is set to GTK_BUTTONBOX_EXPAND. It shouldn't ever make sense to
have spacing between buttons in that case, as themes generally draw
linked elements with a continuous border.
Thus, always set spacing to 0 and ignore GtkDialog's button-spacing
style property when the layout is set to EXPAND.
Also remove the now-redundant css rules which set button-spacing to 0
for message dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=752131
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
If the widget is an action widget, it's been previously added with
gtk_dialog_add_action_widget, which calls add_response_data on it, which
in turn connects to the clicked/activate signal of that widget, so we
don't need to connect to that signal a second time in
gtk_buildable_custom_finished.
We used to move help buttons to the secondary position regardless
how they were added to the action area. Keep doing that, to avoid
breaking existing dialogs that rely on this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=735119
People expect to be able to call gtk_widget_show_all on the dialog
to make action widgets visible, as seen e.g. in
https://bugzilla.gnome.org/show_bug.cgi?id=733431
To keep this working, we can't always set no-show-all on the
action_box. Only set it when the action_area is not used and empty.
We can't avoid calling set_titlebar in buildable_add_child, since
GtkBuilder assumes that it can e.g. call grab_default at the end,
which only works if the widget is inside a toplevel at that point.
Instead, drop the titlebar and clean up priv->headerbar in constructed
if we find that we don't want a headerbar.
This is fallout from the recent dialog changes. We don't set the
headerbar as titlebar early enough anymore, so when the window title
gets set, it does not get passed on to the headerbar. So, re-set it
manually when the titlebar is put in place.
https://bugzilla.gnome.org/show_bug.cgi?id=733099
