* 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).


Flightgear-devel mailing list

Reply via email to