On Feb 29, 2008, at 8:19 AM, Maximilian Albert wrote:
> Actually, I think the only question is if there is any scenario
> when new
> desktops shouldn't be activated right away. From what I understood by
> skimming through the rest of the code, they are activated but only
> a bit
> later, but the signals emitted are the same and I can't see any reason
> why emitting these slightly earlier should do any harm. In fact, as
> bug shows, the contrary seems to be the case because in the
> time some tools may query data from the wrong desktop (namely, the one
> that was activated before the new one was created).
I think the real problem is that that ACTIVE macros are used at all.
In the past I think Ted had also expressed a desire to remove
SP_ACTIVE_DESKTOP and its friends. I definitely feel that way.
One problem is that you break encapsulation. A component or widget
being used says "hey, I know who should be calling my from up higher,
so I'll peek out and find him". Among all the other problems, this
also makes things hard to use. You might pass in a few parameters,
but without inspecting the code it is hard to see what the bit will
use or go looking for.
Another problem is that this hardcodes the assumption that the thing
is a singleton being used for all desktops. This is exactly the sort
of thing that started getting in the way of the dockable dialogs. A
floating dialog version of a panel still should operate on the
"active" desktop's document, however all embedded ones should work on
one and only one desktop (the one it is embedded in). At the moment
this problem can be worked around by setting the active desktop for
those as active is changed, but you might get race conditions (like
might be the bug here), and you can also see things like docked
dialogs showing info on windows they are not actually docked in.
As Ted pointed out a while back, verbs have the desktop they are
called from as a parameter... so that should be passed on down and no
SP_ACTIVE_DESKTOP, IS_ACTIVE, etc, should be called. As functions
call sub-functions, instead of the desktop they can pass on in things
like the document, an object, etc. Limiting the type to the
"smallest" and most atomic needed.
So instead of having code "poll" to find out what the active thing of
the moment is, things should have the change in active desktop
"pushed" down into them. You might ask "what about the floating
dialogs?". That is simple. The *dialog* holding the panel should be
the one watching for "active" changes, and pushing that down into the
panel as it goes.
One additional refinement is that I think we need to get some
"contexts" that contain some data and an interface to get at that
data. At the moment we have "the whole big application", "the whole
editing window" and "the whole document". I'd like to see some that
are broken down to a finer degree. In fact, with the tablet support
I've got need of that already. As you switch what device you use on
the tablet, we switch tools. It would be nice to have a clean,
generic way to also switch in a subset of settings. That way the tip
of the pen could be the calligraphy tool set for drawing, and the
back could be the same tool but set for engraving, etc.