Re: [EGD-discu] Concilier la frappe en A et l’émulation de pavé numérique / Re: Pression multiple des touches mortes pour obtenir des diacritiques alternatifs, essentiellement ceux souscrits

[Marcel <bkn.ema@xxxxxxxxx>]

Lundi 1 Août 2016 17:35:40, Olivier Guéry a écrit :
[…]
>
> La méthode classique ne décale pas les mains à gauche… Je pense qu’historiquement, 
> on a ajouté des touches sous le petit doigt droit, en se disant que c’était des 
> caractères accessoires, et qu’on les mettaient à droite puisqu’il y a plus de 
> droitier. Mais il n’y a pas eu de volonté de décaler les mains à gauche.
> 
Je m’étais mal exprimé : pour atteindre les touches, faire ↖ ↖ (et ↘ ↘).

>> Ce qui est fréquent aussi, c’est de rentrer des données dans une BDD et d’alterner
>> constamment entre texte et chiffres. Dans cette situation, des utilisateurs
>> préfèrent n’avoir qu’à appuyer sur une modificatrice sur la gauche du clavier pour
>> avoir le pavé numérique direct sur le bloc alpha, peu importe qu’il soit décalé.
> 
> Comme d’habitude, tu fais des affirmations gratuite. Le « ce qui est fréquent », je 
> ne sais pas d’où tu le sors. Mais ne peux ni le confirmer ni l’infirmer. Par contre 
> dans les professions où on utilise beaucoup les chiffres… on prend un clavier avec 
> un pavé numérique ou un pavé numérique externe (comme ça on peut le mettre à gauche 
> c’est plus ergonomique, ça évite de mettre la souris trop à droite).
> 
C’est que j’ai extrapolé. Je sais qu’il existe beaucoup de bases de données mixtes,
mélangeant les champs de texte et les champs numériques. Mais je suis allé trop loin
en affirmant que c’est fréquent, car c’est tout à fait relatif. Tout le monde ne 
travaille pas avec des bases de données ; la preuve : dans les suites payantes, 
le logiciel dédié manque souvent.

Ensuite il existe aussi les utilisateurs qui travaillent avec le clavier dans un 
esprit quelque peu sportif — sans que ce soient forcément les sportifs de haut niveau,
qui au contraire ménagent leurs efforts dans la vie quotidienne afin de la garder pour
pouvoir « exploser » en compétition. Mais il y a des utilisateurs qui font même sauter
des touches à force de “frapper”. J’extrapole toute sorte de situations, et il a été
amplement déploré que cette inconscience est un obstacle à la sensibilisation à 
l’ergonomie du clavier.

Par conséquent, selon mon interprétation, les utilisateurs du bépo sont les plus à
même d’apprécier les avantages de combiner l’ensemble des pavés alphanumériques
avec un pavé numérique superposable sur chacun d’entre eux. Dans un fil parallèle
vous en avez parlé :

Sun, 31 Jul 2016 08:38:42 +0000, Olivier Guéry a écrit :
> [HS]
> En pensant à tout ça, je me dis que le problème, aussi, c’est que les OS sont 
> mal foutus (enfin linux et win, je crois que mac a fait des progrès sur le 
> sujet, ou c’est seulement l’accès aux caractères accentués qui se fait par une 
> pression longue sur la lettre).
> Lorsqu’un symbol mort est tapée, le symbol devrait apparaître. D’un autre 
> couleur, clignotant, que sais-je mais l’OS devrait signaler qu’une autre frappe 
> est attendue.
> Du coup une frappe sur le ^ donnerait un ^ rouge ou bleu, qui deviendrait un ê 
> après la frappe sur le e. Mais avec un second appuie sur le ^, le symbol 
> clignotant serait le ^ souscrit, attendant la frappe suivante.
> Avec un mécanisme comme ça, les choses seraient plus simple, plus évidente pour 
> l’utilisateur.
> Malheureusement, je ne crois pas qu’on puisse espérer que même une 
> recommandation de l’AFNOR change quoi que ce soit.
> 
Moi aussi je trouve que c’est génial comme système. Après, je ne suis pas sûr 
que Microsoft s’y investisse, car Keyman fait déjà quelque chose de semblable :
il envoie les caractères tapés, puis une fois qu’il a le caractère ciblé, il 
efface ces caractères pour mettre le résultat à la place. L’idée du feedback
visuel est réalisée, avec ou sans couleurs je ne sais pas.
Donc quand on a des problèmes pour écrire avec des touches mortes, il ne 
faut pas hésiter à utiliser Keyman, qui existe pour la plupart des plateformes
(pour Linux peut-être pas, il faudrait vérifier) et est gratuit si on n’utilise 
pas plus de deux dispos à la fois. 

Dimanche 31 Juillet 2016 10:54:34, Valentin Melot a répondu à Olivier Guéry :
>
> Je suis tout à fait d'accord avec cette analyse. Disons qu'on pourrait au moins 
> demander lors de la réunion de septembre : « on a repéré les points suivants 
> sur lesquels l'ergonomie est améliorable mais qui ne relèvent pas /stricto 
> sensu/ de la norme, est-il possible d'y adjoindre des recommandations ? ». 
> Recommandations qui pourraient porter sur ce que tu proposes, sur l'existence 
> d'un AltGr à gauche ou encore sur l'émulation d'un pavé numérique par une 
> touche F_n. Si l'AFNOR et les représentants des fabriquants de claviers nous 
> envoient bouler, tant pis. Sinon, c'est génial ! :)
> 
L’accessibilité fait en effet partie intégrante de l’ergonomie, et rien ne 
devrait empêcher les constructeurs d’étendre la couche Fonction à la totalité 
du bloc alphanumérique, pour la mettre à la disposition des développeurs. 
À part que le pavé numérique dans la couche F_n là où il existe (encore) est un 
vrai pavé numérique avec les keycodes, juste sans touches physiques dédiées, et 
qu’il est programmable dans le driver au titre du pavé numérique tout court, je 
n’ai pas trouvé comment se servir de cette touche F_n pour utiliser aussi les 
autres touches du bloc alphabétique.

Peut-être est-ce possible sur les claviers Apple, qui bénéficient de définitions
en XML aux possibilités bien plus larges que ce que propose Windows. Ceux qui 
utilisent Mac en ont plus. C’est comme le bio : au final, ça coûte moins cher.

[…]
> 
> Désolé d’être un peu dur mais tu es de ceux qui propose les plus grosse 
> modifications…

Il n’y a pas de souci. En fait je ne propose plus que des modifications périphériques
et sur les niveaux supérieurs, et dans les touches mortes.

> Compliquer de juger de ton travail… c’est sur un azerty.

Peut-être est-ce possible de modéliser ainsi des fonctionnalités dans l’attente
de trouver moyen de les porter au bépo.

> Mais déjà :
> — Les insécables en automatique, c’est très discutable, tu en as même mis 
> deux types différents ;

Avec EIC c’est uniquement pour la compatibilité, et c’est moins bien accessible.
Je vais doubler sur la couche Maj + Num les séquences avec ?!:;, car juste au-dessus
d’AltGr (Pro) c’est peu commode. Mais on peut faire pareil sur le bépo ! Ainsi on ne 
touche à rien et on a tout. Sauf que pour les guillemets, les séquences avec EFI 
ne seront probablement pas sur les mêmes touches.

> — je ne vois pas ce qui justifie de mettre les accolades et guillemets sur 
> le pavé central.

C’est l’accessibilité et la fréquence. Les parenthèses, je les gardais longtemps là-haut en accès direct, mais c’est contre-productif car pour éviter de déformer l’expression écrite, il faut que les () et les [] soient à peu près à égalité.
Cf. « Un avantage de cette solution est que les parenthèses et les crochets sont 
désormais au même niveau, et que l’utilisateur choisit librement entre les deux, 
sans devoir considérer des différences ergonomiques comme sur l’AZERTY hérité, qui 
favorise les parenthèses, mais aussi l’US-QWERTY, qui donne l’avantage aux crochets. 
Dans les deux cas, l’agencement se répercute sur les préférences des utilisateurs — 
un biais qui peut altérer l’aspect des documents. Les DTMD garantissent une 
quasi-égalité entre les quatre. »
http://dispoclavier.com/index.html#p37

Pour les guillemets il n’y a pas le choix car il faut deux paires de colonnes
AltGr / Maj + AltGr entières. J’ai cherché à les placer de manière mnémonique.

> — Si les Æ Œ sont sur le pavé central c’est pour la logique, la facilité de 
> les trouver… respectivement sur le A et le O ;

C’est souvent l’option retenue, mais sous Xorg le clavier Latin-9 plaçait déjà 
l’œŒ sur la touche $# du bépo, ou plutôt, sur la touche ² de l’azerty. Sans doute 
pour fêter son arrivée et l’accueillir dans les meilleures conditions. Aux yeux des 
normalisateurs de l’ISO, sa place sur O n’est plus assurée parce quʼil y entre
en concurrence avec l’Ø, historiquement antérieur dans les ordinateurs. Donc ils 
le mettent sur E…
Cf. « Placer nos digrammes soudés en accès direct »
http://dispoclavier.com/index.html#h235

Je pense que sur l’azerty, qui dédie une rangée aux diacrités (en décalant
les chiffres rien que pour eux), nos digrammes soudés méritent tout autant leur 
accès direct. Donc j’avais commencé par placer l’Œ sur l’& et à générer l’Æ par 
touches mortes (GRAVE ➔ Æ, AIGU ➔ Ǽ). Je ne voudrais pas les mettre sur A et O, 
déjà techniquement car Kana est insensible à VerrCap, donc ce n’est pas une 
solution propre sous Windows, pas plus que d’utiliser AltGr sur les touches 
alphabétiques à cause des nombreux problèmes de raccourcis qui sont gérés 
proprement par Word mais en général pas ailleurs.

Or Word, justement, désactive les séquences commençant par une touche morte et 
finissant sur AltGr. Essayez de taper « ǽ » sur bépo dans Word 2010 (Starter ou
pas Starter, peu importe) : ça ne fonctionne pas.


> — je ne suis pas convaincu par les # et @ en accès direct (et j’avais déjà 
> discuté de ça pour le bépo que met le @ en direct ;
> 
Je n’ai compris la nécessité de les mettre en accès direct tous les deux
que quand j’ai vu la demande sur Twitter.
Cf. « Arobase et croisillon en accès direct » :
http://dispoclavier.com/index.html#h79
et la note :
http://dispoclavier.com/index.html#n14
Mais il est prévu de faire des variantes plus rétrocompatibles où ils ne sont 
pas en accès direct, pas plus que sur la variante malienne qui a besoin de ces
touches pour les ɛ, ɔ, ŋ, ɲ.

> Et ce n’est que mon avis après avoir re-regardé ta dispo… impossible de 
> débattre de tout ça entre nous avant la fin de l’été.
> 
Oui, maintenant il faut parler du bépo, et c’est par rapport au bépo – et 
en partie faute de mieux – que j’ai partagé ce lien sur la ML.

[…]
> 
> On a pas dit récemment que c’était une mauvaise idée de faire Ctrl+Alt, quel 
> que soit l’OS ?
> 
Vu les contraintes de Windows, je n’ai pas le choix, mais je conseillerais 
de remapper si possible telle ou telle touche vers le scancode auquel j’ai 
attribué le keycode d’Alt droite qui continue de fonctionner comme AltGr.
Aussi n’ai-je jamais enlevé l’option KLLF_ALTGR dans aucune source :
«/*
* Locale-specific special processing // KLLF_ALTGR must NOT be disabled, because 
*/ // RMENU can be reintroduced as T5E using
MAKELONG(KLLF_ALTGR, KBD_VERSION), // the Scan Code Mapper, see kbdcommon.H(250).


[…]
>> Au survol de certains caractères sur les touches, une infobulle en dit plus.
>
> J’ai vu, oui, merci.
>
De rien ; on pourrait utiliser ce système pour le bépo, soit dans un tableau comme 
celui-ci, soit dans un svg ou autre avec des zones. Mais je ne sais mettre les 
info-bulles qu’en HTML, et dans LibreOffice Calc… (car Excel Starter ne permet pas
d’en ajouter).

Sur tout cela je n’ai pas encore pu réviser beaucoup de touches mortes…

Marcel

--
Pour ne plus recevoir les messels de cette liste de discussion, envoyez un messel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".