Board index FlightGear Development Canvas

New Canvas GUI

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

New Canvas GUI

Postby wlbragg » Wed Jan 07, 2015 10:22 pm

I'll start with I'm not sure this is correct place or system to use, but is anyone working on or plan to update the GUI any time soon.
IE:
1) dock-able
2) size-able
3) other wish lists?

Just asking as it is in the back of my mind as a project I might be able to handle with a little coaching here and there.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4622
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: New Canvas GUI

Postby Thorsten » Thu Jan 08, 2015 7:09 am

According to the mailing list, Clement was working on this. Not sure it'll make it into the next release.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: New Canvas GUI

Postby wlbragg » Thu Jan 08, 2015 7:33 am

Oh, good. Looking forward to seeing it, thank you.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4622
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: New Canvas GUI

Postby Torsten » Thu Jan 08, 2015 9:40 am

There is currently heavy activity towards a new UI. There will be the HTML5 based version, I am currently working on and an internal implementation based on well supported libraries. Most likely, both will use a common service layer to provide necessary data.
Neither of those will use Nasal or Canvas to render the UI elements.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 632
Joined: Fri Feb 01, 2008 9:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: New Canvas GUI

Postby Hooray » Thu Jan 08, 2015 12:46 pm

Thorsten wrote:
wlbragg wrote in Wed Jan 07, 2015 10:22 pm:I'll start with I'm not sure this is correct place or system to use, but is anyone working on or plan to update the GUI any time soon.
IE:
1) dock-able
2) size-able
3) other wish lists?
According to the mailing list, Clement was working on this. Not sure it'll make it into the next release.

Actually, Clement was working on an integrated GUI by combining a bunch of existing dialogs (mainly AircraftCenter) and porting a few more PUI dialogs - the features listed above are unrelated to that.
The main motivation behind coming up with the "Aircraft Center" was getting rid of roughly ~15 different platform/OS specific GUI lauchers/front-ends: http://wiki.flightgear.org/Aircraft_Cen ... _Situation


For a summary, see: http://wiki.flightgear.org/Aircraft_Cen ... _.28WIP.29
Image


Like Torsten said, there's other GUI related work ongoing that is entirely orthogonal to anything involving Nasal/Canvas - in fact, it will be a completely external GUI that has all the advantages (and disadvantages) of not running in the same process space as FlightGear. Therefore, this will be mainly of interest to people who can live with having an external window open and controlling FlightGear from an external application (which indeed is how professional FTDs/full-motion sims work).

The state of Torsten's work can be seen here: Instructor Station

One of the main motivations for adopting Canvas was to help getting rid of PUI (our legacy GUI), while coming up with a GUI that would be compatible with other important use-cases (think MFDs showing GUI dialogs and vice versa). The latter is an increasingly important use-case in real life avionics (on jets/airliners) - as can be seen by ARINC661. Such use-cases aren't easily supported by a distributed approach involving for example a browser, HTML5 and ECMAScript/JavaScript
In addition, the idea is to keep modernizing and unifying the 2D rendering back-end in FlightGear by getting rid of legacy GL code to hopefully use modern OSG code in more and more places: http://wiki.flightgear.org/Unifying_the ... via_canvas

Recently, there's been a 3rd heavily overlapping effort, by adding an integrated Qt5 based launcher: https://gitorious.org/fg/flightgear/com ... 149b6d01e8

Basically all of these 3 approaches could have easily made the other 2 two obsolete if more coordination had taken place behind the scenes ...

For the time being, Torsten's work is most complete from a functionality standpoint - but is obviously not as "integrated" with fgfs itself when it comes to accessing internal data structures, and he's favoring using dedicated C++ changes to expose new stuff.
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: New Canvas GUI

Postby wlbragg » Thu Jan 08, 2015 9:51 pm

Good info, thanks.

Specifically what I was "dreaming" about was caused by a scenario I was flying. I was attempting AAR and had AP, Map and Fuel System all open in sim. I was thinking that there is no reason, other than no one has created it yet, that we couldn't have sizable, dockable dialogs that could be so modular as to be able to grab whatever part of the dialog you wanted and drop it onto another, including "temporarily" being able to delete parts also. So in the end you could have a custom dialog with several parts of different dialogs combined. Or even a "Customize Dialog" to, customize your dialogs.
How nice would that be?
This is the specific concept I was referring to.
I didn't want to start down this path until I knew what is already being considered and around the corner.
I didn't see anything here to suggest this concept is being considered?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4622
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: New Canvas GUI

Postby Philosopher » Thu Jan 08, 2015 10:51 pm

why do you need a combined dialog when you have separate dialog? anyways. with canvas, things should be resizable at least... up to a point
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: New Canvas GUI

Postby wlbragg » Fri Jan 09, 2015 12:43 am

It would be nice to be able to take just a piece of a dialog and combine it with another. For example, the fuel dialog for some of these planes have a couple of sliders for fuel, one for each tank. Then there is other data to the right, that takes up a considerable amount of the screen. AP has what could be by design 3 modules. In this scenario, it would be really convenient to combine just the fuel sliders with the AP Magnetic Heading and the Map. All sized and arranged to fit in a small area. A necessity no, really convenient, yes So basically any combination of dialog and data could be combined and even made to be persistant. Even just the ability to size the dialog would be helpful.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4622
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: New Canvas GUI

Postby Hooray » Fri Jan 09, 2015 2:06 am

what you describe above is do-able right now as far I can tell - i.e. can be implemented without requiring any C++ changes.
"drag & drop" are supported mouse events. For creating a canvas, see the "Canvas Snippets" link above. For adding widgets, refer to $FG_ROOT/Nasal/canvas/gui
Next, you'd want to register drag&drop listeners for moving widgets between different canvases - you could even allocate a new canvas on demand.
So there really isn't anything significant missing.
I'll probably post a more detailed responses later/tomorrow - but basically a fully interactive -and dynamic- GUI should be possible without too much work.
Then again, the question is if you want to be integrated or not - for anything "integrated", you'll undoubtedly want to use Nasal/Canvas - otherwise, I''d suggest to look at Torsten's work.
Personally, I think that some kind of "drag & drop widget system" could be implemented pretty quickly, probably even in under 100 lines of code (i.e. a prototype/proof-of-concept).
I don't quite see any need for your particular use-case, but I am also interested in a dynamic and flexible Canvas GUI, so I could probably help by posting a few pointers, explanations and snippets to get you going faster.
For instance, what you describe above could be conceptually considered a "dialog composer" where entities are dynamically mapped to the proper widgets (think fuel -> sliders, think position -> map, think frequencies -> text widgets and so on).
Internally, this could be implemented as a simple hash that contains items, mapping and validation routines for different types of data.
That would also make it possible to allow people to combine arbitrary elements/items to create new features/dialogs in an interactive fashion (persistence really being a no-brainer)
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: New Canvas GUI

Postby wlbragg » Fri Jan 09, 2015 2:45 am

what you describe above is do-able right now as far I can tell

Well, that's what I fjgured.
I would do it "integrated".
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4622
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: New Canvas GUI

Postby Hooray » Fri Jan 09, 2015 8:53 am

I think the only thing that might not be supported is dynamically resizing a Canvas without re-allocating the whole thing - I think we did have a discussion about this a while back, i.e. so that Canvas internals (dimensions, resolution, internal format etc) could be also changed at run-time. I don't think anybody ever got around to implement that though (haven't checked yet).

You'll probably want to take a look at $FG_ROOT/Nasal/canvas/gui

and especially these sub-folders there:

/dialogs
/widgets

We're in the process of documenting things - and Necolatis started working on new widgets.

So all the building blocks are there already - it's mainly a matter of adding new widgets and dialogs.
Widgets should ideally be prioritized according to existing PUI widgets (see $FG_ROOT/Docs/README.gui), so that we can sooner or later replace the old GUI.

However, I would suggest not to start coding anything "big" (as in a global/integrated GUI dialog containing a lot of stuff) yet - in fact, I even consider F-JJTH's attempts a bit "premature, given the FG/GUI situation outlined above.

It makes sense to make some experiments first, and document your findings - e.g. by dabbling with different widgets, adapting a few dialogs and helping to extend the wiki accordingly.

For instance, by adding stuff here: http://wiki.flightgear.org/Canvas_Snippets

This will help grow a repository of useful snippets, so that we can start adding new widgets and dialogs over time.

All the features you mentioned are straightforward to support using Nasal/Canvas, even in its current state - and shouldn't even require C++ level modifications.

But as can be seen in my other response, the main challenge we're facing currently is a lack of coordination/collaboration among people interested basically in the same thing (=a better FG GUI).

For an integrated solution, Nasal/Canvas are obviously going to be the right approach.

If I were to play with this, I would use the "Canvas Snippets" article and use the "Canvas dialog" snippet there, and adapt it to add a few simple EXISTING widgets (think label/button).
Next, you would want to register listeners/event handlers for supporting/handling drag&drop events: http://wiki.flightgear.org/Canvas_-_Event_Handling
For layout management, see: http://wiki.flightgear.org/Canvas_Layout_System

At that point you would end up with a Canvas dialog whose buttons could be freely dragged around, possibly using dynamic layouts.

I would then probably add a sidebar with a handful of buttons for each supported widget (e.g. label, button, checkbox for starters) and turn this into a simple GUI editor where widgets could be added/moved around and maybe resized by clicking the corresponding widget button to add a new widget to the dialog.

I would guess that a simple prototype doing this is between 100-120 lines of OOP Nasal code - and you would end up with a simple way for creating/editing dialogs (e.g. by serializing everything to a JSON-like hash representation).

The main snippets to get you going are these:
http://wiki.flightgear.org/Canvas_Snipp ... GUI_Window
http://wiki.flightgear.org/Canvas_Snipp ... Layouts.29

These could be adapted according to what I described above, i.e. so that a handful of buttons can be used to dynamically add new widgets to a dialog.

Once you have completed this, you should have all the basic building blocks in place to dynamically change dialogs "on the fly" - even if that may require re-allocating a Canvas to change its size for now.
Even though another workaround might be allocating a larger Canvas and only showing a certain area of it, so that the allocated Canvas would be large enough for things to be edited.

So I don't think that those potentially missing features are really showstoppers. I think this could be prototyped in a few evenings of spare time coding

I am currently not able to run FG, but I wouldn't mind posting a few more pointers every once in a while - but given how these efforts usually turn out (i.e. real life taking over), I would appreciate if you could tackle this by using the wiki and using/adding useful code snippets there - e.g. also by creating a little tutorial to document your whole effort at some point (i.e. creating a dynamically-editable GUI dialog)

A simple built-in GUI editor would seem useful overall, and it would provide a good learning experience for people wanting to create such flexible GUI dialogs - e.g. by allowing elements to be dragged onto a window (think properties, widgets, maps, or a ND/PFD).

The other thing worth keeping in mind is that localization is currently not a first-class concept supported by Canvas, so needs to be explicitly taken into account.

Depending on your motivation to work on this for a few days, you could probably come up with something useful pretty soon - at which point it would make sense to get others involved, especially Necolatis should be interested in this - as he's doing all of this currently manually, and is also increasingly familiar with the Canvas GUI, creating widgets etc.

PS: dialog resizing is supported through some kind of "resizeable" property
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 10:21 am

Update (10/2015):

Apparently, things have changed a little with regard to the AircraftCenter, the original Google hangout consensus being this:

http://sourceforge.net/p/flightgear/mai ... /34196458/
Durk Talsma wrote:There's been a strong devision of opinion among a couple of core developers with respect to the question whether a QT dependency is desirable or not. In one of the hangouts, a couple of months ago, we had the chance to discuss the pros and cons, when the most outspoken developers regarding this issue were both present. We concluded that a QT dependency was undesirable, unless it had a specific benefit. With this in mind, I proposed to consider the option of allowing a QT dependency in only one module (call it FGGui). For all practical purposes, this would be a platform independent replacement of fgrun, but because of the proposed modularity, it will appear to be seamlessly integrated with FlightGear. Both developers representing the opposite ends of the debate could live with this compromise.


The most recent announcement related to the AircraftCenter/Integrated Qt5 launcher being this:

http://sourceforge.net/p/flightgear/mai ... /34520595/
James Turner wrote:The in-sim GUI should probably be considered an experiment which won’t be developed further - while it was being created, the core developers agreed that use of Qt to provide ‘out of window’ GUI was reasonable. At some point (possibly quite soon) I’ll enable a version of the Qt launcher to be triggered from the in-sim menu (but as a separate dialog), at least an an experimental feature.


In other words, it seems that the AircraftCenter is going to be replaced with a Qt5-based equivalent "soon-ish", which also means that all people building from source, will inevitably need to make sure that they have all the Qt5 dependencies.

Interestingly, the posting first declares the AircraftCenter "an experiment" that "won't be developed further" in order to provide a Qt5-based "out of window" GUI, which also will be "an experimental feature" :?
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: New Canvas GUI

Postby hamzaalloush » Wed Oct 07, 2015 10:51 am

I think he could discuss the reason why a Canvas based download center is excluded, maybe you could try the mailing list to bring it up for discussion? frankly, i like the new QT5 gui/launcher and catalog download, but i'm using Linux(QT is easy to get), also in a static build a QT dependency wouldn't matter/present issues.

I'm just trying to start a discussion...
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 11:00 am

actually, it does make sense not to come up with our own GUI framework from scratch.
And introducting even more custom "solutions" (like Nasal) is a bad idea.

Frankly, we would be in a much better shape now, had Qt (or Lua/Python) been accepted years ago - righ now, the situation is just challenging due to all the existing features we have.

The main issue here is the significant build time dependency, as well as the lack of integration with the rest of the sim.

Especially with regard to features found on modern avionics (think ARINC661, which need to render their own GUI elements).
Equally, we have tons of useful functionality in Nasal/Canvas space that isn't currently reused on the Qt5 launcher - e.g. look at the airport layer, and its replacement in the Qt5 launcher.

All of this is easily circumvented in Nasal/Canvas space obviously, because we can trivially reuse stuff arbitrarily - e.g. we can show a MFD with buttons, and we can even render a moving map on each button, incliding even tooltips - because recursion is fully supported.

You would be hard pressed to implement a moving map system using Qt5 controls (widgets), because we would need to find a way to reuse Qt5 widges in Canvas and vice versa.

If Qt5 is indeed going to be used, it will be even more important to stop using Nasal/Canvas "as is" and expose the CanvasElement/PropertyBasedElement helpers to Nasal via CppBind, to ensure that useful functionality can be exposed/registered in a use-case independent fashion, so that other front-ends (think the Qt5 UI) can reuse such functionality, without having to go through Nasal space explicitly - i.e. the only IPC mechanism should then be the property tree, so that we can register useful stuff as dedicated specialized-elements, which can be directly instantiated using the property tree, with very thin Nasal bindings/wrappers.

We are already seeing useful Canvas-based features being re-implemented in C++/Qt5 space because James didn't see a good way to reuse those:

Image

So it would definitely make sense to revisit the idea of allowing new Canvas elements (and possibly projections) to be registered via cppBind, and implemented in Nasal space.

To ensure that we can also provide backward compatibility (think versioned elements), but also so that people can more easily create elements that provide support for different use-cases, multiple instances, aircraft etc.

If TheTom should find some time to expose sc::Element and maybe PropertyBasedElement via cppbind, I would help create examples on the wiki for documenting this as a best practices to implement new Canvas based features, without requiring people to call Nasal APIs directly.

The main advantage being that we can also much more easily encapsulate, optimize and version useful features. Because right now we are frankly aproaching a chaotic situation with regard to tons of useful Canvas features that are rarely, if ever, reusable due to the way people are using Canvas...
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 11:03 am

In other words, it seems that the AircraftCenter is going to be replaced with a Qt5-based equivalent "soon-ish", which also means that all people building from source, will inevitably need to make sure that they have all the Qt5 dependencies.


Sorry, I can't read that into the message. Why can't the in-sim triggered Qt launcher /not/ be optional like the rest of the launcher? It's not like the aircraft center would somehow be crucial functionality necessary to use the sim.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests