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 Thorsten » Sat Oct 17, 2015 5:43 pm

Given the state of plans as outlined on the mailing list, I think this would be most useful to have, if only for a transition period.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Sat Oct 17, 2015 6:03 pm

The parser processing scenario.xml:
Image


Thorsten wrote in Sat Oct 17, 2015 5:43 pm:Given the state of plans as outlined on the mailing list, I think this would be most useful to have, if only for a transition period.


I have been documenting the whole journey on the wiki, including a number of patches and references to the underlying README files, and/or Nasal APIs. And I am also planning to regularly add the updated parser to the article - in other words, people can decide for themselves if they want to use this or not (temporarily or not).

From my standpoint, it's just a mental exercise, and a good way to stress-test the Canvas system, too.

However, like I stated roughly a week ago: I have no intention to come up with a full parser, or full Canvas widget set, for the time being - especially given the unclear situation regarding Qt5.

I have been in touch with a handful of people who have previously expressed an interest in having a Canvas UI, and basically all of them told me that they'd be hesitant to get involved in this, due to the Qt5/Phi situation, which could basically render the "pui2canvas" parser redundant/useless shortly.

Personally, I am not going to compete with any core development efforts, so I am just coming up with a proof-of-concept, covering the more difficult features (embedded Nasal, canvas, fgcommands) and will release this "into the wild".

Either way, I think I have demonstrated by now that a single contributor can come up with 200-300 lines of Nasal code to parse a relatively complete subset of PUI/XML within jus a few days, and that writing a parser scales much better in comparison to literally porting the whole UI (no matter if done in a scripted or manual fashion).

Especially when it comes to long-term maintenance, and assets outside the $FG_ROOT/$FG_ADDON domain (e.g. external hangars).

However, should anybody seriously hope for this to "take off" (and possibly even "fly"), it would make sense to establish, and document, a consensus that people can rely on - absent that, I don't see anybody joining this effort anytime soon. Because the situation is too uncertain, i.e. too many contradictions and overlapping efforts.

Let me re-iterate, I don't have the slightest objection against Qt5 (or Phi for that matter), and I absolutely share the concerns of adding even more Nasal-based code to the main loop. Especially given that Nasal runs indeed in the main loop, and that none of the FG APIs can be considered thread-safe, and that our Garbage Collector (GC) is a mark/sweep one.

But we don't seem to have many other options, short of revisiting the whole Qt5 discussion, because we would otherwise be adding an "optional" dependency to the build process, while tying more and more useful functionality to it, without satisfying the MFD use-case - i.e. people wanting to render widgets to a MFD, and MFDs to a widget.

As things are standing now, this could probably be "finished" within 2-3 weekends - i.e. throwing different dialogs/widgets and features at the parser, and incrementally adding/refining missing stuff.

In other words, even if this should end up exceeding 1000 lines in size - it would still be trivial compared to all the dialogs it is loading/parsing and displaying ...

However, there definitely are plenty of opportunities to not just optimize the parser, but also the underlying Canvas code for this particular use-case, as well as incrementally optimize the way our dialogs are structured (which is frankly a huge mess).
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 27, 2015 7:41 pm

Thorsten wrote in Sat Oct 17, 2015 5:43 pm:Given the state of plans as outlined on the mailing list, I think this would be most useful to have, if only for a transition period.


The other issue being that the way the Qt5 code is currently used in FlightGear is becoming more and more known for triggering entirely new bugs, such as segfaults and race conditions (multi-threading issues).

Bugman and others have mentioned a number of more or less serious issues related to the way FlightGear is using Qt5, with backtraces usually pointing at the Qt5 layer in FG.

For some background, I suggest to check out these postings:

So regardless of Canvas, and no matter if Qt5 is going to remain optional or not - it seems prudent to make sure that such issues are well-understood, and in fact, fixed, before Qt5 is going to be used more - even for implementing optional features, especially once the corresponding Qt5 code is not only going to run during startup (as it is the case for now), but also after startup (which will be the case, once the UI will be implemented by Qt5).

Personally, I don't have the slightest doubt that this is due to the way the FlightGear code is structured, and that those bugs (crashes) are not inherent to Qt5 at all - however, it is worth pointing out that the corresponding integration layer was written by one of the most active FlightGear core developers, who has been involved in FlightGear for over ten years, and who is enormously experienced and highly familiar with FlightGear and Qt internals (having single-handedly rewritten reset/re-init and handled the implementation of tons of other difficult features, including the SQLite NavCache).

So given that most of us others don't have this background, it is probably a good idea to be careful about adding more non-optional Qt5 based features to the FlightGear runtime code, as long as existing issues are not well understood and fixed, or we may be in for a bug surprise.

And this has nothing to do with Qt5 or Canvas - if the latter were known to cause non-deterministic/hardly-reproducible segfaults, it would also not be a good idea to use it for implementing and providing non-optional features at run-time that may end up crippling the FG experience for others.
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

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest