Canvas ND on another aircraft than Boeing and Airbus

[Octal450]

OK, when I'm ready for it, I'll ask. Thanks.

[Hooray]

looking at the state of the "framework", learning inkscape may very well take longer than coming up with new a new ND feature or MapStructure layer - it's not exactly elegant code, but it's fairly generic and easily extensible meanwhile, so that the lack of Inkscape skills may be the main factor slowing people down when creating new ND styles

[clm76]

@Hooray

For prototyping purposes, i.e. developing new styles for other aircraft, my suggestion would really be to use a PUI/XML dialog and add the boilerplate code from ND.nas into it, so that you can develop the style without having to exit/restart FlightGear:

That needs some explanations to implement that. I don't see how to do !... have you an example ?

Currently, I use my own ND.nas without calling navdisplay(). I use the functions "addLayer()" from mapstructure. It works well with airports and vor. Before continuing, I tried to transfer all this code to a citation navdislay.styles but I encounter some problems with the names include in the loops "foreach" of the navdisplay.mfd, which are really different of these in my .svg file.

@itOuchpods

Are you going to making an Citation Style Canvas Display?

Yes, I'm doing for the CitationX.

[Hooray]

My suggestion would be to use the ufo to prototype new layers, and then create a new PUI/XML dialog that contains the code you currently have in ND.nas

The basic steps are detailed at: http://wiki.flightgear.org/Howto:Adding ... GUI_dialog

This also has a working example, the Nasal section needs to be replaced with the ND.nas equivalent to set up an ND.

At that point you can protoype your ND without having to exit/restart FlightGear (exiting/reloading the GUI dialog will do).

You can also use io.include() to explicitly include the corresponding Nasal files so that those are reloaded to (just bind the whole thing to a new namespace).

Given that you won't have a real cockpit when using the ufo, you will definitely need to add a few buttons to the GUI dialog - as per the screenshot I posted previously.

For an more sophisticated example, you could also refer to $FG_ROOT/gui/dialogs/map-canvas.xml

Overall, the whole point of this is that you can independently develop the ND/MFD without tightly coupling it to any particular aircraft - at that point you can also render multiple independent MFDs in a single GUI dialog, so that it will be a piece of cake to support multiple MFDs/NDs per cockpit.

At that point, you can then also use the same GUI dialog to prototype other Canvas MFDs,such as a PFD.

This is how I ended up refactoring Gijs' original ND code to support multiple independent instances.

If you are interested in this, I can probably walk you through the whole thing and mentor you to create a corresponding dialog and make that work to easily create new ND styles - but I would ask you to help us update the wiki accordingly, or even document your journey using a new wiki article.

EDIT: Different SVG names should not be a problem as long as you update your foreach loop/vector accordingly

[clm76]

If you are interested in this, I can probably walk you through the whole thing and mentor you to create a corresponding dialog and make that work to easily create new ND styles - but I would ask you to help us update the wiki accordingly, or even document your journey using a new wiki article.

I'm interested with your proposition to help me if needed and it's ok to update the wiki. I've already the authorization to edit.
First, I'll have a look on the steps you describe in your post and come back if necessary, soon I think !...

I can also update the item " Customizing MapStructure Styling" of the "Canvas Snippets wiki". Now I know how to modify styles of APT, VOR ...

[Hooray]

Yeah, feel free to help us improve the wiki if you think there is info missing/unclear.

For the MapStructure/ND dialog, I would probably create a new article.
I am not in a good position to test (actually run) things, but I can defintiely provide code snippets, XML and advice/feedback.

My suggestion would be look at the PUI/XML dialog that sets up a Canvas and then use that as a template for setting up a dialog with 2 canvas areas, one for the captain's ND, one for the first officer's

You can then develop the new style while testing everything independently - note that the screenshot above is already using two Canvas regions, but the 2nd one is showing some profiling info

Besides, this isn't really difficult to do - it's mainly about adapting some code snippets that can be easily found on the wiki, as in putting the ND.nas stuff into said GUI dialog and adapting that to use a different Canvas placement.

Obviously you will need to add a row with buttons to control the whole thing, but from then on, you can much more easily prototype/test the whole thing - and I guess that other users may also find this handy

An early version I used for testing purposes was based on the map/map-canvas dialog:

[clm76]

Hi Hooray,

If you are interested in this, I can probably walk you through the whole thing and mentor you to create a corresponding dialog and make that work to easily create new ND styles -

I tried your suggestion to use the ufo for testing the canvas implementation. First, I used the gui/dialogs/map-canvas.xml and tried some modifications of values to see what happens.
After that, I tried to replace the nasal code include in map-canvas.xml by the "Boeing" nd.nas, without success : Black screen on the canvas window. So, can you help me please ?
My idea is to start of the existing nd.nas (Boeing) which will call "myNavDisplay" (in a new navdisplayCitation.mfd) which will call "navdisplayCitation.styles". All this to keep the same structure than the Boeing and Airbus structure. Is it a good idea or not ?
So, I'm waiting after you to let me know the right way and help me to create my own ND.

[Hooray]

In case you missed it, in response to your topic/posting, I specifically created a new wiki article containing code and instructions, including details on the idea/approach and implementation that I used originally: http://wiki.flightgear.org/Howto:Protot ... play_Style

The proof-of-concept is working fine, but is still missing buttons/checkboxes for the corresponding switches:



My suggestion would be restructure the code a little to use io.include() in the nasal open block, so that the dialog automatically reloads navdisplay.mfd and its navdisplay.styles file whenever the dialog is re-opened. At that point, you should have a simple environment to easily test style changes/additions quickly.

It would also be possible to wrap the inclusion in a call() invocation to trigger an exception/error if there is a parsing problem and show a corresponding error message/dialog.

I haven't checked if the original dialog still works or not, but I found it and added a link to it to the article.

If you are interested in working with the dialog I added to the wiki, you can simply add your changes to it, so that others can more easily follow your progress.

I am currently a little busy, but I will try to extend this according to the functionality provided by the original example, which basically looked like this (I think you only need the stuff on the left hand side, so ignore the plotting stuff on the right side):

[clm76]

Many thanks, it's better to work.

I corrected a small error in the code in "Howto: prototyping a new NavDisplay style". A ">" was missing at the end of "/border".
After correction :

Code: Select all

  <button>
    <legend>Reload</legend>
    <default>1</default>
    <border>2</border>
    <binding>
      <command>reinit</command>
      <subsystem>gui</subsystem>
    </binding>
  </button>


[clm76]

There is a problem with the nasal code "close" in your article "Howto: Prototyping a new NavDisplay Style" :

Code: Select all

  <close><![CDATA[
    print("nasal/closing block");
    foreach(var mfd; MFDInstances) {
        mfd.del();
    }
  ]]></close>

The Log Window says :

Code: Select all

Nasal runtime error: No such member: del
  at /home/chris/fgfs2016_4/install/flightgear/fgdata/Nasal/canvas/api.nas, line 467
  called from: /home/chris/fgfs2016_4/install/flightgear/fgdata/Nasal/canvas/map/navdisplay.mfd, line 108
  called from: __dlg:canvas-nd, line 4


[Hooray]

yeah, thanks for notifying - but that's a minor thing actually (a bug in the code trying to clean up all instances) - I didn't thoroughly test that code, I just wanted to post something that works.

You can review the code of the original dialog to see how to add the buttons/checkboxes to toggle ND features on/off

I will also try to post an augmented version shortly, but please feel free to get involved by making changes - refer to $FG_ROOT/Docs/README.gui for supported widgets, README.layout for layouting options - basically, you can easily create/render several independent NDs and reload those to test new styling/features witout requiring an actual aircraft/FDM or cockpit, with the added advantage that your changes won't be aircraft specific in any shape or form

[Hooray]

Okay, I have now reworked the dialog to support an arbitrary number of ND instances, with added checkboxes for each boolean cockpit switch.
The io.include() stuff to automatically reload navdisplay.mfd( and the styling stuff) also works already, but it does require a few fgdata changes, because there are some hard-coded assumptions in those files (2 places only, which don't properly resolve the canvas namespace).

Apart from this, this is already a rather functional dialog to easily test new changes without having to exit/restart fgfs - this can also be useful for regression testing purposes, because it will always create/show at least 2 independent instances. Hopefully this will also allow us to refactor some of the legacy code in navdisplay.mfd, especially the update() function is begging to be cleaned up and incrementally moved to the styles hash, because it still contains many hard-coded assumptions (e.g. SVG id names that are Boeing specific).


I am also hoping that this could be the groundwork to integrate this with Richard's MFD framework, as well as allowing the same mechanism to be used for other MFDs, such as the PFD, which should ideally also support styling.

Ultimately, this could also help people wanting to use something along the lines of "FGCanvas", i.e. remotely rendering MFDs in a separate fgfs instance.

Maybe Gijs or Hyde would also be willing to get those changes committed to the fgdata repository, so that people can more easily help develop/maintain new ND styles in the future.

http://wiki.flightgear.org/Howto:Protot ... play_Style

[clm76]

Hi,

1 - Sorry but there is still a problem with the <close> item :

Code: Select all

<close><![CDATA[
    print("nasal/closing block");
    foreach(var mfd; MFDInstances) {
        MFDInstances[mfd].del();
    }
  ]]></close>


it closes fg with this error :

Code: Select all

nasal/closing block
Nasal runtime error: container index not scalar
  at __dlg:canvas-nd, line 4

2 - In VOR.symbols, there is an element called "me.radial_vor" which draw a line (and a circle) related to the property "instrumentation/nav/radials/selected-deg".
How, in navdisplay.styles ("vor" hash) can we update this radial if the property changes. I tried with "update_on" without success. I think it accepts only toggle switches or "rate_hz", no ?


3 - when can we use your new dialog work ?

[Hooray]

if the radial line/arc don't change when the property is updated, that would seem like a bug to me - if in doubt, get in touch with Gijs/Hyde to see what they have to say about this - but my understanding is that (without having looked at the corresponding files), the property should be picked up whenever the layer is redrawn - and it should be redrawn if/when the property changes.
So I _assume_ that the MapStructure framework is trying to be too smart, i.e. not redrawing the layer but simply using getprop() instead of a listener to trigger a redraw event.
I don't remember the update_on() semantics, but it should be easy to change/extend to also support other types of "signals" or "events".
I am a bit hesitant to change that as long as Gijs or Hyde don't confirm that this is an actual bug - like I said, I haven't touched that code in years, so I am really not very familiar with it, and I am also not familiar with the aircraft using it - so it's really best to report this to Gijs and Hyde, ideally with a test-case that they can reproduce, and then let them determine if it's a bug or not - once they have confirmed it is a bug, we can work out how to fix it.

Regarding the updated dialog, I haven't yet posted it, because there are two issues - one fgdata related that prevents io.include() from properly reloading everything related to the navdisplay.mfd file (including styling) - which basically means those 2-3 changes need to be committed first, and the other being an actual segfault (crash) related to the Canvas Map/Group code that may reference an invalid element when the dialog closes, which also prevents the reload stuff from working correctly.

I sent a heads-up to TheTom (Canvas core developer), not sure if he's around - if he isn't, I'll ask Richard to take a look, because he's also done tons of Canvas/MFD work recently (unrelated to the ND though).

Apart from that, your screenshot is looking good - it seems you managed to adapt the map-canvas.xml dialog quite well !

Besides, you could also add checkboxes for /sim/rendering/draw-masks to disable rendering of scenery/aircraft to speed up loading even more (while developing the ND)

I can also update the item " Customizing MapStructure Styling" of the "Canvas Snippets wiki". Now I know how to modify styles of APT, VOR ...

map-canvas.xml contains a few examples on changing the colors/appearance of a few MapStructure layers, so feel free to add those to the wiki

[Hooray]

I tried to transfer all this code to a citation navdislay.styles but I encounter some problems with the names include in the loops "foreach" of the navdisplay.mfd, which are really different of these in my .svg file.

This is one of those things where it actually makes sense to clean up navdisplay.mfd, see: http://wiki.flightgear.org/Canvas_ND_Fr ... pendencies

In other words, the newMFD() method is probably the culprit.

Actually, it should not contain these assumptions, but the whole vector should be moved to the styles files, into the Boeing hash - and then looked up there.

There are two foreach loops in the newMFD() method that I would simplify:

Code: Select all

### this is the "old" method that's less flexible, we want to use the style hash instead (see above)
      # because things are much better configurable that way
      # now look up all required SVG elements and initialize member fields using the same name  to have a convenient handle
      foreach(var element; ["dmeLDist","dmeRDist","dmeL","dmeR","vorL","vorR","vorLId","vorRId",
                            "status.wxr","status.wpt","status.sta","status.arpt"])
         me.symbols[element] = me.nd.getElementById(element);

      # load elements from vector image, and create instance variables using identical names, and call updateCenter() on each
      # anything that needs updatecenter called, should be added to the vector here
      #
      foreach(var element; ["staArrowL2","staArrowR2","staFromL2","staToL2","staFromR2","staToR2",
                            "hdgTrk","trkInd","hdgBug","HdgBugCRT","TrkBugLCD","HdgBugLCD","curHdgPtr",
                            "HdgBugCRT2","TrkBugLCD2","HdgBugLCD2","hdgBug2","selHdgLine","selHdgLine2","curHdgPtr2",
                            "staArrowL","staArrowR","staToL","staFromL","staToR","staFromR"] )
         me.symbols[element] = me.nd.getElementById(element).updateCenter();
      


all those element names should be moved into navdisplay.styles

The next huge issue is cleaning up update() accordingly, which basically entails identifying parts that can be moved into styles, too.

Otherwise, creating a completely new style is unnecessarily difficult - full explanation at: http://wiki.flightgear.org/Canvas_ND_Fr ... _ND_Styles

(this is still the case, the code contains roughly 20-30 hard-coded assumptions that make it specific to the orginal Boeing style)