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
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
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 acce
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
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
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,
> >
> > Ji
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 someth
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
___
Flig
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
con
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:
0.000
0.000
0.167
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 swit
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
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
> > d
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 keyboar
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 ha
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 v
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 t
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 co
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 han
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 t
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 p
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 tr
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 model
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
th
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
FlightGea
25 matches
Mail list logo