ToolBuilder, PlusTools and Namespaces

Hi all.

I'm making a version of the PlusTools that support nested Namespaces.

- 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?

- Tree widgets can be simulated using a list - just expand it totally and add indents to each item. It is reasonable to make tree support mandatory for implementers of the ToolBuilder API? They're very useful and used in the Object Explorer, which is IMO a required tool.

- 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.

Michael.

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.

> - 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? What would happen (for example) to browsers which utilize four
lists out of the box?

Cheers,
   - Andreas

Andreas Raab wrote:
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.

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.

Michael van der Gulik wrote:
> Andreas Raab wrote:
>> 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.

I don't have an example handy but IIRC then PlusTools used drag and drop
for regular browsers.

> 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?

You just realized one of the things that I really wanted to address in
Tweak. A way of not having to specify endless callbacks and yet to react
flexibly to standardized events in widgets. Welcome to method triggers,
which provided a standardized way of specifying which method should fire
in response to what event ;-)

Cheers,
   - Andreas