*ListMorphs

Daniel Vainsencher danielv at netvision.net.il
Mon May 5 10:24:47 UTC 2003


It sounds right. I'm just saying you should remember to keep the
model/morphic borders more or less where they are now.

If you keep whisker's use of morphs, it is probably right.

What I meant in detail -

A domain object is the object that represents whatever your application
is about. For example, in the browsers, the domain objects are lists of
names of categories, methods, classes. Why lists of the names, and not
of the class objects or method references? because PLM expects to get
strings, it can't deal with most kinds of objects(*).

So for a concrete example, when the users chooses to remove an object
from a list, the domain object should be modified directly, and the UI
should be updated from that. Is that clearer?

(*) This is another limitation that it would be nice to be rid of. That
was the idea I'd implemented - PLM's could be configured with an
transformer object that can be sent a domain object, and produces an
appropriate morph. This fixes both the "recieves only strings" and the
"displays only string morphs" problems.

Daniel

tbr at mannynkapy.net (Tom Rushworth) wrote:
> On Mon, May 05, 2003 at 01:48:53AM +0200, Daniel Vainsencher wrote:
> > One thing you might consider is that your list should probably be of
> > domain objects, represented by morphs, not a list of morphs. You might
> > find the SM package ColorDevTools (CDT) intersting.
> 
> I'll take a look, but you can probably help me reduce my ignorance a
> little faster by elaborating on what you mean by "domain objects,
> represented by morphs".  I stole shamelessly from the Whisker Browser,
> so the morphs in my list of morphs are relatively small wrappers around
> the non-morph objects containing the information I want to display. Is
> that what you mean, or am I hopelessly lost?
> > 
> > I think this is generally an important direction, because more
> > expressive lists would make many interfaces more useful.
> > 
> > Daniel
> > 
> > tbr at mannynkapy.net (Tom Rushworth) wrote:
> > > On Sun, May 04, 2003 at 01:58:20PM +0100, Paul Chapman wrote:
> > > > Are there any plans to build versions of the various list morphs
> > > > which draw their rows directly instead of using a submorph for
> > > > every row?  For large lists the current implementation is very slow!
> > > 
> > > There are some LargeList enhancements floating around.  Check the
> > > list archives and the swiki.  My apologies for not having the
> > > references handy.
> > > > 
> > > > Cheers, Paul
> > > > 
> > > While we're on the subject of ListMorphs, all of the list morphs seem
> > > to expect the submorphs to be string/text morphs, and seem to provide
> > > the submorphs with (effectively) infinite width.  I want to display a
> > > list of more complicated morphs where each submorph is a window with
> > > 3 (or more) panes.  I want the submorphs to be laid out proportionally
> > > in the horizontal direction, but to be fixed size and scrolled in the
> > > vertical direction.  (For anyone who has used Quicken, think of how the
> > > list of transactions in an account is displayed.)
> > > 
> > > I just got such a morph working yesterday, but I had to make changes
> > > all over the place :(.  Now that I've proved to myself I can do it :),
> > > I can ask the list: is there an obvious, easy way to do this?  One that
> > > doesn't involve a dozen new classes and changes to many old classes?
> > > 
> > > Also, what should this morph be called?  I've called it the
> > > "PluggableMorphListMorh" in the sense of pluggable(MorphList)morph, not
> > > because I like that name (I don't) but because I couldn't think of anything
> > > better.  Suggestions anyone?
> > > 
> > > If anyone's interested, I'll post it once I get rid all the cruft and
> > > dead end code from the things I tried that didn't work.  Right at the
> > > moment I don't think my pride could handle someone else looking at it :).
> > > 
> > > Regards,
> > > 
> > > -- 
> > > Tom Rushworth
> > 
> 
> -- 
> Tom Rushworth



More information about the Squeak-dev mailing list