Discussion:Version 0.6.6/Archive

Untitled

Cette page est en cours de nettoyage pour faciliter la lecture des avis aux votants.

Pour une bonne utilisation des pages de discussion :

• répondez à la suite (en-dessous) des précédentes contributions et évitez de les modifier ;
• créez un nouveau fil de discussion en dessous de ceux existants ;
• utilisez les deux-points « : » en début de ligne pour indenter vos réponses (plusieurs ::: pour indenter de plus en plus) ;
• signez automatiquement vos interventions en tapant ~~~~ qui sera remplacé par votre pseudo et la date après sauvegarde.

Rappel de quelques conventions utilisées sur le wiki :

• Concernant les touches de clavier :
  • « X » et X désignent le caractère X dans l’absolu. Utiliser les guillemets pour clarifier si nécessaire ;
  • {X} et clavier bépoX désignent la touche X sur la disposition BÉPO courante (syntaxe : {{touche|X}}) ou son alias {{t|X}}).
  • [X] et clavier azertyX désignent la touche X sur la disposition AZERTY (syntaxe : {{toucheA|X}} ou son alias {{tA|X}}) ;
• Les votes se font avec les modèles pour, contre et neutre (syntaxe : {{pour}}, {{contre}} et {{neutre}}).

Utilisation des pages de discussions

Lisez les recommandations en haut de cette page : il serait bien pour les autres utilisateurs qui relisent vos discussions de ne pas intervenir au milieu des contributions des autres. De plus les pages de discussions doivent servir pour commenter les articles correspondants. Si l'article n'évolue pas il n'y a pas de raison de discuter. Toutes les propositions ci-dessus sont a ajouter sur la page version 0.6.6, puis seront débattues ici (suppression, modification, ajout…). Par exemple pour la dernière remarque de Tohuvabohuo : éditer l'article, y ajouter ce point, puis s'il faut détailler ajouter en page de discussion « J'ai rajouté que l'on pouvait utiliser la touche wind pour compose car je trouve que… ». Chose à laquelle je répondrais « Oui, pourquoi pas ! Mais… ». Je met l'article à jour, en espérant qu'il se construise petit à petit par tous et non du jour au lendemain par 2-3 personnes comme on a prit l'habitude. A2 31 mars 2008 à 18:48 (CEST)

Inversions r/n et j/f

oxman : Vous l'aurez compris, on vote pour cette inversion qui revient, si elle est acceptée, à revenir aux positions d'avant pour ces touches.

Orel'jan : Note : on peut également voter contre.

Pourquoi un nouveau vote ? Car le précédent à été un peu litigieux car des personnes légitimes qui auraient pu renverser la vapeur n'ont pas pu voter (quand je dis "des", je n'en ai qu'une en tête). On redonne un vote pour donner une chance à tous et chacun de défendre son opinion.

omne : Il y en a au moins deux : A2 n’a pas voté.

omne : Et ce coups-ci on fait quoi ? On décide d’une liste de votants « nécessaires » sans qui le vote ne peut-être validé ? On interdit le vote au personnes qui n’étaient pas présent lors des x votes précédents ? On fait passer un test de compétences bépoico-biomécano-anatomico-statistico-oxmantique ? Je comprends la proposition, mais faire ce type d’exception, c’est la porte ouverte à n’importe quoi. De fait, c’est déjà un peu le cas.

oxman : Et bien c'est simple. Cette fois-ci on fait comme la fois précédente. On ne change pas le type de vote pour ne pas biaiser le vote.

omne : Quel type de vote utilisons-nous ? En quoi a-t-il été changé ? Par qui ? Porter des accusations nécessite des précisions. Et la fois précédent, c’est quel vote ? la 0.6.5 ou la 0.6.5.1 ?

oxman : Et bien, le vote standard, c'est à dire n'est pris en compte que les votes données dans le délais stipulé à l'ouverture des votes. Ce système n'a à ce jour encore jamais été changé pour les votes Dvorak bépo, et je n'ai à aucun moment sous entendu le contraire.

omne : Quel est le vote qui n’a pas suivi cette règle, puisque tu réclame « Cette fois-ci on fait comme la fois précédente » et que tu semble affirmer qu’un des votes — lequel — aurait été biaisé ? Le dernier vote a respecté cette règle, pourquoi, alors l’annuler (parce que ce que tu proposes, c’est une annulation, soyons clair) ?

oxman : Aucun, mais quand je dis "cette fois-ci", c'est parce que les prochains votes vont probablement évoluer, car on vient de s'apercevoir qu'ils peuvent être limite. Le vote qui a été biaisé c'est le dernier, ça n'est que mon avis personnel. Biaisé où pas je suis en droit de redemander un vote quoi qu'il en soit. Pourquoi je redemande un vote qui viendrait à annuler le vote précédent ? Puisque on est ici dans un système démocratique, et que l'on a le droit de demander par exemple l'annulation d'un vote précédent avec un nouveau vote. Comme ce qui a été fait ici présentement par le passé mais dans le sens inverse. A savoir proposer un vote qui n'avait pas été accepté par le passé. Et qui finalement a fini par passer. Je parle bien entendu de ce vote.

omne : Ce que je fais ici c’est discuté la raison pour reproposer le vote. Or la raison que tu évoque repose sur une règle qui est : si tel personne manque, le vote est biaisé, il faut le refaire. Je trouve que c’est une mauvaise règle, qui peut entraîner toutes sortes de dérives. Et si on accepte toute re-proposition de vote sans discussion, c’est sans fin. Ou au premier qui se fatigue. Ça manque un peu de maturité, non ?

De plus il n’est pas nouveau que le vote démocratique pose des limites. On peut décider de changer les règles : on décide d’un noyau de personne qui seul a le droit de vote, c’est un autre moyen qui n’est pas plus mauvais.

oxman : Je suis de ton avis sur les dérives, et je trouve que l'on a déjà dérivé en proposant trop de fois ce vote. Et j'ai bien trop l'impression que ce vote est passé justement à cause de ce point "au premier qui se fatigue".

omne : il n’a été que proposé 2 fois. Ça ne justifie pas ta justification pour le proposer à nouveau.

oxman : Quoi qu'il en soit, certains pensent que çà n'est pas normal de proposer le même vote sous deux formes différentes, et vu que des personnes importantes n'ont pas pu voter alors qu'elles voulaient le faire, ce vote semble justifié. Mais on peut voter pour demander l'avis des autres si tu veux, même si pour votre deuxième proposition vous nous avez pas laissé le choix.

En tant que nouvelle, est-ce que j'ai le droit de vote ? Parce que finalement, je l'aime bien, cette inversion. C'est drôlement pratique pour mon adresse @free.fr :-) Flocondeneige 27 mars 2008 à 10:31 (CET)

Sans aucune hésitation. Tout vote bienséant compte (est considéré comme malséant, par exemple, le fait de voter dix fois à la même proposition). Orel'jan 27 mars 2008 à 11:29 (CET).

Mon grain de sel... Premièrement, l'argument "au premier qui se fatigue" est absolument sans fondement : qu'une personne soit pour ou contre une modification, il n'y a absolument aucune raison pour qu'elle change d'avis juste parce qu'elle en a marre de voter (au contraire, la majorité des gens ont plutôt tendance à s'opposer au changement), ou alors c'est qu'elle n'avait pas réellement d'avis sur la question. Par contre, elle peut être convaincue par les arguments des uns ou des autres, et changer son point de vue, ou se rendre compte qu'elle n'a pas d'avis tranché autre qu'un rejet épidermique.

Deuxièmement, à partir du moment où de nouvelles personnes rejoignent le mouvement, il peut être utile de remettre en question des choix qui ont déjà fait l'objet d'un vote. Mais c'est sans intérêt si peu de temps après le premier vote, d'autant plus que les détracteurs de la position acceptée n'ont pas eu le temps de tester les gains/pertes dues à ce changement !

Enfin, une question personnelle à oxman : honnêtement, si le vote avait été dans ton sens et que les personnes auxquelles tu penses auraient pu faire basculer la balance contre ton avis, aurais-tu été si prompt à proposer un nouveau vote ?

Bref, je vote contre ce contre-vote. Attendons quelques mois pour le reproposer, en toute objectivité et avec des nouvelles têtes.

PS : D'ailleurs on a jusqu'à quand pour faire des propositions ? Skippy le Grand Gourou 27 mars 2008 à 22:00 (CET).

Il est avec fondement, parce que des gens ne revotent pas. Elles revotent pas soit parce qu'elles n'ont pas eu le temps, mais souvent parce qu'elles ne pensent pas que l'on revote sur la proposition, elles ne pensent pas avoir à revoter, et à être obligée de regarder attentivement toutes les semaines si il n'y a pas un contre vote du vote qu'ils ont déjà fait. Si ce vote - si peu de temps après le premier - est là, c'est parce que le précédent vote est passé par forcing puisque au moins une personne farouchement contre n'a pas voté parce qu'il avait des impératifs qui lui ont empêché de savoir ce que nouveau vote existait.

Non bien entendu, puisque je ne vais pas proposer quelque chose contre mon choix, c'est évident. Mais quand des personnes ont fait comme moi, j'ai dit que ça n'était pas normal, mais ça a été fait quand même, puisque pour se souvenir, le dernier vote a exactement été fait comme ça.

Et tu vas donc voter contre ce contre-vote, alors que tu ne l'as pas fait pour le précédent vote, qui était lui aussi un contre contre-vote, mais pas affiché clairement, moi au moins j'ai la franchise de mes opinions. Oxman 30 mars 2008 à 14:10 (CET).

Je ne l'ai pas fait pour le vote précédent tout simplement parce que je n'étais pas inscrit avant... Mais j'estime que lorsqu'une décision collective est prise, on devrait s'y tenir pendant au moins plusieurs mois. Remettre en cause une décision est légitime, mais pas le lendemain du vote. Skippy le Grand Gourou 2 avril 2008 à 20:28 (CEST)

Je rappelle ici que la meilleure façon de convaincre les participants de voter pour une proposition est de montrer en quoi elle est meilleure que la configuration actuelle. Pas d'écrire des tartines sur des récriminations concernant un vote précédent. Orel'jan 31 mars 2008 à 07:08 (CET).

Il me semble qu'il y a déjà eu suffisamment d'arguments pour cette inversion, par contre je n'ai pas le souvenir d'en avoir vu beaucoup contre... Il serait peut-être temps d'argumenter sur en quoi elle est mauvaise, non ? Pour ma part, le seul argument que j'aie est très subjectif : j'avais une tendance naturelle à inverser les touches n/r et ça me gênait (je n'avais pas d'avis particulier sur f/j). Skippy le Grand Gourou 2 avril 2008 à 20:28 (CEST)

Utilisateur de la 0.6.4 depuis peu avant la 0.6.5, j'avais moi aussi une tendance naturelle à taper le R à la place du N mais pas le N à la place du R. Depuis l'inversion je n'ai pas réussi à retrouver la vitesse de frappe que j'avais et qui n'était pas encore celle que j'ai en AZERTY. Particulièrement je ne vois pas ce qu'apporte l'inversion f/j : dans mon vocabulaire le f est beaucoup plus présent (en français et dans le if en programmation) et le j est quasiment absent. De plus, taper le digraphe RL me demande un effort alors que taper en 0.6.4 FR ou RJ est beaucoup plus simple et il ne me semble pas qu'il y ait de digraphe NL ou NX en français (position des lettres de l'annulaire droit en 0.6.4). Donc j'attends encore de voir ce que donnera l'inversion R/N une fois que je serais habitué par conte le F/J ne me convient pas du tout et me fait perdre du temps dans ma frappe. Roudoudou 16 avril 2008 à 06:25 (UTC)

Nous sommes bien d’accord, le F est plus courant que le J (16351 contre 8351). D’ailleurs si le F a été mis en bas, c’est justement pour être plus accessible qu’a la place qu’il occupait auparavant, en haut. En effet compte tenu de la taille du petit doigt la rangée du haut lui est plus difficilement accessible (bon, tout dépend du placement de la main, naturellement), cette taille lui permet justement de se fléchir et de trouver la touche [!] rapidement. Pour taper la ligne du haut avec le petit doigt on a tendance a bouger toute la main, je crois : c’est un mouvement moins optimisé qui déplace un peu les autres doigts. Concernant le digramme RL par rapport au NL tu as raison (647 contre 62) mais, par exemple le FR a été grandement amélioré (1266) en laissant le JN (107) pour le digramme difficile a faire ([PL]). Encore une fois, les gains de l’inversion RNJF n’ont toujours été calculés que lorsque les deux inversions sont couplées. N’en conserver qu’une des deux ne pourra être fait qu’avec démonstration et chiffres a l’appui tel que ce fut fait pour RNJF. Pour répondre à ton questionnement concernant les fréquence, c’est très simple les fréquences des touches et des digrammes (j’ai utilisé les digrammes du bas de la page) ont toujours été accessible sur le wiki. Nemolivier 16 avril 2008 à 08:02 (UTC)

Tu as raison c'est une question de placement des mains qui fait ou non bouger lors de la frappe sur [P], je n'avais pas de mal à taper FR en 0.6.4 car je levais un peu la main pour voir les touches (je ne sais pas encore taper sans parfois regarder le clavier) et car la position de ma main rapproche mon annulaire de [P]. Donc à part pour ma mémoire de l'inversion F/J et pour l'exercice de mes doigts pour aller chercher toutes les touches de la rangée du bas (pour les deux mains) ces inversions semblent être une meilleure chose que ce qu'elle me paraissait au début. S'il y a déjà eu des inversions de ce genre, quel est le délai pour s'y faire? Roudoudou 16 avril 2008 à 20:51 (UTC)

Hello, je suis nouvel inscrit bien que suivant le projet depuis quelques temps. Mon avis : l'inversion F/J ne me gêne pas outre mesure. Par contre, je trouve le R, qui me semble plus fréquent que le N, bien plus accessible avec le petit doigt. Le changement récent me gêne beaucoup. --Ploum 4 avril 2008 à 13:13 (CEST) Ploum, le Ploum ? Nemolivier

Mmmh... Ton argument pour le R/N ne joue pas en la faveur de ce que tu défends... Je pense que comme moi, la plupart des gens ont un annulaire plus mobile que l'auriculaire. Tu n'aurais pas fait du piano par hasard ? Skippy le Grand Gourou 7 avril 2008 à 22:08 (CEST)

Pfff, je fais finir par le mettre dans la FAQ : L’annulaire, de part ses muscles, ses tendons et la forme de l’interligne articulaire du carpe est le moins mobile des doigts. L’auriculaire, en revanche, a des muscles propres qui font de lui de doigts avet le plus de liberté après le pouce (et c’est normal, ils sont chacun à une extrémité de la main). En revanche, il est plus court, ce qui lui rend la rengée supérieure plus difficile d’accès (mais pour la rangée de repos et celle du dessous, pas de problèmes). Ça s’ignifie que si vous avec du mal à utiliser votre petit doigt, c’est que vous ne l’utilisez pas comme il faut : entraînez vous, il en est plus que capable. Nemolivier 7 avril 2008 à 23:56 (CEST)

Alors c'est moi qui suit pas normal, pardon. Quand je bouge l'auriculaire, l'annulaire vient avec... Met le dans la FAQ, oui. ;) Skippy le Grand Gourou 8 avril 2008 à 11:05 (CEST)

Si, si ça c’est normal, quand tu écartes l’auriculaire, l’annulaire bouge aussi un peu. Mais je ne vois pas comment tu peux en déduire que l’annulaire est plus mobile que l’auriculaire Nemolivier 8 avril 2008 à 11:58 (CEST)

Effectivement, après quelques tests j'admets avoir parlé trop vite. Les touches LR(X) sont en accès « naturel » pour l'annulaire, et les touches NMF pour l'auriculaire. Ce dernier est effectivement plus rapide dans l'absolu, par contre l'annulaire est plus fort en appui. Au final, je trouve qu'il est plus facile (selon la « dureté » du clavier, évidemment) de taper avec l'annulaire qu'avec l'auriculaire (pour les touches situées immédiatement sous ces doigts), CQFD. Skippy le Grand Gourou 8 avril 2008 à 14:03 (CEST)

Je n’ai pas de chiffres sous la main mais tu serais surpris de la force de l’auriculaire (il constitue d’ailleurs, avec l’annulaire, ce qu’on appelle la « main de force »). Ce dont je suis certain c’est que dans le cadre de l’utilisation d’un clavier ce n’est pas de force mais d’endurance et de précision qu’il s’agit, or, comme tu le notes, sur le clavier l’auriculaire a un travail plus « compliqué » puisqu’il gère plus de touches (en même temps l’annulaire en serait incapable, coincé comme il l’est). On ne peut même pas vraiment comparer ce qu’ils font. Donc… entrainement ! ;o) Nemolivier 16 avril 2008 à 08:23 (UTC)

Hello, je suis nouvel inscrit bien que suivant le projet depuis quelques temps. Mon avis : je suis pour l'inversion F/J pour cause de moyen mnémotechnique. J'associe plus facilement le F au D et le J au G et Q. Par contre, je suis contre l'inversion R/N, de nouveau par pure cause de moyen mnémotechnique, j'associe plus facilement R à S et T, et N à M. --Nickwe 4 avril 2008 à 19:25 (CEST)

Super façon de voir les choses… Tu devrais te faire ta propre disposition avec les touches dans l'ordre alphabétique. Sur le plan mnémotechnique ça sera génial. Au bout de quelques semaines d'utilisation, peut-être que tu reviendras nous voir avec une façon de penser un peu moins idiote (désolé d'allumer comme ça, mais quand je vois l'importance d'une simple voix, faudrait pas que des gens comme ça puissent voter, franchement). Florian 7 avril 2008 à 13:06 (CEST)

Ayant bien lu tous les arguments précédant, je ne vois pas en quoi les autres arguments sont meilleurs... Soit on fait de façon mathématique, scientifique et morphologique et l'on ne demande pas à l'utilisateur lambda que je suis son avis, on a une version stable et finale rapidement et tout le monde est content. Soit on discute sur chaque lettre et l'on n'en fini pas. Là on va de nouveau intervertir les lettres puis à la prochaine version il faudra revoter pour re-re-changer! Sinon je trouverais effectivement plus logique, de n'avoir droit de vote que trois mois après avoir créé son compte, mais comme la question a été posée spécifiquement et qu'il a été dit que tout le monde pouvait voter, j'utilise mon droit de vote comme bon me semble... --Nickwe 9 avril 2008 à 15:13 (CEST)

Bien sûr tu pourras le faire. On est en train d'établir la liste des propositions à voter (et non en train de voter). A2 9 avril 2008 à 17:11 (CEST)

Soyons clair : je ne crois pas qu’il ai jamais été expressément demandé aux utilisateurs lambda de voter, ni de donner leur avis s’ils ne le désirent pas. Ce projet est un projet libre et sont les bienvenus ceux qui désirent y participer, mais les simples utilisateurs ont aussi le droit d’exister, de passer nous dire bonjour, de donner un avis (ou pas), sans forcément voter. Et oui, ce projet se fonde sur des bases scientifiques, mathématiques et morphologiques et les inversions proposées aussi, il se trouve que nous faisons avec nos moyens, compétences et disponibilités, ce qui entraîne quelques contraintes. J’espère bien que les arguments que je donnes concernant, entre autre, cette inversion sont plus valables que l’ordre alphabétique. As-tu vraiment lu tous les arguments ? (wiki et liste de diffusion). Pour moi ton histoire de trois mois ne signifie rien : si un vrai ergothérapeute s’inscrit demain, il a plus de légitimité à voter qu’un simple utilisateur qui serait là depuis 6 mois. Le fait d’être utilisateur « lambda » ne donne pas un droit de vote (pas plus qu’il ne te l’enlève), il te donne le fait d’utiliser la disposition, c’est tout. La participation ici c’est autre chose. Nemolivier 9 avril 2008 à 18:57 (CEST)

Inversion RN simple

Certains retours concernant l’inversion RNFJ ne portent que sur RN ou FJ. Des utilisateurs souhaitent donc ne conserver que l’une des deux inversions. Nbrodu 17 avril 2008 à 07:49 (UTC) et Nemolivier 17 avril 2008 à 10:15 (UTC)

Inversion FJ simple

Cf inversion RN simple. Nbrodu 17 avril 2008 à 07:49 (UTC)

Inversion AU

Les statistiques préliminaires (faudrait un plus grand corpus en particulier) sont vraiment en sa faveur. Et pour avoir testé un peu, « au » vers l'extérieur n'est pas un drame. Donc je propose tant que la phase de soumission n'est pas terminée, n'étant plus là ce WE. Je serai peut-être aussi le premier à voter contre si les stats plus complètes ne confirment pas le résultat préliminaire, mais a priori il y a peu de chances. Et en attendant ça lance le débat. Nbrodu 18 avril 2008 à 16:19 (UTC)

Placement des tirets

Première proposition

• mettre « _ » sur AltGr+[Espace],
• faciliter l’accès du tiret cadratin « — » en le plaçant en accès direct sur [6],
• déplacer le tiret demi-cadratin « – » sur AltGr+[6] pour plus de cohérence,
• réintroduire le signe moins mathématique « − » sur AltGr+{-}.

Ceci a pour but de faciliter l’accès du tiret cadratin souvent employé en français et de réintégrer le signe moins mathématique. Le tiret demi-cadratin est placé sur la même touche que le tiret cadratin pour une plus grande facilité de mémorisation.

Seconde proposition

Attention, elle entraîne plus de changements, mais améliore beaucoup de choses à mon sens — place du « - », du « @ », du « — », etc. Comme c’est un peu long (mais très bien argumenté) elle est sur le une page perso à part. Nemolivier 11 avril 2008 à 12:28 (CEST)

[…] Le K en clavier azerty

• ne me dérange pas, « make » est très facile à taper. Je trouve presque que le K est plus facile d’accès par rapport à avant. En revanche le ç devient plus difficile à attraper. Je pense que cette situation est gagnante mais je testerai un peu plus ce week-end.Tiot 16 avril 2008 à 21:33 (UTC)

Un testeur \o/ Comme toi, je trouves que le « Ç » est un problème. Relativement au gain, je trouve que c’est acceptable, mais pour tester je suis entrain de taper avec un « trou » au niveau de la touche [8]. Pour le Ç, c’est génial. Mais intellectuellement, je ne suis pas très satisfais de cette trouée dans la rangée des chiffres. Nemolivier

Accessibilité de la brève morte

Je reviens sur une meilleure accessibilité de la brève. J'ai plusieurs propositions qui me conviendrait très bien :

• En Maj+AltGr+{P}. Position idéale puisque la lettre qui suit est le U, juste en dessous. S. Veyret 25 mars 2008 à 13:27 (CET).
• En Maj+AltGr+{ê}. Ce serait alors une duplication de la position actuelle puisque l'on se trouve ici sur la touche « facultative ». S. Veyret 25 mars 2008 à 13:27 (CET).

En Alt Gr + {ê}, ça me semble mieux, si l'on considère que « / » est plus accessible en {9} qu'en Alt Gr + {Ê}. Tohuvabohuo 28 mars 2008 à 12:24 (CET)

le « / » en AltGr-{ê} était là pour pouvoir taper « ~/ », sauf que comme c'est le même doigt, ça doit pas s'avérer être pratique (j'utilise pas cette disposition là), et si ça l'est, ça ne l'est pas forcément beaucoup plus que ~ (AltGr-{à}) suivi de / en accès direct. Crako 28 mars 2008 à 14:53 (CET)

• En Maj+AltGr+{k}. Un peu moins pratique que les autres puisque cela décale un peu la main gauche qui doit ensuite faire le U. S. Veyret 25 mars 2008 à 13:27 (CET).

Cf aussi inversion ^/K

• Accepter un AltGr symétrique. Tohuvabohuo 28 mars 2008 à 11:55 (CET).
• Déplacer « µ » en Alt Gr + {V} (ou ailleurs), et mettre la brève morte en Shift + {%} (à la place actuelle de « µ »). Tohuvabohuo 30 mars 2008 à 13:31 (CET).

Je pense que l'utilisateur sera déboussolé de voir, sur un accès maj·, un caractère qui ne sert qu'au turc et à l'espéranto Orel'jan 31 mars 2008 à 08:08 (CET)

N'a-t-on jamais prétendu que les accès Alt Gr à la main gauche étaient à la limite plus faciles que les accès Maj. ? Tohuvabohuo 31 mars 2008 à 08:42 (CET)

• Déplacer « µ » en Alt Gr + {V} (ou ailleurs), et mettre la touche Compose en Shift + {%} (à la place actuelle de « µ »). Le u avec brève « ŭ » de l'espéranto sera donc accessible, si je me souviens bien, par Compose u u. Tohuvabohuo 31 mars 2008 à 09:00 (CET)

@ en Altgr-$

Proposition initiale

J'ai beaucoup de mal à trouver le @ à sa place actuelle (shift-[)]). Il me semble que § et ¶ peuvent très bien aller à une place libre en main droite (altgr-{Q} et altgr-shift-{Q} par ex.) Gaëtan 26 mars 2008 à 15:26 (CET)

Pourrais-tu préciser ce que tu entends par « beaucoup de mal à trouver le @ » ?

Serait-il moins accessible en Shift + [)] qu'en Alt Gr + [²] ? Tohuvabohuo 28 mars 2008 à 11:53 (CET)

À sa place actuelle, une fois sur deux, j'appuie sur une des touches voisine (en général le [0]), chose qui ne m'arrivait jamais quand il était sur [²]) Gaëtan 28 mars 2008 à 12:09 (CET)

Perso, je voterais pour l’annulation du vote sur le double accent aigu et pour le placement de « @ » sur Maj+[²]. « # » se retrouverait en AltGr. Mais que mettre sur Maj+{=} ? YDB 28 mars 2008 à 18:29 (CET)

Je ne vois pas à quoi ça servirait d’annuler le vote sur le double accent aigu. On pourrait très bien, par exemple, mettre « @ » à la place de « § », « § » à la place de « ¶ » et « ¶ » quelque part en Alt Gr main droite. Tohuvabohuo 29 mars 2008 à 22:50 (CET)

C'est peut-être dû à l'habitude de l'Azerty et le « @ » sur le [0] ? Tiot 3 avril 2008 à 11:47 (CEST)

C'est effectivement une explication plausible. Je n'y avais pas pensé parce que, sur l'Azerty belge que je connais mieux, l'@ est en Alt Gr + [2]. Tohuvabohuo 4 avril 2008 à 11:06 (CEST)

J'ai également beaucoup de difficulté avec le @ car la touche est difficile d'accès (petit doigt très haut) et la touche se confond très facilement avec ses deux voisines (au toucher). Contrairement à ce que j'ai lu dans certains argumentaires (le @ ne serait que très peu utilisé à cause du carnet d'adresses), je constate autour de moi une grande utilisation du @, surtout chez les débutants. Il suffit de penser à chaque fois qu'on s'inscrit sur un site. Je pense que le @ ne soit pas être en Alt+Gr mais en accès direct ou en majuscule. Personnellement, je suis un grand grand fan du @ en haut à droite (et cela se justifie, le @ étant selon moi bien plus courant que le $ ou le # si on ne fait pas de programmation et les programmeurs ayant généralement peu de problème avec alt+gr, contrairement aux débutants). Une autre proposition serait le @ à la place du % ou du µ.--Ploum 9 avril 2008 à 10:11 (CEST)

Si le « _ » est déplacé sur AltGr+espace, on a une place en accès direct pour « @ ». Mais franchement, le @ est peu utilisé : les adresses sont automatiquement complétés par firefox pour les site, y compris les nouvelles inscriptions. Et le clients de courriel le font aussi. Nemolivier 9 avril 2008 à 12:08 (CEST)

Je m'insurge contre cette idée. Le @ est extrêmement employé dans plein de cas et est un énorme point bloquant pour les nouveaux utilisateurs sur les claviers Azerty (car demandant un Alt+gr). L'utilisation d'un @ est selon mon observation de beaucoup d'utilisateurs bien plus fréquente qu'un % sans même parler d'un $. --Ploum 11 avril 2008 à 16:07 (CEST)

Tu dis que le « @ » est difficile d'accès et tu proposes de le mettre sur le {%} qui est encore moins facile d'accès pour le petit doigt.Tiot 9 avril 2008 à 13:52 (CEST)

Je trouve la touche % plus "facile à trouver d'un point" car dans un coin (ou presque). Les coins sont les endroits les plus simples selon je ne sais plus quel ergonome. Cela ne signifie pas "plus facile d'un point de vue mécanique". Le @ n'étant que rarement utilisé dans un texte continu, plus souvent dans un contexte "haché" et court, je pense que sa situation idéale est vraiment le coin en haut à gauche (actuel $). Mécaniquement difficile, interrompt la fluidité d'un texte mais super facile à trouver sans réfléchir quand le besoin s'en fait sentir. --Ploum 11 avril 2008 à 16:07 (CEST)

C'est exactement pour ces raisons qu'il a été placé initialement sur la touche [²] en accès direct initialement (avec $ en shift, et # en altgr), reste à savoir si ce qui a été dit pour la version 0.6.4 est toujours valable Crako 11 avril 2008 à 16:18 (CEST)

Je comprends la logique de ton raisonnement. Mais l’accès en Maj n’est-il pas assez « visible » ? Notes bien que le « @ » est en fait frappé dans le flot, au contraire de ce que tu dis. Dans son utilisation courante il n’est ni précédé ni suivi d’une espace. De toutes façon, je reste persuadé que c’est un caractère peu tapé (notion différente d’utilisé). Quelque soit l’usage du clavier. (Notons que sur mon clavier, il est en accès direct sur [6] ;o)) Nemolivier 11 avril 2008 à 16:23 (CEST)

Le @ n'a pas d'espace contigu et il est écrit dans le flot, mais personnellement je pense qu'il y a une sorte de hachage (pour reprendre un précédent terme) au niveau mental. Un email de la forme nom@société.com est mémorisé comme « nom at société.com », c'est pour cela qu'il y a une sorte de hachage, il y a un ralentissement plus au niveau du cerveau qu'au niveau manuel avec la frappe d'un espace.--Gorfou 16 avril 2008 à 15:22 (UTC)

@ est utilisé (et tapé directement) en Perl par exemple, ou dans les commentaires Java. Mais de là à déplacer @ pour remplacer $ qui est encore plus utilisé, non merci. Pour l'accessibilité, je ne sais pas trop. Je tape personnellement [°] avec shift-droit + majeur, pas vraiment standard, donc je ne me prononcerai pas sur ce point. Nbrodu 11 avril 2008 à 18:06 (CEST)

De l’usage de compose et des touches mortes par rapport à celui d’AltGr

J’essaie ici d’établir une règle concernant l’usage de compose, des touches mortes et d’AltGr, qu’il semble que nous ayons implicitement suivie jusqu’à présent. C’est un point a débattre puisque l’usage de compose et des touches mortes semble remporter de plus en plus de succès. Or il me semble important de conserver une cohérence dans ces usages, donc de fixer une règle.

• AltGr (et Maj+AltGr) est utilisé pour les caractères francophones qui n’ont pas trouvés leur place en accès direct ou Maj., les autres caractères utiles et courants (informatiques, typographie, etc.) et les accents morts ;
• Compose et les touches mortes sont utilisées pour des caractères non francophones et des caractères plus rares et/ou fantaisistes (smiley, flèches, etc.).

Cette règle me semble avoir été suivie jusqu’à présent. Comme par exemple le fait que « € » soit resté en accès AltGr alors que les autres symboles monétaires sont en usage combiné touche morte + lettre. Les récentes proposition qui « font tiquer » certaines personnes dont je suis ne me semble pas les suivre.

C'est une façon de voir les choses, sauf que Compose fonctionne de manière mnémotechnique et fait ce qu'il dit faire : Composer des caractères. Il faut donc prendre en compte ce point pour les caractères rares, et faire le bon compromis fréquence / accessibilité entre direct, shift, altgr, compose, surtout qu'il y a un nombre limité de places accessibles sur le clavier. Nbrodu 17 avril 2008 à 07:42 (UTC)

Met-on cette « règle » au vote ? Nemolivier 23 avril 2008 à 08:53 (UTC)

Touche Compose

On parle de plus en plus de l'utilisation de Compose, du moins sous linux, mais on a pas fixé de touche pour l'utiliser. Je sais pas s'il y a un emplacement standard pour Multi_Key, des fois c'est sur la touche « Menu ». Où est-ce qu'on pourrait la mettre ?

• sur <Menu>, mais on perd cette touche sous linux, alors que certains s'en servent peut-être ; Crako 28 mars 2008 à 14:53 (CET).

Je pense qu'on a pas à redéfinir le rôle de cette touche — si l'utilisateur veux le faire dans son coin, pas de problème, mais il ne faut pas que ça soit le cas par défaut, pour ne pas aller contre les usages qui en sont fait actuellement. Gaëtan 10 avril 2008 à 16:02 (CEST)

Je suis de cet avis. Mais si cette touche prends l’importance que certaines propositions lui donnent (telle celle concernant le « æ », par exemple), nous devons la rendre présente par défaut. Nemolivier 12 avril 2008 à 15:31 (CEST)

Cette touche n'existe pas non plus sur mac, on ne peut donc pas l'utiliser « en standard », surtout si elle prend de l'importance, pour Æ par ex. Gaëtan 13 avril 2008 à 09:51 (UTC)

• sur AltGr - espace (mais on risque d'avoir des erreurs, même si ça se voit davantage qu'un nbsp, c'est pas forcément agréable, surtout que Compose + espace + espace donne nbsp). D'ailleurs YDB prévoie d'y mettre « _ » ; Crako 28 mars 2008 à 14:53 (CET).

J'aime bien cette proposition, elle ne prends pas de place dans les touches existantes, tout en rendant Compose assez accessible. Je préfère également garder _ en accès direct pour l'avoir testé un certain temps sur « espace ». Nbrodu 13 avril 2008 à 08:13 (UTC)

• sur <TLDE>, mais où mettre ce qui s'y trouve déjà ; Crako 28 mars 2008 à 14:53 (CET).

C'est une bonne question. On pourrait, par exemple, mettre la multikey à la place de « $ », « $ » à la place de « # », « # » à la place de « § », « § » à la place de « ¶ » et « ¶ » quelque part en Alt Gr à la main droite. Tohuvabohuo 30 mars 2008 à 20:29 (CEST)

• en accès direct sur [6], et n'appliquant que la première modification d'YDB ; Crako 28 mars 2008 à 14:53 (CET). J’aime assez Nemolivier 12 avril 2008 à 15:33 (CEST)
• Sur la touche Windows de droite, mais comme cette touche est absente de certains claviers, il faudra la dupliquer ailleurs. Tohuvabohuo 31 mars 2008 à 11:58 (CEST)

Et certains claviers n'ont pas du tout de touche windows (les macs). Gaëtan 10 avril 2008 à 15:59 (CEST)

Voir aussi mon commentaire sur la touche menu. Gaëtan 10 avril 2008 à 16:02 (CEST)

• Sur altgr-{,} semble être une bonne accessibilité pour cette touche. Gaëtan 10 avril 2008 à 16:10 (CEST)
• ailleurs ? Crako 28 mars 2008 à 14:53 (CET).
• Ne pas mettre de touche Compose.

L'idée de cette touche est bonne en soi, mais malheureusement trop compliquée pour l'utilisateur final. En tout cas, je ne suis pas contre son ajout, mais à condition que ce ne soit pas dans la norme du BÉPO. N'oublions pas que nous créons un standard, un clavier que nous espérons voir un jour dans tous les magasins qui vendent de l'informatique.Rideĉjo 11 avril 2008 à 12:34 (CEST)

L'usage de Compose n'est pas compliqué, vu qu'il fonctionne justement comme composition mnémotechnique. Quand à la normalisation, cf la page wikipedia: c'est un mécanisme ancien et très bien testé, déjà présent sur bon nombre de claviers en vente ou vendus par le passé. Nbrodu 13 avril 2008 à 08:13 (UTC)

En gros, ça créerait une touche comme dans le Leboutte… en moins accessible. Cela dit, elle aurait un rôle moins important. Nemolivier 30 mars 2008 à 13:57 (CET).

Pas tout à fait. Le fameux accent grave mort du Leboutte est une touche morte à usages multiples, qui est utilisée pour une grande diversité de caractères, tels que les lettres avec accent grave, les ligatures, les majuscules accentuées, les symboles monétaires, les fractions, etc. Elle est toujours suivie d'un caractère unique et les associations de caractères ne sont pas toujours évidentes. Par exemple : « ` » mort + « ; » --> « œ » ; « ` » mort + « n » --> "»".

La touche Compose, quant à elle, est généralement suivie de plusieurs caractères, et les associations sont souvent plus mnémotechniques.

Tohuvabohuo 31 mars 2008 à 09:15 (CEST)

Suite aux récents messages sur la liste :

— difficulté de réaliser une touche Compose sous Windows avec les outils actuels (mais potentiellement faisable par la suite) ;

— possible fixation de la carte simplifiée avant d'obtenir ces outils.

Les seules solutions pour se garder la possibilité d'un Compose sont :

— ou bien de le mettre sur un espace actuellement libre ;

• La seule proposition ci-dessus réalisant cette condition est AltGr+Espace, toutes les autres impliquent la suppression ou le déplacement d'une fonctionnalité (y compris Menu).

— ou bien de se faire un « trou » pour plus tard, inutilisé pour le moment sous Windows (mais occupé sous Linux et dès que possible sous Windows).

• Seule AltGr+{,} génère un trou qui pourrait être rempli plus tard en tenant compte d'une éventuelle contrainte de carte simplifiée figée.
• Dans le cas des propositions de Compose en direct (y compris Menu/WinD) ou shift, il faudrait
  • ou bien accepter dès maintenant une exception à la dite contrainte pour pouvoir boucher le trou si ces propositions passent,
  • ou bien ne pas les proposer du tout.

Nbrodu 17 avril 2008 à 08:14 (UTC)

Ligatures en Compose avec redondance possible en AltGr

Motivation: Combien de fois par an utilisez-vous æ ? Combien de fois par jour/heure utilisez-vous & et ` sous Unix, [] dans les programmes et pour les non-programmeurs dans les références numérotées [X] ? Il serait judicieux de récupérer au moins AltGr+{A} (sur la rangée de repos!) pour y mettre un caractère plus courant. Pour œ il y a plus de mots français qui l'utilisent (cœur, sœur, vœux...) ce qui peux justifier une présence non composée (à débattre) mais &[] restent tout de même bien plus fréquents en moyenne. Nbrodu 10 avril 2008 à 14:21 (CEST)

Puis en cascade:

• Homogénéisation des accents morts + [] plus accessible :

En AltGr: ` mort sur {è}. & sur {A} et [] sur {PO}. ` ASCII sur AltGr {4}. Reste une place en AltGr {5}.

──┬────┬────┬────┬────┬
  │ 2 ≤│ 3 ≥│ 4 “│ 5 ”║
 —│ « <│ » >│ ( `│ )  ║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É ˝│ P  │ O  │ È  ║
║ b |│ é ´│ p [│ o ]│ è `║
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬
 ║ A  │ U Ù│ I ˙│ E ¤│ ? ¿║
 ║ a &│ u ù│ i ¨│ e €│ , ’║

En cascade: remettre œ dans la place libérée.

OU

• Meilleure accessibilité pour <>[] :

En AltGr: ¨ sur {A}, € sur {4} et on peut mettre [] ou <> sur {IE} et l'autre sur PO. Le tout cohérent: [] et <> comme {} et “” avec «». Reste un trou en AltGr {5} (faire une proposition en cascade le cas échéant)

──┬────┬────┬────┬────┬          ──┬────┬────┬────┬────┬
  │ 2 “│ 3 ”│ 4 ¤│ 5  ║            │ 2 “│ 3 ”│ 4 ¤│ 5  ║
 —│ « `│ » &│ ( €│ )  ║           —│ « `│ » &│ ( €│ )  ║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬       ╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É ˝│ P  │ O  │ È  ║       ║ B ¦│ É ˝│ P ≤│ O ≥│ È  ║
║ b |│ é ´│ p [│ o ]│ è `║       ║ b |│ é ´│ p <│ o >│ è `║
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬  ou  ╩╗───┴┬───┴┬───┴┬───┴┬───┴┬
 ║ A ˙│ U Ù│ I ≤│ E ≥│ ? ¿║       ║ A ˙│ U Ù│ I  │ E  │ ? ¿║
 ║ a ¨│ u ù│ i <│ e >│ , ’║       ║ a ¨│ u ù│ i [│ e ]│ , ’║

Note: Proposition superflue si <> repassent en accès direct (cf proposition espaces insécables automatiques pour guillemets).

En cascade: remettre œ dans la place libérée.

L'idée de faire les ligatures uniquement avec la touche Compose me plaît beaucoup, à condition, toutefois, que la touche Compose soit très accessible, mais, pour que je l'accepte, il faudra que Stéphane nous explique comment il procède pour installer sa DLL. Tohuvabohuo 10 avril 2008 à 14:07 (CEST)

L'idée est intéressante, mais elle nécessite effectivement une excellente accessibilité de la touche compose, chose que nous n'auront pas sans remettre en question toute la disposition. Une touche compose en altgr pour faire quelques caractères exotiques, ok, mais pour faire des caractères de la langue française, ça me paraît complètement inaproprié. Gaëtan 10 avril 2008 à 20:37 (CEST)

Excellente accessibilité ⇒ certaines des propositions ci-dessus pour Compose me semblent très accessibles. Inapproprié? C'est ton avis, mais on verra lors du vote si d'autres pensent que la place de æ ne serait pas mieux employée, au vu des fréquences d'utilisation. Nbrodu 10 avril 2008 à 22:32 (CEST)

Oui oui, c'est mon avis, et c'est pour ça que j'ai pris la peine de mettre « me parait » à la place de « est » :-) Gaëtan 10 avril 2008 à 22:53 (CEST)

Lesquelles ? Moi je ne vois que des touches secondaires ou des touches pas portables. Gaëtan 10 avril 2008 à 22:53 (CEST)

On sors beaucoup des règles d’accessibilité et de logique pour les caractères du français — æ et œ sont des caractères français, c’est comme ça, c’est une contrainte avec laquelle il faut « jouer » — et du fait que les majuscules sont en position Maj. de leur minuscule. En plus c’est une solution complexe. On tombe en partie sur des critiques faites au Leboutte. Sauf que sur le Leboutte, pour le coups, son « œ » serait plus facile. Là, ça veux dire que pour faire « œ » je dois faire, mettons : AltGr+{,} suivi de « o » et de « e » (un trigramme à un doigt). Je ne suis pas certain que ce soit génial… D’autant que c’est un caractère rare, il lui faut donc une place logique. Et l’usage du compose est totalement inconnu du « grand public ». Maintenant, il est vrai que le Æ est rare, mais ne plus avoir « ¨ » sur I, € sur E, c’est dommage. Nemolivier 10 avril 2008 à 17:03 (CEST)

Tu soulèves quelques points que je vais séparer pour mieux répondre:

• æ et Æ sont des caractères du français, et il faut les supporter.

C'est vrai, il faut les supporter, mais de manière appropriée. Ici ils occupent une position sur la home row, c'est disproportionné au regard de leur fréquence ! Compose nous donne l'occasion de corriger ce point. On pourrait aussi envisager de les placer en AltGr droit, mais à ce stade, Compose+a+e sera plus facile à retenir pour les rares cas d'usage qu'une localisation obscure. Nbrodu 10 avril 2008 à 20:20 (CEST)

• œ et Œ sont des caractères du français, et il faut les supporter.

Pour œ en effet, il faut débattre si la fréquence justifie ou non de passer en Compose ou si un rappel en AltGr est vraiment nécessaire. Par contre en comparaison de &[] par exemple œ reste bien moins fréquent. Nbrodu 10 avril 2008 à 20:20 (CEST)

Il faut des nombres pour ce genre d'affirmation, mais ils sont malheureusement bien difficile à obtenir, tant ils dépendent de l'utilisation faite de l'ordinateur. Gaëtan 10 avril 2008 à 20:33 (CEST)

D'accord avec toi qu'il faudrait des chiffres et un corpus adéquat. D'accord aussi que pour certains utilisateurs, œ sera plus fréquents que []. Mais franchement, au vu du nombre quotidien d'usage de &[], il suffit d'un seul programmeur/scientifique utilisant des [X] reférences/etc pour (grand nombre indeterminé ici) de gens pour lesquels œ serait plus fréquent, pour qu'en moyenne [] passe devant sur l'ensemble de la population. Et quand bien même on ne programme pas on se sert tout de même de [] de temps en temps. Alors non, je n'ai pas de chiffres exacts, mais je pense qu'il est vraiment dommage de privilégier quelques frappes rares (pour tout le monde) au détriment de frappes très courantes (pour moins de monde certes, mais c'est loin d'être négligeable et en moyenne probablement même que [] est plus fréquent que œ sur l'ensemble de la population). Quand on voie la différence d'accessibilité de œ (un peu moins bonne sur Compose, négligeable sur une localisation proche en AltGr de l'emplacement courant) et sa rareté relative, comparé avec le gain d'accessibilité pour d'autres caractères ([] par exemple) qui sont sans commune mesure plus fréquents pour bon nombre d'utilisateurs, ce serait vraiment très dommage. Nbrodu 10 avril 2008 à 22:32 (CEST)

On reste dans les conjonctures, mais admettons. Autant l'argument se discute pour « æ » qui est vraiment rare, autant je ne suis pas d'accord pour « œ » qui est loin d'être rare (il est plus fréquent que « k » par exemple) et qui a tout à fait sa place sur altgr-{o}. Gaëtan 10 avril 2008 à 22:53 (CEST)

Le œ est relativement utilisé (plus que le K d'après Gaëtan) et sa place sur le {O} est logique. Je pense que de le passer en compose O E réduira son utilisation et on aura des « ma soeur mange le coeur de l'oeuf ». À mon avis le Bépo rempli déjà sa philosophie qui est de privilégier le Français puis la programmation. Les [] reste plus accessible qu'en azerty. Et je ne vois pas ce que tu reproches à l'emplacement actuel du &.Tiot 11 avril 2008 à 11:53 (CEST)

Si on reste avec & en AltGr comme présupposé, je n'ai pas grand chose à dire pour le & actuel. L'idée est surtout de mettre æ peu fréquent ailleurs qu'en home row (ici en Compose, mais cf aussi propositions en section suivante) pour privilégier autre chose, en l'occurence rapprocher [] ou <>. Nbrodu 11 avril 2008 à 22:34 (CEST)

• Ce sont des caractères rares, il faut leur donner des places logiques.

Les places actuelles de œ et æ sont en effet faciles à retenir. Mais par logique, il faut inclure aussi leur fréquence d'utilisation. Comme ces positions sur {a} et {o} sont très accessibles on peut les réutiliser pour des caractères plus fréquents. Et alors Compose+a+e et Compose+o+e deviennent les solutions les plus facile à retenir pour les rares fois où on les utilise. Nbrodu 10 avril 2008 à 20:20 (CEST)

• L’usage du compose est totalement inconnu du « grand public ».

C'est l'occasion de le démocratiser ! Quand on découvre Compose et tout ce qu'on peut faire avec, par exemple les flèches comme → (plus fréquentes que æ en ce qui me concerne d'ailleurs !) et des tas d'autres choses, on est bien content :) Nbrodu 10 avril 2008 à 20:20 (CEST)

Non, ça n'est pas l'occasion : placer quelques caractères rares, mais indispensable pour le français sur cette touche, c'est tout simplement inciter les utilisateur à ne pas les utiliser et à écrire « ae » et « oe » à la place de « æ » et « œ ». Pour éduquer l'utilisateur, il faut donner un rôle beaucoup plus important à cette touche sur le clavier. Gaëtan 10 avril 2008 à 20:42 (CEST)

Ah? Je viens de vérifier: J'ai æ sur [a] sur mon Azerty sous Linux depuis des années et je ne l'ai jamais utilisé. Je me demande même bien le pourcentage de gens qui l'ont utilisé avant de passer au bépo. Quand à œ d'ailleurs, avant de passer au bépo, c'est avec Compose que je le faisais. Alors bien au contraire, montrer à l'utilisateur qu'il a beaucoup à gagner avec Compose (comme → ⇒ ☺ par exemple mais tellement d'autres) peut précisément lui donner l'idée de taper Compose+o+e et Compose+a+e. Quand à l'éducation générale je suis d'accord, à commencer par apprendre à taper Français plutôt que SMS dans les courriers électroniques. Nbrodu 10 avril 2008 à 22:32 (CEST)

L'usage de æ et de œ est aussi inconnu du "grand public" qui n'a pas été habitué à un accès à ces caractères (j'utilise un clavier depuis 15 ans et je ne sais toujours pas comment les taper sous Windows et linux en AZERTY (je les ai copiés plus haut dans le texte)). Donc je pense que l'accès en compose de ces caractères est intéressant, mnémonique, laisse de la place pour des caractères plus utilisés et n'entraîne pas une dérive vers le langage SMS (cet accès en compose laisse cette dérive là où elle est) puisque la majorité des utilisateurs de claviers ne savent déjà pas comment former ces caractères sur un AZERTY. Roudoudou 16 avril 2008 à 21:45 (UTC)

• Compose est une solution complexe

Certes plus complexe en terme de nombres de frappes, mais simple à utiliser et aussi voire plus simple à mémoriser. Nbrodu 10 avril 2008 à 20:20 (CEST)

• C’est dommage de ne plus avoir « ¨ » sur I, € sur E.

(Pour la deuxième proposition) en effet. Mais <> ou [] sont bien plus fréquents en ce qui me concerne et les positionner ici est cohérent avec {}. Et puis le tréma et l'euro restent quand même bien accessibles (le tréma est sur la home row). Enfin, c'est pour cela que j'ai fait deux propositions, pour lesquelles chacun peut voter pour ou contre indépendamment. Nbrodu 10 avril 2008 à 20:20 (CEST)

Je suis d'accord avec Olivier. Compose n'est absolument pas standard, en particulier dans le monde de Windows. Si l'on ajoute cette touche sur le BÉPO, ça doit être un plus, une option que peut choisir d'utiliser l'utilisateur final, mais pas une obligation. Les ligatures æ et œ ne doivent donc surtout pas être supprimées. Et puis, je suis désolé de rabâcher cela, mais j'ai bien peur que l'on nous fasse quelques difficultés pour normaliser un clavier qui déjà, d'apparence, est bizarre, mais qui, en plus, s'utilise de façon trop différente de ce que connait le grand publique. Et même si c'était standardisé, ces bizarreries risqueraient de freiner encore plus son adoption. Rideĉjo 11 avril 2008 à 12:44 (CEST)

Bah, sauf que Compose existait bien avant que M$ n'impose son Windows, et ils ont préféré ne pas reprendre l'idée mais plutôt y introduire AltGr + code à 3 chiffres, tellement plus mnémotechnique. Pour la normalisation, je ne voie donc pas en quoi Compose poserait problème, c'est un mécanisme très ancien et bien testé. Quand au « ne doivent surtout pas être supprimées » de un elles ne sont pas supprimées simplement déplacées en Compose, de deux je ne perçois pas bien l'intérêt vital et crucial de la chose (le « surtout pas »). Enfin, même si on garde une redondance en AltGr, autant pour œ je suis d'accord que ça se discute de le déplacer (et c'est ce qu'on fait), autant æ sur la home row est disproportionné au regard de ce qu'on pourrait y mettre d'autre. Nbrodu 11 avril 2008 à 18:45 (CEST)

Æ ailleurs que sur la home row (indépendamment de Compose)

Contrairement à la section précédente cette section forme une proposition séparée et ne nécessitant pas l'acceptation de Compose en Cascade (æ reste en AltGr). Qui plus est, ici, œ n'est pas déplacé. Les arguments de fréquence relatifs à æ et amenant à la proposition de son déplacement n'ont pas été repris de la section précédente pour alléger cette section (merci d'aller les lire plus haut!). Nbrodu 11 avril 2008 à 18:58 (CEST)

• Proposition 1

──┬────┬────┬────┬────┬
  │ 2 ≤│ 3 ≥│ 4 ˝│ 5 Æ║
 —│ « <│ » >│ ( ´│ ) æ║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É “│ P ”│ O Œ│ È `║
║ b |│ é [│ p ]│ o œ│ è `║
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬
 ║ A  │ U Ù│ I ˙│ E ¤│ ? ¿║
 ║ a &│ u ù│ i ¨│ e €│ , ’║

• Proposition en cascade: échanger <> et [] sur le dessin

Une modification comme celle-ci permettrait de ne pas utiliser la touche compose tout en conservant une partie des avantages de cette proposition. Les « < » et « > » peuvent être rappatriés à la place de « [ » et « ] ». Fredb219 11 avril 2008 à 13:41 (CEST)

OU

• Proposition 2

──┬────┬────┬────┬────┬
  │ 2 ≤│ 3 ≥│ 4 ˝│ 5  ║
 —│ « <│ » >│ ( ´│ ) `║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É “│ P ”│ O Œ│ È  ║ ! ¡│ V Æ│
║ b |│ é [│ p ]│ o œ│ è `║ ˆ ˇ│ v æ│
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬─
 ║ A  │ U Ù│ I ˙│ E ¤│ ? ¿║
 ║ a &│ u ù│ i ¨│ e €│ , ’║

• Proposition en cascade: échanger <> et [] sur le dessin

Comme la proposition 1, mais avec en plus une homogénéisation des accents morts (` mort devient accessible en AltGr et à côté de ´ mort). Æ est toujours présent (support correct du Français) mais en symétrique à œ, et peut donc toujours être retrouvé à l'occasion. ` mort est aussi possiblement plus courant en moyenne sur l'ensemble des utilisateurs (autres langues, fréquence à déterminer) que æ (Français, très occasionnel). Votre avis ? Nbrodu 11 avril 2008 à 19:31 (CEST)

Tu proposes de mettre une lettre du français (peu fréquente d'accord, mais quand même une lettre du français) en altgr-main droite (sans altgr symétrique) juste pour descendre « [ » et « ] » d'une ligne, au prix de la cohérence de placement de « [ » et « ] » et des accents morts ? J'utilise ces signes tous les jours (en C++, en python et dans les wiki). Leur accessibilité est déjà très bonne où ils sont placés. C'est, à mon avis, complètement disproportionné. Il est important de garder une cohérence dans les caractères rares ! Qu'on ne mette pas « { » et « } » en altgr-shift-« ( » et « ) », je veux bien comprendre, mais là, à mon avis, c'est trop. Gaëtan 13 avril 2008 à 09:23 (UTC)

Oui, c'est bien ce que je propose, déplacer une lettre très rare du Français en dehors de la home row pour améliorer l'accessibilité de caractères bien plus fréquents. La lettre du Français Æ restant disponible par ailleurs, ici (proposition 2) en symétrique de Œ. Que tu penses la chose disproportionnée (bouger une lettre rare du Français) ne me gêne pas, on a juste des avis différents sur la question (moi je trouve que ce qui est disproportionné c'est la place qu'elle occupe actuellement, sous un des doigts au repos). Après, tu peux aussi être satisfait des [] actuels, mais je pense que ÉP est plus accessible que 45. La cohérence de placement des [] et des accents morts vient en bonus. Nbrodu 13 avril 2008 à 09:57 (UTC)

OU

• Proposition 3 (sous réserve d'acceptation des espaces insécables automatiques pour les guillemets)

──┬────┬────┬────┬────┬
  │ 2 ≤│ 3 ≥│ 4 ˝│ 5  ║
 —│ < [│ > ]│ ( ´│ ) `║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É “│ P ”│ O Œ│ È  ║ ! ¡│ V Æ│
║ b |│ é «│ p »│ o œ│ è `║ ˆ ˇ│ v æ│
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬───┴┬─
 ║ A  │ U Ù│ I ˙│ E ¤│ ? ¿║
 ║ a &│ u ù│ i ¨│ e €│ , ’║

• Proposition en cascade: Æ sur AltGr+{Q}

Suite à la remarque ci-dessus voici une autre proposition. Le but est de faire des compromis pour satisfaire un maximum d'utilisateurs (guillemets pour le Français, accents morts pour langues étrangères, symboles de programmation…) au final tout le monde y gagne un peu.

• Améliore l'accessibilité des guillemets par rapport à la disposition actuelle (espaces automatiques inclus)
• Rends cohérent les accents morts, avec le moins utilisé ` sur 5
• Conserve la position de œ, déplace æ en main gauche
• Améliore (un peu) [] en les mettant sur 23 plutôt que 45 (le 5 surtout)
• Améliore l'accessibilité de <>
• Est cohérente pour les guillemets Anglais au dessus des guillemets Français
• Place & proche de |

Testez-là, les guillemets automatiques sous les doigts en particulier sont très sympa ! Voici [le fichier xkb] ainsi que [le fichier Compose] correspondant à la proposition, cf le mode d'emploi à l'intérieur pour tester. Nbrodu 14 avril 2008 à 15:31 (UTC)

Finalement, deux problèmes « importants » à mon sens :

• AltGr+V est une des combinaison les pire que nous ayons, il faudrait trouver autre chose

Hmmm, sur {è}, juste à côté de œ ? Cela impliquerait de remettre les ` (non-mort et mort) sur la même touche, par exemple sur {4}, et ´ sur {5}. Personellement le æ loin ne me gène pas plus que ça, mais si cette nouvelle proposition te conviens mieux on la propose officiellement :) Nbrodu 14 avril 2008 à 16:45 (UTC)

Ce n’est pas idéal… Et ce n’est pas moi qui décide ;) Nemolivier

Update suite à notre discussion IRC: proposition en cascade æ sur AltGr+{Q} qui est (un peu) plus accessible que sur {V}. Nbrodu 15 avril 2008 à 08:36 (UTC)

• on perds la logique d’accès des accents morts. Mais il y a du mieux ! Nemolivier 14 avril 2008 à 16:23 (UTC)

Pourquoi ne pas faire une tournante ~/æ/& ? Ça permettrait de conserver æ à un endroit logique (sur le À), et de mettre le & sur le A, ce qui semble être l'objectif de la manœuvre… À moins que la position de ~ ne soit importante ? Flocondeneige 15 avril 2008 à 08:05 (UTC)

Æ sur À est une bonne idée ! Mais ~ non mort est un sujet sensible aussi, il est utilisé au quotidien sous Linux, et certainement plus fréquemment que æ en moyenne sur l'ensemble de la population… L'objectif est surtout de mettre autre chose de plus fréquent que æ sur la home row, en satisfaisant un maximum de contraintes dues à des usages différents, pour que chacun y gagne un peu. Ce n'est pas facile (suffit de voir l'état de cette page !), mais ça vaut le coup d'essayer. Nbrodu 15 avril 2008 à 08:36 (UTC)

OU

• Proposition 4

──┬────┬────┬────┬────┬
  │ 2 “│ 3 ”│ 4 ˜│ 5 ˝║
 —│ « [│ » ]│ ( ~│ ) ´║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║ B ¦│ É ≤│ P ≥│ O Œ│ È `║
║ b |│ é <│ p >│ o œ│ è `║
╩╗───┴┬───┴┬───┴┬───┴┬───┴┬
 ║ A  │ U Ù│ I ˙│ E ¤│ ? ¿║
 ║ a &│ u ù│ i ¨│ e €│ , ’║
═╝──┬─┴──┬─┴──┬─┴─━┯─┴──┬─┴──┬
 Ê  │ À Æ│ Y  │ H  │ : ·│ K  ║
 ê /│ à æ│ y \│ h {│ . }│ k …║
╦═══╧══╦═╧═══╦╧════╧════╧════╧

Proposition utilisant la suggestion de Flocon :

• « æ » est sur le « à » ce qui est à peu prêt logique et accessible.
• « < » et « > » deviennent bien plus accessibles
• « ~ » perd un peu (et encore)
• « & », « [ » ,et « ] » gagnent en accessibilité
• Les guillemets ne sont pas affectés donc pas de problème d'enchainement.

Fredb219 15 avril 2008 à 08:52 (UTC)

Ça a le mérite de pouvoir se faire même si les insécables automatiques sur guillemets ne sont pas acceptés. Ceci dit si les insécables automatiques sont acceptés, on peut les mettre sur {ÉP} et cela réalise un meilleur compromis que de les laisser sur 23. Tu peux aussi inverser & et ~ afin qu'ils soient plus proches de leurs positions actuelles, même si ça n'a pas d'importance en termes logique. En tout cas ça reste mieux à mon goût que la disposition actuelle.

Dans la même lignée, que penses-tu de la variante ci-dessous, qui à mon avis réalise un meilleur compromis global tout en apportant d'autres avantages ?

OU

• Proposition 5 (impliquant insécables autour des guillemets)

───┬────┬────┬────┬────┬────┬──
1  │ 2 ˝│ 3  │ 4 ≤│ 5 ≥║ 6  │ 7
" `│ ( ´│ ) &│ < [│ > ]║ _ —│ +
═╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──
 ║ B ¦│ É “│ P ”│ O Œ│ È  ║ ! ¡
 ║ b |│ é «│ p »│ o œ│ è `║ ˆ ˇ
═╩╗───┴┬───┴┬───┴┬───┴┬───┴┬───
  ║ A ˜│ U Ù│ I ˙│ E ¤│ ? ¿║ C 
  ║ a ~│ u ù│ i ¨│ e €│ , ’║ c 
╦═╝──┬─┴──┬─┴──┬─┴─━┯─┴──┬─┴──┬
║ Ê  │ À Æ│ Y  │ H  │ : ·│ K  ║
║ ê /│ à æ│ y \│ h {│ . }│ k …║

Par rapport aux précédentes (lettres mortes en rouge, changements vs 0.6.5.1 en bleu):

• « Æ » est à gauche et sur « À » comme propose Flocon et Fred ci-dessus.
• Les guillemets + insécables gagnent par rapport à la 0.6.5.1
• Les parenthèses (utiles pour tout le monde) gagnent en venant sur une paire de doigts forts sur 23 plus accessibles que 45.
• « < » et « > » gagnent
• « ~ » gagne (et ˜ mort qui lui est lié aussi)
• « ´ » mort reste proche du é, « ` » mort gagne en accessibilité et en cohérence hors de Maj
• « [ » et « ] » ne bougent pas
• « & » perds un peu, mais pas beaucoup
• « — » perds en accessibilité, mais gagne en cohérence. Cf Compatibilité ci-dessous.

Autres points :

• Œ ne bouge pas.
• Guillemets anglais cohérents en bonus

Compatibibilité avec les autres propositions :

• Tirets : Indépendance avec la proposition 2 des tirets car « — » est alors dupliqué. Compatible avec la proposition 1 qui agit sur [6]
• « … » sur {.} et positions ligne du bas: On applique d'abord les nouvelles positions de {}\~ le cas échéant, puis on échange les positions de AltGr+{à} et AltGr+{a} comme ci-dessus.
• Guillemets : Accepter cette proposition implique automatiquement l'acceptation des espaces automatiques autour des guillemets.

Au final chaque catégorie d'utilisateur y gagne, et cela réponds aux critiques principales soulevées dans les discussions précédentes. Vos avis ? Nbrodu 15 avril 2008 à 10:10 (UTC)

Je ne vois pas l’intérêt d’inverser æ et ~. Le tildé est-il si important qu’on sacrifie la logique de placement du Æ ? En fait, tu ne pourrait déplacer que les accents et les parenthèses et autres guillemets. Nemolivier

Cela permet d'éviter d'éloigner « & » en l'envoyant sur clavier bépo4 ou clavier bépo5. Par contre, le placements des guillements en Altgr ne va pas rendre leur utilisation secondaire fasse à un « " » en accès direct ? Fredb219 15 avril 2008 à 10:49 (UTC)

En pairant les guillemets avec les insécables, et en les mettant sur ÉP, l'enchainement guillemet-insécable est bien plus facile que dans la version actuelle. Pour « æ » l'intérêt est de mettre autre chose de plus fréquent sur la home row, ici ~, dans d'autres propositions &, mais ce pourrait être autre chose aussi. Quand au « sacrifice » consenti en le mettant sur {À}, que voulez-vous de plus ? Au regard de sa fréquence, le « sacrifice » est plutôt sa place en home row qu'on pourrait mieux employer ! La proposition de Flocon garde non seulement pour æ une cohérence logique mais en plus un accès à gauche, répondant aux critiques majeures faites contre son déplacement. Nbrodu 15 avril 2008 à 12:00 (UTC)

Dans cette proposition n°5 il me semble que le æ et le ~ pourraient revenir à leurs places actuelles sans que le & (qui est sur 3) en soit affecté, non ? Nemolivier 15 avril 2008 à 11:25 (UTC)

Je suis d'accord qu'on pourrait découper cette proposition en petit bouts (inversion æ/~, déplacement ~\{}…, guillemets pairés avec insécables ou non, descendre les guillemets en ÉP, homogénéiser les accents morts aigu/grave, position du &, etc… ce qui est d'ailleurs déjà en partie le cas. Mais alors ça revient implicitement à autoriser une acceptation partielle, et comment recoller les bouts ? Comment garder une cohérence d'ensemble en équilibrant les intérêts de chacun ? Si on coupe en petit bouts, on se retrouve avec chacun votant pour favoriser ses caractères préférés et bloquant les changements qui seraient utiles à d'autres, on l'a vu lors des votes précédents. C'est pourquoi je propose une solution intégrée où chacun peux au moins y trouver un avantage, en précisant qui plus est les intéractions avec les autres propositions (tiret, ligne du bas) pour éviter de casser le compromis. C'est aussi pour cette raison qu'il y a tant de propositions sur cette page, afin d'essayer de trouver une solution satisfaisante avant la fin de la phase de propositions. J'irai même plus loin en disant qu'il faudrait pendant la phase de mise en cohérence des propositions avant le vote, autoriser le regroupement de certaines propositions pour ne garder qu'un ensemble réduit de propositions équilibrées, avec des variantes si besoin est en propositions cascades, et éventuellement à côté quelques annexes indépendantes des propositions globales. En attendant, merci de faire une proposition 6 si vous avez d'autres idées :) Nbrodu 15 avril 2008 à 12:00 (UTC)

j’entends bien, c’est pourquoi je dis qu’il me semble que ta proposition n°5 gagnerait à ne pas inverser le Æ et le ~ Nemolivier 15 avril 2008 à 12:28 (UTC)

Il y a 2 aspects principaux à débattre :

• Dégager les touches É et P pour y mettre un couple de touches
  • et mettre « « » et « » » en ajoutant les espaces inceccables.
    • et mettre « < » et « > » en acces direct (proposition 3)
    • et Décaler « ( » et « ) » vers la gauche et mettre « < » et « > » en acces direct à droite (proposition 5)
  • et mettre « < » et « > »
    • « [ » et « ] » peuvent remplacer « < » et « > »(proposition 4)
    • « & » et « ´ » peuvent remplacer « < » et « > »
  • et mettre « [ » et « ] » (proposition 1 et 2)
  • et mettre « ( » et « ) »
    • et mettre « < » et « > » en acces direct
    • et mettre « & » et et un heureux élu en acces direct
    • je ne crois pas qu’on puisse se « permettre » de mettre les parenthèses en accès AltGr Nemolivier

• Déplacer « æ » pour y mettre un autre caractère
  • et remplacer par « ~ »
    • Je ne comprends pas l’intérêt Nemolivier
  • et remplacer par « & »
    • pareil, on perd en logique pour un gain d’accessibilité du & pas énorme (sauf ci on casse tout comme proposé au dessus, ça fait beaucoup casser !) Nemolivier 15 avril 2008 à 13:29 (UTC)
  • Déplacer « æ » à droite à un emplacement inutilisé comme AltGr+{V} ou AltGr+{Q}. Cf la section précédente pour le Compose.

Actuellement j'ai l'impression qu'il y a beaucoup de proposition mais que personne ne sais vraiment quel est le but recherché. Je pense qu'il faut essayer de se mettre d'accord sur les apports principaux de ses propositions puis de voir ou placer les caractères restants. Que penses les défenceurs du « « » et « » »  ? Leur placement en altgr n'est pas trop génant ? Si cette modification ne se fait pas, la descente de « < » et « > » me semble aussi très interressante. Je vois un interet à déplacer le « æ » si et seulement si « & » perd en accessibilité (je fais surement trop de PHP).Fredb219 15 avril 2008 à 13:07 (UTC)

Ok, vous avez raison d'essayer de dégager les idées principales, on y gagnera en clareté. Sans Æ/~ les 4 et 5 n'ont plus à être dans cette section. Ce qui n'empêcherait pas de refaire des paquets intégrés comme ceux dans cette section lors de la phase de dépouillement des propositions, afin de réaliser des solutions de compromis pour éviter le phénomène ci-dessus du chacun pour soi. Nbrodu 15 avril 2008 à 13:19 (UTC)

Merci du résumé. Je suis un « défenseur » des guillemets. Mais je test depuis quelque temps maintenant leur position en AltGr (avec insécable automatique) et je dois bien reconnaitre que c’est très confortable. Même sur 2/3. Pour moi, pas besoin de les déplacer ailleurs. J’ai donc < et > en accès direct. J’ai du mal à savoir qui de chevrons et des parenthèses « mérite » le plus d’être sur 2/3.

J’ai bien | et & facilement accessible et je n’utilises jamais « ´ » et « ` ». En gros, j’aime assez mon clavier actuel, dans cette région manque une optimisation du « ` » mais sinon… Nemolivier 15 avril 2008 à 13:29 (UTC)

Il faut noter que le « > » en accès direct peut augmenter sensiblement la vitesse de frappes en PHP et C++ : l'enchainement de « - » et de « > » pour les pointeurs ( -> ) n'est vraiment pas comfortable actuellement.Fredb219 15 avril 2008 à 13:41 (UTC)

Bien d'accord avec Fred. Ceci dit ce débat devrait avoir lieu dans la section concernée... Nbrodu 15 avril 2008 à 13:48 (UTC)

Pour résumer les choix sur la position de æ: æ en Compose OU æ en AltGr+V OU æ en AltGr+Q OU æ en AltGr+À. Fred a résumé les choix sur les autres caractères, cf aussi les sections guillemets+insécables et libération de ÉP. Nbrodu 20 avril 2008 à 20:59 (UTC)

« … » sur {.}

• Mets … sur .
• Mieux pour disposition doigts gauche à gauche, pas gênant pour les autres

les différentes options :

• « { » et « } » décalés à gauche et « \ » sur [B] ;
• « \ », « { » et « } » et décalé à gauche, « … » sur « . » et « ~ » sur [B] ;

Testé avec la position /\{}…~ depuis deux jours, je ne reviens pas de la facilité avec laquelle je trouve les accolades. Je pense que c’est lié au fait qu’elles sont maintenant sur le même couple de doigts que celui qui fait les guillemets et les chevrons. Nemolivier 19 avril 2008 à 09:31 (UTC)

À part ça, personnellement je préfère le « ~ » en AltGr+« . » qu'en AltGr+« K », mais le choix contraire ne me dérangerait pas outre mesure. Skippy le Grand Gourou 11 avril 2008 à 15:06 (CEST)

Proposition plus ou moins liée : le ~

Rappel de l’usage : shell, espagnol (ñ), portugais (ã, õ), insécable en LateX…

Je ne voie pas l'intérêt de créer un ˜ mort pour ñ, vu que Alt-Gr + tilde mort + n provoquerait une frappe de plus que Alt-Gr + n (et un relachement de AltGr au milieu de la combinaison). Pour le portugais (ã, õ) on peut argumenter d'un AltGr gauche (et cf ci-dessous), mais alors il faudrait comparer la population francophone (cible prioritaire du bépo) qui parle aussi le portugais, avec celle qui utilise Latex ou un shell Unix... Nbrodu 19 avril 2008 à 23:07 (UTC)

Il a été évoqué sur irc de mettre le ~ mort en accès AltGr et ~ non mort en Maj+AltGr pour être cohérent avec les autres accents morts. Pour faciliter le « ~/ » utile aux unixéens, on peut faire un « raccourcis » Compose avec ~mort+/ donne « ~/ ».

Règles pour le .XCompose :

<dead_tilde> <slash> : "~/"
<dead_tilde> <division> : "~/" 

Ça ne résous pas le problème des ~nom_utilisateur, que tu retrouves parfois dans certaines URLs d'ailleurs, même si en effet ~/ est la combinaison la plus fréquente. Nbrodu 19 avril 2008 à 23:07 (UTC)

Problème, pour signer le wiki, il faudrait alors… 8 frappes sur cette touches morte ! (ou 4 du ~ en Maj+AltGr).

Après test, on va plus vite a faire quatre fois AltGr+Maj+[B] que huit fois AltGr+[B] (avec le ~ dans cette position). Nemolivier 19 avril 2008 à 09:31 (UTC)

Donc, il est peut être intéressant de coupler avec la proposition ci-dessus, rendant la « manœuvre » peut-être plus facile (pas pire en tout cas) :

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

Le « ` » non mort

Si la proposition ci-dessus passe (même partiellement), ˝ et ` se retrouveront être les seuls accents morts à ne pas être en accès altgr. ˝ est un peu à part : nous l’avons « lié » à ´ pour la logique. Est-ce que les utilisateur du ` non mort accepteraient qu’on inverse le mort et le non mort ? Le double accent mort ou Maj+AltGr+{è} sont-elles vraiment deux combinaisons incompatibles à votre usage de ce signe ? J’ai du mal à me rendre compte, je ne l’utilises jamais… Nemolivier 15 avril 2008 à 10:23 (UTC)

Si ` non mort est en AltGr et non Shift-AltGr c'est parce que c'est un caractère utile en shell Unix, perl, etc. Il signifie en gros « exécute moi cette commande et donne moi le résultat ». Et on a déjà À È Ù précomposés pour le Français. Une bonne solution selon moi est tout simplement de garder ` non mort là où il est, et de rajouter un ` mort ailleurs pour les liguistes de langues étrangères où il est utilisé (ceux qui en aurait besoin : lesquelles ?).

Par exemple, j'ai fait des propositions en ce sens dans la section « libérer AltGr É P ». Nbrodu 19 avril 2008 à 22:43 (UTC)

Je sais à quoi il sers. Ce que je disais par là c’est que le Maj+AltGr est encore bien accessible dans cette situation, et permet d’être cohérent avec l’ensemble du clavier. J’ai du mal a me rendre compte de l’usage et de comment il s’insère dans le flot de la frappe. Séparer ` mort et non mort me semble non seulement une perte de place mais aussi une perte de logique. Nemolivier 19 avril 2008 à 23:00 (UTC)

D'autres ne le savaient peut-être pas (à quoi sert le ` non mort). Si le grave mort est vraiment utile pour des langues étrangères, mettons-le en AltGr+6 sans toucher au ` non mort. Je rajoute une proposition alternative en ce sens... Nbrodu 20 avril 2008 à 21:33 (UTC)

Inversion ^/K

• [B] accessible des deux mains, peut taper ^+voyelle en alterné
• peut aussi taper ! avec la main gauche si on veut
• ˇ+u plus facile aussi pour ceux que ça intéresse
• Compatible avec inversion précédente \ sur {K}

Est-ce que ça ne rends pas « \ » (ou tout autre symbole en AltGr+{K}) très difficile d’accès (AltGr+[Y]) ? Nemolivier 11 avril 2008 à 09:19 (CEST)

[B] n'est pas accessible des deux mains sur les split keyboards, les Kinesis, les TypeMatrix et d'autres claviers plus ou moins ergonomiques où les deux mains sont séparées. Tohuvabohuo 10 avril 2008 à 14:28 (CEST)

Même sur des claviers droits standard, [B] n'est pas accessible des deux mains : toutes les méthodes de dactylographie affectent cette touche à l'index de la main gauche ; du coup, produire un « Ô » deviendrait pénible. {^} doit rester sous la main droite ! Kaze 22 avril 2008 à 09:00 (UTC)

Ça me paraît plus que pertinent… (et je n’y ai même pas pensé…) Conserve-t-on cette proposition ? Mon avis c’est que non.Nemolivier 23 avril 2008 à 09:05 (UTC)

De plus, j'aimerais attirer l'attention sur la différence entre ˇ et ˘. Tohuvabohuo 10 avril 2008 à 14:28 (CEST)

Quelle est la fréquence du {K} par rapport aux différents caractères circonflexés en Français ? J'ai l'impression que le rapport est nettement en défaveur du {K}, or il me semble moins fatiguant de replier l'index que de le tendre vers le [Y] de l'azerty, ce qui aurait tendance à à me faire pencher en faveur de l'inversion (cela dit, la carte d'accessibilité des touches me contredit). --Aldoo 11 avril 2008 à 16:44 (CEST)

Même si on définit un clavier français, je pense que l'on est nombreux à taper des mots en anglais. Et dans cette langue, K (et H) se rencontrent assez souvent Herisson 17 avril 2008 à 13:36 (UTC)

H ailleurs

Le pb est que sous E ou I (en fonction du placement des doigts) HE/EH et HI/IH sont fréquents, de même que pour P et O. Il faut donc trouver une lettre qui ne combine pas beaucoup avec E et I.

La page qui détaille la précédente proposition (inversion HX voire triangulaire HXÀ) de Nemolivier à ce sujet est ici

On peut désormais fournir des statistiques pour comparer les possibilités suivantes :

• À droite

• HX comme indiqué ci-dessus, mais avec des statistiques plus complètes.
• Triangulaire H→X et X→À et À→H
• Triangulaire H→X et X→Q et Q→H
• Autre ?

• À gauche

• inversion HY
• inversion HÀ

L’argument principal pour le rejet de l’inversion HY était la difficulté du du digramme [H:] ({CH}), cet argument est aussi opposable pour les « triangulaires ». Pour ma part, je suis très content de cette inversion HX. Nemolivier 10 avril 2008 à 16:52 (CEST)

Je suis en train de tester la triangulaire HXÀ. Ça ne fait que deux jours. Justifié par le fait que le À est plus courant que le X, et pas dans des digrammes avec I ou E. Sur nos claviers pourris, là où ça « coince » immédiatement, c’est pour le digramme [WS] ({UX} avec ce que je teste). Ce n’est pas dramatique d’autant que le petit doigt sur la rangée du bas et l’annulaire sur celle du milieu, on respecte la longueur des doigts (l’inverse aurait été très nul), ça se fait bien. Mais je dois reconnaitre que le trigammes « eux » ne m’est pas encore naturel… avec une disposition en colonne type typematrix ce serait tout de suite mieux. Nemolivier 10 avril 2008 à 16:52 (CEST)

Le À à la place de clavier bépoH n’est pas trop dérangeant et du point de vue mémotechnique je m’y suis fait assez rapidement. J’avais peur pour les digrammes CH et TH mais je dois avouer qu’ils passent bien et comme après il y a une voyelle à la main gauche cela respecte l’alternance. Écrire « philosophie » devient un jeux d’enfant. Par contre le X pose un peu problème surtout si tu as des difficultés pour les UX qui est un digramme très fréquent. Je me demande si ce n’est pas dû au manque d’habitude de bouger le petit doigt. Pour le trigramme EUX je dois avouer que le X tombe naturrelement sous l’auriculaire et que ce n’est pas le plus difficile : « exact » est assez costaud.

Bref je suis mitigé à cause du X mais je me dis que c’est de la faute de mon petit doigt gauche sous entraîné. (Au début du bépo j’avais du mal à taper le M et le F et maintenant ça va tout seul).Tiot 17 avril 2008 à 20:32 (UTC)

J'aime bien l'idée de mettre le Q en {H}. Si je comprends bien la triangulaire, le H se retrouverait en {X} et le X en {Q} ? Je suis moins attirée par la triangulaire HXÀ. Je n'ai pas testé (je ne suis pas encore assez à l'aise avec le clavier), mais la proximité de À et A est un bon moyen mnémotechnique... Flocondeneige 10 avril 2008 à 18:36 (CEST)

Pour un caractère aussi courant que le À, l’argument mnémotechnique a moins de valeur, je trouve. Nemolivier 11 avril 2008 à 09:39 (CEST)

Je ne sais pas pour la triangulaire HQX. Premièrement, je voudrais des chiffres ! Fréquence des digrammes, etc. Ensuite C’est mettre X sur une touche très accessible (index droit) et Q à une place bien que théoriquement accessible, pratiquement compliquée sur les claviers qui ne sont pas en colonnes (c’est là le débat). Or Q a une fréquence de 20889 et X de 5928… De plus, ça met le digramme QU — soit le plus fréquent des digrammes avec Q (20350, 9ème digramme de la langue française —, sur une main, avec deux doigts adjacents, le plus long des deux (le majeur) sur la rangée du bas et le plus court (annulaire) sur la rangée de repos. Et avec le décalage de la rangée du bas ça fait une position très écartée pour deux doigts qui sont assez liés (ils ont un petit bout de tendon qui relie leurs extenseurs, parlez en à Schumann). Posez vos doigts sur le clavier, c’est assez évident. Pour finir, après ce digramme QU, qu’a-t-on ? Une voyelle… encore main gauche, essayez le QUE dans cette configuration… Pour moi, c’est non direct, ça ne devrait même pas apparaître dans les proposition de la page principale. La triangulaire HXÀ ou l’inversion HX, malgré leurs défauts, sont bien mieux. Nemolivier 11 avril 2008 à 09:39 (CEST)

Une idée encore plus tordue... Pourquoi ne pas mettre le Q sur {À} ? Ça ne serait pas forcément un gain de temps pour « qua », mais serait redoutable pour « qui », « que » et même probablement pour « quoi » puisque le mouvement difficile sur OI serait compensé par l'efficacité sur QUO. Du coup, on pourrait mettre le À sur {H} pour le laisser au milieu des voyelles, mettre le X sur {Q}, et récupérer sa place pour le H (afin qu'il ne soit pas sur le même doigt que le C). Je laisse ceux qui ont de l'expérience me dire si c'est complètement stupide ou pas ! Flocondeneige 13 avril 2008 à 06:37 (UTC)

C'est surtout gênant pour ceux qui comme moi (et on est pas si rare!) placent les doigts de la main gauche à gauche sur la ligne du bas. Dans ce cas Q serait ici juste en dessous de U… Nbrodu 13 avril 2008 à 07:19 (UTC)

Ça peut toujours se discuter mais j’aimerai qu’on m’explique d’où vient cette idée soudaine que les trigrammes d’une main sont facile à faire, ergonomiques, permettent d’aller vite et ne surchargent pas le schéma moteur… Je radote, mais QU est le 9ème digramme en fréquence, le mettre sur une seule main me semble une très mauvaise idée. D’autant que, comme tu le notes, on tombe sur des tétragrammes d’une main ! Toutes les lettres qui suivent QU sont des voyelles, on a donc toujours un digramme d’une main dans les trigrammes QUx (et plus encore dans les enchaînements comme QUOI) faire passer le Q à gauche en fait donc forcément des trigrammes d’une main. Je n’ai pas de fréquence des trigrammes mais à mon avis les QUx ne sont pas rares du tout. Où est l’intérêt ? Nemolivier 13 avril 2008 à 08:37 (UTC)

En l'occurrence, j'y ai pensé quand j'étais en train de pianoter sur mon bureau. Rien de tel que d'avoir les doigts dans une position à peu près naturelle et d'enchaîner auriculaire-annulaire-majeur-index. Enfin, c'est mon avis, et je suggère, c'est tout. Je suis loin d'avoir suffisamment d'expérience sur le projet pour prétendre avoir raison sur tout ce que je dis ! Flocondeneige 13 avril 2008 à 09:59 (UTC)

Moi, il me plait bien le trigramme QUE (annulaire-majeur-index) dans la disposition Leboutte-Mouëtte. Difficile de faire un trigramme mieux coordonné que celui-ci (trois doigts différents, frappe vers l'intérieur) ! Le QUOI est déjà un peu plus accrobatique dans cette disposition par contre. --Aldoo 16 avril 2008 à 15:00 (UTC)

Je n'ai pas vraiment d'avis sur la question précédente, mais Nemolivier, est-tu en train de suggérer que la synchronisation des deux mains serait plus efficace que la synchronisation « majeur-index » (et vice versa) d'une même main, par exemple ? Skippy le Grand Gourou 15 avril 2008 à 10:13 (UTC)

Sur un digramme index-majeur sur les touches de repos la « synchronisation » est au pire équivalente. Mais le problème c’est si les digrammes concernés passent d’une ligne à une autre. Il est aussi question de ce que font les doigts avant et après un digramme d’une main. Si c’est déjà (ou encore) cette main que travail (le petit doigt sur la rangée du bas dans ce cas-ci), on perds de l’efficacité, oui, je pense. Et de la vitesse c’est certain. Nemolivier 15 avril 2008 à 14:00 (UTC)

Finalement, on propose quoi ? La triangulaire HXÀ ? Flocondeneige 20 avril 2008 à 17:15 (UTC)

Le problème de la triangulaire HXÀ est que le digramme UX, à cause de cette saleté de décalage n’est pas génial. Or UX c’est… 3500 digrammes ! Cela dit, tout le reste est parfait (les digrammes avec H, la place du À) et je pense que c’est une petit contrainte a laquelle on peut se faire. Mais je trouve qu’il faudrait que plus de personnes donnent leur avis. Tu as essayé ? Concernant l’inversion HX, il n’y a rien de nouveau depuis la première fois où je l’ai proposée. Il faudrait que ce soit accepté par les autres. Sinon on va encore m’accuser de faire du forcing. Nemolivier 20 avril 2008 à 17:31 (UTC)

Bah, NRFJ a bien été reproposée dès le lendemain de la 0.6.5.1 sans justification (mais avec les stats et débats passées sur la liste, plus les nouveaux utilisateurs et une plus grande phase de test, je n'ai rien contre la reproposer). Pour X/H (et ses variantes dont X/H/À) je pense que de même on peut le reproposer, d'autant plus que maintenant on va avoir des stats complètes, venant compléter tes explications, et portant sur l'intégralité des digrammes impliqués. Par exemple, pour UX, on peut compter précisément le gain/perte de digrammes à un doigt sur différents Corpus. Après, chacun votera en fonction des critères qu'il/elle estime le plus important (stats brutes, ressenti, arguments physiologiques, règles d'alternance, calcul d'énergie, corpus employé, etc.). Certains demandaient des stats avant de se prononcer lors du vote précédent, ils en auront. Nbrodu 20 avril 2008 à 19:33 (UTC)

Comme pour toute modification que je propose, les stats étaient fournies lors de la dernière proposition d’inversions HX. Et plus que ça : analysées, les digrammes classés selon leur facilités, etc… tldr. Quelle que soit l’inversion (HX ou HXÀ) UX n’est jamais un digramme a un doigt. Encore une fois, les stats ne suffisent pas, sinon je ne critiquerais pas les résultats de l’algorithme. Nemolivier 20 avril 2008 à 21:09 (UTC)

Je viens de faire le changement pour tester sur mon clavier. Malheureusement, je n'ai pas grand-chose à taper pour l'instant. Cela dit, je ne vois pas trop où est le problème avec UX. EUX passe sans souci, et on a un peu de temps pour bouger l'auriculaire dans EAUX… « Philippe », philanthrope et philo s'écrivent beaucoup plus facilement. Je cherche des défauts, mais je n'en vois pas (et je n'ai pas eu de souci pour taper ce texte rempli de X et de H).

Merci de tester. C’est surtout pour AUX et EAUX que je m’inquiète un peu. Mais je pense que ce changement est de toutes façons bénéfique. Nemolivier 21 avril 2008 à 09:01 (UTC)

Je trouve que le H à droite est plutôt bénéfique. Par contre je ne vois pas l'avantage entre l'inversion X/H et la triangulaire XHÀ. Il y a des arguments pour le XHÀ au lieu du XH ?Tiot 22 avril 2008 à 12:03 (UTC)

Oui, bien entendu :o). En fait au début j’ai seulement interverti H/X et c’était déjà bien. Mais. Mais (et je le savais déjà, ayant fait les stats) les digrammes avec X+voyelle, bien que moins nombreux que ceux avec H, ne sont pas rares. Or donc UX/XU (mauvais sens des doigts long/court), XE/EX, XI/IX, XO/OX… se retrouvais en toute relative « mauvaise » posture. Ainsi l’idée est-elle venue d’une inversion supplémentaire avec le À. À n’a presque pas de digrammes tout en étant plus courant que X, donc la place sous l’index lui va très bien ! XA/AX se fait maintenant a un doigt mais ça représente… 192 digrammes. Ces explications se trouvent déjà sur la page concernée… Nemolivier 22 avril 2008 à 17:05 (UTC)

Cela paraît censé, je ne voyais pas trop la différence parce que j'ai tendance à taper le clavier azertyC avec l'index et non le majeur.Tiot 23 avril 2008 à 06:49 (UTC)

Hum… le problème c’est que quand tu auras ton typematrix, tu feras [C] avec le majeur… (enfin j’espère) Nemolivier 23 avril 2008 à 08:41 (UTC)

Comme Tiot je place mes doigts de la main gauche en « A », et je n'ai pas de typematrix. Peut-être un « A-shape » nous conviendrait-il mieux… En attendant je suis d'accord avec toi que le À combine moins que le X, on a même discutté de cette idée ensemble sur IRC quand elle a été lancée. Ceci dit, je teste aussi l'inversion AU… et tant que je n'ai pas finalisé les stats je préfère garder la possibilité d'une HX simple. Quand j'aurai les stats pour AU+HX, AU+HXÀ, HX simple, HXÀ simple, voire aussi pour Q y'a pas de raison, et le tout pour chaque placement des doigts (dactylo et A-shape), là c'est possible qu'il y ait des simplifications à faire en effet. Nbrodu 23 avril 2008 à 09:00 (UTC)

Le « A shape » est totalement anti-ergonomique et même contre productif : le petit doigt n’a plus en charge que le Maj gauche (voire la 105ème touche, aucun intérêt) et l’index se retrouve avec [C], [V] et [B] a gérer. On ne peux pas changer la méthode de dactylographie. Le clavier est nul, c’est une contrainte avec laquelle nous nous débrouillons. Ce n’est pas parce que vous avez le droit de ne pas respecter les règles dactylographiques qu’il faut le faire « payer » aux autres ;o). De plus je suis totalement opposé au fait de faire passer Q sur la main gauche même avec l’inversion AU. Ça reste un digramme très courant, le faire a une main d’un doigt long sur la rangée du bas vers un doigt court sur la rangée de repos, c’est totalement nul. Poses tes doigts (majeur sur [C]) [QC] ou [SC] c’est l’écartèlement. Nemolivier 23 avril 2008 à 09:14 (UTC)

Oulà… doucement. Je ne fait pas l'apologie du A-shape, je précise juste que sur un clavier à touches décalées on est nombreux à placer nos doigts gauche à gauche pour pas avoir à se tordre la main et garder un bon alignement avec le bras. Quand au Q je suis aussi d'accord qu'il semble ne pas apporter d'avantages, comparé au À. Ma remarque était simplement que je suis en train d'établir des stats pour tout ça et que je préfère attendre qu'elles soient sorties (d'ici quelques jours) avant de supprimer les propositions. Nbrodu 23 avril 2008 à 09:36 (UTC)

Non non je ne suis pas en A shape ou je ne sais quoi. Mon index est bien sur le [F] mais je tape le [C] avec l'index, [X] avec le majeur et [W] avec l'auriculaire. C'est pour cela que je ne voyais pas la différence (en testant) entre l'inversion HX et la triangulaire ÀHX. Étant donné que j'ai une « mauvaise » utilisation du clavier, que les dactylos et les utilisateurs des claviers droit tapent [C] avec le majeur. Je pense qu'il est plus logique de faire la triangulaire.Tiot 23 avril 2008 à 12:01 (UTC)

Espaces insécables automatiques pour « »

L'idée est d'ajouter automatiquement un espace insécable après/avant les guillemets ouvrant/fermant.

Option : Il est possible de le faire pour la disposition bépo sans pour autant interférer avec les autres dispositions proposant éventuellement les guillemets.

Je ne sais plus dans quelles langues (Allemand, entre autre) mais les guillemets « français » sont aussi utilisés. «Sans insécable» ou »inversé« (et sans insécables aussi). Reste à dire que nous privilégions le français… jusqu’où.Nemolivier 10 avril 2008 à 16:44 (CEST)

Ne peut-on pas envisager d'ajouter l'espace insécable aux guillemets français, et d'utiliser Compose + « < » + « < » et Compose + « > » + « > » lorsqu'on a besoin de "«" et "»" sans espace ? Tohuvabohuo 12 avril 2008 à 08:19 (CEST)

Oui, il suffit de proposer un accès simple avec l'espace (français privilégié), et un autre sans l'espace. Il reste de la place… Skippy le Grand Gourou 15 avril 2008 à 10:04 (UTC)

J’aime bien cette idée. Nemolivier 17 avril 2008 à 08:54 (UTC)

Mettre « » en AltGr avec les insécables

Les insécables automatiques changeant la donne par rapport au vote en 0.6.5.

Plussoyons en chœur... Les guillemets sont de toute façon sans intérêt sans les espaces qui vont avec, et sachant que la plupart des applications (que je connais) remplacent automatiquement les guillemets anglais par les français, voire n'acceptent pas ces derniers (LaTeX), autant favoriser les <> (qui sont en plus très utilisés par les programmeurs pour (presque) tous les langages).Skippy le Grand Gourou 10 avril 2008 à 13:49 (CEST)

Je croyais que le Dvorak était d'abord fait pour le français puis pour la programmation. De plus à ma connaissance la plupart des clients mails, des navigateurs internet et des clients de messagerie instantanée ne convertissent pas les " en « ». Et je suis persuadé que la plupart des utilisateurs tapent plus de texte avec ces logiciels qu'avec OpenOffice ou LaTeX.Tiot 10 avril 2008 à 14:42 (CEST)

En effet, de nombreux logiciels ne remplacent pas automatiquement les " par des « » : clients mails, IRC… C'est une des raisons pour laquelle le vote a été de garder « » en direct pour la 0.6.5 (et que j'ai alors voté neutre). Cependant l'ajout automatique des insécables change la donne : les guillemets + insécables auto en AltGr sont plus faciles que « suivi de shift-espace dans la disposition actuelle, ce qui permet d'en profiter pour que <> soient aussi plus accessibles. Au final on gagne sur les deux plans, plutôt que de ne gagner que sur un seul si « + espace auto reste en direct. Nbrodu 10 avril 2008 à 15:04 (CEST)

Propositions dépendantes:

Choix des caractères en direct sur 23 :

• <> : Ceci à l'avantage de ne pas affecter d'autres touches

┬────┬────┬────┬────┬
│2  ≤│3  ≥│4  “│5  ”║
│< «⍽│> ⍽»│(  [│)  ]║

• () : Ceci à l'avantage de mettre les parenthèses sur un couple de doigts forts. Les parenthèses bénéficient à tous les francophones, pas juste aux programmeurs. Cet avantage des parenthèses serait un argument de plus pour «  » en AltGr

┬────┬────┬────┬────┬
│2  “│3  ”│4  ≤│5  ≥║
│( «⍽│) ⍽»│<  [│>  ]║

Choix de l'emplacement des guillemets :

• Sur 23 : Ceci à l'avantage de ne pas affecter d'autres touches. Cf dessins ci-dessus.
• Sur É et P : Ceci à l'avantage de rendre les guillemets encore plus accessibles que sur 23 (mais entraîne d'autres changements). Cf dessins dans la section suivante.

Libérer AltGr É et P

• On déplacerait alors & et ´ mort ailleurs, cf les propositions dans les autres sections
• Ça libère une place privilégiée (accessible par deux doigts longs sans bouger les autres de la position de repos) pour y mettre une paire logique de caractères. Propositions candidates :

• «  » avec insécables
• <>
• []

Il faudra réaliser pendant la phase de dépouillement une ou plusieurs solutions synthétiques pour y placer une paire, afin d'éviter une multiplications des propositions possibles et de proposer aux votants quelques solutions simples et équilibrées. Nbrodu 17 avril 2008 à 08:44 (UTC)

On descend «⍽ et ⍽» sur É P

• & et ´ prennent les places par échange (compatible avec ` mort sur AltGr-6)

┬────┬────┬────┬────┬
│2  ˝│3   │4  ≤│5  ≥║
│(  ´│)  &│<  [│>  ]║
┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
  ¦│É  “│P  ”│O  Œ│È  `║
  |│é «⍽│p ⍽»│o  œ│è  `║

Ou encore: on descend [] au lieu de «» dans le premier dessin ci-dessus

Ou encore:

────┬────┬────┬────┬────┬────┬──
1   │2  ˝│3   │4  ≤│5  ≥║6   │7
"  `│(  ´│)  &│<  [│>  ]║_  —│ +
══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──
  ║B  ¦│É  “│P  ”│O  Œ│È   ║!  ¡
  ║b  |│é «⍽│p ⍽»│o  œ│è  `║ˆ  ˇ

Où tout le monde y gagne:

• L'enchaînement guillemets-insécable est plus facile que dans la version actuelle
• Les parenthèses sont sur deux doigts forts et non sur deux fois l'index
• On récupère <> en direct
• On récupère l'accent grave mort ` en AltGr au lieu de Shift+AltGr
• & et ´ mort sont toujours accessibles

Proposition pouvant être remplacée si æ sort de la home row par:

──┬────┬────┬────┬────┬
  │2  ≤│3  ≥│4  ˝│5   ║
 —│(  ]│)  ]│<  ´│>  `║
╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬
║B  ¦│É  “│P  ”│O  Œ│È   ║
║b  |│é «⍽│p ⍽»│o  œ│è  `║
╩╗───┴┬───┴┬───┴┬───┴┬───┴
 ║A   │U  Ù│I  ˙│E  ¤│?  ¿║
 ║a  &│u  ù│i  ¨│e  €│,  ’║

Qui reprends les avantages précédents en y ajoutant une meilleure accessibilité pour & ´mort [ ].

il serait bien que tu ajoutes la proposition de déplacement du æ à cet endroit. Ça clarifierait les choses. Nemolivier

Il y a ci-dessus (dans les sections concernées) au moins 4 possibilités: æ en Compose, æ en AltGr+V, æ en AltGr+Q, æ en AltGr+À. Le principal ici est que æ soit mis ailleurs, pour que cette proposition soit applicable (quel que soit l'endroit ou æ se retrouve). A contrario, cette proposition peut aussi être un argument supplémentaire pour mettre æ ailleurs ! Nbrodu 20 avril 2008 à 20:35 (UTC)

Il n’empêche que la proposition de vote se doit d’être claire, avec peu de choix. Ne pas oublier que, par exemple, æ en À modifie la place du « ~ » il faut une proposition pour palier a cette modification. Nemolivier 20 avril 2008 à 21:14 (UTC)

Cf la liste de Fred dans la section concernée. Il faudra dans la phase de mise en forme reprendre les choix un par un: voulez-vous æ ailleurs, oui ou non? on y met & ou ~? voulez-vous «» en direct ou altGr? sur 23 ou ÉP ? Voulez-vous () ou <> en direct sur 23 ? [] ou «» sur ÉP? On pourrait faire des dessins pour chaque proposition, avec plus de temps. Nbrodu 20 avril 2008 à 21:58 (UTC)

Touche morte « lettres grecques »

L'idée a été lancée sur cette page et sur celle-ci de créer une touche morte « lettres grecques ». Voici donc une section pour soumettre cette idée.

• Proposition: Placer « lettres grecques » au lieu de l'actuel µ. µ devient accessible par « grecque » + m, comme indiqué ici, ou tout simplement par double pression ou par « grecque » + espace (comportement identique aux autres touches mortes).

µ a été introduit par référence à l'azerty qui le propose, mais n'est utilisé en Français que pour désigner les millionièmes d'unités (comme µm), soit vraiment pas fréquemment (sondage : Combien de fois l'avez-vous réellement utilisé, mettons, au cours de l'année passée ?). Par contre les autres lettres grecques sont non seulement utiles mais réellement fréquentes en math, physique, statistiques... et pour taper du Grec aussi ! Et actuellement la seule option disponible pour les taper (hors éditeur spécialisé) est une table de caractères. Qui plus est la double pression sur la touche morte conserve pour µ une accessibilité privilégiée par rapport aux autres lettres grecques, pour les millionièmes. Nbrodu 13 avril 2008 à 06:44 (UTC)

On peut noter de plus que % et ‰ sont sur la même touche que µ et qu'ils ne sont accompagnés que par des chiffres (qui eux sont en majuscule). Place-t-on la touche morte « lettres grecques » en accès direct ? A2 13 avril 2008 à 09:16 (UTC)

Le % devrait toujours être en majuscule si on part du principe qu'il est tapé après les chiffres du clavier (cela pose un problème si on tape avec le pavé numérique). Par rapport au µ je pense qu'il faut le garder pour des raisons historiques et que je ne vois par qu'elle autre lettre il faudrait privilégier. Personnellement j'utilise quelque fois dans les phrase les µm mais très peu les autres lettres grecques (à part dans les formules).Tiot 14 avril 2008 à 11:41 (UTC)

Même si en utilisateur exclusif de LaTeX, je n'en ai pas personnellement l'utilité, j'aime beaucoup l'idée de rendre accessibles toutes les lettres grecques grâce à une touche morte. Dans ce cas je ne vois aucune raison de conserver le µ, l'« historisme » n'a pas lieu d'être à mon avis (sinon, vive l'azerty…). Skippy le Grand Gourou 22 avril 2008 à 14:08 (UTC)

• Placer la touche morte lettres grecques sur altgr-{g} et décaler le rond en chef mort sur altgr-{q}. De cette façon, la touche morte lettres grecques aura une bonne accessibilité, son emplacement sera facile à mémoriser, et on libère le shift-{%} pour la brève morte. Gaëtan 19 avril 2008 à 08:13 (UTC)

Figer les caractères de la carte simplifiée

Il arrive un moment où il faut s'arrêter. La 0.6.6 serait alors la dernière version pour laquelle les caractères de la carte simplifiée auraient bougés. Ceci permettrait également typematrix de faire une skin pour le bépo. Gaëtan 7 avril 2008 à 12:42 (CEST)

Autant je comprend l'impatience des utilisateurs d'avoir une version stable, et les intérêts d'une companie comme TypeMatrix d'avoir des garanties sur la stabilité (qui par ailleurs bénéficie aussi les utilisateurs car on aurait des beaux claviers!) ; et autant il reste encore bien des questions en suspens. On a pas règlé la place du H par exemple. Le W est trop loin pour l'anglais, langue courante (bon OK, c'est un argument personnel, mais...). Tes propres travaux Gaëtan montrent que l'index gauche est surchargé (on la propose cette inversion P/O pour 0.6.6?). Le corpus pourrait être amélioré. Etc. Autant faire une version 1.0 pour la symbolique de la chose ne me gêne pas, autant ce serait dommage de figer le layout tant qu'on a même pas établi les règles d'ergonomie permettant de juger un peu plus objectivement une inversion, carte d'accessibilité des touches, et placement des doigts. Le projet actuel est déjà assez mature pour donner lieu à une disposition sympa, mais ce n'est pas la seule dvorak-fr qui existe (il y en a même d'autres comme celle-ci avec des années de recherche derrière). Quelle légitimité avons-nous, avec un faible nombre de votants et des règles pas finalisées ? Mon avis est qu'on en a assez pour proposer quelquechose qui tiens la route car déjà bien testé, mais pas assez pour figer « une fois pour toutes » le layout. Désolé de jouer le rabat-joie, mais il y en a encore pour des années de boulot... Donc, une version 1.0 pourquoi pas, mais on se garde la possibilité d'évoluer, voire de faire une 2.0 complètement différente. Si ce point est clairement établi avec les partenaires commerciaux comme TypeMatrix en particulier, ils peuvent quand même sortir s'ils le souhaitent un layout basé sur la 1.0 en connaissance de cause, mais au moins on est honnête et on ne les prends pas en traître si on évolue par la suite. Nbrodu 7 avril 2008 à 19:29 (CEST)

Comme il est dit au dessus, il arrive un moment ou il faut s'arrêter. Il est vrai que le clavier n'est pas parfait, qu'il y a surement des marges d'amélioration, mais je pense sincèrement qu'elles sont faibles. En plus les gens qui participe au projet de longue date sont de plus en plus irrités par les propositions de modifications bien souvent peu justifiées à leurs yeux. Il faut reconnaitre que les modifications proposées représente souvent une amélioration faible du clavier dans sa globalité, ou parfois (souvent ?) une remise en question des choix faits par le passé (altgr symétrique, clavier d'abord pour le français, version technique, etc.). Donc l'idée est de figée les choses importantes et établies depuis longtemps pour faciliter l'adoption du bépo (ou la création de claviers par ex). Après ça, on achève les réflexions qu'on a sur les caractères secondaires, et les implémentations techniques pour arriver à une version finale. En parallèle, on continue le travail commencé sur les corpus, les régles, la carte d'accessiblité, etc, et on évalue la nouvelle disposition obtenu et la disposition stable. Il y a de bonne chance, à mon avis, que l'écart soit faible, et qu'on ne reparle plus de nouvelle disposition. Et non, je ne veux pas inverser O et P : c'est des changements bien trop négatifs dans les digrammes — c'était juste une mauvaise blague. Gaëtan 7 avril 2008 à 20:27 (CEST)

Pour synthétiser les deux réactions précédentes en une phrase, un faible nombre de votants dont la légitimité est surtout (sans doute pas pour tous, évidemment) historique en a marre de voir ses décisions remises en question par les nouveaux arrivants... J'imagine que si les choses sont fixées une fois pour toutes alors qu'un nombre de plus en plus important de gens rejoignent le projet, un fork devrait rapidement voir le jour... Skippy le Grand Gourou 7 avril 2008 à 22:03 (CEST)

Pour synthétiser la réaction précédente, Skippy est un boulet qui n'a rien compris au problème : nos améliorations sont mineures en terme de confort, mais sont un vrai frein à l'adoption du bépo. Gaëtan 7 avril 2008 à 22:17 (CEST)

C'est pas une raison pour devenir désagréable, c'est pas vraiment le lieu pour les attaques personnelles... Pour moi, pour une version stable au moins l'alphabet doit être définitivement figé. Ce n'est pas encore le cas, visiblement. Voir les débats R/N F/J, les histoires de H et je ne sais quoi d'autre. Skippy le Grand Gourou 8 avril 2008 à 11:13 (CEST)

Disons que compte tenu des votes très serrés concernant RNJF, par exemple, ce ne seront jamais des questions tranchées. La preuve, elle est déjà à nouveau au vote. L’histoire du H (en fait de la rangée sous la main gauche), c’est parreil : c’est un problème de hardware, que l’algo ne prends pas en compte. Nemolivier 8 avril 2008 à 12:01 (CEST)

En même temps, ça risque pas d'avancer très vite avec le genre de discution non argumentées que l'on (moi le premier) tient ici... Pourquoi, pour des changements de cette importance, ne pas regrouper tous les arguments sérieux et motivés, la problématique, etc. dans une page pour chaque inversion, comme celle que tu as faite pour X/H, et faire en sorte que les votants prennent le soin de peser le pour et le contre avant de voter ? (C'est une suggestion d'ordre général, te sens pas visé... ;)) Skippy le Grand Gourou 8 avril 2008 à 14:13 (CEST)

Bon, pour résumer un peu ce qui s'est dit sur IRC, on est d'accord avec Gaëtan que de sortir une version stable et continuer à bosser à côté est une solution. Et aussi de la nécessité d'un corpus représentatif des usages réels, de règles ergonomiques bien établies, d'une carte d'accessibilité des touches, et d'une base utilisateur. (Je rajoute ici mon avis d'une CàT y compris avec modificateurs, et un algorithme incrémental pour tester unitairement et un peu plus objectivement les inversions). On a recensé principalement ces points de désaccord:

• Comment nommer les versions: stable vs développement, 1.0 vs finale, etc. Autrement dit comment apparaître suffisamment stable pour attirer du monde tout en se gardant la possibilité d'une v2, etc.
• Sur l'adéquation de la version actuelle avec les besoins utilisateurs. Gaëtan pense que « nos améliorations sont mineures en terme de confort » alors que je pense (et Skippy aussi visiblement) que des problèmes récurrents bien identifiés (comme la position du H) sont au moins à règler avant une 1.0 (et si on peut le faire en 0.6.6 tant mieux).
• Sur ce qui va sortir d'une version ultérieure, en termes d'améliorations par rapport à la version stable, ou si on fera différent mais au final pas beaucoup mieux. Le seul moyen étant de tester on est d'accord sur le fait de continuer une version ultérieure.

Nbrodu 7 avril 2008 à 23:53 (CEST)

Salut, il n'y a pas de problème particulier à avoir deux version du clavier : une pour les utilisateurs qui est relativement stable et une pour les développeurs où tout peut-être testé à une échelle relativement grande. Le noyau Linux a fait ça pendant longtemps avec un certain succès. Pour les numéros de version on peut imaginer que les versions 1.0.x soit stable et 1.1.x soient expérimentales. Au bout d'un certain temps et d'un vote la 1.1.x devient la 1.2.0 et on continu la branche expérimentales sur la 1.3.x etc. Après tout le problème réside dans le fait de savoir si la version actuelle peut-être stabilisée (donc mis en version 1.0.0) ou si des améliorations sont encore possibles et souhaitables. Moi je suis nouveau et je pense que c'est à ceux qui ont une expérience qui doivent en décider.Tiot 8 avril 2008 à 09:01 (CEST)

Bonjour, je pense aussi qu'il faut stabiliser le clavier de base car l'expansion du Bépo est "à ce prix". J'utilise la version 0.6.4 et frappe (pas vite !) à 10 doigts. Je pense ne pas être le seul à ne pas vouloir changer de config tous les 6 mois, donc il faut figer. Si les évolutions de la 0.6.5 sont confirmées en 0.6.6, je les adopterai si la config de base est figée. PS : je n'ai pas compris comment créer une proposition de changement, j'aimerais que le "&" revienne, comme en 0.6.4, sur la touche "é" (pour une raison mnémotechnique)... Signature Herisson 13 avril 2008 à 16:53 (UTC)

Je plussoie un peu tout le mode : il serait bon de figer un layout simplifié (la couche de base, sans AltGr). C'est déjà long et fastidieux d'apprendre un nouveau layout et de nouveaux raccourcis clavier (voire d'adapter son IDE au layout pour les développeurs), sans avoir à douter en plus de la pérennité du layout. Et je pense qu'un layout simplifié «figé» devrait porter un numéro de version 1.0. En attendant la version 1.0, et plutôt que de figer un layout dans l'urgence, je crois qu'une version "stable" du layout (0.6.x par exemple) serait un plus pour les utilisateurs lambda, et qu'il serait plus facile d'obtenir l'intégration d'une version "stable" dans Xorg, même si ce n'est pas une version définitive. Kaze 15 avril 2008 à 11:21 (UTC)

Comment y arriver

2 propositions se sont dégagées de nos débats avec Gaëtan:

• Proposer de figer en même temps que le vote de la 0.6.6.
  • On voie assez bien quel sera le layout de la 0.6.6 pour décider de le figer ou non.
  • Cela permet d'éviter un nouveau vote et de gagner du temps.

OU

• Attendre de connaître le layout de la 0.6.6 avant de voter.
  • On ne voie pas assez bien quel sera le layout de la 0.6.6 pour décider de le figer ou non.
  • On fait un nouveau vote dès la sortie de la 0.6.6 pour savoir si on la fige ou pas.
  • Ce nouveau vote dure, mettons, 2 semaines, pour que les potentiels absents puissent avoir une opportunité de voter.

Note: Dans les deux cas on ne fixe que la Carte Simplifiée. Ce qui donne donc une branche dite « stable » où on ne s'autorise que des modifications de caractères secondaires, et une branche dite « développement » en parallèle.

Gaëtan, dis-moi si ce résumé te convient (et enlève cette dernière phrase après !) Nbrodu 18 avril 2008 à 06:09 (UTC)

Mettre en place un mécanisme de « Release Candidates »

Il s'agit là d'un mode de fonctionnement utilisé dans de nombreux des projets de logiciel libres. On pourrait s'en inspirer pour notre projet.

Quand on a décidé de faire une version dans la branche « stable » (cf vote précédent), le mécanisme de « release candidate » est le suivant:

• Si ce vote passe, on renomme la version en cours en version-rc1, puis:
  • On fait de la communication, un appel à testeurs.
  • A l'issue d'une période fixe (généralement 1 mois) où de nouveaux testeurs sont arrivés, et aussi où les membres du projet on l'occasion de tester le layout, on a du retour sur sa qualité.
    • On vote pour renommer la rc1 en release tout court ou faire une rc2 prenant en compte les remarques éventuelles. Si rc2, on boucle. Si le vote passe :
    • Release et nouveau plan de communication.
  • Les remarques éventuelles non prises en compte dans la release sont reportées sur la prochaine version de la branche « stable ».

Votre avis ? Nbrodu 18 avril 2008 à 06:26 (UTC)

Je crois que je suis plutôt pour cette idée d’une série de RC, de prendre un peu de temps pour faire les choses bien. Mais. Ne peuvent voter pour la RC que des personnes qui l’utilisent (ça a l’air bête, mais bon). Et surtout, je m’inquiète de voir de nombreux testeurs arriver qui n’auraient absolument pas suivi le projet jusqu’alors. Je ne suis pas certain qu’il faille les faire voter. Peut-être une sortes de questionnaire suffirait-il. Ou quelque chose comme ça. Sinon on va encore se retrouver à répondre aux mêmes questions, à avoir des votes de personnes qui n’ont pas pensé aux tenants et aboutissants, qui ne savent pas l’historique du projet, etc.

Je pense aussi que pour les votes de la 0.6.6, il faut très clairement séparer les votes qui auront une influence sur cette carte simplifiée de ceux qui n’en auront pas. Nemolivier 18 avril 2008 à 09:04 (UTC)

Si on fige une version « stable », pourquoi devrait-ce être la 0.6.6 (forcément peu testée) plutôt qu'une version antérieure ? Par exemple, Hardy Heron est livré en standard avec la 0.6.2.1.1. Par ailleurs, je ne suis pas sûr qu'en l'état le projet soit suffisamment avancé pour une release candidate, une version « stable » avec un numéro 0.x serait déjà un progrès. Juste mes deux centimes. Kaze 25 avril 2008 à 20:33 (UTC)

Déplacement du & (retour sur {é})

Bonjour, Utilisant la version 0.6.4. (et pas participé au vote de la version 0.6.5), je viens de voir que le & a été déplacé. J'aimerais que le retour du & sur la touche {é} au lieu de {p} soit soumis au vote. C'est bêtement mnémotechnique ce qui n'est pas un argument "solide" mais pour un caractère peu utilisé, je pense que c'est recevable. Herisson 14 avril 2008 à 17:45 (UTC)

Bonjour. Je suis d'accord avec toi sur le plan mnémotechnique. Personnellement, moi aussi j'aimerais cet annulation. Cependant, ton argument de caractère peu utilisé ne tiendrait pas la route selon les programmeurs… YDB 14 avril 2008 à 17:54 (UTC)

Chiffres en direct

Je reviens avec cette proposition que l'on a faite plusieurs fois, sans vraiment trop en discuter. Va-t-on conserver les chiffres en accès majuscule ? Dans ce cas :

• Ce serait le seul clavier Dvorak à ne pas avoir les chiffres en accès direct. Sommes-nous les seuls malins à avoir compris ? Ou au contraire, sommes-nous dans l'erreur ?
• Un poste de travail ergonomique n'a pas de pavé numérique intégré au clavier, au moins pour les droitiers (ceux-ci peuvent éventuellement mettre un pavé numérique indépendant à gauche). D'autre part, les ordinateurs portables, de plus en plus nombreux, n'ont en général pas ce pavé numérique. Les arguments qui disent que les chiffres en accès directs ne servent à rien à cause du pavé numériques ne sont donc pas justifiables (mais ce n'est que mon avis).
• Si on mettait au moins les symboles demandant un espace insécable en Maj+chiffres, cela serait une moindre gène.

Votre avis ? Rideĉjo 15 avril 2008 à 13:56 (CET)

• Se sont-ils contentés (comme nous peut-être) de reproduire ce qui était sur leurs claviers « natifs » ? Sans plus réfléchir ?
• Les vrai poste de travail ergonomiques (clavier droit) et les portables ont un numlock qui crée un pavé numérique sous les doigts. On peut aussi, étant droitier mettre sa souris… à gauche ! N’était les vieilles habitudes, les longues séries de chiffres devrait être tapées sur ces pavés bien plus adaptés qu’une rangée de chiffres.
• Il ne manque que les guillemets (et, plus compliqué, le tiret sur cadratin) et plusieurs propositions dans cette page tentent elles aussi de régler le problème.

Je continue a trouver que c’est une perte de place pour un ensemble de caractères qui disposent déjà de plusieurs solutions d’optimisation. Nemolivier 15 avril 2008 à 13:13 (UTC)

J'ai déjà proposé cette amélioration dans la ML. Au vu de la croissance de vente de PC portables, l'accès direct aux chiffres serait à la fois utile et aussi une amélioration immédiatement visible par rapport au clavier Azerty, ce qui pourrait aider à une plus large diffusion du Bépo. L'implémentation sans changer le placement des lettres n'est pas trivial, une idée pourrait être de mettre "=" à la place de [²], garder les chiffres comme sur l'Azerty puis mettre sur [à] l'opérande "+" (et "-" en Maj) et en [)] * (et / en Maj). C'est juste une idée de départ qui doit être discutée.

« amélioration immédiatement visible » pour ceux qui estiment qu’il est une nécessité à ce que les chiffres soit en accès direct… Nous n’avons aucune certitudes que cet accès direct faciliterait une plus large diffusion du bépo. Cet argument n’est valable que pour toi. Je ne suis pas certain qu’il le soit pour l’ensemble des personnes qui utilisent un clavier au quotidien. Il faudra bien choisir… on ne peut pas avoir «/», </> et (/) et les chiffres en accès direct. Nemolivier

Les chiffres en accès direct me paraissent de très loin préférables pour tout le monde, pas seulement les développeurs. En utilisation professionnelle on a toujours des nombres au milieu du texte ; or, il me semble bien plus important de pouvoir saisir un nombre « dans la foulée », comme n'importe quel mot, plutôt que des caractères tels que <«/»> qui sont de toutes façons hors du flot. Par ailleurs, je crois que le principal défaut de l'AZERTY (tel que perçu par les utilisateurs lambda), c'est justement les chiffres en accès indirect ; même un pavé numérique ne résout pas le problème de la saisie des nombres dans le flot du texte. Je pense donc que ça serait un bénéfice immédiatement visible par tous les utilisateurs francophones. Kaze 17 avril 2008 à 17:04 (UTC)

Le problème c'est qu'il n'y a pas que /, lui-même déjà assez fréquent pour les URLs, le shell unix, les commentaires... Hors programmeurs tu as - le trait d'union, et surtout, les parenthèses (regarde juste les textes sur cette page). Prendre 10 places en accès direct implique de se priver de tout ça. Mettre les parenthèses sur [)] et [=] n'est pas top pour leur accessibilité. Faire des trous dans les chiffres est possible mais faudrait vraiment le tester pour voir le gain réel par rapport à une disposition logique en Shift. Bref, tant qu'on a pas de solutions pour mettre ()- au moins... Nbrodu 17 avril 2008 à 20:47 (UTC)

C’est une demande tellement courante qu’elle demande que nous nous y penchions (encore). Personnellement, de caractères de barre, j’utilise couramment (plusieurs fois par jour) : «, », (, ), -, /, *, =, % (ce sont les commentaires en TeX…). Avec des aménagements on pourait enlever : « et » (qui passent en altgr,</> serait en Maj.). Le « % » en Shift ne serait pas un drame. Admettons que ce soit identique pour les parenthèses. Ce qui m’embêterai vraiment, serait de « perdre » : « / », * et naturellement « - », le plus important. Et j’imagine que d’autres auraient d’autres exigences. Pourriez-vous expliquer pourquoi le ShiftLock ne vous plaît pas, ceux qui l’ont enlevés ? Nemolivier 17 avril 2008 à 22:43 (UTC)

Le ShiftLock n'est pas satisfaisant dans le cadre d'une utilisation professionnelle, où l'on a très souvent recours aux nombres pour exprimer des quantités, des montants ou des dates ; de plus, on n'utilise que très rarement plusieurs caractères tels que "<>()_+-/* à la suite, contrairement aux chiffres. Kaze 22 avril 2008 à 11:27 (UTC)

Quoiqu'il en soit, c'est une évolution pour une future version. Je pense que la priorité est d'abord de figer la position des lettres. Voyant les nombreuses suggestions d'évolutions, il serait peut être plus efficace, à l'avenir, de définir l'axe majeur d'évolution pour une version donnée, de travailler dessus et ensuite de figer l'évolution. La définition du Bépo est maintenant bien avancée et de toute façon bien plus ergonomique que les autres claviers. Figeons les lettres puis les chiffres (si la demande est confirmée) enfin les "autres" caractères et ensuite que soit clairement expliqué à ceux qui le veulent le moyen de programmer leur propre placement sous Windows et Linux.Herisson 17 avril 2008 à 13:30 (UTC)

On a un article place des chiffres pour débattre de ça plus longuement qu'à chaque version si vous voulez. A2 17 avril 2008 à 15:19 (UTC)

L'article sur la place des chiffres est fort intéressant en tant que liste comparative de solutions. Mais la synthèse reste à faire ou bien le résultat des discussions précédentes a t il été de garder les chiffres en indirect ? Comme les avis ont l'air divergent sur ce point, j'itère ma proposition qu'une fois le layout de la 0.6.6 figé, il soit soumis au vote le passage des chiffres en direct car la finalisation du placement des "caractères secondaires" en sera fortement affectée. Il est fort probable que l'utilisation du PC influe sur l'avis de chacun (bureautique vs programmation par exemple) , mais peut on figer le layout sans avoir tranché sur ce point qui revient de manière régulière ? Herisson 19 avril 2008 à 12:52 (UTC)

Ce qui est certain c’est que les propositions de vote pour la version 0.6.6 c’est demain, dimanche. Pour que ce sujet soit mis au vote il faut une vraie proposition, avec des solutions aux problèmes posés (comme le tiret, les parenthèses), et ce n’est pas encore le cas (ou alors la proposition est une simple inversion de l’existant). Nemolivier 19 avril 2008 à 13:58 (UTC)

Où

Suite à la discussion IRC de hier (merci jofo), il s'agirait d'apparier ù avec o automatiquement car « ù » n'est utilisé en Français que pour « où ». Le « ù » restant de toutes façons disponible avec l'accent grave mort + « u », et de même pour sa majuscule. Ce qui donnerait :

• « où » en clavier bépoAltGr+clavier bépou
• « Où » en clavier bépoMaj+clavier bépoAltGr+clavier bépou
• « OÙ » en modification Caps-Lock.

Pour tester, il suffit d'ajouter les deux lignes suivantes dans son .XCompose :

<ugrave> : "où"
<Ugrave> : "Où"

Nbrodu 15 avril 2008 à 13:48 (UTC)

Je suis en train de tester… mais je n’ai pas encore écrit de « où » (à, si, ça y est…). Je continue a trouver ça un peu tordu. D’autant que le raccourcis pour « où » (\o/) se trouve sur le {U}, il serait plus légitime en {o}. Passons. Je trouve que si cette proposition est acceptée il faut qu’elle le soit conjointement avec une inversion « `mort » « ` ». De façon à ce que le « `mort » soit sur AltGr. Nemolivier 16 avril 2008 à 11:45 (UTC)

Sinon, partant du principe que le fait d'entrer plusieurs caractères à partir d'« une seule » touche peut en désorienter plus d'un, je proposerais bien une solution indolore pour tout le monde : garder le {ù} où il est, et mettre "où" en compose+o+u pour les utilisateurs avancés (cette manière de faire me semble en tout cas plus intuitive). Inconvénient : il devient difficile de taper {ů} (dans quelle langue on trouve ce caractère, en fait ?) --Aldoo 16 avril 2008 à 14:46 (UTC)

Je suis désolé, mais ça me semble totalement illogique comme proposition. Un « où » en Compose (dont on ne connait toujours pas l’emplacement) nécessiterait 3 frappes là où la situation actuelle n’en nécessite que deux très accessible et où la proposition avec AltGr n’en fait plus qu’une. Que gagne-t-on avec un accès en compose ? Je pense qu’un « utilisateur avancé » n’utiliserai jamais cette solution. Nemolivier 17 avril 2008 à 08:19 (UTC)

Sous windows pas moyen d'obtenir OÙ en capslock pour le moment. Sinon pour les «  d'omne pas de problème. A2 16 avril 2008 à 21:23 (UTC)

En effet. Avec MSKLC, ce serait possible en accès direct, mais pas en Alt Gr. Stéphane, le pilote que tu as compilé pourrait-il être adapté pour avoir « où » en Alt Gr + {U}, « Où » en Shift + Alt Gr + {U} et « OÙ » en Caps Lock + Alt Gr + {U} ? Tohuvabohuo 17 avril 2008 à 09:40 (UTC)

Je ne sais pas si cette option du CapsLock+AltGr+{U} est intéressante. Je pense que dans le cas — rare — d’une nécessité d’écrire OÙ, le plus simple est d’utiliser l’accent grave mort (en AltGr ?) pour le mettre sur le U. Je suppose que c’est une question de logique. Les deux peuvent cohabiter, naturellement. Je continue quoi qu’il en soit a trouver que cette une solution du « où » automatique, bien que séduisante pour nous qui sommes « le nez » dans nos claviers, n’est peut-être pas une bonne chose pour l’utilisateur final. Nemolivier 17 avril 2008 à 10:07 (UTC)

S'il n'y a vraiment que « où » qui porte un u grave en français je ne vois pas pourquoi l'utilisateur final serait déboussolé. Ça permettra de lui faire savoir que les ligatures existent et qu'il peut les utiliser sur sa dispo perso. En vieux français on trouve pas mal de ù (il y en a en italien également). A2 17 avril 2008 à 14:51 (UTC)

Euh, dans la situation actuelle, si je ne m'abuse, "ù" est en AltGr+{u}, donc tapper "où" demande trois frapes, comme dans ma proposition... à la différence près que le compose est rémanent, donc bien plus facile. Maintenant ma proposition a plein d'autres défauts. --Aldoo 17 avril 2008 à 16:13 (UTC)

Tu as bien raison, mais AltGr+U c’est une frappe simultanée, elle ne compte donc que pour une seule, ce qui fait un total de 2. Sinon nous n’aurions pas utilisé de AltGr mais des compose partout Nemolivier 17 avril 2008 à 16:46 (UTC)

Alors, je suis en train de tester. Et pour le moment, je suis contre. Certes, on peut sans doute s’y faire. Mais je trouve qu’il y a un problème de logique dans le fait qu’on obtienne « où » avec un « raccourcis » sur « U ». Ce serait sur O, à la limite, je comprendrais, mais là je trouve que c’est trop capilotracté ! Que des geek du claviers le fassent dans leur coin, très bien, mais le proposer pour une normalisation, je ne suis pas d’accord. Nemolivier 21 avril 2008 à 09:16 (UTC)

Uniformisation du comportement des touches mortes

Tout le monde semble s'accorder sur le fait d'uniformiser le comportement des touches mortes sur tous les OS. La page Touches mortes décrit un comportement qui est réalisable sans problème avec windows et mac os, mais pose des problèmes sur linux, car les touches mortes sont définies pour une locale, et ne peuvent donc pas être modifiée sans modifier le comportement des autres claviers :

• la touche morte dead_acute suivie de espace et la touche dead_acute pressée deux fois ne produisent pas le même signe ;
• même chose pour la touche dead_diaeresis.

Ce comportement est décrit sur Portabilité#Préservation du comportement des touches mortes.

Plusieurs options :

• implémenter sous windows et sous mac le même comportement que sous linux ;
• proposer à l'utilisateur linux d'obtenir le même comportement que sur les autres OS grâce à un fichier Compose optionnel ;
• réimplémenter complètement ces deux touches mortes sous linux pour obtenir le comportement souhaité sans modifier le comportement des autres claviers ;
• accepter ces (petites) différences sous linux. Glehmann 16 avril 2008 à 18:29 (CET)

AltGr symétrique

Voici les différentes propositions de placement:

• clavier azertyAlt gauche devient Alt Gr et clavier azertyCtrl droit devient Alt

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║      ║     ║                           ║     ║      ║     ║      ║
║ Ctrl  ║ Win  ║AltGr║                           ║AltGr║ Win  ║Menu ║ Alt  ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

• clavier azertyWin droit devient Ctrl et Win droit est replacé en clavier azertyMaj+clavier azertyWin gauche (certains environnements font la différence entre Win Gauche et Win Droit)

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║ WinD ║     ║                           ║     ║      ║     ║      ║
║ Ctrl  ║ WinG ║AltGr║                           ║AltGr║ Ctrl ║Menu ║ Alt  ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

• clavier azertyMenu devient Ctrl et Menu est replacé en clavier azertyMaj+clavier azertyWin gauche

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║ Menu ║     ║                           ║     ║      ║     ║      ║
║ Ctrl  ║ WinG ║AltGr║                           ║AltGr║ WinD ║Crtl ║ Alt  ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

• clavier azertyMenu devient Ctrl, clavier azertyWin droit devient Menu et Win droit est replacé en clavier azertyMaj+clavier azertyWin gauche

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║ WinD ║     ║                           ║     ║      ║     ║      ║
║ Ctrl  ║ WinG ║AltGr║                           ║AltGr║ Menu ║Ctrl ║ Alt  ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

J'ai déplacé les dessins de Laurent ici pour pouvoir plus facilement rajouter des commentaires. Nbrodu

Pourquoi déplacer Ctrl Droit pour y mettre Alt quand c'est la touche WinD qui disparait dans les dessins ci-dessus? Les combinaisons Ctrl+flèches et Ctrl+Shift+flèches sont des raccourcis pratiques pour se déplacer mot à mot et sélectionnner les mots. Laissons Ctrl le plus proche possible des flèches!

Par exemple:

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║      ║     ║                           ║     ║ WinG ║     ║      ║
║ Ctrl  ║ Alt  ║AltGr║                           ║AltGr║ WinD ║Menu ║ Ctrl ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

ou

╠══════╩╦═══╧══╦═╧═══╦╧════╧════╧════╧════╧════╧═╦══╧══╦═╧════╬═════╦══════╣
║       ║ WinD ║     ║                           ║     ║      ║     ║      ║
║ Ctrl  ║ WinG ║AltGr║                           ║AltGr║ Alt  ║Menu ║ Ctrl ║
╚═══════╩══════╩═════╩═══════════════════════════╩═════╩══════╩═════╩══════╝

Il faudrait aussi prévoir de laisser un Alt (c'est à dire ne rien changer) quand les touches Win ne sont pas présentes. Nbrodu 19 avril 2008 à 21:11 (UTC)

Et comment faire ça ? A-t-on les « moyens » qu’en fonction du type de claviers le pilote s’adapte automatiquement ? (sachant qu’il est bien courant que l’os lui-même ne sache pas si telle ou telle touche est présente…). Nemolivier

Je disais juste qu'il faudrait qu'on ait toujours accès à la touche Alt si il n'y a pas de WinD/G pour l'y mettre. Par exemple il y avait des versions du AltGr symétrique qui plaçaient un Alt sur [²]. Maintenant je n'ai pas de solution à proposer, je fais juste la remarque. Pour la détection automatique je ne pense pas. Le seul moyen simple que voie serait de fournir plusieurs pilotes en fonction du layout, mais cela irait à l'encontre d'une disposition unique. À moins comme dit Laurent que de toutes façons sous Mac avec la touche Pomme la différence des modificateurs (et leur rôle comme pas de Alt) soit déjà un fait établi, et alors on aurait une version Mac différente. Mais bon, là je ne connais pas les Macs donc je ne me prononcerai pas. Nbrodu

J'ai proposé Alt sur clavier azertyCtrl droit plutôt que sur une touche clavier azertyWindows, justement pour éviter des problèmes avec les claviers qui n'ont pas de touche clavier azertyWindows (ou n'en ont qu'une, ce qui est fréquent sur des claviers récents, notamment de portables, mais pas seulement). Concernant le Ctrl+flêches, je pratique aussi à l'occasion, et je trouve bien plus pratique d'utiliser la touche Ctrl gauche...

Sinon, il me semble que quelqu'un avait fait sur la ML une proposition qui impliquait pas mal de permutations mais présentait un résultat très intéressant, mais je ne suis pas arrivé à la retrouver. Si l'auteur voulait bien la refaire, ce serait le moment. Laurent 20 avril 2008 à 01:02 (UTC)

Euh... Sur mon eeepc où je me trouve actuellement, j'ai une touche ctrl, win (enfin... maison, mais c'est pareil) et alt d'un côté, et altGr et menu de l'autre. Avec altGr symétrique, je perds l'une de ces touches... Flocondeneige 20 avril 2008 à 17:13 (UTC)

Je pense que symétriser AltGr est une fausse bonne idée :

• sous Windows™, on peut faire un pseudo AltGr gauche avec Ctrl+Alt (en perdant la position de base pour l'auriculaire gauche) ;
• sous Windows™ toujours, redéfinir les modifieurs suppose un bidouillage de la base de registre et s'applique à tous les layouts du système, pas seulement au Bépo ;
• sous les autres systèmes d'exploitation, il est facile de redéfinir le comportement des modifieurs avec xmodmap ;
• l'emplacement des touches Alt/AltGr (sous les pouces) rend possible, sinon confortable, d'accéder à toutes les combinaisons Alt+touche ou AltGr+touche.

Je pense que l'approche la plus censée consiste à dissymétriser la couche AltGr, en gardant tous les caractères courants sous la main gauche, comme c'est le cas actuellement - du moins pour la plupart des caractères utilisés en français. En complément, je suggérerais plutôt de remplacer {Ê} par une touche AltGr morte, ce qui, à défaut d'être parfait, reste confortable et implémentable proprement sous toutes les plate-formes, sans remettre en cause les raccourcis clavier usuels. Kaze 22 avril 2008 à 10:04 (UTC)

Une autre alternative - plus violente - serait de mettre cette touche AltGr morte en [I], comme suggéré sur ma page perso… Kaze 24 avril 2008 à 09:42 (UTC)

Ajout de caractères en indice sur le hatchek mort ???

Vu sur la page de vote :

Ajout de caractères en indice sur le hatchek mort « ˇ »

Les caractères en indice : ₀ ₁ ₂ ₃ ₄ ₅ ₆ ₇ ₈ ₉ ₊ ₋ ₌ ₍ ₎

D'où sort cette proposition ??? Ils sont pas bien en circonflexe mort ??? Skippy le Grand Gourou 27 avril 2008 à 15:48 (UTC)

On parle ici de caractères en position inférieure, ou indice, ceux liés a « ^ » sont en position supérieure, ou exposant.

Effectivement, j'ai lu trop vite et ai confondu indice et exposant. Quoiqu'il en soit, rajouter les indices est une excellente idée, mais on aurait dû discuter de la position avant. Skippy le Grand Gourou 27 avril 2008 à 18:30 (UTC)

[NB: Je m'étais planté de page en cherchant une éventuelle trace de discussion concernant cette proposition.]

D'un point de vue mnémotechnique, je trouve que la cédille morte (ou autre diacritique inférieur : point souscrit, ogonek) serait plus indiquée pour les indices. Kaze 27 avril 2008 à 20:14 (UTC)