Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search
added info and link to SourceForge, minor spelling corrections
m (spelling)
(added info and link to SourceForge, minor spelling corrections)
Line 1: Line 1:
: ''See also [[Bugs]]''
: ''See also [[Bugs]]''
'''Please note:''' We now have a a tracker on SourceForge at [http://sourceforge.net/tracker/?group_id=583]. Please list your bug/feature request/enhancement/idea on SourceForge as well as here.


Occasionally, people join the FlightGear mailing lists offering to contribute to FlightGear and asking where they might start contributing, apparently often hoping for some sort of official "TODO" list or at least some sort of semi-official roadmap. Unfortunately, nothing like this exists so far for FlightGear and the closest thing to a "TODO" page, the "Goals page", has apparently not really been updated for several years.
Occasionally, people join the FlightGear mailing lists offering to contribute to FlightGear and asking where they might start contributing, apparently often hoping for some sort of official "TODO" list or at least some sort of semi-official roadmap. Unfortunately, nothing like this exists so far for FlightGear and the closest thing to a "TODO" page, the "Goals page", has apparently not really been updated for several years.
Line 6: Line 9:
In addition, many developers find it often hard to come up with suggestions for "mini projects", not because there are not any such opportunities, but rather because there does not exist any sort of general schedule or development plan. However, FlightGear itself does indeed offer a very broad range of often exciting contribution possibilities, this page is dedicated to providing a collection of such ideas that were discussed on the mailing lists. Not all of these ideas are necessarily "mini projects", rather some of these can be quite complex efforts that were simply not pursued because of the very complexity.
In addition, many developers find it often hard to come up with suggestions for "mini projects", not because there are not any such opportunities, but rather because there does not exist any sort of general schedule or development plan. However, FlightGear itself does indeed offer a very broad range of often exciting contribution possibilities, this page is dedicated to providing a collection of such ideas that were discussed on the mailing lists. Not all of these ideas are necessarily "mini projects", rather some of these can be quite complex efforts that were simply not pursued because of the very complexity.


Also, as this is a static page and no searchable bug tracking system, we have decided to categorize these "mini projects" into groups ranging from "minor", "intermediate", "major" and "huge" to give new developers an impression of the estimated complexity of the various ideas.
Also, as this is a static page <strike>and no searchable bug tracking system,</strike> '''no longer true - see above re SourceForge tracker''' we have decided to categorize these "mini projects" into groups ranging from "minor", "intermediate", "major" and "huge" to give new developers an impression of the estimated complexity of the various ideas.


Please note: while this list is only meant to provide an overview of desirable short- and long-term features for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects, that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole, for example:
Please note: while this list is only meant to provide an overview of desirable short- and long-term features for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects, that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole, for example:
Line 176: Line 179:
* saving/loading flights is not very convenient, currently loading a flight requires the user to remember its path and filename, a better way would be some sort of file picker dialog, so that the user can actually browse his file system and view all files. Also, we will probably want to have some sort of standard location for saved flights, possibly in the ~/.fgfs home directory? Additionally, it may be desirable to save additional meta information with each flight (i.e. a description) so that we could show this information as some sort of preview for all flights that were saved.
* saving/loading flights is not very convenient, currently loading a flight requires the user to remember its path and filename, a better way would be some sort of file picker dialog, so that the user can actually browse his file system and view all files. Also, we will probably want to have some sort of standard location for saved flights, possibly in the ~/.fgfs home directory? Additionally, it may be desirable to save additional meta information with each flight (i.e. a description) so that we could show this information as some sort of preview for all flights that were saved.
* there is a great number of aircraft in FlightGear that cannot yet be reliably reset due to problems relating to tied properties that cannot properly be untied, obviously there are various parts in FlightGear that still do not make proper use of the property tree, we should get rid of such problems eventually
* there is a great number of aircraft in FlightGear that cannot yet be reliably reset due to problems relating to tied properties that cannot properly be untied, obviously there are various parts in FlightGear that still do not make proper use of the property tree, we should get rid of such problems eventually
* Currently, TerraSync (the automatic scenery tile downloader) is a separate program, that users need to get, explicitly install and set up in order to be able to use it. Even moreso, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience. That's why it would probably make sense to port the TerraSync functionality over to FG, so that it can become a native part of FlightGear itself, preferably an SGSubsystem based service that's runtime configurable via property tree variables. At http://www.samba.org/rsync/ there is a small C library available that exposes most of the rsync features, we could make the library either an additional dependency or simply make it a part of FlightGear/SimGear, so that it's automatically available to all FG users.
* Currently, TerraSync (the automatic scenery tile downloader) is a separate program, that users need to get, explicitly install and set up in order to be able to use it. Even more so, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience. That's why it would probably make sense to port the TerraSync functionality over to FG, so that it can become a native part of FlightGear itself, preferably an SGSubsystem based service that's runtime configurable via property tree variables. At http://www.samba.org/rsync/ there is a small C library available that exposes most of the rsync features, we could make the library either an additional dependency or simply make it a part of FlightGear/SimGear, so that it's automatically available to all FG users.
* After each FlightGear session there are often many OpenAL related warnings displayed in the console, we should try to get rid of these wherever possible
* After each FlightGear session there are often many OpenAL related warnings displayed in the console, we should try to get rid of these wherever possible
* add support for texture based OpenGL cursors, so that we can specify arbitrary textures to be displayed as cursors. Currently, we support both, GLUT as well as SDL, so we should try to maintain compatibility with both libraries.
* add support for texture based OpenGL cursors, so that we can specify arbitrary textures to be displayed as cursors. Currently, we support both, GLUT as well as SDL, so we should try to maintain compatibility with both libraries.
81

edits

Navigation menu