The asynchronous nature of the profile bites us here. plotDive() signals
that it changes model data and expects the rest of the data structures to
respond to that. Very neat and it seems to work perfectly well on the
desktop, but on Android calling render() right after plotDive() resulted
in paint() functions being called before all the elements had been
calculated as a result of the signals being emitted in the model change.
That's why so often the profile was missing parts.
Now admittedly this makes me nervous. Do we now know that all calculations
have finished by the time render() gets called? Not really. It just seems
that in my testing we tend to get lucky and things work out. But that does
not feel like a sane architecture to me.
Messing around with the animation speed is silly as we render the profile
into a pixmap, so let's turn this off globally.
Also, the scaling of the pixmap is still completely bogus.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The persistent storage of the preferences includes the Organization name
set in the application. So we need to make sure we load the preferences
AFTER setting up the Organization in the init_ui() call.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
