GNOME Bugzilla – Bug 532795
GtkActivatable should provide a unified definition of the "activate" signal for 3.0
Last modified: 2013-11-11 05:27:14 UTC
In GTK+ 3 there should be a real GtkActivatable interface instead of the class variable GtkWidgetClass->activate_signal. See also bug 468689 for a replacement of GtkWidgetClass->set_scroll_adjustments_signal.
Created attachment 110780 [details] [review] Introduce a GtkActivatable interface with as less changes as possible. Deprecated widgets are probably broken.
Comment on attachment 110780 [details] [review] Introduce a GtkActivatable interface with as less changes as possible. Looks incorrect, wrong bug?
Created attachment 110781 [details] [review] Introduce a GtkActivatable interface with as less changes as possible. (The previous patch was the wrong one) Deprecated widgets are probably broken.
Hi, Matthias pointed out to me that we were somehow working on the same thing, same same but different... (see bug 560228 about some work I did cleaning up GtkAction code with activatable iface...) Anyway, I had some thoughts on the activate signal while plowing through all that activatable code, so I'll paste them here from the other bug: ================ The bug on bug 532795 targets 3.0 and... I'm not sure what we can do so far as api breaks, I wonder, if a button and an expander use "activate" to do something, while a menu or an entry clearly use "activate" to denote user input (i.e. useful "activate" to listen to...) if its a good idea to mix this implementation into an interface. I would really like that kind of thing to be resolved for 3.0, "activate" should mean user activated, or it should mean do a fancy dance (I would really like the name "dance" for this actually ;-)) or it could even mean both... ================ I would really like to land activatable for 2.16 (mostly for gtkbuilder purposes) with or without the signal - am I totally off mark with the signal's conflict of meaning ? (I dont think a button "activate"s when its clicked by the user...)
Hm, yeah the activate-signal is used for multiple purposes (signal user input, react on key bindings, etc.) so it is probably better to not convert it into a new interface with the same problems but to add better implementations.
Some additional thoughts... Since I saw GtkEntry's new icon behavior, I think that it should also be activatable and emit some unified "GtkActivatable::activate" signal (probably for a combination of icon-pressed/icon-released with a monitored enter/leave notify like GtkButton does for "clicked")... along the same lines I think it would be very interesting to make a GtkTextAction that could be used to represent a string... that may or may not be modifiable by its proxies. another thought, is the signal name "activated" available ? if we had consensus that we wanted "activated" signals strictly to notify user input or state changes, it could be a good alternative name for a unified "get it right" implementation.
GtkActivatable exists now: http://library.gnome.org/devel/gtk/stable/GtkActivatable.html Should this bug title be updated?
Updating bug title and description for clarification. This would be IMHO a very good thing to deal with before 3.0; provided the implied api breaks are acceptable... The problem here is we have a divergence in the meaning of the "activate" signal: a.) notifies that there should be an action activated for this proxy. b.) notifies the proxy that it should do a dance and provide feedback for it's underlying action which was somehow activated. Would be nice to have a unified implementation of the "activate" signal and possibly an added separate "dance" signal for the latter interpretation of the "activate" signal.
I think the answer here is GAction
Or rather GtkActionable, the new GtkActivatable replacement which basically does what GtkActivatable does, but for GActions. In either case, we still have the same confusing issue where some concrete widget classes declare an "activate" signal, while some of these classes use it as an indication that the proxy itself should "do a dance" and other classes use it to notify that the user requested some activation. This doesnt just go under the rug just because we reimplemented actions all over again... suggest we rename this with 's/GtkActivatable/GtkActionable/' instead of closing.