1 - Avoir la possibilité de remapper ses touches
2 - Avoir une configuration utilisable par défaut
Pour les logiciels/jeux utilisant les caractères (t pour tirer, r pour recharger, ...) il faut utiliser la méthode "logique/unicode".
Pour les jeux/logiciels où la position des touches physique est importante (le T inversé pour se déplacer / la ligne du haut ou il y a communément des chiffres pour une liste ordonnée d’item...), il faut que le jeu/logiciels utilise la méthode des "physique/scancode".
Avec cette méthode, il ne peut pas y avoir de conflits, car pour la majorité des claviers les touches suivante ont le même emplacement : les touches fléchés, la ligne du haut (ou il y a des chiffres), le T inversé des gamers, la barre espace, la touche maj et la touche contrôle. Cette méthode fonctionne sur 100% des claviers standards quelquesoit le mappage (azerty, bépo, dvorak), et les développeurs peuvent se renseigner un tout petit peu sur les « touches qui bougent d’un clavier à l’autre ». D’ailleurs c’est assez facile, ces touches sont (en azerty) μ, </> , page up/down, suppr, origin/fin, pause, imprécran/système, inser/ menu. Toutes les autres sont vraiment presque fixe. Si on prend en compte les claviers ergonomique ils faut rajouter quelques touches en plus ($ en azerty notamment). Et pour le coup je sais de quoi je parle vu que je participe activement au projet bépo.
Actuellement 0ad utilise la méthode "logique/unicode" alors que seul la position physique des touches est importante. C’est donc un non-sens. De plus cela oblige à remapper la très grande majorités des touches si on utilise un clavier standard (donc physiquement le même que celui du développeur à l’exception de la touche <), mais avec un mappage non qwerty-US. Je ne comprends pas en quoi c’est un problème d’utiliser la position physique des touches plutôt qu’un caractère.
De plus, tu dis que
si le dev ne veux pas s'encombrer avec des caractère sur 16 bits
Ce qui représente sur mon clavier au moins 4 touches (àéèç), et c’est très agaçant, alors qu’il n’y a aucune raison que je ne puisse pas les utiliser.
Je tiens à préciser pour avoir beaucoup bidouiller les claviers physique, que le signal reçu par l’OS est une position de touche physique (méthode "physique/scancode"), et que c’est l’OS qui s’occupe de faire la conversion vers les caractère unicode (méthode "logique/unicode"). Donc je ne voit pas en quoi c’est un problème que la SDL fasse un binding vers ces codes physique fournis par l’OS (on peut les voir avec xev sous linux).
[^] # Re: Raccourcis claviers
Posté par robin . En réponse à la dépêche Dernières évolutions autour de 0 A.D.. Évalué à 3.
Je reformule ce que je voulais dire.
1 - Avoir la possibilité de remapper ses touches
2 - Avoir une configuration utilisable par défaut
Pour les logiciels/jeux utilisant les caractères (t pour tirer, r pour recharger, ...) il faut utiliser la méthode "logique/unicode".
Pour les jeux/logiciels où la position des touches physique est importante (le T inversé pour se déplacer / la ligne du haut ou il y a communément des chiffres pour une liste ordonnée d’item...), il faut que le jeu/logiciels utilise la méthode des "physique/scancode".
Avec cette méthode, il ne peut pas y avoir de conflits, car pour la majorité des claviers les touches suivante ont le même emplacement : les touches fléchés, la ligne du haut (ou il y a des chiffres), le T inversé des gamers, la barre espace, la touche maj et la touche contrôle. Cette méthode fonctionne sur 100% des claviers standards quelquesoit le mappage (azerty, bépo, dvorak), et les développeurs peuvent se renseigner un tout petit peu sur les « touches qui bougent d’un clavier à l’autre ». D’ailleurs c’est assez facile, ces touches sont (en azerty) μ, </> , page up/down, suppr, origin/fin, pause, imprécran/système, inser/ menu. Toutes les autres sont vraiment presque fixe. Si on prend en compte les claviers ergonomique ils faut rajouter quelques touches en plus ($ en azerty notamment). Et pour le coup je sais de quoi je parle vu que je participe activement au projet bépo.
Actuellement 0ad utilise la méthode "logique/unicode" alors que seul la position physique des touches est importante. C’est donc un non-sens. De plus cela oblige à remapper la très grande majorités des touches si on utilise un clavier standard (donc physiquement le même que celui du développeur à l’exception de la touche <), mais avec un mappage non qwerty-US. Je ne comprends pas en quoi c’est un problème d’utiliser la position physique des touches plutôt qu’un caractère.
De plus, tu dis que
Je tiens à préciser pour avoir beaucoup bidouiller les claviers physique, que le signal reçu par l’OS est une position de touche physique (méthode "physique/scancode"), et que c’est l’OS qui s’occupe de faire la conversion vers les caractère unicode (méthode "logique/unicode"). Donc je ne voit pas en quoi c’est un problème que la SDL fasse un binding vers ces codes physique fournis par l’OS (on peut les voir avec xev sous linux).
bépo powered