Flexible squeak - a call for extension mechanisms

Lex Spoon lex at cc.gatech.edu
Mon Jul 14 21:49:21 UTC 2003


IMHO, we should add hooks sparingly and as we need them.  We don't
really want everything to be customizable.

Regarding the menus, I am looking at the World menu and I see hardly
anything that should be extended by multiple packages.  open, yes. 
objects/new morph, yes.  But debug?  flaps?  projects?  authoring tools?
 playfield options?  Leave them un-extensible.  If someone wants to mess
with those menus, then they can have a discussion with whoever owns the
package defining those menus.

I don't see a good case for extensible key strokes in the text editor. 
There shouldn't be many extensions, because Squeak only has 1-character
key combinations.  (Which seems fine, btw!  Do we really want multi-key
combinations in Squeak's text editor?!)  Furthermore, the design of the
keystrokes can be done much better if a single person arranges them all,
than if they are registered.


To give an example of what happens to the UI under generalization, just
look at the open menu in Squeak:

	1. The items are completely unsorted.  It used to be that, for example,
thet Internet clients all showed up in the same part of the list.

	2. The items use different capitalization, making them harder to read. 
(IRC chat, Package Loader, web browser)

	3. The items use generally different styles of description.  Some of
them use acronyms (VMMaker), while others spell out the tool in extreme
detail (Bug Fixes Archive Viewer).


I actually like the open menu registry, but I think we all have to admit
that the worst UI designer in the world could have done a better job if
all this was centralized.


Let's be light on the hooks, *especially* in matters that pertain to the
user interface.  Generalization comes with a penalty.


Lex



More information about the Squeak-dev mailing list