GNOME Bugzilla – Bug 733683
Stop using GdHeaderButton
Last modified: 2014-07-27 22:57:21 UTC
These days we can accomplish the same using standard GTK+ API. So let's just use that.
Created attachment 281607 [details] [review] Drop Gd.HeaderSimpleButton
Created attachment 281609 [details] [review] Drop Gd.HeaderToggleButton
Review of attachment 281607 [details] [review]: Does GtkImage not do the right thing if we just pass the icon name in without a pixel size? Looks good otherwise.
Review of attachment 281609 [details] [review]: See comment on the other patch.
Created attachment 281618 [details] [review] Drop Gd.HeaderMenuButton Should gtk_button_set_label be annotated as allow-none?
Created attachment 281750 [details] [review] Drop Gd.HeaderSimpleButton
Created attachment 281751 [details] [review] Drop Gd.HeaderToggleButton
Created attachment 281752 [details] [review] Drop Gd.HeaderMenuButton
(In reply to comment #3) > Review of attachment 281607 [details] [review]: > > Does GtkImage not do the right thing if we just pass the icon name in without a > pixel size? You are right, it does. I have removed those. Do you want me to squash the patches? I kept them separate because I was replacing them one by one, but now I realize that there isn't much difference between them.
Review of attachment 281750 [details] [review]: Looks good
Review of attachment 281751 [details] [review]: Looks good
Review of attachment 281752 [details] [review]: OK ::: src/mainToolbar.js @@ +179,3 @@ + if (this._selectionMenu) { + if (primary) { Want to file a bug against GTK for the NULL-ability of gtk_button_set_label()? @@ +181,3 @@ + if (primary) { + this._selectionMenu.set_label(primary); + this._selectionMenu.get_child().use_markup = true; I think it'd be nice if GtkButton supported this in a less hackish way - either by having a property on the button itself, or with a separate gtk_button_set_markup() method. Maybe file a bug against GTK for this as well?
Created attachment 281801 [details] [review] build: Drop unused libgd components
Review of attachment 281801 [details] [review]: Looks good