Re: [EGD-discu] Organisation - Proposition alpha pour normalisation

[Marcel Schneider <bkn.ema@xxxxxxxxx>]

Le 09/02/16 14:37, Jérôme Schwartz <elivagar@xxxxxxxxx> a écrit :
 
> La principale différence entre un sélecteur de groupe et une touche morte est la rémanence alors, je me trompe ?

Ces deux concepts ne sont pas au même niveau, ce qui fait qu’il n’est pas très utile de les comparer dans l’absolu. Sélecteur de groupe est sinon une invention de la normalisation, du moins une idée présente surtout dans la norme ISO/CEI 9995 et ses implémentations, comme l’est l’idée de groupe en tant qu’ensemble de niveaux. L’exemple le plus frappant est peut-être le clavier US International, qui utilise AltGr, touche qui a dû être déclarée comme étant le sélecteur de groupe d’ISO/CEI 9995 afin de rendre le clavier conforme à cette norme – et avec lui toutes les dispositions qui utilisent le niveau Maj+AltGr. On voit donc bien le côté artificiel de ce concept.

Le “sélecteur de groupe” chevauche différentes réalités techniques, car la norme permet qu’il soit rémanent ou non-rémanent. D’ailleurs est-ce qu’il y a un mot pour cela ? ― Quand le sélecteur de groupe est implémenté sous forme de modificatrice, il est typiquement non-rémanent (s’il est possible de généraliser à partir de deux ou trois implémentations !). Certes il existe aussi la rémanence de toutes les modificatrices, paramétrable dans les options d’ergonomie. Mais si comme dans la norme de clavier allemande de 2012 – non implémentée telle quelle à ce jour ! – le sélecteur de groupe est la combinaison Maj+AltGr, il doit être rémanent pour avoir deux ou trois niveaux derrière.

>
> Serait il possible, en utilisant une autre touche tel que CapLock de rendre la touche morte rémanente, et de quitter le groupe en désactivant CapLock ?

Oui il est tout à fait possible d’avoir un sélecteur de groupe basculant, et de le placer sur CapLock. La touche CapLock servira alors à actionner la bascule KanaLock, qui est exactement la version bascule du sélecteur de groupe utilisé sur le clavier Canadien multilingue standard, où il est présent sous forme de modificatrice. C’est VK_KANA la bascule, et VK_XXXXX défini comme KBDKANA qui est la modificatrice. Dans ma reconstitution du clavier Canadien multilingue standard – non géré par le MSKLC – je l’appelle VK_OEM_8.

C’est d’ailleurs selon ce principe qu’une bascule peut être en même temps une modificatrice, tant qu’elle est pressée c’est un autre niveau qui est actif dans ce cas. Mais ce n’est pas – encore – courant.

>
> Ce n’est peut être pas disponible dans les drivers..

Il arrivait souvent aux normalisateurs de clavier – tant au niveau international que sur le plan national – de spécifier des fonctionnalités qui ne sont pas faciles à rendre disponibles dans les drivers, en effet, ou qu’il est même impossible d’avoir sous Windows. Après, « impossible n’est pas français » si je me rappelle bien, donc on part du principe qu’un bon programmeur en C peut implémenter n’importe quel comportement jugé utile. Dans ce cas il reste juste deux questions  : Pourquoi cela n’a pas été fait en Allemagne, et est-ce que les ressources existantes – et largement sous-exploitées – ne permettent pas de faire de meilleurs claviers ?

Les normalisateurs avaient dix ans pour se décider avant qu'íls publient la norme ― et avant que Microsoft fige les API claviers de Windows. À mon avis, avec cinq modificatrices et deux bascules, Windows et sans doute les autres OS sont bien garnis. En ce qui concerne Windows je peux témoigner que KbdUTool fourni gratuitement avec le MSKLC permet de compiler et faire fonctionner tout cela – bon la 5^e modificatrice je n’ai pas encore essayé. Au delà il y a même une modificatrice GRPSELTAP dont il paraît que l’on ne sait rien. ― GRP SELT ressemble d’ailleurs à “Group Select”, et ça existe depuis au moins 20 ans. De là à supposer que la normalisation n’a peut-être pas tant inventé que cela ―

Bonne journée,

Marcel