ToolBuilder, PlusTools and Namespaces
Michael van der Gulik
squeakml at gulik.co.nz
Fri Feb 9 08:14:25 UTC 2007
Andreas Raab wrote:
> Michael van der Gulik wrote:
>
>> - It appears that the Morphic tree widget from ToolBuilder doesn't
>> support drag and drop yet. Is this correct? Is there a version out
>> there of ToolBuilder with a Morphic tree widget that supports drag and
>> drop, or is this something I'll have to fix up?
>
>
> The latest version at http://squeaksource.com/ToolBuilder should support
> drag and drop.
That's the one I have. Is there an example of a PluggableTreeSpec which
supports drag and drop? There still exists the possibility that I'm
simply not using it right.
Otherwise I should have drag and drop working on this tree tonight.
>> - ToolBuilder uses a lot of configurable method callbacks: when
>> constructing a UI, the constructor specifies which methods on the
>> model respond to which events. Was it ever considered to hard-code
>> these method names so that the model *must* implement them, or
>> subclass something which does? Arguably that would make code more
>> readable - it is guaranteed that a method of a particular name
>> implements that particular callback making the callback easier to find.
>
>
> Wouldn't that mean you can only have a single widget of each type per
> model?
Yes. That is a situation I didn't consider.
> What would happen (for example) to browsers which utilize four
> lists out of the box?
My style of design here would be to have a model object for each list,
each of which observes the list to it's left (in the case of the
Browser). That would make each list much more plug and play - consider
that you can mix and match these lists to make your Package browser,
standard browser, single-class-only browser, inheritance hierarchy
browser, Namespace browser, "specific list of classes" browser, and so
forth.
Unfortunately, what you gain in plug+play you lose in the explosion of
classes; you'd need a separate class for each list.
On futher thought, you've convinced me that it's currently done the
right way. I can think of other examples where having hard-coded event
handlers would make things difficult. What would be nice would be to
have a convention for naming event handlers, perhaps with defaults that
get picked up automagically?
Michael.
More information about the Squeak-dev
mailing list
|