Jim Wilson wrote:

Sorry for the dumb question: why are they offending? I'm in favor of limiting
aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled
differently than it is now.

It's a layering violation: I know that sounds like a technicality, but it has serious effects on usability and system management.

Once we set up a GUI for bindings, the user should not be surprised by having new, unrequested key bindings appear simply because (s)he chose a different airplane. For example, if the user binds '/' to fire an afterburner then loads a plane that uses '/' to deploy slats, we have broken the prime directive of user apps and discarded the user's input without warning. The only reason this hasn't been a problem so far is that changing key bindings without a GUI is too complicated for non-power users.

From a management point of view, let's say that we decide to use '/' by default to open a save file. With the current system, that will work fine until the user happens to load a plane that uses '/' for something else, and then it will fail to work, even if the user switches back to the original plane, because the rebinding will outlive the aircraft that triggered it.

So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite anyway.

All the best,


Flightgear-devel mailing list

Reply via email to