[squeak-dev] MorphicUIManager

Casey Ransberger casey.obrien.r at gmail.com
Sun May 2 22:22:56 UTC 2010


Interesting. Is the class variable used at all? If not, we should probably
remove it.

David: thank you very much for your reply. As you have some experience with
these classes, and are willing to make it happen, I'm going to continue my
quest in other classes:)

I am filled with joy right now.

On Sun, May 2, 2010 at 2:54 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Sat, May 01, 2010 at 07:14:54PM -0700, Casey Ransberger wrote:
> > Class comment is:
> > "The Morphic ui manager."
> >
> > This comment is beyond useless. I'm glancing over the methods it exposes.
> > Looks like it specializes a generic UIManager for morphic... and there's
> a
> > similar MVCUIManager, comment is similarly useless.
> >
> > Ah, the base class has a comment.
> >
> > "UIManager is a dispatcher for various UI requests."
> >
> > Do I take it the usual way of getting a UIManager is to send #default to
> the
> > base class?
> >
> > Thinking I'm going to add (at the least) a note to both subclasses saying
> > "See the class comment in UIManager for more information." Technically
> this
> > is true as it *does* have *slightly* more information. Then I'm going to
> > mess around with it to get a sense for what it can do, and then expand
> the
> > comment some.
> >
> > Anything folks think I should know about this class before I go writing
> > damned lies about it? :P
>
> Well this turns out to be a very interesting question. I had done some
> work with UIManager in the course of refactoring some of the MVC stuff
> to make MVC unloadable, so I figured that I aught to be able to explain
> how it works. So I wrote a draft method comment explaining how I *thought*
> it worked, and then did some double checking to make sure that the comment
> matched reality.
>
> It turned out that my comment did not match the implementation, and
> this led me to notice that he implementation is actually somewhat broken.
> I had expected that UIManager was swapping in the appropriate type of
> manager (MVC or Morphic) whenever you switch projects, and that UIManager
> has a Current class var that should point to the currently active
> manager. But in fact the implementation is incomplete here, and every
> time we make a reference to "UIManager current" we create a new instance
> (after figuring out what kind on instance to create), and the result
> is never actually cached in Current at all. This works fine, but it is
> confusing (and inefficient), in that UIManager appears to be caching the
> current manager, but in fact does not do so.
>
> I tried fixing this so the cached Current value would be used, but the
> result felt rather kludgy. I think that a better approach is to simply
> associate an instance of UIManager with each project.
>
> I will post fixes to trunk and add the following class comments:
>
>  UIManager comment:
>    UIManager is a dispatcher for various user interface requests, such as
>    menu and dialog interactions. An instance of UIManager is associated
> with
>    each Project to implement the appropriate functions for Morphic, MVC or
>    other user interfaces.
>
>  VMCUIManager comment:
>    MVCUIManager is a UIManager that implements user interface requests for
>    an MVC user interface.
>
>  MorphicUIManager comment:
>    MorphicUIManager is a UIManager that implements user interface requests
>    for a Morphic user interface.
>
> Dave
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100502/2a0c8bec/attachment.htm


More information about the Squeak-dev mailing list