From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Dec 06 2006 - 07:59:22 CST
pemuro wrote :
> Philippe Verdy wrote:
> > From: "Andrew West" <andrewcwest@gmail.com>
> > > Too late for that. "Exit" as a menu item is universally shortcut with
> > > alt-x, and some applications have "Exit" as a top level menu (and for
> > > Word you can add "Exit" as a top-level menu if you want). I'm pretty
> > > sure that "Exit" was in common use many years before alt-x Unicode
> > > conversion came into being.
> >
> > Not so universally; In French Windows, you can also find Alt+Q (Quitter)
> > ('exit' is not a French term,even if it's commonly understood). But remember that
> > this only works as a menu item shortcut, not as a menubar item shortcut, so when
> > the keyboard input focus is on the document, Alt+X or Alt+Q does not map to a
> > menubar and is usable as a custom shortcut. I'm sure that this hex Unicode
> > conversion shortcut can be customized in Word (and it should be already
> > changed in Word for localisations where X is already taken by a menubar item,
> > like it is for Alt+F for the universal "File" menu in English or "Fichier" menu in
> > French, or Alt+A for some other romance languages using "Archivo".)
> > Anyway, it would have been better to use Ctrl+U for this conversion shortcut
> > in Office (but in English Word, this is a shortcut for applying/removing the
> > underlining style on the selected text).
> >
> > This Alt-X is not a standard input feature of Windows, but an
> > application-specific mapping to a function; All such application mappings
> > should be localizable; normally, sequences like Alt+letter/digit or
> > Ctrl+letter/digit are left free in all keyboard drivers. (remember that
> > Ctrl+Alt+letter/digit should behave the same as AltGr+letter/digit in
> > almost all keyboard drivers, except a few ones like the default US
> > English keymap, which does not have the Alt vs. AltGr distinction but offers two equivalent Alt keys).
> >
> The many universal (?!) meanings of Alt-X or _Q ... for Exit/Quit ...
> are a surprise to me Ctrl_X/Ctrl_Q... are familiar from the old times of
> ascii-terminals.
They are normally not part of menu item accelerators but classified as control functions, specific to each application, which may either use them to perform special functions or, in terminals, to send a control character "over the wire." Most of these ASCII controls are deprecated because they conflict with other uses in plain text files. For example Ctrl+M generates an ASCII carriage return which is also a valid character in plain-texts; the wayt they are interpreted however still depend on the transmission protocol in some way, and they are not always bindable to application-specific behaviors (like those functions performed in plain text editors like "vi" or "emacs".)
> Alt_F/Alt_D for Menue-file-open../_Datei_oeffnen... are familiar, and these meanings
> are usually ignored when the keyboard-layout sends some other character, not so
> with the Ctrl-key-combinations which seem to be caught by the OS (XP or Linux) and
> do not go through the keyboard-filter.
They are not ignored. But Alt+letters should not be assigned in keyboard drivers, to compose characters and left to applications. That's why they are not proposed in MSKLC.
> MSKLC.exe (keyboard-layout-creator) allows to enter 8 different (reassigns one
> each for normal, shift, R-Alt=AltGr, AltGr-Shift, CapsLock, CapsLock-Shift) character
> or dead-key-lists per physical key-top. Unfortunately, even after makeing these
> assigns many AltGr-combinations just Highlight a line in a dead-key-table,
> left-over from some editing-short-cuts?
That's WRONG. AltGr+key combination do that ONLY if the keyboard map assigns them to a dead-key table. If so, it works as intended.
AltGr+key should NEVER be assigned by applications and left to keyboard drivers for composing characters;
> WORSE: Ligatures are not accepted in CapsLock-states, where reassigns for ^° , ´ `,
> and some others, particularly deadkey-lists are completely ignored when building
> the keyboard.
That's WRONG too! In keyboard maps with CapsLock states, each state defines its own map, where one could bring to a dead-key table (identified by a default Unicode character), and another to a single characters.
Then the next letter to compose in the dead-key state can be composed using any of the other states, where the Capslock state is also considered; the character pair in the dead-key table then generates a precomposed character on output or a string.
> I would like to know how to override this behaviour without having to change the
> Short-cut-key-assigns at each individual machine (or eaach application) where I
> install my MultiLatin++ -keyboard.
Do not even try to assign shortcut function keys in a MSKLC driver. It is NOT designed for that, because the intent is only to compose Unicode characters or strings of characters, and nothing else.
Applications should NEVER assign special function meaning to:
* AltGr+characterKey (or Ctrl+Alt+characterKey which is treated as equivalent for physical keyboards that don't have an AltGr key, or a second Alt key)
* Shift+AltGr+characterKey (or Shift+Ctrl+Alt+characterKey which is treated as equivalent for physical keyboards that don't have an AltGr key, or a second Alt key
as they are reserved for keyboard drivers to compose characters. Applications that do that are plain BOGOUS and will not work correctly with international keyboards following the well-established standards.
Applications can use :
* Alt+character key (in ANY shift or capslock state) for menu items or GUI controls (and make sure that all letters are left to menu items so that they can be translated)
* Ctrl+key or Ctrl+Shift+key to perform special functions, using the ASCII control AS GENERATED from the keyboard driver. For example they should not assume that Ctrl+2 is free of any character assignment in the keyboard driver, unless this binding is also translatable and adaptable to other keyboards that need Ctrl+2 to compose for example the ASCII "Ctrl+_" (U+001F) if Ctrl+2 is mapped in the keyboard driver like the mapping of the "_" character on that same key.
This last item is what "vi", and "emacs" use, i.e. they don't care about how the control was generated, but only about the ASCII control character coming from the keyboard. These applications demonstrate that you can have plenty of application-specific functions assigned to "keyboard shortcuts" that do not conflict with the keyboard driver, or with the GUI "menu accelerators" or "mnemonics".
In a HTML page for the web, using Alt+letter shortcuts assignments to some form input element (in a way that changes the location of the input focus in the HTML page, or that scrolls a page to another location) is always a very BAD idea, if the HTML page must be rendered in a browser installed in another language where there are assignments for the browser-specific (and language-specific) GUI menu items ; this part of the HTML specification should NOT be used on the web (or input forms should not depend on them), but only in standalone applications that use an internal HTML engine for rendering both their own GUI and their own content.
This archive was generated by hypermail 2.1.5 : Wed Dec 06 2006 - 08:03:43 CST