On Monday, July 11, 2011 05:37:06 AM Stuart Buchanan wrote:
> 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
Or a Performance/Quality setting that could be tied to a frame rate thresholds
that would automatically throttle the rendering quality based on what frame
rates the user is seeing.
Hal
>
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
