* Giles Robertson -- Wednesday 22 June 2005 21:58: > If this were extended to all controls, then it could be used as an > abstraction for key bindings,
Except that only a part of the bindings is Nasal-based. > which would allow us to deal with the kb > localisation issues that were mentioned earlier this month. I'm not sure if doing this at runtime is a good idea. That's very static information and should probably be done at init time. The easiest would be to have keyboard files in $FG_ROOT/Translations/, analogous to the string files: keyboard-nl.xml, keyboard-de.xml, etc. These would simply be loaded after the global keyboard.xml file and have the chance to overwrite some bindings. Disadvantage: these would then not only contain key numbers/translations but also commands/bindings. Annoying to maintain. Better in *this* respect would be files with a few swap instructions: keyboard-fr.xml: -> swap US/65 bindings with US/81 bindings. Also ugly, and more complex for non-letter keys, where the normal and the shifted character are often not on the same keys (compared with default/US). Advantage: write once, never ever edit again. :-) BTW: with both (and other) solutions one could easily write a script that extracts all existing bindings from a running fgfs, and makes a key overview table. Could even be done as nasal module that writes TeX code (as soon as Nasal can write files, that is). m. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
