Board index FlightGear Development Canvas

Canvas G1000

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: Canvas G1000

Postby Hooray » Mon Jan 15, 2018 7:55 pm

While I still think that separating the display and treating it as a raster image is a good idea, the scaling feature should be possible to implement regardless of that. Keep in mind that everything you see is just a conventional Canvas element - i.e. even groups are sub-classed from Canvas::Element - thus, all APIs there are also available, including the scaling stuff. I think that this may even be preferable for vector graphics, because vector graphics can be scaled without causing pixelation.

If in doubt, refer to $FG_ROOT/Nasal/canvas/api.nas to see what else can be done at the superclass level: https://sourceforge.net/p/flightgear/fg ... as/api.nas

Note that you can directly access the transformation matrix, but also use dedicated helpers for scaling purposes:

Code: Select all
# Shortcut for setting scale
  setScale: func { me._getTf().setScale(arg); return me; },
  # Shortcut for getting scale
  getScale: func me._getTf().getScale(),


My suggestion would be to look at your original zooming/panning work in the airports.xml dialog - I cannot think of any good reason why people should not be able to customize the size of the display by using the mouse wheel incrementing/decrementing scale by 0.1%, what do you think ?

Regarding tooltips, like I said, you could take a look at rleibner's recently developed oscilloscope/gca addons - both are using tooltips IIRC.

The tooltip API is in $FG_ROOT/Nasal/canvas/tooltip.nas: https://sourceforge.net/p/flightgear/fg ... ooltip.nas

This is one of those features that got actually documented (originally by James): http://wiki.flightgear.org/Tooltips

More examples can be found by "grep"ing for "tooltip".

From an integration standpoint, you will want to register a "mouseover" listener for the hotspots: http://wiki.flightgear.org/Canvas_Event ... vent_types

The tooltip string could be added to the vector with hashes, i.e. for each hot-spot one "tooltip" key.

That being said, you might not just want to display a tooltip - but also change the mouse cursor. That, too, can be accomplished via Nasal, see $FG_ROOT/Nasal/gui.nas (line 60):

Code: Select all
##
# Set mouse cursor coordinates and shape (number or name), and return
# current shape (number).
#
# Example:  var cursor = gui.setCursor();
#           gui.setCursor(nil, nil, "wait");
#
var setCursor = func(x = nil, y = nil, cursor = nil) {
    var args = props.Node.new();
    if (x != nil) args.getNode("x", 1).setIntValue(x);
    if (y != nil) args.getNode("y", 1).setIntValue(y);
    if (cursor != nil) {
        if (num(cursor) == nil)
            cursor = cursor_types[cursor];
        if (cursor == nil)
            die("cursor must be one of: " ~ string.join(", ", keys(cursor_types)));
        setprop("/sim/mouse/hide-cursor", cursor);
        args.getNode("cursor", 1).setIntValue(cursor);
    }
    fgcommand("set-cursor", args);
    return args.getValue("cursor");
}



Besides, using the same APIs, it should also be possible to animate buttons/dials to respond to events -e.g. by zooming in or when the dial is selected.

Anyway, hope that helps for now.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Tue Jan 16, 2018 8:48 am

Hi Hooray,

Re: Scaling. Yes, I can scale elements quite easily, but there are a couple offsets for the maps, which differ in location depending on the page which would be a bit of a pain to re-calculate. I've got the raster image code checked in, so it's all good :).

Re: tooptips/mouse cursor. I'm slightly concerned about the perf impact of this. As it stands, I'd need to add the mousover event to entire dialog (because the buttons aren't separate Canvas objects) and then check it against the list of tooltips. I should do some profiling.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: tooltips/cursor:

Postby Hooray » Tue Jan 16, 2018 7:03 pm

I see - yes, that's probably a valid concern.
I don't know if there is any "best practices" here to deal with this.
What I think should work fairly well is the following workaround:

  • use the existing vector of hotspots coordinates
  • but instead of setting up event listeners directly, set up new Canvas.elements (e.g. raster images)
  • simply assign an invisible/transparent image using the coordinates/size of the corresponding hotspot
  • and then set up the event handler for the whole Canvas.Element (Canvas.Image)

That way, you should end up with button-specific elements that have their own dedicated event listeners - i.e. all the runtime checks should be handled by C++ code then (IIRC).

Another thing that would probably work pretty well is using the underlying SVG to look up the corresponding coordinates dynamically.

But given the size of the SVG file, I think it would actually be a good idea to review what else would be useful to support via svg.nas - for example:
  • <image> tag
  • nested SVG files (basically, calling parsesvg recursively)
  • gradients
  • <script> tag (for starters, we could use language="nasal" - which would be trivial to support)
  • DOM events

The first 2-3 would seem particularly useful, because SVGs could become much more modular that way.
The last 2 ones (scripting & DOM events support) would make it possible to use existing standard tooling (think inkscape) to create fairly complex SVGs using native tools - e.g. so that non-coders could come up with a PFD.

Looking at svg.nas it would even be possible to support dynamic updates of elements by adding the Canvas.element (Canvas.Path) to a closure that can be referenced in the script block - which would end up being the equivalent of a "reparse()" function.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Wed Jan 17, 2018 12:56 pm

Hi Hooray,

Good idea to use an overlay. I think one could even just have a separate SVG file for the hotspots, which would be easy to create. I may look into that later.

RE: SVG enhancements: I do want to add the <image> tag soon as I want to leverage that. I'm sceptical that adding scripting support to Inkscape would make writing PFDs easier. Certainly my experience so far with the MFD is that there's a lot of state, and using a proper MVC approach is needed to stay sane. Personally, I think providing infrastructure and templates so that people can just drop in their business logic is going to be easier to understand. I'm going to leave them for the moment I think.

Unfortunately I've also started seeing some crashes that I think are caused by Canvas Elements being deleted twice. So I may have to spend some time debugging.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Michat » Wed Jan 17, 2018 5:28 pm

Stuart, FYI I've updated the design with some missing elements, some amended by you and some other missing.

Two things:

It seems that manipulating the svg you have move by mistake some elements that now appear unaligned. These are RANGE Push Pan Button tags, now displaced to the right. If you need to move some element I recommend you bravely to select such element by clicking on it, then move it with shift + cursor arrow in that way you are sure that the element will be placed exactly in the same position when you move it back to the original position. Always avoid to move any element with mouse.


Can you tell me the exact size you are using for the Garmin screen area. It seems your current box is exceeding slightly the right margin over the screen border. I'll try to get you enough accomodation space for that and I'll send you the new file as soon as I get a solution.

Thanks
User avatar
Michat
 
Posts: 962
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby Hooray » Wed Jan 17, 2018 7:47 pm

stuart wrote in Wed Jan 17, 2018 12:56 pm:Good idea to use an overlay. I think one could even just have a separate SVG file for the hotspots, which would be easy to create. I may look into that later.


Actually, that is one of the reasons why I suggested looking into supporting the <image> tag (for which I added a corresponding patch to the wiki): That way, it would be easy to take Michat's latest work and export a highres version to a PNG file - and create a lightweight SVG wrapper that is using that to set up a corresponding overlay using conventional SVG elements.
That way, you can even use the IDs to set up everything in an automated fashion - as matter of fact, if you were to use Emesary IDs as IDs for the SVG elements, even the notifications could be mapped automatically, without having to add any dedicated "scripting" support.

My thinking here is that supporting external raster/vector images in svg.nas would make many things easier - while also adding to the structure/modularity of the SVG files.
For instance, we could have a "UI.svg" file that loads "skin.png" and sets up the matching hotspots.

Besides, in conjunction with support for some basic DOM events, the same file may even work for Phi.

Regarding the crashes you are seeing, my suggestion would be to check if they're in any way affected by not doing any of your resource cleanup - I've seen that a few times, i.e. deleting stuff that was already being deleted implicitly.

Anyway, for now, I believe that extending svg.nas to add support for the <image> tag, and maybe for external SVG files would come in handy for people wanting to add to this effort.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby Hooray » Fri Jan 19, 2018 8:00 pm

Michat wrote in Wed Jan 17, 2018 5:28 pm:Can you tell me the exact size you are using for the Garmin screen area. It seems your current box is exceeding slightly the right margin over the screen border. I'll try to get you enough accomodation space for that and I'll send you the new file as soon as I get a solution.


Right now, it's 1024 x 768 (texture size) and the embedded screen is width : 1407, height : 918

For details, see: https://sourceforge.net/p/flightgear/fg ... al/gui.nas

As a matter of fact, Stuart said a while ago, that he was still evaluating which parts of the FG1000 should be instrument specific and which ones should be "promoted" to become a native part of the underlying MFD framework - and I actually think that the "skinning" approach that is currently used (set of images in conjunction with hotpots for event handling purposes and a screen area for the actual display) would be enormously useful to have, especially in conjunction with Emesary hooks.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby Thorsten » Sat Jan 20, 2018 9:18 am

For instance, we could have a "UI.svg" file that loads "skin.png" and sets up the matching hotspots.


:mrgreen:

I was contemplating the same idea for a canvas implementation of various equipment dialogs.
Thorsten
 
Posts: 11086
Joined: Mon Nov 02, 2009 8:33 am

Re: Canvas G1000

Postby Hooray » Sat Jan 20, 2018 10:36 am

It's actually rather simple and straightforward to modify svg.nas to add support for the <image> tag, which is then mapped to the corresponding Canvas.Element (Canvas.Image in this case). I once came up with the corresponding patch and documented the steps here: http://wiki.flightgear.org/Howto:Extend ... age.3E_tag

This will load an svg file that references splash screen textures:

Code: Select all
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <image x="20" y="20" width="80" height="80" xlink:href="Textures/Splash1.png" />
  <image x="120" y="20" width="80" height="80" xlink:href="Textures/Splash2.png" />
  <image x="220" y="20" width="80" height="80" xlink:href="Textures/Splash3.png" />
  <image x="20" y="120" width="80" height="80" xlink:href="Textures/Splash4.png" />
  <image x="120" y="120" width="80" height="80" xlink:href="Textures/Splash5.png" />
</svg>



Image

Note that these are conventional Canvas elements once they're processed by svg.nas, so you can do all sorty of fancy things (event handling, tooltips, animations etc)

This would be a straightforward mechanism to come up with theming/skinning support for arbitrary purposes using standard SVG files, i.e. nothing specific to fgfs/Nasal or Canvas at all.

Besides, if the event handling is done via conventional SVG/DOM events, there is really no technical reason why the same "equipment dialog/svg" would not also work for Phi (or even Qt5) - at the mere cost of doing the event propagation via DOM events that end up calling fgcommands, without Phi/Qt5 having to know anything about Canvas or Emesary/Nasal.

And like I said previously, it would be also straightforward to modify svg.nas to support loading external SVG files - that way, it would become possible to structure SVG files much better, i.e. by using separate SVG/raster images, instead of having a single monolithic one only. This may also mean that existing SVG-based UI toolkits (provided they're GPL compatible) could be used to help populate the Canvas GUI widget ecosystem - for instance, TheTom was originally using artwork from ubuntu to prototype the current widget set. With a few more SVG features supported by svg.nas, it would be possible to take existing SVG widgets and use those directly inside fgfs.

Finally, if/when better (more native/more standard) SVG support becomes available, there will be nothing fgfs specifiic in our implementation/use of the system.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby Michat » Mon Jan 29, 2018 2:47 am

There some progress in the FGarmin design, lets call it progress, as I struggle creating several elements making reverse engineering of the PFD. Pretty sucked by several factors:

1. Garmin Original Scales and it's reverse engineering from ytube to my pixel workspace.

2. Became crazy thinking that everything is wrong (dials) and I should start again with mm units.

3.Thinking about horizon and translucent elements that we'll cannot solve at graphic level, cause the trick is made by code G1000.

4. Getting better idea of what sucker is G1000 for the GA :oops: .

5. Due to it's themed style PFD nature. I'll should reproduce those different styles. For your information I'll add one more style called FG, of course. Will contain a serious "buggy bug" from the russian aviation know-how. No special programming needed.

6. If you are the guy that say "to the left" but you are thinking "to the right" this is your PFD equipment, coriolis aptus. :mrgreen:

7. Fonts is gonna be a problem :x

8. There are several version of the G1000, luckily I got the good one when I designed the Gui1000.

9. Many things can be improved just but not using the garmin documentation, this usually vary and the quality of the pdf design left into the schematic and anecdotic world. Not happy to see other sims have better design than us for this g1000. Cause I used the official docs. But not the real thing. :x

So this is the base structure, waiting to be border tunned.
But I'm not happy.



Image

29.92
User avatar
Michat
 
Posts: 962
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby Hooray » Mon Jan 29, 2018 11:29 am

that's looking really good - but I assume that all that Stuart is needs is just a standalone SVG file with just the PFD - because the outer part (surround/skin) has already been converted to a raster image anyway. Actually, all modes are basically "pages" that have their own associated SVG/XML files: https://sourceforge.net/p/flightgear/fg ... 00/Models/
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Mon Jan 29, 2018 1:27 pm

Hi Michat,

Thanks very much for working on this.

As Hooray says, what I really need is a well-structure SVG file with just the PFD contents and no surround. If you're able to add all the warning messages, I can show/hide them very easily, provided they have sensible element names.

I expect to implement the inset map, Direct To elements etc. implemented as overlay pages with their own SVG files, so don't worry about them.

If you have a look at the xkv1000, that may give you some "inspiration" and ideas of what techniques to use.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Mon Jan 29, 2018 2:13 pm

Here's the link to the corresponding file/repository: https://sebmarque.hd.free.fr/git/seb/zk ... ls/PFD.svg
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby Michat » Mon Jan 29, 2018 3:36 pm

Don't worry PFD and outer part are different elements. It is just that I put it together to get better idea of the proportions and relation between them.

The svg that you point to me is gonna be a good reference, it will help me out. However the design does not provide a dedicated font style for numbers. The font is generic, so does not have the point macula in the center of the zeros among other differences. I can recreate a dot macula to every zero of the scale it does help.

Stuart I'll will put warning messages.Thank you I was on doubt for that.


29.92
User avatar
Michat
 
Posts: 962
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby Hooray » Mon Jan 29, 2018 3:48 pm

I believe that non-static text can be omitted anyway, as it's going surely going to to use Canvas.Text ...
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest