Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Cleaning up legacy code

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.
Cquote1.png FlightGear is an old code base, and lots of the old assumptions (like

a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either. The problem with some great new features is that they show up with code that is "ready" to integrate, but without the integration work done. So they languish in the CVS tree until everyone forgets about them. I can recall at least one occasion where a unused module got replaced by a simpler (and arguably less functional) one precicely because the original never got integrated very well and the replacement actually worked.

The extreme programming cult manages to get this idea right (every religion has a kernal of truth, right?) with their insistence on constant refactoring and integration. Features are useless in isolation.[1]

Cquote2.png


Legacy OpenGL code

  • PUI
  • HUD
  • 2D panels
  • Map dialog
  • NavDisplay
  • splash screen
  • od_gauge instruments (wxradar, agradar)
  • kln89

Property tree

Cquote1.png In terms of integration with the property tree, I'm thinking that in the short term all the different components that we split out into separate threads or executables will simply use their own properties trees, and use the RTI to reflect the particular (minimal) data that needs to be passed between components.
— Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png The second thing is to realise that the property tree as it is currently is in need of some rework because of the ownship (single desktop aircraft) approach. This is easier than it sounds - basically most of the property tree becomes part of the aircraft and only a few items are shared. This will also allow the switching of aircraft. The reason to consider this now, and maybe not implement it, is to ensure that the design will support this when it is time to implement it.
— Richard Harrison (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes)
Cquote2.png
  1. Andy Ross (Wed, 12 Nov 2003 10:01:42 -0800). Oh where Oh where ........