Finding a UIManager

At the moment, "UIManager default" delegates to Project current
uiManager, which looks like this:

Project >> uiManager
    "Answer the manager that provides user interface services for this project "
    ^ uiManager
        ifNil: [uiManager := Smalltalk
            at: #UIManager
            ifPresent: [:mgr | uiManager := mgr getDefault]]

I'm not sure why we do this. I guess it's to let different Projects
use their own UIManager. What I don't like is that this makes
ToolBuilder-Kernel depend on System (which depends on
ToolBuilder-Kernel). If I made UIManager default _not_ delegate to
Project, I could break this dependency. (ToolBuilder would then be
conceptually lower level than System.)

For instance,

UIManager class >> #default
    ^ Default ifNil: [Default := self getDefault].

Another option would be to push Project into Kernel, but I'm reluctant
to do that.

Thoughts? Alternatives?

frank

On 12/7/13, Frank Shearar <[hidden email]> wrote:
How would #getDefault look like?


>
> Another option would be to push Project into Kernel, but I'm reluctant
> to do that.
>
> Thoughts? Alternatives?
>
> frank
>
>

On 7 December 2013 19:43, H. Hirzel <[hidden email]> wrote:
It already exists:

UIManager class >> getDefault
"Ensure that a more specific manager can always be made by subclassing
a tool builder and implementing a more specific way of reacting to
#isActiveManager. For example, a BobsUIManager can subclass
MorphicUIManager and (if enabled, say Preferences useBobsUI) will
be considered before the parent (generic MorphicUIManager)."

    ^ (self allSubclasses
        detect: [:any | any isActiveManager
            and: [any subclasses
                noneSatisfy: [:sub | sub isActiveManager]]]
        ifNone: [])
        ifNotNilDo: [:mgrClass | mgrClass new]

frank

On Sat, Dec 07, 2013 at 07:23:12PM +0000, Frank Shearar wrote:
Right. A project as a UI manager. In particular, a MorphicProject
has a MorphicUIManager, an MVCProject has an MVCUIManager, and a
SeasideProject would have a SeasideUIManager. This needs to always
work whenever transitioning between different projects, because it
is generally not possible to open a debugger if something goes wrong.

That will not work. It will answer an instance of whatever flavor
of UI manager was in effect at the time that you cached it.

>
> Another option would be to push Project into Kernel, but I'm reluctant
> to do that.
>
> Thoughts? Alternatives?
>

Much of what you see is the result of work that I did under Andreas'
guidance to make MVC fully unloadable and reloadable. The corresponding
work to make Morphic unloadable and reloadable has not been done, and
was not possible at that time because MVC was too badly broken. Since
then, MVC as been restored to a state in which it can be used (although
not without problems), so it would be reasonable at this time to consider
making Morphic unloadable and reloadable. That will require significant
work, but the end result would be a huge step forward in modularity.

Aside from that, I have no preference with respect to package refactorings.
If you do change it, test to make sure that you can move back and forth
between existing Morphic and MCV projects (i.e. projects that you created
prior to the change), and also that you can open new Morphic and MVC
projects, and enter and leave them without error.

By the way, the "Smalltalk at: #UIManager ifPresent: [:mgr .... " idiom
is there to break a package dependency. It's not pretty but it works,
so it's something to keep in mind if you find yourself moving a class
to a place that it may not belong just to resolve a reference in a class
side utility method.

Dave