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

>  - 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.


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 >
Flightgear-devel mailing list

Reply via email to