Certains éulateurs envisagent une option : ne pas essayer de faire le malin avec la disposition physique du clavier de l’hôte, mais simplement ne rien supposer à son sujet.
En d’autres termes, accepter lorsqu’une API fournit un symbole et non une position sur le clavier.
Dans ce cas, lorsque les API Javascript indiquent « l’utilisateur a appuyé sur <ce_qu'on_veut> », il ne faut pas essayer de deviner que « en partant du principe qu’il s’agit d’un hôte physique équipé d’un clavier PC105 classique avec une disposition AZERTY française, ce symbole devrait être ce qui apparaît quand l’utilisateur appuie sur la touche à la ligne x et colonne y, que je vais mapper sur la touche physique du CPC à la ligne x’ et colonne y’ ».
Au lieu de cela, il faut accepter que, par exemple, l’utilisateur a appuyé sur « une touche qui produit un guillemet ». Il suffit d’avoir une table de correspondance entre les symboles et les touches du CPC, indépendante du clavier physique de l’hôte. Cela peut nécessiter une séquence dans la machine émulée, du type « appuyer sur majuscule, appuyer sur 2, relâcher 2, relâcher majuscule ».
Arnoldemu permet tout à fait une logique similaire et l’appelle « translated » (traduite), par opposition à « positional » (positionnelle).
Je l’appellerais plutôt « basée sur les symboles ».
Je crois que caprice32 le permet aussi.
L’un des avantages est qu’on peut taper sur le CPC avec son clavier PC comme dans n’importe quel autre programme. C’est génial pour programmer ou éditer n’importe quel type de texte. Et pour taper run"disc.
Pour en revenir à la situation actuelle : tout dépend si l’émulateur prend en charge une telle logique indépendante du clavier physique. Ce qui n’est pas le cas de RVM, j’imagine ?
La rangée du haut produit normalement des symboles et les chiffres s’obtiennent avec Maj, et on dirait que FF avec RFP activé remonte les touches physiques appuyées comme s’il s’agissait d’un layout US, mais mélangé avec des valeurs de touches localisées en français ?