Jon A. Cruz wrote:
Now, a more concrete example is one of the problems we face today. Say you have two documents open, with one of them having two views.
That's another thing I don't understand, what is the difference between a document and a view? I presume that a document represents an SVG file, while a view represents a window in which that document is open. Why documents originally opened from the same file are treated differently than documents opened from distinct files?
For the case of an embedded panel/dialog that would simply get the context of the desktop of that window. However, for a floating one, an external class could listen for changes in the active desktop and then set the new context in to the floating dialogs as needed. So we just need to flip from polling a global variable to instead push an explicit context in.
Switching to that no-more-globals approach will gain better functionality with less code and fewer bugs.
The key is a Document. A Document can have many open Desktops. A Desktop is a UI-centric widget keyed to editing a Document.
Why do we treat desktops that show different files differently than desktops showing different files? Is this to reduce memory usage in some corner case where the user has the same file open multiple times? If I open icon.svg two times in the same instance of Inkscape, I would expect them to be independent, e.g. when I edit one of the copies the other is not affected in any way. Why do we need to keep track of whether two desktops are editing the same document?
Also, by it's very nature a GtkAction *is* a gui element. No, it is not. Gtk::Action has no GUI elements, but provides methods that generate menu widgets, toolbar widgets, etc. One Gtk::Action can have multiple GUI elements that can be used to activate it, but by default it has none.
Although
GtkAction does not directly derive from GtkWidget, it does include such members as "is_visible", "is_sensitive", "set_accel_path" and has several methods that return GtkWidgets. (...) True, you *can* use GtkAction without gui specifics if you want, but then you'll be skipping over half of it's API.
So does SPAction. It has a function to set whether it is sensitive and "active" (I have no idea what that means). It is still used in console mode. By the way, I also discovered an oddity called InkAction, and it looks like this is a subclass of GtkAction that is generated from SPAction for use in menus, so we have three levels of things, while I think that one (Gtk::Action) could be sufficient.
By the way, Gtk::Actions can also be document-specific. We can have multiple Gtk::ActionGroups, e.g. one for each desktop. That's even the recommended thing to do in GTK documentation. A Gtk::Action also contains a pointer to the ActionGroup it belongs to, so if we subclass ActionGroup to contain a desktop pointer, we can find out the desktop given only the Action.
Regards, Krzysztof Kosiński