Allow a MFD to be controlled via Emesary notifications (notifications.PFDEventNotification);
Notification needs to be constructed with the following parameters;
1 - MFD designation (text; name of MFD)
2 - MFD identity (int, id of the MFD within the model). Default 1; same as used when creating the MFD
3 - Event type (PFDEventNotification.SoftKeyPushed, notifications.PFDEventNotification.ChangeMenuText
4 - Event parameter.
a) for PFDEventNotification.SoftKeyPushed an int identifying the button
b) for notifications.PFDEventNotification.ChangeMenuText a hash array containing the menu ID and the new text (e.g. [{ Id: 1, Text: "NNN"}])
Method obj.PFD.RegisterWithEmesary(emesary.GlobalTransmitter) need to be called to connect the MFD to a transmitter
Don't use the built-in SVG/rect parser, since this bypasses creating
coordinate / command properties which some Canvas users rely upon.
This reverts commit 57a2d21ddf.
- properly referencing the canvas namespace, so that the ND module can be separately included via io.include()
- moving the initialization of aircraft specific SVG elements into the navdisplay.styles file, and the corresponding Boeing/Airbus entries there (see initialize_elements())
This links together the generic MFD and the NavDisplay; it allows a fairly easy method to add a Map page to an MFD device.
----------------------
See: http://wiki.flightgear.org/Canvas_MFD_Framework
----------------------
Instantiate parameters:
1. pfd_device (instance of PFD_Device)
2. instrument display ident (e.g. mfd-map, or mfd-map-left mfd-map-right for multiple displays) - used to map to the property tree
3. layer_id: main layer in the SVG
4. nd_group_ident : group (usually within the main layer) to place the NavDisplay
5. [optional] switches - used to connect the property tree to the nav display. see the canvas nav display.
To add a canvas nav display page simply do
me.some_page = PFD_NavDisplay.new(me.PFD,"Situation", "mpcd-sit", "ID", "jtids_main");
I created a substantial quantity of new work in the New Regional
Textures project and I would like to ask if anyone could review and
perhaps commit them into FGDATA. The modifications are:
- New textures and material definitions for California
- New textures and material definitions for Mexico
- New material definitions for Central America
- New textures and material definitions for Southern Europe
(Mediterranean region: Portugal, Spain, south of Italy, Greece, coast of
Balkans)
- New airport grass texture (global)
- New airport grass texture for Latin America
- New American town texture (global)
- Small improvement to grass blade textures (to better fit the airport
grass texture)
If this will be committed, we must add a note thanking the United States
Geological Survey (USGS) for the satellite images of California (
http://www.usgs.gov/ ) to the Thanks file.
Add generic version of a canvas MFD (based on the F-15)
It has a fairly simple class structure and hopefully is reasonably easy to understand; Thorsten's using it on the Shuttle and Hooray mentioned that it'd be a good idea to make it generic. It provides a device, that has pages and a set of buttons. The set of buttons control the page that is selected (i.e. a menu). Each page has its own set of menus. A menu defines a label and a page that is displayed. I intend to document it on the wiki once its added.
Only show max 50 aircraft by default and provide a "Show More"
button. This prevents locking the GUI for up to nearly 15 seconds
with showing the list of all aircraft.
Rewrite the way scrolling for ScrollAreas is handled: Store
content position instead of scrollbar positions to keep position
on resize and promote moving the content instead of the contents
to as primary API.
Let the mousewheel scroll by fixed content offset instead of
scrollbar offset to make it actually usable (especially with
low scrolling distance).
- Increase default size.
- Run parse_markdown on description to remove multi
whitespace, possible present in catalog.xml and
also support simple, one-level bullet point lists.
- Needs FlightGear compiled with -DENABLE_PACKAGE_SYSTEM.
- Shows only first 100 available aircrafts.
- Now progress indication on install/remove (need to reopen
dialog afterwards)
Fix the main bugs, add features and convert most of the layers.
Move/refactor some things as well. Add a canvas map dialog next to the
built-in one -- it's not 100% functional but it's quite close actually.
As before, the excitement has been taking place at our team clone.
https://gitorious.org/fg/canvas-hackers-fgdata/commits/0b4cc84
(topics/canvas-map-dialog branch this time, current HEAD in above URL.)
Features:
- Various configurable styles.
- Working scroll bars, thanks to Tom
- Adequate REPL-ness.
See the wiki for more information!
http://wiki.flightgear.org/Interactive_Nasal_Console
N.B. This makes some (sane) changes to other Nasal files, including
expanding some of the Canvas API.
- Calculate bounding box after adding all children.
- Apply rotation after all SVG defined rotations to use correct
center of rotation (as defined in Inkscape)
This (together with the SimGear and FlightGear commits) fixes
the core problems of #1333.
Implement traffic in MapStructure and use it. Various other hacks and/or
cleanup. Feedback required on whether this is a lot better than before.
Also partially revert 9c018d94c4d88dad7476ec250fa3b52024526f4b to add
feature to geo.PositionedSearch: it me._equals is overridden then the
old mechanism is used instead of the new C++ function, so that the
custom equality can be used. (In particular for the Fixes with the
TrafficModel class).
Make fdm listener single-fire, don't listen to /sim/signals/reinit. This
allows the Canvas to stay with the same placement through reinit, after
both the 777 and 747 were having problems. I don't see any reason for
having to recreate it all, and the cleanup function is still there (e.g.
for independent windows, to have their .del() call the ND's .del()).
renamed handle_reinit() -> del()
This also makes sure the /canvas/by-index/canvas[3/4]/ nodes are removed
and then recrated, as well as making sure the MapStructure del() path is
followed and working. Unfortunately the NDs are still blank after reinit.
The old API is not used with newer versions of FG. If an old
version of FG is used, also the according version of fgdata
should be used, which also includes the correct API wrappers.
In time for 3.0. The API is still not fully complete, and not fully
cleaned up, but this is good enough for this release cycle (and it
should offer benefit longer term, if not now -- hopefully performance as
well).
Many thanks to Hooray as well, who has helped prepare things while I
could not, and often suggested ideas.
- move SVG to Canvas directory
- add basic wxradar
- differentiate between track and heading
- improve altitude arc
- add range arcs
- display correct ETA for next waypoint
- get rid of global variables and use instance variables
- identified all important drawing routines and move them into *.draw files
- changed to dynamic loading of *.draw *.model and *.layer files
- implemented poor-man's controller hash to move use-case specific conditionals out of the draw files, and back into the instantiation, i.e. Gijs' EFIS class
- started identifying stuff that is not specific to drawing, but to what is to be drawn, i.e. Model stuff - such as positioned queries, moved those out into *.model files
- some more work on supporting more than a single ND MFD instance per aircraft
- renamed a handful of SVG identifiers to avoid naming conflicts and to simplify usage of SVG IDs as member fields
- moved all of the setlistener setup out of the fdm-initialized stub right into the ctor of the Efis class (actually that's controller stuff...)
- initial MapStructure framework
- aircraft-agnostic NavDisplay class
- preparations for deprecating map.nas
- additions to canvas.map
- preparations for making NDStyles configurable via XML
- Canvas window placements now use 'id' instead of 'index'...
- Provide Dialog class for backwards compatibilty (but print a
warning that it will be removed)