Vous n'êtes pas identifié(e).
Bonjour,
vu les besoins virevoltants des utilisateurs j'imaginais que l'on pourrait créer une interface graphique pour éditer la configuration d'un clavier à partir d'une disposition donnée. On pourrait aussi ajouter des choses à cette interface graphique pour orienter les recherches, par exemple un module statistique, un module « représentation 3D » des fréquences en fonction d'un corpus de texte, c'est à dire quelque chose vraiment de poussé, mais dans un premier temps je pense d'abord à la création de nouvelles dispositions. Qu'en pensez vous ?
Merci.
Hors ligne
« création » ?!?
Réunir toutes les dispositions alternatives à bépo selon leurs usages serait déjà un bon départ.
« vu les besoins virevoltants des utilisateurs j'imaginais que l'on pourrait créer une interface graphique pour éditer la configuration d'un clavier à partir d'une disposition donnée. On pourrait aussi ajouter des choses à cette interface graphique pour orienter les recherches, par exemple un module statistique, un module « représentation 3D » des fréquences en fonction d'un corpus de texte, c'est à dire quelque chose vraiment de poussé,… »
Au bon vouloir des dev… Là c'est exactement la même chose : il existe déjà des programmes capables partiellement de ce dont tu causes, commences donc à référencer les outils existant
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
Salut.
J'ai trouvé ce logiciel :
https://github.com/simos/keyboardlayouteditor
ce software a deux ans.
Je pense qu'il est un peu inutilisable en l'état.
Je pense que coder une gui python comme celle là peut être aussi rapide, formateur et efficace que de reprendre le code existant, car j'ai une idée assez claire de ce que j'ai en tête.
Je n'ai pas trouvé grand chose d'autre.
Hors ligne
Ton logiciel serait super.
Sur Windows, le logiciel qui produit les drivers est très limité, et il faut en plus bidouiller parce qu’on a mis l’underscore en AltGr+Space, ce qui n’est théoriquement pas permis par le logiciel. De plus, si j’ai bonne mémoire, il faut d’abord lancer des scripts sous Linux pour produire les fichiers de config utilisables sous Windows. Bref, c’est tout sauf pratique.
Sur Linux, je ne sais pas trop, je crois qu’il faut éditer à la main un gros fichier texte. Pas très user-friendly non plus, mais moins problématique que sous Windows.
Un bépo orienté français, anglais, programmation : le bépo.ŵ
Hors ligne
C’est marrant, j’y réfléchis aussi depuis quelques semaines. Plutôt sur Java/Ecplise RCP, mais comme j’ai plus d’idées de projet que de temps à y consacrer, cela n’aboutira peut-être jamais. Par contre je suis dispo pour en discuter, si tu veux.
Un clavier est plus personnel qu’une brosse à dent.
Hors ligne
Merci pour ton commentaire. J'ai réussi à faire tourner keyboardlayouteditor sans (trop) de difficulté, le software se lance très bien pour peu qu'on ait les dépendances adéquates. Cependant, je ne comprends pas encore l'idée de la syntaxe des fichiers .xkb, j'imagine que c'est encore différent sous windows.
Mon idée est donc de développer un logiciel orienté « keyboard layout », sans toute fois de prévoir des modules de sortie, qui peuvent être développés après coup une fois que le cœur de l'application est stable et utile.
Dans l'immédiat, ce dont je pense avoir besoin, est une structure de représentation des claviers physiques, c'est à dire de comment représenter un clavier physique dans une classe abstraite. Pour cela, je pense avoir besoin de savoir quelles sont les caractéristiques des claviers sur le marché (nombre de touche, clavier droit) et de savoir quelles sont les caractéristiques qui nous intéressent dans l'édition d'une disposition de clavier.
Sinon, on peut tout de suite partir sur un clavier 105 touche comme « cas particulier » et mettre à jour ce modèle pour rendre compte de la diversité des claviers présents sur le marché.
Une description simple serait celle d'un rectangle avec pour chaque coordonnée une touche donnée. On peut aussi choisir de représenter la main gauche et la main droite séparément.
On peut aussi y aller plus franco en considérant chaque touche comme occupant un espace physique (rectangle), le clavier final n'étant que l'assemblage de plusieurs rectangles accolés.
David
Hors ligne
Si tu veux un exemple de module d'analyse fréquentielle, je te recommande d'essayer WordCreator. Ce n'est pas libre mais c'est bigrement puissant. Un corpus de 12 millions de caractères synthétisé en 2 minutes avec ma rutilante machine⸮
Les caractères unicodes, les digrammes, les trigrammes, les syllabes, les majuscules, des filtres pour les faibles fréquences ou par caractère.
Un vieux fichier excel que j'ai amélioré depuis pour cartographier l'utilisation des touches, mesurer la distance, l'effort, l'alternance, le roulement, les frappes du même doigt…Clavier.xlsx
Et une réalisation très récente et très visuel des statistiques…statistiquebvofrak.xlsx
D'autres exemples, en javascript(enfin je crois) mais pour de l'anglais:
http://www.andong.co.uk/dvorak/
http://patorjk.com/keyboard-layout-analyzer/
Pour la 3d, cf le topic suivant…
Voilà pour des exemples, le développement est à vous mais je pourrai tester…
BvoFRak : la disposition qui vous donne 1 coup 2 main passe en version 1 béta.
Hors ligne
Cependant, je ne comprends pas encore l'idée de la syntaxe des fichiers .xkb,
XKB illustre parfaitement le fait qu’être open source ne dispense pas de documenter au moins les formats de fichiers. Vu qu’il n’y a aucune doc officielle (à part le code), j’utilise :
j'imagine que c'est encore différent sous windows.
Sous windows c’est directement une DLL. Normalement l’API prévoit qu’un layout puisse s’autodécrire (notamment pour des applis comme le clavier visuel), mais les structures prévues ne couvrent pas tous les cas de figure. Par exemple le clavier canadien a 2 sélecteurs de groupe : AltGr et Ctrl Droit (qui du coup porte un autre nom que j’ai oublié). La DLL fonctionne bien mais son auto-description ne peut pas mentionner ce deuxième sélecteur.
Résultat si tu cherches à modifier cette disposition dans MSKLC (l’utilitaire windows d’édition des layouts) tu perds des caractères !
Dans l'immédiat, ce dont je pense avoir besoin, est une structure de représentation des claviers physiques, c'est à dire de comment représenter un clavier physique dans une classe abstraite. Pour cela, je pense avoir besoin de savoir quelles sont les caractéristiques des claviers sur le marché (nombre de touche, clavier droit) et de savoir quelles sont les caractéristiques qui nous intéressent dans l'édition d'une disposition de clavier.
Tu as pas mal d’infos sur ce sujet dans les sections « geometry » des fichiers XKB.
Sur les layouts eux-mêmes un standard proposé par google est passé sur la liste de diffusion https://docs.google.com/document/d/1XSF … iIYvg/edit.
Je n’ai pas eu le temps de regarder dans le détail. J’ai juste vu que dans les exemples de données, il n’y a avait aucune plateforme Unix/Linux d’où des doutes sur des fonctionnalités comme Compose.
On peut aussi y aller plus franco en considérant chaque touche comme occupant un espace physique (rectangle), le clavier final n'étant que l'assemblage de plusieurs rectangles accolés.
Je pense utiliser des fichiers SVG avec un groupe (<g>) par touche contenant le contour de celle-ci et son texte. Plusieurs avantages :
les touches ou le clavier peuvent être aussi exotiques qu’ils veulent (genre Maltron, Truly Ergonomic…) ça n’a pas d’importance
il est facile de définir des styles différents (angles droits, arrondis, espaces ou pas entre les touches, couleurs…)
comme c’est un format XML, c’est relativement simple à générer automatiquement; par exemple depuis des fichiers XKB
si besoin, il y a plein d’éditeurs graphiques de SVG, pas besoin de réinventer la roue
Il a pas mal de bibliothèque qui permettent une intégration rapide (Batik pour Java, pour python je ne sais pas)
J’ai fait quelques essais que je peux t’envoyer par mail, si ça t’intéresse.
Un clavier est plus personnel qu’une brosse à dent.
Hors ligne
Sous windows c’est directement une DLL. Normalement l’API prévoit qu’un layout puisse s’autodécrire (notamment pour des applis comme le clavier visuel), mais les structures prévues ne couvrent pas tous les cas de figure. Par exemple le clavier canadien a 2 sélecteurs de groupe : AltGr et Ctrl Droit (qui du coup porte un autre nom que j’ai oublié). La DLL fonctionne bien mais son auto-description ne peut pas mentionner ce deuxième sélecteur.
Résultat si tu cherches à modifier cette disposition dans MSKLC (l’utilitaire windows d’édition des layouts) tu perds des caractères !
Pour Windows, ConfigGenerator crée des fichiers .klc (du texte) qu’il faut compiler avec MSKLC pour produire les DLL.
http://bepo.fr/wiki/ConfigGenerator
Un bépo orienté français, anglais, programmation : le bépo.ŵ
Hors ligne
Merci à tous.
Je recense les idées listées. En fait je cherche surtout un outil de « recherche », pour optimiser une disposition de clavier de manière heuristique, un peu un tout-en-un.
Tout d'abord, mon langage de prédilection est python. C'est solide, bien supporté par la communauté, assez trendy libre, et je pense que c'est un des langages les plus importants en terme de bibliothèques tierces.
Java est également riche en bibliothèques tierces parties, mais c'est un langage plus formel, peut être plus sérieux.
Je pense donc choisir python comme langage de départ.
Merci à tous pour vos idées de logiciels existants. Je pense recenser cela sur le wiki, car c'est à ce niveau que nous avons le plus de visibilité pour écrire de la documentation.
Pour la modélisation de claviers au format SVG, je trouve que c'est une bonne idée, cela permet d'avoir des graphiques de qualité à moindre frais. La modélisation « physique » du clavier est importante mais cela ne forme pas la majorité de nos besoins en terme d'analyse statistique de texte.
Effectivement, les fichiers xkb prennent en compte la géométrie des claviers. Je peux m'en inspirer comme « patrons » pour la plupart des modèles de clavier semble-t-il.
L'existence d'outils définis pour générer les pilotes windows/linux/macos permettra à mon logiciel éventuel de n'utiliser qu'un format de sortie, qui serait donné par cette page : http://bepo.fr/wiki/ConfigGenerator#Cr. … isposition
Je suis intéressé par tous programme faisant de l'analyse statistique des trigrammes/digrammes/etc.
Merci beaucoup pour vos retours. J'ai pas mal de boulot en ce moment, donc ce sera dur à gérer, je vais essayer de faire quelque chose de positif pour la communauté.
Hors ligne
C'est que du bon tout ça ! Cependant, oublies pas de remplir le champ de description quand tu modifies le wiki, ça permet de savoir où chercher sur la page.
Prends ton temps pour le dev, c'est à la cool par ici.
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
Merci, un premier sous-projet serait de générer des fichiers .svg à partir des fichier -geometry de xkb.
Hors ligne