From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Jul 12 2010 - 05:11:47 CDT
"a a" <abysta@yandex.ru> wrote on 2010-07-08 at 14:21:
>
> Thanks for your replies.
> I’m developing a keyboard layout based on US (Custom) which has 001B, 001D, 001C, 0020 defined for the Ctrl shift state. I don’t know should I leave them or not. The MKLC help recommends to avoid defining characters for both the Ctrl and Ctrl+Shift shift states, but also says: “You may notice specific keys in the Ctrl shift state are assigned when you load an existing keyboard layout. These key assignments are used in certain legacy applications like Microsoft HyperTerminal and should usually not be removed.”
Note that there are still a lot of applications that depend on being
able to enter ALL the possible ASCII controls, and this includes
various terminal protocols, including those for Unix/Linux (notably
CTRL+D which should still be mapped to an ASCII control, even if those
keys are marked, on Windows and X11 protocols at least, as out-of-band
non-character system commands, just like other function keys like
F1..F12, cursor control arrows, and even the Enter or Backspace and
Delete keys)
But if you use a VT-like terminal emulation, including the
DOS-compatible "ANSI" emulation in the Windows console, or
applications that just use the low-level BIOS emulation (or other
legacy protocols through a serial link) that does not support marking
those sequences as out-of-band, the only thing that will be
transmitted is the control itself for each function key (that's why
Unix/Linux shells and editors like Vi or Emacs do not depend on
out-of-band marking of function keys, but still depend on the keyboard
driver to generate these controls or escape sequences, both for input
and output).
So keyboard drivers will require you to assign somewhere on the
keyboard map a position appropriate for each ASCII control. Note that
these positions are dependant of the national layout of letters
(notably CTRL+Q vs. CTRL+A, or CTRL+W vs. CTRL+Z vs. CTRL+Y), but even
more critically all those controls that are typically entered as
CTRL+ASCII punctuation (e.g. CTRL+@ for entering NUL : on the French
keyboard '@' is entered as AltrGr+0 or Ctrl+Alt+0, without a Shift,
and CTRL+@ used to enter the NUL would fall on Ctrl+0, without using
Shift).
But if you look at the various national keyboards, those punctuations
are only accessible with the Shift key, and even sometimes using the
AltGr key, so these controls will also be entered at the same mnemonic
positions, sometimes with a needed Shift because two of the needed
ASCII punctuations fall on the same key).
The 'Esc' key should also be mapped to the ESCAPE control of ASCII,
but there will still be a distinction from the regular input of Ctrl+[
in terminals, because the Esc key will be also marked as a system
function, notably for GUI applications (e.g. to close a dialog). So
the Esc key is not the proper way to enter the ESCAPE control needed
in terminals or Unix editors for escape sequences.
What Microsoft says is that all CTRL+key or CTRL+SHIFT+key, where key
is on one of the four rows of the alphanumeric and punctuation area,
should be reserved for entering ASCII controls, and should not be used
for entering ASCII control characters (and you cannot expect that
CTRL+1..CTRL+9 and CTRL+0 will be available for other
application/system commands. A keyboard validation should ensure that
all ASCII controls are mapped on the keyboard layout, along with other
printable characters needed for ISO 646 IRV; some other ASCII
punctuation that are not in the ISO 646 IRV may require using
AltGr=Ctrl+Alt on the keyboard map.
If an application still wants to assign a function to CTRL+digit (or
CTRL+SHIFT+digit if digits), should not assume that it will be
available (as it may be mapped in a layout to enter a regular control
character). One way to solve the problem is to make sure that the
application allows user configurable shortkeys for system commands.
Windows for example allows the user to specify his shortcuts as
CTRL+SHIFT+alphanumeric, or SHIFT+ALT+alphanumeric, but also allows
the user to select the modifier keys ; but it correctly forbids, in
the standard GUI of its builtin applications, shell and control
panels, and in its international design guides for conforming
applications, the assignment of CTRL+ALT+alphanumeric key (equivalent
to AltGr+alphanumeric) and of CTRL+ALT+SHIFT+alphanumeric (equivalent
to AltGr+SHIFT+alphanumeric) because it may conflict with keyboard
drivers or input methods needed to enter some characters.
But NO keymap should assign any character to CTRL+key or to
CTRL+SHIFT+key, where the key pressed alone is mapped for letters
A..Z: these 26×2 positions in the keyboard layout mapping should be
left free for applications (that will chooe themselves if they want to
use them for entering applications functions, or if they want to
generate a control, with or without the Shift distinction).
Given that the controls U+0000, U+001B..U+001F, and U+007F do not map
traditionally as CTRL+ASCII letter, you can (and should) perfectly
place them all, on any other non-letter key of the keyboard layout
that will be convenient and mnemonic, using either CTRL or ALT,
possibly in combination with SHIFT, but not CTRL+ALT (or ALTGR)
together, and not CTRL+ALT+SHIFT (or ALTGR+SHIFT) : all the remaining
CTRL+keys, where key is in the main alphanumeric part but not part of
the alphabetic keys [A]..[Z], are perfectly assignable for mapping
these seven controls.
Note that most keyboards don't have two ALT keys : the ALTGR is placed
where the US keyboard places the second (right) ALT key. Applications
should not depend on which ALT has been pressed, except in
applications not using them for entering text (such as games), in
which case the ALTGR key will behave exactly like the second ALT (but
it will also activate the CTRL state at the same time, that can't be
disabled as it is full part of the national keyboard behavior...).
Some applications may still detect if a CTRL key was really pressed or
if the CTRL state is enabled as the result of pressing AltGr, by
looking at extended state bits (but many applications forget to look
at those extra state bits, and behave extremely badly when one just
wants to enter a national character with AltGr and the applications «
thinks » that a system command was requested, for example by closing a
window of flushing/resetting an input form): these applications have
typically been designed by poor US programmers that are not aware of
international requirements where the second ALT (AltGr) should never
be used as an application command even if the CTRL state is enabled.
Note that Windows keyboard drivers contain a flag bit in their layout,
saying if the AltGr semantic is needed and fully reserved for the
national layout use (it will fully replace the second ALT feature). In
this case, it will NEVER generate a WM_SYSCHAR containing a
system/application command to applications, but may generate a WM_CHAR
if there's a character mapped on this key, after it has been
translated to a character using the layout data.
Applications can then behave correctly, if they are correctly
programmed and never mix WM_CHAR and WM_SYSCHAR messages in their GUI
message loop, and if they severely restrict their own assignments of
keyboard shortcuts within the alphanumeric and punctuation areas of
the keyboard
There's much less restrictions for the numeric keypad, and for the
"Function" keys (excepting the few global system shortcuts for Shell
controls, that are now preferably mapped using the separate "Windows"
and "Menu/Application" keys on PC keyboards, or the Apple "Option" and
"Cmd" keys on Mac keyboards.
And the "Fn" key typically found on notebooks are reserved for
controlling media-player and hardware features (like Volume +/-/Mute,
Play/pause/stop, Next/previous track, Wifi on/off, image
lightness/contrast, or switching on/off alternate display outputs,
entering/resuming power sleep mode, or user-configurable shortcuts to
launch a browser or read emails), that national keyboard maps should
not use for entering actual characters, as these mappings will remain
invisible to applications, but visible only to specific low-level
hardware drivers with their specific system control panels for their
configuration by the user.
-- Philippe.
This archive was generated by hypermail 2.1.5 : Mon Jul 12 2010 - 05:18:58 CDT