Vous n'êtes pas identifié(e).
As-tu testé avec maj et altgr à leur place d’origine, dès fois que ce soit la touche verr maj qui fasse des siennes ?
Hors ligne
Teste avec un autre clavier, mais c'est possible que ta combinaison et cette matrice de clavier ne soit pas compatible spécialement si tu as changé les modificateurs de place.
Autre piste : Les applications en gtk sont connu pour poser des problèmes. la page compose peut t'apporter une solution http://bepo.fr/wiki/Compose#Que_faire_s … econnu_.3F
GNU/Linux depuis 2/2012 : Ubuntu→ Xubuntu 4/12→ Debian (Xfce) 10/12 + Cubian 10/13
BOINC (World Community Grid) depuis 4/11 - BÉPO depuis 3/12 - Vapoteur depuis 10/13
Claviers Cherry G80-3000 (MXClear), TIPRO MID KM128A (MXBlack) Noppo MID 87 ANSI (MXRed)
Kensington Orbit trackball (à gauche), Wacom Intuos3 A4
Hors ligne
Ah très évidemment c'est verr maj qui m'embête! Si je n'utilise pas {caps lock} dans la combinaison maj + altgr, ça fonctionne nickel. Apparemment xkb ne veut pas que je l'utilise comme modificateur lorsqu'un autre modificateur est déjà enfoncé. Par contre ça ne me dit pas comment résoudre le problème...
(au passage, je pense avoir trouvé comment placer "page précédente" et "page suivante" sur le clavier: XF86Forward et XF86Back (le fichier symbols/inet contient beaucoup d'infos là-dessus )
Dernière modification par lawrent (22/4/2013 00:07:29)
Hors ligne
Bon je pense que c'est foutu pour moi... J'ai inversé les keycodes de <CAPS> et de <LFSH> dans keycodes/evdev et le problème reste le même. A mon avis c'est mon clavier qui est endommagé. Je pense que je vais placer maj sur {tab} qui est plus accessible que {maj gauche}.
Mais du coup ça me laisse {caps lock} libre pour backspace, ce qui n'est pas plus mal .
Dernière modification par lawrent (22/4/2013 00:37:32)
Hors ligne
Bon bidouillage !
On dirais moi avec ma touche ê et ma touche w (diposition bépo) qui déconne et qui du coup fait des gros hack !
Hors ligne
C'est décidé: si ma config (celle "à tester" décrite sur ma page perso) fonctionne sans bugs, je quitte définitivement azerty cette semaine (sauf peut-être quelques retours prévus au début pour des devoirs de cours à rendre).
Robin, pour ta question sur un autre fil concernant le swap j<->b "vaut-il mieux rester en bépo par souci de compatiblité avec la version bépo figée?" je pense que vu ce que tu as fait de tes modificateurs et de tes déplacements du w et ç, tu n'es plus à ce détail près . Si un jour tu dois bosser sur le pc d'un copain, autant revenir sur l'azerty. Les touches seront écrites sur le clavier
Hors ligne
C’est ce que j’ai fait. En revanche si tu modifie la place de certaines touches comme j<->b ou p<->o fait le avant d’apprendre les trigrammes. Pour moi j’ai déjà eu un peu de mal malgré la faible fréquence des touches j et b.
Hors ligne
Bon vous allez rire... Le bug de mon "3" semble se produire lorsque altgr se trouve sur {caps lock} et lorsqu'il se trouve sur {tab}. Tant pis, je laisse mon clavier comme ça et je bourrinerai pour taper mon 3.
Hors ligne
C'est ce que je disais : problème de matrice de clavier pas compatible avec le déplacement des modificateurs.
http://www.microsoft.com/appliedscience … ained.mspx
Ton fichier marchera pour sûr en utilisant un bon clavier externe avec anti-ghosting complet du genre clavier gamer mécanique à diodes (un Filco ou un Truly Ergonomic, pas un Cherry G80)
GNU/Linux depuis 2/2012 : Ubuntu→ Xubuntu 4/12→ Debian (Xfce) 10/12 + Cubian 10/13
BOINC (World Community Grid) depuis 4/11 - BÉPO depuis 3/12 - Vapoteur depuis 10/13
Claviers Cherry G80-3000 (MXClear), TIPRO MID KM128A (MXBlack) Noppo MID 87 ANSI (MXRed)
Kensington Orbit trackball (à gauche), Wacom Intuos3 A4
Hors ligne
Juste comme ça, as tu essayé ma config avec les modificateur sur la ligne supérieure. On s’y fait très bien et ça pourrais régler ton problème de caps lock/tab
Dernière modification par robin_moussu (22/4/2013 04:47:18)
Hors ligne
Dans la mesure où ces touches ne sont pas faites pour ça, ça pose aussi le risque de tomber un jour sur un clavier incompatible.
Si c’est un clavier de machine de bureau, on peut toujours le changer, mais si c’est un clavier de portable…
Mais du coup ça me laisse {caps lock} libre pour backspace, ce qui n'est pas plus mal
.
Le Colemak fait ça. Résultat sur X.org : un backspace sans répétition ! Je te laisse réfléchir à l’utilisabilité…
En fait, il y a une possibilité de spécifier dans la définition du clavier qu’une touche doit avoir une répétition ou pas, mais j’ai oublié comment, vu que la dernière fois que j’ai essayé, ça ne fonctionnait pas (une fonctionnalité que quasiment personne n’utilise n’est pas forcément trop testée ni déboguée…).
Il y a un moyen qui fonctionne, c’est (par exemple pour la touche Caps Lock),
xset r 66
mais il faut le faire à chaque fois. Généralement, les environnements permettent de lancer des programmes au lancement de la session (et s’ils ne prévoient pas de passer des paramètres, il suffit de placer la commande avec ses paramètres dans un script), mais ça reste quand même moins pratique que de le spécifier directement dans la définition du clavier…
Mise à jour : j’ai retrouvé comment spécifier qu’une touche doit se répéter ou pas. Par exemple avec backspace sur Verr. Maj., façon Colemak, ça donnerait :
key <CAPS> { type[group1] = "ONE_LEVEL", repeat = yes, [ BackSpace ] };
sauf qu’en vrai, ça ne fonctionne pas. Dommage !
Dernière modification par Laurent (23/4/2013 08:08:13)
Hors ligne
Dans la mesure où ces touches ne sont pas faites pour ça, ça pose aussi le risque de tomber un jour sur un clavier incompatible.
Si c’est un clavier de machine de bureau, on peut toujours le changer, mais si c’est un clavier de portable…
Autant pour caps lock ça me parais logique que certains clavier le gère matériellement, autant pour ctrl alt win & co ça me paraitrais plus étrange qu’il y ait une incompatibilité matérielle.
Hors ligne
Très bien vu, XavierC! J'ai testé avec xev (très pratique pour détecter les combinaisons de touches qui ne génèrent pas de keycode), <AC10> + <LALT> + une touche parmi { <CAPS>, <TAB> et <TLDE> } ne génère rien.
Robin: mettre les modificateurs sur la ligne des chiffres, très peu pour moi! Surtout que tu les places au centre de la ligne, ce qui oblige de déplacer l'index. Toutefois je vais duppliquer AltGr sur <AE01> et m'habituer à la combinaison <LALT> + <AE01> comme maj-altgr lorsque j'ai besoin du pavé numérique.
Hors ligne
Autant pour caps lock ça me parais logique que certains clavier le gère matériellement,
À mon avis, tous les claviers le gèrent de la même façon, si ce n’est que sur les claviers avec une matrice bas de gamme où le fabricant joue sur sa répartition pour permettre les frappes simultanées les plus probables, la touche Caps Lock est une bonne candidate pour être servie en dernier.
autant pour ctrl alt win & co ça me paraitrais plus étrange qu’il y ait une incompatibilité matérielle.
Moi aussi. Par contre, pour la touche 6 sur laquelle tu as mis ton Maj (par exemple), c’est moins clair…
Par exemple, le clavier de mon portable est capable de détecter que j’enfonce consécutivement (sans les relâcher) les touches [1], [2], [3] et [4] (Azerty), mais si je maintient les touches [5] et [6], il ne détecte pas que j’enfonce la [7].
Hors ligne
Pour les ctrl je les fait au majeur, et ça m’évite de bouger les poignet pour attendre la ligne de la barre espace avec les petites doigts. Pour les combinaisons chelou genre ctrl+alt ils sont côte à côte, et la touche maj au milieu c’est justement pour rapprocher tous les modificateurs. Mais j’avoue que mes touches overlay me prennent de la place.
Pour<AE01> c’est une bonne idée.
key <AE01> { [ VoidSymbol ], actions = [ SetControls(controls=Overlay2) ], overlay2 = <Ta_Touche_ALTGR> };
Hors ligne
Moi aussi. Par contre, pour la touche 6 sur laquelle tu as mis ton Maj (par exemple), c’est moins clair…
Par exemple, le clavier de mon portable est capable de détecter que j’enfonce consécutivement (sans les relâcher) les touches [1], [2], [3] et [4] (Azerty), mais si je maintient les touches [5] et [6], il ne détecte pas que j’enfonce la [7].
Tu m’a mis un doute et viens de tester avec xev. Toutes les combinaisons doubles marchent mais certaines combinaisons comme win maj droite ne marchent pas. À vrai dire toutes celles avec la touche [6] plus d’autres. Les quadruples en revanche ne posent pas plus de problèmes.
J’avoue que je ne m’attendais pas du tout à ça !
Hors ligne
Ma disposition et le fichier xkb sont sur ma page perso, normalement je ne devrais plus trop y toucher
Robin: BackSpace sur <TAB> c'est juste le bonheur !
Dernière modification par lawrent (22/4/2013 22:15:19)
Hors ligne
C’est ce que j’ai fait. En revanche si tu modifie la place de certaines touches comme j<->b ou p<->o fait le avant d’apprendre les trigrammes. Pour moi j’ai déjà eu un peu de mal malgré la faible fréquence des touches j et b.
À noter qu’échanger P et O sans toucher à I et E ferait de « oi » et « io » des digrammes à un doigt !
La seule voyelle avec laquelle O forme des digrammes moins fréquents qu’avec E, c’est A, mais mettre O à la place de B surchargerait fortement l’auriculaire.
Globalement, si l’on veut modifier la place des lettres, mieux vaut tester le résultat avec un comparateur de dispositions pour éviter de dégrader significativement la disposition sur certains critères.
Dernière modification par Laurent (23/4/2013 08:26:10)
Hors ligne
Robin: je ne sais pas si le swap b<->j est vraiment intéressant parce que du coup le digramme "mb" se fait à un seul doigt du coup
Hors ligne
Utilise donc le comparateur que j’ai mentionné juste au dessus, il prend directement des dispositions au format XKB.
Pour le corpus, tu peux soit en trouver sur le site, soit en faire un à toi.
Hors ligne
Robin: je ne sais pas si le swap b<->j est vraiment intéressant parce que du coup le digramme "mb" se fait à un seul doigt du coup
Combien de fois écris-tu cmb par jour ? !!!
ab + ba : 3500 + 3000 = 7500 occurences
mb + bm +bn + nb : 2000 + 20 + 9 + 15 = 2000 occurences
(selon http://www.lexique.org/listes/liste_bigrammes.txt)
C’est sans appel au niveau des bigrammes
Robin: BackSpace sur <TAB> c'est juste le bonheur !
24 heures pour s’y habituer mais depuis je me trompe tout le temps sur les autres ordis tellement c’est devenus naturel !
Pour ce qui est du comparateur de disposition, je ne sais pas si il est adapté (pour ma dispo complète) à cause du placement de w et k sur les touches maj, des chiffres en altgr maj qu’il a l’air de ne pas trouver. De plus il ne prend pas en compte la touche compose ni les touches mortes. En tout cas voici les résultats (comme corpus j’ai pris tout ceux présent à cette adresseque j’ai compilés dans un seul fichier)
Résultats du changement (en %) :
Charge des doigts (de gauche à droite, d'auriculaire à auriculaire)
ancien% 11,47 7,88 9,67 21,53 0,00 0,48 14,07 11,11 11,87 11,93
nouveau% 12,46 7,91 9,66 20,26 0,00 3,59 14,93 11,30 12,04 12,45
gain/perte-relative% 8,69 0,49 -0,15 -5,88 NaN 648,82 6,10 1,67 1,49 4,39
gain/perte-energy% 19,80 4,75 -2,30 -8,76 NaN 545,60 14,22 5,03 3,90 10,72
Energie : +21,65%
Accessibilité : -0,83%
Frappes vers l'intérieur : (3207807 - 3120709) / 18772202 = +0,46% absolu, +2,79% relatif
Digrammes faciles (hors alternance) : (4363905 - 4198078) / 18772202 = +0,88% absolu, +3,95% relatif
Digrammes moyens (hors alternance) : (1014818 - 726477) / 18772202 = +1,54% absolu, +39,69% relatif
Alternance brute : -1,45%
Digrammes faciles (incluant alternance) : (14987326 - 15171858) / 18772202 = -0,98% absolu, -1,22% relatif
Digrammes moyens (incluant alternance) : (3041620 - 2614647) / 18772202 = +2,27% absolu, +16,33% relatif
Digrammes difficiles : (717199 - 985697) / 18772202 = -1,43% absolu, -27,24% relatif
dont digrammes 1 doigts (touches différentes) : (411326 - 508575) / 18772202 = -0,52% absolu, -19,12% relatif
Niveau diagramme ça m’a l’air mieux. Pour la charge des doigts les données me semblent étrange (la charge est supérieurs sur tout les doigts)
et juste l’inversion b<->j
Résultats du changement (en %) :
Charge des doigts (de gauche à droite, d'auriculaire à auriculaire)
ancien% 11,47 7,88 9,67 21,53 0,00 0,48 14,07 11,11 11,87 11,93
nouveau% 11,12 7,88 9,67 21,53 0,00 0,48 14,07 11,11 11,87 12,28
gain/perte-relative% -3,04 0,00 0,00 0,00 NaN 0,00 0,00 0,00 0,00 2,93
gain/perte-energy% -6,26 0,03 0,01 -0,14 NaN -0,07 -0,00 0,00 0,00 7,64
Energie : -0,05%
Accessibilité : -0,04%
Frappes vers l'intérieur : (3200631 - 3120709) / 18772202 = +0,43% absolu, +2,56% relatif
Digrammes faciles (hors alternance) : (4198078 - 4198078) / 18772202 = +0,00% absolu, +0,00% relatif
Digrammes moyens (hors alternance) : (802230 - 726477) / 18772202 = +0,40% absolu, +10,43% relatif
Alternance brute : -0,27%
Digrammes faciles (incluant alternance) : (15171858 - 15171858) / 18772202 = +0,00% absolu, +0,00% relatif
Digrammes moyens (incluant alternance) : (2653936 - 2614647) / 18772202 = +0,21% absolu, +1,50% relatif
Digrammes difficiles : (946408 - 985697) / 18772202 = -0,21% absolu, -3,99% relatif
dont digrammes 1 doigts (touches différentes) : (488296 - 508575) / 18772202 = -0,11% absolu, -3,99% relatif
Il y a bien une diminution des digrammes à un doigt en inversant b et j et plus de digrammes moyen. Mon impression initiale semble être justifié.
Hors ligne
Pour ce qui est du comparateur de disposition, je ne sais pas si il est adapté (pour ma dispo complète) à cause du placement de w et k sur les touches maj
Ce ne sont pas des lettres très fréquentes en français.
En tout cas voici les résultats (comme corpus j’ai pris tout ceux présent à cette adresseque j’ai compilés dans un seul fichier)
Par contre, si les corpus contiennent l’apostrophe droite et que tu tapes l’apostrophe typographique, tu devrais faire le remplacement, surtout que c’est pour tester un déplacement du J, souvent suivi d’une apostrophe.
et juste l’inversion b<->j
Résultats du changement (en %) : Charge des doigts (de gauche à droite, d'auriculaire à auriculaire) ancien% 11,47 7,88 9,67 21,53 0,00 0,48 14,07 11,11 11,87 11,93 nouveau% 11,12 7,88 9,67 21,53 0,00 0,48 14,07 11,11 11,87 12,28 gain/perte-relative% -3,04 0,00 0,00 0,00 NaN 0,00 0,00 0,00 0,00 2,93 gain/perte-energy% -6,26 0,03 0,01 -0,14 NaN -0,07 -0,00 0,00 0,00 7,64 Energie : -0,05% Accessibilité : -0,04% Frappes vers l'intérieur : (3200631 - 3120709) / 18772202 = +0,43% absolu, +2,56% relatif Digrammes faciles (hors alternance) : (4198078 - 4198078) / 18772202 = +0,00% absolu, +0,00% relatif Digrammes moyens (hors alternance) : (802230 - 726477) / 18772202 = +0,40% absolu, +10,43% relatif Alternance brute : -0,27% Digrammes faciles (incluant alternance) : (15171858 - 15171858) / 18772202 = +0,00% absolu, +0,00% relatif Digrammes moyens (incluant alternance) : (2653936 - 2614647) / 18772202 = +0,21% absolu, +1,50% relatif Digrammes difficiles : (946408 - 985697) / 18772202 = -0,21% absolu, -3,99% relatif dont digrammes 1 doigts (touches différentes) : (488296 - 508575) / 18772202 = -0,11% absolu, -3,99% relatif
Il y a bien une diminution des digrammes à un doigt en inversant b et j et plus de digrammes moyen. Mon impression initiale semble être justifié.
Tu perdrais juste un peu sur l’alternance.
Cela dit, les pourcentages étant assez faibles, tu devrais vérifier que le corpus contient la bonne apostrophe.
Hors ligne
Effectivement j'utilise l'apostrophe courbe, mais ce qui m'étonne c'est que la charge de tout les doigts ait augmente, pas seulement l'index droit (pour l'apostrophe)
Hors ligne
Effectivement j'utilise l'apostrophe courbe, mais ce qui m'étonne c'est que la charge de tout les doigts ait augmente, pas seulement l'index droit (pour l'apostrophe)
Effectivement, quand on additionne, on trouve plus de 104 % !
Soit il y a un bug, soit il se base sur le nombre de frappes avec la première disposition et il y a un caractère qu’il ne prenait pas en compte dans la première, ou il y a un caractère qui avait un accès direct et qui ne se fait plus que par composition.
Hors ligne