Board index FlightGear Development Canvas

Aircraft-specific dialogs

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: Aircraft-specific dialogs

Postby Hooray » Tue Feb 06, 2018 5:20 pm

Agreed with Thorsten - anything that can be treated as a Canvas element (text, image, vector graphics) can also have associated event handlers/rectangular hotspots - so it's trivial to do.

I am not sure what Alant was hinting at, but the existing Canvas widget set is unrelated to this, but actually perfectly functional, too - it is what was originally used by the Canvas based aircraft center, but also other built-in Canvas dialogs:

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

Image

You can also assign an arbitrary raster image as the background image for Canvas widgets.
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-specific dialogs

Postby Thorsten » Thu Feb 15, 2018 7:08 pm

After some bughunts, I'm now resuming work on this - I've added the automatic limit function which shows values outside the normal range in red.

Also, I've placed the (growing) widget library on FGData, so that it can be io.include()d from aircraft Nasal files where needed.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Thorsten » Sun Mar 11, 2018 11:52 am

Re-vamped orbiter temperature distribution dialog with a generic widget to display a bunch of systems information (here only used for the temperature, but the widget actually can display a whole table underneath the title and adjusts size automatically).

Image
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Sun Mar 11, 2018 11:55 am

this is looking really good - but it's all going through Nasal, right - i.e. it's not declarative in the sense that it'd be using SVG or XML to instantiate anything procedurally ?
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-specific dialogs

Postby Thorsten » Sun Mar 11, 2018 4:15 pm

You could use xml to instance the elements if you had a parser.

As I've said a few times, I decided upon an SVG-free workflow for this, so you can't use SVG elements - it's raster images and code. If you have an SVG workflow anyway, you don't really need widgets.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Sun Mar 11, 2018 4:24 pm

okay, fair enough - have you considered sticking with the props.Node structure (hashes) - I am asking because, as you know, at that point, you would automatically have a serialization scheme via the property tree - i.e. fgfs can natively turn XML into properties and properties into XML.

The background being that a number of folks have expressed concerns due to extensive Nasal use for these things - and given my own UI related experiments involving PUI vs. Canvas, I think that people like James and Torsten do have a very point. From a simulation standpoint, it is definitely desirable to have a declarative way to specify the UI. No matter if that means XML, JSON or props.Node (Nasal hashes)

As things are standing now, any declarative UI dialog can be trivially updated/parsed or converted/translated - that does not apply to UI dialogs using primarily "code".

Anyway, no matter how you're proceeding from here, I'd definitely suggest to version the underlying API so that you can make breaking changes in the future - which is another long-standing shortcoming in our UI - i.e. there is no way to safely change/add features, unless people are willing to break compatibility with existing UI resources.
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-specific dialogs

Postby Thorsten » Sun Mar 11, 2018 5:34 pm

Think of this rather like functions which a very fancy (virtual) MFD might display or provide - your very own virtual touchscreen in the cockpit. The whole idea resembles that much more than a PUI dialog.

Even if you had an xml parser, it'd have to call the same code driving it, because the flexibility and power comes from it being 'code' rather than 'data' - though with the access barrier rather low.

(And it's going to be as future-proof as any in-cockpit canvas displays because it uses the same technology).

I'll typically start versioning the moment I write documentation so that people can adopt it - right now this is version 0.1 and will stay that way for a while and nobody is supposed to adopt this without volunteering to test for me.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Thorsten » Fri Mar 23, 2018 8:47 am

Depressable raster image buttons

Image

(the main challenge is to create the artwork, but if you have the texture sheet for the cockpit anyway and know some gimp-fu, this is dead easy to implement...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Fri Mar 23, 2018 12:13 pm

That looks really good - one question, does "depressable" mean that you are also animating the underlying texture to show clicks ?
I mean just how interactive is the whole thing from a feedback standpoint, i.e. I know you have code to support tooltips and cursor changes, are you also changing the button (scale/color/background) to make it obvious that the button is getting clicked, i.e. is there any visual feedback ?

Apart from that, I am not sure if I mentioned this already or not - but this is freakingly similar to the way the existing 2D panel system works. I don't know if you have done a 2D panel because they are considered a legacy thing, or if you are familiar with the approach - but it's a really straightforward mechanism that sets up an arbitrary number of textures that can respond to events (mouse clicks), so that arbitrary fgcommands are triggered that can then be used to animate the textures by rotating/transforming/scaling the sheet of textures as desired.

The point of this being that it may be interesting to look at README.xmlpanel and README.minipanel - it's a rather simple mechanism that is pretty useful, and that could help you make up your mind on how to proceed from here. For instance, xml panels use texture maps to extract sub-textures into separately addressable textures, which is also something that the Canvas system can do.

I am mentioning this, because you highlighted how your mechanism greatly benefits from existing aircraft textures, and I believe that this could be very promising to pursue further, i.e. determining how much is overlapping here.

Besides, such dialogs could even be trivially rendered by _any_ front-end, including even Phi.

The only major suggestion I can make at this point is to encapsulate all event handlers by registering custom fgcommands using the addcommand API.
This is something that Stuart's fg1000 is also doing, and the key benefit here is that this makes it possible to share all the back-end logic (same file, same function) without having to duplicate stuff at all:

addcommand() API

Note that there is no technical restrictions here - because any piece of Nasal code can be registered to be a fgcommand, but once it's an fgcommand, it is well encapsulated and can be called/invoked by any front-end, no matter if that's a 3D cockpit, Canvas dialog, PUI dialog, Phi dialog or external mechanism/front-end (think FGQCanvas, telnet or whatever else people come up with)

I made a posting in the fg1000 topic summarizing the key advantages, and Stuart ended up agreeing with them and also extended the concept even further to adopt Richard's Emesary framework there - at that point, the sky is the limit, because the front-end stuff has to know nothing about Nasal/Emesary at all, because it's all just fgcommands that are invoked: fgcommands & Canvas FG1000
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-specific dialogs

Postby Thorsten » Fri Mar 23, 2018 12:20 pm

That looks really good - one question, does "depressable" mean that you are also animating the underlying texture to show clicks ?


Yep - and it even looks nice...

The main widget is an indexed stack of raster images where mouse events change indexing and visibility - a depressable button is just one side application, the same thing can do switches, talkbacks, quality level sliders,... all you need is the artwork.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Fri Mar 23, 2018 12:26 pm

Yes, and it is touching on a previous suggestion I made when I suggested to port the dps keypad to become a procedurally defined Canvas dialog:

http://wiki.flightgear.org/Howto:Creati ... FD_Dialogs
Image

Note that in the corresponding Nasal code, the setup of event handlers (buttons) is taking merely a vector of hashes that contains all the button specific information.
This is also what rleibner used for his UI - i.e. it's a nice way to still use code, but have a highly declarative way to encode event handling semantics in a generic fashion.

You can see the same method being used in the code shown here: http://wiki.flightgear.org/Howto:Reset/ ... sal_dialog
Image

(Just ignore the fact that these examples are using conventional Canvas widgets, I am only trying to make the point that you can encapsulate button specific event handling details using a vector of hashes. In other words, such code could be easily ported to use your new widgets, by changing just a single line of code)
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-specific dialogs

Postby Thorsten » Fri Mar 23, 2018 7:10 pm

I'm actually not after coding a button here - it merely comes out of a widget that can be used to code a button made of raster imagery. When you use the widget, you just tell it what the specific function to be executed is in one line, no need to make a fuss. The code for the new keypad isn't any longer than the code for the old PUI keypad, just the artwork is different.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Fri Mar 23, 2018 8:42 pm

My response wasn't about coding a "button" at all, it was about encapsulating the widget interface by using a vector of hashes (regardless of the actual widget), and using the fgcommand layer to make sure that the widget code does not introduce custom Nasal blobs unnecessarily.

That way, you can even share the back-end logic between your various front-ends (think 3D cockpit, Canvas dialogs or Phi/FGQCanvas stuff)

Anyway, I am admittely beginning to realize that this may seem premature to you, and that you are primarily interested in tinkering and exploring/innovating new stuff right now, so that such suggestions are probably not very welcome, or rather that it is apparently hard to see any merits (for now at least)
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-specific dialogs

Postby Thorsten » Sat Mar 24, 2018 7:46 am

That way, you can even share the back-end logic between your various front-ends (think 3D cockpit, Canvas dialogs or Phi/FGQCanvas stuff)


Sorry, you lost me on the way - how do you think this works now? There's a function assigned to each key by the Shuttle avionics code, and all the dialogs (old style PUI, new style canvas, in-cockpit keypads,... just call that function. It's a one-liner to attach that function to the widget, so I fail to see how much more compact the design could get.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft-specific dialogs

Postby Hooray » Sat Mar 24, 2018 9:40 am

we will see if/when you share a link to the corresponding code, maybe you are already using this - I don't know ... if in doubt, looks at Stuart's or rleibner's code that's setting up event handlers for the "skin", and you'll see what I was hinting at
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

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 6 guests