Board index FlightGear Development Canvas

Getting involved in Canvas GUI development

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.

Getting involved in Canvas GUI development

Postby punkepanda » Thu Mar 20, 2014 12:41 am

TheTom wrote in Wed Mar 19, 2014 11:57 pm:While working on the new GUI based on Canvas I have not noticed any problems so far, so it should not suffer from the clipping problems.


Thats really good news.. Better solutions works ;)

Any place to test it? from git?
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby TheTom » Thu Mar 20, 2014 1:49 am

punkepanda wrote in Thu Mar 20, 2014 12:41 am:Any place to test it? from git?

Use latest git, start with --prop:/sim/gui/canvas/demo=1 and click on the aircraft/help icon in the top right corner.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby punkepanda » Thu Mar 20, 2014 3:31 am

TheTom wrote in Thu Mar 20, 2014 1:49 am:
punkepanda wrote in Thu Mar 20, 2014 12:41 am:Any place to test it? from git?

Use latest git, start with --prop:/sim/gui/canvas/demo=1 and click on the aircraft/help icon in the top right corner.



Works perfect ;)
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby punkepanda » Thu Mar 20, 2014 3:38 am

punkepanda wrote in Wed Mar 19, 2014 11:30 pm:Runway light now works from a distance with ATI, but it gradualy dissapair as you fly closer. But just in ALS mode....Strange!! In regular mode its no runway lights at all.

So that must mean that there is hope.. It look that it is hope because the light came on after the runway light updates not long ago.

But why? And why the light not showign itself at close distance.. Anyway i guess that qualify for that it is possible to fix in the code.
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Thu Mar 20, 2014 4:08 am

punkepanda wrote in Thu Mar 20, 2014 3:31 am:Works perfect ;)


which goes to show that recent C++ code using OSG (Canvas) does not seem to trigger the same bug - which kinda makes sense, because Canvas is basically 100% native OSG code (well, except for ShivaVG) - but in general, OSG knows exactly what's going on there, because Canvas stuff is mostly using OSG code and OSG data structures - which is a completely different thing once it comes to our old GUI (PLIB/PUI), because there, some workarounds had to be made to reuse the old code without having to rewrite it from scratch - so it could be a combination of ATI/AMD specific driver issues/settings, but also because of our way of running such legacy code. And the same thing could apply to other pre-OSG features that were not properly/fully ported, but merely "integrated" to make them "just work" for most people, so that they end up being more fragile and more prone to driver issues.
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

Postby punkepanda » Thu Mar 20, 2014 4:15 pm

Hooray wrote in Thu Mar 20, 2014 4:08 am:
punkepanda wrote in Thu Mar 20, 2014 3:31 am:Works perfect ;)


which goes to show that recent C++ code using OSG (Canvas) does not seem to trigger the same bug - which kinda makes sense, because Canvas is basically 100% native OSG code (well, except for ShivaVG) - but in general, OSG knows exactly what's going on there, because Canvas stuff is mostly using OSG code and OSG data structures - which is a completely different thing once it comes to our old GUI (PLIB/PUI), because there, some workarounds had to be made to reuse the old code without having to rewrite it from scratch - so it could be a combination of ATI/AMD specific driver issues/settings, but also because of our way of running such legacy code. And the same thing could apply to other pre-OSG features that were not properly/fully ported, but merely "integrated" to make them "just work" for most people, so that they end up being more fragile and more prone to driver issues.



I see the Hooray. So partly being old code and partly being driver issues with that code. And uffcourse a lack of manpower which makes sense.

Do you know if there is some work going on with the new Canvas menu system that we could expect in the near future? Or is there need for more manpower on that part.
I really think that is of big priority because then ATI users can atleast operate FG without having to switch to low graphic settings. Then it is just the light as i know of that missing. So this two things and ATI user will be happy. I guess that doubles the user base for FG. Since we cant expect user to buy expensive new hardware to enjoy free flying.
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Thu Mar 20, 2014 4:29 pm

punkepanda wrote in Thu Mar 20, 2014 4:15 pm:Do you know if there is some work going on with the new Canvas menu system that we could expect in the near future?

There's still some C++ changes that TheTom wanted to get finished - and only afterwards can we really look at porting our existing GUI widgets to Canvas.
So that will take a while, and personally I don't expect this to be completed within the 3.x release cycle, I think it will at least take 2 release cycles, probably more like 18 months.
But at the end of the day it obviously boils down to manpower - because anything that's Canvas based is also supported from Nasal space - in other words, anybody able to run FlightGear, can also help in porting GUI widgets (text box, edit field, buttons, radio button, checkbox etc) - that will typically involve 50-120 lines of Nasal code, but it will require programming experience and Nasal/OOP knowledge in particular - and obviously familiarity with Canvas.

If we now had 5-6 guys working on this each weekend for 2-3 months, it could obviously be finished in time for 3.2 :D

Or is there need for more manpower on that part.

We do appreciate any help that you or others can provide - no matter if it's feedback, testing or even coming up with new widgets. If you are interested in coding, you could look at the existing "button.nas" widget in $FG_ROOT/Nasal/canvas/gui/widgets and see if it makes sense to you. If it doesn't, you need to read up on Nasal, OO and maybe Canvas. It isn't necessarily difficult, especially not for people already familiar with other programming/scripting languages like JavaScript - and you'll be part of the solution instead of being "part of the problem" :D
Besides, if you want to help with this, you'll get full 1:1 support, i.e. in the form of dedicated wiki tutorials, aimed at people wanting to help with this. And we also have a few people here who can help with vector images (Michat & pommesschranke), which means that complicated widgets don't need to be manually drawn inevitably.

People interested in helping with coding the upcoming Nasal/Canvas-based GUI, will mainly need to be familiar with these concepts:
  • Nasal
  • object oriented programming
  • Canvas
  • Canvas Event Listeners
  • Canvas & vector images (SVGs)

galvedro and Necolatis also mentioned a while ago that they're interested in using Nasal/Canvas for their GUI, and Philosopher has recently done Canvas/GUI coding, too:
http://wiki.flightgear.org/Interactive_Nasal_Console
Image

And someone else recently mentioned in the issue tracker being interested in helping with an integrated GUI launcher: http://code.google.com/p/flightgear-bug ... id=1295#c2
So we have a handful of people, some of them very familiar with Nasal, so if you want to help, it would seem like a good time to team up now ...

There's still some C++ stuff missing, I don't think keyboard handling is very advanced currently - but the more people we have involved in the scripting side of things, the more time C++ developers like Tom can spend on coming up with C++ code instead of Nasal code - so your time is put to good use :D
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

Postby punkepanda » Thu Mar 20, 2014 5:55 pm

Thanks for support Horay,

I have some C/C++ OOP experience and PHP. Client side scripting has never been my field but I'ill take a closer look at Nasal and Canvas to see if I could contribute to something there.
The new Canvas REPL look promising tough ;)
Since the Canvas GUI framework is not fully developed yet it would be fun to see what could be made out of it as of today.
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Thu Mar 20, 2014 7:55 pm

There's a lot of things that could already be implemented purely from scripting space, without touching any C++ code, and without rebuilding FG.
Again, the more people we have interested in helping with the scripting side of things, the more time others can dedicate to C++ development.
Now, if you really WANT to look into C++ stuff, you'll obviously need to be able to build FG from source first of all, and be familiar with git and gitorious ideally.
But before anybody wants to help with Canvas/C++ things, I'd suggest to get in touch with TheTom to get some pointers.
While we do have a "Canvas Development" article in the wiki, that one doesn't currently cover any GUI specifics, i.e. styling/windows/event handling etc, and it would probably take me
1-2 weeks to update things accordingly.

With your sort of background, the Nasal/Canvas part of playing with custom widgets should be pretty straightforward, and it would actually be great if you could document the whole process - especially, because there are now a handful of people interested in related things (Philosopher, galvedro, Necolatis, kujife09) - so if we could team up and turn this into a new wiki tutorial, we could share and spread our knowledge, i.e. use some leverage.

Widget-wise, we'll at least need to re-implement the widgets currently supported by the old GUI, i.e. things like checkboxes and radio buttons, see $FG_ROOT/Docs/README.gui for examples.
Once those widgets are available, we really only need to write a parser that turns our existing XML dialogs into Canvas dialogs.

For now, the main thing would seem to be to get this started, i.e. writing about what's involved, and documenting the specifics - preferably using the wiki, so that everybody can easily track progress and contribute

PS: If you have a gitorious account, we can add you to the canvas-hackers team clone as a contributor, so that you can directly commit your experiments there
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

Postby punkepanda » Thu Mar 20, 2014 9:28 pm

Yes, turning the existing XML dialogs into Canvas was excactly what i wanted to experiment with. I've just finished playing a little with Nasal now for a couple of hours and I see that it pretty straight forward lightweight syntax. Thats a good thing.

I was looking for some good documentation on the Canvas part, but as you say its not yet that well documented in the wiki. So I guess the deeper learning has to be from digging into the Canvas development as new things get implemented.

BTW Hooray. In http://wiki.flightgear.org/Howto:Load_a ... at_runtime there is missing the use of
Code: Select all
~getprop("/sim/fg_root")
in the example so you might want to update that if you can. Since it was my first touch with Nasal and I got a "Cannot stat file: loadme.nas.txt:" error Just for the really fresh ones not getting confused like me :roll:

I did it like this if you wanna cut'n paste :)

Code: Select all
# test.nas (save in $FG_ROOT/Nasal)

# First we need to get the "$FG-ROOT" path and extend that with the file to load
var getpath = func {
 getprop("/sim/fg-root") ~ "/Nasal/loadme.nas.txt";
}

# Then we define the loader function
var loader = func(getpath) {
  io.load_nasal(getpath);
}

# And setting up the listener
_setlistener("/sim/signals/nasal-dir-initialized", loader);


# Finaly we execute the loader function
loader(getpath());



I'll see if I can create a gitorious account if I not already have it.
Last edited by Gijs on Thu Mar 20, 2014 9:34 pm, edited 1 time in total.
Reason: No useless quoting please. Use the "Reply" button instead.
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Flightgear doesn't use 100% of the workload and GUI clip

Postby Hooray » Fri Mar 21, 2014 5:58 am

thanks for the bug report, feel free to directly edit those tutorials - that's why they're kept in the wiki after all.
Regarding Canvas tutorials, we do have a few actually. Check out the Canvas navbar at: http://wiki.flightgear.org/Canvas
There's a tutorials section too.

Note that XML dialogs should not be manually turned into Canvas dialogs, instead we need to come up with missing widgets (checkbox, label, textfield, radio button etc).
Those can be drawn using Inkscape vector images, and animated/made-interactive using Nasal code. A checkbox or radio button would seem like a simple thing to play with.
Once we have working widgets, we only need to come up with a simple parser that can turn existing dialogs into canvas windows.
svg.nas is our existing example on populating a canvas procedurally by parsing an XML file.

Basically, it looks for supported SVG primitives, and turns those into Canvas/OpenVG primitives by setting properties.

I've been in touch with TheTom and Philosopher, and we'll probably update the wiki to provide a few more pointers on recent Canvas/GUI efforts, and missing things.

But again, please do not touch individual dialogs for now - what's needed is just widgets as per README.gui
For starters, there are simple dialogs like the exit/about dialogs - these can already be expressed using existing Canvas means.
What's primarily missing here is layout management, which is something that Tom has been working on.

A summary of past discussions can be found at:
http://wiki.flightgear.org/Canvas_GUI
http://wiki.flightgear.org/Canvas_Widgets


If properly done, the XML/GUI dialogs will never need to be touched/edited - they will merely be processed by a Nasal function.
And the underlying GUI related fgcommands (show-dialog, close-dialog etc) will simply be overwritten from Nasal space using the addCommand() API
Which will basically disable the underlying C++ code and allow all GUI dialogs to be processed via Nasal/Canvas, without them having to be edited at all.

Now, layout mangement obviously is already supported (see README.layout) and we need to make sure that our Canvas based layout engine supports everything available there, so that we can get rid of Andy's original C++ code here.

This isn't necessarily difficult work, and it can be mostly done without requiring C++ changes - but it will require quite a few new widgets obviously.
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: Getting involved in Canvas GUI development

Postby TheTom » Fri Mar 21, 2014 8:27 pm

Everyone interested in GUI development should get the latest FlightGear from git and it with --prop:/sim/gui/canvas/demo=1. You will notice an icon in the upper right hand corner of the window which upon a click opens a dialog. To play around with it have a look at the bottom of fgdata/Nasal/canvas/gui.nas. You will find more code in fgdata/Nasal/canvas/gui/*.

I am currently working on a layouting system similar to the one found in Qt. Layout items will have a minimum, maximum and preferred size with some additional flags. A layout item can be either a widget or a layout. Layouts can have further layout items as children. Depending on the size hints and flags layouts will recursively distribute space. In a later revision of the layout system I will probably also add support for width-for-height/height-for-width which will be useful for layouting larger text blocks. The basic layouting system should probably be ready within the next few weeks (I hope 1-2 weeks).

If you want to create new widgets keep the requirements of the layouting system in mind. Every widget at least needs to provide sensible values for min/max/preferred size. Also for a GUI using images seems to be a better solution than vector images. For example the button uses a 9-scale image for the border, which allows cheap smooth borders and gradients and also reuse of many images from existing themes. New widgets should all use images from the same and optimally just require to swap the base path of the images for a different theme.

If anyone wants to help with any part, something in the API/Canvas is missing or has any questions, just let me know :-)
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Getting involved in Canvas GUI development

Postby Philosopher » Fri Mar 21, 2014 10:37 pm

Tom, that demo looks great, especially with your new features (HTTP and scrolling). Definitely catches me :D. (Even despite looking like it needs some of that layout management ;).)

I think we'll be able to make widgets too - checkboxes and radios should be fun. You've been using the Ambiance Classic from GNOME look, right? Should we download the images from there to create our widgets? It's amazing how small they are...
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Getting involved in Canvas GUI development

Postby Philosopher » Sat Mar 22, 2014 12:19 am

Wow, using the scrollbar widget literally took 15 minutes, and most of that was finding where to reset the view (to the bottom). I did learn the hard way that you have to attach the widget to a window object, otherwise it fails when focusing, but in general it was very easy. One thing it needs is documentation, but I can work on that (if it doesn't interfere with you).

Thanks again!

https://gitorious.org/fg/philosophers-f ... 4b3aa22f09
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Getting involved in Canvas GUI development

Postby Hooray » Sat Mar 22, 2014 7:27 am

you guys should really post some screen shots, for those of us who haven't run FG in weeks... :oops:
(and a screen shot would also be a nice newsletter/changelog addition to document the ongoing canvas progress)
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 6 guests