Re: [Flightgear-devel] Important: input properties
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
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
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
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
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
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
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
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
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
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 0.333 0.667 0.833 1.000 ...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
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
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
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
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
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
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
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
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
Re: [Flightgear-devel] Important: input properties
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
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
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
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
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
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