Spoken GCA

[rleibner]

I found the origin of the nasal error line 294

Fine !

I've just uploaded PAR version 0.0.2 which includes buttons for glideSlope customization.

[clm76]

Hi,

Cool the slope customization.
But a new problem appears : When changing the rwy (by the RWY button), the cone angle with the ground changes, as you can see, for example, at LSGG.

[rleibner]

When changing the rwy (by the RWY button), the cone angle with the ground changes

Yes it does. As the terrain profile changes (following the RWY heading), the minimum slope is adjusted to avoid collisions and the cone (about 4 degrees wide) rotates accordingly.

[Hooray]

if in doubt, add an option to display the sampled terrain (again) ?

[rleibner]

if in doubt, add an option to display the sampled terrain (again) ?

In my opinion, ver.:0.0.3 is working OK.
By the way, I think it's time to remove SpokenGCA from SF ( keeping a Readme suggesting PAR? ).
Same to its wiki page (redirect it to PAR page).
Are you agree with that?

[Hooray]

It's your decision, I believe you can proceed as you prefer - so far, you've been the primary addon developer anyway

[clm76]

To improve readability of PAR text, I suggest to use the font “LiberationMono-Regular.ttf" and add this line in “plot2D.nas” :

Code: Select all

Text.setFont("LiberationFonts/LiberationMono-Regular.ttf");

here :

Code: Select all

text: func(group,text, origin=nil, size=nil, color="#0",align="left-baseline") {
------
 if(size==nil) size = [11,1];
  var Text = group.createChild("text", id);
  Text.setFont("LiberationFonts/LiberationMono-Regular.ttf");
  Text.setFontSize(size[0],size[1]).setAlignment(align);
  Text.setText(text);
  Text.setColor(color);
  Text.setTranslation(origin);
 return Text;
}, # text


This font is in « $FG_ROOT/Fonts/liberationFonts » and works with Linux but I don’t know if it’s the same for Windows and Mac.

Before After

Another point : There is a problem of coexistence between fgaddon/PAR and fgaddon/Oscilloscope :
They have the same classes names (for example plotD in plot2D.nas in Oscilloscope and PAR, graph in graph.nas...), so it’s the plot2D class of Oscilloscope which is used with PAR instead of the PAR class.
To test that, for example you delete (with #), the « text » function in « plot2D » class of Oscilloscope and launch the PAR : it doesn’t work with a nasal runtime error : « No such member : text ».

[rleibner]

To improve readability of PAR text, I suggest to use the font “LiberationMono-Regular.ttf" and add this line in “plot2D.nas”...

Please note that all the 3 files

* plot2D.nas
* graph.nas
* skinnable.nas

are not exclusives for PAR use. The next FG release will include them under the $FG-ROOT/Nasal/Canvas folder, and new features/addons (not only PAR and Oscilloscope) will use them.
For that reason it's not a good idea to modify plot2D.nas.
Nevertheless, you can change the PAR default font at the canvas.group level:
Edit par.nas line #47 changing m.frontGroup = sk.root.createChild("group");
to m.frontGroup = sk.root.createChild("group").set("font", "LiberationFonts/LiberationMono-Regular.ttf");

Another point : There is a problem of coexistence between fgaddon/PAR and fgaddon/Oscilloscope :

As said before, both addons uses the same tools. By the moment they are (duplicated) under the addon folder. It does not matter which one is loaded into the canvas namespace (because they are identical).
In the future each addon will call the common $FG-ROOT/Nasal/Canvas/skinnable, $FG-ROOT/Nasal/Canvas/plot2D and $FG-ROOT/Nasal/Canvas/graph

[Alant]

Be aware that the Liberation font family is not included in a standard windows installation. Fortunately it is simple to download and install e.g. https://pagure.io/liberation-fonts.

Alan

[clm76]

Be aware that the Liberation font family is not included in a standard windows installation. Fortunately it is simple to download and install e.g. https://pagure.io/liberation-fonts.

Ok, thanks.
Do you know which Flightgear fonts are common to all installations ?

[Hooray]

See $FG_ROOT/Fonts (IIRC)

Regarding your skinnable work/docs (wiki), I'd suggest to look at Stuart's FG1000 work, especially gui.nas: $FG_ROOT/Aircraft/Instruments-3d/FG1000/Nasal/gui.nas

He's using a rather generic approach, and if you could adapt your skinnable module accordingly, it would become even more powerful.

Basically, I'd suggest a modular approach along the lines of your plot2D helpers - just with a focus on "skinnable" dialogs:

- screen area (clipping, embedded canvas)
- keys/buttons (event handlers)
- tooltips
- changing cursor

If these features could be integrated and generalized, I am sure that more addons will be using a theme-based UI, which is also a good way to make up for the lack of Canvas widgets, and it would be in line with Thorsten's ongoing work in the aircraft dialog department.


http://wiki.flightgear.org/FG1000

[rleibner]

I agree, the more generic is the most useful approach will be

I'd suggest to look at Stuart's FG1000 work, especially gui.nas: $FG_ROOT/Aircraft/Instruments-3d/FG1000/Nasal/gui.nas

I wonder what makes Stuart's approach more generic and useful than mine.
I guess that

* To use a scale argument along with the size one.
* To set listeners to mouse wheel, not only to click.
* To callback notifying the event, not only its coordinates.
* To provide a cleaner and safer del() method.

Please advise me if I'm missing something important.

[Hooray]

There is a vector with a hash map that handles all the mapping for various events/tooltips etc - it's rather generic in its current form, and could be easily generalized to move this into the MFD framework, or directly into the Canvas namespace.

Basically, there is a foreach loop traversing the vector to dynamically add skin specific event handlers, tooltips etc

This could be generalized more to support different types of events and also animations (mouseover/cursor), and maybe even a distinct "screen" component to serve as a wrapper for an embedded Canvas.

At that point, it would be possible to implement arbitrarily complex MFDs using such a skinnable helper - imagine stuff on the shuttle (multiple screens, multiple keypads ) - all rendererd in a single dialog.

For now, this is purely feedback, I wouldn't do any coding at this point, just suggesting to take a look at similar use-cases and maybe borrow code/ideas from those.

[rleibner]

There is a vector with a hash map that handles all the mapping for various events/tooltips etc

Currently I have such vector in the client (par.nas). You are suggesting to pass that vector (as an argument) to the skinnable object ... In that way skinnable will manage the events, check the hotpoints and notify the client when appropriate.

Interesting, will try that.

[Hooray]

Yeah, I was suggesting to come up with a "skinnable" framework, and the corresponding helpers, to generalize Stuart's approach even more.
For instance, click-able regions can also register a mouse-over event to show tooltips: http://wiki.flightgear.org/Tooltips

Regarding cursor handling, see:

Code: Select all

var c =gui.setCursor(cursor:"crosshair") ;

fgcommand("set-cursor", props.Node.new({
'cursor':'crosshair'
}
));


For reference, see: https://sourceforge.net/p/flightgear/fl ... r.cxx#l222

For now, I would suggest to ignore the Nasal API, because either the docs are wrong or the API got broken ... the fgcommand should work just fine though (it does for me).