Board index FlightGear Development Canvas

Aircraft Center | pui2canvas parser (devel-list follow-up)

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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Thorsten » Fri Jun 17, 2016 6:29 am

Thorsten - one of the ideas of using Qt5 is to provide dialogs that the current primitive PUI system cannot even come close to providing.


Yes, that's cool.

So suppose we get super-fancy weather dialog. But the current weather dialog also works - because at the end of the day, what the dialogs do is set properties, execute FGCommands or start Nasal scripts. The fact that you have created a super-fancy dialog to do these tasks doesn't mean the simple one stops working. While the visuals of the dialogs can be really complicated, how the dialog communicates with FG is very well defined.

It's like saying Phi will stop working because there's Qt - it won't, because internally it also sets properties, executes FGCommands or scripts. New widgets don't equal new ways to interact with FG for your module - how you interact with FG is determined by what the subsystems understand, not what your dialog does.

The same way as a launcher is just a fancy way of assembling a commandline, and... you can just skip it and type the commandline.

Reading through what you write here one could get the impression that there's a well-defined migration plan. There is not - I've been talking to TorstenD in person about how he sees the future of Phi and what he envisions, and he had a couple of good ideas, but nothing like a concrete plan. I've been asking several times on the list for what's forseen for aircraft dialogs, and I got a couple of ideas in return, no clear migration path. That's because such a master-plan doesn't exist - we make it up as we go along. So you can chalk it all up as a modification to the plan...

In my view (and I've said this a few times) a canvas GUI is a reasonable way to be able to drop PUI rather sooner than later, a good fix for the AMD rendering issues, the only option proposed so far for legacy aircraft dialogs, and fits nicely into two ideas that have been brought forward a couple of times, which is that Qt is supposed to be an optional dependency and that the FG GUI is supposed to be modular.

I have yet to hear any counter arguments.

If someone seriously believes the Qt plan for FG can be derailed or endangered by a minimalistic pui2canvas parser, then this prompts the question how solid the Qt approach is in the first place. Personally, I don't think it is that fragile.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby bugman » Fri Jun 17, 2016 12:40 pm

Hooray, if you haven't already realised, everyone's aims are slightly different. Especially what you and Thorsten would like out of the Canvas GUI. That is what my postings essentially all come down to - to stimulate discussion on GUI transition areas that, at least to me, no one is clear on and where there is a distinct lack of clarity.

Btw, I'm using the CUI acronym so I don't have to write Canvas GUI every time I talk about the Canvas GUI, because repetitively typing Canvas GUI is tedious as Canvas GUI is quite long and CUI is easier to type than Canvas GUI. As for proving my points, that is not necessary as they are not points but rather pure opinions. I will stick with my opinion that Thorsten's desire to have a pure CUI driving FG - which does not match your aim - is a mammoth task. Anyway, please feel free to correct any of my following opinions and views:

  • The PLIB GUI (PUI) is dead and it will be stripped out in its entirety from FlightGear as soon as possible.
  • The core development to replace this will be the Qt5 GUI (QUI).
  • The CUI as you envisage it will not replace the current PUI. Pui2canvas is only one part. But without implementing other parts, without PUI (or QUI) you cannot get to the dialogs.
  • The CUI as Thorsten wishes it to be will be a minimal but stand-alone environment. The CUI will be able to launch the dialogs.
  • Fully replacing PUI with pure CUI is a mammoth task.
  • The PUI-XML will be supported for legacy dialogs.
  • There is no reason to be bound to the legacy PUI-XML for new GUI developments. This is an extreme restriction on the full potential that Qt5, or any modern GUI toolkit, can bring.
  • The current Qt launcher and aircraft center do not use the legacy PUI-XML. To me this is pretty obviously a big hint for future QUI developments - i.e. PUI-XML will only be supported for legacy stuff.
  • James may not take up your pui2canvas parser, as there is a glaringly obvious communication barrier. Let me quote the FlightGear policy document: "All decisions affecting the core of the project (e.g. simgear/flightgear source code, fgdata, releases, infrastructure, future direction) are made on the flightgear-devel att lists.sourceforge.net mailing list". James, like many core developers, does not have the time to follow the forum. Therefore if those behind the CUI do not communicate person-to-person with the other GUI developers on the mailing list, pui2canvas will unlikely be incorporated into the QUI.
  • A good example of the barrier is the fact that both the aircraft center and the airport layout UI element in the airport selection UI have been reimplemented in pure Qt, not using any of the existing canvas work.
  • This disjoint between the QUI and CUI will continue, so that in the end the QUI may not use canvas at all.
  • Thorsten's opinion and vision of the CUI is different to yours, so he cannot effectively communicate your aims and desires to James.
  • My knowledge of the CUI is insufficient for me to communicate your aims and desires to James.
  • I am not against the CUI developments under any of the different visions for it.
  • I will not argue against CUI.
  • My argument on the mailing list was to not stop the PUI->QUI transition.
  • This is not a flamewar but rather a long overdue discussion.

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

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Thorsten » Fri Jun 17, 2016 2:51 pm

But without implementing other parts, without PUI (or QUI) you cannot get to the dialogs.


Right... What other parts? Do you honesty think that it's difficult to open canvas windows from Nasal? Do you really believe we need PUI or Qt for a job which is a one-liner?

Fully replacing PUI with pure CUI is a mammoth task.


See above... It's the whole point about using tried and tested FG-native technology - it's all there. We know how to do it. It's been debugged to death years ago.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Fri Jun 17, 2016 4:46 pm

Just briefly, given that we can parse pui/XML to create dialogs, we can just as well create a fully functional menubar to call the corresponding show-dialog commands, which is not really complicated to do... (ignore the dialog decoration, I added that for better debugging)

After all, a menubar is just a transparent window with event handling enabled
Image

It's roughly 50 loc to do this, and create the corresponding pop-up for each submenu
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sat Jun 18, 2016 10:01 am

@bugman: Regarding your other posting, given that you are mainly stating views and opinions here, I would suggest that you actually review the corresponding discussions in the archives - it's not that this is a long overdue discussion, it has taken place years ago, and what you have posted now looks like a pool of questions that could be easily answered by referring to those topics, or even just by reviewing the pointers collected in the pui2canvas parser article; there really are too many conceptual issues in your posting currently.
Likewise, I am not asking you, or Thorsten, to communicate my perspective to James, Torsten or others - had you looked up the corresponding topics, you would have noticed that James himself made these exact same points several years ago, so I am merely rehashing the original core developer consensus back then, and posing the question whether it is fair to claim that this stance has "evolved" and that many of the original technical arguments made back then, are simply no longer applicable.

Besides, thanks for clarifying why you're using "CUI" as an acronym, but I did realize why you used it, I just STILL don't know what you want it to stand for - honestly, and without meaning to offend, I am not getting the impression that you are commenting here on something that you really understand, despite a number of postings, and pointers, posted to provide the relevant background information - information that would be valuable even if you ignored everything that I have said and written about the topic.

Like I said previously, there are different components available in FlightGear - as in an existing "Canvas GUI" SGSubsystem that runs inside the main loop, which all Canvas code can leverage - aside from that, there are widgets, and a framework to easily create new widgets - including a SVG parser that can reuse JavaScript/HTML based widgets.
Apart from that, there is the pui2canvas parser that maps a subset of the legacy PUI markup to this existing infrastructure.

Trying to encourage me to participate in the devel list, you have told me more than once previously that my signal-to-noise ratio would be exceptionally good in this case, because I am actually familiar with the corresponding C++ and Nasal modules (PUI, Canvas and to some extend Qt5/launcher), and have actually come up with code that just works - thus, I don't quite get why you are not simply reviewing the pointers that I have posted to make up your own mind - as far as I can tell, there's a huge disconnect between the different concepts and ideas brought forward here.

For instance, just look at your comment regarding James not taking up the pui2canvas parser: That was never the point of what I said, I specifically referred to the Canvas GUI SGSubsystem, referring to the challenge of rendering a Qt5 widget into the existing FlightGear OSG/OpenGL window - I said, that this is exactly what the Canvas system has successed doing, like ~5 years ago - and that this would be the best/easiest option to make the Qt5 stuff work inside FlightGear - totally unrelated to pui2canvas or PUI specifically.

Please, do me a favor and at least try to do some reading prior to making these bold and authoritative postings, especially if you otherwise end up bailing out claiminig that you're just posting your "views" and "opinions" - in that case, it would make much more sense to pose those as questions. What you have done so far in this discussion (excluding your last posting) is making it all sound decided and final - whereas the opposite is the case.

I do realize that you are trying to interface between the forum and the devel list, but for that to succeed, you really need to understand the concepts and ideas you are juggling here, or you are just adding to the confusion.

Bottom line, the Canvas UI SGSubsystem is there, it's existing C++ code, that has been integrated years ago - it's used every day - whenever you're seeing a tooltip, a Canvas GUI dialog or a CanvasWidget, it's all there and just works.

If people find it challenging to render a webkit or Qt5 widget into FlightGear, they'd be well-advised to simply come up with a custom Canvas::Element child class - which I also understand how to do, and James has previously done that, too (he implemented/prototyped Canvas::Image for handling raster images), so he understaands perfectly how to extend the Canvas system to support other "elements".

This path is unrelated to PUI or pui2canvas - it's just a way of rendering into the FligthGear window, without having to do much homework - it'll just work, which includes event handling etc - Tom implemented that almost half a decade ago, indeed at the encouragement of James and others back then ...

It is how I prototyped support for rendering PDF files and 3D models to a Canvas:

Image Image

Finally, the replacing the PUI menubar with a Canvas-based one is trivial - the code on the wiki actually worked, i.e. is parsing menubar.xml and creates buttons that create popups with the corresponding entries.

Anyway, I have tried to kept this positive - realizing that you're trying to be part of the solution and not the problem, but the degree of misinformation you're spreading is not exactly encouraging, and I am frankly annoyed by that, especially given that the facts are not just there in the form of devel list postings, but actual commits and code in SG/FG proving you wrong.

The way you have introduced the CUI acronym, and been using it, you are hugely misrepresenting the state of Canvas affairs in FlightGear - especially because that has zero to do with the menubar or pui2canvas efforts.


In summary, the pui2canvas effort does not need to be used, supported, endorsed or even just reviewed/committed by any core developers, because it's just a tiny, and optional, Nasal/Canvas module that can be added to fgdata by fgdata contributors - or even just distributed as a self-contained Nasal module that can be dropped into $FG_HOME/Nasal - and it just works, so there really is no "disconnect" or "communication barrier" here - that debate took place years ago, and James himself came up with most of the ideas related to this, we're really just implementing his original proposal - regardless of his Qt5 work, and regardless of his current priorities - he not only came up with these ideas, but approved them and encouraged this work, just like he encouraged the development of the Canvas based aircraft center

So please stop spreading all this FUD, and consider reviewing what has been said and done so far - and you would notice that the Qt5 launcher simply cannot reuse any Nasal/Canvas stuff due to the reset/re-init system not initializing Nasal early enough.

So far, it's been implemented as a startup option that isn't well integrated with the main loop or other SGSubsystems - thus, nasal/canvas are only just about to become actual options here.

And it's typical OSS-"surival of the fittest" that will prove which approach is superior in terms of workload and resources/expertise required to implemend and maintain these features in the mid-term. Thus, I absolutely share Thorsten's view - and I do know to implement everything that Thorsten would like to see, without it causing tons of work, which is why his comments were spot-on: If people really wanted to get rid of PUI, it can be done fairly easily and quickly, without requiring any support/endorsemeent from any core developers - regardless of efforts that they consider competing/conflicting by their nature
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sat Jun 18, 2016 10:13 am

I challenge you to strip out PUI from the compilation

as a matter of fact, you don't even need to "entirely strip out PUI from any source code" to see that this works, because you can use the corresponding fgcommands to remove the entire PUI subsystem at runtime - e.g. using what you referred to as "segfault heaven":

http://wiki.flightgear.org/Howto:Reset/ ... leshooting
Image

In other words, pui2canvas can be solely implemented in fgdata space, and it can even remove PUI at runtime ...
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Thorsten » Sat Jun 18, 2016 12:18 pm

Fully replacing PUI with pure CUI is a mammoth task.


Well, perhaps one more comment to that...

As said earlier, any UI talks to FG in terms of setting properties, calling FGcommands and Nasal scripts. Pretty much anyone who has done a glass cockpit for FG has solved the task.

In fact, the Shuttle UI with the combination of MEDS/DPS pages, the keypad entry, the various keyboard to IDP to screen mappings and the major function/major mode constraints is much more complicated than FGs PUI. It'd be trivial (and amusing) to let some fictional Shuttle DPS pages control FG settings - it'd be straighforward to do because the DPS does what any GUI does - it communicates with FG via properties, FGCommands and scripts.

So what you call a 'mammoth' task (providing a graphical representation for communication with the rest of FG) is in fact exactly what canvas is for and what it does in every aircraft that uses a more advanced glass cockpit. Without any major problems really... Really all that is needed is the xml parser and the widgets - the rest is all there and has been used for years.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sun Jun 19, 2016 10:14 am

agreed, that also means that the pool of experienced Nasal/Canvas contributors (i.e. those who have done some Nasal/Canvas hacking for their aircraft), and thus potential UI contributors is much larger in the FlightGear community compared to, say, people familiar with the FlightGear/SimGear code base, and Qt5 development in particular.

Like Thorsten said, the bottleneck is creating a parser that supports a sufficiently complete subset of PUI/XML as it is used in FlightGear, and coming up with the corresponding widgets provided/used by FlightGear's PUI/XML interface.

Fortunately, there is a SVG parser that we can use to reuse JavaScript/SVG widgets and render those inside FlightGear - but once you look at the roughly ~15 tags/widgets we need to support, you will realize that most of the ones we don't currently support, have fairly common requirements - e.g. implementing a single "list" widget can serve as the baseclass for ALL PUI lists, including the property browser, airport list, waypoint list etc - as a rough, but functional approximation, I put a property browser together that merely renders one button per child element to a scrollArea, and which updates the list once a button is selected/double-clicked - and that's roughly 30 lines of code, and actually working (ignore the appearance, all these screenshots simply ignore most layouting directives for the time being):

Image

Which is to say, that -like James originally said- supporting (and thus, parsing) PUI/XML is the only sane way forward to deal with existing legacy UI dialogs, short of volunteering to not only rewrite the whole UI engine, but also dozens of UI dialogs (and related features) that we have accumulated over many years.

For example, porting the airports.xml dialog, any of the weather dialogs, or the checklist/tutorials stuff over to a new UI framework would take more time, people and other resources than extending the parser to support these dialogs without introducing any major regressions - e.g. here's what the nasal-console.xml dialog looks like currently:

Image

Obviously, this is missing some features - but just extending the parser to support those, will mean that all other dialogs (including those outside fgdata/fgaddon) would benefit from that.

Thus, while the pui2canvas approach is not intended to "compete" with other UI efforts - any other UI effort not using the parser-approach is sooner or later going to face the breakeven point where parsing a sufficiently large subset of PUI/XML is much less work compared to rewriting most of the current UI dialogs, and that even applies in a scenario where most/many of these dialogs would be ported in a scripted/semi-automated fashion.

In contrast, the pui2canvas parser really only needs to work, and look, good enough to work for most people, and whenever something is incomplete/lacking, it is a single module that needs to be updated/maintained for the whole UI to benefit.

Thus, even unrelated to Nasal and Canvas - it really is like James and other stated repeatedly, parsing and supporting PUI/XML is the only sound, and feasible, approach to deal with the current situation, unless there is a team of volunteers familiar with C++/QT and SG/FG to do all this work, without introducing major regressions.

We have seen how much "progress" has been made in the Qt department over the course of roughly ~10 months (as well as new issues caused by some added Qt related code), all this was mainly handled by a single enormously-experienced FlightGear developer - whereas the pui2canvas parser was prototyped within just a few days, and could be extended to come up to par with PUI in just a few more weeks, at which point PUI could be disabled at runtime (or stripped out entirely).


Thus, while I do think that a Qt5 UI would be desirable in the long term, it is like Thorsten said: we have a shortage of core developers (and apparently even a shortage of experienced Qt5 devs), but a comparatively large number of fgdata contributors who know how to use Nasal/Canvas and SVGs/Inkscape - sooner or later, aircraft developers will determine the pain/gain ratio of whatever solution is available to make their existing UI dialogs works; at that point, any solution that doesn't provide for a ~90% seamless/painless transition, is going to be controversial, "survival of the fittest" - which is why I James mentioned on many occasions that he wanted to retain PUI/XML support (unlike bugman's claims), as well as wanting to version, and extend, PUI/XML incrementally.
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby bugman » Sun Jun 19, 2016 6:56 pm

Hooray wrote in Sun Jun 19, 2016 10:14 am:which is why I James mentioned on many occasions that he wanted to retain PUI/XML support (unlike bugman's claims), as well as wanting to version, and extend, PUI/XML incrementally.


You're still missing my points. I'm never said this - you will not find me making that claim anywhere. There will be support for the old XML system. However the new UI will not be constrained by a technology abandoned 10 years ago. What this means is that for the Canvas GUI, the pui2canvas parser will only be one part of the technology stack required. You might also need qml2canvas, as well as new code to replicate the far more advanced Qt widgets used in the new FG GUI. But we have to wait and see what ends up being the best technology for new dialogs. If the Qt launcher and aircraft centre are seen as a precedent - a technology preview - then maybe the menu system and dialogs will in the end be hard coded into C++.

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

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sun Jun 19, 2016 7:19 pm

well, that's your "ideal vision", and I even agree with that to some extent - but you are drawing the wrong conclusions here, in a perfect world, that would happen - but in reality, we've seen a number of such incidents/efforts, where we allowed "the perfect to be the enemy of the good" - just look at HLA, which has been "around the corner" for over 10 years now, and which has literally blocked dozens of attempts at modernizing the FlightGear multiplayer system, as well as FlightGear's threading architecture, repeatedly referred to as being "pie in the sky" by some of our most senior contributors.

As a matter of fact, a number of long-time core developers were opposed to the idea of making Qt5 a mandatory build dependency - James has repeatedly stated that he agrees with this assessment - thus, replacing the non-optional PUI GUI without also providing an option that will work without said optional feature is unlikely to be particularly popular - especially in the light of new race conditions and other segfaults linked back to said code.

Frankly, as long as there is not a 1:1 mapping between the old system and the new UI system (without breaking existing features like tutorials, checklists and aircraft specific dialogs etc), QML (or whatever else you think is cool) is unlikely to be even remotely relevant in the context of FlightGear - keep in mind, you are talking about an optional feature after all - so why would/should that have any bearing on features that do not require optional dependencies at all ?

It would be pointless (and even more redundant) to map something like QML to Canvas - the sole benefit of the pui2canvas approach is that there's a huge repository of existing resources, whereas the Qt UI is just about to evolve, while being intended to remain entirely optional - as long as that is the case, it will hardly affect efforts to provide an approximation of PUI using built-in, non-optional, means.

Stating the opposite is like saying that existing Nasal modules would inevitably be affected by your FGPythonSys experiments, despite their optional nature.

Also, it really is like Thorsten said: It's a manpower thing, there is a single enormously experienced guy developing a Qt5 UI, who's been told to keep everything 100% modular and optional by fellow core developers, and there are like 20+ aircraft developers familiar with Nasal/Canvas who don't want to code a UI from scratch, but who also don't want to have to update all their dialogs - thus, teaming up to extend/refine a simple parser, without being subject to the core development bottleneck, is most likely the lowest hanging fruit - at least until /someone/ has actually ported the existing UI without causing major regressions; without using a parser/translator, that is simply not feasible without also having a corresponding team of experienced developers at your disposal.

Thus, QML and whatever Qt may be doing is irrelevant as long as Qt is supposed to remain an optional thing - when/if that has changed, the whole discussion has become moot, because at that point it would be a matter of mapping Qt5 to a handful of Canvas bindings, so that both systems can use each other - as long as that is not the case, it simply doesn't make much/any sense for other subsystems to take Qt5 into account, let alone introduce it for implementing non-optional functionality through some kind of backdoor (which is already happening with the catalog/package manager and hangar code anyway ...)

But we have to wait and see what ends up being the best technology for new dialogs. If the Qt launcher and aircraft centre are seen as a precedent - a technology preview - then maybe the menu system and dialogs will in the end be hard coded into C++.


Please just do us a favor and look up what's been said about this: James himself stated repeatedly that doing this would be a step backwards - currently, any fgdata contributor can contribute to the UI, if people like Thorsten suddenly need to wait for James to create, update and maintain dialogs, that would be considered hugely problematic quickly.

Besides, I honestly doubt that "the best technology" wins - otherwise, we would be having HLA support already, there are very real constraints that people need to take into account - and sometimes concessions mean that we can get something done without expending too much effort - which probably sums up why technologies like PUI, and Nasal, have survived for so long in FlightGear ... "fitness" is not necessarily a measure of "quality" or "elegance", but also of implementation/maintenance costs, i.e. how much effort is required to actually do something, and how many volunteers can step up to help with something.

If James decided to drop his Qt5 work, it would be virtual dead - in contrast, the pui2canvas approach cannot be simply "dead" (even if I were to disappear tomorrow), because its underlying technologies have become the cornerstones/pillars of avionics/MFD modeling in FlightGear.

Thus, people will always weigh the pros and cons of using different options - and personally, I'd only get involved in the Qt5 effort/code, if it was generally available.

Absent that, it will definitely remain much less work to extend the parser (or even come up with a new/better one from scratch), than manually porting all the aircraft-specific dialogs (think 777, f14, shuttle etc) - equally, checklists and tutorials must continue to work - it's not like the people implementing these features are automatically experienced Qt5 coders.

So, please, let's try to be real here ...
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby bugman » Sun Jun 19, 2016 7:32 pm

Hooray wrote in Sun Jun 19, 2016 7:19 pm:Frankly, as long as there is not a 1:1 mapping between the old system and the new UI system (without breaking existing features like tutorials, checklists and aircraft specific dialogs etc), QML (or whatever else you think is cool) is unlikely to be even remotely relevant in the context of FlightGear - keep in mind, you are talking about an optional feature after all - so why would/should that have any bearing on features that do not require optional dependencies at all ?


It may be optional, but it will be the default for all users of pre-compiled binaries on all operating systems.

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

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sun Jun 19, 2016 7:53 pm

I am well aware of that, but given that the FlightGear core developers have, by consensus, asked for any Qt code to remain entirely optional, it doesn't make sense to let its use affect non-optional features - it would be akin to saying that JSBSim and YASim need to make changes because MATLAB is optionally supported and enabled.

(let's ignore the segfaults for now ...)

You only need to look at the commit logs of the Qt5 code, and then compare that to the commit logs of non-optional features, such as the Canvas system (sg, fg and fgdata) to see for yourself that there clearly is a bottleneck, and that all this work rests on the shoulders of a single person - I think you may be hugely underestimating the amount of work that lies ahead, and the benefits of a simple parser that can help implement support for the existing UI resources, without introducing additional dependencies, and which can even help facilitate making UI dialogs entirely declarative, i.e. by getting rid of custom Nasal blobs and introducing custom fgcommands, layout/widget APIs as needed.

There's a reason why Nasal and PUI have been in use for so long, despite certain technical issues being fairly obvious.

The talks about ripping out PUI have been ongoing for years - and the most recent comments actually re-discovered the idea of absorbing pui/plib into simgear instead of ripping it out; which matches the ongoing commits with custom PUI widgets implemented/refined - i.e. no Qt code whatsoever.

For the time being, and given the recent commit logs, the most direct option to actually rip out PUI entirely is the pui2canvas approach (parsing PUI/XML and translating it to Canvas calls) - but that approach is not specific to the Canvas system, it could be just as well done for Phi/qt5 (including even the problematic use of embedded Nasal code) - in fact, the challenges James mentioned would be solved immediately by sub-classing QWidget and turning it into a Canvas::Element with event handling applied.

As long as the existing PUI-UI is not completely ported to Qt5, and as long as Qt5 is not a generally accepted build dependency, it is unlikely to have much/any bearing on the Canvas system, or the pui2canvas effort in particular, because other subsystems cannot afford being subversive to work around the core developer consensus by introducing qt code through a backdoor, it's as simple as that.

If a single guy volunteers to handle all that work, that's obviously great - but looking at the history of events in FlightGear, the work ahead may be hugely underestimated by some folks - which is why HLA, FGPythonSys and many other clever ideas are still "pie in the sky", despite being conceptually "perfect".

You know, we gotta walk before we run - and with the pui2canvas approach, you can actually simplify UI dialogs, to make them easy to process for external UIs not wanting to support embedded Nasal scripts.

There is no need to communicate this to anybody, it's a self-evident thing - and time will show that this remains true, even more so if/once people will move on (just look at Rembrandt, or compare basic weather to advanced weather - it's for a reason that fgdata solutions usually end up working so nicely)
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Sun Jun 19, 2016 9:48 pm

I have implemented a simple table parser (25 LOC actually) that converts tables into Canvas vbox/hbox layouts - and it can now process most table layouts - e.g. here's the timeofday.xml dialog (bindings are actually working as expected):

Image


Here's the earthview dialog:

Image

Note that it will add labels showing n/a for widgets not yet implemented (e.g. dropdown menu and sliders in the images above)

The other obvious thing missing in the first screenshot is that I am not currently setting up a callback to update <live> properties, but instead just display the property for now

Apart from that, it's ignoring the hrule and vrule widgets, too


Here's instruments.xml and radios.xml (same missing widgets for the time being, and ignoring most layouting directives):

Image

Image

And here's logging.xml:
Image

Note that the parser is now 420 LOC ...and I haven't touched a single line of C++ code, it's just Nasal and Canvas, with most functions being 10-20 lines in size.

Besides, it should go without saying that I also haven't had to touch any of the GUI XML dialog files or other files in $FG_ROOT - these are all unmodified files parsed by a standalone module that resides in $FG_HOME/Nasal and that registers itself as a fgcommand.

The same approach would work for rendering, and replacing, the existing PUI menubar - using a fraction of the code (and in fact, most existing code should come in handy to do this)
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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Tue Jun 21, 2016 5:08 pm

Thorsten wrote:In my view (and I've said this a few times) a canvas GUI is a reasonable way to be able to drop PUI rather sooner than later, a good fix for the AMD rendering issues, the only option proposed so far for legacy aircraft dialogs



FYI: I have been testing the parser with some aircraft-dialogs, and it is working nicely so far - next, it would make sense to provide 2-3 more widgets, but I will need to coordinate that with Tom (mainly a combo/dropdown widget and a slider/dial are missing - once these are available, most other dialogs can be simplified/represented using a combination of existing widgets).


Next, it would make sense to implement "pui-fgcommand-patching", i.e. mapping existing PUI fgcommands to the corresponding Canvas/widget updates (which typically involves just a property getprop/setprop call to get/set/update a widget's value), and then we can already begin looking at some of the more dynamic use-cases, i.e. procedurally created dialogs (think performance monitor, wildfire dialog, tutorials, checklists - and anything else going through gui.nas).

Anyway, the work is well-defined and also not exactly difficult either - let's keep in mind that this parser still is below 500 LOC in size, and that it is trivial compared not only to the Qt5/PUI code, but also to most of the dialogs, and their embedded Nasal sections, it is processing.

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

Re: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby Hooray » Tue Jun 21, 2016 6:26 pm

Hooray wrote in Tue Jun 21, 2016 5:08 pm:and then we can already begin looking at some of the more dynamic use-cases, i.e. procedurally created dialogs (think performance monitor, wildfire dialog, tutorials, checklists - and anything else going through gui.nas).


This took actually 20 lines of code to get working reasonably well, it mainly involves mapping dialog-new fgcommands to a hash lookup that can be used to register dialogs (=property trees) dynamically, so that it's just a props.Node lookup.

For example, here's AndersG's wildfire configuration dialog, which is not a static file in $FG_ROOT/gui/dialogs (ignore the title, it's still using the original code to build a title from the filename logic), but procedurally created from Nasal using the corresponding fgcommands (see $FG_ROOT/Nasal/wildfire.nas for details):

Image

Obviously, it's ignoring dialog/widget size for now - i.e. the real thing looks like this:
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 3 guests

cron