Re: [Flightgear-devel] New re-arranging and styling for the QtLauncher

[James T. <zak...@ma...>]

> On 5 Feb 2017, at 12:59, Sébastien Vavassori <seb...@gm...> wrote:
> 
> Please find my proposition here (btw, I tried to concat your remarks and some wishes I found in the forum, SF bug tracker and in some FG wiki pages) :
> 
> http://wiki.flightgear.org/FlightGear_Qt_launcher#Wish_List
> 
> Please share your thoughts. Maybe we could add some drawings to the wiki too...

Thanks for writing this up, it’s turned out quite a bit bigger than I was expecting.

Separately, I have coded up the short-term changes I talked about, as a proof-of-concept, I’ll push those to Git later, so people can play with it as a mock-up.

For the list on the wiki, some of the items are definitely a lot of work (I won’t say impossible, but, a lot of work!) but there’s quite a lot of simple stuff. What I’m slightly worried about is two things:

- violating the ‘do things in once place’ principle, i.e duplicating in-sim UI in the launcher

- making the default experience a bit overwhelming for new users

Some of this can be dealt with via the ‘show advanced’ toggles you can see in my prototype code, but for some things I really think are better left as command-line options. For example Dany’s point about setting wind-speed and direction, I fully agree that’s needed for testing setups but that is what the command line switches are perfect for. 

Of course, the ‘do things in one place’ principle would be easier if we used this same UI in-sim for some settings, but that would be quite a controversial step. Equally, if you consider the rendering dialog changes Stuart has just made to support additional OSM layers - if we had copied the old rendering settings into the Qt launcher, we would now have to update everything, or face a bad situation from a usability perspective. (Old UI in the launcher, working+correct UI in the ‘rendering’ dialog in-sim)

I think a good next step before diving into about wireframes / mockups, which are quite easy to do in Qt, would be to prioritise changes from the current launcher, based on user demand, feasibility, etc. Then we can discuss which pieces people might actually be interested in designing + implementing, and how. 

Kind regards,
James