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

[Jim H. <ji...@ch...>]

James,

First:  Thank you for your detailed overview of the process.  The fact that you "own" QT, (so to speak), will make a huge difference in the quality of the resulting dialogs.

Reading your posting, I am getting what sounds like two distinct messages here.  Correct me if I am wrong:

1.  First priority is to "cure" the "deficiencies" in the current launcher, (i.e. The "missing functionality"), even if it doesn't result in a clean re-design.
(Suggestion:  Can we put this "new" stuff on a separate tab instead of bunching it up into the existing tabs which are already confusing?)

2.  Second - or even lower - priority is the aesthetic and functional re-design of the whole QT launcher paradigm, including integrating it with the in-app UI design.
(Thinking out-loud:  Is it possible to merge the "launcher" and "in-app" functionality?)

================================================

Thinking out loud here - AKA "brainstorming" - these are just thoughts I'm tossing out to see what gathers traction and which ones don't.

Item #1 should be an effort to include the functionality that our advanced user-base wants.  This can/should be done without worrying about any kind of re-design.  The goal is to get this out to the people who need it ASAP.

Item #2 could be likened to an entire project itself.  "We", (the two of us, and whomever else wants to jump in), can take our time and plan something that will be a professional effort truly worthy of being included with FG.

Though I have absolutely no problem with a discussion like this occurring on this list, I am not so sure that the dev mailing list is the *best* forum for a UI design discussion - being limited to plain-text.  Do you think that creating a sub-tree within the FG wiki where we can discuss this, post wire-frames and mock-ups, and do it in a way that is potentially more visible, has merit?

My thoughts here are that:
1.  We have an opportunity to really kick some serious butt here and make FG's launcher the Thing of Beauty that it deserves to be.  (As opposed to "scratching the itch" and throwing something together.)
2.  We have an opportunity to be very visible.  We can invite comment.  Users, power users, dev's, etc. etc. etc. can all chime in.
If we can get a multitude of viewpoints, and if we can include a lot of input from various stakeholders, we have a much better chance of getting the buy-in we need.
3.  Notwithstanding wkitty's comment to me before (on a different topic) about managing an Open Source project is like herding cats, (grin!), having a clearly defined plan and clearly defined goals, helps everyone who chooses to help with this work toward a common goal.  (I believe you said the same thing, but in a different way.)
3a.  This also allows those who *REALLY KNOW* the subject matter - like yourself - to help guide us.  These subject matter experts can help guide us away from features or designs that would be either "impossible" or "extremely difficult" to implement.  (Or would be more trouble than they are worth. . . .)
Impossible = Doable, but would require absolutely insane amounts of effort to do.
Extremely Difficult = Doable with a level of effort that, while not *absolutely* insane, appears to be rapidly approaching that level of difficulty.

In essence I would like this to be as inclusive as possible so that we can attract the brightest and best efforts from everyone.

Likewise, I would rather not have this tied to a release schedule.  Ii.e. The world will end if it's not ready for 2017.2.2)

Question:  Can we cut "test releases" using a stable release except dropping in our latest efforts.  Kind of like a "beta" release.  This way we could come up with an idea, plug it in, and see if it's really ready for prime-time, or is it a great idea that just doesn't work in practice.

I'd really like to see comments from a diverse group if possible.  And no, I'm *NOT* trying to "boss this around" - I'm just tossing out ideas, wanting to establish a firm and workable framework to work within, attract comment, and start a lively and productive discussion.

What say ye?

-----------------------------------------------------------------
Jim "JR" Harris 

Some see things as they are, and ask "Why?" 
I dream things that never were, and ask "Why Not".
Robert F. Kennedy 

“Impossible” is only found in the dictionary of a fool. 
Old Chinese Proverb 

-----Original Message-----
From: James Turner [mailto:zak...@ma...] 
Sent: Sunday, January 29, 2017 3:15 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] New re-arranging and styling for the QtLauncher


> On 29 Jan 2017, at 18:51, Jim Harris <ji...@ch...> wrote:
> 
> Is this something we can discuss, or is this yet another conversation I'm butting my big nose into?

Quick answer: yes, but also no, and maybe :) And now a better answer:

The launcher UI is built using Qt, which is also my day job so I know it quite extensively. Hence the concern is not what Linux, Mac or Windows can do, it’s what Qt can do. This means any widget Qt has on all the platforms, or any widget I can code up, is feasible *in principle*. In practice some Qt widgets look a bit ‘foreign’ on some platforms, eg the tab-bar is not as nice on Windows as what Chrome or a WPF application would show.

(Qt also takes care of offering native style, but also allowing a completely custom visual appearance, but with different amounts of work, as Emilian wrote)

Secondly, the current launcher was thrown together quickly two years ago by me to fill an urgent need, and has evolved organically since then. The plan I proposed in my earlier email is an incremental step I want to do regardless, because of very direct feedback about missing *functionality*. The audience for those changes is advanced users, mostly, and it’s very easy work for me, there’s no big technical hurdles involved.

Given the above, if you want to review the UI, it would be far better to do it holistically, considering the launcher *and* the in-sim UI, which is due for an overhaul. This needs to be informed by which settings we can change at startup vs in-sim (changing this is considerable work or even ‘impossible’ for some things, eg Rembrandt vs not). The problem is the in-sim UI supports a very different experience to the launcher, both at present, and in the future depending on the technology we migrate towards there.

There is also the role of Phi (the web UI) to consider, because we could potentially delegate quite a bit of non-critical UI to only work in Phi, especially instructor-station and debug functionality.

Thinking about all the above is quite a large task, if you want to start at it from a pure UI / UX level that would be entirely possible, but I can’t promise that any development would happen immediately in response to such work. Equally having an agreed goal to work towards conceptually might motivate some development effort. 

Kind regards,
James



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
Flightgear-devel mailing list
Fli...@li...
https://lists.sourceforge.net/lists/listinfo/flightgear-devel