::: Désolé de te contredire mais c’est qu’on parle vraiment de la même chose. Tu veux utiliser un caractère hors BMP comme caractère de base à modifier par touche morte, j’explique comment ça marche et ça n’ajoute pas de “touche” morte, seulement en interne il y a enchaînement mais à une vitesse qui ne vient pas à la conscience de l’utilisateur. À l’usage tout se passe normalement. [[Utilisateur:Marcel|Marcel]] ([[Discussion utilisateur:Marcel|discussion]]) 3 septembre 2016 à 20:44 (CEST)
::: Désolé de te contredire mais c’est qu’on parle vraiment de la même chose. Tu veux utiliser un caractère hors BMP comme caractère de base à modifier par touche morte, j’explique comment ça marche et ça n’ajoute pas de “touche” morte, seulement en interne il y a enchaînement mais à une vitesse qui ne vient pas à la conscience de l’utilisateur. À l’usage tout se passe normalement. [[Utilisateur:Marcel|Marcel]] ([[Discussion utilisateur:Marcel|discussion]]) 3 septembre 2016 à 20:44 (CEST)
::::Ça veux dire que pour que ça marche il faut décomposé de caractère hors BMP, qui sont desfois considérer comme ligatures, et utiliser le premier caractère décomposé en morte ? La question est comment est décomposé 1F12F ? --[[Utilisateur:Flavien21|Flavien21]] ([[Discussion utilisateur:Flavien21|discussion]]) 5 septembre 2016 à 09:37 (CEST)
::::Ça veux dire que pour que ça marche il faut décomposé de caractère hors BMP, qui sont desfois considérer comme ligatures, et utiliser le premier caractère décomposé en morte ? La question est comment est décomposé 1F12F ? --[[Utilisateur:Flavien21|Flavien21]] ([[Discussion utilisateur:Flavien21|discussion]]) 5 septembre 2016 à 09:37 (CEST)
:::::Bon effectivement j’ai testé mais ça ne fonctionne qu’à moitié. La décomposition de 1F12F est D83C+DD2F. Ça ne fonctionne qu’à moité dans le sens que ça m’affiche bien le caractère voulu, mais ça m’ajoute DD2F deuxième caractère de la décomposition. Ça pose donc problème. --[[Utilisateur:Flavien21|Flavien21]] ([[Discussion utilisateur:Flavien21|discussion]]) 5 septembre 2016 à 10:00 (CEST)
=== Barre inscrite ===
=== Barre inscrite ===
Version du 5 septembre 2016 à 09:00
Pour une bonne utilisation des pages de discussion :
répondez à la suite (en-dessous) des précédentes contributions et évitez de les modifier ;
Note pour mémoire que cette page de discussion a déjà été utilisée en 2010. Elle comporte quelques discussions sur la touche compose et la touche morte symbole monétaire et est maintenant « archivée » sur Discussion:Version 1.0.1/archives. – A2 (discussion) 9 février 2016 à 03:13 (CET)
Première proposition de placement des caractères demandés par l’AFNOR
Une première proposition ébauchée en janvier 2016 sur la ML (en rouge) :
la brève morte (˘) passe de clavier bépoAltGr+clavier bépoW en clavier bépoAltGr+clavier bépoMaj+clavier bépoV
le tilde du K devient mort
l’eng (ŋ) est mis en clavier bépoAltGr+clavier bépo(Maj)+clavier bépoN
le schwa (ə) passe en clavier bépoAltGr+clavier bépo(Maj)+clavier bépoW
l’ezh (ʒ) est mis en clavier bépoAltGr+clavier bépo(Maj)+clavier bépoZ
la morte double accent grave fonctionne en miroir de la double accent aigu (donc clavier bépoAltGr+clavier bépoMaj+clavier bépoÈ devient un double accent grave mort)
le trait-d’union insécable est mis en clavier bépoAltGr+clavier bépoMaj+clavier bépoK. – Milton (discussion) 2 février 2016.
Valse des touches mortes
La première proposition pose la question de la suppression des accès aux tilde et grave non-morts. Ainsi que la perte de l'accessibilité du tilde mort et de la brève très utilisée par les espérantistes qui ont de suite soulevés des interrogations quant à son replacement en clavier bépoAltGr+clavier bépoMaj. Plus fondamentalement, on a plusieurs problèmes de fond avec les touches mortes. On ne doit pas les déplacer à des endroits inaccessibles alors qu'elles portent de nombreux caractères et qu'il faudrait leur donner plus d'accessibilité. À cause des contraintes historiques (pas de compose sous Windows), on traîne des caractères rares en clavier bépoAltGr+clavier béporangée de repos : il y a seulement trois touches mortes des vingt existantes en AltGr sur la rangée de repos…
J’en profite pour mentionner le problème des touches mortes qui sont sur les caractères avec lesquelles elles peuvent se composer, tréma/point en chef/tilde et monnaie morte et qui entraînent des doubles frappes de la même touche dont on pourrait se passer. – A2 (discussion) 9 février 2016 à 23:35 (CET)
Le grave non mort est encore en Maj+%, non ? – Flavien21 10 février 2016 à 13:05 (CET)
Oui, le grave non mort est à cet endroit.
Mais je ne suis pas sûr de suivre : il y a un consensus sur le fait de rendre certains caractères composables exclusivement avec la touche Compose ?
Je suis plutôt en désaccord avec le fait de virer les caractères du français courant de la carte simplifiée, notamment le ù. De même, je me permets de penser que l’« Æ » et l’« Œ » du français, l’« € » qui est la monnaie de l’UE ou encore l’ß de l’Allemand (dialecte parlé par plusieurs millions de francophones de France, de Belgique et de Suisse) devraient rester les plus accessibles possibles.
Quant aux touches mortes, certes l’emplacement de la plupart d’entre elles induit des répétitions, mais il permet aussi de faciliter la mémorisation de la carte complète. Je pense qu’il est plus intuitif pour un francophone de retrouver les trémas sur une {voyelle} que sur une consonne. Le tilde sur le {N} a aussi un sens pour ceux qui ont des notions d’espagnol ou de portugais. La barre sur le {L}, idem en raison du Polonais. Et cetera.
Après, pour la ligature IJ (qui si je ne m’abuse est de plus en plus réalisée par deux caractères), why not. Pourquoi pas aussi virer certains des symboles de copyright (encore que dans mon souvenir, l’un des trois était plus utilisé, je ne sais plus lequel). Mais il faudrait éviter de systématiser le recours aux touches mortes pour la saisie du français et des langues les plus parlées des locuteurs francophones (l’anglais ne pose pas de problème, mais l’allemand ou l’espagnol devraient être pris en compte, a minima).
Cordialement --Milton (discussion) 10 février 2016 à 14:23 (CET)
Merci de rappeler qu’on a le grave non mort en doublon. – A2 (discussion) 10 février 2016 à 20:33 (CET)
Tenant compte de ce message d’A2, j’ai listé sur ma page personnelle quelques idées concernant les touches mortes. Cordialement --Milton (discussion) 16 février 2016 à 23:51 (CET)
Le problème de la double frappe du n tilde est résolu à son tour si l’on place le tilde mort sur T, où il profite de la même mnémonique que le macron mort sur M. La touche morte Étendu (Latin et ponctuation) pourrait être versée dans une touche morte Groupe façon ISO/CEI 9995 qui peut être placée en AltGr sur G, parce que le grec peut être mis en touches vives, sous Windows grâce à la modificatrice Oyayubi droite (ROya) ajoutée à la bascule Verr Cap (garder l’auriculaire gauche sur Verr Cap et redonner un coup après avoir fini). Mac et Linux doivent avoir l’équivalent. Sur R et N je mettrais l’Ɛ et l’Ɔ en touches vives car très utilisés – souvent en voyelle double – dans la Francophonie, notamment en bambara. Enfin, une fonctionnalité compose propre au bépo éviterait en particulier de perdre la couverture des symboles de copyright et de marques, et donnerait aux personnes intéressées une alternative à l’apprentissage de cartes de touches mortes (mémoire visuelle vs mémoire textuelle). Je mettrais cette touche morte compose en AltGr sur C. Marcel (discussion) 21 mai 2016 à 15:50 (CEST)
Une touche morte pour le latin étendu ?
2 propositions ont été envoyées sur la ML, le fait de rajouter la touche est très débattu mais cela à l’avantage de ne rien toucher à la couche de base et d’aller plus loin que les 2-3 lettres de l’AFNOR.
La position de cette touche est proposée en clavier bépoAltGr+clavier bépoMaj+clavier bépoÀ ou clavier bépoAltGr+clavier bépoMaj+clavier bépoL.
Proposition de Flavien21 :
Latin étendu et ponctuation étendue
♯
♭
♮
‐
―
‒
♀
⩽
‹
⟨
♂
⩾
›
⟩
⸢
⌜
⸤
⌞
⸣
⌝
⸥
⌟
♢
♣
♡
♠
※
⅓
⁜
☞
ↀ
⅔
-
ↁ
⅛
∴
∵
ↂ
⅜
⁂
ↇ
⅝
◌
ↈ
⅞
‴
⁗
⌫
↹
Ꞵ
Ɛ
⁊
ȹ
℗
Ɔ
Ꞷ
Ʌ
Ɯ
ȸ
Lj
LJ
Ʒ
Dz
DZ
Ƿ
ȣ
⏎
⇪
Ɑ
Ʊ
ɥ
Ɩ
Ǝ
Ꞌ
ʔ
Ɂ
ʕ
ϴ
ſt
st
ʁ
Ŋ
Nj
NJ
⇧
fl
fi
Ꜣ
ꜥ
Ȝ
Ʃ
⁃
•
ĸ
‽
⸮
Ꭓ
Ɣ
Ƕ
ffl
ff
ffi
⇧
Ctrl
Super
Alt
‾
AltGr
Super
Menu
Ctrl
Proposition de yeKcim :
Moins fournie et reprend des caractères de la couche de base.
À titre personnel, je ne vois pas de raison de se priver de tous les caractères qu’a inclus Flavien. Avec cette nouvelle touche morte, on ne manque pas de place. Cordialement --Milton (discussion) 13 février 2016 à 19:31 (CET)
Je n’enlèverais surtout rien de la proposition de Flavien21. L’avantage de la proposition de yeKcim que je vois, c’est qu’elle place l’Ɛ sur clavier bépoÈ, car avant la réforme de l’orthographe du bambara en 1982, l’È était la graphie officielle du son aujourd’hui écrit Ɛ. Du coup la touche clavier bépoÉ devient libre pour l’Ǝ, et il est important d’avoir une touche poiur l’Ǝ comme dans la proposition de yeKcim car sa minuscule n’est pas encodée au même endroit que celle du schwa, pour la bonne raison pratique que la séparation des deux lettres permet un bon fonctionnement de la conversion de la “casse”. Comme indiqué sur la ML, la minuscule d’Ǝ est ǝ U+01DD. Marcel (discussion) 19 mai 2016 à 15:15 (CEST)
Personnellement je ne comprends pas la logique de fourre-tout. Quand on regarde http://bepo.fr/wiki/Touches_mortes chaque layout a sa logique, aucun n’est fourre-tout tel que celui que Flavien21 propose. Quelle est la logique ?
Ce n’est pas si fourre-tout que ça. Si tu prends en compte que c’est une touche morte latin étendu et ponctuation étendu, à part les cœur, pique, carreau, trèfle, mâle et femelle, tout est logique. alpha latin sur a, beta latin sur b, ej sur j, esh sur x [logique catalane pour celui là car le x ce prononce ʃ (sauf entre deux voyelles)]… Flavien21 (discussion) 15 février 2016 à 22:41 (CET)
Si je puis me permettre une suggestion : si je ne pense pas que la carte « latin étendu » soit la meilleure place pour les caractères « Vénus/femelle », « Mars/mâle » ni les symboles de musicologie : ils ne relèvent vraiment pas de l’alphabet latin étendu, mais sont des symboles à usage technique précis (Mars et Vénus en astronomie, dièse, bémol et bécarre en musique…). Je pense qu’il vaut donc mieux les inclure dans une carte « symboles mathématiques et techniques » (ma page perso comporte une proposition en cours de finalisation), allégeant cette carte-ci. Il en est de même, je pense, pour les chevrons étirés que tu as placés en AltGr + 2/3 (produit scalaire des mathématiciens), et éventuellement des tierce et quarte.
On peut éventuellement discuter de la pertinence des couleurs de cartes ou des ⁜ et autres, encore que je ne pense pas que ces symboles soient « gênants » (ils peuvent peut-être servir de puces ?). Je trouve très appréciable le fait de donner accès aux ponctuations plus rares comme l’astérisme, le point d’ironie, les traits d’union insécable/conditionnel, etc.
Par curiosité, les ligatures de D, C et I en haut à droite, c’est des chiffres romains ?
Cordialement --Milton (discussion) 15 février 2016 à 23:05 (CET)
Dièse est là en étendu du # qui lui ressemble et bémol et bécarre sont là par extensions.
Je suis tout à fait d’accord pour mâle/femelle et la couleur des cartes, je les ai ajouté juste comme ça.
Oui, ↀ, ↁ, ↂ, ↇ et ↈ sont les chiffres romain pour 1 000, 5 000, 10 000, 50 000 et 100 000. Flavien21 (discussion) 15 février 2016 à 23:42 (CET)
En réponse à la requête de yeKcim, je vais tâcher d’expliquer la « logique de fourre-tout ».
Chaque touche morte réelle est une ressource précieuse. (Je l’appelle touche morte réelle pour la distinguer des touches mortes virtuelles auxquelles on a accès par chaînage de touches mortes.) Précieuse car l’augmentation du nombre de touches mortes réelles se fait aux dépens des touches vives.
Le souci de l’efficience impose d’exploiter au mieux toutes les cartes d’agencement, que ce soit la carte de base, la carte du groupe secondaire ISO/IEC 9995, du groupe tertiaire et suivants le cas échéant, et les cartes des touches mortes.
Agencer le clavier dans ce souci de l’efficience soulève un défi mnémonique. Moins on laisse de ressources dormantes, plus on valorise le potentiel de la disposition, et plus il faudra retenir – ou pas, car les caractères supplémentaires sont là uniquement pour les utilisateurs intéressés. Ceux qui n’en ont pas l’utilité ne sont pas tenus de les retenir. On pourrait d’ailleurs, pour faciliter la tâche de sélection des objets d’apprentissage, choisir de colorer les cartes en rehaussant le contenu de base. Par exemple dans le cas de la touche morte Étendu (Latin étendu et ponctuation étendue), on pourrait colorer toute la carte d’un ton pastel puis colorer en blanc les lettres du latin étendu et les ponctuations comme les guillemets-chevrons simples. Marcel (discussion) 19 mai 2016 à 17:14 (CEST)
Suite à la modification d’A2 de la page Version 1.0.1 ou il mettait un lien vers la page Touche morte latin étendu, j’ai donc créé cette dernière en y faisant une proposition très sensé et en accord avec la logique X.org pour une implémentation sur Linux (à part peut-être un ou deux caractères). Je vous invite à en discuter sur la page Discussion:Touche_morte_latin_étendu.
La description caractère par caractère n’est pas terminée. J’ai repris le modèle de la page de la touche morte monnaie. --Flavien21 (discussion) 30 août 2016 à 19:16 (CEST)
On perd quand même pas mal de caractères et autres accès pratiques. Tu veux vraiment chambouler la carte à quelques semaines de la normalisation alors que c’était parfaitement consensuel sur la ML ? :| Je reconnais que ça permet de beaucoup alléger la carte, après… --Milton (discussion) 30 août 2016 à 20:37 (CEST)
Ben en fait on en avait pas encore discuter et je doute fortement que la carte sera accepté tel quel par la communauté --Flavien21 (discussion) 30 août 2016 à 21:50 (CEST)
De toute façon, la normalisation consiste à définir un ensemble minimum de choses, en laissant de la place pour que les pilotes ajoutent ce qu'ils veulent. Si la carte latin étendu est trop chargée, personne ne la retiendra de toute façon. Dans ces conditions, je trouve que c'est une bonne idée d'avoir une carte « légère ». --Thomas (discussion) 30 août 2016 à 22:47 (CEST)
D’où l’avantage de normaliser plutôt un ou mieux deux sélecteurs de groupe symétriques, car ce sera conforme à ISO/IEC 9995 et personne ne demandera de logique au niveau des inclusions (seulement pour les placements). Ce sont juste une, deux ou trois (ou plus de) cartes supplémentaires.Marcel (discussion) 30 août 2016 à 23:32 (CEST)
Je pense qu’on peut s’accommoder de la perte des ligatures obsolètes, des chiffres romains > 500, des symboles de cartes, des anguleux ou encore des caractères sténographiques. Je peine à voir l’utilité des fractions (idem sur la couche de base d’ailleurs). Quant à la suppression des symboles musicaux et des tierce et quatrième, je suppose qu’ils migrent en couche maths ?
J’ai juste un peu de mal à comprendre le choix du placement du thêta latin, et serais favorable à la réintroduction des puces ⁃ et ▪. Mais sinon, beau travail d’allégement, merci à toi ! --Milton (discussion) 31 août 2016 à 12:20 (CEST)
Le Thêta latin peux passer en C, j’ai l’ai mis là car, pour mêtre une lettre par touche je ne voulais pas le laisser avec le Þ, je l’ai donc mis sur ç, car en API c’est le phonème le plus proche qui correspondait. Pour les autre caractères disparu, on peux les remettre en latin étendu, j’essayais de trouver des positions qui plairaient aussi à X.org, je n’ai pas fini du tout la page Latin Étendu, et depuis le début de ma mission à Franceinfo j’ai un peu moins le temps. --Flavien21 (discussion) 31 août 2016 à 20:20 (CEST)
Ah d’accord, ne connaissant pas le roumain, je ne savais pas ce qui t’avait poussé à le mettre là. J’ai l’impression que le reste est bon. :) --Milton (discussion) 31 août 2016 à 21:13 (CEST)
Attention à ne pas confondre Roumain et Rromani, deux langues complètement différentes. Cela dit je m’étais basé sur sa prononciation en API (θ, comme pour le þ) car en Rromani il se prononce comme un simple t (ou parfois d) --Flavien21 (discussion) 1 septembre 2016 à 05:03 (CEST)
Pardon, je voulais dire rromani en plus… --Milton (discussion) 2 septembre 2016 à 21:29 (CEST)
Changement en attente ?
Vu sur la page : «Touche de basculement linguistique permettant de saisir dans d’autres alphabets (grec, arabe, cyrillique, hébreux, au moins)... par Maj+F[1-6]»
Attention aux combinaisons Maj+F[1-6] qui peuvent être utilisées par les logiciels...
Le changement de disposition clavier via l’OS comme dans les pays multilingue est préférable. Flavien21 (discussion) 12 février 2016 à 19:41 (CET)
Inversion espace fine insécable et espace insécable
Bonjour ! Sur la mailing list (saturée de nouveaux messages), a notamment été débattu l’usage typographique des espaces insécables. Si j’ai bien suivi (que nul n’hésite à me corriger !), l’espace insécable classique (EIC) n’est presque plus utilisée en typographie moderne, où elle est supplantée devant les « ; », « : », « ? » et « ! » ainsi qu’entre les guillemets par des espaces fines insécables (EFI). Je ne connais en fait aucune situation qui nécessite une EIC dans les textes tapés aujourd’hui (il semblerait, d’après ce qui s’est dit sur la ML, que certains imprimeurs aient par le passé préféré une espace insécable justifiante (EIJ), qui serait insécable mais de largeur variable).
En fait, selon le standard Unicode l’espace insécable U+00A0 est justifiante, et tel est son comportement dans les pages web. En traitement de texte elle est à largeur fixe, et en PAO il semblerait qu’elle soit dédoublée pour que l’utilisateur ait le choix entre les deux comportements au cas par cas. Marcel (discussion) 18 mai 2016 à 21:46 (CEST)
Pour l’instant, l’EIC est accessible en {Maj + Espace}, l’EFI en {AltGr + Maj + Espace}. Le seul obstacle à un échange que j’aie lu sur la ML est un bug sur certaines applications qui ne reconnaissaient pas la combinaison Maj + Espace, bug indépendant de nous et semble-t-il corrigé partout sauf sur le client mail Thunderbird (mais connu depuis dix ans).
L’inversion des deux vous paraît-elle envisageable sur cette version ?
Bien cordialement --Milton (discussion) 13 février 2016 à 21:08 (CET)
En fait, l’inversion des deux espaces insécables amène une rupture de l’expérience utilisateur, qui ne pourrait donc se faire que dans le cadre d’une version 2.0 du bépo. Je pense aux utilisateurs de traitements de texte qui ne prennent en charge que l’EIC. De plus, l’EFI ne sert régulièrement qu’avec les ponctuations hautes, lesquelles sont mieux en séquences (voir plus bas « Touches mortes comme sélecteurs de groupe »). En fin de compte je laisserais les espaces insécables telles quelles mais je doublerais un certain nombre de ponctuations dans le groupe Circonflexe, et j’utiliserais le bépo uniquement accompagné de Clavier+. L’équivalant sous Linux et Mac reste à trouver voire à faire. Marcel (discussion) 18 mai 2016 à 21:39 (CEST)
Je sais que ce nouveau pdv est contraire à ce que j’écrivais sur la ML et ce que j’ai écrit encore le même jour au matin. En fait j’avais déjà pensé à utiliser Clavier+ pour les séquences espace-ponctuation. Pour désactiver l’insécable en Maj d’Espace en fonction de l’environnement j’ai mentionné Clavier+ sur la ML. Marcel (discussion) 19 mai 2016 à 00:42 (CEST)
Doubler l’espace fine insécable sur une émulation de pavé numérique
Une solution alternative, qui permet d’avoir toutes les ponctuations hautes avec l’EFI sur un même niveau, consiste à utiliser la touche 105 (ISO B00) comme modificatrice sélecteur de groupe (« KbdGrpSeltAp » sous Windows, ou plus simplement GrpSelt). C’est l’occasion d’émuler un pavé numérique – sans les keycodes – en-desssous des touches 7–9, ou mieux 7–0 pour faciliter la saisie des chiffres binaires. Les ponctuations hautes peuvent être doublées sur leurs touches respectives, et les guillemets-chevrons simples ajoutés à droite des doubles. Sur la barre en mode pavé numérique il faut l’EFI puisque c’est le séparateur de milliers français. Pour les doubles et triples zéros il reste les touches C et K. Les chiffres A–F peuvent être placés sous la main gauche, dont l’auriculaire serait bloqué, en mode pavé numérique, sur la nouvelle modificatrice B00.
Le problème serait la portabilité, à la fois physique car les Typematrix n’ont semble-t-il pas de touche B00, et logicielle parce que GrpSelt(Ap) est probablement une implémentation du sélecteur de groupe ISO/IEC 9995, qui sous Linux est évidemment implémenté de manière bien plus évidente (même si pour le coup je ne sais pas comment, mais j’ai vu que la norme est implémentée à la lettre).
Mais en gros il n’y a pas de problème car l’objectif est un bépo 105 touches, et « le plus universel possible » “donc” à commencer par Windows qui est typiquement le facteur limitatif. Les autres OS ne manqueront pas de modificatrices supplémentaires. Oyayubi droite (ajoutée sur la bascule VerrCap) est déjà prévue pour le grec, et Oyayubi gauche qui serait ajoutée sur une éventuelle bascule Kana, pour le cyrillique. Marcel (discussion) 6 juin 2016 à 20:51 (CEST)
Touches mortes comme sélecteurs de groupe
Pour augmenter l’ergonomie encore plus, on peut considérer les touches mortes comme des sélecteurs de groupe. Cela concerne avant tout la touche morte circonflexe, parce que c’est la seule en accès direct. Le rôle de sélecteur de groupe s’inspire d’ISO/IEC 9995 et équivaut à une modificatrice rémanente.
Un exemple d’exploitation du potentiel de la touche morte circonflexe est le doublage des guillemets-chevrons simples, déjà prévus dans le groupe Latin étendu - ponctuation étendue :
clavier bépoêclavier bépo« donne ‘‹’
clavier bépoêclavier bépo» donne ‘›’
On peut aussi doubler des ponctuations pour libérer des combinaisons de touches utilisables ensuite avec Clavier+ afin de disposer des séquences espace-ponctuation via des raccourcis Clavier+ :
clavier bépoêclavier bépo. donne ‘·’
clavier bépoêclavier bépo\: donne ‘…’ (La touche vive est le deux-points.)
Cela permet d’utiliser les niveaux AltGr et Maj+AltGr de la touche du point pour des raccourcis Clavier+ par rapport au deux-points, avec ‘EFI:’ en AltGr et par exemple ‘U+2060 Espace U+2060 Deux-points’ en Maj+AltGr de clavier bépo..
clavier bépoêclavier bépo, donne ‘’’ soit l’apostrophe (typographique)
Cela permet d’avoir ‘EFI;’ par Clavier+ en AltGr de clavier bépo,.
clavier bépoêclavier bépo? donne ‘¿’
clavier bépoêclavier bépo! donne ‘¡’
Ces deux sont sans doute bien aussi en touche morte Tilde puisque les ponctuations tournées sont pour l’espagnol, car avec Circonflexe on peut avoir le point exclarrogatif ‽ par exemple. Au bout du compte en tout cas, deux ponctuations de plus en séquence avec EFI possibles par Clavier+. Marcel (discussion) 18 mai 2016 à 20:44 (CEST)
L’utilisateur peut aussi ajouter des raccourcis Clavier+ pour générer les séquences ‘«EFI’ et ‘EFI»’ en AltGr de clavier bépo« et clavier bépo», et ajouter – toujours dans Clavier+ – le remplacement des guillemets-chevrons par les chevrons mathématiques.Marcel (discussion) 19 mai 2016 à 00:51 (CEST) Mais c’est du domaine de la personnalisation, puisque dans une partie de la Francophonie les guillemets ne sont pas accompagnés d’espace insécable.
Comme proposé plus haut, je mettrais une touche morte de sélection de groupe à la place de la touche morte grec, les alphabets grec et, si tout fonctionne bien, un deuxième alphabet c’est-à-dire le cyrillique pouvant passer en touches vives, en Oyayubi droite ajoutée sur Verr Cap. (Si les niveaux Kana d’Oyayubi sont désactivés, on peut mettre le cyrillique dans Oyayubi gauche, mais pour ajouter celle-là il faudrait avoir la bascule Kana, ou remapper des scan codes si un scan code inutilisé est défini comme Oyayubi gauche.
Ce sélecteur de groupe rémanent ISO/CEI 9995 sur AltGr+G donnerait accès au groupe secondaire dont l’agencement ne soulève plus du tout de questions sur la logique puisqu’il ne porte pas d’étiquette de catégorie. Un groupe tertiaire peut être accessible par Maj+AltGr+G. Ainsi il y aura de la place pour tout ce qui est dans la touche morte Étendu proposée, ainsi que dans la touche morte IPA, notamment la lettre ɪ qui a reçu une majuscule dans Unicode 9.0 – U+A7AE – parce qu’elle ne sert pas qu’en écriture phonétique. Marcel (discussion) 21 mai 2016 à 16:17 (CEST)
Lettre apostrophe pour le breton, okina pour les langues polynésiennes
C’est aussi un bon moyen de compléter le bépo du côté des lettres apostrophe et okina, discutées sur la ML. Comme l’okina ressemble à un guillemet-virgule simple ouvrant, il serait bien en [circonflexe] guillemet-virgule simple ouvrant. Pareil pour la lettre apostrophe :
clavier bépoêclavier bépo‘ donne ‘ʻ’ (l’okina)
clavier bépoêclavier bépo’ donne ‘ʼ’ (la lettre apostrophe)
On peut aussi les obtenir à partir du guillemet simple informatique, qui lui est en accès direct, mais a priori ce sera avec [accent grave] ou [accent aigu]. Puisque le bépo a les guillemets sur le clavier, on peut mettre les lettres apostrophe et okina en [accent aigu] guillemet simple informatique et en [accent grave] guillemet simple informatique :
clavier bépoáclavier bépo' donne ‘ʼ’ (la lettre apostrophe)
clavier bépoòclavier bépo' donne ‘ʻ’ (l’okina)
Mais ces touches mortes ne sont pas en accès direct, donc on peut mettre ces lettres en [circonflexe] guillemet simple informatique pour la lettre apostrophe, et [circonflexe] accent grave espaçant pour l’okina (accent grave espaçant ou accent grave vif) :
clavier bépoêclavier bépo' donne ‘ʼ’ (la lettre apostrophe)
clavier bépoêclavier bépo` donne ‘ʻ’ (l’okina) Marcel (discussion) 4 juin 2016 à 17:47 (CEST)
Pavé numérique émulé sur le bloc alphabétique
Une demande existe pour une émulation de pavé numérique sur le bloc alphanumérique des claviers qui ont le pavé numérique au delà du bloc d’édition, ou qui n’ont pas de pavé numérique du tout, même pas en couche fonction. Pour avoir les caractères du pavé numérique et les double/triple zéro, lettres hex, opérateurs au choix et plus, on peut utiliser la touche 105 pour y mettre une modificatrice dédiée au pavé numérique émulé. Sur la barre d’espace on a la fine insécable du coup.
La modificatrice utilisable est par exemple sous Windows le sélecteur de groupe, appelé un peu bizarrement « KBDGRPSELTAP » (au lieu de KBDGRPSELT) sans qu’il y ait la moindre documentation accessible. Je sais qu’elle fonctionne car je l’ai testée avec succès il y a 2 jours. Mais il y a des problèmes de désactivation de niveaux supérieurs, qui apparaissent et disparaissent au fil des tests. En tout cas pour un pavé numérique c’est bon, et la touche 105 paraît être là pour cela vu que le bépo y a mis l’ê. Sur les claviers 104 touches de bureau on peut mettre cette modificatrice sur Windows gauche, mais pas dans le pilote. Cela peut se faire avec le scan code mapper de Windows. Marcel (discussion) 4 juin 2016 à 17:47 (CEST)
Versionnage du bépo
J’ai failli changer le titre en « Version 1.1 » à cause de la règle qui réserve le troisième numéro aux versions de débogage. Le système de versionnage couramment utilisé incrémente le deuxième numéro en cas d’ajout de nouvelles fonctionnalités.
Il faudrait à mon avis trouver moyen de ne plus parler d’une version 1.0.1 mais d’une version 1.1 pour éviter les malentendus et les quiproquos dans les relations avec l’extérieur, pas tant l’Afnor car elle est au courant, mais la presse. Je pense qu’on va faire l’économie de pas mal d’ennuis si l’on évite de sortir une « version 1.0.1 » au lieu d’une version 1.1. Marcel (discussion) 18 mai 2016 à 20:58 (CEST)
En même temps, garder 1.0.1 permet d’insister sur le fait que les changements sont absolument mineurs. C’est important pour la communication aussi… --Milton (discussion) 31 août 2016 à 12:22 (CEST)
Je reviens sur ma position suite au message de StatelessCat sur IRC, approuvé par Iiiak :
Dans la communautédev, il est courament admis commo référence : http://semver.org/. Si tu utilise le troisième niveau d'incrément de la version (1.0.0 -> 1.0.1), c'est pas pour un changement' même mineur. C'est vraiment pour un bug fix. le comportement de l'app/module/spec ne doit pas volontairement changer.
Cordialement --Milton (discussion) 2 septembre 2016 à 21:36 (CEST)
On renomme la page du coup ? En « Version 1.1 »? Marcel (discussion) 3 septembre 2016 à 22:45 (CEST)
Suite à cette discussion, je viens de renommer la page. Marcel (discussion) 4 septembre 2016 à 19:11 (CEST)
OK merci. :) --Milton (discussion) 4 septembre 2016 à 22:34 (CEST)
Changements à débattre
Suite à mention sur la ML, je mets ici les (derniers ?) changements à discuter. Certaines discussions sont retranscrites de la ML, il peut y avoir des erreurs ou oublis. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Variante en A
Concernant la variante en A, on est d’accord qu’on part sur un développement d’une version séparée, et qu’on demandera le point de vue de l’AFNOR avant de trancher si on en fait quelque chose d’officiel ou pas ? --Milton (discussion) 29 août 2016 à 12:25 (CEST)
On peut avoir à la fois la saisie en A et la touche tiret, et une version unique à promouvoir, si l’on place l’« À » sur la touche {4}, où il sera d’une accessibilité comparable à celle de l’« È » : Quand on tient la main en A et qu’on étend l’index et le majeur, on atteint en même temps l’{È} et la {(}. Celle-ci passerait en AltDroite + {A}, l’« Æ » sur {@}, l’« @ » sur {=}, le « = » sur {%}, lequel passerait au même niveau que les chiffres, soit Alt droite ou AltDr, qui sous Windows sera alors Kana, ou “Pro” comme Programmeur. Marcel (discussion) 30 août 2016 à 16:47 (CEST)
Il y a un moment, Marcel, tu finis par être vraiment hors-sujet. La page de discussion devenant rapidement illisible on va finir par faire du ménage. nemolivier (discussion)
Donc en fait on va basculer ça sur la page Discussion:Version 2.0 :) Marcel (discussion) 3 septembre 2016 à 22:37 (CEST)
J’ai fait du ménage à l’aide d’une page Version_2.0 créée tout à l’heure qui renvoie vers les pages du projet de la v2, et où je vais pouvoir détailler la proposition urgente pour une version 2.0 en parallèle aux discussions sur la version 1.1 Marcel (discussion) 4 septembre 2016 à 19:16 (CEST)
Point souscrit
Passage du point souscrit en AltGr+H (pour simplifier la saisie du ḥ en arabe), et déplacement de l’obèle en AltGr+Maj+H [avec obèle simple en AltGr+Maj+G, ajout ultérieur par Milton] : pas vu ni de soutien, ni d’opposition. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Double obèle passerai donc en Latin+obèle, mais ceci dit je proposais le laisser le point souscrit en AltGr+Maj+Q si on ne récupérait pas la place pour autre chose. Et rien n’empêche d’y mettre en plus en double point suscrit. --Flavien
Double point suscrit ? Jamais vu ça sauf comme tréma et comme i avec point dur, résultant en i avec deux point empilés. Le placement : Est-ce que la dispo ne serait pas plus facile à apprendre si l’on mettait le maximum de touches mortes sur la touche de leur initiale ? --Marcel
Pourquoi donc ? J’ai oublié de préciser, pour garder les deux obèles, on peut très bien en mettre une en AltGr+Maj+H, c’est libre et à côté. Pourquoi le point souscrit sur Q ? Il n’y a aucun caractère en point souscrit+Q, tandis qu’il y en a un en point souscrit+h. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
C’est sa place actuelle sur Q Flavien21 (discussion) 29 août 2016 à 16:32 (CEST)
Oui, mais qu’y a-t-il de logique dans cette position ? --Milton (discussion) 29 août 2016 à 22:01 (CEST)
Pas plus que l’ogonek en AltGr+F --Flavien21 (discussion) 29 août 2016 à 22:07 (CEST)
Ben justement, ça permettrait de donner une logique à la position de cette touche ! :D --Milton (discussion) 29 août 2016 à 22:36 (CEST)
Si l’arabe est pleinement supporté et que cette modification aide à sa saisie, je suis pour. Il y a un certain nombre d’arabophones qui sont aussi francophones, cool si le bépo peut les aider. Mais je pense qu’ils changent complètement de dispo pour écrire vraiment en arabe et pas avec l’alphabet latin, non ? nemolivier (discussion)
La romanisation standard de l’arabe est en effet pleinement supportée (avec l’ajout de deux caractères en latin étendu), et je confirme qu’avoir le point souscrit ainsi non seulement aide à sa saisie, mais surtout est un bon mnémotechnique (la position actuelle en Q n’ayant pas vraiment de logique). En ce qui concerne la saisie, les quelques arabophones que je connais (une quinzaine) ont souvent recours au « système D » pour écrire de l’arabe romanisé (que qui reste beaucoup plus simple que de passer par un outil de saisie des caractères arabes) à base des vingt-six lettres latines et de quelques chiffres pour émuler les lettres manquantes. --Milton (discussion) 30 août 2016 à 12:20 (CEST)
Placer un maximum de touches mortes sur la touche de leurs initiales ne permettrait-il pas de réduire la charge mentale ?
Pour le plein support de l’arabe, prévoir aussi les caractères arabes en touches vives. Sous Windows j’ai cette modificatrice sur la bascule Pro et ne peux que recommander cette option pour le bépo. Marcel (discussion) 30 août 2016 à 23:41 (CEST)
Lettre apostrophe
Déplacement de l’hameçon mort sur AltGr+Maj+{B}, la position libérée récupère la lettre-apostrophe du breton (ʼ) : y a-t-il des oppositions, ou des propositions alternatives pour le lieu d’atterrissage de l’hameçon mort ? --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Qu’est-ce qui ne va pas en {Latin}+{Apostrophe} ? Ça se retient facilement et c’est pas une tannée à taper. Si on doit réellement le mettre à la place du crochet/hameçon on peux déplacer ce dernier sur AltGr+Maj+{Q} la barre du Q majuscule rappelant le crochet et ça donne une bonne raison de déplacer le point souscrit en AltGr+{H}. --Flavien
Je reprends la proposition de Thomas. Ça permet d’avoir cette lettre, qui sert dans les langues de France, sur la couche de base. Après, peu m’importe personnellement, mais j’aime bien l’idée d’avoir la hampe en Q. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Flavien, tu peux résumé tous les changements que tu proposes ? Ça semble bien coller.nemolivier (discussion)
Je ne propose aucun changement, si ce n’est des adaptations par rapport à ce que disent les autres. Certains veulent la lettre apostrophe en touche vive (pour une raison qui m’échappe, car ce n’est pas plus utilisé en breton que le ó en catalan par exemple). J’essaye juste de leur trouver une solution logique pour y parvenir.
Vu qu’ils voulaient mettre la lettre apostrophe en AltGr+Maj+’, il faut donc déplacer le Crochet/Hameçon. Vu que Milton propose de mettre le point souscrit en AltGr+H pour la retranscription de l’arabe qui utilise ḥ, ça libère AltGr+Maj+q, ce qui tombe bien car le Q a un truc qui ressemble à un crochet, pourquoi ne pas y mettre le Crochet du coup. Voilà, mais ce n’est pas forcément une proposition à proprement parler.
Et donc, pour reprendre ma proposition de deux sections où j’avais honteusement confondu la corne et le crochet, vous paraît-il envisageable de migrer le cornu (AltGr+Maj+{virgule}, c’est bien ça ?) mort en AltGr+Maj+{apostrophe}, et de ramener la virgule souscrite en AltGr+Maj+{virgule} ? --Milton (discussion) 30 août 2016 à 00:38 (CEST)
Si la lettre apostrophe reste en Latin étendu oui, sinon ça risque d’être compliqué--Flavien21 (discussion) 30 août 2016 à 01:09 (CEST)
Thomas, peut-être peux-tu détailler ta proposition de passer la lettre apostrophe en accès vif ? :-) --Milton (discussion) 30 août 2016 à 00:27 (CEST)
Ma proposition part d'un double constat.
Premièrement, l'apostrophe-lettre est utilisée en breton (et ça devrait aussi être le cas en anglais si l'on en croit [ce lien]). Or le breton est une langue de France, et notre travail s'inscrit dans le cadre de la normalisation AFNOR, qui a pour but de définir un clavier pour toutes les langues de France. Donc il est pertinent d'avoir l'apostrophe-lettre en accès vif.
Pour des raisons mnémotechniques, il est intéressant de regrouper ce caractère avec les autres apostrophes. Deux touches sont candidates:
la touche virgule {, ; ’ ơ} (corne)
la touche apostrophe {' ? ¿ ỏ} (hameçon)
Ces deux touches sont déjà remplies; il faudrait donc déplacer soit la corne soit l'hameçon.
Deuxièmement, le caractère ¦ accessible par AltGr+Maj+b est inutile : personne n'a jamais su à quoi il servait. On peut donc le supprimer.
Par conséquent, je propose de déplacer la touche morte corne depuis AltGr+Maj+, vers AltGr+Maj+b et de mettre l'apostrophe-lettre en AltGr+Maj+, en remplacement de la corne. Sur le plan mnémotechnique, la lettre b est courbe et la corne aussi; son affectation sur la touche b n'est donc pas absurde. Et dans tous les cas, une corne n'est pas une virgule. En revanche, l'hameçon ressemble vaguement à un point d'interrogation; il vaut mieux le laisser sur la touche point d'interrogation. --Thomas 30 août 2016 à 10:43 (CEST)
Je comprends pourquoi il importe de supporter la lettre apostrophe, mais la question à laquelle il faut trancher, c’est davantage : pourquoi la mettre en AltGr+Maj plutôt qu’en direct latin mort ? Au passage, merci pour le lien au sujet de la lettre apostrophe en anglais ! :) --Milton (discussion) 30 août 2016 à 12:35 (CEST)
Il me semble qu'en AltGr+Maj, nous sommes plus certains que ce sera implémenté. La couche latin étendu est susceptible d'être oubliée par certains pilotes: ce sont des caractères rares, et le fait d'avoir d'avoir une touche morte qui ne correspond pas à un diacritique est inhabituel. Il y a donc un risque que les implémenteurs ne voient pas l'intérêt de la couche latin mort. --Thomas (discussion) 30 août 2016 à 15:20 (CEST)
Ce sont nous les implémenteurs, il n’y aura pas de problèmes sur la présence de la couche latin étendu.--Flavien21 (discussion) 30 août 2016 à 16:51 (CEST)
Le lien a trouvé les exceptions pour l’usage de la lettre apostrophe – contraction de « not », dans les noms propres — il a oublié de parler du cas possessif « ʼs », mais dans tous les autres cas comme dans « They’re » ou « He’s » (qui n’est pas du possessif dans ce cas) c’est bien une apostrophe simple et sépare deux mots. Il se contredit avec ses exemples du français.--Flavien21 (discussion) 30 août 2016 à 14:56 (CEST)
Il y a peut-être des approximations dans son raisonnement, mais ça ne change rien à notre sujet :-) --Thomas (discussion) 30 août 2016 à 15:20 (CEST)
Je rejoins Flavien sur le fait que je doute que la couche latin étendu soit zappée. Elle contiendra plusieurs des caractères imposés par la norme, et ce ne sera pas la seule touche morte non diacritique (il y a déjà le dead_currency et le dead_greek, demain dead_api, dead_cyrl, dead_math). À mon avis, la principale chose qui puisse justifier un passage sur la couche principale, c’est la logique (par exemple, toutes les lettres de l’alphabet latin sont en accès vif, on ne va pas en mettre une en morte) et la visibilité que l’on accorde à un symbole (d’où ma proposition pour le copyleft). Ici, il me paraît en plus plus ergonomique de faire AltGr+T puis apo que AltGr+Maj+Apo, mais je puis me tromper. --Milton (discussion) 30 août 2016 à 18:26 (CEST)
Je propose de laisser le sujet de côté pour le moment. Peut-être que la question pourra être abordée lors de la prochaine réunion avec l'AFNOR, et que nous aurons alors plus d'éléments pour décider: l'AFNOR aura peut-être elle-même une solution, et il sera pertinent de mettre les deux claviers (azerty et bépo) en cohérence. --Thomas (discussion) 30 août 2016 à 21:00 (CEST)
Tiret (105e touche)
Le sort de la 105e touche, indépendamment de l’officialisation de la variante BÉPO-A : il semble se dégager trois possibilités : la laisser telle quelle {ê, Ê, /}, la transformer en {- — # shy} ou en {- — / shy}. La première option permet de ne pas toucher au marquage, les deux autres augmentent significativement l’accessibilité des caractères proposés dessus. Et l’on peut trancher entre le slash et le croisillon en AltGr (# est aujourd’hui plus éloigné et moins utilisé que /). --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Je suis pour ne rien toucher à la 105ᵉ touche sur la variante non-A. Mais on peux y mettre sur la 106ᵉ :D --Flavien
Je suis pour une touche tiret !! Je crois que je préfère le croisillon… nemolivier (discussion)
On pourrait également profiter de cette touche pour donner un accès plus simple à l'apostrophe typographique. On aurait alors {’ - / shy} ou {’ - # shy}. Il avait été question d'inverser les deux apostrophes (informatique et typographique), mais ça présente l'inconvénient de modifier (bien que légèrement) la gravure des claviers, et certains problèmes ont été soulevés quant à la compatibilité de l'apostrophe typographique avec certains logiciels. Avoir les deux apostrophes en accès immédiat pourrait éviter les problèmes. --Thomas (discussion) 30 août 2016 à 11:04 (CEST)
Je ne trouve pas pertinent de mettre le tiret en Maj… regarde sa fréquence. En plus il est régulièrement utilisé sans espace, avant ou après. nemolivier (discussion)
Copyleft
Sur la carte de base en AltGr+Maj+{Ç} (l’une des positions les moins accessibles) en déplaçant la virgule morte ailleurs (autre touche ou deuxième niveau de touche morte), ou passage simple en latin étendu ? C’est avant tout une question symbolique, un passage sur la carte de base permettant de rendre le symbole un peu plus visible. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Copyleft sera donc en 1F12F, plus qu’à lui trouver une place. --Flavien
De toute façon copyleft n’est pas dans la norme. Le problème de la touche latin étendu, c’est que son entropie va croissant. Si l’on laisse la lettre apostrophe en latin étendu+apostrophe et déplace le crochet sur Q, on peut alors mettre la virgule souscrite en AltGr+Maj+virgule ! --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Il y a la déjà la corne en AltGr+Maj+{virgule} --Flavien21 (discussion) 29 août 2016 à 16:37 (CEST)
Mais la corne, on propose deux sections plus haut de la déplacer sur Q. ;-) --Milton (discussion) 29 août 2016 à 22:02 (CEST)
Non, on parlait du crochet/hameçon --Flavien21 (discussion) 29 août 2016 à 22:04 (CEST)
Faut-il vraiment la touche morte cornu ? Sauf pour le diacritique cornu combinant, tous les caractères sont fusionnables avec la touche morte cédille. Marcel (discussion) 30 août 2016 à 23:54 (CEST)
La cédille, non, mais effectivement on pourrai placer la virgule morte à la place de la corne sans déplacer la corne mais en les fusionnant, l’un n’ayant que O et U et l’autre que T et S. --Flavien21 (discussion) 31 août 2016 à 08:55 (CEST)
La cédille aussi n’a que C D E G H K L N R S T, autant dire pas l’O ni l’U. L’avantage est dans le compose. « Compose virgule » vaut pour la cédille et est mieux pour le cornu que le « compose point-virgule » de la virgule souscrite (dans un compose à jour d’Unicode). Donc on peut fusionner le cornu avec la cédille, et utiliser « compose virgule virgule » comme doublage dédié au cornu, afin d’accéder aussi au diacritique combinant cornu. Marcel (discussion) 31 août 2016 à 11:58 (CEST)
Le compose peux-très bien être différent des touches morte, rien n’empêche d’avoir la corne avec la virgule en touche morte et la corne et la cédille en Compose+virgule. --Flavien21 (discussion) 31 août 2016 à 20:31 (CEST)
Faire diverger le compose et les touches mortes peut normalement être évité. L’arborescence compose est la base, tout n’est listé qu’une seule fois normalement, et les touches mortes sont comme des raccourcis pour entrer dans l’arborescence. Alors comme le compose du cornu n’est pas le compose de la virgule souscrite, mieux vaut mettre le cornu avec la cédille en accès rapide, et juste pour le diacritique combinant en accès long ajouté en doublage. Ça ce serait pareil si le cornu était avec la virgule souscrite. Mais la logique en moins. Marcel (discussion) 3 septembre 2016 à 20:50 (CEST)
En fait je n’avais pas compris. Tu es d’accord pour le compose virgule à la fois pour cédille et pour cornu, et tu souhaites le cornu dans la touche morte virgule souscrite. Donc on met les lettres cornues à la fois dans la cédille et dans la virgule souscrite. C’est effectivement une bonne idée. Le cornu n’ayant plus de touche morte dédiée, on y accédera aussi bien par virgule souscrite (compose point-virgule) que par cédille (compose virgule). Marcel (discussion) 3 septembre 2016 à 21:11 (CEST)
Bon je viens de tester et malheureusement (encore) sur Windows, les caractères hors plan 1 Unicode en touche vive ne peuvent pas servir de base pour les caractères en touche morte. Ce qui veux dire soit on évite d'utiliser AltGr+Maj+{Ç} dans les touches mortes (de tête j'en compte 2 - en grec et en cyrillique) soit on met le Copyleft sur un emplacement inusité par les touches mortes mais de fait moins logique. --Flavien21 (discussion) 31 août 2016 à 09:22 (CEST)
Sous Windows les caractères SMP peuvent servir de base pour des caractères en touche morte grâce à la fonctionnalité d’enchaînement des touches mortes. Le surrogat haut est la base, et la cible est un caractère intermédiaire quelconque, mis en morte, suite à quoi le surrogat bas est la base, pour le caractère voulu comme résultat. (J’avais testé avec d’autres séquences.) Marcel (discussion) 31 août 2016 à 11:58 (CEST)
Je ne suis pas suffisamment connaisseur pour pouvoir m’exprimer sur ces touches mortes exotiques (je suis à peine capable de différentier une cédille d’une virgule ou d’un ogonek), mais si la proposition de fusion de virgule morte et de cornu paraît censée aux utilisateurs de ces deux caractères, alors j’y suis favorable. Pour le copyleft en couche principale, ça pose problème pour le tréma+tonos en grec et pour le tche majuscule du serbe cyrillique. Il me semble qu’on peut s’en accommoder, d’autant que cette impossibilité dont tu parles semble relever du bug et devrait pouvoir être signalée à Microsoft. Bien à toi --Milton (discussion) 31 août 2016 à 12:04 (CEST)
On ne parle par de la même chose Marcel --Flavien21 (discussion) 31 août 2016 à 20:25 (CEST)
Désolé de te contredire mais c’est qu’on parle vraiment de la même chose. Tu veux utiliser un caractère hors BMP comme caractère de base à modifier par touche morte, j’explique comment ça marche et ça n’ajoute pas de “touche” morte, seulement en interne il y a enchaînement mais à une vitesse qui ne vient pas à la conscience de l’utilisateur. À l’usage tout se passe normalement. Marcel (discussion) 3 septembre 2016 à 20:44 (CEST)
Ça veux dire que pour que ça marche il faut décomposé de caractère hors BMP, qui sont desfois considérer comme ligatures, et utiliser le premier caractère décomposé en morte ? La question est comment est décomposé 1F12F ? --Flavien21 (discussion) 5 septembre 2016 à 09:37 (CEST)
Bon effectivement j’ai testé mais ça ne fonctionne qu’à moitié. La décomposition de 1F12F est D83C+DD2F. Ça ne fonctionne qu’à moité dans le sens que ça m’affiche bien le caractère voulu, mais ça m’ajoute DD2F deuxième caractère de la décomposition. Ça pose donc problème. --Flavien21 (discussion) 5 septembre 2016 à 10:00 (CEST)
Barre inscrite
À en croire ceci, l’usage le plus important du trait horizontal inscrit concernerait la lettre D (croate, same, serbe et vietnamien). Une nouvelle touche morte sur AltGr+Maj+{D} me semble être la solution la plus ergonomique. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Ça voudrait dire déplacer les maths, c’est plus que faisable. Pour l’instant moi j’y plaçait en AltGr+{Z} et je déballais donc l’API, car ƶ est une variante de z pour le français, c’est la manière dont je le fait quand j’écris à la main. AltGr+d ne me dérange pas du tout. Il faut trouver où déplacer les Maths. --Flavien
Euh non, j’ai dit AltGr+Maj+{D}, pas AltGr+{D}. ;-) --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Ben du coup on pourrai inversé les deux, on privilégie l’écriture des langes sur les symboles mathématiques. --Flavien21 (discussion) 29 août 2016 à 16:38 (CEST)
Voir selon la fréquence des usages peut-être ? --Milton (discussion) 29 août 2016 à 22:03 (CEST)
Enfin je veux dire, je sais que mon avis est biaisé puisque j’ai recours fréquemment aux maths, mais on peut inverser… --Milton (discussion) 29 août 2016 à 22:43 (CEST)
Je suis pour qu’on favorise les langues, contre les maths (désolé), mais c’est aussi que nombre de lettres mortes sont en AltGr, non ? Du coup c’est plus logique de continuer comme ça… nemolivier (discussion)
Pas à être désolé, je m’inclinerai devant ce qui arrange le plus grand nombre ! C’est vrai qu’à la réflexion, c’est sans doute plus pertinent de faire ainsi. Par contre, il y a aussi beaucoup de mortes en AltGr+Maj. Donc, rayé mort en AltGr+{D}, maths en AltGr+Maj+{D}. --Milton (discussion) 30 août 2016 à 00:23 (CEST)
Kana
AltGr vs. Kana : concerne essentiellement Windows, cela permettrait notamment de casser l’équivalence AltGr=Ctrl+Alt, donc de limiter des bogues (au prix d’une perte d’accessibilité en l’absence d’AltGr à droite gauche ?).
Rien n’empêche de mettre tout ce qui est en AltGr en Kana (et de mapper Kana sur AltGr), mais également de tout laisser en AltGr pour garder la compatibilité avec Control+Alt. --Flavien
Du coup ça ferait doublon ? Je ne sais même pas où est la touche kana :D nemolivier (discussion)
La touche kana n’est pas sur les claviers 105 par défaut, mais il est possible possible de remplacer n’importe quel touche par Kana en y changeant le VK associer. Dans notre cas, ce serai à la place de Alt Droit. Comme ça Windows le voit en Kana et non en Ctrl+Alt et on peux contrer certains raccourcis de logiciels. Cela dit, on mapperai quand même en plus les touches en AltGr normal (même s’il n’est plus sur le clavier), pour qu’on aie quand même les caractères en passant par la combinaison Ctrl+Alt. Donc c’est un doublon voulu. --Flavien21 (discussion) 29 août 2016 à 23:39 (CEST)
Le manuel d’un logiciel décrit surtout le fonctionnement de ce logiciel. Pour voir comment cela se passe concrètement sous Windows, on n’a pas grand-chose et il faut voir dans les commentaires des sources Microsoft. Il en résulte que Kana est comme Maj en ce qu’il y a une modificatrice et une bascule, sauf que le lien logique entre les deux est OR au lieu d’XOR, et que le modificatrice Kana n’a pas de VK dédié. Et sauf que cela ne fonctionne pas dans les logiciels de création et d’édition de claviers, du fait de limitations arbitraires visant à simplifier le programme.
De manière générale, pour qu’une touche soit telle modificatrice, il ne faut pas lui attribuer un VK spécial. Ce qu’il faut faire, c’est de l’inscrire dans la section d’allocation de VK à drapeau de modificatrice (static ALLOC_SECTION_LDATA VK_TO_BIT). Les bascules quant à elles sont attribuées par le VK.
Il vaut alors mieux ne pas conserver les mappages en Ctrl + Alt. Mais sur les touches non-alphabétiques, où AltGr est traditionnellement utilisé le plus, les niveaux Ctrl + Alt peuvent servir par exemple à pallier la limitation des touches mortes à une seule unité de code. Ainsi Windows aura en revanche un peu plus de touches vives. Marcel (discussion) 30 août 2016 à 23:25 (CEST)
Circonflexe et grave
Accessibilité du circonflexe et du grave espaçants : si l’on ne change rien, ils seront disponibles en {^ mort} + {espace}, {´ mort} + {espace}, AltGr+{6} et maj+{%}. Vue la faible accessibilité de ces positions sans touche morte, et l’importance relative de ces caractères ASCII pour les informaticiens, il est envisageable de les déplacer, si possible à gauche. Problème : pas de place sur les positions en AltGr, et une proposition de déplacement des accents morts suscite l’opposition. Les possibilités principales sont :
Mettre ^ et ` en AltGr+maj+{é}/{è}, les accents doubles passant en deuxième niveau de grave mort, ce qui n’est pas très grave car ils sont peu utilisés.
Ne rien changer.
Foutre ces caractères (ou l’un de ces caractères) au hasard un peu au hasard ailleurs en AltGr+Maj.
Notez qu’avant le vote en faveur de « BÉPOFM », le grave vif était en AltGr+Maj+{È}, avant que l’on ne le remplace par ȍ mort. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Je suis pour laisser comme c’est, et d’ajouter les version non morte en triple pression de la touche morte (au lieu de deux maintenant), en gros on appuis sur la même touche tant qu’on a pas le ^ ou ` qui s’affiche. Un appui : circonflexe suscrit, deux appui : circonflexe souscrit, trois appui : circonflexe non-mort, pareil pour le grave : Grave → Double grave → Grave non-mort. --Flavien
Je t’avoue que je ne suis pas fan de cette idée, sachant qu’on se retrouverait avec des comportements très différents selon les touches mortes. --Milton (discussion) 29 août 2016 à 12:25 (CEST)
Ça ne change rien au comportement actuel si ce n’est qu’en passant par la touche morte il faut faire une pression de plus --Flavien21 (discussion) 29 août 2016 à 16:40 (CEST)
Si on a ce mécanisme de triple appui, on a toujours la solution mort+espace, non ? Les utilisateurs jugeront… nemolivier (discussion)
Je suis partisan de ne rien changer à la situation actuelle : le circonflexe et l'accent grave seront accessible en frappe directe et par leur touche morte. Ce n'est pas rationnel, mais avoir ^ sur la touche AltGr+Maj+é, c'est bizarre ; j'y verrai plutôt le double accent aigu, ce qui est facile à retenir et qui correspond au bépo actuel. --Thomas 29 août 2016 à 14:21 (CEST)
OK. Pas d’autres avis ? --Milton (discussion) 30 août 2016 à 18:27 (CEST)
Accès aux chiffres
Plutôt qu’en Maj et par bascule VerrCap, les chiffres peuvent être accessibles en AltDr (Kana, “Pro”) et par bascule VerrPro (VerrKana) et en Num.
Optimiser l’ergonomie et le support typo
Le texte complet a été transféré sur la pageVersion_2.0parMarcel (discussion) 4 septembre 2016 à 18:50 (CEST)
[…] Sur le plan de l’ergonomie, les éléments nouveaux comprennent sur la rangée supérieure, l’accès avantageux aux chiffres par Alt droite (AltDr ou Pro) et sa bascule (Kana 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) […]
Marcel, on n’avait pas dit sur la ML que ce ne serait certainement pas pour cette version qu’on irait si loin dans les changements ? --Milton (discussion) 1 septembre 2016 à 14:31 (CEST)
On avait dit que le fait de sortir une version bridée maintenant et une autre version plus tard gaspille du process et n’est rien moins que sûr. Il faut par conséquent : ① Expliquer clairement les avantages d’une version optimisée ; ② Faire voter la communauté pour savoir si tout le monde est d’accord pour changer ou pour rester. Sur la ML, trois quatre personnes ont décidé pour des milliers de bépoètes actuels, et des millions à venir. Marcel (discussion) 3 septembre 2016 à 20:55 (CEST)
