W dniu 4 lipca 2011 00:29 użytkownik Jon Cruz <jon@...18...> napisał:
So if a verb for a specific document is disabled, then multiple actions in multiple windows can automatically cascade to be disabled, etc.
I digress a bit, but the concept of having multiple editing windows for one document is fundamentally broken on very many levels; not only does this introduce additional complications, it can introduce severe confusion and lead to accidental data loss. (E.g. you opened the same document 2 times, made some changes to one of the versions and saved it, you then wanted to make different changes in the second window but the original was gone - FAIL)
One key point here is that verbs are abstract and operating at the document level. They do not directly deal with any UI issues (aside from the two methods get_action() and delete_view() which need to be refactored to live elsewhere). Contrast that with a GtkAction object which is completely about UI issues, including being able to create and maintain other GtkWidgets on demand for various UI scenarios.
GTK 3 has a GAction interface implemented by GtkAction, there is also a GSimpleAction implementation which can be used in non-GUI applications when there is no use for the UI stuff. Using GtkAction does not require a working X display as long as you initialize GTK correctly (there is a different init function that doesn't open the display) and don't create any proxy widgets.
So in this case "some systems" includes "even certain subsystems of GTK itself", in addition to various third-party extended tools.
When you wrote "systems" I was thinking about platforms (e.g. Mac, Windows) rather than functions in GTK. I hope this is improved with recent releases of GTK.
My guess, though, is that It appears you were thinking of C subclassing and of C++ and Gtkmm where one might want to rewrite EgeAdjustmentAction as a subclass of Gtk::Action (not GtkAction). In that case we get a far worse problem than the the one that you started to point out. The worse problem is where gtkmm objects often will only behave in an extended way if one *only* calls them from the gtkmm C++ pointers and will lose all extended behavior when called from the wrapped C object.
This only happens when the gtkmm bindings don't support the relevant GObject virtual functions / signals. Subclasses of Gtk::Action work as expected, while subclasses of Gio::InputStream don't (no vfunc support for this object).
(oh and when you said "EgeAdjustmentAction could be rewirtten" did you not catch that it was already a subclass of GtkAction, or were you thinking of using C++ and rewriting it as a subclass of Gtk::Action?)
I didn't catch that it was a GtkAction already, I think I confused it with something else. But subclassing Gtk::Action instead would also be an improvement.
Regards, Krzysztof