GNOME Bugzilla – Bug 768228
not finished GAction
Last modified: 2018-05-02 17:14:45 UTC
Missing Action Helper class GAction behavior is great idea. Somewhere in application, there could be action, and someone element (Widget or System menu item) could activate it, optionally with some data. But there is no support class, or widget method, which could help programmer to activate action someone in application. So I use hack in Formiko, when i get top_level_window for win prefixed action, or next get_application for app prefixed action. If i want to use my own action groups ... So I don't need actions now :-( Default states from action Many (probably all) widgets could get states from stateful actions, but there is bug, so sometime radio buttons activate another radio button in group, when that is active, but it should not be. (GTK+ 3.14.5 in Debian Jessie) No different between activate and change-state I expect, that if radio button group change state, i got only new state - mistake :-( So radio buttons activate / set state on actions, when change it's state from active to not active too. Missing automatic check button action states It could be so nice, if check button or switch could send it's activate state to boolean stateful action. Missing signal connection to action from widgets That's great when widgets set it's state from action at probably realize time, but they not track action state. So if somewhere in application, is two sources for stateful action, they don't refresh own states. I'm not sure how can i split this "bugs", I'm not sure if i can call this comments bugs. So here it is.
Look at the GtkActionable interface. That is implmented by widgets for which it makes sense to hook them up to an action.
(In reply to Matthias Clasen from comment #1) > Look at the GtkActionable interface. That is implmented by widgets for which > it makes sense to hook them up to an action. Yes GtkActionable is fine, but, it is only interface, that i must implement methods for set and get action and target value. Nothing else :-(
As i discovered, stateful action really could re-states some widgets. But only by another actionable widget. If i try to activate, or change state action manually (in some reset to defaults method), that create cyclic activating of action.
(In reply to Ondřej Tůma from comment #2) > (In reply to Matthias Clasen from comment #1) > > Look at the GtkActionable interface. That is implmented by widgets for which > > it makes sense to hook them up to an action. > > Yes GtkActionable is fine, but, it is only interface, that i must implement > methods for set and get action and target value. Nothing else :-( I am telling you that many widgets (GtkButton, GtkMenuItem, etc) have done this for you already. In any case, I think this is not really suitable material for a bug.
(In reply to Matthias Clasen from comment #4) > (In reply to Ondřej Tůma from comment #2) > > (In reply to Matthias Clasen from comment #1) > > > Look at the GtkActionable interface. That is implmented by widgets for which > > > it makes sense to hook them up to an action. > > > > Yes GtkActionable is fine, but, it is only interface, that i must implement > > methods for set and get action and target value. Nothing else :-( > > I am telling you that many widgets (GtkButton, GtkMenuItem, etc) have done > this for you already. Yes, and if I want to create new actionable widget ? I can't. If i want to activate action somewhere in application, i can't. Why ? Because i must list all widgets in application, and find action group, with the right prefix... > In any case, I think this is not really suitable material for a bug. So now, i miss tools (classes or functions) to do that. I must write myself, but GTK has that.
(In reply to Ondřej Tůma from comment #5) > Yes, and if I want to create new actionable widget ? I can't. If i want to > activate action somewhere in application, i can't. Why ? Because i must list > all widgets in application, and find action group, with the right prefix... I don't follow. Yes, if you write a new new actionable widget that does not derive from a GtkActionable implementation, you'll have to implement it yourself. But that is literally two properties, plus a bit of glue to call gtk_action_activate when your widget gets activated. I don't see the complication.
(In reply to Matthias Clasen from comment #6) > (In reply to Ondřej Tůma from comment #5) > > > Yes, and if I want to create new actionable widget ? I can't. If i want to > > activate action somewhere in application, i can't. Why ? Because i must list > > all widgets in application, and find action group, with the right prefix... > > I don't follow. Yes, if you write a new new actionable widget that does not > derive from a GtkActionable implementation, you'll have to implement it > yourself. > > But that is literally two properties, plus a bit of glue to call > gtk_action_activate when your widget gets activated. I don't see the > complication. First, gtk_action_activate is deprecated, and uses GtkAction. Second, i must call g_action_group_activate_action on ActionGroup, which could be Gtk.Application (app prefix), Gtk.ApplicationWindow (win prefix) or ANY other widget with it's own prefix. And there is secret class ActionHelper, which what i see, does exactly what programmer need, when he want to activate action anywhere in application. So now, at the moment, i must split action name, get prefix, and if it "win", i must call get_toplevel to get the action_group, if is "app" prefix, i must call get_application on window to get the action_group, and if is ANY other group, i must get it somewhere where it is. So, please, tell me, why i MUST rewrite the code in my application, which is in GTK, but i can't to use it? So what programmer need, is to call function like gtk_activate_gaction(const gchar *action_name, GVariant *parameter).
(In reply to Ondřej Tůma from comment #7) > (In reply to Matthias Clasen from comment #6) > > (In reply to Ondřej Tůma from comment #5) > > > > > Yes, and if I want to create new actionable widget ? I can't. If i want to > > > activate action somewhere in application, i can't. Why ? Because i must list > > > all widgets in application, and find action group, with the right prefix... > > > > I don't follow. Yes, if you write a new new actionable widget that does not > > derive from a GtkActionable implementation, you'll have to implement it > > yourself. > > > > But that is literally two properties, plus a bit of glue to call > > gtk_action_activate when your widget gets activated. I don't see the > > complication. > > First, gtk_action_activate is deprecated, and uses GtkAction. Second, i must > call g_action_group_activate_action on ActionGroup Sorry, I typoed here. I meant the GActionGroup api
Yes, but please, tell me: How can i get GActionGroup object from action name ?! That is the problem! It is so nice, that there is the function, which I can call on GActionGroup, but i must somehow get the GActionGroup object!
(In reply to Ondřej Tůma from comment #3) > As i discovered, stateful action really could re-states some widgets. But > only by another actionable widget. If i try to activate, or change state > action manually (in some reset to defaults method), that create cyclic > activating of action. I know for a fact that this is not the case, if the relationship between widget and action, and the activation/state change, are done in the correct way. (and no manual guarding is required.) Can you explain what you did that led to this infinite loop? (In reply to Ondřej Tůma from comment #9) > Yes, but please, tell me: How can i get GActionGroup object from action name > ?! That is the problem! It is so nice, that there is the function, which I > can call on GActionGroup, but i must somehow get the GActionGroup object! Groups know which Actions they contain, but the converse is not true. It could get messy to try to make the relation 2-way. Still, if you think you can make it work, a patch is always welcome... :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/639.