2010/3/3 Jon Cruz <jon@...18...>:
"UsabilityManager" makes no sense, and neither does "UserExperienceManager". I think it makes a lot of sense. It "Manages the user experience".
What does "managing the user experience" actually mean? If you want a class called "UILayoutManager", it's acceptable. But "managing the user experience" has no meaning that can be expressed in code.
Also I think *how* the current style widget is updated has a good example. Instead of "peeking out" via SP_ACTIVE_DOCUMENT() or such, the widget has it's dependency "pushed in" via its setDesktop() call. In theory we could do a simple floating dialog that creates and holds a single current style widget. That floating dialog could listen for the "active" desktop to change and then when it hears an update that dialog can turn around and "push down" into the current style widget by calling setDesktop() on it. That's the kind of approach I'm trying to look at.
The idea of re-attaching the floating dialog to a different window is worrying me. Either the dialog should be assigned to some window and stay assigned to it until it's closed, or the dialog should always be assigned to the currently active window. In the first case the desktop should be a construction parameter of the dialog. In the second case using SP_ACTIVE_DESKTOP or an equivalent together with a change signal is OK. If we store the desktop locally and change it using setDesktop() we are at risk of getting out of sync in some obscure code path. I still don't see how an "user experience manager" class might help here.
It doesn't matter whether you use setDesktop() or a construction parameter - there's still a dependency on SPDesktop, and it cannot be removed.
Regards, Krzysztof