In VisualWorks clients that extend existing menus can specify a 
'position' when they register their menu item. The default items leave 
some holes, so you can easily insert yourself. Something like this can 
easily be added to Squeak as well. Just let clients specifiy a 'desired 
position', and sort the items according to these positions.

PS: VisualWorks uses this in the menu pragma mechanism. Have a look at 
UILauncher to have a concrete idea. You do not need the pragma system 
in Squeak, but the positions idea can be put to good use here, and 
works out fine in VisualWorks. It is a pragmatic solution which is 
quite OK.

On Tuesday, Jul 15, 2003, at 00:16 Europe/Zurich, Bijan Parsia wrote:

> 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.
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org