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.
We were not really handling all cases correctly here. We want
the suggested-action style class to only be set on headerbar
buttons, and it should be set on the default widget. Ensure
this by syncing the suggested-action style class with the
default style class. As a side-effect, setting has-default
on an action widget in ui files will now have the expected
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
GtkDialog has convenience API for adding action widgets that are
either placed in the action area or the headerbar. This commit
makes the same functionality available from GtkBuilder ui files
by specifying "action" as the child type.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
The use of border-width-set here was an attempt to differentiate
between explicitly set (from code / ui files) border width from
theme changes. But when we are calling gtk_window_set_border_width
to apply the theme value, the -set property gets set, and all
further theme changes are ignored. This has the effect of only
letting the default value of these properties get applied.
Fix this by unsetting border-width-set after applying theme values.
This fixes an issue where the theme-provided border-width prevents
dialog contents from lining up properly with the headerbar. To make
this work in message dialogs, we have to explicitly set the border-
width of the action area to 0.
We want to present a clean, rounded top when there is nothing
else to show, but many dialogs in applications rely on showing
information in their title, so add a label and show the title
when it is not empty.
If we aren't using a header bar then put a fake titlebar
box on it so we can round the corners.
One of the advantages of this is so that the styling of the dialog
is completely within one theme framework. This prevents skew between
the theming expectations from the window manager and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=725345
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
