Board index FlightGear Development New features

Aircraft reselection qt5

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Aircraft reselection qt5

Postby Parnikkapore » Fri Jan 08, 2016 11:17 am

Kinda a fork from here:
viewtopic.php?f=6&t=28389
What I want in this thread is,that the qt5 launcher pops up again after you quit FG with the menu or button (Technical:the same handler you use for fgadmin (un)installer) Then the user can select another aircraft,Toggle some settings,and relaunch fg under it.
Another,More novel(ahem!)option is to add a menu called "Change aircraft" under File,which(TECHNICAL:
-Fires up the qt5 launcher in a separate stay-on-top window
>when the user clicks Run
-Changes the props(rather like Location->Select airport) and reset fg
)
There are free alternatives to every program you encounter. You just have to find them.
Parnikkapore
 
Posts: 810
Joined: Thu Oct 29, 2015 10:16 am
Callsign: HS-FGS
Version: next [PPA]
OS: Mint 18

Re: Aircraft reselection qt5

Postby Hooray » Fri Jan 08, 2016 12:21 pm

that's planned: http://wiki.flightgear.org/Integrated_Qt5_Launcher

PS: better use the issue tracker for these things: https://sourceforge.net/p/flightgear/codetickets/
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Aircraft reselection qt5

Postby Parnikkapore » Sun Jan 10, 2016 12:02 am

Roger,good idea!

PS how is a qt5 gui better than a Canvas or PUI gui? Is it better with HLA pr just because PUI is outdated?
There are free alternatives to every program you encounter. You just have to find them.
Parnikkapore
 
Posts: 810
Joined: Thu Oct 29, 2015 10:16 am
Callsign: HS-FGS
Version: next [PPA]
OS: Mint 18

Re: Aircraft reselection qt5

Postby Hooray » Sun Jan 10, 2016 8:06 pm

Parnikkapore wrote in Sun Jan 10, 2016 12:02 am:PS how is a qt5 gui better than a Canvas or PUI gui? Is it better with HLA pr just because PUI is outdated?


You could review the corresponding wiki articles, they contain all the key points:

http://wiki.flightgear.org/Integrated_Qt5_Launcher
http://wiki.flightgear.org/Howto:Proces ... ing_Canvas

The main points being 1) PUI is unmaintained and OpenGL specific, i.e. fixed-function pipeline, does not work well with other OSG code running in SG/FG, 2) Qt5 is a separate extremely well-maintained GUI platform, not specific to any particular use-case.

1) PUI is archaic and is known to affect rendering performance, and causing graphics artifacts
2) Qt5 could solve all problems, but is a massive dependency that is intended to remain optional - however, useful functionality is increasingly added/implemented solely in Qt5 space (think catalog/package manager related functionality)
3) Phi does not introduce any bloat at all, and is comparatively lightweight, but requires a browser to control FlightGear, which makes it asynchronous, but also not that suitable for certain features that an integrated UI could provide

Finally, Canvas is a niche-technology only used/available in SimGear/FlightGear, not unlike Nasal scripting.
Thus, anything involving Canvas is a homegrown thing that is unlikely to be able to "compete" with external UI efforts, such as Qt5 or Phi (it using a bunch of different DHTML frameworks), and that even applies to some PUI functionality.

The only real advantage that the Nasal/Canvas approach brings with it is that it is a completely different approach to update the integrated UI: It just involves writing a "converter" (translator) to read existing GUI dialog files and turn those into Canvas graphics (textures) at runtime (procedurally).

Which means that there will only ever need to be a parser written/maintained to deal with our existing set of GUI dialogs, i.e. we don't need to integrate an external GUI library (think Qt5), and certain challenges simply would not show up at all (think the multi-threading issues that bugman mentioned), simply because Canvas is already a technology stack and subsystem that is available in FlightGear, so all that the parser is doing is to read XML dialogs and turn them into their Canvas equivalent.

The same approach (writing just a parser instead of a new UI framework from scratch) would work for the Qt5/Phi efforts (including even support for embedded Nasal code in existing dialogs), but so far the people working on those have prioritized their resources differently, so that it is likely that sooner or later there will be a regression in terms of functionality, unless the parser/translator approach is also embraced by them.

Thus, Qt5 is always going to be superior, but is going to cause tons of work, too - Phi will be able to satisfy use-cases that Qt5 cannot support (external/browser-based UI), Canvas can really only help with the integrated UI - but at the cost of creating widgets from scratch, i.e. equivalents of existing PUI widgets (including those that were custom coded for FlightGear specifically).

Equally, two of the most active FlightGear core developers (James and Torsten) are now both involved in developing, very much overlapping, but entirely optional components (separately) that will not even be executed normally, using two incompatible technology stacks.

So, the increasing interest in revamping the FlightGear UI is likely to drain resources from other core development efforts (just look at the track record, i.e. plethora of components, touched by both, James & Torsten prior to their interest in modernizing the UI).

With Canvas/Nasal, there is not much needed in terms of C++ level changes, it requires mainly Nasal code, i.e. roughly 300-500 lines of additional code could make PUI obsolete so that it can be phased out, without any core developers having to review C++ level changes.

Then again, it would be a niche solution - but it could be implemented using factories/delegates, so that adopting a native code UI library (qt5/wxwidgets etc) would be possible anyway.

The main motivation why some people want to have a Nasal/Canvas-based GUI is to ensure that aircraft avionics can make use of the GUI toolkit, but also so that the integrated GUI can deal with existing Canvas based features (think avionics).

In layman's terms, all this comes down to being able to render a MFD (PFD/ND) in a dialog box, but also to render GUI widgets to a Canvas, i.e. true recursion - as long as this use-case is supported, it does not matter whether Qt5 is used for this or not, the only thing that matters is that it would be possible to create an integrated GUI for editing/maintaining MFD avionics, but also other Canvas-feature (think having a built-in HUD or 2D panels editor).

Admittedly, Qt5 support would be awesome to have, even from the standpoint of those wanting to have support for Canvas based UIs.
In fact, number of people started working on the Canvas UI specifically in response to core developers asking for this, and encouraging this work - subsequently however, those contributors were not involved in the decision making process to adopt Qt5, let alone make it an optional dependency.

While Qt5 would still be an awesome feature from a Canvas perspective, it is simply not an option as long as it is entirely optional, because at that point, some Canvas-based MFD features would no longer work for FlightGear versions without Qt5 support included.

The "pui2canvas" parser demonstrates that this is perfectly possible, with very compact code - last I checked, it was somewhere around 350 lines of code and was able to render a fully functional dialog like this:

http://wiki.flightgear.org/Howto:Proces ... ing_Canvas
Image

Bottom line being: if you care about simulating modern avionics in FlightGear (think MFDs with ARINC 661-level features), e.g. modern airliners (737, 747, 767, 777, 787, any Airbus), bizjets or even spacecraft, you likely want to ensure that a Canvas-based feature can be treated as a "widget" by the integrated UI - so that a MFD can be shown in a dialog. Equally, you will want to be able to render GUI widgets to a Canvas, without duplicating code unnecessarily.

As long as these two use-cases are supported, we can trivially implement built-in editors for things like 2D panels, HUDs or MFDs (imagine having a PFD/ND editor which includes styling).

However, what is currently happening is that functionality existing in Nasal/Canvas space is duplicated in C++ space - which is also introducing regressions, and added maintenance workload, because anything in Nasal/Canvas space can be maintained by fgdata committers, while C++ stuff can obviously only be maintained by core developers.

This is an advantage that the Phi and Canvas approaches have in common.

At the end of the day, it is your call, i.e. depending on whether you care about the use-cases discussed above, or if you'd like to see increasingly diverging/incompatible features being implemented, which may not seem like much of a showstopper currently, but which is going to cause a lot of whining once aircraft developers begin to notice that a non-Qt5 build will not support certain Canvas MFDs.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Aircraft reselection qt5

Postby Parnikkapore » Sun Jan 10, 2016 10:35 pm

Are you planning for native-looking dialogs?
[spoiler] WATCH OUT! The canvas dialogs look like Ubuntu EVEN ON WINDOWS! [/spoiler]
There are free alternatives to every program you encounter. You just have to find them.
Parnikkapore
 
Posts: 810
Joined: Thu Oct 29, 2015 10:16 am
Callsign: HS-FGS
Version: next [PPA]
OS: Mint 18

Re: Aircraft reselection qt5

Postby Hooray » Sun Jan 10, 2016 11:05 pm

That is what Qt5 will basically accomplish - Canvas however is using GUI elements from Ubuntu, so that's why it is looking similar.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am


Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests