Board index FlightGear Development Canvas

Changelog & Progress

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.

Changelog & Progress

Postby TheTom » Mon Jul 16, 2012 6:24 pm

Behind the scenes has happened a lot the last weeks. Here just a few teasers to gain some interest and maybe also some feedback :)

With the basic canvas system which is included in the code for 2.8 and the Nasal API which can be found in my fgdata branch it is eg. possible to load SVG files and modify them dynamically to simulate eg. an EICAS display (see Howto:Use SVG inside a Canvas for details):
Image

With the latest canvas code (which is only available in my fg branch) it is also possible to use the Canvas inside gui dialogs. It is even possible to just drop in geographic coordinates (lat, lon) and let the canvas automatically transform them to canvas coordinates, which makes drawing eg. a map really easy (have a look at the implementation):
Image

If you want you can draw any shape you want (or load it from a SVG file):
Image
Last edited by TheTom on Mon Jul 16, 2012 8:38 pm, edited 1 time in total.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby sa7k » Mon Jul 16, 2012 8:21 pm

That's looking really good! thanks for your work.
sa7k
 
Posts: 380
Joined: Fri Mar 16, 2012 3:24 pm
Location: SA7K
Callsign: LV-EPM
IRC name: sa7k
Version: git
OS: debian

Re: Changelog & Progress

Postby TheTom » Wed Jul 18, 2012 7:18 pm

Currently I'm working on an API for easy animation of different types elements. Here is a short demonstration of my test EICAS while increasing the engine power and one engine failing, which triggers different fault and warning messages:
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby El Flauta » Thu Jul 19, 2012 6:32 am

TheTom wrote in Mon Jul 16, 2012 6:24 pm:If you want you can draw any shape you want (or load it from a SVG file):
Image

This feature looks great to improve better help or checklist dialogs.... developers may create help windows with a scheme of the cockpit, with labels for easy search of buttons or instruments :) ¿it will be able to be placed on every dialog?
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
--
PZL M18B Dromader
CASA C-101 Aviojet
Cessna 337G Skymaster
User avatar
El Flauta
 
Posts: 426
Joined: Fri Mar 14, 2008 1:09 am
Location: SCVM, Chile
Callsign: CC-FLT
Version: 3
OS: Windows 7 SP1

Re: Changelog & Progress

Postby TheTom » Thu Jul 19, 2012 9:49 am

Yes. It can be placed just like any other gui widget. One could also build some nice and interactive load and balance dialogs (eg. like https://picasaweb.google.com/nicolas.xp ... 6940565266).
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby Hooray » Thu Jul 19, 2012 6:56 pm

and the really nice thing is that you can use an image editor like GIMP or InkScape to create your image and then directly use it in a dialog with some glue XML/Nasal code, so you don't need to be a coding expert to create nice dialogs or interactive checklists!
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: Changelog & Progress

Postby Johan G » Fri Jul 20, 2012 10:44 pm

TheTom wrote in Mon Jul 16, 2012 6:24 pm:With the basic canvas system which is included in the code for 2.8 and the Nasal API which can be found in my fgdata branch it is eg. possible to load SVG files and modify them dynamically to simulate eg. an EICAS display (see Howto:Use SVG inside a Canvas for details)

Yummy! I just can't wait to see what kind of ideas people will bring out and try. :shock: 8)

I guess we from now on will need a set of free and open source fonts in the base package... :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6625
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Changelog & Progress

Postby Hooray » Tue Jul 24, 2012 5:19 pm

In case anybody isn't reading the mailing list, Tom just posted another example to demonstrate how powerful his new canvas system really is - this time showing how the canvas system and some Nasal code can be used to create entirely custom widgets, which aren't currently supported by our existing GUI system - but which can be quickly scripted, even by specifying widgets via SVG:



Check out the Nasal code here: https://gitorious.org/~tomprogs/fg/toms ... s-demo.xml

http://www.mail-archive.com/flightgear- ... 37867.html
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: Changelog & Progress

Postby islandmonkey » Tue Jul 24, 2012 5:26 pm

Slightly unrelated but is it me, or did I hear that we are changing to OSG from plib for the GUI soon?
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: Changelog & Progress

Postby TheTom » Tue Jul 24, 2012 5:35 pm

Not really unrelated. It is currently beeing discussed what should happen with the GUI. One proposal is to use osgWidget and create/extend all missing widgets and the other one is to absorb the the UI part of plib into FlightGear/simgear and port all GUI related things to using the Canvas system (using Nasal). The second approach would allow for a easy creation of new or modification of existing widgets without modifying any files inside the core, which I would favor :)
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby Hooray » Tue Jul 24, 2012 5:42 pm

islandmonkey wrote in Tue Jul 24, 2012 5:26 pm:Slightly unrelated but is it me, or did I hear that we are changing to OSG from plib for the GUI soon?


Like Tom says: not at all unrelated, that's in fact what the discussion on the mailing list is all about: There's a new contributor who offered reimplenting the current PLIB/PUI GUI by porting it to osgWidget (a GUI library for OSG). However, osgWidget isn't very actively developed currently - and it doesn't even offer any benefits from a functionality/widget point of view at the moment, i.e. moving to osgWidget would be a regression initially, because all of the existing PUI widgets would need to be reimplemented in C++ for osgWidget.
The new contributor is offering to handle that, but there are countless issues related to that approach.

The point of the canvas widget demo is to demonstrate how powerful and flexible the new canvas system really is, i.e. it cannot just be used for aircraft scripting (instruments, MFDs), but also for GUI scripting - which means that using the canvas system would unify the 2D rendering backend (all can be handled via canvas), while reducing the amount of C++ code we have doing these things, which would mean that the GUI system could be entirely maintained in scripting space, i.e. as part of the base package, by people who don't need to know C++ - some basic Nasal knowledge will do.

Basically, adopting the new canvas system for such and similar purposes, will mean that tons of old/oudated C++ code can be phased out and replaced by a single consistent implementation in C++, that is using modern C++/OSG code - which ultimately also means that OSG itself can make more assumptions about what's being rendered, so that more optimizations (= better frame rates) can be more easily accomplished by using OSG coding patterns and protocols, instead of outdated/custom/3rd party libraries which would need to be manually baked into the existing FG/SG/OSG eco system.

Now what's cool about the canvas system is that it's integrated in such a fashion that it will keep working with the old GUI code still in place.In addition, all of the exsting GUI features (layouting, XML processing) are implicitly supported due to the way the canvas system is implemented. These are real roadblocks when implementing a new GUI library next to PUI, because all of the existing stuff would need to be explicitly ported (either in C++ space or by converting tons of XML files).

Overall, the canvas system will give us all of this "for free", and it will mean less C++ code in the source tree, too - i.e. better maintainability.
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: Changelog & Progress

Postby omega95 » Sun Jul 29, 2012 11:59 am

Hey, is it merged into fgdata yet? I don't have canvas props in my fgdata. I was really looking forward to using this for the ATR 72-500(C)'s FMC... :mrgreen:

Btw, for the ATR 72-500(C)'s FMC, I'll need to use only text, but they need to be in different colors. I could easily do this using a little nasal+XML but then I'd like to know if there's an advantage in using canvas props over nasal+XML, like would it save fps or something? (just for this instrument, I see a lot of advantages in using it for the MFD)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changelog & Progress

Postby Hooray » Sun Jul 29, 2012 12:09 pm

Yes, the core canvas system has been merged several weeks ago already, i.e. it will be also available in the upcoming release (2.8).
See the wiki for details: http://wiki.flightgear.org/Canvas_Prope ... _07.2F2012

As you can see, while the canvas system has been merged, the Nasal API wrapper has not yet been merged.

But you can easily get it from Tom's branch here: https://gitorious.org/~tomprogs/fg/toms ... sal/canvas
See the api.nas file, the svg.nas file provides even more powerful wrappers that allow you to load your geometry directly from SVG files and animate them with Nasal.

For examples on how to use the system, take a look at Tom's c172p-canvas demo here: https://gitorious.org/~tomprogs/fg/toms ... raft/c172p
As you can see in the -set.xml file, there's an example instrument provided which uses the canvas system: https://gitorious.org/~tomprogs/fg/toms ... anvas-test

Also, the canvas-demo GUI dialog contains additional examples: https://gitorious.org/~tomprogs/fg/toms ... xml#line60

Keep in mind that the canvas system is currently work in progress, it is getting more and more flexible and powerful every week - so some things may change. If you want to see what's going on, track Tom's branch. But if you want to make sure that your work also works in the upcoming release, it's a good idea to base everything on what's merged already.

Also, the GUI wrapper for GUI dialogs hasn't yet been merged, so it won't be available in 2.8 unfortunately, but it is currently getting revamped, so it will be even more powerful once it is merged, i.e. in FG 3.0

Overall, for pure text displays, you'll probably need less XML animations and things should perform better frame rate-wise, also there will be more flexibility, and you'll become familiar with a new development system, too ;-)
Basically, you can do this entirely in Nasal space, and easily address individual "screen" regions directly, without complicated XML workarounds.
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: Changelog & Progress

Postby TheTom » Sun Jul 29, 2012 4:32 pm

As Hooray already said fgdata is not merged yet, but you have just to copy Nasal/canvas and Nasal/std from my branch: https://gitorious.org/~tomprogs/fg/toms ... sal/canvas

I have now also copied the code for my C-130J AMU to theWiki. It would be cool if we could extend it to also support being used for a FMC...
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby Hooray » Sun Jul 29, 2012 6:53 pm

I forgot to mention that there's also a README.canvas file in Tom's branch: https://gitorious.org/fg/flightgear/blo ... DME.canvas

While it is pretty outdated meanwhile (many new features), the comments on text elements are still valid.

Regarding the canvas "api.nas" module, it is currently not in $FG_ROOT, but you could add it to your aircraft and then load it via aircraft-set,xml into a "canvas" namespace, that way you can use the canvas namespace, and once the api module is committed to fgroot, you could simply remove this entry from the -set.xml file, and everything will keep working.


There's an even better option: you can make this automatic and truly portable by checking first if the "canvas" namespace exists in your Nasal code, and if it exists, you can return - if it doesn't you can load your own copy of the api.nas module.

You will just need to check the globals hash, using something like this

Code: Select all
# loader.nas

# sub folder of your aircraft-dir where you store the
# copy of all canvas modules (api.nas, svg.nas and string.nas)
var canvas_subfolder = '/Nasal/canvas/';
# list of modules to be loaded, and destination namespace to be used
var modules = [ ['api.nas','canvas'], ['svg.nas','canvas'], ['string.nas','std'] ];
 
# various helpers to check if the canvas namespace is used already
var has_symbol = func(symbol) contains(globals, symbol);
var is_hash = func(h) typeof(h)=='hash';
var has_module = func(m) has_symbol(m) and is_hash( globals[m] );
var has_canvas = func has_module('canvas');
var has_file = func(file) io.stat(file)!=nil;
var success = func(path) print(" SUCCESS:", path);
 
# helper to load all the modules into the right namespace, as defined in the nested modules vector
var load_canvas = func {
  var errors=0; var err = func errors+=1;
  foreach(var m; modules) {
   var path=getprop('/sim/aircraft-dir/') ~canvas_subfolder~m[0];   
   has_file(path) and io.load_nasal( path, m[1] ) and success(path) or err() and print("  File not found:", path) and continue;
  } return errors;
}

# check if the canvas namespace is used or not
if ( !has_canvas() ) {
  # load the modules
  print("No Canvas module found in global namespace!");
  print("Trying to load own canvas/api.nas from sub folder under $FG_AIRCRAFT:"~canvas_subfolder) and
  !load_canvas() and
  print("Okay: Canvas modules successfully loaded!") or
  print("ERROR: While trying to load own canvas/api module from $FG_AIRCRAFT:", canvas_subfolder);
}
else
  print("Okay: Canvas module already loaded, not loading own copy!");



You would then load "loader.nas" via your aircraft-set.xml (namespace not important) and it would check if the canvas module is already loaded or not, and load it on demand.
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

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests