On Feb 9, 2009, at 12:37 PM, Krzysztof Kosiński wrote:
> There are some instances where a generic verb is more appropriate.
> I don't understand this bit, can you explain?
I'll have to dig through lots of old notes to come up with some
precise details. I'd gone over this a while back when someone else
had been asking about Verbs, SPActions and GtkActions.
>> Additionally, SP_ACTIVE_DESKTOP is an older C-style approach that we
>> really need to try to purge.
> It is a macro so it can be replaced with a call to the application
> that will return a refpointer to the currently activated
> desktop/view/document. I also don't see anything wrong with being
> able to
> globally know the active desktop.
That's the "how" of an implementation.
What we need to look at is the "why" at the higher level. That's
where the problem is.
Right off hand you have the equivalent of a global variable - the
"active desktop". And for many many reasons, including multi-
threading, globals are bad.
Additionally encapsulation and modularity are broken, as a tiny
subcomponent says "Hey, I know that I belong to some editor window
somewhere and that it is an Inkscape object, and should have these
other links to other objects"
The proper approach is to have modules that know only what it is they
do, with no idea of where the context they operate on came from. This
makes them more robust, more thread-friendly, easier to test, and
more reusable. They should be small building blocks that can be
combined in different ways by things that might need to use them
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.
If you want to have a floating palette window, the "active desktop"
tracking only partially works, with different operating systems
having different concepts of what "active" means. Now go and add in
the ability to dock a dialog, and we get some very ugly problems. For
some dialogs if you open an embedded one in each of those windows and
then focus different windows, you'll see strange things happening.
The fix for this is to have the dialogs be handed a 'context' to
operate through. This could be the SPDesktop pointer, or could be
something different. The point is, the dialog gets handed an object
that implements an interface it needs to use, instead of the dialog
grabbing a global pointer that changes from moment to moment. 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
Switching to that no-more-globals approach will gain better
functionality with less code and fewer bugs.
>> Also, not all actions are GUI actions. Instead take the view that
>> they are document actions, and some will manifest in the GUI. It's
>> possible to get some that mainly get activated from a script or from
>> the command-line.
> The concept of the active desktop is still valid in command line
> mode, e.g.
> an abstraction over the file being open or processed now. Multiple
> are not present in command line mode either. Also, Gtk::Action is not
> GUI-specific. You can leave the icon, label, etc. undefined, and
> you can
> init and use GTK without a display.
The key is a Document. A Document can have many open Desktops. A
Desktop is a UI-centric widget keyed to editing a Document.
Also, by it's very nature a GtkAction *is* a gui element. The "Gtk"
layer has been split out from GLib, GObject, GdkPixbuf, and GDK. The
Gtk grouping is generally for widgets (aka UI elements). 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.
I would say that GtkAction is very comparable to Swing's Action
interface. Action is in the javax.swing package, but is extended from
EventListener which lives in the more generic and lower-level
True, you *can* use GtkAction without gui specifics if you want, but
then you'll be skipping over half of it's API.
Oh, and for more madness on the "active desktop" front, consider
multi-threaded scripts and extensions operating within the gui but
with a live DOM/tree hooked. eeek!