Utilisateur:Marcel/Version 2.0

Le but de cette page est de ranimer la discussion sur la version 2.0 en parallèle à celle sur la version 1.1, afin qu’avant la normalisation, la communauté puisse voter pour décider de l’ampleur des évolutions qui seront implémentées en vue de la normalisation.

Plusieurs pages préexistantes contiennent le plus gros des ressources
pour la version 2 :

• Présentation générale et orientations : v2:Projet ;
• Boîte à idées : v2:Idées ;
• La page d’accueil v2:Creation référence toutes les pages de la v2.

Dans la suite, il sera question d’une proposition concrète testable à l’aide de fichiers inclus dans le pack à télécharger sur dispoclavier (pour Windows ; les fichiers pour Linux et Mac sont à venir).

Plutôt que comme un accomplissement, la normalisation du bépo peut être considérée comme un point de départ. Dans ce cas, le processus est le moment de la dernière chance. Si la promotion et la popularité du bépo passent à la vitesse supérieure grâce à la norme, la mise au point d’une version 2 ne devrait pas être reportée. C’est un peu juste et c’est dommage de ne pas avoir eu toutes ces idées deux ans plus tôt, mais ce n’est pas une raison d’exclure a priori que le bépo fasse une sorte de mue in extremis. En interprétant des témoignages sur la ML (exemple), on peut affirmer qu’une partie des bépoètes s’attendent à des changements et sont prêts à adopter de nouvelles fonctionnalités.

Sur le plan de l’ergonomie, les éléments nouveaux comprennent la frappe en A, l’exploitation de l’accessibilité des touches sous les médians et les annulaires sur la rangée supérieure, l’accès avantageux aux chiffres par Alt droite (AltDr qui devient la modificatrice Kana sous Windows, qu’on propose d’appeler « Pro ») et sa bascule (KanaLock ou VerrPro) et aussi en pavé par une modificatrice sur la touche 105 (Num, claviers ISO uniquement), l’utilisation des bonnes places en AltDr sur la rangée de repos et voisines pour les caractères informatiques, et le basculement de l’accès direct entre la diacritation (mode Langues) et des caractères informatiques fréquents (mode Programmeur). Sont inclus l’accessibilité simultanée en direct des deux apostrophes (typographique et guillemet simple informatique), un meilleur accès au tiret sur tous les claviers, et au Ç sur les claviers ANSI.

Au niveau typographique on compte l’apostrophe déjà citée, ainsi que l’espace fine insécable (EFI) qui peut être utilisée facilement avec les ponctuations hautes sans modifier l’accès traditionnel à l’espace insécable classique (EIC). Une saisie fluide des minuscules en exposant est possible sur les claviers ISO tant que Maj gauche et Num sont enfoncées. Le grec lui aussi est en touches vives tant que l’on appuie sur VerrMaj, l’arabe en écriture d’origine pareillement avec VerrPro, et le cyrillique l’est avec VerrMaj + Num (ou VerrMaj + touche morte pour 20 % des touches sous Windows, à compléter par touches vives de la rangée supérieure), ainsi que l’hébreu vocalisé avec VerrPro + Num. Le pavé numérique inclus permet la saisie fluide des chiffres avec séparateur de milliers français (EFI), virgule ou point au choix, et pour cent, pour mille ou euro avec leur EFI automatique. C’est là aussi que se trouvent les opérateurs mathématiques en accès facile, dont l’ordonnancement sur la rangée des chiffres a dû être sacrifié à l’optimisation pour le français.

Proposition provisoire pour le bépo normalisable (Voir avec les info-bulles) :

Point de départ

Cette proposition de version 2.0 est concrétisée dans l’urgence juste avant la normalisation pour égaliser les performances du bépo avec celles de l’azerty proposé par le même proposant. L’urgence résulte de la synchronisation, mais aussi et surtout de l’unicité de la chance offerte actuellement aux claviers français. Seules les fonctionnalités acceptées dans le processus présent entreront dans la réalité du grand public.

Normaliser le bépo sous sa forme actuelle (Version_1.0rc2) avec quelques ajustements aurait l’avantage de ne pas nécessiter de négociations avec les constructeurs, ni d’autocollants sur les claviers bépo existants. Mais ce serait inefficient et dangereux dans tous les cas :

• Si l’AFNOR accepte les nouvelles fonctionnalités pour l’azerty, le bépo reste à la traîne ;
• Si l’AFNOR refuse les nouvelles fonctionnalités par égard pour le bépo ou parce que la communauté du bépo les a refusées “elle aussi”, le nouvel azerty de France n’aura probablement pas le potentiel de devenir un grand succès, ni le peuple français l’envie de le porter à l’actif du gouvernement, bien au contraire. Et les Français ne verront peut-être aucune raison de ne pas faire basculer la situation politique et faire conduire l’Union Européenne à l’implosion.

Éléments conservés

Beaucoup de propositions ont été faites pour optimiser l’ergonomie par des inversions ou des permutations circulaires de lettres et d’autres caractères, mais aucun consensus n’a pu se dégager en faveur de telle ou telle option sauf l’aménagement pour la frappe en A. Cette proposition de version 2.0 a donc beaucoup en commun avec la version stable actuelle et a pour but de s’inscrire dans la tradition du bépo afin de pouvoir être adoptée le cas échéant avec un minimum de changements dans les habitudes de base. Les innovations doivent toutes être motivées par un réel plus qu’elles apportent aux utilisateurs.

L’agencement de l’alphabet de base est conservé sauf pour l’X et l’Y, décalés d’une touche vers la gauche pour s’adapter aux nécessités de la frappe en A. Sont pareillement conservés toutes les lettres diacritées en accès direct pour autant qu’elles soient exemptes de problèmes, c’est-à-dire l’É et l’È. Ainsi la rangée éponyme « BÉPOÈ… » reste intacte et assure la continuité de l’identité visuelle du bépo dans ce qu’elle a de plus caractéristique.

Cette proposition maintient la présence de l’espace insécable classique (EIC) au niveau Majuscule sur la barre, et elle renforce l’utilisation de l’EIC avec les ponctuations françaises. Malgré ses inconvénients, l’insécable en Maj + espace est devenue d’emblée une fonctionnalité phare du bépo qui souligne le savoir-faire tant de ses concepteurs que de ses utilisateurs à cause du tour de main qui évite les frappes accidentelles.

Dans le même souci de faire l’économie de ruptures évitables dans l’expérience utilisateur, on propose aussi de maintenir à leurs places actuelles sur la barre les deux espaces insécables, tant que les préférences des utilisateurs ne penchent pas clairement en faveur de l’inversion.

On propose de conserver aussi la prise en charge sur la carte de base, des lettres « ß » et « ij » en minuscule et majuscule afin de maintenir une continuité de l’expérience utilisateur pour les bilingues Flamands et germanophones.

La plupart des caractères spéciaux sont eux aussi maintenus (et mis à jour le cas échéant), soit sur leurs places traditionnelles comme les indicateurs ordinaux, les obèles et la perluète, soit là où il restait des places, possiblement en gardant un minimum de logique ou autre mnémonique, comme pour les ⩽, ⩾, ×, ÷, ¶, ¬.

Idées réalisées

De nombreuses fonctionnalités incluses dans cette proposition se retrouvent déjà sur la page de présentation du projet de version 2 et/ou dans la boîte à idées de la version 2 :

• le non-maintien des chiffres en Majuscule ;
• l’implémentation d’un pavé numérique sur le bloc alphanumérique ;
• le placement de lettres sur la rangée des chiffres ;
• les guillemets en shift pour l’enchaînement avec l’espace insécable ;
• accès direct simultané aux apostrophes droite et typographique.

L’idée d’aménager le bépo pour la frappe en A a été discutée sur la ML et a trouvé un écho favorable. La présente proposition vise à la réaliser tout en évitant à l’À de se retrouver sur la touche 105. Les utilisateurs de claviers ANSI bénéficieraient ainsi eux aussi de la touche tiret au milieu, et le bépo conserverait son unicité.

Fonctionnalités ajoutées

Pour réaliser ces idées dans les meilleures conditions, il est nécessaire d’utiliser des ressources clavier moins courantes que la modificatrice traditionnelle Alternate Graphics. Par exemple, si les chiffres sont accessibles par Alt droite (AltDr), il faut pouvoir transférer le rôle de la bascule Verrouillage Capitales pour les chiffres vers une autre bascule. Sous Windows (soit sur la plupart des ordinateurs) cela aboutit à ajouter une bascule sur le clavier, et à changer pour une autre modificatrice sur AltDr.

L’agencement des chiffres en pavé à son tour nécessite une modificatrice à gauche, qui ne peut pas être sur Alt gauche (Alt), parce que sous Windows, le remappage de cette touche dans le driver de disposition est dysfonctionnel. La seule option normalisable est alors la conversion de la 105ᵉ touche en modificatrice, mais de préférence pas sous la forme d’un simple doublage d’AltDr, comme l’ISO/IEC avait prévu d’y doubler AltGr. L’utilité de cette symétrie concerne surtout les chiffres de la moitié droite, tandis que d’autre part, pour être ergonomique, le pavé numérique émulé doit s’étendre sur davantage de touches que ce qui découle de sa morphologie par défaut. Il en résulte que la 105ᵉ touche devient idéalement une nouvelle modificatrice, naturellement appelée « Num », et utilisable aussi pour écrire en exposants, fonctionnalité utile en français et d’autant plus souhaitable sur un clavier ergonomique.

Deux autres extensions de fonctionnalités sont implémentables sous forme de touches mortes. Il s’agit d’une part d’une paire symétrique de sélecteurs de groupe rémanents façon ISO/IEC 9995, et d’autre part d’une émulation COMPOSE intégrée à la disposition, et qui de ce fait participe de la prise en charge des caractères. Une implémentation rationnelle utilise trois positions de touches en AltDr : celle sur la barre d’espace pour COMPOSE, et deux sur la rangée Tab pour les sélecteurs dont chacun donne accès à la même carte supplémentaire (groupe 3), tandis qu’actionnés en double frappe ou ensemble, ils amènent le groupe 4. Jusqu’à 8 autres groupes sont accessibles par « groupe 3 + chiffre », mais aussi de manière circulaire par des frappes répétées des sélecteurs de groupe. L’avantage de cette approche est de fournir un nombre de cartes suffisant pour les domaines principaux comme les mathématiques et la musicologie, mais aussi de parer aux accusations d’hétéroclitie dans les cas où tel groupe contient des symboles issus de plusieurs secteurs.

Une fonctionnalité supplémentaire consiste à fournir un accès en touches vives à plusieurs écritures européennes et/ou utilisées en France et/ou dans le cadre de la culture occidentale, à savoir l’arabe, le cyrillique, le grec et l’hébreu. Implémentée avec les ressources par défaut d’un driver de disposition au format Windows, et de toute manière, cette fonctionnalité ne permet pas d’écrire de textes dans ces écritures, parce qu’il faut appuyer de manière continue sur une ou deux touches à gauche. (Une disposition de clavier dédiée offre aussi l’avantage que la langue utilisée est reconnue plus facilement par les applications.) Concrètement, les deux modificatrices supplémentaires restantes sous Windows sont ajoutées sur les deux bascules. C’est pertinent parce que le nombre de déverrouillages de la bascule après utilisation ⋘ le nombre de caractères de l’autre écriture entrés par touches vives.

Support par les systèmes d’exploitation et portabilité

Vu l’état du marché de l’informatique, les ressources pour les dispositions de clavier, et les stratégies de développement des éditeurs d’OS, les normes de clavier doivent se caler sur Windows. Les autres schémas d’action se sont révélés inefficaces :

• Apple a adopté l’XML pour configurer les claviers, et c’est aussi dans ce format que les dispositions de clavier sont déposées dans le Common Locale Data Repository (CLDR) d’Unicode. En dépit de tout cela, Windows et Linux continuent d’insupporter les dispositions de clavier en XML.
• Le Comité technique commun de l’ISO et de l’IEC a créé une norme de clavier internationale depuis le milieu des années 1980 à l’initiative de la France (Dʳ Yves NEUVILLE), à laquelle l’AFNOR a mis la dernière main en 2015. Les développeurs de Linux se sont efforcés d’implémenter cette norme internationale, tandis que Microsoft a refusé jusqu’à sa propre participation aux réunions du groupe de travail, et a figé les API de dispositions de clavier, à ce qu’il paraît après avoir implémenté un sélecteur de groupe – probablement celui d’ISO/IEC 9995 – de la manière la plus compliquée à programmer (avec le tout dernier bit drapeau, en sautant l’avant-dernier resté inattribué) et sans la moindre documentation dans kbd.h à part le nom (« KBDGRPSELTAP »).

Le bépo a déjà suivi ce principe en bridant la disposition pour l’aligner sur les ressources connues de Windows telles qu’elles sont représentées par le MSKLC, la seule chose qui dépasse étant le tiret bas sur la barre d’espace.

Maintenant que l’on sait que Windows supporte l’enchaînement des touches mortes, le bépo est mis à jour en conséquence. Dans la foulée, on peut utiliser pareillement les autres ressources clavier dormantes de Windows.

La portabilité sous les autres OS ne pose a priori pas de problème puisque l’XML est déjà plus performant que les API Windows, et que sous Linux on peut sans doute ajouter tout ce que l’on veut. Cela permet de partir du principe qu’une fois les ressources de Windows pleinement mises en œuvre, les autres OS se feront un devoir de prévoir d’en faire au minimum autant, si vraiment il leur manque encore quelque chose.

C’est peut-être un peu naïf comme point de vue, mais probablement plus terre-à-terre que la normalisation idéaliste que représente ISO/IEC 9995. La chose à éviter en tout cas, c’est la conception de dispositions de clavier en vase clos sans garder à l’œil la faisabilité sous l’OS figé qu’est Windows en ce qui concerne les claviers.

Modificatrices et bascules – les niveaux

Cette proposition de version 2.0 change la modificatrice sur Alt droite, place la bascule coordonnée sur la touche au-dessus de Tab, transforme en modificatrice sur la touche 105 à droite de Maj gauche, et superpose une modificatrice sur chacune des deux bascules. Sous Windows, elle donne accès aux niveaux AltGr par Ctrl + Alt, surtout pour pallier l’impossibilité d’y obtenir par touche morte plus d’une unité de code UTF-16. En comptant aussi le niveau Ctrl hérité (presque vide, mais pas tout à fait) et en ajoutant Maj + Ctrl, on arrive à un total de 30 niveaux. Juste assez pour tirer pleinement parti de son clavier.

Le changement de modificatrice sur Alt droite

Le remplacement d’AltGr par Kana documenté sur ce site est proposé pour la version normalisable à ceci près que le kllf_altgr n’est pas supprimé, afin de pouvoir mapper AltGr sur un scancode inutilisé, activable au besoin par l’utilisateur à l’aide du convertisseur de signaux de touches inclus dans Windows Ainsi l’utilisateur peut disposer d’une touche AltGr par exemple sur Windows droite ou gauche.

Selon les derniers tests de Marcel le 14 septembre 2016, le sélecteur de groupe d’ISO/IEC 9995, bien que connu avant le gel de Windows – sa publication date de 1994 – n’a pas été correctement implémenté par Microsoft, car l’attribut GRPSELTAP qui devrait permettre de spécifier pour chaque touche si les niveaux KBDGRPSELTAP et Shift + KBDGRPSELTAP sont soumis à la bascule VerrCap, ne fonctionne pas. (La valeur 0x80 de l’attribut a été additionnée à l’attribut 0x01 de la touche VK_A, attribut qui soumet la touche à la bascule VerrCap pour les niveaux Base et Shift. Le nouvel attribut qui en résulte est 0x81, mais au test, à bascule VerrCap active, la sortie avec la modificatrice KBDGRPSELTAP (implémentée sous forme de la modificatrice Num) était inchangée.) On peut se demander si les lettres « AP » dans GRPSELTAP ne signifieraient pas « aping » (admettant que le reste signifie « group selector »), et imaginer que les développeurs auraient reçu la consigne de prévoir de quoi « singer » ce sélecteur de groupe… Tout cela sur fond d’absence totale du moindre commentaire à propos de GRPSELTAP dans la source kbd.h, par ailleurs plutôt loquace en ce qui concerne les modificatrices et les niveaux.

On va par conséquent rester sur le remplacement d’AltGr par Kana. Ce remplacement est indiqué à condition de ne pas placer de lettres dans ces niveaux. La proposition présentée ici y garde toutefois l’ẞ ß et l’IJ ij, qui ne sont pas utilisées en français et ne sont placées sur des touches vives que pour rassurer les lecteurs de la carte, car on les obtient mieux par la touche morte accent grave – qui, elle, est en accès direct – suivie de [ç] pour « ß », et de [j] pour « ij ».

Ce remplacement d’AltGr par Kana est logique parce que les chiffres sont en AltDr (Alt droite), de sorte que la bascule qui les met en accès direct est simplement la bascule Kana. Cette bascule est associée aux niveaux Kana, et elle est paramétrable touche par touche, comme la bascule Maj. L’allocation des bascules est liée au keycode, qui est VK_KANA pour KanaLock, et VK_CAPITAL pour CapsLock. La modificatrice Kana au contraire, comme toutes les autres modificatrices, est mappée dans une liste d’allocation des bits drapeaux modificateurs, qui dit que telle touche est « KBDKANA ». Ce qui a pu induire en erreur certains développeurs, ce sont les keycodes VK_LSHIFT et VK_RSHIFT des touches Maj, et peut-être le keycode générique VK_SHIFT dans la table des bits drapeaux où il est associé à « KBDSHIFT ».

Comme indiqué sur la page Remplacer AltGr par Kana, on évite ainsi le mélange entre raccourcis clavier et frappes de caractères sous Windows. La pertinence passée de l’implémentation d’AltGr choisie par Microsoft résulte de la volonté de conserver la pleine symétrie du clavier en ce qui concerne les touches Contrôle, Windows, et Alt – et donc désormais Ctrl + Alt pour AltGr – et du faible nombre de raccourcis clavier dans les applications. Ce fut seulement une fois les raccourcis avec Ctrl et Maj + Ctrl saturés, que la mainmise sur les raccourcis en Ctrl + Alt mit le désordre. Ce problème est résolu dans Word, où l’équivalence n’est appliquée qu’en cas de non-interférence. LibreOffice et Windows au contraire désactivent soit les uns, soit les autres quand il y a interférence. Mieux vaut donc éliminer le problème à la base.

Touches mortes

Deux sélecteurs de groupe rémanents

Les contenus sont à venir sous peu, merci de votre compréhension.