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.