Discussion v2:Méthodologie

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}}).

Nouvelle ébauche de projet de v2 par Robipo

(Note d’A2 : cette discussion a été très mal menée, évitez d'utiliser un sommaire en pdd, il vaut engager un nouvelle discussion pour chaque sujet. Là on a du mal à suivre le fil des discussions. Les pages de discussion doivent servir à élaborer les articles correspondants. – A2 3 février 2013 à 16:30 (UTC))

Robipo Pour s’y retrouver et éviter d’avoir des discussions qui partent dans tous les sens, je propose le plan suivant qui correspond à un plan temporel (ouvert aux critiques)

1. Corpus et Clavier (pour Bépo corpus = Thomas Tempé, et clavier = standard décalé français (TODO : quelle Méthode de saisie a été utilisée ? std,t6,o0,A))
2. Algorithme (pour Bépo voir http://www.bepo.fr/wiki/Cr%C3%A9ation_de_la_version_0.1)
3. Ajustements (pour Bépo voir les logs de la ML ?)

Corpus et Clavier

Corpus

Corpus "informatique" (principaux languages de prog, shell unix, etc)

Ce point me gène. Les langages apparaissent, évoluent et meurent. Voir « figer » une disposition sur du mouvant me parait impossible. Enfin, si. Mais faut re-figer tous les 6 mois. *_Si_* j’ai raison (prions que je me trompe), ça va vite vous faire chier.

J’espère cette fois avoir su m’exprimer clairement.

Fork Bomb 19 octobre 2012 à 13:31 (UTC)

D'une part les choses bougent sur une période de temps bien plus longue que 6 mois. L'index TIOBE (qui vaut ce qu'il vaut, mais qui a le mérite d'exister) donne dans le top 10 : C, Java, Objective-C, C++, C#, PHP, (Visual) Basic, Python, Perl, Ruby. Mis à part C#, tous ces languages ont au moins 15 ans (et C# en a 10), voir beaucoup plus.

D'autre part, les languages populaires ont tendance à réutiliser des caractères similaires : {} pour les blocs, [] pour les tableaux, ; pour les fins de lignes, etc.

Enfin, il faut bien bouger et faire quelque chose, quitte à mettre à jour la dispo dans 10 ou 15 ans. Une disposition rationnelle des caractères spéciaux, basée sur la technique actuelle, sera toujours mieux que celle au petit bonheur la chance de la V1 (sans AltGr symétrique, qui plus est).

Arathor 20 octobre 2012 à 03:29 (UTC)

En effet, si on regarde bien, on a les paires (), [], <>, {}, /\, les signes mathématiques +-*/=, logiques &|!, et les autres :,~^"'`$#*%@;. Ça fait beaucoup de signes mais ce sont toujours les mêmes !

Sinma 20 novembre 2012

Ne pas compter les raccourcis claviers, mais encourager les projets qui permettent d'utiliser les raccourcis claviers en Azerty. Il est par exemple possible dans KDE d'activer le Bépo avec les raccourcis claviers d'Azerty dans les logiciels en Qt mais pas en GTK. J'ai fait un rapport de bug à ce sujet. Sinma

Garder les raccourcis clavier de l'azerty n'est qu'un début (ÀMHA une jambe de bois palliant un manque) mais pour aller plus loin on peut encourager les soft qui proposent l'édition de ses propres raccourcis perso. GTK posait déjà des problèmes avec les caractères morts pour les symboles monétaires et les lettres grecques, obligé de passer en XIM, donc privilégier autre chose que GTK mais c'est dommage sur Gnome ou Xfce… Espérons qu'ils vont rapidement mettre à niveau cette bibli. XavierC 12 novembre 2012 à 01:37 (UTC)

Oui, mais c'est plus rapide, plus facile, et tu fais quoi des touches dans les jeux qui ne supportent pas les caractères non ASCII, les sites webs usant de raccourcis claviers… C'est peut-être une jambe de bois mais on ne peut faire autrement à l'heure actuelle. Ou c'est en tout cas la façon la plus simple de répondre à un problème très courant (ah, les jeux Flash en Qwerty… :D). Sinma

Il faut vraiment que () et [] soient frappés par des touches différentes, en programmation c'est super relou. Par ailleurs, il m'arrive souvent d'ouvrir des parenthèses ou des crochet puis de les remplir ensuite, ce qui est aussi très chiant. À mon avis, un gros défaut du Bépo c'est les symboles: @ en accès direct, <> pas accès direct, et le défaut sus-cité. Sinma 9 janvier 2013 à 15:14 (UTC)

Langues étrangères

Dans la section « Déterminer l’ordre des priorités » on distingue les langues de l’UE des autres langues étrangères, principalement parce que les utilisateurs occidentaux ont plus de chance d’écrire dans une de ces langues. Mais une bonne partie des francophones vivent en Afrique et sont souvent polyglottes. Je pense que de la même façon que les langues européennes ont un « statut » spécial, les langues parlées dans les zones francophones devraient aussi bénéficier de ce « statut ». J’ai commencé à lister ces langues et les lettres associées sur la page User:LeBret/Bépo_dans_le_monde.

J’ai conscience que cela ajoute beaucoup de lettres (cela repose la question des variantes). Mais cela me semble important d’autant que ces langues sont rarement bien supportées par l’informatique.

LeBret 29 octobre 2012 à 20:28 (UTC)

L'idée n'est pas mauvaise, mais ton tableau il fait peur… même en rajoutant une touche morte en altgr de chaque touche, ça rentrerait probablement pas… Arathor 31 octobre 2012 à 20:57 (UTC)

La solution pourrait être d’ajouter, en plus des deux touches d’accès au 3me niveau (Alt Gr), deux touches d’accès au 5me niveau. Ça ferait un total de 8 niveaux, ce qui doublerait presque l’espace disponible. Si l’on y ajoute une touche Compose facilement accessible, il n’y a plus de limites, si ce n’est l’impossibilité d’implémenter ladite touche Compose dans PKL (le pilote portable pour Windows) sans en modifier le code. Tohuvabohuo 7 novembre 2012 à 23:58 (UTC)

Clavier

Robipo : Je vote pour faire une version standard avec utilisation de pondération, et de laisser la possibilité aux utilisateurs avancés de se génerer leur propre disposition à leur risques et périls, mais pour avoir une disposition totalement optimisée.

Sinma : Comme maintenant quoi… Je pense que c'est une bonne idée mais à condition d'encourager un max les retours utilisateurs, pour essayer de ne pas avoir de retour négatif (certains doigts trop chargés, position du Z et du W, symboles de programmation…) C'est à dire une bonne partie de ce qui a engendré les dispositions dérivées du bépo.

Je pense qu'il y a deux choses distinctes ici : le ou les types de clavier visés d'une part, et d'autre part l'utilisation (taper du français uniquement ; mélange français/anglais ; informaticien ou non). Pour plusieurs raisons différentes, il vaut mieux une seule version officielle et éventuellement d'autres versions à côté.
http://bepo.fr/wiki/V2#Variantes_ou_pas
Pour les types de claviers supportés, je pense que la cible de base reste les claviers pc10X (ce qui inclue les 102, 103, 104) mais qu'il faut aussi prendre en compte les claviers ergos. Je suis pas certain que la méthode de Robipo (0.8 std + 0.1 typematrix + 0.1 TE) donne un résultat intéressant, mais je me trompe peut-être. À mon sens une manière efficace de prendre en compte les claviers ergos (notamment les symétriques, +1 avec XavierC) c'est avec des contraintes du style « pas de lettres sur le pavé auxiliaire ». Arathor 9 novembre 2012 à 14:23 (UTC)

le type de clavier est discuté ici, l'utilisation est prise en compte par le corpus (cf partie précédente) : merci d’en parler là-bas (en l’occurrence, je pense que pour le corpus/utilisation une méthode similaire serait également le mieux (à savoir pondérations par ex 0.8fr 0.1en 0.1divers pour une version officielle et possibilité de faire des versions custom)). Je pense que pondérer les claviers ergos ou utiliser des contraintes du style pavé auxilière auront un résultat similaire niveau stats finales (bien que l’utilisation de pondérations risque aussi de donner des modifications plus fines, par exemple l’accessibilité de certaines touches changeraient suivant que ce soit un clavier ergo ou clavier décalé, ce qui serait difficile à décrire via des contraintes, sans passer par les pondérations sus-citées). Robipo 9 novembre 2012 à 20:40 (UTC)

Avant de penser Pondération, mieux vaut faire tourner l'algorithme avec cette idée du multi-critère http://bepo.fr/wiki/Id%C3%A9es_pour_une_v2#Multi-crit.C3.A8res (En prenant le français en critère fixe?) puis par la suite déterminer plus finement avec la pondération. On aura ainsi des dispositions très différentes, davantage d'opportunités et de choix.XavierC 13 novembre 2012 à 02:04 (UTC)

Claviers standards

Comme le bépo.

• Avantage : C’est la dispo utilisée par la majorité des claviers, et donc les claviers pas chers de monsieur tout le monde
• Inconvénient : En général les personnes intéressé par l’ergonomie et le bépo seront aussi intéressées par les claviers ergo, donc ce serait dommage de les handicaper (comme le bépo par défaut qui devient horrible sur le TE)

Dans son réarrangement des touches, le Truly Ergonomic fait un choix d’affectation qui n’est optimal que par rapport aux caractères qu’elles portent en Qwerty. Même pour l’Azerty, il n’a aucun sens. En considérant par ailleurs que les touches sont programmables, il ne faut donc pas s’en tenir à leur affectation par défaut pour la conception d’une disposition. Laurent 12 novembre 2012 à 06:27 (UTC)

Qui a parlé de caractères ? Quand on parle de clavier, on parle strictement de clavier, c'est-à-dire du nombre de touches, de leur emplacement et de leur dimensions. Si on lance l’algo pour prendre en compte uniquement l’agencement physique des claviers standards décalés avec touches auxiliaires à droite (ce qui est présenté ici), forcément on va avoir une disposition parfaite pour ce type de clavier, mais qui va handicaper les utilisateurs d’autres claviers (surtout les ergos et en particulier le TE). Je ne vois pas le rapport avec l’aspect programmable, qui est uniquement pour intégrer la dispo directement dans le clavier et donc pouvoir l’utiliser ensuite sur des PC sans devoir installer de driver ou autre. Robipo 12 novembre 2012 à 07:15 (UTC)

C’est moi qui ait parlé de caractères, mais c’est parce que Truly Ergonomic (la boîte) en a tenu compte : les codes touches du TE ont été réaffectés pour obtenir une disposition logique des caractères qui leur correspondent en Qwerty américain, par exemple \ et / côte à côte. Pour une autre disposition, on peut avoir intérêt à affecter les touches déplacées différemment. S’en tenir au fait que telle touche déplacée du TE renvoie tel code est une contrainte non justifiable, surtout que les touches sont sensées être programmables. Laurent 12 novembre 2012 à 17:24 (UTC)

« sensées être programmables » C'est là que réside tout le problème. Il faut avouer que le soft pour reprogrammer le firmware n'est toujours pas disponible, aucune info n'est dispo sur la license, le langage de prog utilisé, l'interface ou même la portabilité sur d'autres OS que Mac/W$. Le TE a mis tellement de temps à sortir qu'il a été pris pour un vaporware donc il est possible que le logiciel sorte (dans combien d'années ?) mais en attendant ce n'est pas le cas et dans le doute il ne faut prendre en compte que les possibilités fournies par les dip switches situés au dos.XavierC 13 novembre 2012 à 00:56 (UTC)

OK, je vais faire plus simple, oublie le TE, imagine qu'il existe un clavier ergonomique super génial mais qui a que 64 touches par exemple. Ce que je dis c'est que peut-importe quels keycode ils auraient choisi pour ces 64 touches (qu'ils aient décidé de mettre les [] qwerty à côté ou de pas les mettre tout court ou autre), si tu fais une disposition qui est étudiée uniquement pour le clavier décalé 102 touches de monsieur tout le monde, alors il sera inutilisable sur le clavier ergonomique cité précédemment. D'où l'intérêt des choix suivant (si tu pondères par exemple, alors ce seront les touches les moins importantes qui seront aux endroits inexistants sur le clavier ergo) Robipo 21 janvier 2013 à 11:17 (UTC)

Pondérer les claviers dans l’algo (par ex : 0.8std + 0.1tmx + 0.1te)

• Avantage : Adaptée à tout type de clavier, il ne devrait pas y avoir de clavier sur lequel la disposition est affreuse à utiliser.
• Inconvénient : La dispo n’est parfaitement optimisée sur aucun clavier réel, c’est une sorte de disposition optimisée pour un clavier abstrait.

Sinma : Le Truly Ergonomic ne me parait pas autant utilisé que le TypeMatrix…

Robipo : Exact, c’est juste un exemple, il est évident que la pondération finale sera sujette à de plus vastes discussions.

Ne pas suivre la mode et les tendances car si cela se trouve d'ici 5 ans le clavier ergo le plus utilisé ne sera aucun des deux cités et on se retrouvera avec les mêmes problèmes. L'idéal serait de faire une dispo par clavier mais ce ne serait pas pratique : il faudrait au moins tenir compte des grandes familles de clavier et veiller particulièrement aux prometteuses dispositions symétriques (TECK, Maltron, μTron…) qui semblent avoir le design le plus intéressant ergonomiquement. XavierC 9 novembre 2012 à 04:52 (UTC)

Sinma : Ou alors simplement faire une pondération entre claviers standards et claviers à rangées orthogonale ? (c'est à dire : essayer de prendre en compte les caractéristiques d'un clavier ergonomique sans ce limiter à ceux qui existent déjà actuellement)

même si les claviers ergos actuels n’existent plus dans le futur, les bases resteront les mêmes (pavé auxiliaire, ortho), donc les stats seront assez semblables. Si les claviers ergos du futur changent vraiment beaucoup, alors ses précurseurs pourront générer leur disposition perso, et si ils deviennent plus utilisés alors il faudra songer à une éventuelle v3. Mais franchement, ne pas pondérer les claviers ergos actuels parce qu'ils ne seront peut-être plus dans le futur, ce serait un peu comme essayer de prévoir le futur, ou genre intégrer dans le corpus des langages de programmations très récents dont on ne sait pas si ils vont avoir un succès ou pas. Robipo

Sinma : Je pense que c'est bien mieux de faire les calculs en prenant juste en compte rangées orthogonales/rangées décalées car comme dit plus haut les claviers sont sujets à variation, et d'ailleurs est-ce qu'on a pris en compte les claviers à rangées décalés avec des touches placées n'importe où? C'est plus simple, et ça permet à s'adapter à plus de claviers.

Faire une dispo par type de clavier

• Avantage : La dispo sera parfaitement optimisée (on peut imaginer que l’algo mette la touche E sur un des espaces du TE par exemple)
• Inconvénient : Faudra faire les ajustements pour chaque clavier, et pour la standardisation et la reconnaissance, c’est pas génial.

Rien n'empêche de faire une seule version officielle et de proposer en option, pour les passionnés, une version pour chaque clavier (et les outils pour personnaliser encore plus si c'est ce que veut l'utilisateur). Arathor 9 novembre 2012 à 14:23 (UTC)

Oui, c’est exactement ce pour quoi j’ai voté en introduction. Robipo 9 novembre 2012 à 20:40 (UTC)

Algorithme

Robipo : Je pense qu’utiliser un algorithme génétique est le mieux

• Croisement très facile à faire : pour chaque touche des deux dispositions parentes, on prend aléatoirement celle du père ou celle de la mère.

Pas si facile que ça en fait. Il se peut que tu mettes 2 fois une lettre en la prenant quelque part du père et quelque part de la mère. Et que tu en supprimes aussi… Amic 10 novembre 2012 à 16:22 (UTC)

• Mutation assez facile : on inverse deux caractères aléatoire par exemple aAæÆ oOœŒ donne ŒAæÆ oOœa (bon ok ce cas est complètement stupide et pour améliorer la rapidité de l’algorithme il faudrait rajouter des contraintes)

Robipo : Idée au passage avant que j’oublie : Quand on laisse tourner l’algo qui optimise les coûts, ce serait bien de voir quelques-unes des meilleures dispo de l’algo en temps réel. Au lieu de s’emmerder à faire une interface graphique, ce serait pas bête de faire que l’algo exporte en continu dans un fichier .html les dispos. Ensuite il suffirait de faire un petit javascript qui refresh en boucle l’affichage de ces dispo. (avec un peu de css on peut avoir un rendu assez sympa je pense).

Calcul des coûts

Avant de choisir une méthode, je pense qu’il faudrait faire des benchmark sur un assez gros corpus, et voir les différentes distances obtenues pour chaque méthode et voir si il y a beaucoup d’écart.

En utilisant un algo génétique on peut aussi imaginer procéder en deux phases : à partir de dispositions purement aléatoire, on fait un premier jet avec un algo rapide mais moins fiable pour obtenir une population « passable » de dispositions assez rapidement, puis on fait une deuxième passe avec l’algo qui parcourt tout le corpus et est bien fiable pour affiner la population. Robipo 9 novembre 2012 à 21:00 (UTC)

J'y avais déjà pensé, et on peut même faire mieux: un algo rapide et grossier, puis de plus en plus fin… Sinma 21 janvier 2013 à 15:40 (UTC)

Utilisation des statistiques de fréquences

• Avantage : très rapide
• Inconvénient : calcul la distance avec les doigts qui reviennent sur la disposition de repos après chaque touche. « bobo » (ou « bébé ») compte pour 4, alors qu'en réalité il vaut 2.

Tentative d’améliorer cet algo pour trouver une sorte de compromis :

Soit les fréquences suivantes :
p 2
i 7
x 1

Principe : au lieu de donner une distance de 2 pour les touches p et x et 0 pour i, comme on sait les fréquences de chaque touche, on peut dire que quand on tape un p par exemple, il y a 20% de chances qu'on était sur un p, donc distance de 0, il y a 70% de chances qu'on était sur un i, donc distance de 1, et 10% de chances qu'on était sur un x, donc distance de 2.

quand on tape P
0.2*0
0.7*1
0.1*2
tot=0.9

quand on tape I
0.2*1
0.7*0
0.1*1
tot=0.3


quand on tape un X
0.2*2
0.7*1
0.1*0
tot=1.1


Soit le corpus suivant : iiiiiiippx (pas très représentatif)
distance réelle = 1+2=3
distance robot = 2+2+2=6
distance compromis = 0.9*2+0.3*7+1.1*1=5

Soit le corpus suivant : iiiixiipip (un peu représentatif)
distance réelle = 2+2+1=5
distance robot = 2+2+2=6
distance compromis = 5

On peut peut-être améliorer l'algo en utilisant les digrammes ? (des matheux dans la salle ?)

Parcours total du corpus

• Avantage : possible de calculer la distance réelle (avec mémorisation de l’emplacement des doigts tout au long du corpus)
• Inconvénient : beaucoup plus long (bépo@home BOINC serait vraiment utile dans ce cas)

Étant donné que c'est pour faire une dispo qui ne bougera plus ensuite, j'aurais envie de laisser tourner l'algo aussi longtemps que nécessaire, pour pondre LA dispo… mais bon, je me leurre peut-être sur la difficulté et/ou le temps que ça demandera. Arathor 12 novembre 2012 à 02:59 (UTC)

Un bépo@home ça me tente vu que BOINC est la première chose que je démarre sur mon ordi. Par contre, comme Arathor, pour la mise en place je pense que ça demande beaucoup de temps et de capacités en prog (je me doute que c'est le genre de truc réalisable qu'en langage compilé donc sans debug assisté de l'IDLE), sans compter la logistique et toute la partie communication (avant et pendant le déroulement du projet). Certes, entre lancer un algo sur quelques machines en crunch et faire un projet de computation il y a un fossé mais c'est aussi beaucoup plus puissant et rapide. ÀMHA ça vaudrait le coup de s'y intéresser. XavierC 12 novembre 2012 à 04:57 (UTC)

• Optimisation possible : si l’algorithme se borne à étudier un nombre raisonnable de caractères adjacents à la fois, par exemple trois, on peut factoriser le corpus en triplets (avec le nombre d’occurences) au début de l’algorithme. Laurent 12 novembre 2012 à 17:29 (UTC)

Maximiser les roulements faciles

Nous sommes au 21ᵉ siècle, pas en 1936. Contrairement aux machines à écrire de l’époque d’August Dvorak, les claviers d’ordinateurs supportent les roulements.

Un roulement consiste à enfoncer d’un seul mouvement des touches consécutives sur une main, en baissant les doigts avec un décalage, puis à ne relâcher toutes les touches qu’à la fin.

C’est plus rapide que l’alternance des mains.

Les roulements sont plus faciles avec des doigts adjacents (ou carrément auriculaire-index), sur des touches alignées (ou avec un décalage d’une rangée avec le doigt le plus long sur la rangée la plus lointaine) et idéalement vers l’intérieur. Un roulement ne peut concerner plus de deux touches que si la progression ne change pas de direction.

Exemples de roulenents faciles en Bépo : au, ie, uie, nr, st, nt… Essayez d’écrire « pluie » en roulant.

La limite est sur le nombre de digrammes ou trigrammes intéressants, d’autant plus qu’il ne faut pas dégrader notablement la façon de faire les autres.

Maximiser l’alternance des mains

Exemple mauvais en bépo : épub dans république, beaucoup se tape presque uniquement à une main

Minimiser les m-grammes à n-doigts (n<m)

Digrammes à un doigt

Exemple mauvais en bépo : pi dans tapis, soupirer, épisode…

Trigrammes à un doigt

Exemple mauvais en bépo : bab dans probablement

Trigrammes à deux doigts

Exemple mauvais en bépo : ove dans novembre

Caractères supportés

Symboles

Si on y regarde bien il a plein de places en AltGr et en Maj + AltGr. Il ne tient qu'à nous de mettre le maximum de symboles. On peut peut-être supprimé des trucs genre le ~ en AltGr + K ne sert à rien a priori. Et puis surtout on a pleins de touches mortes, donc autant les utiliser. On pourrait avoir une touche morte de maths par exemple, ou une touche morte pour tous les symboles qui ne sont pas alphanumériques.

Je propose l'intégration des caractères suivants:

• fléches simples et doubles (avec un TMx il est impossible de faire les flèches (possible sous GNU/Linux avec AltGr et les flèches du pavé numérique))
• le point d'ironie (pourrait être placé en Maj + AltGr + apostrophe)
• Divers symboles mathématiques (symbole infini, ) et ou exclusif
• les boules utilisés pour les listes
• d'autres idées?— Le message qui précède, non signé a été déposé par Sinma (d), le 19 janvier 2013 à 17:19.

Ajustements

Car on ne peut pas tout prévoir dans l’algorithme, il va falloir faire des ajustements à la disposition générée.

Ajout de variantes de lettres grecques

Au cas où des utilisateurs souhaiteraient entrer des mots isolés sans diacritique (accent, esprit…), je suggérerais d'ajouter les deux caractères suivants pour la V2 :

• Le sigma minuscule final U+03C2 « ς », dont l'utilisation à la place du sigma minuscule standard U+03C3 « σ » est requise en fin de mot en grec ancien et moderne. Ce symbole pourrait être localisé sur le « C ». Pour information il est présent sur la disposition allemande Neo.
• Moins nécessaire mais intéressant: puisque ce symbole sigma final n'a pas de majuscule (il s'agirait du sigma majuscule standard) je suggérerais d'ajouter, en «majuscule» de cette même touche, le beta minuscule de milieu de mot, utile pour le grec ancien, de code U+03D0: « ϐ » Jidé 7 novembre 2012 à 19:10 (UTC)

Pour écrire en grec, il vaudrait mieux terminer le bépo grec qui devrait aussi gérer les nombreux diacritiques. La touche morte pour le grec n’a pas pour but de permettre d’écrire en grec, mais plutôt de permettre la saisie de lettres grecques utilisées comme symboles. Dans ce cadre, il faudrait ajouter les caractères ϑ ϒ ϕ ϖ ϰ ϱ ϴ ϵ, variantes de θ Υ φ π κ ρ Θ ε. Tohuvabohuo 8 novembre 2012 à 03:46 (UTC)

C'est aussi ce que je pensais tout en ayant oublié l'existence du bépo grec : les ajouts du bépo ne valent pas les avantages d'une disposition dédiée sur laquelle on bascule à la volée d'une simple séquence de clavier, les lettres grecques du bépo sont plus orientées vers une utilisation en tant que symboles mathématiques saisies occasionnellement qu'en tant que saisie plus littéraire comme développée sur le Neo2 —D'ailleurs son accès aux deux couches grecques est totalement différent et pensé, lui, pour la saisie de texte. XavierC 8 novembre 2012 à 05:05 (UTC)

Je voudrais maintenir qu'il faudrait ajouter au moins le « ς » — et tant pis si je ne convaincs pas car il ne s'agit que d'un détail :

1. Une fois le βηπο grec achevé, rien ne garantit qu'il soit toujours possible de switcher vers lui sur tous les types d'appareils (ordinateur professionnel avec droits limités, tablette, smartphone, etc)
2. Le clavier grec moderne inclut le « ς », et beaucoup considéreront son absence du bépo comme un oubli tant qu'ils n'auront pas pris connaissance qu'elle serait justifiée par la non-utilisation du « ς » en tant que symbole.
3. Il semble que certaines lettres grecques, pourtant disponibles dans les deux casses, ne soient effectivement utilisées comme symboles que dans l'une des deux. Cela rend moins solide l'argument de la non-utilisation du « ς » en sciences.
4. Il reste de nombreuses places libres pour des caractères supplémentaires si on prend en compte la rangée des chiffres.
5. Le coût de l'ajout est minime et permet d'écrire des mots isolés d'une langue supplémentaire (j'insiste sur l'adjectif isolé, il ne s'agit pas d'écrire des phrases), certes sans accent et avec une saisie très lente.
6. Les niveaux 5 et 6 du layout Neo qui englobent les lettres grecques ne me semblent pas adaptées non plus à une utilisation littéraire très poussée (l'écriture de phrases entières ne me semble pas un objectif de cette autre disposition) : – ne serait-ce que le τονος unique du grec moderne est absent ; – devoir alterner les modificateurs Shift+Mod3 et Mod3+Mod4 de part et d'autre du clavier me semble encore plus malcommode que la combinaison AltGr+G, lettre.
7. Je suis d'accord que les variantes et lettres supplémentaires utilisées dans les sciences et techniques devraient être ajoutées. Il faudrait établir une liste des autres symboles utiles possibles ; je pense par exemple qu’il faudrait inclure aussi les deux casses du digamma à usage mathématique que sont U+1D7CA 𝟊 et U+1D7CB 𝟋.
8. Je suis d'accord que seul un layout distinct (pour une saisie rapide et faute de place disponible sur le layout bépo) de type βηπο permettrait aux hellénistes et hellénophones de disposer des avantages d'une disposition dvorak permettant d'écrire convenablement en grec (en grec polytonique ancien avec les nombreux diacritiques — esprits, accents, iotas souscrits … — et en grec monotonique moderne avec le τονος unique). Jidé 18 novembre 2012 à 17:53 (UTC)

Pour le point 6. Apparemment les concepteurs de Neo y ont pensé et on mis un système de blocage de couche quand tu appuies sur les deux modificatrices identiques de part et d'autre du clavier. Ainsi il est possible de bloquer le clavier en mode grec et de saisir les majuscules par une simple pression de <Shift>. XavierC 20 novembre 2012 à 07:37 (UTC)

Rendre les symboles monétaires plus facile d'accès

Je propose de placer la touche morte pour l'accès aux symboles monétaires en clavier bépoAltGr+clavier bépoe. Le symbole de l'euro serait ainsi accessible en clavier bépoAltGr+clavier bépoe+clavier bépoe, la Livre en clavier bépoAltGr+clavier bépoe+clavier bépol, le yen en clavier bépoAltGr+clavier bépoe+clavier bépoy, etc. Tous les symboles monétaires sont ainsi beaucoup plus accessibles (je trouve la combinaison clavier bépoAltGr+clavier bépoMaj+clavier bépoe très peu pratique) et la baisse d'accessibilité de € ne serait que marginale. En points bonus les combinaisons clavier bépoAltGr+clavier bépoMaj+clavier bépoe et clavier bépoAltGr+clavier bépoMaj+clavier bépol deviennent libres (pour y placer € et £ ?) Jarreboum (relit l'entête de cette page STP pour éviter de devoir signer à ta place ultérieurement ;)

Je ne suis pas tout à fait sûr d'avoir bien interprété mais si ton idée c'est bien une touche morte {€} , où mettre le symbole « ¤ » ? en clavier bépoAltGr+clavier bépoMaj+clavier bépoe peut-être… On peut ne pas prendre cet espace en simplement mettant le caractère mort « ¤ » en clavier bépoAltGr+clavier bépoe et donc clavier bépoAltGr+clavier bépoe+clavier bépoe donnera {¤} tandis que clavier bépoAltGr+clavier bépoe puis clavier bépoe donnera {€} mais c'est peut-être ce que tu voulais dire, non ? XavierC 9 janvier 2013 à 02:21 (UTC)

Pardon je me suis mal exprimé, mais tu l'as bien interprété.

• clavier bépoAltGr+clavier bépoe puis clavier bépoe = {€}
• clavier bépoAltGr+clavier bépoe puis clavier bépoAltGr+clavier bépoe = {¤}
• clavier bépoAltGr+clavier bépoe puis clavier bépoy = {¥}
• clavier bépoAltGr+clavier bépoe puis clavier bépoY = {円}

En fait dans cette page rien ne change sauf le placement de {¤}. Puis-je modifier mon premier message pour éclaircissement ou faut-il le garder pour l'historique? Jarreboum 9 janvier 2013 à 14:08 (UTC)

On peut le garder pour l'historique (au pire, si ça gêne, quelqu'un fera la modif) En tout cas je suis pour car même si ça réduit l'accessibilité de {€} qui est un caractère saisi ponctuellement, ça augmente celle de tous les autres caractères monétaires et les mets tous sur la même « couche ». Edit : Je viens de m'apercevoir que cette même proposition a déjà été refusée pour la version 0.6.5.1 j'aimerais bien en connaître les raisons. Il semble que la touche morte « ¤ » venait d'être implanté et la question ne s'est jamais reposée depuis cinq ans donc ça a ptet des chances d'aboutir. XavierC 10 janvier 2013 à 05:00 (UTC)

J’avais milité pour à l’époque mais mon idée a du être mal comprise ou alors je m'étais mal fait comprendre. Ça me parait toujours aussi logique d’avoir la touche morte en clavier bépoAltGr+clavier bépoe. – A2 3 février 2013 à 16:34 (UTC)

Refonte des pages sur la V2

Les pages sur la V2 sont complètement désorganisées, incomplètes et dispersées sur le wiki. Je propose donc de revoir complètement la structure de ces pages. En général, les informations présentes sur la page devront être discutée auparavant dans la page de discussion.

Pour les pages de discussion, il y a pleins d'informations que l'on pourrait en tirer et que je mettrais donc sur ces pages; J'ai l'impression que les personnes qui s'occupent de ce wiki sont attachées à conserver l'historique des discussions, du coup je ne sais pas si on peut conserver les pages de discussion sur une page qui n'existe pas; sinon on créera une page dédiée, comme pour l'historique des versions du Bépo.

Voici ma suggestion :

Page «V2», qui consiste principalement à la présentation des principaux objectifs, caractéristiques et informations.

• Caractères supportés et priorité
  • Langues
  • Symboles
• Compatibilité
  • Matériel
  • Logiciel
• Détails (section qui contient tous les liens vers les sous-pages)
  • Données
  • Symboles
  • Aspects techniques

Sous-page «Données», une page sur toutes les informations qu'il faut/que l'on a récolté et dont on aura besoin.

• Corpus
  • Textes
    • Français
    • Anglais
    • Autre
  • Code sources? (C/C++/Java, PHP/Perl/Shell, Latex, CSS, XML/HTML)
  • Logs d'usage réel
• CAT
  • Claviers standards
  • TypeMatrix
  • Autre (pour que l'on puisse faire des variantes de la disposition pour les autres types de clavier)

Sous-page «symboles», informations sur le placement des symboles. Toutes les idées seront soumises dans la page de discussion, et s'il y a suffisamment de votes et que c'est possible, on le mettra sur la page. Autrement, l'idée finira dans les idées abandonnées, qui n'est pas cachée dans la page de discussion pour éviter les questions de personnes qui n'aurais pas eu l'idée de lire la page de discussion.

• Idées reprises de la V1
  • Symboles par paire
  • Symboles précédé d'une espace insécable en Maj
• Idées abandonnées
• Idées acceptées

Sous-page «aspects techniques» (pour tout ce qui concerne la génération de la disposition)

• Génération des statistiques
• Génération des dispositions
  • Contraintes
• Choix de la meilleure disposition
  • Simulateur de frappe
• Générateur de pilotes

Si vous avez des questions, des remarques: n'hésitez pas. Si personne n'y vois d'objection je m'en occuperais à partir du 13/02. Sinma 2 février 2013 à 13:09 (UTC)

Comme je le répète souvent sur IRC, pour une nouvelle disposition il faudrait surement un autre wiki, un autre canal de discussion, un autre dépôt et motiver les troupes (en commençant par une annonce « officielle » que l'on s'y attele par exemple). Parce qu'il va être très difficile d'arriver à un concensus maintenant qu'on a des centaines d'utilisateurs qui ont tous leurs idées et préférences(merci les outils de la v1 !). Si l’on reste sur ce wiki, il faut une solution technique, peut-être créer un nouvel espace de nom v2:… pour toutes ces pages. Du coup je crains que l'on ne finisse par recopier/recréer toutes les pages en double pour pas grand chose car à terme (si le projet abouti), on ne présentera plus que la v2 (théoriquement mieux que la v1). Du coup, on en viendrait à fusionner les pages v2 avec les v1 pour gagner en clarté et donc à supprimer cet espace de nom. Finalement que de travail pour rien. Une autre solution est peut-être plus simplement d'utiliser l'ensemble des pages actuelles : la plupart de ces pages sont peu travaillées (ou courtes), leurs pages de discussion ont peu été utilisé. Il suffit de créer de nouvelle section sur chacune propre à cette v2. Ceci n'empèchera pas quelques nouvelles pages spécifiques, dont une « centrale » de synthèse avec des liens vers toutes les autres. De toute façon, toutes ces pages ne sont pas réellement présentées au lecteur qui débarque sur le wiki (il faut fouiner) et sont des pages techniques utiles au dévelopement. Ceci dit, j'aime bien le nom du projet que l'on traine depuis un moment aka « v2 », j'espère qu'on ne va pas arriver (en 2020 ?) sur une rangée du haut du genre « bpdljz » sinon le choix du nom de la disposition risque de faire couler beaucoup d'encre… (surtout quand on voit celui du nom d'assoc !) – A2 3 février 2013 à 16:53 (UTC)