Ryan Leavengood <leavengood@xxxxxxxxx> wrote: > I don't know if I quite understand that, as I don't really understand > how keyboard mapping works. But I guess the basic idea is that there > is a difference between the actual physical key pressed (scancode?) > and the resulting character (which depends on the keymap?) And we > could do shortcuts based on either? Exactly. > But I do think that sometimes position is more important for > shortcuts > than the letter, such as the usual z, x, c, v for undo, cut, copy and > paste. If someone uses Dvorak or some other greatly different > keyboard > layout the new locations for those is just not as convenient. But > trying to have both position based and character based shortcuts > could > potentially get confusing. The UI would be quite important. There wouldn't be any UI involved at that point. The application would specify something like: AddShortcut('z', B_COMMAND_KEY | B_RAW_KEY, message); in case the key itself is important (alternatively, the B_RAW_KEY could be passed in an extra flag argument, but there are a few modifier key flags free). In the running application with a German keymap, the shortcut would translate to Command+y. If the shortcut have been added to a menu item, the menu item would just show Command+y as well. Alternatively, if you specify: AddShortcut('+', B_COMMAND_KEY, message); The shortcut would be Command++ on all keymaps; the modifiers necessary to press that key would be ignored. Therefore, with an English keymap, the shortcut would clash with Command+Shift+= - if an application has set such a shortcut, it would automatically be remapped to a different one, for example Command+= in case that one is still free. > The main concern with this is all the custom code that already exists > in various Haiku applications for handling shortcuts. I know that > WebPositive does a lot of things, including overriding > DispatchMessage > which could easily interfere with this proposed system. If we make this available only with GCC4 applications (or after the API change), for example, we can just document the new behaviour and are done with it. No need to worry in that case. For GCC2 we could either not have that feature, or enable it manually via a dedicated method or window flag. > On a related note I've been annoyed with the existing Shortcuts UI > for > a while (and I know I'm not alone) and I may work on that a bit soon > in between Web+ stuff. I have some ideas but if anyone has > suggestions > let me know. Making it look like a Haiku application would be a start :-) Bye, Axel.