« Discussion:Version 1.0rc1/Archive » : différence entre les versions

De Disposition de clavier bépo
Aucun résumé des modifications
 
(177 versions intermédiaires par 19 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{aide discussion}}
== Dates ==
Bien que, malheureusement, notre chère liste de diffusion soit toujours convalescente, je trouve qu’il serait bien de passer rapidement à la suite afin de graver cette dispo dans le marbr…heu… virtuel !
La version 6.7 me semble moins compliquée que les précédentes, et si ce n’est pas le cas… les modérateurs auto-proclamés sont là !
Je ne sais pas s’il est nécessaire de voter pour figer, il me semble que la volonté est d’aller dans ce sens là, que la décision est prise et que faire un vote n’a que peu d’intérêt compte tenu du fait qu’il n’y a pas de date précise pour une 1.0, non plus que de nombre de RC.
Tout au plus appelons cette 0.6.7, 1.0RC1


{{/Archives}}
Relisant la page me semble que les propositions sont claires. Reste à préciser :
* la place du % et ce que ça implique quant aux places accordées à « ^ » et « ` ». Et des propositions pour utiliser la place « vacante ».
* des proposition de places pour les touches mortes « crochet en chef » et « cornu », et une explication de pourquoi nous devrions les ajouter (je croyais que nous avions déjà tous les « accents » morts).


== Validation de la page de vote ==
NB: les propositions sur cette page reçoivent le blanc-seing de nos gentils modérateurs, qui se réservent le droit de les supprimer s'ils les jugent inappropriées.
Je m'y prends un peu tôt, mais je veux être sûr de ne pas oublier ce que je voulais dire… '''Je propose que la page de vote fasse l'objet d'une approbation générale avant le vote proprement dit''' (en rajoutant simplement une section à la page de discussion quelques jours avant le début du vote, dans laquelle les gens peuvent faire part de leurs remarques). Ceci pour éviter des « surprises » comme pour la version 0.6.6, pour laquelle est apparue (le mot est fort, j'ai bien remarqué après coup que cette proposition n'était pas récente puisqu'elle a été ajoutée le 9/04) par exemple une proposition concernant l'ajout des chiffres en indices (excellente idée du reste, mais dont il n'a pas été discuté), ou encore l'absence des propositions d'inversions simples RN/JF pourtant plébiscitées (Nemolivier, concernant ta réponse à mon interrogation, les stats sont peut-être rédhibitoires mais il n'y a pas que les stats dans la vie : elles sont un élément déterminant, mais ne doivent pas faire oublier que chacun utilise son clavier différemment, et que le confort de l'utilisateur est le but final… Et pour mettre les choses au clair, non, je ne défend pas l'inversion simple (j'espère d'ailleurs qu'on en a définitivement terminé avec ces 4 lettres…)).
Donc, prenons quelques jours avant le vote pour se mettre d'accord sur les propositions à garder et leurs formulation. [[Utilisateur:Skippy le Grand Gourou|Skippy le Grand Gourou]] 29 avril 2008 à 09:48 (UTC)
:Il y a eu 15 jours de vote et une semaine de nettoyage de ces dits votes. [[Utilisateur:Nemolivier|Nemolivier]] 29 avril 2008 à 10:15 (UTC)
::Yep, il y a en effet eu les 15 jours de propositions et la semaine de nettoyage. Ceci dit les complaintes de Skippy ne sont pas infondées. Voici quelques remarques et suggestions générales (non ciblées personnellement sur Nemolivier ou Skippy) pour la prochaine fois (et a fortiori si on a pas de 0.6.7 mais une RC que l'on prétendrait « stable »):
::* Plus de temps pour la mise en forme. Nous étions encore sur la mise en forme la veille au soir tard, après un WE où nous avons passé beaucoup de temps personnel pour le projet. On ne pouvait pas tous non plus participer en semaine. Malgré cela il restait encore des petits détails à règler le jour du vote.
::* Avec le temps du point précédent, on pourrait répondre à la requête de Skippy en annonçant sur la ML une demande de relecture de la page de votes quelques jours avant la phase de votes. Là c'eut été impossible, avant le WE la page n'était pas prête (Je réponds ici à Skippy : on a pas malheureusement pas eu le temps de faire valider la page).
::* Améliorer le système de vote. On pourrait comme il a été suggéré sur IRC utiliser un système de vote comme par exemple [http://fr.wikipedia.org/wiki/Vote_pondéré le vote pondéré] où on note les propositions par ordre de préférence (y compris préférences négatives dans cet exemple).
::* Plus de temps également pour les propositions : certains n'ont pas pu émettre des propositions pour la 0.6.6 car ils n'avaient pas accès à Internet (si je me souviens bien avoir lu ceci sur IRC). Sur ce point, il suffirait d'ouvrir une page permanente « propositions pour la prochaine fois » et de l'archiver pour la dépouiller lorsqu'on souhaite faire une nouvelle version. Ou alors simplement de ne faire de nouvelle version que lorsque cette page devient assez chargée, et de faire une version stable si trop peu de changements ont étés proposés en un temps fixé (quelques mois). Ce pourrait être un principe pour une branche de développement.
::* Plus de temps surtout pour les votes. Certains n'ont pas pu voter pour la 0.6.5.1… suffit d'être en déplacement ou vacances au mauvais moment, et c'est trop tard pour voter.
::* Garder toutes les propositions émises, quelles qu'elles soient (je pense à RN et FJ). À moins de choisir un système de vote très bizarre, les propositions les moins bonnes et/ou très minoritaires seront de toutes façons éliminées.
::* Réouvrir une page de discussion pour les arguments des uns et des autres en cours de vote. Pour ce dernier point il n'est d'ailleurs pas trop tard !
::[[Utilisateur:Nbrodu|Nbrodu]] 29 avril 2008 à 12:29 (UTC)
:::Je viens de réaliser le dernier point [[Discuter:Version_0.6.6/Discussions_votes|ici]]. [[Utilisateur:Fredb219|Fredb219]] 29 avril 2008 à 12:59 (UTC)
::::Pour l'ajout des chiffres en indice, vu que ça te tient à cœur et que ça fait trois fois que tu nous rabaches ça, c'est un truc dont on a parlé sur irc il y a bien longtemps, en même temps que l'ajout des exposants. Sauf que ça avait été oublié à la 0.6.5/0.6.5.1. Il ne faut pas croire que cela tombe du ciel ! On est une vingtaine toute la journée à piailler sur irc et ce n'est pas parce que ça n'est pas sur le wiki que ça n'a pas été discuté. Le hatchek pour les indices à côté du circonflexe pour les exposants, même touche, même « utilité ». À noter d'ailleurs que sans irc, le wiki ne ressemblerait jamais à ce qu'il est aujourd'hui. [[Utilisateur:A2|A2]] 29 avril 2008 à 13:18 (UTC)
:::::Et vu le nombre de Contre sur cette proposition on peut se demander si l'absence de discutions ne vient pas tout simplement d'une absence de désaccord. Par rapport au vote je trouve cela non pertinent car il y a eu un mail pour le calendrier et personne n'a présenté le moindre désaccord.
:::::Par rapport à l'accès internet c'est un faux problème, il y a 2 semaines de vote, donc largement le temps de voter (ou sinon on peut mettre un système de procuration) et les propositions rien n'empêche à quelqu'un qui n'a pas internet de donner sa proposition via ML en demandant qu'elle soit intégrée à la prochaine version.
:::::Pour le système de vote je suis d'accord que de pouvoir voter par préférence ou au moins contre une sous proposition sera une avancée.[[Utilisateur:Tiot|Tiot]] 29 avril 2008 à 14:04 (UTC)
::::::*J'estime pour ma part que la date du vote ne doit pas être forcément inéluctable, on n'est pas à deux jours près…
::::::*L'ajout des chiffres en indices ne me tient pas particulièrement à cœur (excellente initiative, et je n'ai rien à redire sur la position), simplement ça avait effectivement l'air de surgir de nulle part au moment du vote (a priori un oubli lors de l'ajout sur la page principale). Question de principe donc (idem pour les inversions).
::::::*C'est sans doute un tort, mais tout le monde ne souhaite pas nécessairement s'investir dans (ou n'apprécie pas forcément, c'est mon cas pour IRC) les trois médias disponibles (wiki/ML/IRC). Il est donc nécessaire (mais pas forcément évident je l'accorde) que les informations soient relayées (au moins sur le wiki, puisque c'est le plus accessible et le lieu des votes). Cumuler les trois médias a certainement des avantages, mais ça présente également l'inconvénient de disperser les discussions. (Bon, je vais m'inscrire sur la liste avant de recevoir vos foudres… :P) [[Utilisateur:Skippy le Grand Gourou|Skippy le Grand Gourou]] 29 avril 2008 à 20:06 (UTC)


== Ajout de la virgule souscrite morte en Shift + Alt Gr + {Ç} ==
:Alors, une proposition en réponse à moi-même. Nous nous donnons jusqu’à la fin de la semaine pour fignoler les dernières propositions (voir ci-dessus). Après quoi, une semaine de vote (15 jours c’est long, on attends pour 2% des votants, c’est nul) avec nécessité que ¾ des votants de la 066 aient voté à la fin de la semaine. Si cette proportion n’est pas atteinte, on envoie un courriel à tout le monde et on se donne 2 jours de plus. Après, basta ! [[Utilisateur:Nemolivier|Nemolivier]] 10 juin 2008 à 18:08 (CEST)


Contre-proposition : utiliser la [[Touches_mortes#Ogonek|touche morte ogonek]] pour la virgule souscrite. Ces deux diacritiques (virgule souscrite / ogonek) me semblent suffisamment proches pour ne pas nécessiter une touche morte supplémentaire. De plus, l'ogonek ne s'applique qu'aux voyelles, tandis que la virgule souscrite ne concerne que les consonnes :
== Vote pour figer, modérateurs et processus de release ==
* Șș et Țț en Roumain (à ne pas confondre avec Şş et Ţţ qui sont des cédilles)
 
* Ģģ Ķķ Ļļ Ņņ en Letton (fait habituellement avec la cédille morte, mais qu'on pourrait faire ''aussi'' avec l'ogonek)
Nous avons voté pour « organiser un autre vote pour décider si on fige ou non les caractères principaux après la sortie de la 0.6.6 ». Donc je propose de voter en même temps que la 0.6.7 :
Avantage : pas de modification de la disposition, une mise à jour du pilote suffirait. [[Utilisateur:Kaze|Kaze]] 29 avril 2008 à 11:16 (UTC)
* pour figer les lettres ou pour figer la carte simplifiée
:C'est effectivement possible, mais ça reste deux diacritiques différents. Et comme la position Shift + Alt Gr + {Ç} est libre, et que la virgule souscrite se rapproche plus de la cédille que de l'ogonek, il me semble adéquat de la placer là. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 29 avril 2008 à 12:45 (UTC)
* pour rentrer dans le [[Processus de release]] ;
:Quant aux Ģģ Ķķ Ļļ Ņņ du letton, on peut éventuellement les dupliquer sur la touche morte virgule souscrite en les laissant sur la cédille. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 29 avril 2008 à 12:47 (UTC)
* pour la liste de [[Modérateurs]]
 
Il devrait être possible de dire : {{v|Pour (sauf si…)}}
[[Utilisateur:Tiot|Tiot]] 4 juin 2008 à 09:22
 
:Je propose de voter avant de faire la 0.6.7 (par exemple… très bientôt). Je pense qu'il était clair que « organiser un autre vote pour décider si on fige ou non les caractères principaux après la sortie de la 0.6.6 » signifiait « et avant la 0.6.7 » puisque le principal argument du vote était « Il faut savoir ce qu'on se propose de figer ». En plus comme ça, il y a deux réponses possibles: pour et contre, ce qui a le mérite d'être clair.[[Utilisateur:Galbolle|Galbolle]] 4 juin 2008 à 13:47 (CEST)
::Les propositions 0.6.6 entraînaient des changements importants : inversion XHÀ, insécable sur «», inversion AU, Æ ailleur qu'en altgr A, où en altgr U… Les propositions de la 0.6.7 paraissent beaucoup plus raisonnable et ne touche pas à l'emplacement des lettres (à pars si l'inversion ?/;). D'où une possibilité de figer en même temps que la 0.6.7.[[Utilisateur:Tiot|Tiot]] 4 juin 2008 à 14:37 (CEST)
:::Le vote sera sans doute plus serein si l'on décide que si l'on fige, les changements entre 0.6.6 et 0.6.7 seront examinés par les modérateurs. [[Utilisateur:Galbolle|Galbolle]] 7 juin 2008 à 12:21 (CEST)
::::Je trouve tous ces votes une perte de temps. Le processus de « figeage » tout le monde le veux. Donc pas besoin de voter. Les modos, il y avait une liste pour savoir qui voulait s’y coller, qui avait des réflexions. Rien n’a bouger. Franchement, je ne crois pas que nous soyons des monstres et éviter un vote de plus nous ferait gagner du temps. Mettons qu’on peut ajouter l’adoubement des modos par la communauté au cours du prochain vote. ''Cf'' ma proposition ci-dessus. [[Utilisateur:Nemolivier|Nemolivier]] 10 juin 2008 à 17:57 (CEST)
:::::Oui ! [[Utilisateur:Asr|Asr]] 25 juin 2008 à 12:46 (CEST)
:::::Est-on vraiment sûr que tout le monde le veut. Moi je le veux, mais pas tout de suite. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 25 juin 2008 à 14:27 (CEST)
 
== Propositions impactant la carte simplifiée ==
=== Revenir sur la « triangulaire » HXÀ ===
J'utilise la vesion 0.6.6, et vraiment, le digramme CH est ''pénible'' (je lève tous les doigts de la main droite pour faire ce digramme !), le H à droite est une horreur pour écrire en anglais (N-grammes TH, WH, …), le X à gauche est pénible pour les couper-coller, et les combinaisons ctrl-x-c et ctrl-x-s sont pratiquement infaisables dans emacs. Revenons à la place précédente, qui rendait difficiles bien moins de choses. [[Utilisateur:Glehmann|Gaëtan]] 22 juin 2008 à 18:13 (CEST)
: Quelle idée, aussi, d'utiliser Emacs… [[Utilisateur:Kaze|Kazé]] 22 juin 2008 à 18:54 (CEST)
 
: Si je me souviens bien, on a testé cette triangulaire hxà parce que dans la version 0.6.5.1, le h était plus pénible à la suite d'un échange malencontreux avec le y ("pour tester", on a testé, on a vu). C'est sur cet échange qu'il faut revenir. Je propose donc (dans la mesure où la boîte de pandore est rouverte) de remettre H, Y, X et À à leurs places de la [[Version_0.6.2.2.2|version 0.6.2.2.2]], même si c'est de l'histoire ancienne. [[Utilisateur:Galbolle|Galbolle]] 22 juin 2008 à 23:42 (CEST)
::J'ajoute à ces arguments mon mauvais ressenti quant à la nouvelle position du X :
::Le X est souvent (toujours ?) entouré de voyelles, alors pourquoi l'avoir mis à gauche ? L'alternance main gauche / main droite est complètement cassée.
::Autre chose, c'est devenu un cauchemar de taper des mots en « aux » (auxilaire, la famille des -al au pluriel comme chevaux, bocaux et j'en passe) : tout avec la main gauche, avec un joli digramme à un doigt pour l'annulaire ! (Certes, c'est moins pire si on tape en position « dactylo », mais c'est tout de même pas très confortable.)
::La solution de Galbolle me semble tout à fait raisonnable. [[Utilisateur:Florian|Florian]] 23 juin 2008 à 01:02 (CEST)
:::Je trouve que H est mieux sous la main droite, puisqu'il est (presque) toujours suivi d'une voyelle. Effectivement il est un peu loin du {C} et les digrammes index/annulaire en descendant ne sont pas très naturels, mais je n'y vois rien de ''pénible'' pour autant, d'autant que les trigrammes CH+voyelle me paraissent largement facilités par rapport à la version 0.6.5.1. Pour le reste :
:::* en Anglais, les digrammes TH ne me gênent pas, et la difficulté des digrammes WH est essentiellement dûe au placement catastrophique du W ''([[Utilisateur:Kaze/Bépo-intl|Bépow rulez!]])'' ; même le Dvorak-US place WTH sous la même main.
:::* Je ne vois aucun problème avec les couper-coller, puisqu'on utilise forcément les flèches entre un couper et un coller.
:::* Je ne suis pas compétent pour Emacs, mais les utilisateurs d'Emacs en Dvorak-US ne se plaignent pas du fait que X soit à gauche et CS à droite… <del>Par ailleurs, ne serait-il pas possible de [[Emacs|mapper É, À ou È comme un Ctrl+X dans Emacs]] ?</del> ''MàJ : non, ce n'est pas possible.''
:::Par contre, je n'aime pas non plus la nouvelle position du X : je trouve qu'il aurait été mieux en [C] qu'en [W], même si les stats étaient légèrement plus favorables à la triangulaire HXÀ qu'à l'inversion H/X. Les fins de mots en -aux sont particulièrement désagréables, alors qu'elles seraient très naturelles avec le X en [C].
:::Concernant le retour de HYXÀ à leurs places de la [[Version_0.6.2.2.2|version 0.6.2.2.2]], je ne vois pas bien ce que ça apporterait, à part pour les digrammes PH… [[Utilisateur:Kaze|Kazé]] 23 juin 2008 à 09:07 (CEST)
::::Ça ajouterait que c'est une version où personne ne se plaignait de la place du H (ni des autres caractères concernés, pour autant que je me souvienne). Accessoirement, c'était la position trouvée par l'algo, il doit bien y avoir une raison. On avait une position du H pas mal, on a voulu tester l'inversion HY, ça n'a pas marché (de l'avis à peu près général). On a alors dit « testons l'inversion HXÀ ». Si on constate qu'elle ne marche pas non plus (je ne me prononce pas là-dessus), autant revenir à la situation qui marchait plutôt que de tester encore une nouvelle possibilité foireuse ou de revenir à une situation qu'on sait pénible, surtout si on veut figer un jour. [[Utilisateur:Galbolle|Galbolle]] 23 juin 2008 à 10:54 (CEST)
:::::Si ça permet d'aboutir à un consensus, pourquoi pas (en faisant abstraction de mon ressenti personnel sur le placement). Je colle la rangée du bas ci-dessous pour clarifier le débat. [[Utilisateur:Kaze|Kaze]] 23 juin 2008 à 11:33 (CEST)
::::::Pour clarifier encore le débat, je précise que c'est la rangée du bas de la <del>0.6.5.1.</del> 0.6.2.2.2 [[Utilisateur:Galbolle|Galbolle]] 23 juin 2008 à 11:37 (CEST)
::::::: Gni ? [[Utilisateur:Kaze|Kaze]] 23 juin 2008 à 12:44 (CEST)
<center>
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴──┬─┴──╔══════╩════╣
║  ^  ║ Ê  │ {{B|À}}  │ {{B|H}}  │ {{B|Y}}  │ :  │ K  ║ ?  │ Q  │ G  │ {{B|X}}  │ F  ║    ^    ║
║  |  ║ ê  │ {{B|à}} \│ {{B|h}} {│ {{B|y}} }│ . …│ k ~║ '  │ q  │ g  │ {{B|x}}  │ f  ║    |    ║
╠══════╩╦══════╦═════╦═══════════════════════╦═══════╦══════╦═╩════╦══════╣
</center>
Eheh si on regarde l'historique des version on s'aperçoit que le point de départ pour l'inversion Y/H est le Japonais. Dans la version [[Discuter:Version_0.6.2.2.1|0.6.2.2.1]] il y a Yota qui fait remarque que les Japonais remplaces le \ par ¥ comme séparateur des répertoires sous windows (Donc pour eux c'est C:¥windows). Il a été refusé pour la [[Discuter:Version_0.6.2.2.2|0.6.2.2.2]] et finalement accepté pour la [[Discuter:Version_0.6.2.2.4|0.6.2.2.4]] apparemment car le H était beaucoup plus utilisé que le Y et qu'il y en a qui ont vu un gain. Aujourd'hui le ¥ a été retiré… on voit bien qu'on tourne en rond.
Il y a un problème dans la méthode. On ne peut pas dire que l'inversion YH apporte un gain, puis que l'inversion XHÀ apporte un gain puis enfin que le fait de revenir à la position originale apporte un gain ! Ça n'a pas de sens.[[Utilisateur:Tiot|Tiot]] 23 juin 2008 à 15:59 (CEST)
:Non, ce que l'on est en train de faire est tout à fait en conformité avec la méthode. À la version 0.6.2.2.4, le changement a été accepter «pour essayer» et «départager les gens», il est donc logique ultérieurement de se poser la question «comment les gens se départagent-ils après l'essai ?». Il se trouve simplement qu'entre temps, on a aussi essayé une autre solution avec HXÀ. Maintenant qu'on a essayé ces solutions avec un succès divers (la 0.6.6 ne me dérange pas, en ce qui me concerne), on se demande ce qui finalement était le mieux. [[Utilisateur:Galbolle|Galbolle]] 23 juin 2008 à 16:10 (CEST)
Certes, le X n’est pas parfait. Mais mon avis est que le H est bien mieux à droite qu’à gauche. [[Utilisateur:Nemolivier|Nemolivier]] 23 juin 2008 à 12:09 (CEST)
:À mes yeux, dire que le X n'est pas parfait est un euphémisme. Je veux bien que le H soit mieux à droite, mais il va nous falloir encore combien de version avant de stabiliser le déplacement du H pour que le X (et les autres) soit bon ?
:Bref, puisqu'on est là pour proposer des solutions, je poste l'idée que j'ai évoqué sur la ML, à savoir une '''inversion X/Z''' :
:* Le X revient à droite
:* Le Ctrl-Z (annuler) devient très facile pour ceux qui continue d'être droitier de la souris. En plus, le Y est juste à côté, parfait couplage pour le Ctrl-Y (refaire, sur beaucoup de logiciels)
:* EZ reste accessible
:* Le Z est, selon l'analyse corpus, environ 3 fois moins utilisé que le X… mais cela peut être l'inverse si on privilégie le vouvoiement. En conséquence, je ne trouve pas insensé d'améliorer son accessibilité.
:* [Edit] Et on se rapproche du bépow !
:[[Utilisateur:Florian|Florian]] 23 juin 2008 à 22:53 (CEST)
:: Difficile de répondre à cette proposition. On est encore sur un problème d’équilibre : {Z} est plus loin mais permet l’alternance. {X} est plus facile mais complique un peu les digrammes. Je ne sais pas comment trancher. Ce qui serait bien, néanmoins, ce serait de décider vite de savoir si on propose quelque chose concernant ce sujet… Qu’en pensez-vous, les autres ? Est-ce une solution intéressante ? Mérite-t-elle d’être mise au vote ? Et surtout '''quand votons nous ?''' [[Utilisateur:Nemolivier|Nemolivier]] 23 juin 2008 à 22:35 (CEST)
:::Il semblerait que cette proposition d'inversion ait reçu un bon accueil sur la ML. Quoi attendre de mieux ? Je me lance et m'attaque à l'édition de l'article ! [[Utilisateur:Florian|Florian]] 23 juin 2008 à 23:11 (CEST)
::::Je pense qu’il faut inverser X et À. Cela impliquera d’autres problèmes avec X mais c’est certainement la meilleure solution. Je trouve personnelement le H bien mieux placé qu’avant et n’ait pas rencontré de problème spécifique sur les digrammes CH. Par contre j’ai relevé le même problème que certains sur les mots en « aux », point qui avait été mis en avant lors des précédents votes (oui les statistiques sont trompeuses, il faudrait plus de testeurs pour ce genre d’inversions). On n’a pas besoin du À sous le majeur, du X non plus à vrai dire mais le fait d’échanger Z/X ne ferait qu’empirer la problématique des lettres « hors zone dactylographique » chère à Kazé et est donc à éviter à tout prix. [[Utilisateur:A2|A2]] 23 juin 2008 à 23:33 (CEST)
::::: Je plussoie A2 : le H à droite me convient très bien, mais quoiqu'en disent les stats, je ne vois pas l'intérêt du X en [W] plutôt qu'en [C].
::::: L'inversion X/Z j'y ai pensé aussi (essentiellement pour Emacs d'ailleurs), je l'ai même postée sur le wiki avant de supprimer le post une heure plus tard. Effectivement ça s'enchaîne pas mal, mais ça surcharge un peu plus l'auriculaire droit, qui n'en a vraiment pas besoin.
::::: Et pour ce qui est du Bépow (même si c'est une considération secondaire), c'est neutre. L'inversion X/Z ne nous rapprocherait pas du Bépow, puisqu'il resterait toujours deux lettres à échanger avec À et È. L'inversion X/À placerait le Z en [W] en Bépow, ce qui en reviendrait au même pour les digrammes EZ.
::::: Bref, je vois beaucoup plus d'avantages à inverser X/À que X/Z. [[Utilisateur:Kaze|Kazé]] 24 juin 2008 à 10:08 (CEST)
Tiens, pas bête du tout cette inversion J/H, personne n'en a parlé ni sur la ML, ni sur cette page. Couplée à l'inversion X/À, cela semble donner une solution tout à fait consensuelle. Je vais tester ça aujourd'hui pour en avoir le cœur net.
Au passage, félicitations à ceux qui ont participé à la synthétisation de la discussion sur l'article, c'est très bien fait :). [[Utilisateur:Florian|Florian]] 25 juin 2008 à 14:57 (CEST)
====Quantifier la gêne====
Une question qui me taraude: si, comme on le pense, le consensus pour figer existe, alors il n'est certainement pas question d'échanger des lettres sans un cas de force majeure, est-ce que le problème du H et du X justifie de ne pas figer ? D'un autre côté, si l'on doit le faire, autant le faire le mieux possible. Comme nous n'avons pas encore eu le temps de beaucoup tester cette inversion, le degré de gêne occasionné n'est pas bien quantifiable. Je vous propose donc un petit sondage pifométrique destiné à éclaircir la situation.
 
Indiquez svp, pour le placement de X et de H, le degré de gêne ressenti, sur une échelle de 0 à 20, avec comme référence 0 = clavier parfait, 10 = comme dans la 0.6.5.1, 20 = comme de taper un W avec l'auriculaire gauche. (Détaillez par digramme au besoin)
[[Utilisateur:Galbolle|Galbolle]] 24 juin 2008 à 11:29 (CEST)
 
:Galbolle: X = 10, H = 7, tests sporadiques sur 15 jours de la 0.6.6
:Kazé : X = 13, H = 4 (<=> je préfère la 0.6.6 à la 0.6.5.1), XXX jours en 0.6.6
:Gaëtan : X = 12, H = 19,5, 27 jours à 100% en 0.6.6
:NémOliv’ : X = 09, H = 2 (CH = 5), XXX jours en 0.6.6
:Seginus : X = 15, H = 5, XXX jours en 0.6.6
:Flocon : X = 5, H = 0, 1 semaine en 0.6.6 + 3 semaines en 0.6.5 avec triangulaire HXÀ
:Asr : X = 8, H = 5, 20 jours en 0.6.6
:A2 : X = 5, H = 0, 3-4 semaines en 0.6.6
:Florian : X = 15, H = 12 (CH = 18) — 1 semaine en 0.6.6
:tiot : X = 12, H = 6 — 6 semaines avec inversion XÀH.
:Skippy : X = 6, H = 1 — XXX jours en 0.6.6.
200000, c'est encore loin de l'infini, non ? Galbolle, tu avais raison, ton échelle est pas top :-)
J'ai mis 1.5 pour le X, par ce que je n'ai considéré que la frappe de texte. Si on compte aussi les raccourcis clavier, je mets beaucoup plus. [[Utilisateur:Glehmann|Gaëtan]] 24 juin 2008 à 18:40 (CEST)
:J'ai changé l'échelle et vos votes arbitrairement, vérifiez [[Utilisateur:Galbolle|Galbolle]] 24 juin 2008 à 21:47 (CEST)
::Je dois être la seule, mais je suis ravie par la disposition actuelle ! J'utilise beaucoup PHI, CH coule tout seul, AUX s'enchaîne bien puisque je m'appuie sur l'annulaire pour aider l'auriculaire à bouger, et EUX est fluide. [[Utilisateur:Flocondeneige|Flocondeneige]] 26 juin 2008 à 10:47 (CEST)
:::Avec l’inversion (la triangulaire) j’ai remarqué une sorte de « blocage », peut-être dû à un mauvais apprentissage sur cette zone : j’hésite parfois entre annulaire et auriculaire pour taper un x (hors digrammes dans la zone). Je pense que la gêne vient plus de la forme du clavier (droit) que d’un pb de positionnement vu que je n’ai pas ce problème main droite. Vivement le TMx2030 :p [[Utilisateur:A2|A2]] 26 juin 2008 à 17:50 (CEST)
 
=== Inversion ?/; ===
<center>
╠═══════╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───╚╗    ║
║        ║ A  │ U  │ I  │ E  │ {{B|;}}  ║ C  │ T  │ S  │ R  │ N  │ M  │ Ç  ║    ║
║  CAPS  ║  æ│  ù│  ¨│  €│ , ’║    │    │    │    │    │    │    ║    ║
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴──┬─┴──╔═╧════╩════╣
║  ^  ║  Ê │ X  │ Y  │ À  │ :  │ K  ║ {{B|?}} {{B|¿}}│ Q  │ G  │ H  │ F  ║    ^    ║
║  |  ║  /│  \│  {│  }│ . …│  ~║ ' ‘│    │    │    │    ║    |    ║
╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦═════╣
</center>
[[Fr%C3%A9quence_des_caract%C3%A8res#Corpus_de_Thomas_Temp.C3.A9|Selon le corpus de Thomas Tempé]], les deux caractères « ? » et « ; » ont sensiblement la même fréquence en français, il n'y a donc pas de raison ergonomique de mettre « ? » en Maj+{,} ; ce placement est probablement un héritage de l'Azerty. Je pense que cette inversion permettrait d'avoir une meilleure cohérence pour la ponctuation :
* le point-virgule au-dessus de la virgule, les deux points au-dessus du point ;
* ./:/,/; sous la main gauche, !/? sous la main droite ; les ponctuations courantes restent avec les voyelles sous la main gauche, comme sur le Dvorak ;
Notez que le placement de «;/:» en Maj + «,/.» est une amélioration adoptée par tous les layouts QWERTY/QWERTZ européens sur leur ancêtre américain. [[Utilisateur:Kaze|Kaze]] 12 mai 2008 à 11:58 (UTC)
 
PS : cette inversion améliorerait la disposition pour deux catégories de personnes :
* les nouveaux utilisateurs fr-dvorak-bepo : un peu de cohérence ne nuit pas à l'apprentissage…
* les utilisateurs Vim : la virgule et le point-virgule étant utilisées pour un même mode de déplacement, il faut au minimum les avoir sous la même main, et idéalement sous le même doigt. Vu qu'on a doublé l'accent grave Ascii pour les utilisateurs Emacs, ça serait bien de penser aussi aux Vimistes.
Ce n'est pas une modification fondamentale, mais puisqu'il s'agit de figer la disposition à court terme, il serait vraiment dommage de conserver des incohérences qui n'apportent rien en ergonomie. [[Utilisateur:Kaze|Kaze]] 3 juin 2008 à 23:56 (CEST)


== Ajout de touches mortes pour l'alphabet phonétique international ==
=== Déplacer % en shift ===
On pourrait peut-être imaginer un système avec une seule touche phonétique, qui pourrait être suivie de plusieurs caractères. Je propose de calquer le comportement de cette touche le plus possible sur le X-SAMPA (un système d'« ASCIIification » de l'API assez répandu). Plus de détails ultérieurement. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 6 mai 2008 à 14:34 (UTC)


== Ajout du s long « ſ » en Shift + Alt Gr + {S} ==
Placer le % au même niveau que les chiffres car il est utilisé essentiellement après des chiffres (peut-être a-t-il une autre utilité en programmation ?). De plus on laisse une touche vide où on peut mettre :
Permettrait de supprimer le ß qui est une ligature du ſ et du s.
* La touche Compose
[[Utilisateur:Asr|Asr]] 30 avril 2008 à 14:12 (UTC)
* Les caractères de programmation tels que ~^`
:Pourquoi supprimer « ß » ? Laissons-le où il est tant qu'on n'a pas intégré de touche Compose. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 30 avril 2008 à 14:53 (UTC)
* Le {{R|~}} et ~
:: Le [http://fr.wikipedia.org/wiki/Eszett Eszett] n'est pas qu'une ligature « ſs » ou « ſz », et contrairement au S long (qui a quasiment disparu) c'est une lettre *très* courante en allemand. Puisqu'elle n'a pas de forme majuscule, je trouverais logique de mettre le s long en Shift+AltGr+{S}, mais il ne faut surtout pas supprimer « ß ». [[Utilisateur:Kaze|Kaze]] 1 mai 2008 à 20:27 (UTC)
:::Je suis tout à fait d'accord : gardons le « ß ». Toutefois, il me semble qu'il n'est plus utilisé officiellement en Suisse alémanique. Il ne figure même pas sur les claviers suisses allemands. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 6 mai 2008 à 14:26 (UTC)
::::Le Œ et Æ ne figure pas sur les claviers Français ce n'est pas pour cela qu'ils ne sont pas utilisés. Donc le critère de figuration sur un clavier n'est pas un bon critère.[[Utilisateur:Tiot|Tiot]] 14 mai 2008 à 09:16 (UTC)
:::::http://fr.wikipedia.org/wiki/%C3%9F#Orthographe_allemande
:::::« La Suisse et le Liechtenstein avaient supprimé complètement l'usage du ß dès la première moitié du XXe siècle et utilisent ss dans tous les cas. »
:::::C'est un bon critère, ça ?
:::::[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 16 mai 2008 à 22:31 (UTC)


== Ajout du « ™ » sur AltGr+Maj.+ R ==
┬────┬────┬────╔═════════╗
Si j’en crois wikipédia, le symbole « ™ » serait plus recommandé dans certain cas que le « ® » pour indiquer qu’une marque est [http://fr.wikipedia.org/wiki/Marque_déposée#Sigle_pour_montrer_qu.27une_marque_est_enregistr.C3.A9e enregistrée].
│ 0  │ {{B|% ‰}}│    ║        ║
C’est un tout petit ajout… sur le xkb il suffit de mettre « trademark » à l’endroit opportun.
│ * ×│ = ¬│ {{R|?}}  ║ <--    ║
┴──┬─┴──┬─┴──┬─╚══╦══════╣


Le code utf que j’avais trouvé n’est pas le bon… si quelqu’un le connaît, nous irons l’ajouter sur la page wikipédia. [[Utilisateur:Nemolivier|Nemolivier]] 14 mai 2008 à 07:38 (UTC)
[[Utilisateur:Tiot|Tiot]] 7 juin 2008 à 20:24 (CEST)


: Sous Linux / xkb ce caractère est nommé « trademark », ça me fait un U+2122 dans ma console. [[Utilisateur:Kaze|Kaze]] 14 mai 2008 à 20:44 (UTC)
: Oui, il est utilisé en programmation, notamment en ASP et JSP où c'est un caractère systématique (<% … %>), nettement moins dans les langages « classiques ». [[Utilisateur:Kaze|Kaze]] 16 mai 2008 à 07:55 (UTC)


== Descendre les < > à un emplacement plus accessible ==
: Il est assez utilisé dans les langages classiques (C, C++ et Ocaml au moins) pour faire des printf. Il est alors généralement précédé d'un espace et suivi d'une lettre (parfois un chiffre). [[Utilisateur:Galbolle|Galbolle]] 4 juin 2008 à 13:47 (CEST)
:: Je serais pas contre le mettre en Alt-Gr [[Utilisateur:Pyerre|Pyerre]] 4 juin 2008 à 16:08 (CEST)
: Il est aussi utilisé en Perl pour préfixer les tableaux associatifs, et dans la plupart des langages pour l'opération modulo. [[Utilisateur:Laurent|Laurent]] 18 juin 2008 à 07:25 (CEST)


== Chiffres en accès direct ==
: Concernant la proposition de remplacement, je mettrais bien ~ en direct, je pense qu'il est aussi fréquent que ^ en programmation, mais il est un peu moins accessible que ^ sans utiliser cette touche (dans l'hypothèse où ~ en altgr-y devient mort). Ainsi on compenserait cette différence. ^ passerait en AltGr, vu que ` est intermédiaire pour l'accessibilité entre ^ et ~, il est logique qu'il soit en Shift. [[Utilisateur:Galbolle|Galbolle]] 7 juin 2008 à 16:24 (CEST)
:: Mettre ~ ''mort'' en direct, ça ''peut'' être intéressant : ça faciliterait les « ~/ » et les « ãẽĩõũỹ », ça libèrerait AltGr+{K}, et on ''pourrait'' en profiter pour mettre mettre ¿¡ en AltGr+[=] : ça serait moins cohérent que sur {!} et {?} mais plus accessible. Dans tous les cas, je pense qu'il vaut mieux avoir les accents morts en direct et les caractères ascii en {Maj}. [[Utilisateur:Kaze|Kazé]] 9 juin 2008 à 18:38 (CEST)
┬────┬────┬────┬────╔═════════╗
│ 9  │ 0  │ {{B|% ‰}}│ {{B|~}} {{B|¡}}║        ║
│ / ÷│ * ×│ = ¬│ {{R|~}} {{B|¿}}║ <--    ║
┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣


Je fais partie de ceux qui souhaitent avoir les chiffres en accès direct, pour deux raisons qui ont certainement déjà été débattues maintes fois :
:: Mise à jour : notez le conditionnel SVP ! À titre personnel, ^`~ me conviennent très bien là où ils sont (sur [YTB]), si ce n'est que je préfèrerais avoir une certaine cohérence pour `~ (accent mort en direct, accent ascii en Shift). Je trouve les ^` ascii en [)=] inutiles et source de confusion. Je pense que l'idée du % en Maj se défend (ne serait-ce que pour insérer facilement un espace insécable entre un nombre et %), mais la pire solution pour moi serait d'avoir une touche ^`~ en [=] : à ce compte-là je ''préfèrerais'' une touche ~¡¿, en remplacement (et non en plus) des positions actuelles de ~¡¿. [[Utilisateur:Kaze|Kazé]] 10 juin 2008 à 00:28 (CEST)
* on n'utilise que très rarement plusieurs caractères tels que "<>()_+-/* à la suite, contrairement aux chiffres ;
:: Mise à jour bis : après avoir pesé les arguments de Galbolle (point suivant), je pense que la façon la plus simple de mettre % en Shift ''serait'' une inversion %/^. Mettre ~ en AltGr+[=] n'aurait aucun intérêt par rapport à AltGr+[B], donc la seule alternative réaliste ''serait'' de le mettre en direct et de passer ^ en AltGr. Ceci dit, je ne suis pas sûr que le ~ ascii en direct sur [=] faciliterait tant que ça les « ~/ ».  [[Utilisateur:Kaze|Kaze]] 12 juin 2008 à 22:50 (CEST)
* dans le cadre d'une utilisation professionnelle, et contrairement à une discussion type IRC, on a très souvent recours aux nombres pour exprimer des quantités, des montants ou des dates - et dans ce cadre-là, l'utilisation du ShiftLock est malpratique.
┬────┬────┬────┬────╔═════════╗      ┬────┬────┬────┬────╔═════════╗
Plutôt que de relancer le débat à ce sujet, pourrait-on avoir une variante du Bépo avec les chiffres en accès direct (« Bépo-num ») pour les irréductibles ? [[Utilisateur:Kaze|Kaze]] 1 mai 2008 à 20:33 (UTC)
│ 9  │ 0  │ {{B|% ‰}}│ {{B|`}}  ║        ║  ou │ 9  │ 0  │ {{B|% ‰}}│ {{B|`}}  ║        ║
:Pourquoi pas ? On pourrait même en profiter pour mettre les guillemets "«" et "»" en majuscule. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 6 mai 2008 à 14:29 (UTC)
│ / ÷│ * ×│ = ¬│ {{B|^}}  ║ <--    ║      │ / ÷│ * ×│ = ¬│ {{B|~ ^}}║ <--     ║
┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣      ┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
: % en direct me paraît beaucoup plus logique que ~ en direct…
: Pour ce qui est des chiffres, % reste en direct avec un CAPS : 18,4% s'écrit TRÈS simplement avec un appui pralable sur CAPS LOCK.  
: Dans la foulée, ça répond aussi aux chiffres en direct. Pas pour la v1, ce n'est pas bloquant (grâce au CAPS). [[Utilisateur:Asr|Asr]] 18 juin 2008 à 15:17 (CEST)
:: Asr a raison : à partir du moment où on admet qu'il faut recourir au CAPS pour les nombres, mettre le % en Shift n'a aucun intérêt. Et ceux qui bricolent le xkb pour avoir les chiffres en direct (ex : moi-même) n'ont aucun intérêt à avoir le % en Shift non plus. Autrement dit, dans les deux cas, le % est mieux en accès direct, CQFD. [[Utilisateur:Kaze|Kaze]] 24 juin 2008 à 14:22 (CEST)


: Pour ma part, ce n'est pas tant l'accès direct aux chiffres qui m'intéresse que l'accès "groupé" aux chiffres et opérateurs ()+-/*= et "." (utilisation d'un tableur). S'il faut taper une fois MAJ pour accèder à ce mode, ce n'est pas un problème et cela peut laisser l'accès direct aux signes typographiques et cela peut éviter de casser tout le travail déjà effectué Herisson 16 mai 2008 à 06:02 (UTC)
=== ` et ^ ===
Ces deux caractères sont spécifique de certaines utilisation. On les trouve pourtant à plusieurs endroits sur la carte. Peut-être y-a-t-il une optimisation à réaliser ?
[[Utilisateur:Nemolivier|Nemolivier]] 7 juin 2008 à 19:31 (CEST)
: Si on se dirige vers une touche compose sur le clavier (par exemple en %), on peut en faire une touche avec ` ^ et ~ pour les linuxiens qui ont déjà un compose ailleurs. Ce sont a priori eux qui sont concernés par les « utilisations spécifiques » où il est nécessaire que ces caractères soient accessible sans touche morte. [[Utilisateur:Galbolle|Galbolle]] 8 juin 2008 à 17:56 (CEST)


Une alternative qui me parait intéressante serait d'utiliser la touche VerrMaj (CapsLock) '''uniquement''' pour changer le comportement des chiffres : les chiffres seraient en acccès direct si VerrMaj est activé. Avantages :
: Je ne vois ^ (ascii) qu'une fois sur la disposition. ` (ascii) est effectivement présent deux fois. ~ serait présent deux fois si on le met sur %.  Il y a deux logiques pour placer ^ ~ et ` ascii: en shift au-dessus de la version morte, ou ensemble en %. Si on privilégie cette solution, on peut libérer les emplacements en altgr + shift + ` et altgr + shift + k. À mon sens, on peut mettre ces touches loin car d'une part on a les versions mortes pas mal placées, et d'autre part, quand on a besoin des versions ascii, ça n'est pas dans le flot de la frappe. [[Utilisateur:Galbolle|Galbolle]] 8 juin 2008 à 18:08 (CEST)
* une seule disposition pour tout le monde ;
::Je crois que la seule raison qui ''nécessite'' d'avoir  `/^/~ ascii ailleurs qu'en AltGr, c'est les raccourcis Ctrl+{`/^/~} d'Emacs. Or, des touches comme {ÀÉÊÈÇ} sont très accessibles (bien plus que Maj+{%/=}) et inutilisées sous Emacs. Il suffirait [[Emacs|qu'un Emacsien fasse un fichier de configuration]] du type :
* l'activation accidentelle du VerrMaj (très courante sur les claviers classiques) aurait des conséquences limitées ;
Ctrl+À  <=>  Ctrl+~  " mieux que Ctrl+Shift+AltGr+{~}
* on peut demander à figurer sur le site [http://capsoff.org CapsOff.org] ;-)
Ctrl+È  <=>  Ctrl+`  " mieux que Ctrl+Shift+{%}
Ça se fait sans problème sous Linux (voir [[Utilisateur:Kaze#Fichier_xkb_.28version_0.6.6_modifi.C3.A9e.29|ce fichier xkb]]), Glehmann et A2 me disent que c'est faisable sous MacOS™ X et Windows™ respectivement.
Ctrl+É  <=>  Ctrl+^  " mieux que Ctrl+Shift+{=}
[[Utilisateur:Kaze|Kaze]] 12 mai 2008 à 11:52 (UTC)
::Sorti d'Emacs je trouve que le gain en confort est faible voire nul : je préfère faire {^}{Espace} plutôt que Maj+{=}. On ferait mieux de regrouper les accents {`^~} (morts et ascii) sur trois touches, quitte à réserver [=] pour l'accent grave ou le tilde. [[Utilisateur:Kaze|Kaze]] 9 juin 2008 à 18:05 (CEST)
::: D'accord avec toi sur l'utilisation dans emacs, sous réserve que l'on puisse faire la manip que tu préconises (je vais vérifier, là comme ça je ne suis pas sûr de voir… je suis même assez pessimiste sur l'existence d'une solution propre). Ta proposition de trois touches «accent mort - accent ascii - ? - ? » suppose de trouver une touche complète pour `, je n'ai pas trop de candidat. Ça s'intégrerait mieux au bépo-intl qui a déjà un accent grave mort en direct. Mais j'aime bien la touche consacrée à ~, qui est le parent pauvre des trois. Note que ~ est mais aussi celui dont les francophones au moins un peu geek utiliseront plus la version ascii que la version morte.[[Utilisateur:Galbolle|Galbolle]] 9 juin 2008 à 19:22 (CEST)
:::: Je trouve complètement ridicule de mettre ~ en accès direct tandis que % qui n’est nulle part ailleurs se retrouve en Maj. J’utilise le ~ dans vim pour changer la casse, je le fait avec AltGr+Maj sans difficulté majeur et je ne vois pas l’intérêt d’aller le mettre là haut. N’avons nous rien d’autre à mettre sur une touche aussi éloignée ? [[Utilisateur:Nemolivier|Nemolivier]] 9 juin 2008 à 23:02 (CEST)
:: Je viens de me rendre compte que Galbolle a raison sur toute la ligne : la logique de « placer ^/~/` ascii en shift au-dessus de la version morte » ne tient pas, ne serait-ce que pour le circonflexe. Par ailleurs, il semble bien qu'on ne peut pas configurer de Ctrl+{lettre accentuée} dans Emacs ni dans Vim (ou alors, pas facilement), et j'imagine que ça sera le cas dans d'autres applications : mon argument précédent ne tient pas.
:: Du coup, puisqu'il faut au moins un ^ ascii quelque part, l'idée de « placer  ^/~/` ascii ensemble en {%} » me paraitrait judicieuse pour faire quelque chose comme ça :
::* % en Shift+{=} — cf. la proposition précédante
::* ^/~/` ascii sur une touche « prog » en [=] — resterait à déterminer l'accès : qui va en direct, en AltGr, en Shift ?
::* `/~ morts en AltGr+{È/B} :
::** soit on supprime les `/~ ascii de ces touches (=> deux emplacements libres pour des diacritiques morts ?)
::** soit on les laisse en doublon sur Shift+AltGr (i.e. on inverse ~ mort/ascii) — les doublons saymal ou pas ?
::[[Utilisateur:Kaze|Kaze]] 12 juin 2008 à 20:08 (CEST)


== Touche Alt Gr symétrique ==
=== AltGr symétrique ===
Pour l'accessibilité des AltGr + [pavé principal droit] je pense qu'on a quatre options :
Récupérer sur PC un accès aussi bon que sur Mac aux symboles en AltGr à droite.<br>
# 100% symétrique : Alt devient AltGr, avec les problèmes que ça suppose : ''quid'' du Alt, implémentation sous Windows™, etc…
Cette amélioration pourra aussi permettre un meileur placement de certains symboles courants.
# asymétrique, en utilisant une autre touche comme AltGr (mêmes objections que précédemment)
┣━━━━━━╋━━━━┷━┳━━┷━━━━╅────┴────┴────┸────┴──┲━┷━━━━┷┳━━━┷━━┳━┻━━━━┳━━━━━━┫
# asymétrique, en utilisant {Ê} comme AltGr mort (voire aussi Compose en Shift+{Ê} ?)
┃      ┃      ┃      ┃ E. ins.  E. ins fine ┃      ┃      ┃ WinG ┃      ┃
# asymétrique, on ne change rien puisque les quelques caractères spéciaux dans le pavé principal droit sont très rares, du moins en français.
┃ Ctrl ┃ Alt  ┃ AltGr ┃ Espace        _      ┃ AltGr ┃ WinD ┃ Menu ┃ Ctrl ┃
┗━━━━━━┻━━━━━━┻━━━━━━━┹──────────────────────┺━━━━━━━┻━━━━━━┻━━━━━━┻━━━━━━┛


À titre perso je serais pour #3 ou #4 (j'utilise beaucoup Win et Alt), je ne sais pas si ça mérite d'être discuté pour la version 0.6.7. Je me suis permis de regrouper ci-dessous les propositions qui nécessitent un AltGr symétrique. [[Utilisateur:Kaze|Kaze]] 15 mai 2008 à 12:02 (UTC)
: Cette proposition n'est pas compatible avec tous les [[Discuter:Type_de_clavier|types de claviers]] que l'on veut supporter. Si on veut un altgr symétrique il faut déplacer beaucoup d'autres éléments, donc pas envisageable dans le cadre de la v1. [[Utilisateur:Crako|Crako]] 18 juin 2008 à 14:34 (CEST)
:: Apparemment, seul le type 3 manque de la touche Menu. Quels sont les portables qui ont ce type de clavier ? Je demande à voir, je n'en ai encore jamais vu jusqu'à maintenant. [[Utilisateur:Laurent|Laurent]] 19 juin 2008 à 08:17 (CEST)
::: Le Dell latitude D630 ? [[Utilisateur:Asr|Asr]] 26 juin 2008 à 12:42 (CEST)


=== Si l'on accepte un Alt Gr symétrique : ===
::: Ce n’est pas qu’une question de faisabilité… là encore ça entraînerait énormément de changements (y compris les chiffres) et il nous faudrait un an minimum, en accélérant le rythme, pour régler ça. Nous nous heurterions, encore et toujours, aux limites de la v1. Il faudrait tout refaire. Ça à un nom… ça s’appelle une V2 ![[Utilisateur:Nemolivier|Nemolivier]] 19 juin 2008 à 10:43 (CEST)
* supprimer « ñ » et « Ñ » et déplacer le tilde mort en Alt Gr + {N},
* déplacer « ç » en Alt Gr + {C} et « Ç » en Shift + Alt Gr + {C},
* déplacer « w » en Alt Gr + {V} et « W » en Shift + Alt Gr + {V}.
[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 15 mai 2008 à 12:16 (UTC)


: Le « w » en Alt Gr + {V} est handicapant pour ceux pratiquant l'anglais assidument et par ailleurs il y a  la proposition d'améliorer l'accès au W … points contradictoires. Herisson 16 mai 2008 à 19:19 (UTC)
::: J'utilise le Bépo notamment sur un portable IBM X31, qui n'a ni touches windows ni menu... si je passe l'Alt de gauche en AltGr, je n'ai plus de touches Alt :-( [[Utilisateur:fredb|fredb]] 25 juin 2008 à 07:44 (CEST)
::::Moi j'utilise un portable qui dispose de toutes les touches d'un clavier étendu, sauf le Win de droite. Et j'ai besoin d'au moins une touche Win : j'utilise exclusivement Windows sur mon portable et les raccourcis avec la touche Win me sont fort utiles.
::::[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 25 juin 2008 à 14:33 (CEST)
::: Même problème pour moi sur l'eeePC : avec l'AltGr symétrique, je perds le Alt normal. [[Utilisateur:Flocondeneige|Flocondeneige]] 26 juin 2008 à 10:26 (CEST)
Sinon, n’oublions pas qu’a peu près tous les claviers existant disposent une touche dangereusement trop accessible pour l’usage qui en est fait : le caps lock ! Seule la réaffectation en modificateur rend cette touche à la fois inoffensive et utile. Existe-t-il des claviers ou ce genre de réglage pose problème ? (théoriquement, les modificateurs ne sont pas câblés comme des touches normales, mais pour l’instant, je n’ai constaté de problème nulle part)--[[Utilisateur:Aldoo|Aldoo]] 26 juin 2008 à 12:15 (CEST)
:Le caps lock m'est très utile, pour les chiffres bien sûr ! [[Utilisateur:Asr|Asr]] 26 juin 2008 à 12:42 (CEST)


== Ajouter un jeu de flèches ==
== Propositions sans impact sur la carte simplifiée ==


== Inversion ?/; ==
=== Ajout de la virgule souscrite morte en AltGr+Maj.+{{T|Ç}} ===
[[Fr%C3%A9quence_des_caract%C3%A8res#Corpus_de_Thomas_Temp.C3.A9|Selon le corpus de Thomas Tempé]], les deux caractères « ? » et « ; » ont sensiblement la même fréquence en français, il n'y a donc pas de raison ergonomique de mettre « ? » en Maj+{,} ; ce placement est probablement un héritage de l'Azerty. Je pense que cette inversion permettrait d'avoir une meilleure cohérence pour la ponctuation :
* le point-virgule au-dessus de la virgule, les deux points au-dessus du point ;
* ./:/,/; sous la main gauche, !/? sous la main droite ; les ponctuations courantes restent avec les voyelles sous la main gauche, comme sur le Dvorak ;
Notez que le placement de «;/:» en Maj + «,/.» est une amélioration adoptée par tous les layouts QWERTY/QWERTZ européens sur leur ancêtre américain. [[Utilisateur:Kaze|Kaze]] 12 mai 2008 à 11:58 (UTC)


Contre-proposition : utiliser la [[Touches_mortes#Ogonek|touche morte ogonek]] pour la virgule souscrite. Ces deux diacritiques (virgule souscrite / ogonek) me semblent suffisamment proches pour ne pas nécessiter une touche morte supplémentaire. De plus, l'ogonek ne s'applique qu'aux voyelles, tandis que la virgule souscrite ne concerne que les consonnes :
* Șș et Țț en Roumain (à ne pas confondre avec Şş et Ţţ qui sont des cédilles)
* Ģģ Ķķ Ļļ Ņņ en Letton (fait habituellement avec la cédille morte, mais qu'on pourrait faire ''aussi'' avec l'ogonek)
Avantage : pas de modification de la disposition, une mise à jour du pilote suffirait. [[Utilisateur:Kaze|Kaze]] 29 avril 2008 à 11:16 (UTC)
:C'est effectivement possible, mais ça reste deux diacritiques différents. Et comme la position Shift + Alt Gr + {Ç} est libre, et que la virgule souscrite se rapproche plus de la cédille que de l'ogonek, il me semble adéquat de la placer là. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 29 avril 2008 à 12:45 (UTC)
:Quant aux Ģģ Ķķ Ļļ Ņņ du letton, on peut éventuellement les dupliquer sur la touche morte virgule souscrite en les laissant sur la cédille. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 29 avril 2008 à 12:47 (UTC)


=== Complément : regrouper les guillemets simples ===
=== Ajout de touches mortes pour l'alphabet phonétique international ===
L'inversion ?/; permettrait également :
On pourrait peut-être imaginer un système avec une seule touche phonétique, qui pourrait être suivie de plusieurs caractères. Je propose de calquer le comportement de cette touche le plus possible sur le X-SAMPA (un système d'« ASCIIification » de l'API assez répandu). Plus de détails ultérieurement. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 6 mai 2008 à 14:34 (UTC)
* de regrouper la paire de guillemets simples « ‘’ » en Maj+AltGr+{Y/À}
: J'ai bien peur que ça ne soit pas si simple, loin de là, au vu du nombre de caractères de l'API. Je ne suis même pas sûr qu'une touche Compose et un fichier ~/.XCompose associé suffisent. Sous Linux, la saisie de caractères IPA se fait via un assistant de saisie type UIM ou Scim. [[Utilisateur:Kaze|Kaze]] 3 juin 2008 à 23:20 (CEST)
* de placer « ¢ » en AltGr+{'} — c'est proche de {C} et de toutes façons, son accessibilité est moisie…
* de dupliquer « Ç » en AltGr+{,} – ce qui serait appréciable sur les claviers pc104 et certains claviers pc105
╠═══════╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬
║        ║ A Æ│ U Ù│ I ˙│ E ¤│ {{B|;}}  ║ C  │ T Þ│
║  CAPS  ║ a æ│ u ù│ i ¨│ e €│ , {{B|ç}}║ c ©│ t þ│
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴─══─┴
║  ^  ║ Ê  │ X  │ Y {{B|‘}}│ À {{B|’}}│ : ·│ K ˜║ {{B|? ¿}}│
║  |  ║ ê /│ x \│ y {│ à }│ . …│ k ~║ ' {{B|¢}}│
╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧══
[[Utilisateur:Kaze|Kazé]] 14 mai 2008 à 19:59 (UTC)


:Pour la cohérence c'est pas mal lorsque j'ai appris le bépo j'avais du mal à trouver le ; et maintenant le ? et ! sont tapés avec le même doigt ce que rajoute encore plus de cohérence. Par contre j'inverserai le ¿ et le ¢ car je n'ai pas l'impression que le ¿ est plus utilisé et le ¢ est accessible via ¤ + c (quoique il faudrait peut être inverser le ¤ et €).[[Utilisateur:Tiot|Tiot]] 15 mai 2008 à 08:30 (UTC)
=== Ajout du s long « ſ » en Shift + Alt Gr + {C} ===
::Le <b>gros</b> problème, c’est que « » est aussi l’apostrophe typographique. Faire passer l’apostrophe de Alt Gr + {,} à Shift + Alt Gr + {À} ne me semble <b>pas du tout</b> une bonne idée. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 16 mai 2008 à 22:46 (UTC)
Permettrait de supprimer le ß qui est une ligature du ſ et du s.
::: Ah, je n'avais pas conscience de l'usage fait par certains utilisateurs du [[Apostrophe|rsqm]] — ça a alimenté le canal IRC pendant toute la journée ! Voilà qui explique la position un peu incohérente de ce caractère. Je trouve la position de « » pourrie pour l'utiliser comme apostrophe (alors que je l'aurais trouvée correcte pour le Ç), mais si elle convient aux utilisateurs du rsqm, autant ne pas la remettre en cause. [[Utilisateur:Kaze|Kaze]] 17 mai 2008 à 18:27 (UTC)
[[Utilisateur:Asr|Asr]] 30 avril 2008 à 14:12 (UTC)
:Pourquoi supprimer « ß » ? Laissons-le où il est tant qu'on n'a pas intégré de touche Compose. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 30 avril 2008 à 14:53 (UTC)
:: Le [http://fr.wikipedia.org/wiki/Eszett Eszett] n'est pas qu'une ligature « ſs » ou « ſz », et contrairement au S long (qui a quasiment disparu) c'est une lettre *très* courante en allemand. Puisqu'elle n'a pas de forme majuscule, je trouverais logique de mettre le s long en Shift+AltGr+{S}, mais il ne faut surtout pas supprimer « ß ». [[Utilisateur:Kaze|Kaze]] 1 mai 2008 à 20:27 (UTC)
:::Je suis tout à fait d'accord : gardons le « ß ». Toutefois, il me semble qu'il n'est plus utilisé officiellement en Suisse alémanique. Il ne figure même pas sur les claviers suisses allemands. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 6 mai 2008 à 14:26 (UTC)
::::Le Œ et Æ ne figure pas sur les claviers Français ce n'est pas pour cela qu'ils ne sont pas utilisés. Donc le critère de figuration sur un clavier n'est pas un bon critère.[[Utilisateur:Tiot|Tiot]] 14 mai 2008 à 09:16 (UTC)
:::::http://fr.wikipedia.org/wiki/%C3%9F#Orthographe_allemande
:::::« La Suisse et le Liechtenstein avaient supprimé complètement l'usage du ß dès la première moitié du XXe siècle et utilisent ss dans tous les cas. »
:::::C'est un bon critère, ça ?
:::::[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 16 mai 2008 à 22:31 (UTC)
Il existe un nouveau caractère pour la capitale de ß : « Uppercasing U+00DF ( ß ) LATIN SMALL LETTER SHARP S to the new U+1E9E LATIN CAPITAL LETTER SHARP S » d'après [http://www.unicode.org/versions/Unicode5.1.0/ unicode 5.1]. Il est probable que les polices ne le gèrent pas avant un bon moment. [[Utilisateur:A2|A2]] 3 juin 2008 à 19:14 (CEST)
:Initialement, j'avais proposé Shift + Alt Gr + {S} pour cette lettre, mais la mettre en Shift + Alt Gr + {C} permettrait de libérer Shift + Alt Gr + {S} pour le « ß » majuscule (voir ci-dessous). [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 4 juin 2008 à 11:37 (CEST)
:<update>Code2000 l'a déjà intégré. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 25 juin 2008 à 14:37 (CEST)</update>


== Tirets cadratin et demi-cadratin sur {1} ==
=== Ajout du ß majuscule ===
Une autre modification pour la cohérence de la dispo :
Ajouter ẞ (U+1E9E, LATIN CAPITAL LETTER SHARP S) en Shift + Alt Gr + {S} et chercher une autre place au s long mentionné ci-dessus.
┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔═════════╗
:Le ß capital est une curiosité Allemande et elle est présente dans (presque ?) aucune police de caractère. (voir [http://en.wikipedia.org/wiki/Capital_%C3%9F Capital ß] et [http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2888.pdf Proposition à unicode]). Quel intérêt a un clavier Francophone de pouvoir taper un caractère Allemand tout nouveau (avril 2008) qui ne s'affiche pas ?[[Utilisateur:Tiot|Tiot]] 4 juin 2008 à 09:04 (CEST)
│ # ¶│ 1 {{B|–}}│ 2 ≤│ 3 ≥│ 4 “│ 5 ”║ 6  │ 7 °│ 8 ′│ 9 ″│ 0  │ ^  │ `  ║        ║
::Il y a quelques années qu'on parle de cette majuscule en Allemagne, Unicode lui a alloué (définitivement) un point de code, et il ne reste plus qu'à l'ajouter à quelques polices de caractères libres pour pouvoir l'utiliser, ce qui sera peut-être fait avant la commercialisation des premiers skins bépo par TypeMatrix.
│ $ §│ " —│ « <│ » >│ ( [) ]║ @  │ + ±│ - {{B|¬}}│ / ÷│ * ×│ = {{B|≠}}│ % ‰║ <--    ║
::Et puis, ne serait-ce pas dommage de déroger au principe « majuscule en Shift + minuscule » pour une seule lettre pour cause de rareté récente ? [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 4 juin 2008 à 11:52 (CEST)
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
:::La majuscule du ß n'existe pas c'est un ß capitale ([http://fr.wikipedia.org/wiki/Majuscule majuscule]) la différence est subtile mais existe. Pour les polices à première vue il y en a [http://de.wikipedia.org/wiki/Gro%C3%9Fes_%C3%9F#Aktuelle_Schriften police avec ß capitale] dont le Linux Libertine. Le ß capitale n'est utile que pour les Allemands qui écrivent en capitale et veulent une typographie très soignée. Je préfère largement avoir un S long à une place logique qu'un caractère Allemand inutilisé.[[Utilisateur:Tiot|Tiot]] 4 juin 2008 à 14:30 (CEST)


* le demi-cadratin passe en Shift+AltGr+1
=== Ajout du « ™ » sur AltGr+Maj.+ R ===
* le signe ¬ est remplacé par ≠ et passe en AltGr+8
Si j’en crois wikipédia, le symbole « ™ » serait plus recommandé dans certain cas que le « ® » pour indiquer qu’une marque est [http://fr.wikipedia.org/wiki/Marque_déposée#Sigle_pour_montrer_qu.27une_marque_est_enregistr.C3.A9e enregistrée].
Peu d'impact, mais meilleure accessibilité du demi-cadratin pour ceux qui l'utilisent, et un peu moins de chances de le confondre avec le tiret. [[Utilisateur:Kaze|Kaze]] 14 mai 2008 à 19:50 (UTC)
C’est un tout petit ajout… sur le xkb il suffit de mettre « trademark » à l’endroit opportun.  
:Le – (tiret demi cadratin) avec le — (tiret cadratin) est une bonne idée. Le ¬ est-il vraiment utilisé ? Il serait plus logique de mettre le − mathématique en alt-gr 6 et de déplacer ¬ je ne sais où.
:Pour en revenir à — et – ils ne seraient pas plus accessible en 6 comme proposé pour la 0.6.6 ? Cela revient à comparer un accès direct en 6 à un accès en alt-gr en 1…
:Je vois plutôt le @ à la place du % et le % en shift ou le @ en alt-gr + 1[[Utilisateur:Tiot|Tiot]] 15 mai 2008 à 08:40 (UTC)
::Le ¬ pourrait être utilisé par les logiciens, mais vu que les autres symboles de logique ne sont pas sur le clavier, je ne vois pas trop ce que ce symbole fait ici. Peut-être a-t-il une autre utilité ? --[[Utilisateur:Aldoo|Aldoo]] 15 mai 2008 à 12:46 (UTC)
::: Le ¬ est le seul signe logique qui soit présent sur d'autres dispositions standard, comme le Qwerty international et le Qwerty espagnol ; de là à savoir pourquoi… Comme il faut remplir cette case pour laisser la minute (′) en Shift+AltGr (cohérence avec la seconde), ça me parait le signe le plus approprié pour aller en AltGr+{-}.
::: Je n'avais jamais entendu parler du − mathématique avant. [[Utilisateur:Kaze|Kaze]] 15 mai 2008 à 21:49 (UTC)
:::: Le - mathématique est en alt-gr + - du pavé numérique, voir [http://fr.wikipedia.org/wiki/Signes_plus_et_moins#En_informatique signe moins (wp)] pour la différence avec le trait d'union. Je ne sais pas si il est beaucoup utilisé mais il va avec les ÷ et ×. [[Utilisateur:Tiot|Tiot]] 16 mai 2008 à 06:50 (UTC)


: Ce point devrait finalement être tranché par le second tour de la version 0.6.6. Le signe « - » mathématique est effectivement plus cohérent que ¬ sur le 8. [[Utilisateur:Kaze|Kaze]] 17 mai 2008 à 18:30 (UTC)
Le code utf que j’avais trouvé n’est pas le bon… si quelqu’un le connaît, nous irons l’ajouter sur la page wikipédia. [[Utilisateur:Nemolivier|Nemolivier]] 14 mai 2008 à 07:38 (UTC)


== Déplacer % en shift ==
: Sous Linux / xkb ce caractère est nommé « trademark », ça me fait un U+2122 dans ma console. [[Utilisateur:Kaze|Kaze]] 14 mai 2008 à 20:44 (UTC)


Placer le % au même niveau que les chiffres car il est utilisé essentiellement après des chiffres (peut-être a-t-il une autre utilité en programmation ?).[[Utilisateur:Tiot|Tiot]] 14 mai 2008 à 09:12 (UTC)
=== Ajout du « ≠ » en AltGr+{=} ===
: Oui, il est utilisé en programmation, notamment en ASP et JSP où c'est un caractère systématique (<% … %>), nettement moins dans les langages « classiques ». [[Utilisateur:Kaze|Kaze]] 16 mai 2008 à 07:55 (UTC)
et déplacement du « ¬ » en AltGr+{6}, la place étant libre depuis la version 0.6.6 :
┬────┬────┬────┬────┬────┬────┬────╔════════╗
║ 6  │ 7  │ 8  │ 9  │ 0  │ ^  │ `  ║        ║
║ @ {{B|¬}}│ + ±│ - −│ / ÷│ * ×│ = {{B|≠}}│ % ║ <--   ║
[[Utilisateur:Kaze|Kaze]] 11 juin 2008 à 11:03 (CEST)
:Alt Gr + {L}, « = » me paraît plus adéquat. [[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 17 juin 2008 à 17:23 (CEST)
:: Il est déjà sur cette combinaison et il n’est pas question de l’en retirer. Je pense que cette proposition est liée au fait que ça s’enchaînerait bien avec les autres signes mathématiques ÷×±. [[Utilisateur:Nemolivier|Nemolivier]] 17 juin 2008 à 17:33 (CEST)
::: Il y a effectivement un souci de cohérence dans cette proposition, mais c'est aussi pour avoir le « ≠ » sous Linux sans toucher au fichier ~/.XCompose que je suggère cette modification. Ça ferait une deuxième façon (plus simple) pour produire un « ≠ », de même qu'on a deux façons de faire un « ù ». [[Utilisateur:Kaze|Kaze]] 19 juin 2008 à 13:25 (CEST)


== Inverser tilde ascii et tilde morte ==
=== Inverser tilde ascii et tilde morte ===


L'idée est d'inverser la tilde morte avec la tilde non morte. Je propose de revoter cette proposition car l'inversion {{R|`}} et ` est passée. Du point de vue de la charge mentale il est logique d'avoir le même comportement entre les touches mortes.
L'idée est d'inverser la tilde morte avec la tilde non morte. Je propose de revoter cette proposition car l'inversion {{R|`}} et ` est passée. Du point de vue de la charge mentale il est logique d'avoir le même comportement entre les touches mortes.


Le ~/ très utilisé sous Linux sera toujours accessible via {{R|~}}+/. Ce qui revient à faire exactement la même chose qu'avant l'inversion. 
Le ~/ très utilisé sous Linux sera toujours accessible via {{R|~}}+/. Ce qui revient à faire exactement la même chose qu'avant l'inversion.  


Proposition à part :
Proposition à part :
On pourrait ajouter le ≃ en {{R|~}} + -, le ≈ en  {{R|~}} + =, ≲ et ≳
On pourrait ajouter le ≃ en {{R|~}} + -, le ≈ en  {{R|~}} + =, ≲ et ≳
: On pourrait aussi ajouter ¿ en {{R|~}} + ?, et ¡ en {{R|~}} + ! [[Utilisateur:Kaze|Kaze]] 3 juin 2008 à 18:47 (CEST)


: D'un autre côté, ~ ascii est un caractère relativement courant dans les «utilisations techniques», notamment pour faire des insécables en latex. Bien plus que ` ascii. Dans la mesure où ce n'est pas un caractère nécessaire pour taper en français, et où on a déjà ñ sur le clavier, est-ce bien judicieux de sacrifier le caractère ascii. Pour apaiser les bretonnants et lusophones, je propose ~ mort en altGr-n, et ~ ascii en altGr-k. ñ garde la même accessibilité, et ~ mort est un peu mieux qu'en K (à vérifier). [[Utilisateur:Galbolle|Galbolle]] 24 juin 2008 à 22:50 (CEST)


== Passer les guillemets anglais « “ » et « ” » en {{t|Altgr}}-{{t|Maj.}}-{{t|«}} et {{t|Altgr}}-{{t|Maj.}}-{{t}} ==
=== Passer les guillemets anglais « “ » et « ” » en AltGr+Maj.+« et AltGr+Maj.+» ===
┌────┬────┬────┬────┬────┬────┬
│ # ¶│ 1 –│ 2 {{B|}}│ 3 {{B|}}│ 4  │ 5  ║
│ $ §│ " —│ « <│ » >│ ( [│ ) ]║
Et supprimer « ≤ » et « ≥ », ou les mettre à la place actuelle des guillemets anglais. [[Utilisateur:Glehmann|Glehmann]] 18 mai 2008 à 16:58 (CEST)
: Nemolivier me fait remarquer que “” sont aussi les guillemets de second niveau du français, par exemple : « Kazé dit “je ne sais pas” ». À ce titre, il serait d'autant plus cohérent d'avoir “” sur les mêmes touches que «». [[Utilisateur:Kaze|Kaze]] 4 juin 2008 à 01:58 (CEST)


Et supprimer « ≤ » et « ≥ », ou les mettre à la place actuelle des guillemets anglais.
=== Ajouter le guillemet ouvrant allemand « „ » ===


== Ajouter le guillemet ouvrant allemand « „ » ==
* En {{ta|Altgr}}-{{ta|Maj.}}-{{ta|1}}, en supprimant le demi-cadratin. <br> Avec la proposition au dessus, on aurait les guillemets allemands côte à côte et dans le bon ordre. C'est la solution qui donnerait la meilleure cohérence, les 6 guillemets doubles étant regroupés sur 3 touches.
┌────┬────┬────┬────┬────┬────┬
│ # {{B|§}}│ 1 {{B|„}}│ 2 {{B|“}}│ 3 {{B|”}}│ 4  │ 5  ║
│ $ {{B|–}}│ " —│ « <│ » >│ ( [│ ) ]║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║  |<-  ║ B ¦│ É ˝│ P {{B|¶}}│ O Œ│ È  ║
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║


En {{ta|Altgr}}-{{ta|Maj.}}-{{ta|1}}, si la place est toujours libre à l'issue du deuxième tour de la 0.6.6.
* En {{ta|Altgr}}-{{ta|Maj.}}-{{ta|$}}, pour préserver le demi-cadratin : « ¶ » passe en {{ta|Altgr}}-{{ta|Maj.}}-{{ta|P}} ('''P'''aragraphe)
Avec la proposition au dessus, on aurait les guillemets allemands dans côte à côte et dans le bon ordre.
┌────┬────┬────┬────┬────┬────┬
│ # {{B|„}}│ 1 –│ 2 {{B|“}}│ 3 {{B|”}}│ 4  │ 5  ║
│ $ §│ " —│ « <│ » >│ ( [│ ) ]║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║  |<-  ║ B ¦│ É ˝│ P {{B|¶}}│ O Œ│ È  ║
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║


== Ajouter U+0309 Diacritique crochet en chef ==
* Ailleurs…
[[Utilisateur:Kaze|Kaze]] 4 juin 2008 à 01:54 (CEST)


== Ajouter U+031B Diacritique cornu ==
=== Ajouter les guillemets de second niveau anglais sur une paire de doigts ===
En AltGr Maj {Y} et {À}. C’est la même paire de doigts que les autres quillemets.


== Inquiétude ==
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬
J’ai voté pour que nous ne figions pas la version 0.6.6 dès sa sortie car je trouvait logique qu’un version soit testée et éprouvée avant de figer quoi que ce soit. Logique aussi qu’y soient faites des petites correction selon un cycle de RC. Ce vote n’allait donc pas contre la volonté que je croyais commune de figer le bépo. Pourtant lisant cette page je regrette mon vote. Les modifications proposée ici ne sont pas rien (double AltGr, touche compose, j’attends que les chiffres en direct arrivent…). Avec de telles perspectives, la v. 0.6.6 ne sera pas figée. De même cette version 0.6.7, si le double AltGr passe par exemple, ne sera pas « figable » et à ce rythme là j’ai peur qu’aucune la suivant ne le soit. Or toutes ces discussions récurrentes mes semblent de belles impasses puisque nous nous heurtons toujours aux mêmes sempiternels problèmes : corpus, carte d’accessibilité, types d’usages du bépo, historique des inversions… tout ce que la v2 se propose de régler, mais qui ne peut être résolu dans le cycle actuel. Je ne dis pas que les idées présentes ici soient mauvaises (quoi que, « W » en AltGr ???), ni qu’elles ne pourraient pas passer (mystères de la démocratie) mais je crois que ce n’est pas souhaitable.
║  ^  ║ Ê  │ X  │ Y {{B|‘}}│ À {{B|’}}│ : ·│ K ˜║
║  |  ║ ê /│ x \│ y {│ à }│ . …│ k ~║
╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧
Si cette proposition est acceptée, je propose que le « ’ » reste à sa place actuelle sur {,} en tant qu’apostrophe typographique, mais que le {’} ne reste pas sur {'} pour ne pas encombrer inutilement.
[[Utilisateur:Nemolivier|Nemolivier]] 7 juin 2008 à 19:06 (CEST)


Je propose donc au vote que cette 0.6.7 soit une 1.0-rc et que les seuls modifications proposées soient des corrections raisonables de la 0.6.6.passer [[Utilisateur:Nemolivier|Nemolivier]] 12 mai 2008 à 20:16 (UTC)
Ou à la place des actuels guillemet anglais de premier niveau :


:Je m'étais jusque là abstenu de voter, étant un utilisateur trop récent. Mais là je pense que je voterai pour figer la 0.6.6. La raison n'est pas que je trouve cette disposition parfaite, mais qu'on en est arrivé à un point où la plupart des défauts évidents (et corrigibles sans grosse modif) ont été corrigés (il en reste bien quelques uns, comme l'inversion ;/?) et où les seuls vrais défauts qui n'ont pas été corrigés sont ceux dont la résolution mettraient le boxon (les ZWMÇ hors de la zone principale, les chiffres en shift, les guillemets pas en shift). Or, qui dit boxon dit perte des bénéfices de l'algorithme qui avait calculé la disposition d'origine, et pléthore de nouveaux défauts auxquels on n'avait pas pensé, et qui vont nous forcer à créer encore 36 000 versions pour les corriger. Bref si on ouvre la boîte de Pandore, le projet n'aboutira jamais.
┌────┬────┬────┬────┬────┬────┬
:De plus, tous ces ajustements obtenus dans la douleur ces dernières années constituent de toute façon un frein psychologique à l'innovation, et il est normal que de bonnes idées trop novatrices se voient refusées dans l'état actuel du projet (du moins tant que le système du vote majoritaire perdurera). Bref les votes sur des évolutions de la disposition actuelle seront nécessairement biaisés en ce sens.
│ # {{B|§}}│ 1 {{B|„}}│ 2 {{B|“}}│ 3 {{B|”}}│ 4 {{B|‘}}│ 5 {{B|’}}║
:Si on veut réellement progresser, tout en gardant ce mode de fonctionnement démocratique, il n'y a pas d'autre choix que de repartir sur une nouvelle base qui évoluera parallèlement à la première base sans la casser.
│ $ {{B|}}" —│ « <│ » >│ ( [│ ) ]║
:C'est pour cela que je pense, comme Nemolivier, que la 0.6.6 doit être figée pour devenir une 1.0-alpha (ou bien beta ou bien rc1... selon la sémantique et l'ampleur des changements envisagés avant la 1.0). Ne pourront être modifiés pour la version suivante que des touches en shift (et inférieurs), puis celle d'après que les touches en alt-gr, et ainsi de suite, jusqu'à obtenir la 1.0 qui sera envoyée à TypeMatrix, par exemple (en revanche, normaliser la 1.0, c'est faire une croix sur la 2.0), et constituera de toute façon un argument de poids pour faire venir de nouveaux utilisateurs.
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
:Les corrections novatrices, chamboulatoires et/ou boxogènes ne devraient être prises en compte qu'en tant que nouvelles contraintes pour l'algo qu'on fera tourner à nouveau pour obtenir une base pour la 2.0 (comment faut-il appeler la version obtenue à la sortie de l'algo ?). Comme ça, on ne casse rien, et on cherche l'optimalité sans a priori.
║  |<-  ║ B ¦│ É ˝│ P {{B|¶}}│ O Œ│ È  ║
:--[[Utilisateur:Aldoo|Aldoo]] 13 mai 2008 à 09:08 (UTC)
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║
::Pour ! {{Pour|Asr}}
:Je suis favorable à la sortie prochaine d'une version 1.0, mais pas avant la résolution des gros problèmes.
:La mauvaise accessibilité du W est un problème qui a été soulevé par des personnes qui tapent aussi en anglais ou en allemand. À condition d'avoir un Alt Gr symétrique, Alt Gr + V m'a paru assez facile à retenir et (dites-moi si je me trompe) plus accessible qu'à l'extrême droite du clavier.
:Si je me souviens bien, A2 a dit sur IRC que ça ne le choquait pas. Personne d'autre n'a réagi. J'ai donc ajouté cette proposition sur la présente page.
:L'accès peu aisé aux chiffres lorsqu'on a beaucoup de grand nombres à taper et qu'on n'a pas de pavé numérique à sa disposition est un autre problème qui se pose souvent.
:J'ai proposé de les rendre accessibles par la touche Caps Lock, et ça a été accepté. Mais certains trouvent ce comportement de la touche Caps Lock inadéquat.
:Je pense donc qu'il faudrait faire des propositions pour avoir les chiffres en accès direct.
:Optionnellement, ça permettrait de mettre les guillemets " et "»" en accès Shift.
:Il y a certainement d'autres problèmes à résoudre, et j'apprécierais qu'ils le soient avant la version 1.0.
:Ça fait trois ans que le projet est en route, alors quelques mois, voire deux ans, de plus ne me font pas peur. Rome ne s'est pas faite en un jour.
:[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 13 mai 2008 à 09:58 (UTC)


Figer la 0.6.6 alors qu'elle n'est même pas finie, et au risque d'incohérences ? Et ensuite prétendre à une version « stable » dans ces conditions ? Personnellement je pense qu'il vaudrait mieux se mettre d'accord sur une liste des [[points bloquants]] restants et figer ça plutôt que de figer le layout, en s'interdisant l'ajout de nouvelles fonctionnalités qui seront pour une v2. Exemple: La touche morte « lettre grecque » a été placée  en AltGr+G. C'est très bien, mais que faire du µ actuel en Shift+% ? Le garder ? Le remplacer par autre chose ? C'est un problème qui est apparu suite à l'implémentation d'une nouvelle fonctionnalité. Figer le layout à ce point ne me semble pas bon, ça interdirait de mettre quelquechose comme (par exemple) l'accent grave ASCII ` en Shift+%. Par contre figer les derniers [[points bloquants]] et interdire de nouvelles fonctionnalités permettrait :
[[Utilisateur:Glehmann|Gaëtan]] 13 juin 2008 à 19:24 (CEST)
* D'éliminer la quasi-totalité des propositions sur cette page (et tant pis pour le s long ſ ou la phonétique, [[Idées pour une v2|cf v2]]) ;
* De résoudre les derniers petits soucis comme le grave ASCII ` qui est passé en AltGr-Shift alors qu'il est très utile en shell ;
* D'attirer l'attention et de focaliser les efforts sur une [[Idées pour une v2|version 2]] pour ceux qui veulent ajouter des fonctionnalités.
Il faut juste se mettre d'accord sur les points à résoudre. La page des [[points bloquants]] actuels peut servir de base de départ, y compris pour reporter des changements comme W ou Ç à une [[Idées pour une v2|version 2]]. [[Utilisateur:Nbrodu|Nbrodu]] 13 mai 2008 à 10:04 (UTC)
:Tu as beaucoup de points bloquant qui sont là uniquement pour le support des langues étrangère et l'informatique. Or le Bépo v1 a été conçu pour le Français (si je ne me trompe pas) et le rendre plus international ou plus technique pourra être justement un des objectifs de la v2.[[Utilisateur:Tiot|Tiot]] 13 mai 2008 à 10:58 (UTC)
::Bah, là il est en train de devenir ''moins'' technique, et plus international (cf inversion accent grave mort). C'est ce genre de compromis qui à mon avis ne peut être résolu que [[Idées_pour_une_v2#Multi-crit.C3.A8res|de façon globale]]. Donc oui, tu as raison que c'est un des objectifs pour une [[Idées pour une v2|version 2]]. [[Utilisateur:Nbrodu|Nbrodu]] 13 mai 2008 à 11:17 (UTC)
:AMHA, l'ajout d'une touche morte (pour la phonétique), ou d'un ſ en (shift-)alt-gr ne remet pas nécessairement en cause toute la disposition, et pourrait être fait même après la première fixation de celle-ci. Sinon je suis d'accord pour permettre la résolution les points bloquants non-chamboulatoires après la première fixation (exemple, inverser ' et ‘, si c'est souhaitable). En revanche, les chiffres en direct et l'internationalisation me semblent avoir trop de conséquences. --[[Utilisateur:Aldoo|Aldoo]] 13 mai 2008 à 12:18 (UTC)


Pour éliminer quelques de points de cette page il y aurait un autre critère bien simple : qu'on retire des objectifs de la v1.0 tout ce qui ne peut pas être implémenté proprement sur toutes les plate-formes : les touches mortes non prévues par xkb, la deuxième touche AltGr, Compose, etc… Quitte à faire une version stable, faisons en sorte qu'elle soit simple. [[Utilisateur:Kaze|Kaze]] 13 mai 2008 à 15:48 (UTC)
=== Compose ===
Ce vote à déjà eu lieu sans qu’une proposition intéressante soit faite pour l’emplacement.
Des discussions sur IRC sont apparues deux propositions. Je ne sais pas si ça rend cette proposition plus valable pour la 1.0.
* Compose sur AltGr Maj {X}
* Compose sur [=] dans la mesure ou il y aurait une réorganisation des `, ^, % et ‰
[[Utilisateur:Nemolivier|Nemolivier]] 7 juin 2008 à 19:31 (CEST)


==Feuille de route==
: Je suis contre l'utilisation de Compose dans une disposition de clavier, pour plusieurs raisons :
Sinon, pour la suite, pourquoi ne pas se mettre d'accord sur une [[feuille de route]] pour la version 1.0 avec des jalons à objectifs précis ? (J0 : définition des points bloquants, avec vote, J1 : résolution des points bloquants, J2 : fixation des accès directs, J3 : fixation des shift... and so on, sachant qu'il peut y avoir zéro, une ou plusieurs versions entre chaque jalon). Je propose que le prochain vote concerne la feuille de route, plutôt que le contenu de la 0.6.7. --[[Utilisateur:Aldoo|Aldoo]] 13 mai 2008 à 12:27 (UTC)
:* ça va être merdique à implémenter sous Windows™ et MacOS™ : les empilements de touches mortes c'est bien beau, mais s'il faut retranscrire tout un fichier ~/.XCompose sous cette forme, on n'a pas fini de rigoler.
: +1, je pense qu'il est préférable de figer la dispo en (au moins) trois temps :
:* sous Windows™ et MacOS™ toujours, on n'a toujours pas d'implémentation de ce procédé. J'attends de voir un pilote permettant d'implémenter une touche Compose qui fonctionne dans toutes les applications (y compris Word™) sans ralentir la machine hôte.
:# Carte des touches en accès direct : on évacue définitivement les souhaits et regrets sur le placement des touches de base.
:* sous Linux, la touche Compose est prévue pour être indépendante de la disposition de clavier, et est définie directement dans /etc/X11/xorg.conf avec une ligne du type :
:# Carte simplifiée : on fige la couche Maj et les principaux caractères en AltGr (les deux points sont liés), les propositions relatives aux accès directs étant désormais irrecevables.
        Option "XkbOptions" "compose:rwin"
:# Carte complète : on place les accès AltGr restants, les propositions impactant la carte simplifiée étant irrecevables.
: Je pense que le choix d'utiliser ou non une touche Compose devrait être laissé au seul utilisateur. Comme beaucoup de Linuxiens j'ai mon propre fichier ~/.XCompose, fait pour mes besoins propres, et je ne vois pas pourquoi la disposition de clavier devrait venir se mêler de ça. Concentrons-nous sur ce qui est implémentable proprement sur *toutes* les plate-formes ! [[Utilisateur:Kaze|Kaze]] 7 juin 2008 à 20:44 (CEST)
:Pour accélérer un peu le mouvement et pour éviter l'aspect « usine à gaz », je pense qu'on pourrait même publier une version 1.0 dès l'étape 2, avec une couche AltGr volontairement incomplète (VoidSymbol) : si la dispo contient tous les caractères présents sur les claviers type Azerty, c'est qu'elle est utilisable au quotidien. Par la suite, rien n'empêcherait de proposer des version 1.0.x où on ne s'autorise à modifier que ce qui n'impacte pas la carte simplifiée ; la « vraie » version stable serait la 1.0 et non la 1.0.x. [[Utilisateur:Kaze|Kazé]] 13 mai 2008 à 15:21 (UTC)
:: je suis assez sensible à cet argument. [[Utilisateur:Nemolivier|Nemolivier]] 7 juin 2008 à 20:58 (CEST)
:PS : la roadmap pourrait être accompagnée de la liste des objectifs pour les deux versions (v1 et v2), ça ne ferait pas de mal. [[Utilisateur:Kaze|Kaze]] 13 mai 2008 à 15:25 (UTC)
:: En même temps, j’ai la touche morte dans mon xkb — il faut mettre « Mult_Key », et ça semble fonctionner, le fait que ce puisse être fait dans le xorg.conf n’interdit pas de le faire dans le xkb (c’est peut-être même plus propre puisque ça permet que le compose soit différent fonction de la disposition utilisée). Quoi qu’il en soit peut-être la proposition de mettre un compose en Maj+AltGr+X permettrait de contenter les linuxéens pour lesquels ce mécanisme et cette touche sont familiers, sans prendre une place primordiale pour les autres système qui n’en profitent pas. Certes ce n’est pas une accessibilité géniale, mais rappelons qu’avec le bépo de nombreux symboles sont accessibles par un autre mécanisme que compose et qu’on peut donc supposer que l’usage de cet touche perde de l’importance. [[Utilisateur:Nemolivier|Nemolivier]] 9 juin 2008 à 17:51 (CEST)
::: Quitte à utiliser un « Mult_key » en Maj+AltGr, est-ce qu'il ne vaudrait pas mieux utiliser Maj+AltGr+{Espace} ? Au moins, ça s'enchaînerait bien avec toutes les combinaisons. [[Utilisateur:Kaze|Kaze]] 9 juin 2008 à 19:47 (CEST)


=== Ajouter U+0309, diacritique crochet en chef ===


=== Ajouter U+031B, diacritique cornu ===
=== Ajouter U2248, « almost equal to » ===
Une bonne position, pour ce signe relativement rare, serait {{t| ~ }} {{t|signe égal}} [[Utilisateur:Asr|Asr]] 30 juin 2008 à 15:31 (CEST)


''Texte repris depuis une discussion qui avait lieu à l'occasion du second tour de la 0.6.6, mais qui a été ajournée au vote qui aura lieu après la sortie de la version 0.6.6 pour savoir si on fige ou non les caractères (et lesquels). À mettre en forme et à fusionner avec le texte précédent.''
== bépow ==
Possibilité offerte aux utilisateurs, en plus du bépo classique, d’un bépo international désigné sur le wiki sous le nom de [[Utilisateur:Kaze/Bépo-intl|bépo-intl ou bépow]]. Ceci permettrait de répondre à la demande — fréquente pour nos utilisateurs actuels, souvent informaticiens — de pouvoir écrire en anglais plus facilement. Le but de cette version est qu’elle « colle » le plus possible à la version officielle du bépo pour que le passage de l’un à l’autre se fasses sans heurts. Cette version n’est donc pas l’occasion de re-proposer des choses tel que le AltGr symétrique ou autres… [[Utilisateur:Nemolivier|Nemolivier]] 8 juin 2008 à 11:41 (CEST)


Ce pourrait être :
== Normalisation par étapes ==
# figer les positions des lettres ;
# définir et figer la carte simplifiée, toutes les propositions concernant les lettres étant désormais irrecevables — à l'issue de quoi, on dispose d'une première ''Release Candidate'' ;
# définir et figer la carte complète, toutes les propositions concernant la carte simplifiée étant désormais irrecevables — à l'issue de quoi, on a une v1.0.
: Il faudrait préciser les modalités de vote, par exemple : on pourrait, dès le prochain vote, proposer de voter de figer la position des lettres, le vote n'étant recevable que si aucune modification des lettres n'est acceptée dans le même vote. Et si nécessaire, on repropose de figer les lettres lors des votent qui suivent, jusqu'à ce que ça soit accepté. Puis idem pour la carte simplifiée, et pareil pour la carte complète. [[Utilisateur:Kaze|Kaze]] 15 mai 2008 à 23:53 (UTC)


Ou encore :
Certains caractères présent sur le clavier, comme ¬, ſ et autres ne sont indispensables ni à la typographie d'une langue européenne, ni à l'usage informatique. Sans qu'il soit nécessaire de les retirer des pilotes, on pourrait envisager le système suivant: on normalise le bépo avec des emplacements vides là où sont actuellement ces caractères, mais en indiquant dans la norme que ce sont les caractères recommandés pour ces emplacements. Cela permet d'adapter le bépo à des usages pour lesquels des caractères non présents sur notre version du clavier seraient nécessaires.
# Figer la liste des [[points bloquants]] à résoudre (et plus de propositions nouvelles hors ces points)
# S'atteler à ces points et uniquement ceux-là
# Figer les caractères principaux quand aucun nouveau point bloquant n'apparait (et Release Candidates à ce point)
# v1
: Si on fige la liste des points bloquants en #1, le point #3 devient « figer les caractères principaux (et Release Candidates à ce point) ».
: Ce qui m'inquiète, c'est que le terme « points bloquants » est ambigu et hautement subjectif. Qu'est-ce qui différencie un point bloquant d'une simple amélioration ? Comment faire pour que la liste des points bloquants ne devienne pas un doublon de la page de discussion du prochain vote ? Est-ce qu'il faudra voter pour valider chaque point bloquant, puis voter pour une façon de le résoudre ? Et si un point bloquant n'a pas de solution simple (ex : place du W), est-ce que ça ne bloquera pas tout le processus ?
: Par ailleurs, je crains que de figer la liste des points bloquants ne revienne plus ou moins à s'interdire de trouver de bonnes idées non « boxogènes » pour la 1.0 — ou pire, à s'interdire de corriger des problèmes qui pourraient apparaître après les changements récents.
: Cette liste de points bloquants est un bon outil, qu'il serait dommage de boxonifier en le soumettant au vote. ;-) [[Utilisateur:Kaze|Kaze]] 15 mai 2008 à 23:53 (UTC)
::Toutafé. Figeons la carte simplifié, et gardons à l'esprit les points bloquants.
::Pour ce qui est du boxogène, l'algorithme du recuit simulé censé résoudre les problèmes np-complets – dont fait partie le clavier BÉPO – prévoit une marge de manoeuvre de plus en plus étroite à mesure de l'avancée des recherches de solution. Ceci, afin de s'autoriser des sautes en arrière de plus en plus réduites, et convirger vers un optimum le plus approchant de l'optimum global.
::Je crois qu'il faut que nous commencions à restreindre la portée des changements proposés. [[Utilisateur:Asr|Asr]] 16 mai 2008 à 06:56 (UTC)


:Je sais que je n'aurais peut-être pas dû faire une page à part, mais j'ai une proposition [[Processus de release|là]] qui il me semble s'attaque à ces problèmes, il me semble qu'il faudrait discuter de ça avant de voir les nouvelles propositions, ne serait-ce que parce que l'on ne fera pas forcément la même 0.6.7 (si on l'appelle comme ça) selon ce qu'on décide. Venez discuter du déroulement et du figeage éventuel. [[Utilisateur:Galbolle|Galbolle]] 3 juin 2008 à 12:01 (CEST)
Pour aller plus loin, on pourrait rendre "facultatifs mais encouragés" les caractères non-ascii non-francophones, par exemple pour faire des variantes adaptées aux pays africains, avec les caractères spécifiques des autres langues de ces pays pas trop inaccessibles. De telles variantes seraient « non-officielles mais compatibles »


: +1, je serais même d'avis d'aller plus loin dans cette logique.
: Je trouve que les touches mortes telles que la grecque ou la monétaire ne devraient pas figurer dans une version officielle : elles sont merdiques à implémenter sous Linux du fait qu'elles reposent sur une modification du comportement de Compose — le bépo étant, à ma connaissance, la seule disposition de clavier qui requière un tel mécanisme.
: En clair, je pense qu'on devrait se contenter de normaliser la carte simplifiée. [[Utilisateur:Kaze|Kaze]] 12 juin 2008 à 09:50 (CEST)
:: Je dirais un tout petit peu plus que la carte simplifiée : je pense qu'on devrait ajouter le demi-quadratin et l'apostrophe courbe: on arriverait à une définition de carte simplifiée qui serait : « tous les caractères nécessaires pour bien taper le français plus tous les caractères ascii imprimables». D'ailleurs si les canadiens utilisent ¢ pour le cent, on pourrait peut-être aussi l'inclure dans cette carte simplifiée. Sinon, entièrement d'accord, à condition de bien préciser que le contenu des autres emplacement est recommandé. [[Utilisateur:Galbolle|Galbolle]] 13 juin 2008 à 10:18 (CEST)
::: Tout à fait d'accord. Cela rejoint parfaitement le discours que j'ai déjà plusieurs fois tenu. Une carte avec les caractères nécessaires au Français pour la norme, puis des annexes précisant des recommandations pour le remplissage des trous. [[Utilisateur:Stéphane Veyret|Rideĉjo]] 17 juin 2008 à 14:38 (CEST)
:: Dans la même veine, faut-il normaliser le comportement de caps-lock ? Son utilisation, que ce soit comme shift-lock ou comme caps-lock est très mineure. En ne normalisant pas, on permet des drivers non officiels avec un comportement de caps-lock plus utile. Par exemple un altgr symétrique, ou un programmer-lock donnant accès aux symboles courants de programmation exilés un peu loin. (Bien sûr cette proposition ne nous engage pas à implémenter ni le altgr symétrique, ni le programmer-lock)[[Utilisateur:Galbolle|Galbolle]] 26 juin 2008 à 12:26 (CEST)
:: Pour en rajouter encore une couche, la touche {ê} est-elle vraiment très utilisée ? (moi je ne m'en sers jamais) Comme elle n'est pas disponible sur certains claviers, ne pas la normaliser ajoute une certaine liberté pour ceux qui ont des besoins exotiques.[[Utilisateur:Galbolle|Galbolle]] 27 juin 2008 à 16:13 (CEST)


Puis une fois cette section faite (TODO)
== Chiffres en direct ==


Approuvez-vous la feuille de route ci-dessus ?
Bon, je ne suis pas venu depuis un petit moment. En fait, la liste de diffusion a cet avantage de me rappeler régulièrement de venir voir ce qui se passe. Avec la grosse panne, j'ai « oublié » de venir pendant longtemps.
* oui
* non


== Qu'entend-t-on par « caractères principaux » ? ==
Depuis le temps qu'on en parle et que personne ne le propose vraiment pour les votes, je suggère de faire une proposition avec les chiffres en accès directs. Cela implique beaucoup plus que d'échanger simplement les chiffres avec les caractères qui sont dessous, alors je laisse à ceux qui ont des idées sur le sujet (ceux qui ont déjà fait des propositions dans ce sens) continuer cette discussion. [[Utilisateur:Stéphane Veyret|Rideĉjo]] 17 juin 2008 à 14:36 (CEST)
:Cette proposition ne doit pas être faites pour la version 1.0. Comme tu le dis les changements que cela entraînerait sont trop nombreux. Ce doit être reporté à la v2. [[Utilisateur:Nemolivier|Nemolivier]] 17 juin 2008 à 14:42 (CEST)
:: Je ne suis pas d'accord. La version 1.0 sera la dernière, il n'y aura donc pas de possibilité de faire cette proposition pour une autre version, si on ne s'en occupe pas maintenant.
:: Je pense que peu de gens franchirons le pas pour passer de l'AZERTY au BÉPO, alors si en plus il faut ensuite passer d'une version 1.0 à une version 2.0, cela ne peut intéresser que les Geeks. Cette proposition de chiffres en direct me semble très importante, et elle ne l'est pas qu'a mes yeux, si j'en juge par les commentaires que l'on a eu à chaque fois qu'on en a parlé. Je pense donc qu'elle doit être étudiée pour la version 1.0, quitte à en retarder la sortie. [[Utilisateur:Stéphane Veyret|Rideĉjo]] 18 juin 2008 à 09:30 (CEST)
::: Rien n’indique que la version 1 sera la dernière. Si la v2 n’intéresse que les geeks, ça tombe bien : ce sont les geek qui veulent les chiffres en direct (de fait, ça correspond à leur usage). Les commentaires que nous avons eu lors des discussions sur le sujet allaient dans les deux sens. Y compris des personnes qui ne savaient pas ce qui était le mieux. Si il y avait eu tant de personnes pour qui cette proposition était importante, évidente ou si facilement « réglable », sans doute aurions-nous eu un vote (on a bien eu un vote pour une touche « où »). Encore une fois, si c’était clairement justifié, consensuel et facilement intégrable, très bien. Ce n’est pas le cas. [[Utilisateur:Nemolivier|Nemolivier]] 18 juin 2008 à 23:22 (CEST)
:::: ''« ce sont les geek qui veulent les chiffres en direct (de fait, ça correspond à leur usage) »''
:::: Non. Je pense au contraire que ce sont les travailleurs qui en ont besoin, pour exprimer des dates, des quantités ou des montants, dans leur documents Word™ ou dans leurs courriels : « RdV le 15.07.2008 à 15h en salle 3b », « Règlement des 3 840,43 € correspondant aux 30 % d'avancement », etc. À moins d'être auteur dramatique, les chiffres en direct sont une nécessité dans le cadre professionnel. Par ailleurs, on n'utilise que très rarement plusieurs caractères tels que "<>()_+-/* à la suite, contrairement aux chiffres ; on pénalise donc fortement l'utilisation professionnelle pour une faible amélioration en utilisation littéraire. Le pavé numérique n'est pas une solution non plus : on perd la position dactylo, c'est déjà nul en Azerty, mais alors pour une disposition qui se veut ergonomique…
:::: L'Azerty est une des très rares dispositions à ne pas avoir les chiffres en direct, mais c'est pour une bonne raison : la plupart des caractères accentués sont sur la rangée des chiffres ; il me semble que le projet Bépo a fait le choix des chiffres en Shift pour de bien mauvaises raisons : héritage de l'Azerty, pas ou peu d'utilisation dans le cadre professionnel, corpus pas représentatif, système de vote, toussa.
:::: Quoiqu'il en soit, je suis entièrement d'accord avec Nemolivier pour dire qu'il est trop tard pour changer ça avant la ''release'' 1.0 — ne serait-ce qu'à cause de l'emplacement du tiret. Gardons ça pour la v2, qui sera, je l'espère, une disposition plus polyvalente que la v1.
:::: [[Utilisateur:Kaze|Kaze]] 19 juin 2008 à 11:32 (CEST)


Votez pour ou contre les propositions suivantes en fonction de vos préférences :
== <> en shift = et % ==
* les lettres ?
[[Discuter:Version_0.6.5/Archive#Place_des_guillemets_fran.C3.A7ais]]
* les lettres et les caractères de ponctuation ?
* les lettres et tous les caractères obtenus sans AltGr ?
* les lettres et les caractères de ponctuation et les caractères fréquents en informatique ?


Rappel: Un vote sera organisé après la sortie de la version 0.6.6 pour savoir si on fige ou non ces caractères
Voilà dans ce fil de discution il y a une personne qui propose de placer <> en shift = et %. Comme il y a eu beaucoup de critiques contre la place actuelle des <> je me demande si ça ne peut pas plaire à pas mal de gens. Les <> seront à mon avis moins accessible mais ils seront en shift et le </> sera plus facile. On pourrait aussi en profiter pour ramener les guillemets simples avec les autres guillemets. J'utilise très peu les <> mais j'aime bien cette solution car elle permet la création de touches guillemets. Avis des utilisateurs de <> ?
┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔═════════╗
│ # ¶│ 1 –│ 2 ‘│ 3 ’│ 4  │ 5  ║ 6  │ 7 °│ 8 ′│ 9 ″│ 0  │ < ≤│ > ≥║        ║
│ $ §│ " —│ « “│ » ”│ ( [│ ) ]║ @  │ + ±│ - −│ / ÷│ * ×│ = ¬│ % ‰║ <--    ║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
 
[[Utilisateur:Tiot|Tiot]] 27 juin 2008 à 09:39 (CEST)
 
: Ça me semble une bonne idée, en profiter pour mettre le guillemet ouvrant allemand ([[Discuter:Version_0.6.7#Ajouter_le_guillemet_ouvrant_allemand_.C2.AB_.E2.80.9E_.C2.BB|voir plus haut]]) et rajouter le guillemet simple ' en AltGr + Maj + ["] permettrait une cohésion des guillemets intéressante.
:J'ai déplacé les caractères en AltGr de ["] vers [@] par défaut : la place était libre.
┌────┬────┬────┬────┬────┬─–───┬────┬────┬────┬────┬────┬────┬────╔═════════╗
│ # ¶│ 1 {{B|'}}│ 2 ‘│ 3 ’│ 4  │ 5  ║ 6 {{B|–}}│ 7 °│ 8 ′│ 9 ″│ 0  │ {{B|<}} {{B|≤}}│ {{B|>}} {{B|≥}}║        ║
│ $ §│ " {{B|„}}│ « “│ » ”│ ( [│ ) ]║ @ {{B|—}}│ + ±│ - −│ / ÷│ * ×│ = ¬│ % ‰║ <--    ║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
: [[Utilisateur:Rogdham|Rogdham]] 28 juin 2008 à 11:40 (CEST)
:: Je pense plutôt que ces deux touche, même en accès Maj, sont bien moins accessibles qu’en AltGr « 2 », « 3 ». Je ne vois pas en quoi les mettre loin facilite le fait de taper « <> ». À l’heure actuelle c’est AltGr mains droite puis « 23 » main gauche. C’est tout aussi bien, mieux puisque les touches sont plus proches. [[Utilisateur:Nemolivier|Nemolivier]] 28 juin 2008 à 13:37 (CEST)
::: Je teste cette disposition des touches en codant une page web à la main. Un premier bilan : je trouve que les deux dispositions des « <> » se valent à peu près, avec un léger avantage pour la disposition actuelle (0.6.6) : ça m'arrive de temps en temps de taper sur le retour arrière à la place de « > » ( [+] en azerty ), peut-être un mauvais apprentissage de cette région du clavier de ma part…
::: Il y a cependant la combinaison « /> » qui est plus facile : avoir l'annulaire sur {/} et le pouce sur AltGr en prévision du {>} main droite est au désavantage de la version actuelle, même c'est largement faisable. Mais cette remarque vaut pour le XML et sûrement pas en général, où l'on n'utilise rarement « / » avant « > ».
::: Enfin, comme je n'ai pas à taper « <> » à la suite, ça ne pose pas de problème de les avoir sous le même doigt, mais il me semble que l'on a à le faire dans certains langages de programmation.
::: La disposition actuelle me semble finalement meilleure, mais je n'ai sans doute pas fait le tour des arguments possibles !
::: [[Utilisateur:Rogdham|Rogdham]] 29 juin 2008 à 10:54 (CEST)


<--!
== Extension des touches mortes ([[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 2 juillet 2008 à 18:40 (CEST)) ==
== Faire de la place ==
Voici une liste (non exhaustive) de caractères qu’on pourrait produire aisément sans chambouler tout le clavier :
Pour faire de la place sur la disposition (idées de Schultz et de Kaze publiées avec 42 jours de retard) :
* ≁ : « / » morte + « ~ »
*Déplacer « X » sur compose + \ + /
* ≢ : « / » morte + « ¯ » mort + « = »
*Déplacer « K » sur compose + | + <
* ≄ : « / » morte + « ~ » mort + « - »
*Déplacer « ^ » sur compose + ´ + `
* ≉ : « / » morte + « ~ » mort + « ~ »
*Déplacer « A » sur compose + / + - + \
* ≇ : « / » morte + « ~ » mort + « = »
*Déplacer « E » sur compose + | + ¯ + _ + -
* ≚ : « ˇ » mort + « = »
*Déplacer « F » sur compose + | + ¯ + -
* ⨣ : « ^ » mort + « + »
*Déplacer « C » sur compose + (
* ≙ : « ^ » mort + « = »
*Déplacer « D » sur compose + | + )
* ⩯ : « ^ » mort + « ~ » mort + « ~ »
*[http://www.google.com/search?hl=xx-hacker&q=31337&btnG=z34r%3C%7C-%7C supprimer les minuscules, voire les lettres tout court]
* ⨪ : « ¯ » mort + « . »
* ⌅ : « ¯ » mort + « ^ »
Pas de vote contre SVP
* ≂ : « ¯ » mort + « ~ »
[[Utilisateur:Tohuvabohuo|Tohuvabohuo]] 13 mai 2008 à 07:57 (UTC) !-->
* ∓ : « ¯ » mort + « + »
* ≡ : « ¯ » mort + « = »
* ⩦ : « ¯ » mort + « ¯ » mort + « . » (deux fois le « ¯ » mort ne pourrait donc plus donner le « ¯ » non mort)
* ⌆ : « ¯ » mort + « ¯ » mort + « ^ »
* ⩳ : « ¯ » mort + « ¯ » mort + « ~ »
* ⩱ : « ¯ » mort + « ¯ » mort + « + »
* ⪙ : « ¯ » mort + « ¯ » mort + « < »
* ≣ : « ¯ » mort + « ¯ » mort + « = »
* ⪚ : « ¯ » mort + « ¯ » mort + « > »
* ⋮ : « ˙ » mort + « : »
* ⩪ : « ˙ » mort + « ~ »
* ⸞ : « ˙ » mort + « ~ »
* ∔ : « ˙ » mort + « + »
* ≐ : « ˙ » mort + « = »
* ⨰ : « ˙ » mort + « × »
* ⪁ : « ˙ » mort + « ≤ »
* ⪂ : « ˙ » mort + « ≥ »
* ⩧ : « ˙ » mort + « ¯ » mort + « = »
* ⦙ : « ˙ » mort + « ˙ » mort + « : » (deux fois le « ˙ » mort ne pourrait donc plus donner le « ˙ » non mort)
* ⩭ : « ˙ » mort + « ~ » mort + « = »
* ⸛ : rond en chef + « ~ »
* ⨢ : rond en chef + « + »
* ≗ : rond en chef + « = »
* ≃ : « ~ » mort + « - »
* : « ~ » mort + « . »
* ≈ : « ~ » mort + « ~ »
* ⨤ : « ~ » mort + « + »
* ⪝ : « ~ » mort + « < »
* ⪞ : « ~ » mort + « > »
* ≆ : « ~ » mort + « / » morte + « = »
* ≅ : « ~ » mort + « ¯ » mort + « - »
* ⩬ : « ~ » mort + « ¯ » mort + « ~ »
* ≊ : « ~ » mort + « ~ » mort + « - » (deux fois le « ~ » mort ne pourrait donc plus donner le « ~ » non mort, ce qui m’amène à penser que ce serait plutôt un caractère pour la touche compose)
* ≋ : « ~ » mort + « ~ » mort + « ~ »
* ⩰ : « ~ » mort + « ~ » mort + « = »
* ⸚ : « ¨ » mort + « - »
: Je radote… Les touches mortes c'est très bien, je trouve ça même mieux qu'AltGr pour les lettres, mais l'implémentation de ce genre de combinaisons est problématique :
:* sous Linux : cela suppose de modifier ou de créer un fichier ~/.XCompose, de modifier le système pour qu'il utilise ce fichier (im-switch & co), bref ça n'est pas pratique, pas accessible à tout le monde, et surtout ça n'est pas portable — ce qui est gênant tant que la dispo n'est pas figée et incluse dans Xorg ;
:* sous Windows™ : les touches mortes en cascades ne sont pas supportées, il faudrait un pilote C spécifique — comme celui qui devrait implémenter la touche Compose.
: Je pense que ces caractères devraient être faits avec une touche Compose, et donc que ça devrait être indépendant de la dispo de clavier. [[Utilisateur:Kaze|Kaze]] 2 juillet 2008 à 18:53 (CEST)

Dernière version du 16 août 2008 à 21:12

Dates

Bien que, malheureusement, notre chère liste de diffusion soit toujours convalescente, je trouve qu’il serait bien de passer rapidement à la suite afin de graver cette dispo dans le marbr…heu… virtuel ! La version 6.7 me semble moins compliquée que les précédentes, et si ce n’est pas le cas… les modérateurs auto-proclamés sont là ! Je ne sais pas s’il est nécessaire de voter pour figer, il me semble que la volonté est d’aller dans ce sens là, que la décision est prise et que faire un vote n’a que peu d’intérêt compte tenu du fait qu’il n’y a pas de date précise pour une 1.0, non plus que de nombre de RC. Tout au plus appelons cette 0.6.7, 1.0RC1

Relisant la page me semble que les propositions sont claires. Reste à préciser :

  • la place du % et ce que ça implique quant aux places accordées à « ^ » et « ` ». Et des propositions pour utiliser la place « vacante ».
  • des proposition de places pour les touches mortes « crochet en chef » et « cornu », et une explication de pourquoi nous devrions les ajouter (je croyais que nous avions déjà tous les « accents » morts).

NB: les propositions sur cette page reçoivent le blanc-seing de nos gentils modérateurs, qui se réservent le droit de les supprimer s'ils les jugent inappropriées.

Alors, une proposition en réponse à moi-même. Nous nous donnons jusqu’à la fin de la semaine pour fignoler les dernières propositions (voir ci-dessus). Après quoi, une semaine de vote (15 jours c’est long, on attends pour 2% des votants, c’est nul) avec nécessité que ¾ des votants de la 066 aient voté à la fin de la semaine. Si cette proportion n’est pas atteinte, on envoie un courriel à tout le monde et on se donne 2 jours de plus. Après, basta ! Nemolivier 10 juin 2008 à 18:08 (CEST)

Vote pour figer, modérateurs et processus de release

Nous avons voté pour « organiser un autre vote pour décider si on fige ou non les caractères principaux après la sortie de la 0.6.6 ». Donc je propose de voter en même temps que la 0.6.7 :

Il devrait être possible de dire : Pour (sauf si…) Tiot 4 juin 2008 à 09:22

Je propose de voter avant de faire la 0.6.7 (par exemple… très bientôt). Je pense qu'il était clair que « organiser un autre vote pour décider si on fige ou non les caractères principaux après la sortie de la 0.6.6 » signifiait « et avant la 0.6.7 » puisque le principal argument du vote était « Il faut savoir ce qu'on se propose de figer ». En plus comme ça, il y a deux réponses possibles: pour et contre, ce qui a le mérite d'être clair.Galbolle 4 juin 2008 à 13:47 (CEST)
Les propositions 0.6.6 entraînaient des changements importants : inversion XHÀ, insécable sur «», inversion AU, Æ ailleur qu'en altgr A, où en altgr U… Les propositions de la 0.6.7 paraissent beaucoup plus raisonnable et ne touche pas à l'emplacement des lettres (à pars si l'inversion ?/;). D'où une possibilité de figer en même temps que la 0.6.7.Tiot 4 juin 2008 à 14:37 (CEST)
Le vote sera sans doute plus serein si l'on décide que si l'on fige, les changements entre 0.6.6 et 0.6.7 seront examinés par les modérateurs. Galbolle 7 juin 2008 à 12:21 (CEST)
Je trouve tous ces votes une perte de temps. Le processus de « figeage » tout le monde le veux. Donc pas besoin de voter. Les modos, il y avait une liste pour savoir qui voulait s’y coller, qui avait des réflexions. Rien n’a bouger. Franchement, je ne crois pas que nous soyons des monstres et éviter un vote de plus nous ferait gagner du temps. Mettons qu’on peut ajouter l’adoubement des modos par la communauté au cours du prochain vote. Cf ma proposition ci-dessus. Nemolivier 10 juin 2008 à 17:57 (CEST)
Oui ! Asr 25 juin 2008 à 12:46 (CEST)
Est-on vraiment sûr que tout le monde le veut. Moi je le veux, mais pas tout de suite. Tohuvabohuo 25 juin 2008 à 14:27 (CEST)

Propositions impactant la carte simplifiée

Revenir sur la « triangulaire » HXÀ

J'utilise la vesion 0.6.6, et vraiment, le digramme CH est pénible (je lève tous les doigts de la main droite pour faire ce digramme !), le H à droite est une horreur pour écrire en anglais (N-grammes TH, WH, …), le X à gauche est pénible pour les couper-coller, et les combinaisons ctrl-x-c et ctrl-x-s sont pratiquement infaisables dans emacs. Revenons à la place précédente, qui rendait difficiles bien moins de choses. Gaëtan 22 juin 2008 à 18:13 (CEST)

Quelle idée, aussi, d'utiliser Emacs… Kazé 22 juin 2008 à 18:54 (CEST)
Si je me souviens bien, on a testé cette triangulaire hxà parce que dans la version 0.6.5.1, le h était plus pénible à la suite d'un échange malencontreux avec le y ("pour tester", on a testé, on a vu). C'est sur cet échange qu'il faut revenir. Je propose donc (dans la mesure où la boîte de pandore est rouverte) de remettre H, Y, X et À à leurs places de la version 0.6.2.2.2, même si c'est de l'histoire ancienne. Galbolle 22 juin 2008 à 23:42 (CEST)
J'ajoute à ces arguments mon mauvais ressenti quant à la nouvelle position du X :
Le X est souvent (toujours ?) entouré de voyelles, alors pourquoi l'avoir mis à gauche ? L'alternance main gauche / main droite est complètement cassée.
Autre chose, c'est devenu un cauchemar de taper des mots en « aux » (auxilaire, la famille des -al au pluriel comme chevaux, bocaux et j'en passe) : tout avec la main gauche, avec un joli digramme à un doigt pour l'annulaire ! (Certes, c'est moins pire si on tape en position « dactylo », mais c'est tout de même pas très confortable.)
La solution de Galbolle me semble tout à fait raisonnable. Florian 23 juin 2008 à 01:02 (CEST)
Je trouve que H est mieux sous la main droite, puisqu'il est (presque) toujours suivi d'une voyelle. Effectivement il est un peu loin du {C} et les digrammes index/annulaire en descendant ne sont pas très naturels, mais je n'y vois rien de pénible pour autant, d'autant que les trigrammes CH+voyelle me paraissent largement facilités par rapport à la version 0.6.5.1. Pour le reste :
  • en Anglais, les digrammes TH ne me gênent pas, et la difficulté des digrammes WH est essentiellement dûe au placement catastrophique du W (Bépow rulez!) ; même le Dvorak-US place WTH sous la même main.
  • Je ne vois aucun problème avec les couper-coller, puisqu'on utilise forcément les flèches entre un couper et un coller.
  • Je ne suis pas compétent pour Emacs, mais les utilisateurs d'Emacs en Dvorak-US ne se plaignent pas du fait que X soit à gauche et CS à droite… Par ailleurs, ne serait-il pas possible de mapper É, À ou È comme un Ctrl+X dans Emacs ? MàJ : non, ce n'est pas possible.
Par contre, je n'aime pas non plus la nouvelle position du X : je trouve qu'il aurait été mieux en [C] qu'en [W], même si les stats étaient légèrement plus favorables à la triangulaire HXÀ qu'à l'inversion H/X. Les fins de mots en -aux sont particulièrement désagréables, alors qu'elles seraient très naturelles avec le X en [C].
Concernant le retour de HYXÀ à leurs places de la version 0.6.2.2.2, je ne vois pas bien ce que ça apporterait, à part pour les digrammes PH… Kazé 23 juin 2008 à 09:07 (CEST)
Ça ajouterait que c'est une version où personne ne se plaignait de la place du H (ni des autres caractères concernés, pour autant que je me souvienne). Accessoirement, c'était la position trouvée par l'algo, il doit bien y avoir une raison. On avait une position du H pas mal, on a voulu tester l'inversion HY, ça n'a pas marché (de l'avis à peu près général). On a alors dit « testons l'inversion HXÀ ». Si on constate qu'elle ne marche pas non plus (je ne me prononce pas là-dessus), autant revenir à la situation qui marchait plutôt que de tester encore une nouvelle possibilité foireuse ou de revenir à une situation qu'on sait pénible, surtout si on veut figer un jour. Galbolle 23 juin 2008 à 10:54 (CEST)
Si ça permet d'aboutir à un consensus, pourquoi pas (en faisant abstraction de mon ressenti personnel sur le placement). Je colle la rangée du bas ci-dessous pour clarifier le débat. Kaze 23 juin 2008 à 11:33 (CEST)
Pour clarifier encore le débat, je précise que c'est la rangée du bas de la 0.6.5.1. 0.6.2.2.2 Galbolle 23 juin 2008 à 11:37 (CEST)
Gni ? Kaze 23 juin 2008 à 12:44 (CEST)
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴──┬─┴──╔══════╩════╣
║   ^  ║ Ê  │ ÀHY  │ :  │ K  ║ ?  │ Q  │ G  │ X  │ F  ║     ^     ║
║   |  ║ ê  │ à \│ h {│ y }│ . …│ k ~║ '  │ q  │ g  │ x  │ f  ║     |     ║
╠══════╩╦══════╦═════╦═══════════════════════╦═══════╦══════╦═╩════╦══════╣

Eheh si on regarde l'historique des version on s'aperçoit que le point de départ pour l'inversion Y/H est le Japonais. Dans la version 0.6.2.2.1 il y a Yota qui fait remarque que les Japonais remplaces le \ par ¥ comme séparateur des répertoires sous windows (Donc pour eux c'est C:¥windows). Il a été refusé pour la 0.6.2.2.2 et finalement accepté pour la 0.6.2.2.4 apparemment car le H était beaucoup plus utilisé que le Y et qu'il y en a qui ont vu un gain. Aujourd'hui le ¥ a été retiré… on voit bien qu'on tourne en rond. Il y a un problème dans la méthode. On ne peut pas dire que l'inversion YH apporte un gain, puis que l'inversion XHÀ apporte un gain puis enfin que le fait de revenir à la position originale apporte un gain ! Ça n'a pas de sens.Tiot 23 juin 2008 à 15:59 (CEST)

Non, ce que l'on est en train de faire est tout à fait en conformité avec la méthode. À la version 0.6.2.2.4, le changement a été accepter «pour essayer» et «départager les gens», il est donc logique ultérieurement de se poser la question «comment les gens se départagent-ils après l'essai ?». Il se trouve simplement qu'entre temps, on a aussi essayé une autre solution avec HXÀ. Maintenant qu'on a essayé ces solutions avec un succès divers (la 0.6.6 ne me dérange pas, en ce qui me concerne), on se demande ce qui finalement était le mieux. Galbolle 23 juin 2008 à 16:10 (CEST)

Certes, le X n’est pas parfait. Mais mon avis est que le H est bien mieux à droite qu’à gauche. Nemolivier 23 juin 2008 à 12:09 (CEST)

À mes yeux, dire que le X n'est pas parfait est un euphémisme. Je veux bien que le H soit mieux à droite, mais il va nous falloir encore combien de version avant de stabiliser le déplacement du H pour que le X (et les autres) soit bon ?
Bref, puisqu'on est là pour proposer des solutions, je poste l'idée que j'ai évoqué sur la ML, à savoir une inversion X/Z :
  • Le X revient à droite
  • Le Ctrl-Z (annuler) devient très facile pour ceux qui continue d'être droitier de la souris. En plus, le Y est juste à côté, parfait couplage pour le Ctrl-Y (refaire, sur beaucoup de logiciels)
  • EZ reste accessible
  • Le Z est, selon l'analyse corpus, environ 3 fois moins utilisé que le X… mais cela peut être l'inverse si on privilégie le vouvoiement. En conséquence, je ne trouve pas insensé d'améliorer son accessibilité.
  • [Edit] Et on se rapproche du bépow !
Florian 23 juin 2008 à 22:53 (CEST)
Difficile de répondre à cette proposition. On est encore sur un problème d’équilibre : {Z} est plus loin mais permet l’alternance. {X} est plus facile mais complique un peu les digrammes. Je ne sais pas comment trancher. Ce qui serait bien, néanmoins, ce serait de décider vite de savoir si on propose quelque chose concernant ce sujet… Qu’en pensez-vous, les autres ? Est-ce une solution intéressante ? Mérite-t-elle d’être mise au vote ? Et surtout quand votons nous ? Nemolivier 23 juin 2008 à 22:35 (CEST)
Il semblerait que cette proposition d'inversion ait reçu un bon accueil sur la ML. Quoi attendre de mieux ? Je me lance et m'attaque à l'édition de l'article ! Florian 23 juin 2008 à 23:11 (CEST)
Je pense qu’il faut inverser X et À. Cela impliquera d’autres problèmes avec X mais c’est certainement la meilleure solution. Je trouve personnelement le H bien mieux placé qu’avant et n’ait pas rencontré de problème spécifique sur les digrammes CH. Par contre j’ai relevé le même problème que certains sur les mots en « aux », point qui avait été mis en avant lors des précédents votes (oui les statistiques sont trompeuses, il faudrait plus de testeurs pour ce genre d’inversions). On n’a pas besoin du À sous le majeur, du X non plus à vrai dire mais le fait d’échanger Z/X ne ferait qu’empirer la problématique des lettres « hors zone dactylographique » chère à Kazé et est donc à éviter à tout prix. A2 23 juin 2008 à 23:33 (CEST)
Je plussoie A2 : le H à droite me convient très bien, mais quoiqu'en disent les stats, je ne vois pas l'intérêt du X en [W] plutôt qu'en [C].
L'inversion X/Z j'y ai pensé aussi (essentiellement pour Emacs d'ailleurs), je l'ai même postée sur le wiki avant de supprimer le post une heure plus tard. Effectivement ça s'enchaîne pas mal, mais ça surcharge un peu plus l'auriculaire droit, qui n'en a vraiment pas besoin.
Et pour ce qui est du Bépow (même si c'est une considération secondaire), c'est neutre. L'inversion X/Z ne nous rapprocherait pas du Bépow, puisqu'il resterait toujours deux lettres à échanger avec À et È. L'inversion X/À placerait le Z en [W] en Bépow, ce qui en reviendrait au même pour les digrammes EZ.
Bref, je vois beaucoup plus d'avantages à inverser X/À que X/Z. Kazé 24 juin 2008 à 10:08 (CEST)

Tiens, pas bête du tout cette inversion J/H, personne n'en a parlé ni sur la ML, ni sur cette page. Couplée à l'inversion X/À, cela semble donner une solution tout à fait consensuelle. Je vais tester ça aujourd'hui pour en avoir le cœur net. Au passage, félicitations à ceux qui ont participé à la synthétisation de la discussion sur l'article, c'est très bien fait :). Florian 25 juin 2008 à 14:57 (CEST)

Quantifier la gêne

Une question qui me taraude: si, comme on le pense, le consensus pour figer existe, alors il n'est certainement pas question d'échanger des lettres sans un cas de force majeure, est-ce que le problème du H et du X justifie de ne pas figer ? D'un autre côté, si l'on doit le faire, autant le faire le mieux possible. Comme nous n'avons pas encore eu le temps de beaucoup tester cette inversion, le degré de gêne occasionné n'est pas bien quantifiable. Je vous propose donc un petit sondage pifométrique destiné à éclaircir la situation.

Indiquez svp, pour le placement de X et de H, le degré de gêne ressenti, sur une échelle de 0 à 20, avec comme référence 0 = clavier parfait, 10 = comme dans la 0.6.5.1, 20 = comme de taper un W avec l'auriculaire gauche. (Détaillez par digramme au besoin) Galbolle 24 juin 2008 à 11:29 (CEST)

Galbolle: X = 10, H = 7, tests sporadiques sur 15 jours de la 0.6.6
Kazé : X = 13, H = 4 (<=> je préfère la 0.6.6 à la 0.6.5.1), XXX jours en 0.6.6
Gaëtan : X = 12, H = 19,5, 27 jours à 100% en 0.6.6
NémOliv’ : X = 09, H = 2 (CH = 5), XXX jours en 0.6.6
Seginus : X = 15, H = 5, XXX jours en 0.6.6
Flocon : X = 5, H = 0, 1 semaine en 0.6.6 + 3 semaines en 0.6.5 avec triangulaire HXÀ
Asr : X = 8, H = 5, 20 jours en 0.6.6
A2 : X = 5, H = 0, 3-4 semaines en 0.6.6
Florian : X = 15, H = 12 (CH = 18) — 1 semaine en 0.6.6
tiot : X = 12, H = 6 — 6 semaines avec inversion XÀH.
Skippy : X = 6, H = 1 — XXX jours en 0.6.6.

200000, c'est encore loin de l'infini, non ? Galbolle, tu avais raison, ton échelle est pas top :-) J'ai mis 1.5 pour le X, par ce que je n'ai considéré que la frappe de texte. Si on compte aussi les raccourcis clavier, je mets beaucoup plus. Gaëtan 24 juin 2008 à 18:40 (CEST)

J'ai changé l'échelle et vos votes arbitrairement, vérifiez Galbolle 24 juin 2008 à 21:47 (CEST)
Je dois être la seule, mais je suis ravie par la disposition actuelle ! J'utilise beaucoup PHI, CH coule tout seul, AUX s'enchaîne bien puisque je m'appuie sur l'annulaire pour aider l'auriculaire à bouger, et EUX est fluide. Flocondeneige 26 juin 2008 à 10:47 (CEST)
Avec l’inversion (la triangulaire) j’ai remarqué une sorte de « blocage », peut-être dû à un mauvais apprentissage sur cette zone : j’hésite parfois entre annulaire et auriculaire pour taper un x (hors digrammes dans la zone). Je pense que la gêne vient plus de la forme du clavier (droit) que d’un pb de positionnement vu que je n’ai pas ce problème main droite. Vivement le TMx2030 :p A2 26 juin 2008 à 17:50 (CEST)

Inversion ?/;

╠═══════╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───╚╗    ║
║        ║ A  │ U  │ I  │ E  │ ;  ║ C  │ T  │ S  │ R  │ N  │ M  │ Ç  ║    ║
║  CAPS  ║   æ│   ù│   ¨│   €│ , ’║    │    │    │    │    │    │    ║    ║
╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴─══─┴──┬─┴──┬─┴──┬─┴──╔═╧════╩════╣
║   ^  ║  Ê │ X  │ Y  │ À  │ :  │ K  ║ ? ¿│ Q  │ G  │ H  │ F  ║     ^     ║
║   |  ║   /│   \│   {│   }│ . …│   ~║ ' ‘│    │    │    │    ║     |     ║
╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦═════╣

Selon le corpus de Thomas Tempé, les deux caractères « ? » et « ; » ont sensiblement la même fréquence en français, il n'y a donc pas de raison ergonomique de mettre « ? » en Maj+{,} ; ce placement est probablement un héritage de l'Azerty. Je pense que cette inversion permettrait d'avoir une meilleure cohérence pour la ponctuation :

  • le point-virgule au-dessus de la virgule, les deux points au-dessus du point ;
  • ./:/,/; sous la main gauche, !/? sous la main droite ; les ponctuations courantes restent avec les voyelles sous la main gauche, comme sur le Dvorak ;

Notez que le placement de «;/:» en Maj + «,/.» est une amélioration adoptée par tous les layouts QWERTY/QWERTZ européens sur leur ancêtre américain. Kaze 12 mai 2008 à 11:58 (UTC)

PS : cette inversion améliorerait la disposition pour deux catégories de personnes :

  • les nouveaux utilisateurs fr-dvorak-bepo : un peu de cohérence ne nuit pas à l'apprentissage…
  • les utilisateurs Vim : la virgule et le point-virgule étant utilisées pour un même mode de déplacement, il faut au minimum les avoir sous la même main, et idéalement sous le même doigt. Vu qu'on a doublé l'accent grave Ascii pour les utilisateurs Emacs, ça serait bien de penser aussi aux Vimistes.

Ce n'est pas une modification fondamentale, mais puisqu'il s'agit de figer la disposition à court terme, il serait vraiment dommage de conserver des incohérences qui n'apportent rien en ergonomie. Kaze 3 juin 2008 à 23:56 (CEST)

Déplacer % en shift

Placer le % au même niveau que les chiffres car il est utilisé essentiellement après des chiffres (peut-être a-t-il une autre utilité en programmation ?). De plus on laisse une touche vide où on peut mettre :

  • La touche Compose
  • Les caractères de programmation tels que ~^`
  • Le ~ et ~
┬────┬────┬────╔═════════╗
│ 0  │ % ‰│    ║         ║
│ * ×│ = ¬│ ?  ║ <--     ║
┴──┬─┴──┬─┴──┬─╚══╦══════╣

Tiot 7 juin 2008 à 20:24 (CEST)

Oui, il est utilisé en programmation, notamment en ASP et JSP où c'est un caractère systématique (<% … %>), nettement moins dans les langages « classiques ». Kaze 16 mai 2008 à 07:55 (UTC)
Il est assez utilisé dans les langages classiques (C, C++ et Ocaml au moins) pour faire des printf. Il est alors généralement précédé d'un espace et suivi d'une lettre (parfois un chiffre). Galbolle 4 juin 2008 à 13:47 (CEST)
Je serais pas contre le mettre en Alt-Gr Pyerre 4 juin 2008 à 16:08 (CEST)
Il est aussi utilisé en Perl pour préfixer les tableaux associatifs, et dans la plupart des langages pour l'opération modulo. Laurent 18 juin 2008 à 07:25 (CEST)
Concernant la proposition de remplacement, je mettrais bien ~ en direct, je pense qu'il est aussi fréquent que ^ en programmation, mais il est un peu moins accessible que ^ sans utiliser cette touche (dans l'hypothèse où ~ en altgr-y devient mort). Ainsi on compenserait cette différence. ^ passerait en AltGr, vu que ` est intermédiaire pour l'accessibilité entre ^ et ~, il est logique qu'il soit en Shift. Galbolle 7 juin 2008 à 16:24 (CEST)
Mettre ~ mort en direct, ça peut être intéressant : ça faciliterait les « ~/ » et les « ãẽĩõũỹ », ça libèrerait AltGr+{K}, et on pourrait en profiter pour mettre mettre ¿¡ en AltGr+[=] : ça serait moins cohérent que sur {!} et {?} mais plus accessible. Dans tous les cas, je pense qu'il vaut mieux avoir les accents morts en direct et les caractères ascii en {Maj}. Kazé 9 juin 2008 à 18:38 (CEST)
┬────┬────┬────┬────╔═════════╗
│ 9  │ 0  │ % ‰~ ¡║         ║
│ / ÷│ * ×│ = ¬│ ~ ¿║ <--     ║
┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
Mise à jour : notez le conditionnel SVP ! À titre personnel, ^`~ me conviennent très bien là où ils sont (sur [YTB]), si ce n'est que je préfèrerais avoir une certaine cohérence pour `~ (accent mort en direct, accent ascii en Shift). Je trouve les ^` ascii en [)=] inutiles et source de confusion. Je pense que l'idée du % en Maj se défend (ne serait-ce que pour insérer facilement un espace insécable entre un nombre et %), mais la pire solution pour moi serait d'avoir une touche ^`~ en [=] : à ce compte-là je préfèrerais une touche ~¡¿, en remplacement (et non en plus) des positions actuelles de ~¡¿. Kazé 10 juin 2008 à 00:28 (CEST)
Mise à jour bis : après avoir pesé les arguments de Galbolle (point suivant), je pense que la façon la plus simple de mettre % en Shift serait une inversion %/^. Mettre ~ en AltGr+[=] n'aurait aucun intérêt par rapport à AltGr+[B], donc la seule alternative réaliste serait de le mettre en direct et de passer ^ en AltGr. Ceci dit, je ne suis pas sûr que le ~ ascii en direct sur [=] faciliterait tant que ça les « ~/ ». Kaze 12 juin 2008 à 22:50 (CEST)
┬────┬────┬────┬────╔═════════╗       ┬────┬────┬────┬────╔═════════╗
│ 9  │ 0  │ % ‰`  ║         ║   ou  │ 9  │ 0  │ % ‰`  ║         ║
│ / ÷│ * ×│ = ¬│ ^  ║ <--     ║       │ / ÷│ * ×│ = ¬│ ~ ^║ <--     ║
┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣       ┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
% en direct me paraît beaucoup plus logique que ~ en direct…
Pour ce qui est des chiffres, % reste en direct avec un CAPS : 18,4% s'écrit TRÈS simplement avec un appui pralable sur CAPS LOCK.
Dans la foulée, ça répond aussi aux chiffres en direct. Pas pour la v1, ce n'est pas bloquant (grâce au CAPS). Asr 18 juin 2008 à 15:17 (CEST)
Asr a raison : à partir du moment où on admet qu'il faut recourir au CAPS pour les nombres, mettre le % en Shift n'a aucun intérêt. Et ceux qui bricolent le xkb pour avoir les chiffres en direct (ex : moi-même) n'ont aucun intérêt à avoir le % en Shift non plus. Autrement dit, dans les deux cas, le % est mieux en accès direct, CQFD. Kaze 24 juin 2008 à 14:22 (CEST)

` et ^

Ces deux caractères sont spécifique de certaines utilisation. On les trouve pourtant à plusieurs endroits sur la carte. Peut-être y-a-t-il une optimisation à réaliser ? Nemolivier 7 juin 2008 à 19:31 (CEST)

Si on se dirige vers une touche compose sur le clavier (par exemple en %), on peut en faire une touche avec ` ^ et ~ pour les linuxiens qui ont déjà un compose ailleurs. Ce sont a priori eux qui sont concernés par les « utilisations spécifiques » où il est nécessaire que ces caractères soient accessible sans touche morte. Galbolle 8 juin 2008 à 17:56 (CEST)
Je ne vois ^ (ascii) qu'une fois sur la disposition. ` (ascii) est effectivement présent deux fois. ~ serait présent deux fois si on le met sur %. Il y a deux logiques pour placer ^ ~ et ` ascii: en shift au-dessus de la version morte, ou ensemble en %. Si on privilégie cette solution, on peut libérer les emplacements en altgr + shift + ` et altgr + shift + k. À mon sens, on peut mettre ces touches loin car d'une part on a les versions mortes pas mal placées, et d'autre part, quand on a besoin des versions ascii, ça n'est pas dans le flot de la frappe. Galbolle 8 juin 2008 à 18:08 (CEST)
Je crois que la seule raison qui nécessite d'avoir `/^/~ ascii ailleurs qu'en AltGr, c'est les raccourcis Ctrl+{`/^/~} d'Emacs. Or, des touches comme {ÀÉÊÈÇ} sont très accessibles (bien plus que Maj+{%/=}) et inutilisées sous Emacs. Il suffirait qu'un Emacsien fasse un fichier de configuration du type :
Ctrl+À  <=>  Ctrl+~   " mieux que Ctrl+Shift+AltGr+{~}
Ctrl+È  <=>  Ctrl+`   " mieux que Ctrl+Shift+{%}
Ctrl+É  <=>  Ctrl+^   " mieux que Ctrl+Shift+{=}
Sorti d'Emacs je trouve que le gain en confort est faible voire nul : je préfère faire {^}{Espace} plutôt que Maj+{=}. On ferait mieux de regrouper les accents {`^~} (morts et ascii) sur trois touches, quitte à réserver [=] pour l'accent grave ou le tilde. Kaze 9 juin 2008 à 18:05 (CEST)
D'accord avec toi sur l'utilisation dans emacs, sous réserve que l'on puisse faire la manip que tu préconises (je vais vérifier, là comme ça je ne suis pas sûr de voir… je suis même assez pessimiste sur l'existence d'une solution propre). Ta proposition de trois touches «accent mort - accent ascii - ? - ? » suppose de trouver une touche complète pour `, je n'ai pas trop de candidat. Ça s'intégrerait mieux au bépo-intl qui a déjà un accent grave mort en direct. Mais j'aime bien la touche consacrée à ~, qui est le parent pauvre des trois. Note que ~ est mais aussi celui dont les francophones au moins un peu geek utiliseront plus la version ascii que la version morte.Galbolle 9 juin 2008 à 19:22 (CEST)
Je trouve complètement ridicule de mettre ~ en accès direct tandis que % qui n’est nulle part ailleurs se retrouve en Maj. J’utilise le ~ dans vim pour changer la casse, je le fait avec AltGr+Maj sans difficulté majeur et je ne vois pas l’intérêt d’aller le mettre là haut. N’avons nous rien d’autre à mettre sur une touche aussi éloignée ? Nemolivier 9 juin 2008 à 23:02 (CEST)
Je viens de me rendre compte que Galbolle a raison sur toute la ligne : la logique de « placer ^/~/` ascii en shift au-dessus de la version morte » ne tient pas, ne serait-ce que pour le circonflexe. Par ailleurs, il semble bien qu'on ne peut pas configurer de Ctrl+{lettre accentuée} dans Emacs ni dans Vim (ou alors, pas facilement), et j'imagine que ça sera le cas dans d'autres applications : mon argument précédent ne tient pas.
Du coup, puisqu'il faut au moins un ^ ascii quelque part, l'idée de « placer ^/~/` ascii ensemble en {%} » me paraitrait judicieuse pour faire quelque chose comme ça :
  • % en Shift+{=} — cf. la proposition précédante
  • ^/~/` ascii sur une touche « prog » en [=] — resterait à déterminer l'accès : qui va en direct, en AltGr, en Shift ?
  • `/~ morts en AltGr+{È/B} :
    • soit on supprime les `/~ ascii de ces touches (=> deux emplacements libres pour des diacritiques morts ?)
    • soit on les laisse en doublon sur Shift+AltGr (i.e. on inverse ~ mort/ascii) — les doublons saymal ou pas ?
Kaze 12 juin 2008 à 20:08 (CEST)

AltGr symétrique

Récupérer sur PC un accès aussi bon que sur Mac aux symboles en AltGr à droite.
Cette amélioration pourra aussi permettre un meileur placement de certains symboles courants.

┣━━━━━━╋━━━━┷━┳━━┷━━━━╅────┴────┴────┸────┴──┲━┷━━━━┷┳━━━┷━━┳━┻━━━━┳━━━━━━┫
┃      ┃      ┃       ┃ E. ins.  E. ins fine ┃       ┃      ┃ WinG ┃      ┃
┃ Ctrl ┃ Alt  ┃ AltGr ┃ Espace        _      ┃ AltGr ┃ WinD ┃ Menu ┃ Ctrl ┃
┗━━━━━━┻━━━━━━┻━━━━━━━┹──────────────────────┺━━━━━━━┻━━━━━━┻━━━━━━┻━━━━━━┛
Cette proposition n'est pas compatible avec tous les types de claviers que l'on veut supporter. Si on veut un altgr symétrique il faut déplacer beaucoup d'autres éléments, donc pas envisageable dans le cadre de la v1. Crako 18 juin 2008 à 14:34 (CEST)
Apparemment, seul le type 3 manque de la touche Menu. Quels sont les portables qui ont ce type de clavier ? Je demande à voir, je n'en ai encore jamais vu jusqu'à maintenant. Laurent 19 juin 2008 à 08:17 (CEST)
 Le Dell latitude D630 ? Asr 26 juin 2008 à 12:42 (CEST)
Ce n’est pas qu’une question de faisabilité… là encore ça entraînerait énormément de changements (y compris les chiffres) et il nous faudrait un an minimum, en accélérant le rythme, pour régler ça. Nous nous heurterions, encore et toujours, aux limites de la v1. Il faudrait tout refaire. Ça à un nom… ça s’appelle une V2 !Nemolivier 19 juin 2008 à 10:43 (CEST)
J'utilise le Bépo notamment sur un portable IBM X31, qui n'a ni touches windows ni menu... si je passe l'Alt de gauche en AltGr, je n'ai plus de touches Alt :-( fredb 25 juin 2008 à 07:44 (CEST)
Moi j'utilise un portable qui dispose de toutes les touches d'un clavier étendu, sauf le Win de droite. Et j'ai besoin d'au moins une touche Win : j'utilise exclusivement Windows sur mon portable et les raccourcis avec la touche Win me sont fort utiles.
Tohuvabohuo 25 juin 2008 à 14:33 (CEST)
Même problème pour moi sur l'eeePC : avec l'AltGr symétrique, je perds le Alt normal. Flocondeneige 26 juin 2008 à 10:26 (CEST)

Sinon, n’oublions pas qu’a peu près tous les claviers existant disposent une touche dangereusement trop accessible pour l’usage qui en est fait : le caps lock ! Seule la réaffectation en modificateur rend cette touche à la fois inoffensive et utile. Existe-t-il des claviers ou ce genre de réglage pose problème ? (théoriquement, les modificateurs ne sont pas câblés comme des touches normales, mais pour l’instant, je n’ai constaté de problème nulle part)--Aldoo 26 juin 2008 à 12:15 (CEST)

Le caps lock m'est très utile, pour les chiffres bien sûr ! Asr 26 juin 2008 à 12:42 (CEST)

Propositions sans impact sur la carte simplifiée

Ajout de la virgule souscrite morte en AltGr+Maj.+clavier bépoÇ

Contre-proposition : utiliser la touche morte ogonek pour la virgule souscrite. Ces deux diacritiques (virgule souscrite / ogonek) me semblent suffisamment proches pour ne pas nécessiter une touche morte supplémentaire. De plus, l'ogonek ne s'applique qu'aux voyelles, tandis que la virgule souscrite ne concerne que les consonnes :

  • Șș et Țț en Roumain (à ne pas confondre avec Şş et Ţţ qui sont des cédilles)
  • Ģģ Ķķ Ļļ Ņņ en Letton (fait habituellement avec la cédille morte, mais qu'on pourrait faire aussi avec l'ogonek)

Avantage : pas de modification de la disposition, une mise à jour du pilote suffirait. Kaze 29 avril 2008 à 11:16 (UTC)

C'est effectivement possible, mais ça reste deux diacritiques différents. Et comme la position Shift + Alt Gr + {Ç} est libre, et que la virgule souscrite se rapproche plus de la cédille que de l'ogonek, il me semble adéquat de la placer là. Tohuvabohuo 29 avril 2008 à 12:45 (UTC)
Quant aux Ģģ Ķķ Ļļ Ņņ du letton, on peut éventuellement les dupliquer sur la touche morte virgule souscrite en les laissant sur la cédille. Tohuvabohuo 29 avril 2008 à 12:47 (UTC)

Ajout de touches mortes pour l'alphabet phonétique international

On pourrait peut-être imaginer un système avec une seule touche phonétique, qui pourrait être suivie de plusieurs caractères. Je propose de calquer le comportement de cette touche le plus possible sur le X-SAMPA (un système d'« ASCIIification » de l'API assez répandu). Plus de détails ultérieurement. Tohuvabohuo 6 mai 2008 à 14:34 (UTC)

J'ai bien peur que ça ne soit pas si simple, loin de là, au vu du nombre de caractères de l'API. Je ne suis même pas sûr qu'une touche Compose et un fichier ~/.XCompose associé suffisent. Sous Linux, la saisie de caractères IPA se fait via un assistant de saisie type UIM ou Scim. Kaze 3 juin 2008 à 23:20 (CEST)

Ajout du s long « ſ » en Shift + Alt Gr + {C}

Permettrait de supprimer le ß qui est une ligature du ſ et du s. Asr 30 avril 2008 à 14:12 (UTC)

Pourquoi supprimer « ß » ? Laissons-le où il est tant qu'on n'a pas intégré de touche Compose. Tohuvabohuo 30 avril 2008 à 14:53 (UTC)
Le Eszett n'est pas qu'une ligature « ſs » ou « ſz », et contrairement au S long (qui a quasiment disparu) c'est une lettre *très* courante en allemand. Puisqu'elle n'a pas de forme majuscule, je trouverais logique de mettre le s long en Shift+AltGr+{S}, mais il ne faut surtout pas supprimer « ß ». Kaze 1 mai 2008 à 20:27 (UTC)
Je suis tout à fait d'accord : gardons le « ß ». Toutefois, il me semble qu'il n'est plus utilisé officiellement en Suisse alémanique. Il ne figure même pas sur les claviers suisses allemands. Tohuvabohuo 6 mai 2008 à 14:26 (UTC)
Le Œ et Æ ne figure pas sur les claviers Français ce n'est pas pour cela qu'ils ne sont pas utilisés. Donc le critère de figuration sur un clavier n'est pas un bon critère.Tiot 14 mai 2008 à 09:16 (UTC)
http://fr.wikipedia.org/wiki/%C3%9F#Orthographe_allemande
« La Suisse et le Liechtenstein avaient supprimé complètement l'usage du ß dès la première moitié du XXe siècle et utilisent ss dans tous les cas. »
C'est un bon critère, ça ?
Tohuvabohuo 16 mai 2008 à 22:31 (UTC)

Il existe un nouveau caractère pour la capitale de ß : « Uppercasing U+00DF ( ß ) LATIN SMALL LETTER SHARP S to the new U+1E9E LATIN CAPITAL LETTER SHARP S » d'après unicode 5.1. Il est probable que les polices ne le gèrent pas avant un bon moment. A2 3 juin 2008 à 19:14 (CEST)

Initialement, j'avais proposé Shift + Alt Gr + {S} pour cette lettre, mais la mettre en Shift + Alt Gr + {C} permettrait de libérer Shift + Alt Gr + {S} pour le « ß » majuscule (voir ci-dessous). Tohuvabohuo 4 juin 2008 à 11:37 (CEST)
<update>Code2000 l'a déjà intégré. Tohuvabohuo 25 juin 2008 à 14:37 (CEST)</update>

Ajout du ß majuscule

Ajouter ẞ (U+1E9E, LATIN CAPITAL LETTER SHARP S) en Shift + Alt Gr + {S} et chercher une autre place au s long mentionné ci-dessus.

Le ß capital est une curiosité Allemande et elle est présente dans (presque ?) aucune police de caractère. (voir Capital ß et Proposition à unicode). Quel intérêt a un clavier Francophone de pouvoir taper un caractère Allemand tout nouveau (avril 2008) qui ne s'affiche pas ?Tiot 4 juin 2008 à 09:04 (CEST)
Il y a quelques années qu'on parle de cette majuscule en Allemagne, Unicode lui a alloué (définitivement) un point de code, et il ne reste plus qu'à l'ajouter à quelques polices de caractères libres pour pouvoir l'utiliser, ce qui sera peut-être fait avant la commercialisation des premiers skins bépo par TypeMatrix.
Et puis, ne serait-ce pas dommage de déroger au principe « majuscule en Shift + minuscule » pour une seule lettre pour cause de rareté récente ? Tohuvabohuo 4 juin 2008 à 11:52 (CEST)
La majuscule du ß n'existe pas c'est un ß capitale (majuscule) la différence est subtile mais existe. Pour les polices à première vue il y en a police avec ß capitale dont le Linux Libertine. Le ß capitale n'est utile que pour les Allemands qui écrivent en capitale et veulent une typographie très soignée. Je préfère largement avoir un S long à une place logique qu'un caractère Allemand inutilisé.Tiot 4 juin 2008 à 14:30 (CEST)

Ajout du « ™ » sur AltGr+Maj.+ R

Si j’en crois wikipédia, le symbole « ™ » serait plus recommandé dans certain cas que le « ® » pour indiquer qu’une marque est enregistrée. C’est un tout petit ajout… sur le xkb il suffit de mettre « trademark » à l’endroit opportun.

Le code utf que j’avais trouvé n’est pas le bon… si quelqu’un le connaît, nous irons l’ajouter sur la page wikipédia. Nemolivier 14 mai 2008 à 07:38 (UTC)

Sous Linux / xkb ce caractère est nommé « trademark », ça me fait un U+2122 dans ma console. Kaze 14 mai 2008 à 20:44 (UTC)

Ajout du « ≠ » en AltGr+{=}

et déplacement du « ¬ » en AltGr+{6}, la place étant libre depuis la version 0.6.6 :

┬────┬────┬────┬────┬────┬────┬────╔════════╗
║ 6  │ 7  │ 8  │ 9  │ 0  │ ^  │ `  ║        ║
║ @ ¬│ + ±│ - −│ / ÷│ * ×│ = │ %  ║ <--    ║

Kaze 11 juin 2008 à 11:03 (CEST)

Alt Gr + {L}, « = » me paraît plus adéquat. Tohuvabohuo 17 juin 2008 à 17:23 (CEST)
Il est déjà sur cette combinaison et il n’est pas question de l’en retirer. Je pense que cette proposition est liée au fait que ça s’enchaînerait bien avec les autres signes mathématiques ÷×±. Nemolivier 17 juin 2008 à 17:33 (CEST)
Il y a effectivement un souci de cohérence dans cette proposition, mais c'est aussi pour avoir le « ≠ » sous Linux sans toucher au fichier ~/.XCompose que je suggère cette modification. Ça ferait une deuxième façon (plus simple) pour produire un « ≠ », de même qu'on a deux façons de faire un « ù ». Kaze 19 juin 2008 à 13:25 (CEST)

Inverser tilde ascii et tilde morte

L'idée est d'inverser la tilde morte avec la tilde non morte. Je propose de revoter cette proposition car l'inversion ` et ` est passée. Du point de vue de la charge mentale il est logique d'avoir le même comportement entre les touches mortes.

Le ~/ très utilisé sous Linux sera toujours accessible via ~+/. Ce qui revient à faire exactement la même chose qu'avant l'inversion.

Proposition à part : On pourrait ajouter le ≃ en ~ + -, le ≈ en ~ + =, ≲ et ≳

On pourrait aussi ajouter ¿ en ~ + ?, et ¡ en ~ + ! Kaze 3 juin 2008 à 18:47 (CEST)
D'un autre côté, ~ ascii est un caractère relativement courant dans les «utilisations techniques», notamment pour faire des insécables en latex. Bien plus que ` ascii. Dans la mesure où ce n'est pas un caractère nécessaire pour taper en français, et où on a déjà ñ sur le clavier, est-ce bien judicieux de sacrifier le caractère ascii. Pour apaiser les bretonnants et lusophones, je propose ~ mort en altGr-n, et ~ ascii en altGr-k. ñ garde la même accessibilité, et ~ mort est un peu mieux qu'en K (à vérifier). Galbolle 24 juin 2008 à 22:50 (CEST)

Passer les guillemets anglais « “ » et « ” » en AltGr+Maj.+« et AltGr+Maj.+»

┌────┬────┬────┬────┬────┬────┬
│ # ¶│ 1 –│ 2 │ 3 │ 4  │ 5  ║
│ $ §│ " —│ « <│ » >│ ( [│ ) ]║

Et supprimer « ≤ » et « ≥ », ou les mettre à la place actuelle des guillemets anglais. Glehmann 18 mai 2008 à 16:58 (CEST)

Nemolivier me fait remarquer que “” sont aussi les guillemets de second niveau du français, par exemple : « Kazé dit “je ne sais pas” ». À ce titre, il serait d'autant plus cohérent d'avoir “” sur les mêmes touches que «». Kaze 4 juin 2008 à 01:58 (CEST)

Ajouter le guillemet ouvrant allemand « „ »

  • En clavier azertyAltGr-clavier azertyMaj-clavier azerty1, en supprimant le demi-cadratin.
    Avec la proposition au dessus, on aurait les guillemets allemands côte à côte et dans le bon ordre. C'est la solution qui donnerait la meilleure cohérence, les 6 guillemets doubles étant regroupés sur 3 touches.
┌────┬────┬────┬────┬────┬────┬
│ # §│ 1 │ 2 │ 3 │ 4  │ 5  ║
│ $ │ " —│ « <│ » >│ ( [│ ) ]║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║  |<-  ║ B ¦│ É ˝│ P │ O Œ│ È  ║
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║
  • En clavier azertyAltGr-clavier azertyMaj-clavier azerty$, pour préserver le demi-cadratin : « ¶ » passe en clavier azertyAltGr-clavier azertyMaj-clavier azertyP (Paragraphe)
┌────┬────┬────┬────┬────┬────┬
│ # │ 1 –│ 2 │ 3 │ 4  │ 5  ║
│ $ §│ " —│ « <│ » >│ ( [│ ) ]║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║  |<-  ║ B ¦│ É ˝│ P │ O Œ│ È  ║
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║
  • Ailleurs…

Kaze 4 juin 2008 à 01:54 (CEST)

Ajouter les guillemets de second niveau anglais sur une paire de doigts

En AltGr Maj {Y} et {À}. C’est la même paire de doigts que les autres quillemets.

╠══════╦═╝──┬─┴──┬─┴──┬─┴─══─┴──┬─┴──┬
║   ^  ║ Ê  │ X  │ Y │ À │ : ·│ K ˜║
║   |  ║ ê /│ x \│ y {│ à }│ . …│ k ~║
╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧

Si cette proposition est acceptée, je propose que le « ’ » reste à sa place actuelle sur {,} en tant qu’apostrophe typographique, mais que le {’} ne reste pas sur {'} pour ne pas encombrer inutilement. Nemolivier 7 juin 2008 à 19:06 (CEST)

Ou à la place des actuels guillemet anglais de premier niveau :

┌────┬────┬────┬────┬────┬────┬
│ # §│ 1 │ 2 │ 3 │ 4 │ 5 ║
│ $ │ " —│ « <│ » >│ ( [│ ) ]║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║  |<-  ║ B ¦│ É ˝│ P │ O Œ│ È  ║
║  ->|  ║ b |│ é ´│ p &│ o œ│ è `║

Gaëtan 13 juin 2008 à 19:24 (CEST)

Compose

Ce vote à déjà eu lieu sans qu’une proposition intéressante soit faite pour l’emplacement. Des discussions sur IRC sont apparues deux propositions. Je ne sais pas si ça rend cette proposition plus valable pour la 1.0.

  • Compose sur AltGr Maj {X}
  • Compose sur [=] dans la mesure ou il y aurait une réorganisation des `, ^, % et ‰

Nemolivier 7 juin 2008 à 19:31 (CEST)

Je suis contre l'utilisation de Compose dans une disposition de clavier, pour plusieurs raisons :
  • ça va être merdique à implémenter sous Windows™ et MacOS™ : les empilements de touches mortes c'est bien beau, mais s'il faut retranscrire tout un fichier ~/.XCompose sous cette forme, on n'a pas fini de rigoler.
  • sous Windows™ et MacOS™ toujours, on n'a toujours pas d'implémentation de ce procédé. J'attends de voir un pilote permettant d'implémenter une touche Compose qui fonctionne dans toutes les applications (y compris Word™) sans ralentir la machine hôte.
  • sous Linux, la touche Compose est prévue pour être indépendante de la disposition de clavier, et est définie directement dans /etc/X11/xorg.conf avec une ligne du type :
       Option "XkbOptions" "compose:rwin"
Je pense que le choix d'utiliser ou non une touche Compose devrait être laissé au seul utilisateur. Comme beaucoup de Linuxiens j'ai mon propre fichier ~/.XCompose, fait pour mes besoins propres, et je ne vois pas pourquoi la disposition de clavier devrait venir se mêler de ça. Concentrons-nous sur ce qui est implémentable proprement sur *toutes* les plate-formes ! Kaze 7 juin 2008 à 20:44 (CEST)
je suis assez sensible à cet argument. Nemolivier 7 juin 2008 à 20:58 (CEST)
En même temps, j’ai la touche morte dans mon xkb — il faut mettre « Mult_Key », et ça semble fonctionner, le fait que ce puisse être fait dans le xorg.conf n’interdit pas de le faire dans le xkb (c’est peut-être même plus propre puisque ça permet que le compose soit différent fonction de la disposition utilisée). Quoi qu’il en soit peut-être la proposition de mettre un compose en Maj+AltGr+X permettrait de contenter les linuxéens pour lesquels ce mécanisme et cette touche sont familiers, sans prendre une place primordiale pour les autres système qui n’en profitent pas. Certes ce n’est pas une accessibilité géniale, mais rappelons qu’avec le bépo de nombreux symboles sont accessibles par un autre mécanisme que compose et qu’on peut donc supposer que l’usage de cet touche perde de l’importance. Nemolivier 9 juin 2008 à 17:51 (CEST)
Quitte à utiliser un « Mult_key » en Maj+AltGr, est-ce qu'il ne vaudrait pas mieux utiliser Maj+AltGr+{Espace} ? Au moins, ça s'enchaînerait bien avec toutes les combinaisons. Kaze 9 juin 2008 à 19:47 (CEST)

Ajouter U+0309, diacritique crochet en chef

Ajouter U+031B, diacritique cornu

Ajouter U2248, « almost equal to »

Une bonne position, pour ce signe relativement rare, serait clavier bépo~ clavier béposigne égal Asr 30 juin 2008 à 15:31 (CEST)

bépow

Possibilité offerte aux utilisateurs, en plus du bépo classique, d’un bépo international désigné sur le wiki sous le nom de bépo-intl ou bépow. Ceci permettrait de répondre à la demande — fréquente pour nos utilisateurs actuels, souvent informaticiens — de pouvoir écrire en anglais plus facilement. Le but de cette version est qu’elle « colle » le plus possible à la version officielle du bépo pour que le passage de l’un à l’autre se fasses sans heurts. Cette version n’est donc pas l’occasion de re-proposer des choses tel que le AltGr symétrique ou autres… Nemolivier 8 juin 2008 à 11:41 (CEST)

Normalisation par étapes

Certains caractères présent sur le clavier, comme ¬, ſ et autres ne sont indispensables ni à la typographie d'une langue européenne, ni à l'usage informatique. Sans qu'il soit nécessaire de les retirer des pilotes, on pourrait envisager le système suivant: on normalise le bépo avec des emplacements vides là où sont actuellement ces caractères, mais en indiquant dans la norme que ce sont les caractères recommandés pour ces emplacements. Cela permet d'adapter le bépo à des usages pour lesquels des caractères non présents sur notre version du clavier seraient nécessaires.

Pour aller plus loin, on pourrait rendre "facultatifs mais encouragés" les caractères non-ascii non-francophones, par exemple pour faire des variantes adaptées aux pays africains, avec les caractères spécifiques des autres langues de ces pays pas trop inaccessibles. De telles variantes seraient « non-officielles mais compatibles »

+1, je serais même d'avis d'aller plus loin dans cette logique.
Je trouve que les touches mortes telles que la grecque ou la monétaire ne devraient pas figurer dans une version officielle : elles sont merdiques à implémenter sous Linux du fait qu'elles reposent sur une modification du comportement de Compose — le bépo étant, à ma connaissance, la seule disposition de clavier qui requière un tel mécanisme.
En clair, je pense qu'on devrait se contenter de normaliser la carte simplifiée. Kaze 12 juin 2008 à 09:50 (CEST)
Je dirais un tout petit peu plus que la carte simplifiée : je pense qu'on devrait ajouter le demi-quadratin et l'apostrophe courbe: on arriverait à une définition de carte simplifiée qui serait : « tous les caractères nécessaires pour bien taper le français plus tous les caractères ascii imprimables». D'ailleurs si les canadiens utilisent ¢ pour le cent, on pourrait peut-être aussi l'inclure dans cette carte simplifiée. Sinon, entièrement d'accord, à condition de bien préciser que le contenu des autres emplacement est recommandé. Galbolle 13 juin 2008 à 10:18 (CEST)
Tout à fait d'accord. Cela rejoint parfaitement le discours que j'ai déjà plusieurs fois tenu. Une carte avec les caractères nécessaires au Français pour la norme, puis des annexes précisant des recommandations pour le remplissage des trous. Rideĉjo 17 juin 2008 à 14:38 (CEST)
Dans la même veine, faut-il normaliser le comportement de caps-lock ? Son utilisation, que ce soit comme shift-lock ou comme caps-lock est très mineure. En ne normalisant pas, on permet des drivers non officiels avec un comportement de caps-lock plus utile. Par exemple un altgr symétrique, ou un programmer-lock donnant accès aux symboles courants de programmation exilés un peu loin. (Bien sûr cette proposition ne nous engage pas à implémenter ni le altgr symétrique, ni le programmer-lock)Galbolle 26 juin 2008 à 12:26 (CEST)
Pour en rajouter encore une couche, la touche {ê} est-elle vraiment très utilisée ? (moi je ne m'en sers jamais) Comme elle n'est pas disponible sur certains claviers, ne pas la normaliser ajoute une certaine liberté pour ceux qui ont des besoins exotiques.Galbolle 27 juin 2008 à 16:13 (CEST)

Chiffres en direct

Bon, je ne suis pas venu depuis un petit moment. En fait, la liste de diffusion a cet avantage de me rappeler régulièrement de venir voir ce qui se passe. Avec la grosse panne, j'ai « oublié » de venir pendant longtemps.

Depuis le temps qu'on en parle et que personne ne le propose vraiment pour les votes, je suggère de faire une proposition avec les chiffres en accès directs. Cela implique beaucoup plus que d'échanger simplement les chiffres avec les caractères qui sont dessous, alors je laisse à ceux qui ont des idées sur le sujet (ceux qui ont déjà fait des propositions dans ce sens) continuer cette discussion. Rideĉjo 17 juin 2008 à 14:36 (CEST)

Cette proposition ne doit pas être faites pour la version 1.0. Comme tu le dis les changements que cela entraînerait sont trop nombreux. Ce doit être reporté à la v2. Nemolivier 17 juin 2008 à 14:42 (CEST)
Je ne suis pas d'accord. La version 1.0 sera la dernière, il n'y aura donc pas de possibilité de faire cette proposition pour une autre version, si on ne s'en occupe pas maintenant.
Je pense que peu de gens franchirons le pas pour passer de l'AZERTY au BÉPO, alors si en plus il faut ensuite passer d'une version 1.0 à une version 2.0, cela ne peut intéresser que les Geeks. Cette proposition de chiffres en direct me semble très importante, et elle ne l'est pas qu'a mes yeux, si j'en juge par les commentaires que l'on a eu à chaque fois qu'on en a parlé. Je pense donc qu'elle doit être étudiée pour la version 1.0, quitte à en retarder la sortie. Rideĉjo 18 juin 2008 à 09:30 (CEST)
Rien n’indique que la version 1 sera la dernière. Si la v2 n’intéresse que les geeks, ça tombe bien : ce sont les geek qui veulent les chiffres en direct (de fait, ça correspond à leur usage). Les commentaires que nous avons eu lors des discussions sur le sujet allaient dans les deux sens. Y compris des personnes qui ne savaient pas ce qui était le mieux. Si il y avait eu tant de personnes pour qui cette proposition était importante, évidente ou si facilement « réglable », sans doute aurions-nous eu un vote (on a bien eu un vote pour une touche « où »). Encore une fois, si c’était clairement justifié, consensuel et facilement intégrable, très bien. Ce n’est pas le cas. Nemolivier 18 juin 2008 à 23:22 (CEST)
« ce sont les geek qui veulent les chiffres en direct (de fait, ça correspond à leur usage) »
Non. Je pense au contraire que ce sont les travailleurs qui en ont besoin, pour exprimer des dates, des quantités ou des montants, dans leur documents Word™ ou dans leurs courriels : « RdV le 15.07.2008 à 15h en salle 3b », « Règlement des 3 840,43 € correspondant aux 30 % d'avancement », etc. À moins d'être auteur dramatique, les chiffres en direct sont une nécessité dans le cadre professionnel. Par ailleurs, on n'utilise que très rarement plusieurs caractères tels que "<>()_+-/* à la suite, contrairement aux chiffres ; on pénalise donc fortement l'utilisation professionnelle pour une faible amélioration en utilisation littéraire. Le pavé numérique n'est pas une solution non plus : on perd la position dactylo, c'est déjà nul en Azerty, mais alors pour une disposition qui se veut ergonomique…
L'Azerty est une des très rares dispositions à ne pas avoir les chiffres en direct, mais c'est pour une bonne raison : la plupart des caractères accentués sont sur la rangée des chiffres ; il me semble que le projet Bépo a fait le choix des chiffres en Shift pour de bien mauvaises raisons : héritage de l'Azerty, pas ou peu d'utilisation dans le cadre professionnel, corpus pas représentatif, système de vote, toussa.
Quoiqu'il en soit, je suis entièrement d'accord avec Nemolivier pour dire qu'il est trop tard pour changer ça avant la release 1.0 — ne serait-ce qu'à cause de l'emplacement du tiret. Gardons ça pour la v2, qui sera, je l'espère, une disposition plus polyvalente que la v1.
Kaze 19 juin 2008 à 11:32 (CEST)

<> en shift = et %

Discuter:Version_0.6.5/Archive#Place_des_guillemets_fran.C3.A7ais

Voilà dans ce fil de discution il y a une personne qui propose de placer <> en shift = et %. Comme il y a eu beaucoup de critiques contre la place actuelle des <> je me demande si ça ne peut pas plaire à pas mal de gens. Les <> seront à mon avis moins accessible mais ils seront en shift et le </> sera plus facile. On pourrait aussi en profiter pour ramener les guillemets simples avec les autres guillemets. J'utilise très peu les <> mais j'aime bien cette solution car elle permet la création de touches guillemets. Avis des utilisateurs de <> ?

┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔═════════╗
│ # ¶│ 1 –│ 2 ‘│ 3 ’│ 4  │ 5  ║ 6  │ 7 °│ 8 ′│ 9 ″│ 0  │ < ≤│ > ≥║         ║
│ $ §│ " —│ « “│ » ”│ ( [│ ) ]║ @  │ + ±│ - −│ / ÷│ * ×│ = ¬│ % ‰║ <--     ║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣

Tiot 27 juin 2008 à 09:39 (CEST)

Ça me semble une bonne idée, en profiter pour mettre le guillemet ouvrant allemand (voir plus haut) et rajouter le guillemet simple ' en AltGr + Maj + ["] permettrait une cohésion des guillemets intéressante.
J'ai déplacé les caractères en AltGr de ["] vers [@] par défaut : la place était libre.
┌────┬────┬────┬────┬────┬─–───┬────┬────┬────┬────┬────┬────┬────╔═════════╗
│ # ¶│ 1 '│ 2 ‘│ 3 ’│ 4  │ 5  ║ 6 │ 7 °│ 8 ′│ 9 ″│ 0  │ < > ║         ║
│ $ §│ " │ « “│ » ”│ ( [│ ) ]║ @ │ + ±│ - −│ / ÷│ * ×│ = ¬│ % ‰║ <--     ║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣
Rogdham 28 juin 2008 à 11:40 (CEST)
Je pense plutôt que ces deux touche, même en accès Maj, sont bien moins accessibles qu’en AltGr « 2 », « 3 ». Je ne vois pas en quoi les mettre loin facilite le fait de taper « <> ». À l’heure actuelle c’est AltGr mains droite puis « 23 » main gauche. C’est tout aussi bien, mieux puisque les touches sont plus proches. Nemolivier 28 juin 2008 à 13:37 (CEST)
Je teste cette disposition des touches en codant une page web à la main. Un premier bilan : je trouve que les deux dispositions des « <> » se valent à peu près, avec un léger avantage pour la disposition actuelle (0.6.6) : ça m'arrive de temps en temps de taper sur le retour arrière à la place de « > » ( [+] en azerty ), peut-être un mauvais apprentissage de cette région du clavier de ma part…
Il y a cependant la combinaison « /> » qui est plus facile : avoir l'annulaire sur {/} et le pouce sur AltGr en prévision du {>} main droite est au désavantage de la version actuelle, même c'est largement faisable. Mais cette remarque vaut pour le XML et sûrement pas en général, où l'on n'utilise rarement « / » avant « > ».
Enfin, comme je n'ai pas à taper « <> » à la suite, ça ne pose pas de problème de les avoir sous le même doigt, mais il me semble que l'on a à le faire dans certains langages de programmation.
La disposition actuelle me semble finalement meilleure, mais je n'ai sans doute pas fait le tour des arguments possibles !
Rogdham 29 juin 2008 à 10:54 (CEST)

Extension des touches mortes (Tohuvabohuo 2 juillet 2008 à 18:40 (CEST))

Voici une liste (non exhaustive) de caractères qu’on pourrait produire aisément sans chambouler tout le clavier :

  • ≁ : « / » morte + « ~ »
  • ≢ : « / » morte + « ¯ » mort + « = »
  • ≄ : « / » morte + « ~ » mort + « - »
  • ≉ : « / » morte + « ~ » mort + « ~ »
  • ≇ : « / » morte + « ~ » mort + « = »
  • ≚ : « ˇ » mort + « = »
  • ⨣ : « ^ » mort + « + »
  • ≙ : « ^ » mort + « = »
  • ⩯ : « ^ » mort + « ~ » mort + « ~ »
  • ⨪ : « ¯ » mort + « . »
  • ⌅ : « ¯ » mort + « ^ »
  • ≂ : « ¯ » mort + « ~ »
  • ∓ : « ¯ » mort + « + »
  • ≡ : « ¯ » mort + « = »
  • ⩦ : « ¯ » mort + « ¯ » mort + « . » (deux fois le « ¯ » mort ne pourrait donc plus donner le « ¯ » non mort)
  • ⌆ : « ¯ » mort + « ¯ » mort + « ^ »
  • ⩳ : « ¯ » mort + « ¯ » mort + « ~ »
  • ⩱ : « ¯ » mort + « ¯ » mort + « + »
  • ⪙ : « ¯ » mort + « ¯ » mort + « < »
  • ≣ : « ¯ » mort + « ¯ » mort + « = »
  • ⪚ : « ¯ » mort + « ¯ » mort + « > »
  • ⋮ : « ˙ » mort + « : »
  • ⩪ : « ˙ » mort + « ~ »
  • ⸞ : « ˙ » mort + « ~ »
  • ∔ : « ˙ » mort + « + »
  • ≐ : « ˙ » mort + « = »
  • ⨰ : « ˙ » mort + « × »
  • ⪁ : « ˙ » mort + « ≤ »
  • ⪂ : « ˙ » mort + « ≥ »
  • ⩧ : « ˙ » mort + « ¯ » mort + « = »
  • ⦙ : « ˙ » mort + « ˙ » mort + « : » (deux fois le « ˙ » mort ne pourrait donc plus donner le « ˙ » non mort)
  • ⩭ : « ˙ » mort + « ~ » mort + « = »
  • ⸛ : rond en chef + « ~ »
  • ⨢ : rond en chef + « + »
  • ≗ : rond en chef + « = »
  • ≃ : « ~ » mort + « - »
  • ⸟ : « ~ » mort + « . »
  • ≈ : « ~ » mort + « ~ »
  • ⨤ : « ~ » mort + « + »
  • ⪝ : « ~ » mort + « < »
  • ⪞ : « ~ » mort + « > »
  • ≆ : « ~ » mort + « / » morte + « = »
  • ≅ : « ~ » mort + « ¯ » mort + « - »
  • ⩬ : « ~ » mort + « ¯ » mort + « ~ »
  • ≊ : « ~ » mort + « ~ » mort + « - » (deux fois le « ~ » mort ne pourrait donc plus donner le « ~ » non mort, ce qui m’amène à penser que ce serait plutôt un caractère pour la touche compose)
  • ≋ : « ~ » mort + « ~ » mort + « ~ »
  • ⩰ : « ~ » mort + « ~ » mort + « = »
  • ⸚ : « ¨ » mort + « - »
Je radote… Les touches mortes c'est très bien, je trouve ça même mieux qu'AltGr pour les lettres, mais l'implémentation de ce genre de combinaisons est problématique :
  • sous Linux : cela suppose de modifier ou de créer un fichier ~/.XCompose, de modifier le système pour qu'il utilise ce fichier (im-switch & co), bref ça n'est pas pratique, pas accessible à tout le monde, et surtout ça n'est pas portable — ce qui est gênant tant que la dispo n'est pas figée et incluse dans Xorg ;
  • sous Windows™ : les touches mortes en cascades ne sont pas supportées, il faudrait un pilote C spécifique — comme celui qui devrait implémenter la touche Compose.
Je pense que ces caractères devraient être faits avec une touche Compose, et donc que ça devrait être indépendant de la dispo de clavier. Kaze 2 juillet 2008 à 18:53 (CEST)