Board index FlightGear Development Canvas

New Canvas GUI

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: New Canvas GUI

Postby Johan G » Thu Oct 08, 2015 3:11 am

@Hooray: If I understand you correctly, the issue is that the Canvas GUI may be replaced by a Qt5 GUI that can not reuse Canvas widgets (in essence making it impossible to have a GUI dialog mirroring for example a NAV display), right?

Hmm, I think "development by voting" may be even less productive than "development by committee". ;) As often, long term stability would make people less concerned with doubts about the usefulness of their contributions. That long term stability can come from a project-wide vision or from an individual's vision for his own contributions, though in general it is better of both are aligned at lest to a degree.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6625
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: New Canvas GUI

Postby Thorsten » Thu Oct 08, 2015 6:50 am

Not a conspiracy, just a bunch of competing and conflicting ideas by some core individuals.
Maybe it is nothing more that the people working on it being to slow, or they themselves decided the hurdles are to great.


Yes, but that hasn't changed - it's in the nature of FG development. By and large, things happen because individuals believe in them and try to make them happen.

Sometimes we end up with different options to do the same thing - there's BW and AW nicely co-existing - each of them has a different scope, idea for the simulation and does different things. Which is why we have Rembrandt, ALS and default. Having competing ideas gives options and gives the sim a broader range of use cases - and often serves as an incentive to do better by adopting features the 'competition' has.

I think TorstenD stated this with respect to Phi pretty explicitly - he believes that this is the best option, so he provides it, knowing others may use other options.

The collection of statements Hooray has assembled only looks confusing if you see them as reflecting a consensus - but many of them are just personal opinions. I think I have said a few times that I would allocate framerate differently from Rembrandt and that is why I keep sticking with a forward renderer - but that's my opinion, not a consensus to discontinue Rembrandt development.

So the consensus according to my knowledge and according to asking once explicitly on the list is that Qt5 is not to be used in-sim, but can be used in a platform-independent launcher. Lots of other statements reflect private opinions on the potential of other approaches.

* James happens to believe in Qt5, so naturally he exploits the limits this consensus gives to the full and prefers to shuffle as much functionality into this as reasonable (by the time the in-sim aircraft center was done, I guess it wasn't clear at all how for Qt5 would go) - which is why he'd rather transfer the aircraft package management back to the launcher. Which is what we have seen now.

* TorstenD happens to believe in Phi, so he works on the html-interfaced GUI. He has made a few statements that he doesn't think the canvas approach is scalable.

* Clement used to work on a canvas GUI but has apparently given up because people told him they don't think it reasonable. Whether that qualifies as 'killing' competing approaches is in the eye of the beholder I guess. So if we want to canvas GUI, someone else has to step up and do it. Or figure out yet another way of doing it. Preferably in a scalable way, i.e. something coping with existing dialogs without manual intervention.

* I personally don't care what GUI we have - it's not something that gets me excited in any way, I just want it to work, and I don't need any launcher, commandline works best for me

I can't see any changes of late to this state of affairs, nor can I see any crossroads. I have seen many people express their dissatisfaction with the current GUI, but that neither means another replacement is imminent nor the case for Qt5 is stronger. I don't think we'll get a true Qt5 in-sim GUI without warning (opposition to that seems to have been strong), and I don't see anyone invest the manpower to replace the existing GUI by something that's not canvas - so the most likely outcome of the state of affairs is that the dissatisfaction with what we have will be addressed by optional out of sim solutions like Phi or an even more expanded Qt5 launcher/controller.

All I can see here is dissatisfactions that others follow their own best judgement.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby wlbragg » Thu Oct 08, 2015 7:17 am

Thorsten wrote in Thu Oct 08, 2015 6:50 am:[Yes, but that hasn't changed - it's in the nature of FG development. By and large, things happen because individuals believe in them and try to make them happen.


I agree with you completely, thus my closing comment.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: New Canvas GUI

Postby hamzaalloush » Thu Oct 08, 2015 4:52 pm

simple question: since James did indeed say "The in-sim GUI should probably be considered an experiment which won’t be developed further", does that mean that improvements wont be allowed? guess not(assumed) or else not by him directly, should ask the man himself.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: New Canvas GUI

Postby Johan G » Fri Oct 09, 2015 4:03 am

Some posts was moved to the new topic ALS vs. Rembrandt (forward vs. deferred rendering).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6625
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: New Canvas GUI

Postby Hooray » Sun Oct 11, 2015 7:06 pm

Update: This discussion has been going on behind the scenes, and Thorsten subsequently moved it back to the devel list, raising a number of open questions and asking for clarification - so anybody interested in the nitty-gritty details of Qt5 use in FlightGear, and the future of an integrated, OpenGL-based, GUI (as per PUI and/or Canvas UI) is encouraged to check out this discussion:

Thorsten's original posting: http://sourceforge.net/p/flightgear/mai ... /34531652/

James' (Qt5 developer) response: http://sourceforge.net/p/flightgear/mai ... /34532040/
Torsten's (Phi developer) reponse: http://sourceforge.net/p/flightgear/mai ... /34532079/
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Canvas GUI

Postby legoboyvdlp » Mon Oct 12, 2015 1:34 pm

As long as FGRUN continues to work, even if not included with the sim, I'm happy, I guess....
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: New Canvas GUI

Postby Hooray » Mon Oct 12, 2015 1:44 pm

legoboyvdlp wrote in Mon Oct 12, 2015 1:34 pm:As long as FGRUN continues to work, even if not included with the sim, I'm happy, I guess....


it will, the only method they are using to interact with the sim are command line arguments, i.e. the same stuff power users are using to start the sim without any GUI at all - so fgrun et al are not affected by plans to phase out/modernize the internal GUI.

However, future fgrun maintenance may be affected by the Qt5 UI becoming the "default" option for the majority of end users - as per Gijs' comments (see the Qt5 UI article on the wiki).

The safest option for fgrun/fgX and friends would be to process a file from $FG_ROOT that details possible startup options (options.xml) and simply provides a UI on top of these, so that there would be no tight coupling at all: http://sourceforge.net/p/fgrun/feature-requests/22/

options.xml and $FG_ROOT/Translations would need to be extended a little - but otherwise that could even be useful for the Phi/Qt5 efforts, i.e. a front-end agnostic mechanism for describing startup, and run-time, options that supports localizations, and that has otherwise no tight integration with the underlying binaries (i.e. no hard-coded assumptions).

Short of doing something along these lines, it is extremely likely that with the increasing plethora of FG front-ends, the functionality/features and use-cases supported by each will be more and more diverging over time.

Basically, options.xml would need to be extended to classify startup/run-time options, and to encode compatibility/exclusivity of options (think YaSim vs. JSBSim, AW vs. BW, ALS vs. Rembrandt) so that the UI front-end (Phi, Qt, Canvas, fgX, fgrun etc) would simply process an XML file and procedurally create a UI based on a PropertyList-encoded list of supported features/options and heuristics/rules.

The underlying control logic would ideally not use any custom Nasal blocks at all, but merely resort to property rules and XML state machine rules. That way, the UI would no longer matter.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Canvas GUI

Postby Hooray » Tue Oct 13, 2015 11:23 am

Given that this thread is titled "New Canvas GUI", here's a screen shot showing a procedurally generated version of the view.xml dialog, the parser is really rudimentary and simple, it does not use any fancy Nasal or Canvas constructs, it is not even OOP - in fact, it is roughly 100 lines of code, parsing only a tiny subset of PUI (layouting and styling missing obviously for now).
But it goes to demonstrate that without too much effort, we can process existing GUI definitions and procedurally interpret/convert those to Canvas widgets/properties, without introducing additional dependencies like Qt5 or having to run a browser to control FlightGear (Phi), while circumventing PLIB PUI entirely:

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

As you can see, this is really basic and unpolished (as is the underlying parser in its current form), but this is basically what can be accomplished with roughly ~100 lines of straightforward Nasal code, which maps PUI tags to Canvas widgets.

Image

In contrast to the Qt5/Phi efforts, this will only ever be about writing/maintaining a single module: the parser for converting PUI/XML to Canvas widgets, with all existing dialogs automatically benefiting from any improvements - including even external dialogs, living outside $FG_ROOT - e.g. aircraft dialogs.

In addition, this approach works with dialogs that contain tons of embedded Nasal code, including even procedurally generated dialogs.

The idea is not to compete with the Qt5/Phi developments, but to ensure that there is a sane migration path, without having to manually rewrite dozens of dialogs with tons of embedded Nasal code.

Also, there are a number of "procedural" PUI dialogs using the "show-dialog" fgcommand to procedurally generate/update a dialog - which includes key functionality like checklists and tutorials, which should arguably remain integrated with the in-sim UI anyway.

While I am not going to implement a full PUI/Canvas parser/widget set at the moment, I am going to continue adding to the article/code to document the whole process - because we will definitely need to be able to render UI widgets to a MFD anyway (think A380 MCDU), so we could just as well grow a library of useful widgets in the process of phasing out PUI.

As things are standing now, it seems clear that Qt5 is not going to become a REQUIRED dependency for building FG, which makes it difficult to rely on it for the MFD use-case.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Canvas GUI

Postby legoboyvdlp » Tue Oct 13, 2015 9:57 pm

+1 on making a Canvas gui.
Needing QT5 to have FG would totally suck.
Plus, thousands of hours would be spent on "why is there no menu" "you need QT5"
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: New Canvas GUI

Postby wkitty42 » Tue Oct 13, 2015 10:02 pm

if qt5 were required, it would be stated and possibly even a runtime version included... it isn't as bad as some make it out to be, really...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: New Canvas GUI

Postby bugman » Tue Oct 13, 2015 10:10 pm

There are not many computers on the planet that don't have a Qt app on them somewhere. The Qt libraries would be compiled into the release versions and nightlies, so it will be directly inside the fgfs binary file, as it currently already is anyway. So you'll get it without thinking. The only issue is for people compiling themselves. But if you can already handle plib and OSG in your building toolchain, then installing the Qt framework for compiling will be a piece of cake.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: New Canvas GUI

Postby hamzaalloush » Wed Oct 14, 2015 12:08 am

First, Canvas is under development, second, it depends on Nasal, while i'm not an expert, i say it's like the curse binding plib to OpenGL.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: New Canvas GUI

Postby Hooray » Wed Oct 14, 2015 11:25 am

I think you'd be hard pressed to come up with evidence that I am fundamentally against Qt5 - in fact, you will find me having made references and suggestions related to it, long before people came up with certain solutions - such as the "webkit/Qt" reference below - all this was at least 6+ months ago, quoting just two postings I made back then (which is to say that I don't disagree with using Qt, but with the chaotic situation resulting from all those contradicting statements):


Technically, it is the right solution to get rid of legacy GL code, but also to get rid of Nasal code in the main loop, and to stop using niche solutions that are "home-grown".

A Canvas UI is certainly not perfect, it is true that it would introduce even more property/Nasal overhead into the main loop, and some widgets would also still need to be created/extended to support existing PUI functionality. But given the trivial nature of PUI, most functionality can be easily re-created.

Also, it would be entirely "custom", too - not unlike Nasal scripting in FG (which really isn't commonly used elsewhere). With the majority of FG components being unmaintained these days, it makes absolutely sense to adopt an industry standard like Qt.

However, a corresponding parser could be written with probably ~1k LOC - and it is straightforward to do, even compared to the existing NewGUI code wrapping PUI (mapping it to xml/properties), and there were plans being discussed to phase out the built-in UI anyway. So for the time being, Nasal/Canvas CAN provide an in-sim UI, without requiring Phi/Qt5. And that could be useful, even if just during the transition time.

As can be currently seen on the devel list, the situation and the repercussions resulting from it, are far from being clear.

According to recent devel list statements, Qt5 is not intended to be required for building FG, even though useful functionality is going to be increasingly tied to it (think launcher, in-sim UI, package manager, AircraftCenter UI).

In a perfect world, we could just discontinue features - i.e. in a major release like FG 4.00 and get rid of PUI entirely, while making Qt5 a mandatory build dependency, which would also help other parts of FG, unrelated to its UI (think threading, networking etc).

Even despite excellent documentation, support and tools - creating a Qt5 dialog is more akin to "coding" than creating a functional PUI/XML equivalent.

Given the current situation, making Phi the default UI scheme and rendering it to a WebKit overlay into the main FG window (like we talked about 6+ months ago) isn't all that unattractive after all ... And for that, not even Qt5 would be required, because WebKit could also be wrapped by a Canvas element - not unlike the PDF viewer idea we've been discussing.

However, it will be interesting to see what consensus people arrive at, and to see if/how that will materialize specifically.

In the meantime, people can refer to the wiki article for isolating themselves from the whole UI situation, by using/extending a snippet of Nasal code that can be used for loading existing dialogs - i.e. regardless of the outcome of the Phi/Qt5 discussion, there is a fallback - and time will show if we are going to need it or not.

Personally, I don't care at all if Qt5 is going to be mandatory or not, as long as the GUI library can render Canvas textures, and as long as the GUI library can render its widgets to a Canvas - which really is required for the MFD use-case.

Finally, the parser is currently at ~150 LOC, and you can throw most dialogs at it and the output will look reasonable, despite many features not even implemented yet - and "bindings" are working correctly, too - including even embedded Nasal code-I think, even if someone were to come up with a Qt/Phi equivalent of the existing UI, it would be easy to match/beat with minor additions to the Nasal parser-simply because we are really just writing a parser/converter here, and are not porting the whole set of PUI dialogs:
Image

Then again, performance is far from perfect during dialog creation (at least on the netbook I was using while prototyping this), and it seems obvious that the Canvas system would benefit from a few optimizations/additions (e.g. widget/dialog caching), but those would be useful to the whole Canvas system, especially should people still want to unify the remaining 2D rendering back-end (e.g. HUDs and 2D panels).
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New Canvas GUI

Postby Hooray » Sat Oct 17, 2015 4:34 pm

Here's a little update from the "parsing PUI/XML" front: The parser is now roughly ~300 lines in size and can deal with:

  • embedded Nasal blocks (open/close)
  • bindings in the form of fgcommands (standard & Nasal)
  • the PUI <format> tag (dynamic labels using sprintf-style strings with associated properties)
  • support for the <canvas> tag (including its own nasal/load section), which isn't really used widely, but is used in one of the key dialogs (airports.xml), for procedurally rendering an airport map with runways/taxiways (most recent addition)

Layouting obviously is still not implemented fully, and many PUI attributes (size, width, heigth, colors, fonts) are simply ignored for now - but it's pretty compelling given that this is just a parser, i.e. existing dialogs don't need to be touched/ported at all, and things will just work, and look pretty reasonable.

I did have to use a few workarounds due to limitations on the Nasal/Canvas side, but no show-stoppers so far.

Image

The other obvious issue are obviously all those hard-coded/custom PUI widgets (airport-list, property-list etc) - but it turned out to be pretty straightforward to come up with a simple Canvas equivalent (not even a widget in its current form):

http://wiki.flightgear.org/Howto:Proces ... ist_widget
Image
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests

cron