2015-04-15 17:59 GMT+02:00 Doug Ewell <[email protected]>: > Luis de la Orden <webalorixa at gmail dot com> wrote: > > > But with regards to the ALt-Gr, there it goes my innocence and feeling > > of accomplishment :)), I had everything linked to the Alt-Gr key and > > did exactly as Ilya said... MS Word is fine, but very specialised > > software such as Photoshop are a pain as their power-user shortcuts > > all use ALT-Gr indeed. > > It's true that some very popular software packages define their own > Alt+key or Ctrl+Alt+key combinations, and keyboard layouts that use the > same combinations (as AltGr+key) will conflict with them. I just annoyed > a colleague the other day because my keyboard layout (John Cowan's > delightful Moby Latin [1]) co-opts one of his favorite Visual Studio > shortcuts; he tried to build a project and got U+2022 BULLET instead. > > But there are also a lot of keyboard layouts worldwide that do use AltGr > keys. There are only so many keys on a standard keyboard, and if you're > designing a layout and you've made all the tough choices and you still > need to find room for more characters, you pretty much have to go to > AltGr. > > It helps to educate users of such a keyboard layout, especially > Americans, that the left and right Alt keys aren't the same. Americans > tend not to expect this, because the standard U.S. keyboard doesn't use > AltGr at all and the key isn't marked as such. >
Another candidate key for modifiers that you can use on PC keyboards is the useless "NumLock" key on 101/102-keys keyboards (there's actually no need to switch the working mode of the numeric keypad, given you have also a separate set of keys for cursor movements, which remain active independantly of the NumLock setting). So this NumLock can be reused as another modifier (e.g. to support input in Japanese without a physical Japanese keyboard). Of course this will not work if your connected keyboard does not have a separate numpad but you need to share it with cursor keys. Some keyboard layouts also use ScrollLock for similar purpose (but this function key is frequently not easy to access on notebooks where you activate it by using the "Fn" key plus another function key. NumLock in that case remains more accessible as it will remain under a single keystroke. Several keyboard drivers (e.g. Logitech) have settings that disable ScrollLock by default (or that recommend disabling it...), a good sign that this function is useless in standard layouts, but more useful for extended layouts (in that case don't disable it in the device control panel!). Outside physical keyboards, for virtual touch keyboards there's no such limitation, and these layouts can have much more freedom in how they will switch their visible panels in various input modes. Many more facilities can be integrated, including faciltiies specific to the application having the input focus (they don't necessarily have to modify the virtual driver of the OS, they can provide these faciltiies directly in their own application UI, but the OS-provided virtual keyboard facility can provide a space for such application-specific customizations of the touch panel). For these virtual panels, even common modifiers like CapsLock, Shift, Control, or Numlock are not productive, as the proposed lists of characters may be arranged in very different groups or input modes and with more choice in terms of geometry. However these applications providing custom UI should propose clear mappings to other common input devices, including physical keyboards and mouse or other pointing devices. These interfaces should also not assume that alternate devices will be able to emulate a multitouch capability (with multiple pointing positions on screen) On touch interfaces, the "AltGr" modifier itself does not have any meaning. It is more important for the layout to offer the best selections of characters for the current language, and offer extended subsets with some logical groupings that make sense for that language, but we are not limited to just 2 or 3 "modifier" keys (for example long presses or clicks on a basic virtual key can open a popup panel that contains dozens characters to choose from, and contextual input can also predispose the most common or most recent choice in some easy position without having to look for other panels). Virtual onscreen keyboards (not necessarily on touch screens because you may also point and click in them) are in fact acting more like an IME than a traditional keyboard These virtual keyboards are in fact true applications with a visual UI, accessible with several other input devices: a tactile area, possibly multitouch, pointing devices, physical keyboards, or other sensors. These applications process all these inputs, present some selections, present the result to be sent to other applications, and they will send these results either by emulating standard keyboard events, or mouse events, or even image captures, or clipboard contents to be pasted in other applications. These IME can also be desigend to manage completely the content of an external input control widget, becoming their standard text editor.
