GNOME Bugzilla – Bug 720059
use headerbars in dialogs
Last modified: 2014-01-28 09:33:52 UTC
It would be nice to use the headerbar in the about dialog so that we can begin the process of making dialogs consistent with respect to the close button and to reduce the amount of vertical space used.
Created attachment 263741 [details] [review] about-dialog: Use headerbar Use a GtkHeaderBar for the credits and about buttons
Created attachment 263752 [details] [review] dialog: use headerbar
Created attachment 263753 [details] [review] dialog: mark alternate button order as deprecated
Created attachment 263754 [details] [review] about-dialog: Use headerbar Use a GtkHeaderBar for the credits and about buttons
Created attachment 263755 [details] [review] font-dialog: use headerbar
Created attachment 263756 [details] [review] color dialog: use headerbar
Created attachment 263757 [details] [review] app chooser: use headerbar
Created attachment 263758 [details] [review] print dialog: use headerbar
Created attachment 263759 [details] [review] page setup: use headerbar
Created attachment 263760 [details] [review] custom page dialog: don't add a close button
Created attachment 263793 [details] [review] dialog: use headerbar
Created attachment 263794 [details] [review] dialog: add an accessor function for header bar
Created attachment 263795 [details] [review] dialog: mark alternate button order as deprecated
Created attachment 263796 [details] [review] message dialog: use headerbar
Created attachment 263797 [details] [review] about-dialog: Use headerbar Use a GtkHeaderBar for the credits and about buttons
Created attachment 263798 [details] [review] font-dialog: use headerbar
Created attachment 263799 [details] [review] color dialog: use headerbar
Created attachment 263800 [details] [review] app chooser: use headerbar
Created attachment 263801 [details] [review] print dialog: use headerbar
Created attachment 263802 [details] [review] page setup: use headerbar
Created attachment 263803 [details] [review] custom page dialog: don't add a close button
Review of attachment 263794 [details] [review]: ::: gtk/gtkdialog.h @@ +193,3 @@ GDK_AVAILABLE_IN_ALL GtkWidget * gtk_dialog_get_content_area (GtkDialog *dialog); +GDK_AVAILABLE_IN_3_10 3.12 by now
Review of attachment 263795 [details] [review]: ::: gtk/gtkdialog.h @@ +169,3 @@ GtkWidget *widget); +GDK_DEPRECATED_IN_3_10 3.12
Looking at these dialogs I'm a little concerned about compatibility. The will work great in GNOME, but may look foreign elsewhere. Any thoughts on that ?
I think you need to set the valign of each button as GTK_ALIGN_CANTER, additionally to set the style "test-button". This still not perfect. We need a way to pack the buttons in the dialog to a single size-group with the close-button, maybe something same to "homogeneous" property in GtkHeaderBar.
(In reply to comment #24) > Looking at these dialogs I'm a little concerned about compatibility. The will > work great in GNOME, but may look foreign elsewhere. Any thoughts on that ? I think most of those changes should happen against a GtkDialog subclass (or sibling) for now, and remove the original dialog in v4. There's loads of uses of dialogues outside of GTK+ which do all kinds of crazy things with the widgets in there, and I'm not sure every single one of them will migrate nicely. Furthermore, is every dialogue supposed to use the headerbar's "Done" button style? What about alerts/warnings? gtk_dialog_set_default_response() might also break.
Created attachment 266095 [details] [review] Set a minimum size on the headerbar title label
Created attachment 266096 [details] [review] Allow unsetting custom titlebar
Created attachment 266097 [details] [review] Add an expand button box type
Created attachment 266098 [details] [review] dialog: use headerbar
Created attachment 266099 [details] [review] message dialog: use headerbar
Created attachment 266100 [details] [review] about-dialog: Use headerbar Use a GtkHeaderBar for the credits and about buttons
Created attachment 266101 [details] [review] font-dialog: use headerbar
Created attachment 266102 [details] [review] color dialog: use headerbar
Created attachment 266103 [details] [review] app chooser: use headerbar
Created attachment 266104 [details] [review] print dialog: use headerbar
Created attachment 266105 [details] [review] page setup: use headerbar
Created attachment 266106 [details] [review] custom page dialog: don't add a close button
Created attachment 266107 [details] [review] Don't use a headerbar on message dialogs
Created attachment 266108 [details] [review] Use header bar on file chooser dialogs
Created attachment 266109 [details] [review] Use header bar on recent chooser dialogs
Created attachment 266110 [details] [review] Allow button box to extend to edge of dialog
Created attachment 266111 [details] [review] demo: add two buttons to the message dialog
Created attachment 266112 [details] [review] demo: add new button box layouts
Created attachment 266113 [details] [review] Don't show images in message dialogs
Bug 722072 for the required style.
Created attachment 266116 [details] [review] Fix order of print buttons We changed the packing order recently
I not see in what patch exactly it, but you miss add GTK_ALIGN_CANTER to some buttons in the file dialog.
Created attachment 266175 [details] [review] Center headerbar buttons added by dialog
Created attachment 266199 [details] [review] Center message dialog text
thanks for this effort - I've pushed an elaboration of this patch set to the dialogs branch.
I think this is wrong on many levels. I'll not bother to write down why I think this is a bad idea from a design point of view since I have long given up on being able to argue a design decision, but with regard on how this design decision is implemented in gtk I see at least the following problems: *) the change will break all the apps that currently use this api: even if technically the change is api/abi compatible, all current users of this api expect the buttons to be at the bottom both from a design point of view and from a documentation point of view *) the change is forced directly at the base of the platform without any form of user validation *) the change breaks cross platform usage of Gtk. How will all this dialog behave on other platforms (windows and osx). How will they behave on other linux platforms that are not gnome? *) the deprecation of the button-order setting is a break of cross platform expectation on its own. I have always been ok with the button order picked by gnome, but I appreciate how "[open|cancel]" have the right order when the app used on windows.
I saw that in Matthias git branch, the use of the header it is conditional to a setting, which reduces some of the concerns about portability etc. However the patch deprecating button-order is still there, and that's already a problem on windows. I still think this whole exercise is kind of pointless: we always complain about the combinatorial explosion of options to test and yet we systematically pick to change a lot of details so that they behave different from how they work on other platforms. Even if buttons on top was better than on bottom (and I do not think it is), is this the most pressing issue in gnome design? Is it so much better to warrant introducing the inconsistency with all third party applications and toolkits? Or do we really think that ISV will rush to change a zillion of dialogs to comply with the GNOME way?
So, we're careful to preserve api and abi, and to phase things out slowly with deprecations while keeping them working, and you just throw all that away and say we break applications anyway ? That seems a little unfair, to say the least. I even made the default of the setting conservative.
Attachment 266097 [details] pushed as 00326d3 - Add an expand button box type