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
The recent reshuffling caused an ordering problem where we would
hide the action area before relocating the buttons to the header
bar. But hiding makes the default button loose its defaultness.
Rearrange things so that we move the buttons before hiding the
action area, and thus preserve the default.
When there area explicitly added buttons in the action area,
we were trying to ensure that the action area is visible,
but failed, since we are now hiding the action_box. Fix it
by showing the action_box when things are left in the action
area.
We were applying response based heuristics, even if the button
is explicitly put in the headerbar. That broke button placement
in some epiphany dialogs, such as the Cookies one. Therefore,
restrict the heuristics to action widgets that are added through
gtk_widget_add_action_widget() or <child type="action">, where it
is not possible to specify placement explicitly.
When combining action child type with <action-widgets> to assign
response ids, we were not properly updating buttons that ended up
getting added to the headerbar before they have a response id.
Fix this by reapplying the headerbar button setup after parsing
<action-widgets>, and make sure to also update the suggested-action
style class.
