On Monday 14 July 2003 10:36 am, Bijan Parsia wrote:
> > this needs to
> > already have a place where applications can register extra
> > action, without modifying image code. Dynamic menus do this in a
> > very specific way for one menu, the question, in my mind, is how
> > to generalize it properly to the many menus that should be
> > dynamically extendible...
>
> Yep.
>
> Hmm. On the keymap model, assuming that all menus are invoke
> through a key/mouse map, you could add/overide the specific menu
> code.
>
> So, right now, *my* extending a menu that, say, i inherit, is easy
> (as long as I can get a hold of the relevant menu object, I can add
> items, delete items, etc. before popping it up). The problem with
> manipulating someone else's menu is that it doesn't normally pass
> through my hands. If it always passed through a keymap, and I can
> add/chain arbitrary keymaps, then I'd have a natural place to put
> menu manipulation code.

I posted a (dubious) hack some time ago that allowed you to extend and 
otherwise modify existing menus, with no changes to existing methods 
that created menus. Apparently no one tried it out.

What it did was to look at the call stack (that's why I called it 
"dubious") to identify what menu it was (that is, the class of the 
menu creator and the method it was being created in). Then you could 
register handlers for menus by where they were created...

It's attached for your amusement. It still works in 3.6.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hooker_3_2-nk.1.cs.gz
Type: text/x-squeak-changeset
Size: 3826 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030714/2b3960e8/Hooker_3_2-nk.1.cs.bin