Am 25.04.2012 12:50, schrieb Renk Thorsten:
>> From my perspective, switching between GUIs runtime and trying to
>> mix features is problematic input in the first place. My
Agreed. And I don't think it was the intention of the current GUI to
toggle between both dialogs, while keeping advanced (or basic) weather
enabled.
However, I'm not too happy with the current way of switching between the
weather systems in general: I don't think "normally advanced" users
understand the concept. This bug report/feature request (i.e. show METAR
in basic weather dialog when advanced weather is enabled) shows the
issue: users think they are toggling between a basic and an advanced
_dialog_ (likely surprised by the "basic dialog" looking a lot more
complex than the "advanced dialog" though). It's easy to miss that this
actually switches between two completely different features: the basic
vs advanced _weather system_ - in the same way as they can switch
between 2D and 3D clouds.
So, maybe we could find a better method of switching between the weather
systems - though this isn't the main issue here. Using radio buttons or
a drop-down list would be a more standard way to toggle between
alternatives. Otherwise, just updating (and maybe moving) the button
descriptions might already help (something like "enable advanced weather
system" rather than just ">> advanced weather", and "disable ..." rather
than ">> basic weather").
>> inclination is if this needs to be hardened against problematic
>> input to treat the usage of the '-> Basic Weather' button as
>> intention to leave Advanced Weather and just add a call to
>> local_weather.clear_all(); to the code of the button which ends
>> Advanced Weather when ending its GUI. That would leave Basic
>> Weather still in disabled state though, so to go beyond I would
>> need to save the state of Basic Weather at startup of Advanced
>> Weather and write these parameters back when ending it.
With the current GUI concept, I'd expect "advanced weather" to be
disabled and "basic weather" to be enabled when I switch back from
advanced to basic weather dialog. So adding your call to disable (and
maybe another to properly enable basic weather) makes sense.
> But where should the METAR string be? My idea was that you can get it
> in-sim via the radio, or if you want to cheat there's always the
> property browser to look it up. Displaying it on the Advanced Weather
> GUI as well is also not really a problem if that's what people think
> should be done. Any opinions?
Users (like me! :) ) probably want to see the METAR string in some
dialog - not just in a property.
I'd suggest to display METAR also in the advanced weather dialog.
Or, maybe we can move METAR to a completely separate dialog (independent
of advanced/basic weather). This would also shrink the basic weather
dialog considerably (it's huge! ;-) ). And we could still add a tiny
button to open the METAR dialog from the weather dialog(s). And we could
have a "METAR" main menu item.
Torsten(D) really needs to comment though...
>> Also, after selecting 'Advanced Weather' then Shift-Esc restarting,
>> clouds flash repeatedly and then segfaults .. only when Shift-Esc
>> after selecting Advanced wetather
> Well, yes - a restart implicitly starts up Basic Weather again
> without terminating Advanced Weather and results in a fight between
> systems.
Ok, so that's what's causing it. Once advanced weather is running, basic
weather should stay disabled - even if the user resets/relocates. The
issue might be a result of our generic method resetting all properties
to their initial value on sim reset. We need to explicitly protect
(exclude) those properties, which should not be affected (enable the
properties' "preserve" flags).
Which properties exactly enable basic weather? Again, I guess Torsten(D)
should know (I'll give a bump shortly, unless he's reading this anyway
;-) ).
> Again, probably the best solution is to end Advanced Weather for good
> on restart (if anyone can tell me what property to tie the listener
> to?) because it's impossible to guess the cause for the restart - a
> restart at the same location would allow to keep the whole calculated
> cloud configuration and just leave it running and not restart Basic
> Weather, a restart at a different location however needs a lot of
> re-computation.
I'm not sure whether that's the expected behaviour. Someone who opts to
advanced weather probably wants to keep using it - even when he's
resetting/relocating. Similar to switching between 2D or 3D clouds - you
don't want to loose your selection on reset.
Anyhow, you should tie a listener to
/sim/signals/fdm-initialized
This triggers on _every_ FDM reset, which is when the aircraft "knows"
its new position. You could use this to disable advanced weather -
though I'd prefer if you used it to reset and adapt the advanced weather
system to the new location, while we sort out how to keep basic weather
disabled.
> I just tried that one, but I didn't get the segfault, the system
> behaved as expected for me. I suspect there may be a timing issue
> involved - clouds from the previous call are still buffered somewhere
I can reproduce the issue easily by enabling advanced weather,
triggering a sim reset and finally trying to disable advanced weather.
The stack trace on my system showed the issue inside cloudfield.cxx.
Adding a guard to protect from a NULL pointer (instead of a cloud
object) seems to fix the issue for me (in Git now). Let me know if
anyone was still seeing the issue with latest Git (=>
http://code.google.com/p/flightgear-bugs/issues/detail?id=717 ).
And maybe someone who knows more about "cloudfield" could also take a
look - the actual trigger of the issue is probably somewhere deeper.
Btw, thanks Thorsten(R) for looking into this issue. And maybe you could
add a comment on the bug tracker, so I could add your account as a
contributor - which would be handy. We could directly notify you about
any advanced weather-related issues then - just in case there ever were
any! ;-)
cheers,
Thorsten(B)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
