Board index FlightGear Development Canvas

Are radio buttons available?  Topic is solved

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: Are radio buttons available?

Postby Hooray » Sat Nov 09, 2019 8:03 pm

This topic should have been moved to a different forum obviously, given that it's about PUI and not Canvas.

Anyway, for the sake of completeness, there is an existing "checkbox" widget for the Canvas system - Tom implemented a dedicated canvas/widget API when he created the "Aircraft Center" Canvas dialog:

http://wiki.flightgear.org/Aircraft_Center
Image

This includes support for buttons (a checkbox really being just a toggle button after all, just like a radio button):

http://wiki.flightgear.org/Canvas_Snipp ... Layouts.29
Image

Using the existing "canvas checkbox widget" it is trivial to take an existing PUI/XML dialog, and load/parse that to map those <checkbox> tags to their corresponding Nasal/Canvas equivalent:

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

Note that this indeed done procedurally, i.e. at runtime - the original PUI/XML dialog wasn't touched to create the Canvas equivalent.

The parser can be also incrementally fixed up to support more complex dialogs, by adding hooks for the widgets currently missing.
For example, the screenshot shown below renders a fully-functional equivalent of map-canvas.xml which contains embedded Nasal/Canvas blobs, and which are correctly handled:

Image

Both, Josh and Thorsten made a number of valid observations/points - however, the point being, dialogs shouldn't need to be "coded" at all. A number of core developers have previously discussed this on the devel list - thus, dialogs should really be entirely declarative, with functionality living inside "widgets", which is also a necessity to end up with a reusable widget system, and one that can be maintained.

Like Thorsten said, anybody who's ever done any Nasal/Canvas coding would be in an excellent position to create widgets like those that he created.

However, I am pretty sure that manually porting our UI dialogs is going to be rather tedious process - i.e. look at some of the more complex dialogs that contain tons of Nasal functionality, these are already problematic in the sense that they are de-facto not purely declarative - in other words, while it may take an experienced contributor 10-20 hours to manually port a PUI/XML dialog to a different UI stack, a single aircraft developer who's ever done any moderate Nasal/Canvas coding, would be able to implement a few widgets in Canvas space, so that all dialogs using those widgets would automatically work "as is".

There's a list of PUI widgets and a matrix comparing that to what Canvas comes with: http://wiki.flightgear.org/Canvas_Widget_Matrix

You can also look at existing widgets: http://wiki.flightgear.org/Howto:Creati ... GUI_Widget

The shuttle stuff is cool, as is the E500 UI stuff, however to be truly useful, such work would have to be agnostic to the aircraft/use-case at hand, i.e. we would have to grow an actual library of widgets, ideally using README.gui as reference, i.e. to bring "our widget toolkit" up to par with the basic functionality that PUI has to offer.

While this may seem like a moot point given the Qt5/QQ effort, anything using the Canvas system would obviously also work for non-Qt builds, as well as for people wanting to use widgets for their avionics/MFDs
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: Are radio buttons available?

Postby Thorsten » Sat Nov 09, 2019 8:52 pm

The shuttle stuff is cool, as is the E500 UI stuff, however to be truly useful, such work would have to be agnostic to the aircraft/use-case at hand, i.e. we would have to grow an actual library of widgets


Which we actually do if you care to look into the codebase...
Thorsten
 
Posts: 11204
Joined: Mon Nov 02, 2009 8:33 am

Re: Are radio buttons available?

Postby Hooray » Sun Nov 10, 2019 11:14 am

I haven't looked at any FG stuff in months - so, you would be in a much better position to judge if it would make sense for people to use your widget framework to create new widgets from scratch.
I guess, if it's sufficiently flexible, people want to take a look at it. If in doubt, I'd suggest to post a few pointers here - so that folks working on their own widget-functionality can take a look.
Personally, I kinda like the MVC approach that TheTom took when he implemented his widgets - and the thing to keep in mind is, even if people don't like those existing Canvas widgets, they're really 100% style-able, and they look "Ubuntu-ish" because that is where he took the GPL-compatible artwork from.
The same back-end code could also be used to create custom aircraft widgets.

The thing I do have to agree with though is that having a widget library (or a framework to create widgets) is one thing, but we really don't want to have people that "code" UI dialogs, as Josh was alluding to, and like James and others said.
When it comes to PUI/XML, and implementing/porting that, it really is the sheer amount of Nasal code, i.e. non-widgets/non-layouts that is complicating matters.
We gotta keep in mind that while both, Nasal and Canvas are indeed perfectly suitable to implement a UI inside FlightGear, we will want to use a declarative appproach, instead of having more and more Nasal/Canvas dependencies interspersed all over the place - which is why the original idea was to implement a parser to translate PUI/XML to Canvas, and then version all our existing UI files, so that changes to the XML format can be safely made, by introducing new layouting/widget directives to get rid of Nasal blobs in our dialogs, and instead move those into the parser.

At that point, the back-end implementing the scripting/UI portion would be well encapsulated, so that even Python and Qt/QQ could be used some day (when/if that work is sufficiently mature).

Then again,I can relate to aircraft devs wanting to shield themselves from such tedious work by simply opting to go the Nasal/Canvas route, so that the UI question remains irrelevant as long as the fgfs binary comes with Nasal and Canvas included ;-)
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest