The parser processing scenario.xml:
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).