Re: [Flightgear-devel] Minor GUI layout improvements
..how about historical weather from e.g. air crash reports? fgfs --metar=add any metar you want here -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
On Sat, 16 Jul 2011 10:34:33 +0200, Torsten wrote in message 4e214d19.20...@t3r.de: ..how about historical weather from e.g. air crash reports? fgfs --metar=add any metar you want here ..replacing METAR IDs with a data file that FG reads to emulate the historical weather??? Would kick ass. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
Am 16.07.2011 17:37, schrieb Arnt Karlsen: On Sat, 16 Jul 2011 10:34:33 +0200, Torsten wrote in message 4e214d19.20...@t3r.de: ..how about historical weather from e.g. air crash reports? fgfs --metar=add any metar you want here ..replacing METAR IDs with a data file that FG reads to emulate the historical weather??? Would kick ass Check out utils/metarproxy/README to get you kick http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=blob;f=utils/metarproxy/README;h=bb2e4f1645f59330bbabc39b7d12d63edc154d8d;hb=HEAD -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
On Sat, Jul 16, 2011 at 4:37 PM, Arnt Karlsen wrote: On Sat, 16 Jul 2011 10:34:33 +0200, Torsten wrote in message 4e214d19.20...@t3r.de: ..how about historical weather from e.g. air crash reports? fgfs --metar=add any metar you want here ..replacing METAR IDs with a data file that FG reads to emulate the historical weather??? Would kick ass. You can just edit Environment/environment.xml and add some new weather scenarios. Very straightforward. -Stuart -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
On Mon, 11 Jul 2011 13:38:21 +0100, Stuart wrote in message cap3ntyuoqjffdsfanod-21zph1jv3lyakfqztjvka-eaydo...@mail.gmail.com: On Sun, Jul 10, 2011 at 7:33 AM, thorsten.i.r...@jyu.fi wrote: Sounds logical to me ...the double weather systems are a bit of nuisance , would be nicer, in my opinion , if they could be combined in a single dialog but not sure if that's possible.I use real world weather anyway , so i never use those settings. That misses the point - you can use real weather and render it with Global Weather, or you can use real weather and render it with the Local Weather package - both are capable of doing the job. I think this really highlights the problem - it really isn't obvious from looking at the UI that the Local Weather can interpret Real Weather. ..how about historical weather from e.g. air crash reports? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
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? I guess the key differences in philosophy are: * terrain interaction: clouds in Local Weather 'know' terrain type and elevation underneath and react to it, clouds in global weather don't * locality: weather phenomena in Local Weather are genuine local things - you can see rain underneath a cloud from the outside, fly there across a visible border and get wet and fly out again. Can't do using global weather. Also true for e.g. pressure which is interpolated - wasn't so in global weather a while ago, but is now, and the systems have become more similar here * (some overlap with the first point) physics: Local Weather tries to implement an (admittedly crude) model of atmospheric physics and dynamics, Global Weather renders what you specify without trying to make too much sense of it I don't think 'static' vs. 'dynamic' are good labels, I would apply these to how much things change in time, and as compared to the last release, Global Weather has now the interpolation of METAR as well as moving 3d clouds, i.e. a fair share of dynamics. 'simple' and 'complex' would work for me, although it's a bit of an injustice to the 'global' system as it isn't really that simple either. I'm not particularly attached to the current labels, but whatever we choose should capture the essentials. 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. You can do this, but there'll be a price to pay: The user also expects that he can 'just' change the wind, press okay and it's done without waiting half a minute - but that's not true. The reason is that with terrain interaction you open a can of worms, and especially with moving clouds over time it gets worse an order of magnitude - you need tons of computations in the background - which is no problem as they can be split over many frames, the system just doesn't start or change in a hurry. Take my current project - 3rd generation cloud/terrain interaction http://www.flightgear.org/forums/viewtopic.php?f=5t=7358start=375#p129648 Each cloud placement takes into account terrain gradient at kilometer scale, terrain elevation, terrain type, wind direction, windspeed and time of the day. If you change the wind, the whole picture changes. You just spent ~1500 frames getting to what you see (which by the way I think is acceptable at startup, as you'd usually start your engines and go through your procedures anyway, so you don't need full framerates). If you change 'just' the wind and press okay, you can implicitly restart the system - it's just going to delete everything and recompute for 1500 frames - there's no way to hide that unless you make probing the terrain a factor 100 faster. So if you can't hide the fact that you have to restart everything, in my view the user is going to be less disappointed if he realizes that he has to restart everything than if the system pretends you can just change parameters and be done with it. Apart from the stop/start time (which could be handled by a please wait message), is there any reason we couldn't do this? Psychology. In my view it's bad to give the user a false impression. Not realizing it's a full restart, a user will be disappointed that it takes that long to change the wind. Having the info that it's a full restart, he's more likely to accept it. (I see myself waiting at the gate at an airport. Being told that I have to wait foran unspecified amout of time just makes me angry. Being told that there is a severe storm at my destination and we can't land, but if we wait for 2 more hours so that it can be expected to have passed by the time we arrive, I'm fine.) I think 90% of users are going to struggle to understand what most of these settings mean. Well, it's a complex system, so its configuration reflects some of the complexity, an it comes with a manual... If some user tells you 'I have trouble to understand what all these gauges in the cockpit of the c172 mean' - do you simplify the cockpit, or do you ask him to read the manual where it is explained? I'd be happy with a limited number of options - but many users can't run the system well with the set of options I like - and that was the point when I started exposing properties so that the system can be customized individually. I took the time to document every option and most algorithms in 42 pages of manual (out of which you are free to read what you need - the description of what a particular option does is shorter) - so
Re: [Flightgear-devel] Minor GUI layout improvements
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 -- 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
Re: [Flightgear-devel] Minor GUI layout improvements
On Sun, Jul 10, 2011 at 7:33 AM, thorsten.i.r...@jyu.fi wrote: Sounds logical to me ...the double weather systems are a bit of nuisance , would be nicer, in my opinion , if they could be combined in a single dialog but not sure if that's possible.I use real world weather anyway , so i never use those settings. That misses the point - you can use real weather and render it with Global Weather, or you can use real weather and render it with the Local Weather package - both are capable of doing the job. I think this really highlights the problem - it really isn't obvious from looking at the UI that the Local Weather can interpret Real Weather. -Stuart -- 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
Re: [Flightgear-devel] Minor GUI layout improvements
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
Re: [Flightgear-devel] Minor GUI layout improvements
Stuart wrote: 1) Currently there is a wireframe option on the Rendering menu. While it's of moderate interest to developers, I don't think it's really of any interest to the average user. I'd like to move this option to the Debug menu. The reason I added it is that we got quite some people that accidentaly enabled this option in FGRun and couldn't find it back. It really is a rendering option IMO,but I don't care if you move it to the Debug Menu. Altough I don't think it deserves a special menu-item and make the already big Debug Menu even bigger... Submenus would be nice here, but I guess our GUI system is too basic for that. Cheers,Gijs -- 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
Re: [Flightgear-devel] Minor GUI layout improvements
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) Dependent on the setting in this dialog, the menu options for either Local or Global weather would then be available and the other greyed out. I think that would be the most intuitive structure. It would also prevent a user from discovering the hard way that he can enter whatever he likes for, say, visibility in the 'Global Weather' dialog, it won't ever show up whenever Local Weather is running. Such a solution would also allow for easy integration of a hypothetical third weather package 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 * 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). Cheers, * Thorsten -- 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
Re: [Flightgear-devel] Minor GUI layout improvements
Sounds logical to me ...the double weather systems are a bit of nuisance , would be nicer, in my opinion , if they could be combined in a single dialog but not sure if that's possible.I use real world weather anyway , so i never use those settings. That misses the point - you can use real weather and render it with Global Weather, or you can use real weather and render it with the Local Weather package - both are capable of doing the job. Maybe you're also so lucky that no matter what conditions, your framerate is high enough - I'm not, so I have to change settings when the scene changes enough. * Thorsten -- 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
Re: [Flightgear-devel] Minor GUI layout improvements
Sounds logical to me ...the double weather systems are a bit of nuisance , would be nicer, in my opinion , if they could be combined in a single dialog but not sure if that's possible.I use real world weather anyway , so i never use those settings. Cheers On Sat, Jul 9, 2011 at 12:57 PM, Stuart Buchanan stuar...@gmail.com wrote: Hi All, I've just done a pass over the GUI making minor changes to clean it up and make it consistent. There are a couple of slightly more significant layout changes I'd like to make, but want to discuss first. 1) Currently there is a wireframe option on the Rendering menu. While it's of moderate interest to developers, I don't think it's really of any interest to the average user. I'd like to move this option to the Debug menu. 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. 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?) 3) Split the Jetway Settings, and move the Enable jetway editor, Debug mode and Open Editor buttons to a new dialog in the Debug menu. Again, on the basis that most normal users have no interest in these controls. Comments? -Stuart -- 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
