GNOME Bugzilla – Bug 626457
Add a lock button widget
Last modified: 2011-05-07 02:47:59 UTC
Created attachment 167437 [details] [review]
Similar to the widget provided by the polkit-gtk library in PolicyKit-gnome.
A lock button is commonly used on dialogs which make 'privileged' changes. The lockbutton 'unlocks' the rest of the ui (and also allows to lock it again).
GIO now provides an abstract GPermission interface that allows us to implement such a widget in GTK+ without linking directly against PolicyKit. PolicyKit contains an implementation (PolkitPermission) of GPermission, that can be used with the lock button.
I like this widget, it looks good and I think having such a widget in GTK+ makes a lot of sense. FWIW, I just tested it with
and it works great.
- Do we want getters/setters for the properties?
My guess is that we probably don't want that.
- We hide the widget when the GPermission has the state
(allowed && !can_release) which I think makes a lot of
sense. We need to point that out in the docs though.
(Maybe we want to control that behavior later on by
adding a flags property.)
In fact, it looks like you are missing an entire
introductory SECTION:GtkLockButton entry.
- The widget is implemented as a hbox containing a GtkButton
and a GtkLabel where the button only has an image. One
side-effect with that setup, is that the clickable area is
confined to the button - maybe we want to make GtkLockButton
a GtkButton subclass instead?
- There's some concerns here
about sizing. Any thoughts on what to do with that?
> My guess is that we probably don't want that.
Right, I wanted to leave those out for now, to not drown the api in rarely used getters and setters.
> In fact, it looks like you are missing an entire
> introductory SECTION:GtkLockButton entry.
Right, I've added some docs now (heavily borrowing from your PolkitLockButton docs).
> The widget is implemented as a hbox containing a GtkButton and a GtkLabel...
Not sure, we could also make it so that the extra label can be hidden, for space-constrained situations. I'll just go with the current approach for now.
I don't think we need to make the widget fixed-size. In most situations, the lock button should be right-aligned in the action area, by itself (right ?), so the size change should not by itself mess up the layout of the action area, except for the second point. But that is really a bug in GtkButtonBox that it needs to be smarter about enforcing homogeneity without making a mess. I'll have a look at that, perhaps.
my biggest concern is the lack of guidelines for use of this button
where does it go in a dialog with buttons for example?
- above action area?
- left side of action area?
- what if there is also a help button?
- some "windicator" crack?
Created attachment 186955 [details] [review]
add a non-homogeneous child property in gtkbuttonbox
Created attachment 186956 [details] [review]
These patches update the implementation to whats currently used in the control-center, and add some more documentation.