On Mon, 14 Jul 2003, Daniel Vainsencher wrote:

> [keymaps, chaining in DrScheme]
> Hmm, I read the urls given, but having no experience with it, and it
> being a little sparse, I'm not sure I understood what I was reading, and
> definitely didn't get a sense of what it's like to use. Can you explain
> this a little?

Well, maybe. It's been a while. Roughly keymaps (which work, I believe,
for mouse clicks/gestures) are a table of key event to function bindings.
Chaining maps lets a keymap define only some keys. Any key not handled by
the first map is passed on to the prior one, and so on.

> [menus are already extensible and rearrangable]
> What do you mean? that they can be extended in runtime?

Yep.

> I know, that's
> what the RB does, for example. The current inflexibility I am talking
> about comes from the way they are generated and used -

Hence: """> > menus are already extensible and rearrageable, I think. The
question is
> > more on conventions and best practices."""

Though, I should have said that extra support for those conventions and
practices is a great idea.

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

Hmm. have to think about it some more.

Cheers,
Bijan Parsia.