Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Erik Hofman
David Megginson wrote:
Through the magic of find and grep, here are the offending aircraft 
(including some of my own work):

737
T38
b52-yasim
A320
MD11
c182
c310-base.xml
p51d
hunter
hunter-2tanks
YF-23-yasim
YF-23
an225-yasim
bo105
seahawk
ComperSwift
pa28-161
fokker100
Some of these are using the bindings solely to set flap detents -- we 
should find a better system than that.
That is something Nasal can do. Another one that is quite common is 
speedbrake deflection.

Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread David Megginson
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,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Christian Brunschen
On 25 Jun 2004, at 12:36, David Megginson wrote:
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.
Just one personal opinion ...
What would be really good is if it were possible for the *user* to 
define an arbitrary number of keyboard / joystick configurations. These 
could also be named and grouped together; and there should be an easy 
way to switch between these configurations, from the keyboard or 
joystick itself if so desired.

This would allow the user to set up different control configurations 
for flying different types of aircraft. For instance, a plane that 
doesn't have a retractable undercarriage won't need those controls at 
all, and the keys that would otherwise have controlled the 
undercarriage could then be used for something else.

Also, it would allow people to set up different control configurations 
for different flight regimes with the same aircraft. For instance when 
flying a motorglider, you might want to switch between 'powered' and 
'gliding' flight regimes, and have the throttle lever alternatively 
control the engine or the airbrakes; Setting up different control sets 
and being able to switch between them easily would make that sort of 
thing very easy and would probably be very useful and improve the user 
experience a lot.

Behind all of this, there would of course be a _default_ configuration 
for the keyboard, for each type of joystick, etc, but the user should 
be able to set up as many of their own configs as they want.

And the configurations woul also be able to vary by which physical 
controllers were actually available. A laptop user might have a big 
hefty joystick at home, but might also want to fly 
'keyboard-and-mouse-only' when elsewhere; and might need different 
keyboard configurations for these settings.

The reason I mentioned grouping configurations together is to allow the 
user to specify, say, that three configs - 'fighter takeoff, fighter 
dogfight, fighter landing' - all belong together. Combine this with a 
'cycle to next configuration in set' function which could be assigned 
to the same button in each fighter config, the user could easily switch 
back and forth between regimes as neccessary - without involving the 
four helicopter and two motorglider configurations they've _also_ made, 
but which are of course irrelevant when flying a fighter plane. The 
particular configuration group could be chosen in a menu (being a 
relatively infrequent operation). Aircraft might also be able to 
provide hints, so that a suitable control configuration set could be 
loaded automatically.

But I digress ... I hope you don't mind these musing from an 
interested-but-not-actively-coding reader of this mailing list.

All the best,
Best wishes,
David
// Christian Brunschen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread David Megginson
Christian Brunschen wrote:
What would be really good is if it were possible for the *user* to 
define an arbitrary number of keyboard / joystick configurations. These 
could also be named and grouped together; and there should be an easy 
way to switch between these configurations, from the keyboard or 
joystick itself if so desired.
I agree.  Pulling keyboard/joystick/mouse configuration out of the main 
property tree makes this easier, because we don't have bindings left over 
when we switch to a new configuration (we load the whole configuration tree 
fresh with every reset()).

This would allow the user to set up different control configurations for 
flying different types of aircraft. For instance, a plane that doesn't 
have a retractable undercarriage won't need those controls at all, and 
the keys that would otherwise have controlled the undercarriage could 
then be used for something else.
Of course, a user would be welcome to do that, but we shouldn't recommend it 
as a good practice.  As a general rule, it's better to have a key be a no-op 
for some planes than to keep changing meaning depending on the plane being 
loaded.  The only exception is when the two things are closely related, such 
as (say) speed brakes or a drag chute.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Jim Wilson
David Megginson said:

 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.
 

My earlier thought on this is that we should allocate aircraft specific keys
by creating a dummy binding in keyboard.xml that would reserve the key. 
This came up in a discussion a few weeks ago.  We could simply reserve maybe 2
or 3 or some small number that can be used.  And they would be purposefully
held to a very small number so that only features that are truly aircraft
specific would be included.

One idea on this that I haven't really worked out would be separating the
functional properties of the bindings from the keys that make them work.  So
basically you'd have a configuration of named bindings that could be
attached to keys or buttons.  All the property tree references, scripts, and
so on would be in the named bindings xml.  Anyway...just a vague notion.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Jim Wilson
Christian Brunschen said:

 
 Just one personal opinion ...
 
 What would be really good is if it were possible for the *user* to 
 define an arbitrary number of keyboard / joystick configurations. These 
 could also be named and grouped together; and there should be an easy 
 way to switch between these configurations, from the keyboard or 
 joystick itself if so desired.
 
 This would allow the user to set up different control configurations 
 for flying different types of aircraft. For instance, a plane that 
 doesn't have a retractable undercarriage won't need those controls at 
 all, and the keys that would otherwise have controlled the 
 undercarriage could then be used for something else.
 
 Also, it would allow people to set up different control configurations 
 for different flight regimes with the same aircraft. For instance when 
 flying a motorglider, you might want to switch between 'powered' and 
 'gliding' flight regimes, and have the throttle lever alternatively 
 control the engine or the airbrakes; Setting up different control sets 
 and being able to switch between them easily would make that sort of 
 thing very easy and would probably be very useful and improve the user 
 experience a lot.
 
 Behind all of this, there would of course be a _default_ configuration 
 for the keyboard, for each type of joystick, etc, but the user should 
 be able to set up as many of their own configs as they want.
 
 And the configurations woul also be able to vary by which physical 
 controllers were actually available. A laptop user might have a big 
 hefty joystick at home, but might also want to fly 
 'keyboard-and-mouse-only' when elsewhere; and might need different 
 keyboard configurations for these settings.
 
 The reason I mentioned grouping configurations together is to allow the 
 user to specify, say, that three configs - 'fighter takeoff, fighter 
 dogfight, fighter landing' - all belong together. Combine this with a 
 'cycle to next configuration in set' function which could be assigned 
 to the same button in each fighter config, the user could easily switch 
 back and forth between regimes as neccessary - without involving the 
 four helicopter and two motorglider configurations they've _also_ made, 
 but which are of course irrelevant when flying a fighter plane. The 
 particular configuration group could be chosen in a menu (being a 
 relatively infrequent operation). Aircraft might also be able to 
 provide hints, so that a suitable control configuration set could be 
 loaded automatically.
 
 But I digress ... I hope you don't mind these musing from an 
 interested-but-not-actively-coding reader of this mailing list.
 

Sounds like a cool idea.  Reminds me of how much television I'd have to
watch to ever get good at using that universal remote control :-)

Modelers could perhaps build at the aircraft specific versions, so
that they are there, and the program would default to ignoring these.  Users
who wanted the alternate versions could then deliberately enable them. 

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Christian Brunschen
On 25 Jun 2004, at 14:16, David Megginson wrote:
Christian Brunschen wrote:
What would be really good is if it were possible for the *user* to 
define an arbitrary number of keyboard / joystick configurations. 
These could also be named and grouped together; and there should be 
an easy way to switch between these configurations, from the keyboard 
or joystick itself if so desired.
I agree.  Pulling keyboard/joystick/mouse configuration out of the 
main property tree makes this easier, because we don't have bindings 
left over when we switch to a new configuration (we load the whole 
configuration tree fresh with every reset()).
Yes, it would nicely decouple the input device configuration from the 
planes.

This would allow the user to set up different control configurations 
for flying different types of aircraft. For instance, a plane that 
doesn't have a retractable undercarriage won't need those controls at 
all, and the keys that would otherwise have controlled the 
undercarriage could then be used for something else.
Of course, a user would be welcome to do that, but we shouldn't 
recommend it as a good practice.  As a general rule, it's better to 
have a key be a no-op for some planes than to keep changing meaning 
depending on the plane being loaded.  The only exception is when the 
two things are closely related, such as (say) speed brakes or a drag 
chute.
Consider an aircraft with *lots* of different things that can be 
changed; including things like autopilot, radios, and so on. Rather 
than having to have all possible things accessible from the keyboard - 
likely leading to overloading of keys through modifiers, i.e., having 
to use 'x' and 'shift-x' to mean different things - one could cycle 
through having the keyboard 'focus' on different parts of the 
instrument panel. One second the entire keyboard could be 'dedicated' 
to setting up the autopilot just right, thus allowing lots of freedom 
in the choice of which keys do what; by a simple keypress the keyboard 
configuration could be changed to look at only the radios, with the 
same keys that would change the heading on the autopilot configuration, 
now used to change the frequency of the main communication radio, for 
instance.

My preference is for there to be a useful default keyboard 
configuration that covers most of the common functionality that is 
usually available in most aircraft. As more and more different aircraft 
are covered, this means cramming more and more stuff into the same 
limited number of keys, though. Yes, it makes sense to have gear up and 
down control be on the default key configuration, and simply have it 
not do anything on fixed-wheel aircraft. But what about something like 
wing sweep? Not really enough aircraft have it to make it a common 
feature that we should try to squeeze onto the already heavily loaded 
keyboard .. or should we?

By allowing aircraft to provide hints, we could actually include a few 
different keyboard  joystick configurations to match different broad 
types of aircraft, or different broad capabilities (ie, sets of 
instruments and controls), which could allow those keyboard 
configurations to be less cramped than one single default that tries to 
please everyone. And those hints could also be used by users who have 
customised their own configurations.

The point here is that it isn't the plane that is being loaded that 
supplies a control configuration that may or may not suit the user; it 
simply provides hints, and the rest of the system is free to act on 
those hints or ignore them. If the user has asked the system to look at 
the hints and load different configuration sets based on those hints, 
then that is a choice the user has made. Of course, if FlightGear as 
shipped were to include several different control sets and use hints 
itself to choose between them (say, if there were two control sets to 
differentiate between fixed-wing and rotor-wing craft), that would have 
to be documented: After all, there would now not be 'one default 
control setup', but two different ones. But at the same time it's not 
an insurmountable hurdle, I don't think.

All the best,
Best wishes,
David
// Christian Brunschen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Andy Ross
David Megginson wrote:
 Some of these are using the bindings solely to set flap detents
 we should find a better system than that.

We already do, actually.  Take a look at the 747 configuration,
you basically just drop in a /sim/flaps section that looks like:

  flaps
   setting0.000/setting
   setting0.000/setting !-- Flaps 1: 66% Slats only at this detent --
   setting0.167/setting !-- Flaps 5: 100% Slats --
   setting0.333/setting !-- Flaps 10: takeoff --
   setting0.667/setting !-- Flaps 20: takeoff, go-around --
   setting0.833/setting !-- Flaps 25: landing --
   setting1.000/setting !-- Flaps 30: landing --
  /flaps

...and the default bindings to the right thing.  Doing the
handler code was easy, porting all the existing content over to
the new scheme takes more effort.  We're in a similar situation
with the Joystick bindings, where many of the less-used sticks
still aren't using the newer Nasal bindings (like the one that
flap settings like the above).

Andy


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Josh Babcock
Christian Brunschen wrote:
By allowing aircraft to provide hints, we could actually include a few 
different keyboard  joystick configurations to match different broad 
types of aircraft, or different broad capabilities (ie, sets of 
instruments and controls), which could allow those keyboard 
configurations to be less cramped than one single default that tries to 
please everyone. And those hints could also be used by users who have 
customised their own configurations.
Whatever we do, it should be self documenting.  There should be a way to turn on 
something like tooltips for clickable regions.  I can see something like cycling 
between just the panel displayed, to clickable regions displayed, to clickable 
regions displayed with little glowing letters for the key presses to activate 
them down in each lower right corner.  More importantly, you should be able to 
bring up a window that shows every key you can press at the moment with a name 
for its function.

Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Josh Babcock
Jim Wilson wrote:
Modelers could perhaps build at the aircraft specific versions, so
that they are there, and the program would default to ignoring these.  Users
who wanted the alternate versions could then deliberately enable them. 

Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
What if there were an intermediate layer, call it functions.  Each key in a key 
configuration is bound to a function, say key 's' - function 'aero-braking'. 
Then a plane config could simply say I need function 'aero-braking' defined and 
so on.  Then the user just picks a key config that has all the appropriate 
functions, (or even one that doesn't, but this should generate a warning so our 
user can fix his key config).  When the user what's to activate his speedbrake, 
or drogue chute or whatever aero-braking system that their plane has, they just 
press 's' or whatever they have defined.  Loads a different plane, different 
plane author, different, but similar, braking system maybe, but the function 
name stays the same across planes, and the actual key that Joe user presses 
stays the same.

The only caveat is that we would have to make sure everyone is using the same 
function names, but that's a lot easier than doing it with keys, since keys are 
finite but there are an endless number of potential function names.  If we start 
with a broad enough list of functions to bind keys to, people should be able to 
work within the system without having to add a new function too often.  When 
they do, the user just has to edit his key config and add a key for that function.

Josh, still convinced that aircraft shouldn't be able to define the interface.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Ampere K. Hardraade
I came up with a similar idea a few weeks ago.

The panel will have to lost focus automatically when no input is given within 
a certain time.

Regards,
Ampere

On June 25, 2004 11:17 am, Josh Babcock wrote:
 Whatever we do, it should be self documenting.  There should be a way to
 turn on something like tooltips for clickable regions.  I can see something
 like cycling between just the panel displayed, to clickable regions
 displayed, to clickable regions displayed with little glowing letters for
 the key presses to activate them down in each lower right corner.  More
 importantly, you should be able to bring up a window that shows every key
 you can press at the moment with a name for its function.

 Josh

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Jim Wilson
Josh Babcock said:

 Jim Wilson wrote:
 
  Modelers could perhaps build at the aircraft specific versions, so
  that they are there, and the program would default to ignoring these.  Users
  who wanted the alternate versions could then deliberately enable them. 
  
  Best,
  
  Jim
  
  
  ___
  Flightgear-devel mailing list
  [EMAIL PROTECTED]
  http://mail.flightgear.org/mailman/listinfo/flightgear-devel
  
 
 What if there were an intermediate layer, call it functions.  Each key in a key 
 configuration is bound to a function, say key 's' - function 'aero-braking'. 
 Then a plane config could simply say I need function 'aero-braking' defined and 
 so on.  Then the user just picks a key config that has all the appropriate 
 functions, (or even one that doesn't, but this should generate a warning so our 
 user can fix his key config).  When the user what's to activate his speedbrake, 
 or drogue chute or whatever aero-braking system that their plane has, they just 
 press 's' or whatever they have defined.  Loads a different plane, different 
 plane author, different, but similar, braking system maybe, but the function 
 name stays the same across planes, and the actual key that Joe user presses 
 stays the same.
 
 The only caveat is that we would have to make sure everyone is using the same 
 function names, but that's a lot easier than doing it with keys, since keys are 
 finite but there are an endless number of potential function names.  If we
start 
 with a broad enough list of functions to bind keys to, people should be able to 
 work within the system without having to add a new function too often.  When 
 they do, the user just has to edit his key config and add a key for that
function.
 
 Josh, still convinced that aircraft shouldn't be able to define the interface.
 

That sounds great Josh.  And the functions, independant of any binding would
be on the order of increase-flaps or decrease-flaps rather than current
single binding definition with mod entries (e.g. mod-shift).  Your example
ought be two functions: aero-braking-on and aero-braking-off,  two
different bindings that could be attached to keys, key combos (like shift+key)
or joystick buttons.

It is possible that something might have a similar function, e.g. aero braking
and still be deployed separately...so it might be difficult to generalize in
many cases.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Josh Babcock
Ampere K. Hardraade wrote:
I came up with a similar idea a few weeks ago.
The panel will have to lost focus automatically when no input is given within 
a certain time.

Regards,
Ampere
On June 25, 2004 11:17 am, Josh Babcock wrote:
Whatever we do, it should be self documenting.  There should be a way to
turn on something like tooltips for clickable regions.  I can see something
like cycling between just the panel displayed, to clickable regions
displayed, to clickable regions displayed with little glowing letters for
the key presses to activate them down in each lower right corner.  More
importantly, you should be able to bring up a window that shows every key
you can press at the moment with a name for its function.
Josh

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Hmm, what do you mean by focus?  I was envisioning a purely visual thing that 
would be turned on/off for the whole panel by the user.  By focus I assume you 
mean the ability of a mouse click to change something on the panel, which is now 
a function of the mouse mode.

Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Ampere K. Hardraade
Sorry, I should have quote this instead:

 Christian Brunschen worte:
 Consider an aircraft with *lots* of different things that can be 
 changed; including things like autopilot, radios, and so on. Rather 
 than having to have all possible things accessible from the keyboard - 
 likely leading to overloading of keys through modifiers, i.e., having 
 to use 'x' and 'shift-x' to mean different things - one could cycle 
 through having the keyboard 'focus' on different parts of the 
 instrument panel. One second the entire keyboard could be 'dedicated' 
 to setting up the autopilot just right, thus allowing lots of freedom 
 in the choice of which keys do what; by a simple keypress the keyboard 
 configuration could be changed to look at only the radios, with the 
 same keys that would change the heading on the autopilot configuration, 
 now used to change the frequency of the main communication radio, for 
 instance.

If a panel is dedicated to a specific key bindings when it is selected, then 
we need to unselect it and tell FlightGear to use the original keybindings 
after a certain time.  You don't want the user to forgot about cancelling the 
selection until it is too late.

Regards,
Ampere

On June 25, 2004 12:55 pm, Josh Babcock wrote:
 Hmm, what do you mean by focus?  I was envisioning a purely visual thing
 that would be turned on/off for the whole panel by the user.  By focus I
 assume you mean the ability of a mouse click to change something on the
 panel, which is now a function of the mouse mode.

 Josh

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Christian Brunschen
On 25 Jun 2004, at 20:41, Ampere K. Hardraade wrote:
Sorry, I should have quote this instead:
 Christian Brunschen worte:
Consider an aircraft with *lots* of different things that can be
changed; including things like autopilot, radios, and so on. Rather
than having to have all possible things accessible from the keyboard -
likely leading to overloading of keys through modifiers, i.e., having
to use 'x' and 'shift-x' to mean different things - one could cycle
through having the keyboard 'focus' on different parts of the
instrument panel. One second the entire keyboard could be 'dedicated'
to setting up the autopilot just right, thus allowing lots of freedom
in the choice of which keys do what; by a simple keypress the keyboard
configuration could be changed to look at only the radios, with the
same keys that would change the heading on the autopilot 
configuration,
now used to change the frequency of the main communication radio, for
instance.
If a panel is dedicated to a specific key bindings when it is 
selected, then
we need to unselect it and tell FlightGear to use the original 
keybindings
after a certain time.  You don't want the user to forgot about 
cancelling the
selection until it is too late.
I think you misunderstand the scenario I'm sketching at.
You seem to be suggesting a scenario with one 'main' configuration, and 
the ability to focus briefly by selecting a certain part of the panel, 
with the default panel resuming operation after the user 'deselects' 
the panel - with a certain time of inactivity triggering automatic 
deselection, to handle the case where the user forgets to deselect it.

That is not what I had in mind. I was thinking of a scenario where the 
user would use one or two keys on the keyboard to switch between 
different keyboard configurations, and that this change would be 
persistent until the user actively changes the configuration back 
themselves. I was not thinking of the user mousing around in the 
cockpit to select a certain part of the panel per se; just to give the 
user the ability to switch between different keyboard / mouse / 
joystick configurations. 'focusing on one part of the panel' was just a 
perhaps somewhat contrived example of a scenario where swapping out a 
large part of the keyboard controls would make sense.

Your idea of being able to select a part of the panel, which would 
bring a panel-specific keyboard configuration into place while that 
part of the panel is selected (and automatically deselecting it if 
necessary), is really an orthogonal idea - but a very interesting one 
in itself. A GPS might be able to offer actual typing input to the 
user, which might be very useful indeed.

But to reiterate, I wasn't suggesting quite what you thought I was. 
Really, I think my suggestion is *mainly* useful for switching between 
different *joystick* configurations - such as for the motorglider 
example I suggested (switching the purpose of the throttle lever 
between controlling the engine and controlling the airbrakes). I just 
think that on principle, the same facility should be made available for 
the keyboard as well.

I happen to not really like having to use modifier keys to access 
different functions from the keyboard, especially if I'm keeping my 
hand on the joystick to control the plane. Also mousing around the 
cockpit to select a part of the panel to focus on doesn't really appeal 
to me as it, too, would possibly disturb my control of the plane. But 
using the keyboard with one hand, using keys to switch between 
different keyboard configurations to allow me quicker access to the 
specific functions I've set configured, would make it not just possible 
but actually *easy* to control even the complex functionality available 
in some planes.

Regards,
Best wishes,
Ampere
// Christian Brunschen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Ampere K. Hardraade
I suppose I did.  I'm sorry about it. =)

Regards,
Ampere

On June 25, 2004 04:16 pm, Christian Brunschen wrote:

 I think you misunderstand the scenario I'm sketching at.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-25 Thread Innis Cunningham

 Christian Brunschen  writes
I think you misunderstand the scenario I'm sketching at.
You seem to be suggesting a scenario with one 'main' configuration, and the 
ability to focus briefly by selecting a certain part of the panel, with the 
default panel resuming operation after the user 'deselects' the panel - 
with a certain time of inactivity triggering automatic deselection, to 
handle the case where the user forgets to deselect it.

That is not what I had in mind. I was thinking of a scenario where the user 
would use one or two keys on the keyboard to switch between different 
keyboard configurations, and that this change would be persistent until the 
user actively changes the configuration back themselves. I was not thinking 
of the user mousing around in the cockpit to select a certain part of the 
panel per se; just to give the user the ability to switch between different 
keyboard / mouse / joystick configurations. 'focusing on one part of the 
panel' was just a perhaps somewhat contrived example of a scenario where 
swapping out a large part of the keyboard controls would make sense.

Your idea of being able to select a part of the panel, which would bring a 
panel-specific keyboard configuration into place while that part of the 
panel is selected (and automatically deselecting it if necessary), is 
really an orthogonal idea - but a very interesting one in itself. A GPS 
might be able to offer actual typing input to the user, which might be very 
useful indeed.

But to reiterate, I wasn't suggesting quite what you thought I was. Really, 
I think my suggestion is *mainly* useful for switching between different 
*joystick* configurations - such as for the motorglider example I suggested 
(switching the purpose of the throttle lever between controlling the engine 
and controlling the airbrakes). I just think that on principle, the same 
facility should be made available for the keyboard as well.

I happen to not really like having to use modifier keys to access different 
functions from the keyboard, especially if I'm keeping my hand on the 
joystick to control the plane. Also mousing around the cockpit to select a 
part of the panel to focus on doesn't really appeal to me as it, too, would 
possibly disturb my control of the plane. But using the keyboard with one 
hand, using keys to switch between different keyboard configurations to 
allow me quicker access to the specific functions I've set configured, 
would make it not just possible but actually *easy* to control even the 
complex functionality available in some planes.
Maybe I am not reading this thread correctly but arnt most of the
functions allready on the keyboard.
In a thread a couple of weeks ago I suggested putting aside about
ten keys for aircraft specific things which the modeller of the
aircraft would specify in a readme file that would be in the file
with the model.
As for selecting things on the panel I thought we could already do
this via hotspots.I know that is only on 2D panels but we can do it.
As for mousing around in the cockpit.I would think that every real
pilot every day mouses around in the cockpit.Except that what he
uses is not a mouse but is called a hand.As we cant normally use a
hand because we dont have touch screens we have to use a mouse.
Do I understand that there is a proposal to have more than one keyboard
layout and for them to be selectable.
That would seem to me to be more complicated than the current set up
Regards,

// Christian Brunschen
Cheers
Innis
_
Find love today with ninemsn personals. Click here:  
http://ninemsn.match.com?referrer=hotmailtagline

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread Andy Ross
David Megginson wrote:
 Does anyone have code that depends on having bindings for the
 keyboard, mouse, and joystick(s) visibile in the main property tree?

Some of the joysticks (at least the X45, maybe others) use a mode
property under /input/joysticks/js[0] to track switch positions.  But
this can easily be moved somewhere else; or just left in place as a
lonely, vestigial relic of code gone by.

Andy


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread Jim Wilson
David Megginson said:

 Does anyone have code that depends on having bindings for the keyboard, 
 mouse, and joystick(s) visibile in the main property tree?  I'm planning a 
 cleanup of the input subsystem, and part of that will be reading XML 
 configuration files directly like we do for models and other parts of 
 FlightGear.  That will also make it possible to reload new bindings at 
 runtime without stopping and restarting FlightGear.
 

It seems that doing aircraft specific bindings relies on the current method. 
I think we should be thinking about the possibility of providing binding
dialogs, including the ability to change individual bindings on the fly and
also save those changes so that they are in place during subsequent executions.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread Jim Wilson
Andy Ross said:

 David Megginson wrote:
  Does anyone have code that depends on having bindings for the
  keyboard, mouse, and joystick(s) visibile in the main property tree?
 
 Some of the joysticks (at least the X45, maybe others) use a mode
 property under /input/joysticks/js[0] to track switch positions.  But
 this can easily be moved somewhere else; or just left in place as a
 lonely, vestigial relic of code gone by.
 

Forgot about that one.  This could be a problem for some folks.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread David Megginson
Andy Ross wrote:
Some of the joysticks (at least the X45, maybe others) use a mode
property under /input/joysticks/js[0] to track switch positions.  But
this can easily be moved somewhere else; or just left in place as a
lonely, vestigial relic of code gone by.
I have no trouble leaving that in place, since it's state information rather 
than configuration information.

I seem to remember that a while ago some people were rebinding keys in the 
airplane config files (I was probably one of them).  Is that still 
happening?  If so, we'll need a better approach either way, but I don't want 
to do anything that will make some of the planes suddenly stop working.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread Josh Babcock
David Megginson wrote:
Andy Ross wrote:
Some of the joysticks (at least the X45, maybe others) use a mode
property under /input/joysticks/js[0] to track switch positions.  But
this can easily be moved somewhere else; or just left in place as a
lonely, vestigial relic of code gone by.

I have no trouble leaving that in place, since it's state information 
rather than configuration information.

I seem to remember that a while ago some people were rebinding keys in 
the airplane config files (I was probably one of them).  Is that still 
happening?  If so, we'll need a better approach either way, but I don't 
want to do anything that will make some of the planes suddenly stop 
working.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Yes, people are still doing that, though I think there needs to be a better way 
of redefining keys for individual aircraft.  The current method is getting a 
little chaotic, and some functions have already been overwritten for some 
aircraft.  Sorry, don't have the examples handy.

Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread David Megginson
Josh Babcock wrote:
Yes, people are still doing that, though I think there needs to be a 
better way of redefining keys for individual aircraft.  The current 
method is getting a little chaotic, and some functions have already been 
overwritten for some aircraft.  Sorry, don't have the examples handy.
Through the magic of find and grep, here are the offending aircraft 
(including some of my own work):

737
T38
b52-yasim
A320
MD11
c182
c310-base.xml
p51d
hunter
hunter-2tanks
YF-23-yasim
YF-23
an225-yasim
bo105
seahawk
ComperSwift
pa28-161
fokker100
Some of these are using the bindings solely to set flap detents -- we should 
find a better system than that.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Important: input properties

2004-06-24 Thread Jim Wilson
David Megginson said:

 Through the magic of find and grep, here are the offending aircraft 

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.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel