Keyboard function priority list: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(added carb heat, speed brakes - moved rudder,aileron trim to low-priority, added weapons, misc)
 
(27 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Template:RFC Navigation}}
{{cquote|My point of view is that the current keybindings file is a mess, with many historical bindings, and also it binds in the ASCII space, as opposed to the scan code space, so we can't distinguish keypad vs normal number keys, and various other combinations, even though osgViewer supports that.
My *personal* feeling is that unless it's something the > 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading,
fine, but things to change view distance or FoV seem unnecessary to me.
The other issue is the keybindings are effectively 'full' (we can't easily add more), because they've been added and added over the years, but rarely removed, so at this point every key 'does something', but often something quite obscure.
What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :)  - then have a complete discussion about which key-bindings make sense on
the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39648.html |title= Keyboard bindings|author=James Turner |date= Sun, 03 Mar 2013}}</ref>|James Turner}}
{{cquote|<nowiki>A separate step, much harder to make happen, would be to explicitly reserve the
Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard
shortcuts. I would really like to do this so we can have user-friendly
key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for
autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire
normal key / key + shift / key+alt ranges available FOR aircraft functions, of
course) The problem is right now we have aircraft using Ctrl- shortcuts for
many things (usually because they're the only choice), and I can't decide a
sane way to migrate to this split without lots of breakage and frustration. Any
ideas welcome.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40838.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>the problem is the OSs have already decreed that Ctrl (Command on Mac) is
the standard shortcut key, so lots of Ctrl-something have standard meanings
which FlightGear deviates from. Though we escape the worst of it since we don't
support file or edit operations.
Keep in mind if the GUI things such as dialogs were moved to Ctrl-blah, that
frees up lots of normal keys for use, which are currently taken up by simulator
things. While I agree Ctrl is probably the easiest modifier to access (except
maybe shift, since there's two, so it's more friendly for left-handed people),
I think by this logic a shortcut with *no* modifiers is even easier to access,
and that's an argument in *favour* of such change :)</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40853.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>this actually shows a larger problem. Obviously it isn't too
uncommon for aircraft to disable or override specific menu items -
mainly affects menu items for the radio stack and autopilot.
Unfortunately all of this is done using fixed menu item positions -
e.g. 5th menu, 3rd item... So any change of the menu item ordering
currently breaks lots of planes. And obviously the recent menubar
overhaul has done just that.
We'll need to adapt all the aircraft using such hacks to the changed
menu structure. And might need to think about a better solution to
avoid future problems of this kind.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30166.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>IMO the menu reordering represents a significant usability improvement and is
something we want to encourage. Furthermore backing it out will also require
changes to the manual, so isn't quite as straightforward as it might seem at
first.
I think the number of affected theses aircraft is sufficiently small that they
can be updated to fix this. Aircraft maintainers have always had to keep up
with changes in the core code (e.g. The ambient material change) and this is no
different except that it has only been noticed fairly late in the release
cycle.
Aircraft outside of the shears repository are not restricted to our release
cycle and can be updated after the release as and when their maintainers notice
this issue. I suspect that a number are waiting for the release to test their
aircraft anyway.
Adding symbolic names along with some helper functions for disabling them in
Nasal/gui.nas is pretty easy.  I'm happy to take on writing the code etc.
Probably not today though!</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30178.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>It turns out that Nasal/gui.nas already had a menuEnable function for
enabling or disabling entire menus or individual menu items using
unique names rather than the labels. Names already exist for the
autopilot menu and the Fuel & Payload dialog.  So, the fix is for the
aircraft to make use of this e.g.
gui.menuEnable("fuel-and-payload", false);
We can add new names for any other menus that we might want to disable
on a per-aircraft basis, but from a quick skim through the menus I
couldn't see any other candidates.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30188.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>Going through the aircraft highlighted a number of functions that
aren't covered by the existing enable/disable function in gui.nas
1) Replacing the autopilot dialog with another.
2) Adding pushback. Most aircraft add this to the Equipment menu
I'll need to think about how to handle these cases.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30194.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>The following aircraft override the radio dialog, which has moved since v2.0.0.
777-200ER
b1900d
Citation-Bravo
I've just pushed an enhancement to gui.nas that allows the aircraft developer to
change the binding for a symbolically named dialog, in the same way
that they can
enable/disable dialogs and menus using the existing gui.menuEnable() function.
So, you can now put the following code in your aircraft-specific Nasal files:
gui.menuBind("radio", "dialogs.Radio.open()");
This replaces the binding for the "radio" menu item with a command to open the
dialogs.Radio dialog box (that you've defined elsewhere).
Note that this searches the menu for the symbolic names (name tag) defined in
menubar.xml, (e.g. radio, autopilot-settings, gps, map) rather than
the label tag,
which may change over time, so should be a robust long-term solution.
</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
<references/>
As a first step in the keyboard refactoring, we need to come up with a prioritized list of functions that (a) are general enough to apply to most (or at least many) aircraft, and (b) are important enough to justify a keyboard shortcut rather than just a menu/dialog or a model hotspot.
As a first step in the keyboard refactoring, we need to come up with a prioritized list of functions that (a) are general enough to apply to most (or at least many) aircraft, and (b) are important enough to justify a keyboard shortcut rather than just a menu/dialog or a model hotspot.


Feel free to add to the list, but please don't delete anything &mdash; just move it to the bottom if you don't think it's important.
Feel free to add to the list, but please don't delete anything just move it to the bottom if you don't think it's important.


As we'll probably not want to change too many existing key-bindings, The current CVS key-binding is also listed in brackets.
* Program
** Pause {{Key press|P}}
** Exit {{Key press|Esc}}
** Show/Hide menu {{Key press|F10}}
* Primary flight controls
* Primary flight controls
** ailerons
** ailerons {{Key press|Left}} / {{Key press|Right}}, {{Key press|4}} / {{Key press|6}}
** elevator
** elevator {{Key press|Up}} / {{Key press|Down}}, {{Key press|8}} / {{Key press|2}}
** rudder
** rudder {{Key press|0}} / {{Key press|Enter}}, {{Key press|Insert}}
* Powerplant
** centre controls {{Key press|5}}
** throttle
* Primary powerplant
** mixture (piston aircraft only)
** throttle — ''for helicopters, should the same key control the collective?'' {{Key press|3}} / {{Key press|9}}, {{Key press|Page up}} / {{Key press|Page down}}
** propeller (some piston aircraft only)
** Winch / Aerotow (begin winching, open hitch etc)
** carburettor heat (some piston aircraft only)
* View controls
* View controls
** look left/right, etc.
** view reset {{Key press|Ctrl|V}}
** zoom in/out
** look left/right {{Key press|Shift|4}} / {{Key press|Shift|6}}
** look up/down
** look forward/backwad {{Key press|Shift|8}} / {{Key press|Shift|2}}
** zoom in/out {{Key press|X}} / {{Key press|Shift|X}}
** change view type — ''e.g. cockpit, chase plane, tower, etc.'' {{Key press|V}} / {{Key press|Shift|V}}
* Secondary flight controls
* Secondary flight controls
** flaps extend/retract
** flaps extend/retract {{Key press|<nowiki>[</nowiki>}} / {{Key press|<nowiki>]</nowiki>}}
** landing gear raise/retract
** landing gear raise/retract {{Key press|G}} / {{Key press|Shift|G}}
** elevator trim up/down
** elevator trim up/down {{Key press|1}} / {{Key press|7}}, {{Key press|Home}} / {{Key press|End}}
** speed brakes/spoilers
** speed brakes extend/retract {{Key press|Ctrl|B}}
** differential toe brakes left/right
** spoilers extend/retract {{Key press|J}} / {{Key press|K}}
** parking brake
** slats extend/retract
** toggle tailwheel lock {{Key press|1}}
** differential toe brakes left/right {{Key press|,}} / {{Key press|.}}
** parking brake {{Key press|Shift|B}}
** drag chute deploy/jettison
** drag chute deploy/jettison
** aileron trim left/right
** aileron trim left/right
** rudder trim left/right
** rudder trim left/right
* Secondary powerplant
** mixture — ''piston aircraft only'' {{Key press|Shit|M}} / {{Key press|M}}
** propeller — ''some piston aircraft only'' {{Key press|Shift|N}} / {{Key press|N}}
** carburettor heat — ''some piston aircraft only''
** magneto/ignition selection {{Key press|<nowiki>{</nowiki>}} / {{Key press|<nowiki>}</nowiki>}}
** Select engines {{Key press|~}} / {{Key press|@}} / {{Key press|!}} / {{Key press|#}} / {{Key press|$}} <small>(Note: These keys are problematic on some keyboard layouts, e.g. Swedish where IIRC '~', '@' and'$' are at inconvenient locations. Is there a way to capture number key + shift instead of whatever "strange" symbol the English keyboard layout maps to that key?)</small>
* Autopilot
* Autopilot
** engage/disengage
** engage/disengage
** toggle heading mode
** toggle heading mode {{Key press|Ctrl|H}}
** toggle altitude mode
** toggle altitude mode {{Key press|Ctrl|A}}
** toggle wing leveller {{Key press|Ctrl|W}}
** toggle speed mode (auto-throttle) {{Key press|Ctrl|S}}
** autotrim engage/disengage
* Comms
** open/close text based chat console
** PTT switch {{Key press|Space}}
** active/standby com/nav channel swap
* Weapons
* Weapons
** weapon select
** fire primary weapon
** fire weapon
** fire secondary weapon
** select secondary weapon
** jettison store
* Miscellaneous
* Miscellaneous
** hoist deploy (helicopters)
** hoist deploy (helicopters)
** hoist up/down
** hoist up/down
** hoist jettison
** hoist jettison
** water/cargo release  
** water/cargo release  
** carrier launch bar engage
** carrier catapult release
** hook up/down (compatible A/C ''all modern jet fighters have a hook'')
** canopy toggle
** seat up/down/default


Things that don't require key bindings:
* throw turkey out of window (Les Nessman only)
* change viewing styles (dynamic view and g-force based view where supported)


* throw turkey out of window (Les Nessman only)
[[Category:RFC]]
[[Category:FlightGear keyboard]]

Latest revision as of 12:03, 28 July 2016

Request for Comments:
Cquote1.png My point of view is that the current keybindings file is a mess, with many historical bindings, and also it binds in the ASCII space, as opposed to the scan code space, so we can't distinguish keypad vs normal number keys, and various other combinations, even though osgViewer supports that.

My *personal* feeling is that unless it's something the > 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading, fine, but things to change view distance or FoV seem unnecessary to me.

The other issue is the keybindings are effectively 'full' (we can't easily add more), because they've been added and added over the years, but rarely removed, so at this point every key 'does something', but often something quite obscure.

What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :) - then have a complete discussion about which key-bindings make sense on

the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :)[1]
— James Turner
Cquote2.png
Cquote1.png A separate step, much harder to make happen, would be to explicitly reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard shortcuts. I would really like to do this so we can have user-friendly key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire normal key / key + shift / key+alt ranges available FOR aircraft functions, of course) The problem is right now we have aircraft using Ctrl- shortcuts for many things (usually because they're the only choice), and I can't decide a sane way to migrate to this split without lots of breakage and frustration. Any ideas welcome.[2]
Cquote2.png
Cquote1.png the problem is the OSs have already decreed that Ctrl (Command on Mac) is the standard shortcut key, so lots of Ctrl-something have standard meanings which FlightGear deviates from. Though we escape the worst of it since we don't support file or edit operations. Keep in mind if the GUI things such as dialogs were moved to Ctrl-blah, that frees up lots of normal keys for use, which are currently taken up by simulator things. While I agree Ctrl is probably the easiest modifier to access (except maybe shift, since there's two, so it's more friendly for left-handed people), I think by this logic a shortcut with *no* modifiers is even easier to access, and that's an argument in *favour* of such change :)[3]
Cquote2.png
Cquote1.png this actually shows a larger problem. Obviously it isn't too uncommon for aircraft to disable or override specific menu items - mainly affects menu items for the radio stack and autopilot. Unfortunately all of this is done using fixed menu item positions - e.g. 5th menu, 3rd item... So any change of the menu item ordering currently breaks lots of planes. And obviously the recent menubar overhaul has done just that. We'll need to adapt all the aircraft using such hacks to the changed menu structure. And might need to think about a better solution to avoid future problems of this kind.[4]
Cquote2.png
Cquote1.png IMO the menu reordering represents a significant usability improvement and is something we want to encourage. Furthermore backing it out will also require changes to the manual, so isn't quite as straightforward as it might seem at first. I think the number of affected theses aircraft is sufficiently small that they can be updated to fix this. Aircraft maintainers have always had to keep up with changes in the core code (e.g. The ambient material change) and this is no different except that it has only been noticed fairly late in the release cycle. Aircraft outside of the shears repository are not restricted to our release cycle and can be updated after the release as and when their maintainers notice this issue. I suspect that a number are waiting for the release to test their aircraft anyway. Adding symbolic names along with some helper functions for disabling them in Nasal/gui.nas is pretty easy. I'm happy to take on writing the code etc. Probably not today though![5]
Cquote2.png
Cquote1.png It turns out that Nasal/gui.nas already had a menuEnable function for enabling or disabling entire menus or individual menu items using unique names rather than the labels. Names already exist for the autopilot menu and the Fuel & Payload dialog. So, the fix is for the aircraft to make use of this e.g. gui.menuEnable("fuel-and-payload", false); We can add new names for any other menus that we might want to disable on a per-aircraft basis, but from a quick skim through the menus I couldn't see any other candidates.[6]
Cquote2.png
Cquote1.png Going through the aircraft highlighted a number of functions that aren't covered by the existing enable/disable function in gui.nas 1) Replacing the autopilot dialog with another. 2) Adding pushback. Most aircraft add this to the Equipment menu I'll need to think about how to handle these cases.[7]
Cquote2.png
Cquote1.png The following aircraft override the radio dialog, which has moved since v2.0.0. 777-200ER b1900d Citation-Bravo I've just pushed an enhancement to gui.nas that allows the aircraft developer to change the binding for a symbolically named dialog, in the same way that they can enable/disable dialogs and menus using the existing gui.menuEnable() function. So, you can now put the following code in your aircraft-specific Nasal files: gui.menuBind("radio", "dialogs.Radio.open()"); This replaces the binding for the "radio" menu item with a command to open the dialogs.Radio dialog box (that you've defined elsewhere). Note that this searches the menu for the symbolic names (name tag) defined in menubar.xml, (e.g. radio, autopilot-settings, gps, map) rather than the label tag, which may change over time, so should be a robust long-term solution. [8]
Cquote2.png
  1. James Turner (Sun, 03 Mar 2013). Keyboard bindings.
  2.  (). .
  3.  (). .
  4.  (). .
  5.  (). .
  6.  (). .
  7.  (). .
  8.  (). .

As a first step in the keyboard refactoring, we need to come up with a prioritized list of functions that (a) are general enough to apply to most (or at least many) aircraft, and (b) are important enough to justify a keyboard shortcut rather than just a menu/dialog or a model hotspot.

Feel free to add to the list, but please don't delete anything — just move it to the bottom if you don't think it's important.

As we'll probably not want to change too many existing key-bindings, The current CVS key-binding is also listed in brackets.

  • Program
    • Pause P
    • Exit Esc
    • Show/Hide menu F10
  • Primary flight controls
    • ailerons / , 4 / 6
    • elevator / , 8 / 2
    • rudder 0 / Enter, Insert
    • centre controls 5
  • Primary powerplant
    • throttle — for helicopters, should the same key control the collective? 3 / 9, Page up / Page down
    • Winch / Aerotow (begin winching, open hitch etc)
  • View controls
    • view reset Ctrl+V
    • look left/right Shift+4 / Shift+6
    • look up/down
    • look forward/backwad Shift+8 / Shift+2
    • zoom in/out X / Shift+X
    • change view type — e.g. cockpit, chase plane, tower, etc. V / Shift+V
  • Secondary flight controls
    • flaps extend/retract [ / ]
    • landing gear raise/retract G / Shift+G
    • elevator trim up/down 1 / 7, Home / End
    • speed brakes extend/retract Ctrl+B
    • spoilers extend/retract J / K
    • slats extend/retract
    • toggle tailwheel lock 1
    • differential toe brakes left/right , / .
    • parking brake Shift+B
    • drag chute deploy/jettison
    • aileron trim left/right
    • rudder trim left/right
  • Secondary powerplant
    • mixture — piston aircraft only Shit+M / M
    • propeller — some piston aircraft only Shift+N / N
    • carburettor heat — some piston aircraft only
    • magneto/ignition selection { / }
    • Select engines ~ / @ / ! / # / $ (Note: These keys are problematic on some keyboard layouts, e.g. Swedish where IIRC '~', '@' and'$' are at inconvenient locations. Is there a way to capture number key + shift instead of whatever "strange" symbol the English keyboard layout maps to that key?)
  • Autopilot
    • engage/disengage
    • toggle heading mode Ctrl+H
    • toggle altitude mode Ctrl+A
    • toggle wing leveller Ctrl+W
    • toggle speed mode (auto-throttle) Ctrl+S
    • autotrim engage/disengage
  • Comms
    • open/close text based chat console
    • PTT switch Space
    • active/standby com/nav channel swap
  • Weapons
    • fire primary weapon
    • fire secondary weapon
    • select secondary weapon
    • jettison store
  • Miscellaneous
    • hoist deploy (helicopters)
    • hoist up/down
    • hoist jettison
    • water/cargo release
    • carrier launch bar engage
    • carrier catapult release
    • hook up/down (compatible A/C all modern jet fighters have a hook)
    • canopy toggle
    • seat up/down/default

Things that don't require key bindings:

  • throw turkey out of window (Les Nessman only)
  • change viewing styles (dynamic view and g-force based view where supported)