GNOME Bugzilla – Bug 346451
Create an interface for toggle/radio widgets
Last modified: 2015-03-07 20:37:36 UTC
For example, GtkCellLayout is a cool interface for giving a common behavior to different widgets... actually there're 4 radio widgets and also other toggle widgets, why don't create an interface for them? My request would be a GtkRadioInterface, GtkToggleInterface, and so on...
Any comment? I would implement this myself and creating a patch if you think it's a good idea at all... Bye.
After having discovered this bug during the meeting last evening, there's no doubt several people are very much in favour of such interfaces. I'm going to come up with initial implementations shortly.
Created attachment 123484 [details] [review] Implement GtkToggle and adjust widgets This is a mostly complete implementation of GtkToggle, probably one or two things I didn't do right. And I didn't patch GtkCellRendererToggle and not much testing.
I dont think that the implementations need to override the property and print a warning, the docs say it has no effect to set inconsistant on a toggle button for example, that is a lie if it results in a warning. (and btw, you can have a proper class_init() for your interface now, no more need to pull that if (initialized) trick...) Also; is it a good practice to install properties that match the names of already existing properties on the implementing classes ? maybe, in this particular case its ok because the types happen to all match... Note my approach to GtkActivatableIface is to have the activatable widgets connect and register to "notify" on the actions, so if we can agree on that; there would be no application of the iface there... (i.e. the portion where we update toggle state is done by the proxy itself when appropriate). I wonder how a GtkToggleable will be used in real life, do you have some ideas of how we could put a toggleable iface to use ?
Created attachment 125138 [details] [review] Implement GtkToggle, revised (In reply to comment #4) > I dont think that the implementations need to override the property > and print a warning, the docs say it has no effect to set inconsistant > on a toggle button for example, that is a lie if it results in a warning. Agreed. What I did reflects that I was undecided how to do it. I decided now it should just be silently ignored, just like it is already described. > Also; is it a good practice to install properties that match the names > of already existing properties on the implementing classes ? maybe, > in this particular case its ok because the types happen to all match... I think it's fine for the very reason you state. I really wouldn't want to introduce a new set of properties for this. > Note my approach to GtkActivatableIface is to have the activatable > widgets connect and register to "notify" on the actions, so if we can > agree on that; there would be no application of the iface there... > (i.e. the portion where we update toggle state is done by the proxy > itself when appropriate). Note sure. I find having the implementor dealing with the actual state in this case more natural than connecting from the outside like applications. > I wonder how a GtkToggleable will be used in real life, do you > have some ideas of how we could put a toggleable iface to use ? Look at the subclasses in this patch that I implement GtkToggle for. There you have the primary use cases. On top of that any application or library specific subclasses that provide the same behaviour can now use the same API. The updated patch also implements GtkCellRendererToggle now, where I actually added a warning to the "radio" property to deprecate it. I'm not sure if it's ther best way, since from what I'm aware we don't normally deprecated properties at all, yet it seems wrong to just remove it in the next major version.
superseded by GAction and GtkActionable