On Jul 3, 2011, at 12:37 PM, Krzysztof Kosiński wrote:
2011/7/1 Jon Cruz <jon@...18...>:
However, there are a few things that the verbs do that GtkAction does not. Conceptually it is slightly higher level. Also being able to be associated with more than a single view can be helpful. Consider the case where you have a single document, but multiple windows open editing that at the same time.
GTK docs say in this case you should create a separate set of GtkActions for each window.
Yes, exactly. So that is at a *lower* level of the physical UI widgets of a single window. Verbs operate at the higher level of potential operations on a document.
So if a verb for a specific document is disabled, then multiple actions in multiple windows can automatically cascade to be disabled, etc.
If an author is writing some code to operate on a document, then having to stop and think about chasing down multiple UI widgets and owning instances gets bad. It also breaks modularity and encapsulation.
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. So a GtkAction ties up some abstract functionality along with a lot of UI specifics. This is similar to Java's Action interface or Qt's QAction class, but with the addition of GtkAction also having the methods to act as a factory where Qt and Java left that pattern separated.
*Also* using separate GtkActions for each window is essentially what we have going in our code now. There are per-window GtkActions in use, and then we also have the legacy per-View SPAction that is more a one-to-one correlation to GtkAction. SPAction is the main class that is a candidate for folding into replacement with GtkAction, while Verb is still conceptually different..
A different issue you should look into is exactly *which* GtkActions are allowed. Some systems only support stock GtkAction classes that come with Gtk, whereas Inkscape has several custom GtkAction subclasses.
Which "some systems"? If you can compile a GTK application, you can also write custom subclasses of GtkAction, for example EgeAdjustmentAction could be rewritten as a subclass of GtkAction. The only caveat is that gtkmm might not expose 100% of functionality available through the C API.
I think you missed a bit of the subtle issues here.
Currently EgeAdjustmentAction already *is* a custom subclass of GtkAction. It adds a fair bit of functionality, however certain other code that *consumes* GtkActions may not handle things that EgeAdjustmentAction does. For example, some revisions of GTK itself had problems dealing with GtkWidgets created from custom GtkActions. Some of the GTK code itself was incorrectly assuming the created widgets would be of a specific base type and we would see hundreds of warnings thrown out on the command line when running under versions of GTK that did not yet have that fixed.
So in this case "some systems" includes "even certain subsystems of GTK itself", in addition to various third-party extended tools.
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. (A simple way to test that is to take a C++ gtkmm subclass pointer and call gobj() on it. Use the returned C instance pointer with the C GTK API and see what breaks).
For many things, as soon as one switches from the C++ world and back to plain C GTK+ land, all extending gets lost. So if one wanted to use gtkmm subclassing of Gtk::Action one would need to only use tools (e.g. for OSX menu integration) that were solely C++ and gtkmm and could not count on general GTK-based ones. *However* one would also have to keep in mind that any C/C++ mismatch problems would be in addition to the common ones of using extended GtkAction subclasses that were solely operating via C. So you would end up with two or three sets of problems and not just one.
(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?)