> That brings up another question: I frequently hesitate to create a 
> new class, especially if it is only for "internal" reasons. Maybe I 
> should just go ahead. 

Much of Morphic is pluggable at the object level; the EventHandlers 
are set up for this, as are the properties. Unfortunately, 
SimpleButtonMorph's response to mouseDown is not (though if you mark 
it as a parts donor it won't respond to mouseDown events).

Perhaps you should try marking it as a parts donor:

myButton isPartsDonor: true

though I still don't understand what a SimpleButtonMorph that doesn't 
handle mouse events does that is any different than, say, a TextMorph 
inside a BorderedMorph.

> OTOH there is some good reason behind my hesitation: for another 
> person it will not be obvious which classes are ment for public use 
> and which are for internal use. 
> 
> Now you may argue that every class is for public use, but still: 
> seeing a screw and a car engine on the same parts list may make the 
> list hard to read, especially when there are many more screws than 
> car engines on the list and you really are interested in the car 
> engines only. 
> 
> Is there a solution for that ? 

Class categories or modules would seem to present a solution, though 
there's not much use of them for hiding internal classes yet. You can 
look at (for instance) the category "Morphic-Text Support" which 
appears to have all internal classes.

I'd be in favor of having sub-categories that hide "internal" classes 
(i.e. not usefully part of the external interface).

Also, as far as Morphs go, ones that are made for end-user use 
generally appear in the Objects tool (i.e. their class responds to 
descriptionForPartsBin or supplementaryParts Description), and they 
tend to return true to includeInNewMorphMenu.