FlightGear Newsletter May 2014: Difference between revisions

{{TOC_right|limit=2}}

== Development news ==

=== Project Rembrandt ===

=== Porting the Garmin GPSMap 196 to Canvas ===

The Garmin 196 is currently in the process of being ported to [[Canvas]] and [[MapStructure]] by F-JJTH.  

Given the generic nature of Philosopher's [[MapStructure]] framework,it only took us 60 seconds to integrate with MapStructure using just 10 lines of [[Nasal]] code - it's a fully working moving map - scale is obviously still off in those screen shots, but it's a matter of setting another style (which can also be used to change color and most symbols)

This is exactly the reason, why we've been working towards an aircraft and GUI agnostic abstraction layer using MVC design concepts - so that reusing and integrating such stuff is really straightforward, without people having to come up with their own custom maps and layers from scratch.

Also see [[Garmin GPSMap 196]].

=== Canvas Performance ===

Canvas is a new technology in FlightGear, and it not just a single technology, it's built on top of other technologies, like the [[Property Tree]], ShivaVG/OpenVG, OSG and OpenGL. As you may have noticed, we didn't even mention [[Nasal]] yet - that's because Nasal scripting, strictly speaking, isn't even required to use [[Canvas]] - the whole thing can be used without touching any Nasal - just by using the property tree, the built-in httpd or even the [[Telnet usage|telnet]] interface.

=== A Canvas-based Map dialog ===

As part of increasingly adopting our [[Canvas]] 2D rendering framework and in order to help [[Unifying the 2D rendering backend via canvas]], the canvas-based [[Map]] dialog is currently being overhauled by Philosopher and Hooray, who are hoping to finalize this in time for 3.2 - the hard-coded [[Map]] dialog will obviously remain functional for at least one full release cycle until it can be phased out by a pure [[Nasal]]/[[Canvas]] based solution using the new [[MapStructure]] framework. Currently, this is all still just available in the [[Canvas-hackers|canvas-hackers team clone on gitorious]] - but we're hoping to implement the main missing features within the next few weeks.

Map-canvas-dialog-storms-overlay.png|Gijs' original wxr (storms) layer ported to Philosopher's MapStructure framework (still experimental)

</gallery>

=== Missions & Adventures ===

[[File:Tmabanner.png]]

FGTAM - FlightGear Tutorials, Missions & Adventures has received an assorted set of icons created by Michat in order to support with standard vectorial graphics the broad range of options that this collaborative code effort and technology can offer to the FG Project.  

[[File:Jettraffic.png]]

[[File:Pickuppoint.png]]

[[File:Precisionlandingpoint.png]]

Here are shown some examples of icons that have been created.

{{forum|79|Tutorials, Missions & Adventures}}

=== Getting your own ideas into FlightGear without having to be a programmer ===

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.

Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.

We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".

Continue reading at [[Implementing new features for FlightGear]]...

=== Getting involved as a programmer ===

Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done.  Fundamentally we need more core devs.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== Wiki updates ==

|}

== And finally ... ==

=== Contributing ===

{{Volunteer Intro|mode=showlogo}}

=== Call for volunteers ===

* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support

[[Category:Changes after 3.00]]