On Fri, Oct 21, 2011 at 3:55 AM, Marijn <hk...@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/20/11 20:30, Robby Findler wrote: >> On Thu, Oct 20, 2011 at 11:34 AM, Marijn <hk...@gentoo.org> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> Hi Robby, >>> >>> On 10/20/11 18:15, Robby Findler wrote: >>>> Generally, the <menukey>-c, <menukey>-v, keybindings (and >>>> friends) come about via the menus, not via a keymap% object. >>>> And those menus come in via a frame. I'm not sure how you're >>>> using your library, but you might want to consider some of the >>>> mixins in the framework whose names start with "frame:". >>> >>> I'm actually trying to create something spreadsheet-like. I'm >>> using editors to manage(display/edit) cell contents. Although >>> each cell(-editor) individually doesn't have a menu, when used in >>> a complete application there probably will be menus, and I'm >>> planning to check out what the framework provides. >>> >>> However, I don't understand the logic of menus that bring about >>> key bindings for editors. >> >> I'm not sure how to respond here, except to say that that's what >> the GUI designers of the world seem to have come up with. The >> keybindings that you asked for earlier (control-c and control-v for >> copy and paste under windows, for example (command-c and command-v >> on the mac)) are there because they are shortcuts for menu items, >> not because they are keybindings at the level of the editor. > > So you're saying this is something that is inherited from Gtk and the > Windows and OSX graphics layers?
Roughly, yes. You can, of course, make keybindings (via a keymap%) that would cover standard bindings such as these, but it would be confusing to users of your library (assuming you package this up as a library) and you'd be duplicating a bunch of code. Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev