Re: [Flightgear-devel] Moving menus (aka, usability)
You know one of the things that needs to happen with light-year is that the menus need to be accessible for the visually impaired it is very difficult to get to the menus we need to see the menus on the menu bar and have a little more accessibility to this because I use this mostly by keyboard and I can't get to some of the menu if not all of them Sent from my iPhone > On Sep 26, 2013, at 12:29, Clement de l'Hamaide wrote: > > Hi, > > > - merge 'Autopilot' into the Equipment menu, as a section (probably the > > first section) > > I have no objection with this. > > > > > - potentially rename 'Environment' to 'World' > > Environment word looks fine to me. > A quick search on Google reveal that X-Plane use "Environment" but FSX use > "World". So other simulators doesn't help here :-D > > > > > reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft > > keyboard shortcuts > > I agree with this. > > > Regards, > Clément > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
Hi, > - merge 'Autopilot' into the Equipment menu, as a section (probably the > first section) I have no objection with this. > - potentially rename 'Environment' to 'World' Environment word looks fine to me. A quick search on Google reveal that X-Plane use "Environment" but FSX use "World". So other simulators doesn't help here :-D > reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft > keyboard shortcuts I agree with this. Regards, Clément -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
> The Autopilot menu change does make sense (although there may possibly be a > case for keeping such a flight-critical menu rapidly accessed at the top > level?) I don't see this need. When I'm in a hurry, I use my left hand to enter a keyboard shortcut, rather than taking my right hand off the most critical flight controls to grab the mouse and navigate to/through a menu. > the control key is usually one of the easiest modifiers to find on a keyboard Mhh.. personally, I'd slightly prefer the shift key over the control key for the most important two-key-shortcuts. Using one hand (remember, the other hand is on the stick;), shift enables a slightly larger range than control: I can somewhat easily type shift+5, whereas control+5 becomes a little difficult. Tom -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
On 26 Sep 2013, at 16:21, AJ MacLeod wrote: > That's exactly what the word environment means though, isn't it! I really > don't think there's any point at all in changing the name of that menu entry; > the current one perfectly accurately describes "things around you" and avoids > having to change documentation etc. Okay, to me 'World' sounds a bit less technical, and it's also a shorter word. But either work, I agree. > Regarding the control key mapping restrictions, I'm definitely not too keen > on that for this reason; the control key is usually one of the easiest > modifiers to find on a keyboard, and if anything I personally think more > flight-related functions should be accessed using the control key as you > often want to access those rapidly, perhaps even by feel without hunting > around the keyboard. > > Program related functions on the other hand are rarely needed in a hurry and > could be mapped to any modifier without making much difference to > functionality. > > Just my opinions, possibly strange ones :-) Hmm, 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 :) I still don't have a good technical way to migrate this, so it's not a big deal anyway. James-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
On Thu, 26 Sep 2013 11:45:38 +0100 James Turner wrote: The Autopilot menu change does make sense (although there may possibly be a case for keeping such a flight-critical menu rapidly accessed at the top level?) > - potentially rename 'Environment' to 'World' > If most of the AI stuff moves to 'World', I think that name makes sense - > it's about things outside your aircraft, which does include tankers, carriers > and scenarios, as well as the weather and time/season. That's exactly what the word environment means though, isn't it! I really don't think there's any point at all in changing the name of that menu entry; the current one perfectly accurately describes "things around you" and avoids having to change documentation etc. Regarding the control key mapping restrictions, I'm definitely not too keen on that for this reason; the control key is usually one of the easiest modifiers to find on a keyboard, and if anything I personally think more flight-related functions should be accessed using the control key as you often want to access those rapidly, perhaps even by feel without hunting around the keyboard. Program related functions on the other hand are rarely needed in a hurry and could be mapped to any modifier without making much difference to functionality. Just my opinions, possibly strange ones :-) AJ -- -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
On Thu, Sep 26, 2013 at 11:45 AM, James Turner wrote: > I was reviewing the current menu structure and would like to propose a couple > of changes. Partly because we have too many menus, all quite short, but also > to remove some bad terminology. > > Each of these changes is independent, comments explicitly requested: > > - merge 'Autopilot' into the Equipment menu, as a section (probably the > first section) > > Autopilot is just another piece of equipment, and route-manager and GPS are > really parallel features, since route-manger is basically the FMC. The > combined menu is still a reasonable length. Aircraft without the default > autopilot (including the C172) would need to > disable just those menu items, but that's ok OK with me. A while back I introduced a Nasal abstraction layer so that aircraft could disable particular menu items without needing to know the the structure of the menu itself. So, in theory this should be pretty straightforward and not require any aircraft updates. However, I think you'll need to update the Nasal code (in gui.nas IIRC - not at my FG computer right now) so that the "autopilot" item now maps to the full set of autopilot items. That's slightly ugly, but at least hides this from the aircraft developer. > - potentially rename 'Environment' to 'World' > > This is less of an issue, but makes sense with the next one: > > - Move the AI items elsewhere > > -- Traffic / Scenarios move to 'World' menu > -- ATC services mode to World or Equipment (opinions requested) > -- All the 'controls' for tanker/carrier/wingman also move to world (or > somewhere even smarter … unfortunately PUI doesn't support sub-menus) > > The rationale here is that 'AI' is a completely meaningless term for most > users, and the way we use it in FlightGear has long since ceased to be > accurate. 'AI objects' are really what is normally called a 'mobile' or > 'actor' in most game engines. So the menu needs to either be removed or > renamed, and I don't think there's a sane meaningful new name, compared to > relocating the items. > > If most of the AI stuff moves to 'World', I think that name makes sense - > it's about things outside your aircraft, which does include tankers, carriers > and scenarios, as well as the weather and time/season. I'm OK with this as well. I expect that such large changes will require a significant update to The Manual, so please let me know what the final changes are once you make them and I'll update The Manual code. > 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. I think this is a good idea. I think it would be worth doing this as part of a wider re-org of the keyboard so we only have to re-assign keys on aircraft once. I'm sure there are various keys (time/sim acceleration) that pre-date the GUI and really no-longer need/deserve key bindings for the majority of users. Hopefully that would free up some keys, and allow us to set aside a standard set of keys for aircraft bindings. -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Moving menus (aka, usability)
I was reviewing the current menu structure and would like to propose a couple of changes. Partly because we have too many menus, all quite short, but also to remove some bad terminology. Each of these changes is independent, comments explicitly requested: - merge 'Autopilot' into the Equipment menu, as a section (probably the first section) Autopilot is just another piece of equipment, and route-manager and GPS are really parallel features, since route-manger is basically the FMC. The combined menu is still a reasonable length. Aircraft without the default autopilot (including the C172) would need to disable just those menu items, but that's ok - potentially rename 'Environment' to 'World' This is less of an issue, but makes sense with the next one: - Move the AI items elsewhere -- Traffic / Scenarios move to 'World' menu -- ATC services mode to World or Equipment (opinions requested) -- All the 'controls' for tanker/carrier/wingman also move to world (or somewhere even smarter … unfortunately PUI doesn't support sub-menus) The rationale here is that 'AI' is a completely meaningless term for most users, and the way we use it in FlightGear has long since ceased to be accurate. 'AI objects' are really what is normally called a 'mobile' or 'actor' in most game engines. So the menu needs to either be removed or renamed, and I don't think there's a sane meaningful new name, compared to relocating the items. If most of the AI stuff moves to 'World', I think that name makes sense - it's about things outside your aircraft, which does include tankers, carriers and scenarios, as well as the weather and time/season. 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. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
