On Mon, 14 Jul 2003, Lex Spoon wrote:

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

Piffle. What "we" can you possibly be talking about, given that at least
four people have expressed such desires and two posted code from prior
efforts in this direction.

So, you and maybe some other people who I'm sure can and will chime in
feel this way.

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

And there's the open menu itself.

[snip]
> 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.

I've often wanted to change, augment, or override squeaks key commands for
specific projects/editors/etc. All the time, in fact. It's horrifically
painful as it stands.

>  (Which seems fine, btw!  Do we really want multi-key
> combinations in Squeak's text editor?!)

Sure. Why not.

>  Furthermore, the design of the
> keystrokes can be done much better if a single person arranges them all,
> than if they are registered.

Not for my application.

Not if I want to change the keystrokes overall, and in a friendly way.

> To give an example of what happens to the UI under generalization, just
> look at the open menu in Squeak:
[snip current problems]

Actually, this is exactly what I meant my UI issues. One hopes a better
mechanism, plus some best practices and conventions, would do better.

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

Er...Actually, you think wrong. I certainly don't *have* to admit.
Considering what some of the not-worst-but-God-not-good UI designers have
done, you misestimate them.

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

You've been pretty light on what the penalties could be, and pretty strong
on the idea that the only way to avoid them is to avoid improving things
on the programmatic side of things. I find this uncompelling.

(False generalization comes with a penalty too! "we" indeed :))

Cheers,
Bijan Parsia.