Re: [Flightgear-devel] Minor GUI layout improvements

[Stuart B. <stu...@gm...>]

Hi Thorsten,

I think we've gone beyond what can be done for the upcoming
release, but comments below.

On Sun, Jul 10, 2011 at 7:30 AM,thorsten.i.renk wrote:
>> 2) As it stands, it's very difficult for a new user to understand the
>> difference between Local Weather and Global Weather. let alone how
>> they inter-relate.  Enabling the Local Weather package requires
>> setting "Enabled local weather module" from the Local Weather Settings
>> menu, yet the rest of the settings a user is likely to want are in the
>> Local Weather dialog.  As a first step to sorting this out, I'd like
>> to do the following:
>> 2a) Move the "Enable local weather module" checkbox to the Local Weather
>> dialog.
>
> In my opinion, a clean solution would be to introduce a new master weather
> dialog on which the user can specify
>
> * is live weather to be used or an offline solution
> * which weather system (local or global) is supposed to render the weather
> information (and supply the offline solution if applicable)

Yes, a unified dialog for high level weather setting would be a very good idea,
This would undo some of the work that (Torsten?) did to amalgamate the various
global weather dialogs some time ago, but I think splitting off the
METAR/scenario
section at the bottom of the dialog makes a lot of sense given that in most
"modes" the various detailed configuration options are read-only anyway.

I also wonder if the terms "global" and "local" are really applicable. Would
"static weather modeling" and "dynamic weather modeling be better terms,
or how about simple/complex?

>> 2b) Move  "Local Weather Settings" to the Debug menu, on the
>> assumption that more users will never need to modify the settings
>> there (Thorsten R. - is this true?)
>
> No - quite the contrary. The design philosophy is (not strictly true, but
> mostly):
>
> * Local Weather (i.e. what used to be Local Weather Tiles) is a launcher -
> everything you select here is parsed only at startup of the weather
> system, but cannot be modified runtime

I think this "launcher" aspect is something that we want to hide from the
end-user. Most people just want to be able to change the weather
system and then press Apply or OK. Having to press "Stop" first is very
different from the rest of the UI.

I think we'll want to make this implicit, so the user can press (say)
Apply, and
the underlying weather system stops and then is started under the covers
with the new parameters.

Apart from the stop/start time (which could be handled by a "please wait"
message), is there any reason we couldn't do this?

> * Local Weather Settings contains all options which can be modified
> runtime. The main purpose is to get a handle on performance - for instance
> you might start out on relatively clear skies, so you can render clouds
> out to 55 km without large framerate impact - but then as you go on, you
> come into overcast skies, and the framerate drops like a rock - this menu
> allows you to choose runtime that you'd like to see clouds only to 20 km
> and get the framerate back
>
> So in my view, this should not appear in debug (for reference - I use the
> 'Settings' menu maybe 3-4 times  per hour of flight or so).

I think 90% of users are going to struggle to understand what most of these
settings mean. Is there one particular setting that you are changing regularly?
Perhaps we could extract it alone and give it a easier to understand name?

Alternatively, could we use some arbitrary Performance/Quality slider that
is mapped to these settings?

-Stuart