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.

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

Postby Hooray » Sun Jun 12, 2016 2:45 pm

Referring to the recent Aircraft Center/Canvas GUI discussion on the devel list, and the Nasal/Canvas parser I came up with to process PUI/XML dialogs and turn those into Canvas GUI dialogs, it's been suggested that I re-post my comments here for future reference:

I haven't really been following the debate on the devel list - and I am not sure I will have the time to catch up with everything that's been said - there's just one thing I'd like to clarify: this is NOT a separate GUI effort, it is a parser that maps our existing PUI/XML tags to the Canvas widget set, and absent those, to lower level 2D drawing and event handling code - which is how it gets away with being under 400 LOC.

I haven't really touched that code in months - but IIRC, I came up with all the proof-of-concept code within just a few days (just see the wiki history), i.e. a single guy could prototype a tiny parser that would be able to handle all/any existing dialogs (including those outside fgdata/fgaddon), while also providing a migration path, and interim solution until other issues have been sorted out.

What I implemented only dealt with a subset of the tags/widgets supported (e.g. no table layouts), i.e. it would definitely need to be extended to support certain widgets that PUI already supports (think dropdown menu), that are not currently available as dedicated Canvas widgets, work that would typically be the equivalent of coming up with a SVG file that implements the artwork, and a Nasal callback that implements the logic (update/event handling).

However, personally I am not the slightest bit opposed to Qt5 - in fact, Tom and I talked about it, and being able to just use Qt5 for the Canvas UI would solve a ton of issues for the Canvas UI effort, too - that is, if we could assume it to be ALWAYS available - but given that Qt5 has been a controversial dependency with some folks (not us!), we simply cannot rely on it to be ALWAYS available for the Canvas use-case, which would mean that certain Canvas efforts (think MFDs) would only work for Qt5-enabled builds, which is obviously a no-go, because at that point, we would be the ones making an optional dependency a required one ...

The real motivation for the Canvas UI is not reinventing the wheel, but being able to render widgets to a MFD and MFDs to a GUI widget (which is unrelated to the appearance of the widget, i.e. has to do much more with event handling and propagating events between different layers properly - imagine rendering a space shuttle MFD inside a GUI dialog, e.g. as part of the tutorial system - which may in turn render GUI widgets and/or external camera views: with the Canvas approach, we have a straightforward way to make this happen in a portable fashion, without platform/build specifics).

That also applies to external GUIs, or multi-instance/multiplayer setups that can seamlessly deal with multiple fgfs instances and selectively propagate/sync relevant state

Besides, Torsten and James are correct in saying that there are widgets that are not currently available via Canvas and which would need to be implemented, which would usually mean additional Nasal overhead (mainly timers and listeners).

However, that is not inevatibly the case - before the Canvas UI effort got declared dead, we talked about using Torsten's autopilot/property-rule subsystems to dynamically instantiate "property controllers" on-demand as part of the /canvas sub-tree (per Canvas or per element) to help update/animate Canvas elements - this would mean that the degree of added Nasal overhead would be kept to an absolute minimum that would only come to bear during initialization of the corresponding C++ data structures, but afterwards everything would be pure C++ code

The main thing that prevented us from adding more widgets at the time was the degree of artwork needed, which is why Tom ended up borrowing artwork from Ubuntu, and we contemplated using a JavaScript/HTML widget set using SVG artwork, so that we would not have to draw dozens of widgets ...

Anyway, the code I originally came up with is to be found here: http://wiki.flightgear.org/Howto:Proces ... ource_Code
To test it, all that needs to be done is to put it into a Nasal file that is loaded during startup (the console may work, too) - I would recommend to put it into $FG_HOME/Nasal/pui2canvas.nas

Apart from that, there isn't anything else needed from an integration standpoint, it will go through the fgcommand layer so that the parser can be tested by using a line like this:
Code: Select all
fgcommand("canvas-dialog-show", props.Node.new({'dialog-name':"view"}) );


Like I said, I haven't put much/any work, or thought, into extending it to support unsupported use-cases since there was so much opposition, but I don't believe it to be difficult to bring up to par with the functionality of PUI, including dialogs with embedded Nasal code, dialogs with embedded Canvas regions (airports.xml), as well as procedurally created/updated dialogs like the multiplayer/pilot list or performance monitor.

The work ahead is comparatively straightforward, and while it could definitely benefit from certain C++ additions, those are not needed - compared to the Qt5 work ahead of us, a dedicated fgdata contributor familiar with Nasal, Canvas and SVG editing could definitely provide a PUI replacement without requiring too much time - after all, the main work is extending the parser to support the existing PUI/XML format, and mapping that to existing Canvas features, and come up with new widgets for which we don't currently have matching Canvas widgets.

Which are basically the exact workflows aircraft/MFD developers are already familiar with.

From my standpoint, I would just like to use Qt5 if it was available, and I have been in touch with TheTom on adding the corresponding factories to the Canvas system - but if that is not an option because others don't want to require Qt5 for building FG, we still need a generic UI framework for all the use-cases not covered by optional Qt5 support.

As far as I can tell the main bottleneck is, like James and Torsten said, the number of available Canvas widgets/artwork - but if an existing SVG widget library is used, that could be quickly addressed, because we can already render SVGs and register event handlers.

Besides, the main loop/async point remains valid, but it would be possible for the Nasal/Canvas route to learn from Phi and use the same mongoose/httpd layer to run its property I/O and fgcommands asynchronously, at the mere cost of requiring the httpd service to be up and running for the UI to work in async mode. After all, all Nasal http I/O is already async anyway...

The best way to reduce Nasal overhead is expose more SimGear/FlighGear subsystems to scripting/Canvas space, so that e.g. property rules and state machines can be used for updating/animating Canvas elements - at that point, there's really no added Nasal overhead at all. Equally, it would be possible to not just support event handlers in the form of Nasal callbacks, but just fgcommands - which work without Nasal entirely.

The major benefit this would have is that Canvas is modern OpenGL/OSG code, and that it's integrated in an OSG--aware fashion, while also being property-tree enabled, which means that remote interaction scenarios can be easily implemented, which includes remote replication of UIs/MFDs etc.

I have seen some words of encouragement to pursue this further given the segfaults introduced by the Qt5 code, but it seems that bugman and James addressed some of those recently - so I haven't yet really thought about resurrecting the parser - however, it being just a fgdata module, it could obviously be added as a runtime option without requiring core developer support/endorsement necessarily - like some people said already on the forum, it might provide a sane option for users with AMD/ATI hardware that would otherwise not be able to use the UI at all.

Possibly, this may get more attention/traction once it is provided as a "fallback option" as part of the base package - and the way it is implemented, it is a Nasal sub-module that can be kept disabled by default, like some have suggested. However, it's not that it would actually "run" anything if the code is not used - the main overhead is the number of added GC symbols (variables), but otherwise there's no runtime footprint if it's not used

I will try to review the main points made on the devel list and see if a follow-up is needed, and/or if the parser should be resurrected (or just declared dead, too) - but like I said, none of the Canvas UI folks are opposed to Qt5 at all, if it were generally available (and not intended to remain optional), we would just jump onto the same bandwaggon and use it, as long as there are steps taken to ensure that we can render UI widgets to a Canvas texture and a Canvas texture to a Qt5 widget ...

Because this degree of supporting full "recursion" is it that would enable us to also create built-in tools (GUI editors) for creating, editing and maintaining resources like a HUD, 2D panel, cockpit instruments, splash screens or MFDs as a whole.

PS: I am also involved in a project using J661 (ARINC 661) in conjunction with FlightGear, which needs a way to render widgets to a MFD, so some of this is motivated by ARINC 661 compatibility - modern avionics like the Avidyne Entegra R9 will undoubtedly greatly benefit from a UI framework, unrelated to its appearance being different from the main UI or not - that's just a matter of styling, which the Canvas UI framework supports as a first class concept (it is even possible to retarget Canvas UIs to support mobile platforms, it's mainly scaleable vector graphics after all)
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 » Mon Jun 13, 2016 8:24 pm

https://sourceforge.net/p/flightgear/ma ... /35155239/
bugman wrote:It is clear that there is no one actively pursuing a pure Canvas GUI
(CUI). The development of the complete widget set required to fully
replace all elements of the dead PLIB GUI (PUI) would be a nightmare.



@bugman: no offense, but that's a rather serious misrepresentation of what has been previously said about this, and in fact even James and Tom originally researched what's needed to pull this off - the wiki article I sent you contains all the relevant pointers, it is far from a "nightmare" - if in doubt, I suggest to review the resources that have been shared with you. I realize that you are very much "pro Qt", but so are many of us - however, the consensus NOT to make Qt5 a required dependency was imposed on us by others, so we gotta work with that.

What may seem "clear" to you, is far from it actually - just like James recently stated that he felt discouraged working on his Qt5 code due to the Canvas UI effort, three different Canvas UI efforts got actively discouraged by a few core developers, which undoubtedly affected how much time went into the whole idea.

I am still not saying that this (i.e. a Canvas UI) is necessarily such a great idea - but this kind of misrepresentation isn't funny, especially given that you're well aware of the various views - and in fact, the main candidates (Phi, Qt5 and Canvas) could actually benefit from each other - the Canvas route could greatly benefit from being able to use Qt5, and Canvas could greatly help clean up/simplify existing PUI dialogs. Equally, some of the ideas used in Phi could be useful for the Canvas/Qt5 approach. I don't think this has to be a mutually-exclusive thing at all - the main issue is the degree of ugly Nasal hacks in those PUI/XML dialogs; however, these dialogs can obviously be processed via Nasal and Canvas easily - so that it would actually make sense to use this opportunity to refactor said dialogs and turn into just declarative XML using tags and fgcommand/remote properties.

Specifically, I strongly disagree with your notion of a "heavy Nasal back-end" and "complex widget set" - PUI is trivial to implement in Nasal/Canvas, it's an archaic 90s style widget set after all, and the degree of Nasal needed is straightforward, too - and far from "heavy", it's just tedious and redundant work, i.e. there are much more interesting things to do than re-implement a widget set in Nasal space.

For the record, the existing -list widgets wrapping the PUI list widget can be implemented using 50 lines of Nasal/Canvas code - there's nothing "complex" or "heavy" about that, and that includes widgets like the "property browser", which can be approximated rather easily, even without having to come up with the corresponding widgets from scratch.

It is kinda moot to mention the "policy document" in this context, because the declared core developer consensus is that "Qt5 is never going to be required for building FlightGear", while that document reads "replace built-in GUI using Qt5" (arguably not added/supported by the developers forming that consensus), the contradiction is self-evident I guess.

And no, I am not the slightest bit opposed to Qt5 (or Phi for that matter) - but this policy-making is really ridiculous, and all you are accomplishing with this is that I may actually take a little time to bring the parser up to par with the PUI widget set, and the Qt5 launcher, to prove you wrong - at least as long as Qt5 is not generally made available to us

bugman wrote:For the CUI, it's route is not PUI -> CUI. Instead,
the developer taking this route should come up with another way of
bootstrapping up that interface (just like the Phi UI). This will
however probably require the first and most difficult step of
developing a menu widget set (which will also be an interesting
problem to solve for the QUI).


Sorry, but, in the light of the two of us having literally exchanged 20+ messages specifically related to this over the course of several months, and the Qt5 effort specifically, this is as misleading/ill-informed as it gets, and thus, I assume it's just deliberately manipulative what you are stating here. You are either commenting on something without understanding its context, or you are ignoring everything that you actually should know better, much better.

I realize that you are usually trying to speak, and act, on behalf of the project, i.e. what you think is best for the project - but what you're commenting on here is just ill-informed FUD, and you should know better than make these postings - it's kinda disappointing to see your tactics applied in this context.

None of the people involved in the Canvas/UI effort were opposed to Qt5 at anytime - if you are so concerned about James dropping the idea, it'd be a much better idea to get involved in the approach that you believe in than deliberately misrepresenting facts, that are extremely well documented in the devel list archives, and even supported by comments made by James himself (as well as a bunch other core developers).

*plonk*
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 » Tue Jun 14, 2016 2:10 pm

Hooray wrote in Mon Jun 13, 2016 8:24 pm:https://sourceforge.net/p/flightgear/mailman/message/35155239/
bugman wrote:It is clear that there is no one actively pursuing a pure Canvas GUI
(CUI). The development of the complete widget set required to fully
replace all elements of the dead PLIB GUI (PUI) would be a nightmare.



@bugman: no offense, but that's a rather serious misrepresentation of what has been previously said about this, and in fact even James and Tom originally researched what's needed to pull this off - the wiki article I sent you contains all the relevant pointers, it is far from a "nightmare" - if in doubt, I suggest to review the resources that have been shared with you. I realize that you are very much "pro Qt", but so are many of us - however, the consensus NOT to make Qt5 a required dependency was imposed on us by others, so we gotta work with that.


No offence taken, because you may have missed the meaning ;) By nightmare I mean that to implement the full plib UI widget set used in the current GUI will require a tonne of work and debugging. Much of this is missing, and this is far more complicated than implementing a set of dialogs and buttons. The number of just generic widgets is quite high. But then there is the required asynchronous event messaging system, modal vs. non-modal elements, non-blocking threading, dynamic menus, window ordering, etc. And it will have to be packaged as one toolkit. The dumping of the XML menu system will also be a big issue (see below). This will be a mammoth task, by anyone's measure. That is why almost everyone just uses one of the pre-built toolkits, rather than spinning their own. So I see this reinventing of this huge wheel is far closer to a nightmare than to a redundant and tedious task.

As for Qt being optional, over the last two years on the mailing list, that position has obviously evolved. I'm only stating what I see. And that is that it will be only optional for a tiny subset of people. The majority will use it, probably without knowing, as it will be the default GUI shipped with FG. As the canvas GUI (CUI) is a long, long way from being a full replacement UI and being able to replace PUI, the small subset of people not wishing to use Qt will be missing a lot of features for a long time. Not working directly with the source code repositories or the mailing list is doing a huge disservice to the CUI idea and its viability.

What may seem "clear" to you, is far from it actually - just like James recently stated that he felt discouraged working on his Qt5 code due to the Canvas UI effort, three different Canvas UI efforts got actively discouraged by a few core developers, which undoubtedly affected how much time went into the whole idea.


I thought that was clear. This is also an evolving process shaped by the fact that the PUI -> QUI (Qt GUI) transition appears to be the only viable option going forwards. And the fact that people see the CUI as being a huge restriction on their ability to innovate on the GUI front, as the XML format is quite limiting and there is no well formed, isolated, and fgdata-committed canvas widget set to look at.

I am still not saying that this (i.e. a Canvas UI) is necessarily such a great idea - but this kind of misrepresentation isn't funny, especially given that you're well aware of the various views - and in fact, the main candidates (Phi, Qt5 and Canvas) could actually benefit from each other - the Canvas route could greatly benefit from being able to use Qt5, and Canvas could greatly help clean up/simplify existing PUI dialogs. Equally, some of the ideas used in Phi could be useful for the Canvas/Qt5 approach. I don't think this has to be a mutually-exclusive thing at all - the main issue is the degree of ugly Nasal hacks in those PUI/XML dialogs; however, these dialogs can obviously be processed via Nasal and Canvas easily - so that it would actually make sense to use this opportunity to refactor said dialogs and turn into just declarative XML using tags and fgcommand/remote properties.


This is not misrepresenting it. Coding a full set of widgets, including menus, trees, buttons of all sorts, sliders, etc. and having a consistent look and feel is hard. It requires careful planning and careful graphics design. And it will be much heavier than a Qt or other modern toolkit implementation, as it will be in the OpenGL and Nasal space.

Anyway, I think a CUI as an option is a good idea, if a complete GUI toolkit can be built. But this is clearly a mammoth task.

And a Qt-canvas merger for certain 'feature' windows would also be great, but that will require some communication and cooperation on the mailing list to let that happen. Otherwise it's pretty obvious that James will just continue to implement everything on the Qt side (think of the duplicated airport maps, but for all elements) until everything is in Qt and all canvas parts have been replaced.

Specifically, I strongly disagree with your notion of a "heavy Nasal back-end" and "complex widget set" - PUI is trivial to implement in Nasal/Canvas, it's an archaic 90s style widget set after all, and the degree of Nasal needed is straightforward, too - and far from "heavy", it's just tedious and redundant work, i.e. there are much more interesting things to do than re-implement a widget set in Nasal space.


I disagree. Implementing a fully functional GUI toolkit with all the required bells and whistles is not at all trivial.

For the record, the existing -list widgets wrapping the PUI list widget can be implemented using 50 lines of Nasal/Canvas code - there's nothing "complex" or "heavy" about that, and that includes widgets like the "property browser", which can be approximated rather easily, even without having to come up with the corresponding widgets from scratch.


I have written my own for my own software. It consists of 917 SLOC and 508 lines of comments. 50 lines might get a basic system up and running, but for a fully fledged property browser window, I cannot see how it won't be closer to 1k lines.

It is kinda moot to mention the "policy document" in this context, because the declared core developer consensus is that "Qt5 is never going to be required for building FlightGear", while that document reads "replace built-in GUI using Qt5" (arguably not added/supported by the developers forming that consensus), the contradiction is self-evident I guess.


The contradiction is the evolving position of the core group on the mailing list. But this is not a contradiction as it is forced by the fact that only a PUI->QUI transition is seen as feasible, and a PUI->CUI is not.

And no, I am not the slightest bit opposed to Qt5 (or Phi for that matter) - but this policy-making is really ridiculous, and all you are accomplishing with this is that I may actually take a little time to bring the parser up to par with the PUI widget set, and the Qt5 launcher, to prove you wrong - at least as long as Qt5 is not generally made available to us

bugman wrote:For the CUI, it's route is not PUI -> CUI. Instead,
the developer taking this route should come up with another way of
bootstrapping up that interface (just like the Phi UI). This will
however probably require the first and most difficult step of
developing a menu widget set (which will also be an interesting
problem to solve for the QUI).


Sorry, but, in the light of the two of us having literally exchanged 20+ messages specifically related to this over the course of several months, and the Qt5 effort specifically, this is as misleading/ill-informed as it gets, and thus, I assume it's just deliberately manipulative what you are stating here. You are either commenting on something without understanding its context, or you are ignoring everything that you actually should know better, much better.


I don't see how is this manipulative. This is the route that is actually currently in full progress. Note that the plan by the core developers is to dump the full XML PUI menu system in fgdata. The XML is seen as a severe limitation on the advancement of the FG GUI. Some parts may remain, specifically the aircraft menu XML, but it's pretty clear that most will go. The CUI will have to take this into account. The assumption that you can automatically translate the current XML into the full CUI system will need some reconsideration.

I realize that you are usually trying to speak, and act, on behalf of the project, i.e. what you think is best for the project - but what you're commenting on here is just ill-informed FUD, and you should know better than make these postings - it's kinda disappointing to see your tactics applied in this context.


This is not on behalf of the project. It is simply what I see, and is what the commit logs for the repositories show. This has been discussed before, and it is committed into the FlightGear Policy and Roadmap Document. I have had zero influence on any of this. The transition from PUI -> QUI is clearly in progress. The transition of PUI -> CUI is not in consideration by the core. This does not however preclude the existence of a CUI.

None of the people involved in the Canvas/UI effort were opposed to Qt5 at anytime - if you are so concerned about James dropping the idea, it'd be a much better idea to get involved in the approach that you believe in than deliberately misrepresenting facts, that are extremely well documented in the devel list archives, and even supported by comments made by James himself (as well as a bunch other core developers).


In my mailing list post, I simply argued that the in-progress and agreed upon PUI -> QUI transition should not be stopped, and that an eventual CUI option should not be blocked, but implementing a pure CUI, which will be a mammoth task, is not currently planned. Which part of this sentence is not correct?

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 » Tue Jun 14, 2016 9:03 pm


  • FlightGear PUI/XML exposes, and uses, only a tiny subset of PUI functionality
  • the canvas UI system (as in C++ code) already implement z-indexing, event handling, window ordering etc
  • feel free to share with us any pointers regarding PUI's use of multi-threading
  • even approximating hard-coded widgets like the property-list can be done using roughly ~20 lines of Nasal/Canvas code (see below)
  • dumping the XML format is the most important reason /for/ using the "CUI" approach, because that can be orthogonal to Phi/Qt5 in that it can greatly facilitate these efforts, e.g. as a first step by moving custom Nasal blobs out of dialogs, and then adding version tags to each dialog, so that new tags/widgets can be supported - i.e. those that would fit a modern UI using Qt5/Phi
  • If you think that the project's position on Qt5 "has evolved", you would be well-advised not just to post your assertion, but to back up your notion by getting in touch with the folks who don't want to "require" Qt5 - at that point, this whole discussion is moot, and we can move on.
  • there's nothing XML-specific in the "CUI" approach at all
  • it's not rocket science to find the Canvas Widget API and a bunch of existing widgets using it
  • equally, you can find a SVG parser in the base package that could be used to reuse existing SVG widgets and render them via Canvas - in fact, you could even reuse JavaScript/ECMAScript bindings, because Nasal is similar enough ...
  • we don't need to "build a complete UI toolkit" to provide a fallback option for PUI, that's the whole point, which is why this effort cannot, and never will, "compete" with a Qt5-based approach

it's pretty obvious that James will just continue to implement everything on the Qt side (think of the duplicated airport maps, but for all elements) until everything is in Qt and all canvas parts have been replaced.


that's even worse than your previous postings: you cannot realistically "replace" those parts, unless Qt5 is indeed mandatory, and unless it is provided in a form that is compatible with the way Canvas is currently used for those "elements" - namely, avionics (MFDs).

Implementing a fully functional GUI toolkit with all the required bells and whistles is not at all trivial.

Absolutely agreed, but that is not, and never was, the focus/intention of the Canvas UI effort, let alone the parser we're talking about - I suggest that you really look up the history, because we're really just wasting our time here ...

50 lines might get a basic system up and running, but for a fully fledged property browser window, I cannot see how it won't be closer to 1k lines.


Ignoring some hidden features, the existing property browser allows properties to be treated like a file-system hierarchy that can be navigated, and to change property values. (hint: you could actually look at the underlying C++ code, the PUI/XML dialog opening that dialog to see for yourself what it is doing).

The Nasal/Canvas approach can get away with so little code because of the technology stacks it is using, Nasal & Canvas - which are well integrated with concepts like the property tree, so that we don't need to reinvent the wheel to come up with tree traversal helpers, but can simply use props.nas (for instance).

Frankly, I suggest that you focus commenting on Qt stuff, because that's clearly where your interest, and expertise is - you don't seem to have taken even just a minute to look up how PUI works in FG, how it is integrated (let alone how it is implemented), and how the Canvas system can _already_ approximate most of PUI's functionality fairly well.

Most of what you said would be 99% accurate under normal circumstances - but this isn't "normal", you are talking about FlightGear and the way it is using PUI, without having done any research to understand how all this hangs together. Most of your multi-threading and UI experience simply, and unfortunately, isn't very valid in this context ...

And that is not specific to Canvas - all this would be useful knowledge if you are truly interested in helping with the Qt5 work.


Anyway, let's agree to disagree - you don't seem to have actually looked at any of the modules in question, and while I am annoyed by that, and your tendency to still make certain comments, you are clearly wrong on technical grounds - and if others haven't it already pointed out to you in private, it is certainly because they share your conclusion/motivation - which is fine, I can live with that - but if you think that some developer consensus is "evolving", you would be better off not just interpreting things accordingly, but getting something to back up your "facts" - so that we can really move on, being able to use Qt5 everywhere would simplify a ton of things, not just the Canvas/UI 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: Aircraft Center | pui2canvas parser (devel-list follow-u

Postby bugman » Tue Jun 14, 2016 10:26 pm

I not sure we are even talking about the same thing. I thought that the current CUI efforts is not designed fully replace the PUI, and hence not compete with the QUI? But the current QUI efforts are designed to completely replace PUI? Qt5 will not be mandatory, but it is currently built in and shipped will all FlightGear releases, so almost all FG users will be using it? If you don't use Qt then, once the PUI is finally stripped out, you will not have any CUI menus? The entire context of my posts is that the PUI -> QUI transition is occurring, because a PUI -> CUI transition is not planned, would be a mammoth task, and there is no one working on that transition. There is nothing in there about the current CUI efforts. Due to the responses here, I can only guess that there is a misunderstanding or that I landed on a raw nerve of a previous Canvas vs. Qt conflict.

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 » Tue Jun 14, 2016 10:36 pm

I assure you that language is not the issue, and neither are the technologies involved in this - I am well aware of the Qt5 effort, of Phi, of the state of affairs of Canvas, and the pui2canvas parser in particular.

You've begun introducing new terms, terms neither of us was using previously, such as the acronym "CUI" (again, to mean what exactly?)

If you are specifically referring to the menubar, recreated via Canvas, that was something that Jabberwocky once started - and apparently struggled with, but apart from that, it's trivial compared to the pui2canvas parser; and assuming that non-Qt builds, without PUI, may still need a way to actually invoke those existing UI dialogs (provided via the pui2canvas parser), it would not be far-fetched to resurrect that idea.

Either way, it is at best very unfortunate to introduce new terms, and acronyms, as long as you cannot be sure that all parties are indeed on the same page - that, apparently, you've been adding to the recent confusion significantly.

All your Qt5/Python experience may come in handy regarding the Qt5 effort - however, you will find that most of it is frankly not relevant in the context of PUI in FlightGear, and the Canvas UI specifically.

As a matter of fact, you have been overloading terms that were previously well-established (in fact, there's a dedicated SGSubsystem registered with the name "Canvas GUI", which implements many of the things that you are so concerned about (z-indexing, window ordering, event propagation etc))

Either way, I am not sure why you are bringing up the menubar, and then mention widgets - re-creating the existing PUI menubar using Canvas takes probably less than 100 LOC, and has nothing to do with "widgets" beyond creating popup menus with a few buttons or text labels.
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 » Tue Jun 14, 2016 11:34 pm

I've introduced the acronyms when first mentioned. And I'm using them as there are so many user interface (UI) technologies being talked about that it is quicker to simply abbreviate:

    GUI - graphical user interface.
    PUI - the PLIB GUI or Picoscopic User Interface Library.
    QUI - the Qt5 GUI currently being built.
    CUI - the Canvas GUI.
My context for talking about these is for providing a full UI for the user to interact with FlightGear. You say that CUI and QUI do not compete. I say that they do not compete. As PUI is dead, the last release being 10 years ago in 2006, it needs to be replaced. Therefore the transition is PUI -> QUI, not PUI to CUI (otherwise CUI competes with QUI).

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 » Wed Jun 15, 2016 12:14 pm

Therefore the transition is PUI -> QUI, not PUI to CUI (otherwise CUI competes with QUI).


Competes for what?

Developer resources? Aka, the people who typically code Nasal are the same people who use Qt5? That'd be news to me.

Users? Maybe, but since when has that been an issue?

System resources? Since both approaches are envisioned optional modules, surely not.

So in what sense would there be a competition? As the strategic plan forsees optional GUI module use, they are just different options.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby Hooray » Wed Jun 15, 2016 11:22 pm

Sorry bugman, you don't make much/any sense - and I have really tried to interpret your postings in more than one way, regardless of your position (which is clearly pro-Qt5) - I don't seem to be able to determine what you are trying to tell us, apart from the obvious misrepresentation of facts that I pointed out previously.

Anyway, if what you say is true, you should definitely be able to put an end to this debate by posting the evidence that I asked for - no matter if that is referring to your notion of PUI's multi-threading bits, or the fact that the FlightGear project's stance on the Qt5 dependency has "evolved" meanwhile. Equally, nobody in their sane mind would arrive at the conclusion that something like 500 LOC of Nasal/Canvas could realistically "compete" with the Qt technology stack, that's just irrelevant FUD

Besides, I also still don't get why you digged out the menubar snippets referring to "CUI" - sorry, you didn't hit a raw nerve, you just don't make sense, and I am saying that as someone who's actually familiar with the corresponding UI modules/options, not just referring to the Canvas bits 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 » Thu Jun 16, 2016 5:25 pm

Let's create the following context:

  • Strip out the abandoned PLIB GUI (PUI) completely from the current FG code base.
  • Try to interact with FG without the menus.
  • Try to change some of the settings.
Obviously neither the Qt GUI (QUI) nor the Canvas UI (CUI) are currently up to the job of providing the required user interface (UI). The core developers, specifically lead by James, are making the transition of PUI -> QUI. And this will involve the removal of most of the XML for the menu system (hence why Torsten was talking about QML). I have no problem if the CUI is developed so that it can be used to fully interface with FG, and is provided as an optional UI. But if they do the same thing of providing a full in-sim GUI, then of course there will be competition (which is not always a bad thing). Anyway, I believe that Hooray's goal of combining CUI+QUI will not lead to your goal of having a simple UI based solely on XML+CUI. That is why I linked to the earlier attempt at a CUI menu system, as a menu system in the main OSG window is one of the essential UI components.

Regards,
Edward

P. S. Hooray, I have experience with 4 different GUI toolkits, but Qt5 is not one of them. But once you know one or two, switching to the others is a piece of cake.
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 » Thu Jun 16, 2016 6:01 pm

You previously mentioned all your UI and multi-threading experience, and I told you more than once that many of your points are not applicable when it comes to PUI and the way it is integrated/used in FlightGear.

You are mixing up too many concepts here - there is a dedicated Canvas GUI system, and it is indeed up to the job outlined in your "context", i.e. it contains all the hooks to render a menubar and functional dialogs, without requiring major/any additions to the C++ code.

If you think I am wrong in saying that, feel free to point me to something that you consider missing - you already mentioned a handful of important features, and I explained that the corresponding C++ code has been available via the CanvasGUI SGSubsystem for several years now.

So please stop providing a "context" and instead start stating a few facts - sorry, I don't care about assertions or sentiments if you cannot back them up, and I also don't care about prior UI experience as long as it's relevant in this particular context - namely, FlightGear/SimGear (its SGSubsystemMgr-based main loop, PUI specifically, the Canvas subsystem, and the Canvas GUI subsystem implementing GUI placements, including event handling, z-indexing, stacking, window ordering etc).

Seriously, no offense, but please don't start your phrase with "obviously", if it's not even obvious to the people who worked out the code in question - this is hugely misleading what you are doing here. Unlike the existing Qt5 integration code, the Canvas system is indeed able to render a dialog/menubar in the sim window, it can be used to render splash screens and other things. The Canvas system really doesn't care what it renders - it just works in terms of "placements", and you can specifically tell a placement to support keyboard/mouse events or to ignore those.

Equally, the whole notion of pluralism referring to the Qt5 effort being an orchestrated among several core developers is very misleading, there is a single core developer who's been doing 99.99% of the work here, someone who happens to have a 10+ year track record of contributing to FlightGear, and presumably a similar track record of working with Qt technologies specifically - yet, we're seeing tons of bug reports related to the Qt5 launcher/UI, and even segfaults reportedly related to that particular code.

Thus, why on earth should people jump onto this optional bandwaggon, given it has taken several years now for a seasoned 10+ year C++ veteran coder intimately familiar with much of the FlightGear/SimGear codebase and the Qt APIs, to come up with an UI that is not even coming close to the functionality provided by PUI, whereas a simple parser can accomplish the same thing with much less, time, energy, expertise and other resources required ?

Likewise, I don't understand why you specifically mention the "XML menu system" - this is either poorly researched, poorly phrased or simply another inaccurate (incorrect) assessment: When it comes to the UI system in FlightGear, the menu system is not problematic at all - in fact, had you looked up its implementation, you would have noticed that James himself re-implemented a Mac OSX back-end using the exact same menu, this has zero to do with QML.

Equally, having (or not supporting) QML is unrelated to the menubar system - the original PUI/XML system is dead-simple and could be wrapped by a tiny parser module easily, no matter if that is implemented for Qt5 or Phi - the problematic stuff is tons of Nasal stuff added all over the place in the form of code blobs, as well as other constructs to work around issues in the widget/layouting system, usually in the form of SGConditions and other property tree workarounds.

This kind of stuff is tedious to re-implement/support - unless you happen to use the exact same platform that contains these subsystems.

Realistically, the Canvas UI cannot compete with the Qt5/Phi efforts at all - but to understand why that is, you need to stop talking here and look up the facts to see that many of your statements are plain wrong.

There's no "goal of combining QUI + CUI" - there's merely the idea to reuse Qt5 for the Canvas UI option - what there is however, is an actual plan to use the Canvas UI route to facilitate phasing out PUI/XML in favor of Phi/Qt5 - to do that, the first step is simplifying the XML dialog files to become entirely declarative, like both, Torsten and James have confirmed more than once - once they're are purely declarative, they can be parsed and/or converted/tranformed by arbitrary tools, and for arbitrary purposes - for that to happen, the first step is havinig a parser that parses PUI/XML, which supports all its features, so that they can be mapped to other constructs (think Phi, Qt5, "CUI") - this will entail removing Nasal blobs, and introducing new tags for custom widgets currently unsupported by PUI, but emulated via Nasal, conditions and existing elements (think tabs implemented via buttons hiding PUI groups via SGConditions).

Either way, you keep reading too much into these postings - there's no holistic goal for the "Canvas GUI" to be solely XML - it's just well understood that the existing PUI/XML system must continue to work unless there is a sound system in place to semi-automatically transform/translate or re-interpret the existing resources to make the transition easier - like I said, James himself has stated this more than once, for a variety of good reasons, and it absolutely makes sense.

Anyway, I could go on and on and spoon-feed you everything that's been said about this, and you still wouldn't believe me - so, I'd rather spend my time differently. However, I'd politely suggest that you look up what's been written, and said, about this - if in doubt, by people who you respect, and who are involved in these efforts - such as James and Torsten; for your convenience, you will find many of these points nicely presented at: http://wiki.flightgear.org/Howto:Proces ... Discussion


Specifically, you will see statements like these:
http://sourceforge.net/p/flightgear/mai ... /29583931/
James wrote:Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility.
[...]
of course it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is.
[...]
so long as you keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.
[...]


Presumably, you'll now tell me that those are outdated comments and that the "FlightGear developer's standpoint has meanwhile evolved" - but frankly, just look at the technical arguments made by people like Torsten and James, and then make up your own mind if their original comments were really so wrong, or if they're just about to make concessions in the light of the difficulties that have shown over the course of the last 3+ years, given the progress in the UI department, as well as the stability issues caused by the addition of Qt5 code to the FlightGear code base, that is intended to be optional, but that -like you keep saying- is built-in by default into all distributed binaries.


It is all fine and dandy to mention QML, and had you done a little homework, you might have noticed that we specifically talked about this in the context of the Canvas GUI, and James himself explicitly discouraged us from going down that route - so please, just stop wasting our time, do a little research first, and you may find that you are preaching to the choir, and while you think that you are doing a service to James and his work, I can pull out enough quotes to prove that you are completely wrong with your assertion here, but I'd politely suggest that you consider doing that yourself - anyway:

QML and other GUI markup languages
zakalawe wrote:Just so you guys are aware, there is no real GUI editor for QML / QQ2 at this time. There is something that /looks/ like one, but in practice all the real work is done by editing QML as text. The GUI editor exists so when people ask about one, we can point to it. (Qt Designer generates .ui XML files, which are different again - they could be used to specify dialog boxes, but since we can already reload dialogs dynamically, not much benefit). Editing QML is a nicer syntax than our XML PropertyLists, and more compact, but that's about the only difference: QML is 'just' a JSON object tree really.

My suggestion would be to make interactive editing work - since with the tools Tom is building, that should be doable. I.e select an element, bring up a 'canvas inspector', tweak properties. Re-arranging the tree would need a tree widget, which I would not relish creating, but for adjusting the animations on a dial or similar, I think it would be good.

Also keep in mind, aside from 'custom' UIs like was mentioned in another thread (which look cool!), we don't want most people creating widgets using the canvas (cockpit displays, sure) - we want to keep compatibility with the existing dialog XML files. The dialog XML syntax is pretty straightforward and clean, much easier for most people to edit and understand the canvas and raw event handling.



Thus, please stop preaching to the choir - if you want to defend/protect James' recent work, please look up the history of what's been said, and more importantly done, in this context - and you'll see for yourself, that you are actually contradicting what James and Torsten said, so you are currently doing a disservice to all the UI efforts by misrepresenting the situation as it stand, either accidently or deliberately - I am just hoping that it is the former, because the latter would be very unfortunate in the light of the events, and as I have now shown in a very compelling fashion, you are not debating with me at all - you are questioning what some of our most seasoned core developers have previously stated in the context of the UI discussion.

And obviously, not having done an investigation of the options, and history, of your own, is not helping your case at all. Sorry, but you are really preaching to the choir here ... and like Thorsten said already it won't affect efforts to pursue the Canvas UI option, unless you actually make a strong technical point, which you have failed to do so far, because you keep making abstract and highly generic points that are generally true in most discussions, but which are out of context given the situation in FlightGear, and the comments made by a number of long-term contributors.
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 » Thu Jun 16, 2016 7:09 pm

And this will involve the removal of most of the XML for the menu system (hence why Torsten was talking about QML).


I guess that's news to James then...

That is roughly correct, but I always imagined I’d write some code to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface.

Even if there'll be a new dialog config format it doesn't mean we need to remove the old xml definitions - removing PUI doesn't imply removing the xmls.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby bugman » Thu Jun 16, 2016 7:30 pm

@Hooray, then I challenge you to strip out PUI from the compilation and provide a full CUI interface that provides 100% of the functionality of the current PUI! I say it's a mammoth task, so I'm hoping you can prove me wrong ;)

@Thorsten - one of the ideas of using Qt5 is to provide dialogs that the current primitive PUI system cannot even come close to providing. I could be wrong, but I don't see any interest in expanding the XML definitions. Anyway, I think the current launcher design and the reuse of certain elements in the Qt aircraft center is a clear demonstration of the complete lack of XML behind this technology, as well as a clear demonstration that there is no interest in using XML for new GUI elements. The total absence of Canvas UI developers interacting with the core developers on the mailing list, or even dropping into the weekly Google hangout for a chat, is creating a huge canyon between the two efforts, and making the sharing of basic technologies impossible.

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 » Thu Jun 16, 2016 7:55 pm

@bugman: Is that supposed to be a concession that you could actually have been wrong, because you cannot be bothered to actually substantiate all yoru claims here ? I still have not the slightest notion what you are even trying to imply with the "CUI" acronym, because you keep making weird references ...

Anyway, there's really no point in challenging me like that, I asked you to back up your claims, instead of just sharing what you think without also looking at the facts - I stated quite clearly that the Canvas GUI effort was never about replicating 100% of the functionality of PUI; you are turning this into a flamewar that you want to win, and the way you are challenging me/us, you will inevitably be correct - because there's simply no good reason to provide 100% parity/compatibility with the PUI/XML feature set.

I specifically used a wording along the lines of "approximate most PUI functionality [...] sufficiently well" to mean just that:

a Nasal/Canvas module that interprets a subset of PUI/XML markup and maps that to existing Canvas layout directives and Canvas widgets. This is not to say, or mean, that I am going to prioritize my time to implement support for the existing PUI/XML styling, or other features that would unnecessarily complicate matters - but that would just as well apply to Phi/Qt5, just like both, Torsten and James have stated repeatedly.

Thus, I stated specifically that creating a sufficiently-complete parser is much less work than re-implementing even just a single complex dialog from scratch, no matter the "back-end" (it could be Phi, Qt5 or even "CUI") - if Phi/Qt5 were using this approach, they would be much closer to updating the PUI/XML format to get rid of all those problematic patterns - as things are standing now, what you are referrinig to as "CUI" is your best option to accomplish that, because so far, it's the only sane option to deal with the plethora of legacy resources without causing additonal workload for each dialog that is encountered, so that a single module could deal with all existing resources, while providing a migration path to get rid of problematic PUI/XML constructs and make those dialogs entirely declarative, so that all "code" can be removed/re-implemented on top of generic building blocks (think tags for widgets and layouts, but also dedicated fgcommands for certain uses, like Torsten suggested repeatedly when he mentioned how Phi should ideally work)

https://sourceforge.net/p/flightgear/ma ... /34534324/
Torsten wrote:What I was talking about was to have most of the logic extracted out of the
UI implementation. How many properties do we have to write to to switch
from AW to BW? Nothing a UI should know about. A service
"GetAvailableWxEngines" and "SelectWxEngine" should do the job.



@Thorsten: Personally, I don't necessarily disagree that removing/updating/extending/re-implementing the existing XML dialog system (to adopt an established industry standard) may be useful at some point, just like I don't disagree that qt5 support would be cool to have (for a number of reasons).

However, there are a number of interim/intermediate steps needed for that to happen, unless the corresponding solution is all-encompassing in the sense that it doesn't introduce major regressions - which will usually entail having a parser; which can be either used for procedurally building the UI using a different back-end, and/or for translating the existing UI resources to a new/better system once and using that from then on - but even in that case, we still need to make sure that resources outside fgdata/fgaddon work properly, i.e. there must be some kind of sane, and portable, migration path - and aircraft specific GUI dialogs are really just the tip of the iceberg here.

Quite frankly, and without meaning to offend anybody here, that is the reason why the parser-based approach is the only viable path forward unless someone (ideally, a team of contributors) offers their time, dedication, expertise to come up with a neww UI system that can replace PUI/XML, while taking into account all the current use-cases - which inevitably means having a way to deal with established workarounds that we have accumulated over the last 13+ years.

We really need to keep in mind that PUI/XML uses of embedded Nasal, the property tree , SGConditions etc and other tight coupling may be unfortunate these days, but these workarounds have also been the foundation for major features implemented over the course of many years, including major enhancements -implemented by other core developers, such as the tutorial system, joystick configuration UI, aircraft checklists etc

These are major additions to FlightGear, and not using the parser-based approach -without also offering your time to re-implement these features using whatever other UI system will be used, means breaking most of the work that major contributors like Stuart have come up with in the last 5+ years.

And that is not even taking into account procedurally generated/dialogs going through the PUI/XML related fgcommand APIs.

pui2canvas can support all of these, and more, without requiring major C++ work, and without requiring tons of expertise.

The pui2canvas approach is certainly not the only option - Phi/Qt5 could just as well be using the same method (parsing/translation), and they'd solve all these issues once and for all; but if we follow bugman's suggestion, we're skipping a bunch of interim steps, so that there's no longer iterative development taking place.
And let's face it, people have been hugely underestimating the work that lies ahead when it comes to updating the UI - no matter if that means looking at Phi or Qt5 - these are nowhere near to being actual replacements for PUI, i.e. there's no sane migration path that doesn't entail a major rewrite, and/or major regressions - and almost certainly even both.

Like I said previously, Phi is the most polished, and most promising, option we have today - thus, rendering an OSG webkit/html view (html viewer) to a Canvas may be the easiest option to get Phi to work inside the FlightGear OSG window - and once/if Phi used the parsing approach, it could also be brought up to par with PUI fairly easily - and arguably, much faster than any Qt efforts, without added costs - just look at the progress Torsten has been making compared to the progress James has been making in pretty much the same time frame.

However, absent this (rendering Phi via osg/webkit), even the Qt5 effort may hugely benefit from piggybacking its widget rendering onto a Canvas::Element, which would solve a bunch of problems James has been facing for the last couple of months, without introducing threading related segfaults. There really is too little coordination taking place here unfortunately - the Canvas system had to solve most/all of these problems at some point to work the way it works.

Saying that "CUI" competes with Phi/Qt5 is ridiculous - and akin to suggesting that Nasal-based PID controllers compete with Torsten's autopilot/PID subsystem, or that Nasal-based FDMs compete with YASim/JSBSim.
At the end of the day, Nasal being used for these purposes is really just a symptom of a deeper issue, but has nothing to do with Nasal competing with established subsystems - especially not those that are not even exposed to aircraft developers to the same degree that Nasal scripting is (have you ever tried to instantiate a C++ PID controller component from Nasal, or a YASim/JSBSim instance, or an AI-guided aircraft). There's a reason that Nasal is used for these purposes by many folks,, its accessibly and the fact that there is no better solution available short of patching and rebuilding SG/FG ...

Equally, I James stating that he feels discouraged by Canvas UI efforts would be like Torsten stating that some kind of Nasal system would discourage him from maintaining his autopilot subsystem - it ain't gonna happen, for good reasons.

The whole notion of "competition" (competing for developer resources) here is kinda lame - could I write Qt5/C++ or JavaScript/HTML code instead of Nasal ? Certainly. But I won't get involved in Qt5 as long as the majority of core developers have decided that Qt5 must remain entirely optional, and while Phi is cool, I usually prefer having an in-window UI, so I am not particularly interested in getting involved there currently - however, I actually recently dabbled with it, and found it flexible enough to render an orbital map via Phi/mongoose, and it actually seemed to work.
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 jaxsin » Thu Jun 16, 2016 11:01 pm

the question has been posed, I think it is a fair question. What is stopping anyone from finishing the CUI? No competition, PUI is done, so move forward already.
I'm all for discussion, but has it really got us anywhere besides circular arguments and unsubstantiated statements thus far?
jaxsin
 
Posts: 395
Joined: Mon Dec 28, 2015 4:54 pm

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests