On Thursday 27 May 2004 21:21, Josh Babcock wrote:
> Lee Elliott wrote:
> > On Thursday 27 May 2004 20:18, Andy Ross wrote:
> >>Josh Babcock wrote:
> >>>So maybe airplanes shouldn't be in the interface business. Maybe we
> >>>should spend our energy agreeing on property conventions and Nasal
> >>>scripts.
> >>
> >>Even better would be to take a big audit of all the existing bindings
> >>and re-assign them from scratch. We've accumulated all sorts of
> >>inconsistencies and usability glitches over the years. Here's one
> >>
> >>right here:
> >>>a Tailhook down
> >>>A Tailhook up
> >>>L Toggle slats
> >>
> >>IMHO, we want to adhere to *either* the traditional toggle convention
> >>*or* the no-shift-means-down/shift-means-up idea. Using a combination
> >>in the default mappings is confusing. Likewise, we have other
> >>bindings (magnetos, flaps) that use yet another convention ("key
> >>pair") to indicate increase/decrease.
> >>
> >>I'm sure this will generate a good viscious flame war, but IMHO it
> >>ought to be done sooner rather than later. We're starting to attract
> >>real newbies, and they are already having a hard time with our default
> >>interface.
> >>
> >>And while we're at it, we need to do the same thing for the joystick
> >>bindings. I bought a new stick recently to replace my X45 (a Logitech
> >>Extreme Digital 3D) and discovered that our default bindings for it
> >>are absolutely nothing like the ones for the X45. It does "snap view"
> >>with the hat instead of panning, for instance.
> >>
> >>>Lastly, while we're at it, get rid of any key bindings define in the
> >>>code and put the mappings in keyboard.xml.
> >>
> >>This is done already. There are no more hard-coded key bindings in
> >>the C++ code. Outside of bindings done for aircraft, everything is
> >>in keyboard.xml.
> >>
> >>Andy
> >
> > I hope there's no flame war over this - it's too important.
> >
> > Part of the problem with coming up with a good keyboard mapping scheme is
> > that a comprehensive survey of the requirements needs to be done before
> > anything can be planned e.g. are slats simply toggleable (erk!) or do
> > they need to be stepped up/down? (I guess this particular example could
> > be accommodated via Nasal, as used for the flap indents - I've already
> > done this for the B-52F, which only has two flap positions, so
> > essentially they're being toggled)
> >
> > Perhaps a wiki could help to gather the information, then many people
> > could enter the requirements they know about and it would avoid having to
> > make a single person responsible for finding everything out and possibly
> > missing something, which would lead to a flawed solution.
> >
> > Then there could also be an issue with some keyboard combinations being
> > difficult to use when the context is taken into consideration, i.e. is
> > having to use Shift/Control combos to control things a good idea at
> > critical points in the flight, such as take-offs and landings?
> >
> > LeeE
> >
> > _______________________________________________
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
> Well, I'm glad to see other people take this seriously. I consider what I
> suggested a sort of half-measure holding action. I didn't really think
> that there was enough desire out there to really look at the problem.
>
> I actually think that it goes a little deeper than the configuration too.
> One of the basic problems is that these actions don't even mean the same
> thing in every aircraft. In the B-29 for example, flaps and gear are
> controlled by an instantaneous switch that you have to hold down throughout
> the transit, with no detents. I really haven't been able to come up with a
> way to deal with that. I think that one of the (many) things we should look
> at is whether it's smart for the input layer to be directly modifiying
> properties. Maybe it's smarter for the keyboard.xml file and the joystick
> files to just say that when I press this button, I want this sort of thing
> to happen. It may be move the flaps to the next lowest detent at speed x
> or it may be move the flaps down at speed x until I let up on the button.
>
> We could do this by having an abstract layer between input and the actual
> workings. Pressing a key or button would just raise a flag or create an
> event that would then cause some script to run. It could be a default
> script, or a specific one in an aircraft defenition that overrides the
> default.
>
> Maybe another good question to ask is: what should even be controlled by
> keypresses? Maybe a radical departure like having a bunch of stuff
> controlled by pop-up dialog like the radios. I think in real life it's
> analogous to: I need to change setting x
> I'm going to look over here at the x type panel
> I'm going to reach over and twiddle dial x
> Now I'm going to look back out the windscreen.
> So maybe stuff like autopilots could all be in dialogs and you just press
> one key to get all the functions in the dialog.
>
> Alternatively, you could use a WYSIWYG paradigm and just make all the
> functions clickable and make people click over to mode 0 and use the mouse
> cursor. The way I see it a real pilot has to let go of something to twiddle
> a dial anyway, we shouldn't complain if we have to as well.
>
> This could leave a lot more keys free for major function that in a real
> cockpit would not be a small part of some small panel, but would have their
> own big lever or button or a control directly on the yoke or throttle.
>
> Josh
The issue of keyboard mapping has come up a number of times in the past and
I'm sure it's taken very seriously by the developers but while the current
set-up is generally workable & flexible, quite understandably, I doubt it has
the highest of priorities.
LeeE
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
