FlightGear Qt launcher and FlightGear package manager: Difference between pages

From FlightGear wiki
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Out of date}}
{{Stub}}
{{-}}
 
{{infobox subsystem
{{Infobox subsystem
| name           = FlightGear Qt launcher
|name       = Integrated Package Manager
| image          = Qt launcher for FlightGear 3.5 on Windows 7.jpg
|started    = ...
| alt            = The aircraft page of the Qt launcher for FlightGear 3.5 as rendered on Windows 7
|description = Provides an integrated package manager for installing/managing and uninstalling aircraft and other fgdata resources
| started        = 01/2015
|status      = Under active development as of 03/2015.
| description    = Integrated launcher for FlightGear designed to replace [[FGRun]]
|maintainers = {{usr|Zakalawe}}
| maintainers   = {{usr|Zakalawe|James Turner}}
|developers = Zakalawe (since)
| developers     = James Turner
<!-- for easily tracking file-specific changes -->
| status        = Under active development as of 05/2016.
|project-history = flightgear
| folders        = {{flightgear source|path=src/GUI}}
|path-history=/simgear/package
| changelog      = {{flightgear source|path=src/GUI|view=log}}
}}
}}
{{Package Management}}
{{Package Management}}
The '''Qt launcher''' is an integrated launcher for FlightGear designed as a replacement for [[FGRun]]. Initially designed as a stop-gap solution in FlightGear 3.4 for the problem of support for the [[FlightGear Mac OS X Launcher|old FlightGear Mac launcher]] ending with OS X Yosemite, it has become FlightGear's main launcher for all platforms, and is shipped with all official FlightGear releases (however, users building from source may need to separately configure/rebuild FlightGear).
In addition, this was also motivated by the plethora of 3rd party GUI launchers/frontends developed by numerous contributors over the years <ref>[[The FlightGear Front-End Situation]]</ref>.
== History and status ==
In October 2014, Apple released OS X 10.10 Yosemite. Unfortunately, one of the frameworks the [[FlightGear Mac OS X Launcher|old FlightGear Mac launcher]] relied upon, called {{wikipedia|RubyCocoa}}, was removed, making it incompatible with OS X Yosemite. James Turner started work on a solution for the then-upcoming 3.4 release. He added a simple built-in launcher using Qt, run before the main window would be created. It was released with FlightGear 3.4 as a Mac-only feature.


After FlightGear 3.4, it was decided to that this temporary Mac-only launcher would be developed into a replacement for [[FGRun]] and that it would become part of the plan for updating the FlightGear user interface. In FlightGear 3.6, it became available for all platforms, and has continued to be developed, enhanced, and refined.
{{DeQuote}}
 
As of May 2016, the Qt launcher is under active development. This includes the adding of new features, fixing bugs, and refining existing features.


== Background ==
== Background ==
In accordance with the [[FlightGear 4.xx Roadmap]], FlightGear's current graphical interface (based on the [[PUI]] library of [[PLIB]]) will be replaced by one based on Qt. [[FGRun]] will also be removed in future to be replaced by this launcher. In addition, a browser-based UI (called [[Phi]]) will continue to be developed in parallel.<ref>{{cite web
TheTom and Zakalawe have begun working on an aircraft package manager, the backend pieces are mostly there but will need some intensive testing. The UI is implemented via [[Canvas]] and [[Nasal]] in the form of the [[Aircraft Center]]. There is a <code>#define</code> flag you can toggle (in HTTPClient.cxx) to enable the code including the Nasal API; it will download / refresh a catalog, which is generated by the scripts  committed to fgmeta. Then you can access the package system from <code>pkg.root</code> in the [[Nasal Console]], using the API defined at the bottom of HTTPClient.cxx<ref>http://sourceforge.net/p/flightgear/mailman/message/32440549/http://sourceforge.net/p/flightgear/mailman/message/32440549/</ref> [http://sourceforge.net/p/flightgear/mailman/message/34183839/].
|url=https://forum.flightgear.org/viewtopic.php?f=18&t=25115#p229445
|title=Re: New Canvas GUI
|author=Torsten
|date=Jan 10th, 2015
}}</ref> This will result in the following user interface:
* Qt launcher
* Internal UI based on Qt, possibly with [[Canvas]] integration
* External browser-based UI (Phi)


However, it should be made clear that Qt will always remain an optional dependency.<ref name="GUIquestions">{{cite web
|url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
|title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
|author = James Turner
|date  = Oct 11th, 2015
}}</ref>


== Usage ==
The idea to encourage hangar authors to ideally use some standard tooling to create their XML, or alternatively we need to provide some XML verification tools around it. Given that property-list XML is not easy to check with an XML schema, any suggestions on a ‘catalog compliance check’ are welcome; we could write one in Python using the same scripts  used to generate the official catalog.<ref> {{cite web
To run the launcher:
  | url    = http://sourceforge.net/p/flightgear/mailman/message/35009088/
* Microsoft Windows users can double-click the '''FlightGear <version>''' icon on the Desktop or click on '''Start''' -> '''All Programs''' -> '''FlightGear <version>''' -> '''FlightGear Launcher''';
  | title  = <nowiki>Re: [Flightgear-devel] Built-in launcher: reproducible segfault
* OS X and Linux users must open a terminal and run <tt>fgfs</tt> with the option <code>--launcher</code>:
  when downloading an aircraft</nowiki>
<syntaxhighlight lang="shell">
   | author = <nowiki>James Turner</nowiki>
$ fgfs --launcher
   | date  = Apr 12th, 2016
</syntaxhighlight>
   | added  = Apr 12th, 2016
 
   | script_version = 0.25
{{note|The launcher is an optional feature for the reasons explained below in the [[#Dependencies|Dependencies]] section. As a result, if you are on Linux and have installed the version of FlightGear provided by your distribution, it might not be available because the packagers might have not enabled it. In that case, ask your distribution to enable the feature.}}
 
<gallery mode="packed">
Qt launcher for FlightGear 3.5 on Windows 7 location.jpg|Location page of Qt launcher in FG 3.5 on Windows 7
Qt launcher for FlightGear 3.5 on Windows 7 settings.jpg|Settings page of Qt launcher in FG 3.5 on Windows 7
Qt launcher for FlightGear 3.5 on Windows 7 addons.jpg|Addons page of Qt launcher in FG 3.5 on Windows 7
</gallery>
 
=== Multiplayer connections ===
As the launcher is still under development, only some basic options are present. Notably, no multiplayer option is shown. To connect to the multiplayer servers, you can do either of the following:
* Start FlightGear from the launcher and then choose {{menu item|Multiplayer|Multiplayer Settings}} inside the simulator.
* Open the '''Settings''' tab in the launcher and specify the following parameters:
<syntaxhighlight lang="shell">
--multiplay=out,10,mpserver01.flightgear.org, --multiplay=in,10,, --callsign=mycallsign
</syntaxhighlight>
replacing ''mpserver01.flightgear.org'' with the multiplayer server to be used and ''mycallsign'' with the desired callsign. Note that a callsign can only be 7 characters long.
 
=== Enabling console display on Windows systems ===
To enable console display on Windows, right-click on the FlightGear shortcut on the Desktop and click '''Properties'''. In the '''Target''' box under the '''Shortcut''' tab, add <tt>--console</tt> at the end and click '''OK'''.
 
=== Aircraft/TerraSync download directory ===
As of FlightGear 2016.2, the location used by the launcher to store downloaded aircraft and TerraSync scenery can be specified in the '''Add-ons''' tab. Specifying the TerraSync download directory manually has, thus, become unnecessary.<ref name="LauncherChanges">{{cite web
| url    = http://sourceforge.net/p/flightgear/mailman/message/35001457/
| title  = <nowiki>[Flightgear-devel] Launcher add-on handling changes</nowiki>
| author = <nowiki>James Turner</nowiki>
| date  = Apr 8th, 2016
| added  = Apr 8th, 2016
| script_version = 0.25
}}</ref>
 
=== Preferences ===
In FlightGear 2016.2 and later, the preferences are stored in ''[[$FG_HOME]]/flightgear.org/FlightGear.ini''.<ref name="LauncherChanges" /> Older versions make use of the default location used by Qt:
* the Registry on Microsoft Windows;
* ''~/Library/Preferences'' on OS X;
* the default preferences location on Linux (usually ''~/.config/FlightGear/FlightGear.conf'').
 
Preferences can be reset to their default values by holding down the {{key press|Alt}} key while starting the launcher.<ref name="LauncherPreferences">{{cite web
| url    = http://sourceforge.net/p/flightgear/mailman/message/34642397/
| title  = <nowiki>Re: [Flightgear-devel] Qt launcher and phi-utility FGFS 3.6.0 RC
to 3.7.0</nowiki>
| author = <nowiki>James Turner</nowiki>
| date  = Nov 23rd, 2015
| added  = Nov 23rd, 2015
| script_version = 0.23
}}</ref>
 
== Repercussions ==
=== Dependencies ===
There is 100% agreement that FlightGear will never require Qt<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
  |title  = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
  |author = <nowiki>James Turner</nowiki>
  |date  = Oct 11th, 2015
  |added  = May 7th, 2016
  |script_version = 0.35
  }}
</ref>, the intention is we’re adding integrated convenience features but the command line / shell environment won’t change and the default mode of ‘fgfs’ even in a Qt-enabled build is unchanged. You need set an env var or pass an argument to get the launcher, even if the feature was selected at compile time. We have the advantage that the Windows and Mac pre-built builds, it’s easy to ensure Qt is available, and those users are less likely to want complex command-line control than Linux users.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
  |title = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
   |author = <nowiki>James Turner</nowiki>
   |date  = Oct 11th, 2015
   |added = May 7th, 2016
   |script_version = 0.35
  }}
</ref>
 
And even if Qt is selected at compile time, it will still be possible to disable it at run time. That’s important because /initially/ it’s likely that some window-setup features won’t work when using Qt. Especially the multi-window options for handling different projectors side-by-side. <ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
  |title  = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
  |author = <nowiki>James Turner</nowiki>
  |date  = Oct 11th, 2015
  |added  = May 7th, 2016
   |script_version = 0.35
   }}
   }}
</ref>
</ref>
When the launcher was introduced, there were significant divergences of opinion regarding whether it was appropriate to require the dependency on Qt; the core developers concluded that it was undesirable, unless it had a specific benefit.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34196458/
|title=<nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>
|author=<nowiki>Durk Talsma</nowiki>
|date=<nowiki>2015-06-11</nowiki>
}}</ref> Since, for the time being, Qt is only needed for the launcher, it has been made an optional dependency, and people can continue using other frontends should they wish so.
If CMake is not able to find Qt 5.1 (the minimum required version) or later, the launcher is not compiled,<ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498614/
|title  = <nowiki>Re: [Flightgear-devel] FGData splitting / assembling the base
package</nowiki>
|author = Rebecca N. Palmer
|date  = Feb 26th, 2015
}}</ref><ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498869/
|title  = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear
git</nowiki>
|author = Bertrand Coconnier
|date  = Feb 26th, 2015
}}</ref> and the following message will be printed:
<syntaxhighlight lang="text">
-- Qt launcher enabled, checking for Qt 5.1 / qmake
CMake Warning at CMakeLists.txt:303 (find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.
  Could not find a package configuration file provided by "Qt5" (requested
  version 5.1) with any of the following names:
    Qt5Config.cmake
    qt5-config.cmake
  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.
</syntaxhighlight>
As of May 2015, the Qt launcher is the default on Microsoft Windows and OS X: in the case of Linux, it's up to the distribution packagers whether to include it or not.
If, how and when the internal GUI can leverage Qt is under investigation and in such an early state that those responsible preferred to not announce anything yet. If this ever happens, this will be discussed on the mailing list.<ref name="GUIhell">{{cite web
|url    = http://forum.flightgear.org/viewtopic.php?p=229563#p229563
|title  = <nowiki>Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??</nowiki>
|author = Torsten
|date  = Jan 11th, 2015
}}</ref>
=== Segmentation faults and race conditions ===
{{Note|Also see {{Issue|1819}}}}
{{FGCquote|1= Should installing an aircraft to the proper aircraft folder be allowed to crash the launcher if that plane has an error the launcher can detect or should maybe the launcher load and report an error somewhere visible in the launchers gui?|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34430800/  | title  = <nowiki>Re: [Flightgear-devel] fgaddon c310 typos??</nowiki>  | author = <nowiki>Ray St. Marie</nowiki>  | date  = Sep 3rd, 2015  }}}}
{{FGCquote|1= The problem with GUI coding is that it is very, very hard - it is much more problematic than normal coding and causes far more headaches (from all the banging of your head against the wall trying to work out why it is racing and segfaulting on one system and not another). |2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34430850/  | title  = <nowiki>Re: [Flightgear-devel] fgaddon c310 typos??</nowiki>  | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Sep 3rd, 2015  }}}}
{{FGCquote|1= Note that as the QtLauncher transitions into a full GUI to replace the PUI GUI, many of these issues will disappear, and new ones will appear. In any case, debugging a modern GUI is much harder than debugging the non-GUI parts. A basic knowledge of threading, locks, and racing is quite useful for understanding and catching these bugs.|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34431801/  | title  = <nowiki>Re: [Flightgear-devel] Debug build / crash on exit</nowiki>  | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Sep 4th, 2015  }}}}


== Issues ==
{{FGCquote
{{FGCquote
|1= One concern I have though, from the discussions over the last year, is that the PUI->Qt migration plan is not a direct one-to-one migration. I.e. to have a main Qt window providing the main FlightGear window by containing a top menu bar followed by a QtWindow GL widget underneath, in which the FG main execution loop is run as a thread from within the Qt main loop. My impression was that the GUI will be a secondary window or dialog that you have to switch to. But one problem I see with this design is that all modern GUI toolkits (Qt, GTK, metro, Cacoa, Carbon, etc.) suffer from racing and segfaulting issues if the GUI main thread or main loop/event handler is not thread number 1.
  |I’ve been working on the package code so it’s ready for 3.6, must admit I’ve not been paying attention to 3.4.1<br/>
|2= {{cite web
<br/>
  | url   = http://sourceforge.net/p/flightgear/mailman/message/34536197/
I have a little bit of time later this evening, I will check the status but I think things are basically ready to roll on Mac and Windows. Once I’ve verified the builds myself I’ll ask here for some other folks to test.
  | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34007335/
  | author = <nowiki>Edward d'Auvergne</nowiki>
    |title=<nowiki>Re: [Flightgear-devel] When is 3.4.1 planned?</nowiki>
  | date   = Oct 13th, 2015
    |author=<nowiki>James Turner</nowiki>
  }}
    |date=<nowiki>2015-04-24</nowiki>
}}
  }}
 
=== Canvas ===
{{Note|Building a QT based GUI is not in any way meant to obstruct the further development of a Canvas based GUI. We did voice some concerns as to whether the need to re-implement a complete widget is worth the cost is terms of development effort. The beauty of open source is that there's more than one way to do things, however. Especially in a completely modular environment (via [[HLA]]) [http://sourceforge.net/p/flightgear/mailman/message/34196458/].
}}
}}


{{FGCquote
{{FGCquote
|1= Canvas works fine in this scenario, we can embed the texture or image a Canvas produces into a QtQuick dialog just fine. (It would be possible to reimplement Canvas using Qt but I don’t see any benefit there - the non-Qt builds still need Canvas support for flight-displays and the like)
  |The default aircraft catalog download path is <br/>
|2= {{cite web
http://fgfs.goneabitbursar.com/pkg/<version>/default-catalog.xml, which <br/>
  | url   = http://sourceforge.net/p/flightgear/mailman/message/34532040/
does not exist for 3.4.0 or 3.5.0, giving a "catalog download failure:" <br/>
  | title = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
error and an empty Aircraft Center.
  | author = <nowiki>James Turner</nowiki>
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33679386/
  | date   = Oct 11th, 2015
    |title=<nowiki>[Flightgear-devel] Non-existent default catalog</nowiki>
  | added  = Oct 11th, 2015
    |author=<nowiki>Rebecca N. Palmer</nowiki>
  | script_version = 0.23
    |date=<nowiki>2015-03-31</nowiki>
  }}
  }}
}}
}}


James isn't expecting many issues integrating Canvas layers with a Qt GUI, so there is no wasted development effort there (there is the possibility to make a [[Canvas]] backend based upon QPainter, which might be a great way to use spare CPU cycles to unload the GPU, however, as Canvas rendering becomes more intensive).<ref name="GUItech">{{cite web
== Objective ==
|url    = http://sourceforge.net/p/flightgear/mailman/message/33245028/
Tthe goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed<ref>http://sourceforge.net/p/flightgear/mailman/message/33413096/</ref>.
|title  = <nowiki>[Flightgear-devel] Gui technologies</nowiki>
|author = James Turner
The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident<ref>http://sourceforge.net/p/flightgear/mailman/message/33550567/</ref>
|date  = Jan 20th, 2015
   
}}</ref> However, at least for the time being, the Qt5 GUI is not even available at run-time, but will be shut down after handing over control to the main FlightGear initialization routines.
The intention is that adding additional ‘hangars’ (aka ‘catalogs’) will be trivial. And anyone can host a hangar, it’s deliberately de-centralised. There is also the expectation that some hangars might have different license terms, e.g. some Creative Commons license which is incompatible with the GPL. (Then we need to decide, how we explain this to users, but right now they download a .zip from a website and don’t care about the license at all).<ref>http://sourceforge.net/p/flightgear/mailman/message/33594007/</ref>


Originally, one of the main motivations for adopting Canvas and using it for UI purposes was to help getting rid of PUI (our legacy GUI engine), while coming up with a GUI that would be compatible with other important use-cases (think modern MFDs showing GUI dialogs and vice versa).  
Then the role of the development team is simply to select which aircraft appear (in each release) in the official catalog (hangar). Obviously we would only select from GPLd aircraft, but beyond that the aircraft could be developed anywhere at all.


The latter is an increasingly important use-case in real life avionics (on jets/airliners) - as can be seen by  [[ARINC 661]]. Such use-cases aren't easily supported by a distributed approach involving for example a browser, HTML5 and ECMAScript/JavaScript.
And I would expect/hope other people to curate hangars based on their choices - e.g. based on time period (WW2), type of aircraft (gliders) or whatever. Often these people might be the aircraft developers themselves (e.g. FGUK team or Lake Of Constance) but again the code doesn’t care. Of course once the technical system is in place there are some social discussions around this to figure out :)
<ref>http://sourceforge.net/p/flightgear/mailman/message/33594007/</ref>


In addition, the idea is to keep modernizing and [[Unifying_the_2D_rendering_backend_via_canvas|unifying the 2D rendering back-end]] in FlightGear by getting rid of legacy GL code to hopefully use modern OSG code in more and more places.<ref>{{cite web
== Security ==
|url    = http://forum.flightgear.org/viewtopic.php?p=229311#p229311
Please be aware that the code downloads zips, unpacks them, makes calls to unlink files, renames directories, and so on. So, some caution is recommended, and especially, don’t run it as '''root''' (while developing it, Zakalawe had it extract a few zips to ‘/‘ or worse due to screwed up path logic).
|title  = <nowiki>Re: New Canvas GUI</nowiki>
|author = Hooray
|date  = Jan 8th, 2015
}}</ref> At least for now, it isn't even clear if/how and when Canvas-based MFDs may support HTML5/Qt5-based UI components or vice versa (e.g. a Qt5 based dialog showing Canvas-based features, such as a [[MapStructure]] layer or MFD instances like the [[NavDisplay]]). Unlike Canvas-based efforts like the [[Aircraft Center]], the Qt5 effort is also adding a rather significant build-time dependency for those wanting to use the new built-in launcher.


=== Duplicating existing functionality ===
A code review of the code in simgear/package/Install.cxx to check any security issues or dangerous behaviour would be appreciate. The code /tries/ to be ‘safe’ - extract zip to a temporary folder, and uses rename/unlink to atomically update if the zip extraction succeeds. But it’s only had one pair of eyes on it so far<ref>http://sourceforge.net/p/flightgear/mailman/message/32440549/http://sourceforge.net/p/flightgear/mailman/message/32440549/</ref>.
{{FGCquote
|1= While Qt5 would still be an awesome feature from a Canvas perspective, it is simply not an option as long as it is entirely optional, because at that point,  some Canvas-based MFD features would no longer work for FlightGear versions without Qt5 support included.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
  | title  = <nowiki>Re: Aircraft reselection </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 10th, 2016
  }}
}}


There's also the issue of code duplication and maintenance, too. As can be seen by functionality that is now getting added/re-implemented in Qt5/C++ space, despite already existing elsewhere:


<gallery widths="400">
{{cquote
Qt launcher for FlightGear 3.5 on Windows 7 location.jpg|This is the location tab of the new Qt5-based launcher, which is entirely hard-coded in C++
   |<nowiki>Well, if we make a manual catalog.xml from the current fgdata/Aircraft (which I have parts of a script to do), and we treat the current aircraft zip URLs as canonical, that is possible with current code right now - since it can do the zip download + extraction to a directory of our choice. We could throw an (ugly) PUI UI around that, and then if someone with more talent than me wants to Canvas-GUI-ify it, that will be great.</nowiki><br/><nowiki>
Airport-selection-dialog.png|A [[Canvas]]/[[MapStructure]] based view of airports with runways/taxiways
</nowiki><br/><nowiki>
</gallery>
I will attempt to get a prototype version of this working tonight / tomorrow. I don’t promise to produce anything usable but as you say, anything would be an improvement.</nowiki>
As can be seen, there's currently no code reuse taking place when it comes to the Qt5-based location tab, and the Canvas/MapStructure-based airport/taxiway layers are very much superior in comparison, too (as well as being much better maintainable (living in fgdata)) - so it would make sense to work out a way to reuse existing code instead.
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32397779/
 
    |title=<nowiki>Re: [Flightgear-devel] select/download aircraft</nowiki>
{{FGCquote
    |author=<nowiki>James Turner</nowiki>
|1= The main motivation why some people want to have a Nasal/Canvas-based GUI is to ensure that aircraft avionics can make use of the GUI toolkit, but also so that the integrated GUI can deal with existing Canvas based features (think avionics).
    |date=<nowiki>2014-05-30</nowiki>
In layman's terms, all this comes down to being able to render a MFD (PFD/ND) in a dialog box, but also to render GUI widgets to a Canvas, i.e. true recursion - as long as this use-case is supported, it does not matter whether Qt5 is used for this or not, the only thing that matters is that it would be possible to create an integrated GUI for editing/maintaining MFD avionics, but also other Canvas-feature (think having a built-in HUD or 2D panels editor).
   }}
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
  | title  = <nowiki>Re: Aircraft reselection </nowiki>
   | author = <nowiki>Hooray</nowiki>
  | date  = Jan 10th, 2016
  }}
}}
 
Once the [[Canvas Development#The_Future_of_Canvas_in_FlightGear|PropertyBasedElement/CanvasElement wrappers]] are fully exposed to scripting space, we could easily register MapStructure as a new Canvas element for directly making the corresponding layers available to C++ code, without introducing any direct Nasal dependencies - i.e. the corresponding airports/runway and taxiways diagrams would be transparently created by Nasal-based Canvas elements, with the Qt5/C++ code only ever having to set a handful of properties (airport ICAO id, styling, range etc).
 
The main obstacle preventing us from doing this right now is that we're not yet [[Initializing Nasal early]], so that the corresponding Nasal/Canvas bindings (via [[Nasal/CppBind]]) are not yet available when the Qt5 UI is running.
 
=== PLIB/PUI (legacy GUI) ===
{{Main article|Howto:Processing legacy PUI dialogs using Canvas}}
Up to now - only a simple replacement for the Mac Launcher has been introduced (and enabled by default only on OSX). This is not related to the internal user interface of FlightGear (which is mainly based on [[PUI]] and increasingly Canvas these days), at least for now.<ref name="GUIhell"/>
 
However, the goal is to make an '''optional''' Qt dependency to replace PLIB PUI.<ref>{{cite web
|url    = http://sourceforge.net/blog/november-2015-community-choice-project-of-the-month-flightgear/
|title  = November 2015, "Community Choice" Project of the Month – FlightGear
|author = SourceForge Community Team
|date  = Nov 1st, 2015
}}</ref>
 
Except of course PUI will have to remain for some awkward use cases in the short term (aircraft dialogs, potentially). When compiled without Qt support, you’ll get a fully functional FG (i.e., '''Qt will never be a requirement to build FG'''), but without the GUI functions – which is indeed what some people want anyway (e.g., in some home cockpit setups).
 
Any in-sim GUI using Qt will exist in parallel to the PLIB/PUI one for at least one major release, although this may mean maintaining two sets of dialogs, unless the XML-translation-tool is good enough that we can use it at run-time for aircraft dialogs.<ref name="GUIquestions"/>
 
Expect to see a test branch in Git in the next month or so, and hopefully something usable for 3.6. The PLIB code will remain so hopefully it can be a gradual transition.<ref name="GUItech"/>
 
{{FGCquote
|1= From what I've seen, I don't see any reason why there cannot be a direct one-to-one migration of the PUI GUI main window to a Qt main window, including dynamically generating the aircraft menu and submenus by parsing the XML unmodified. This can be done incrementally as it is developed, and probably in a way that requiresero changes to the aircraft PUI GUI XML (though changes could be made later, as you can do far, far more with Qt than with PUI). So I personally think that targeting dialogs for the PUI GUI would be the best way to go as this can be directly translated by the GUI developers into Qt dialogs requiring the aircraft developers to do nothing
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34536197/
  | title  = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Oct 13th, 2015
  }}
}}
 
{{FGCquote
|1= At least for the time being, PUI doesn't seem to become obsolete anytime soon, according to James Turner's continuing preference to hack/extend and maaintain custom PUI widgets:
http://sourceforge.net/p/flightgear/mailman/message/34747786/
This observation is also in line with numerous PUI related commits that he made despite his ongoing Qt5 work: http://wiki.flightgear.org/Canvas_GUI#PUI_Widgets
For a more recent example, look at the waypointlist commits that are using neither Qt5, Phi or Canvas at all: http://sourceforge.net/p/flightgear/flightgear/ci/846fd2
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272148#p272148
  | title  = <nowiki>Re: Can't install FGRun package (+ rant about Qt5 launcher)</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 9th, 2016
  | added  = Jan 9th, 2016
  | script_version = 0.23
  }}
}}
 
{{FGCquote
|1= I am strongly against using a very non-standard UI (a text box + slider) to achieve that interaction. I’d much rather we add a spin-box to PUI, which is not especially hard, and give it the ‘click and drag’ mouse interaction which some spinboxes in other apps have, to give similar UI to the sliders without the visual clutter.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34747786/
  | title  = <nowiki>Re: [Flightgear-devel] Speed-up vs time-warp</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Jan 7th, 2016
  | added  = Jan 7th, 2016
  | script_version = 0.23
  }}
}}
 
=== FGRun ===
One of the goals of the Qt launcher is to deprecate older frontends, like [[FGRun]].<ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/codetickets/1591/#4cb7
|title  = Re: #1591 Restore defaults sets invalid paths
|author = Gijs de Rooy
|date  = Mar 8th, 2015
}}</ref><ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235634#p235634
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Mar 17</nowiki>
}}</ref> At the time of writing (May 2016), however, it is still kept provisionally, and the user can choose whether to use the old or the new launcher. This is done for a variety of reasons:
* FGRun has more functionality than the Qt launcher;<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235167#p235167
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
|author=<nowiki>wkitty42</nowiki>
|date=<nowiki>Sat Mar 14</nowiki>
}}</ref>
* it is still being debated whether Qt will also be used for the internal FlightGear UI, and to what extent (especially because there is partial overlapping with the Canvas framework);<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235635#p235635
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Tue Mar 17</nowiki>
}}</ref>
* UI integration will take some time, due to the need for legacy code to be refactored;<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235646#p235646
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Mar 17</nowiki>
}}</ref>
* some building scripts still need to be updated.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235217#p235217
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
|author=<nowiki>wkitty42</nowiki>
|date=<nowiki>Sun Mar 15</nowiki>
}}</ref>
 
=== Python in FlightGear ===
{{See also|Python in FlightGear}}
{{See also|FGPythonSys}}
 
{{FGCquote
|1= depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments  (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=275910#p275910
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
  | script_version = 0.25
  }}
}}
 
{{FGCquote
|1= if this FGPythonSys were integrated into FG, doing things in Python that are directly committed to the core (properly reviewed---well, as the C++ code) as opposed to coming from various uncontrolled external places would certainly be pretty interesting
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=275923#p275923
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>rominet</nowiki>
   | date  = Feb 13th, 2016
  | added  = Feb 13th, 2016
  | script_version = 0.25
  }}
}}
 
{{FGCquote
|1= The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&amp;4 under Python 2&amp;3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures).
(and I have tried other toolkits before Qt and Tk, namely GTK+ 1.2 and wxWidgets [around 2003] Bottom line: for me, Qt is the best)
|2= {{cite web
  | url   = http://forum.flightgear.org/viewtopic.php?p=275923#p275923
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 13th, 2016
  | added  = Feb 13th, 2016
  | script_version = 0.25
  }}
}}
 
== Cross compiling using MinGW64 ==
{{Main article|Building FlightGear - Cross Compiling}}
As of May 2014, the dependency on Qt 5.1 makes it impossible to cross-compile the launcher using MinGW64, as the MXE project does not have makefiles for that version of QT.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}</ref>
 
== Community Feedback ==
{{FGCquote
|1= My issues are:
* I really would like to be able to see ONLY the planes I have installed on my system and not every single plane available for FG. Maybe a checkbox "show only local planes" could solve this? * I can't use a different FGDATA path, which was a very handy feature of FGRun. Even adding <nowiki>--fg-root=/path/to/fgdata</nowiki> to the "Additional options" field doesn't work. - when trying to add Aircraft and Scenery paths, I am presented with a dialog to find them, but I can't see hidden folders there, and Ctrl+H doesn't affect it
* I can't seem to be able to move a scenery path up and down to change the priority order, which is fundamental when using custom scenery
* seems to have much fewer options than FGRun, some of which were handy (for instance, where can I set texture compression now?)
* I love the airport view but I would expect I could position and rotate my aircraft anywhere by clicking around instead of being able to only select runways (which would be a handy feature to start at a parking position if it's not defined for a given airport)
|2= {{cite web
  | url   = http://sourceforge.net/p/flightgear/mailman/message/34752316/
  | title  = <nowiki>[Flightgear-devel] Issues with Qt5 launcher</nowiki>
  | author = <nowiki>Gilberto Agostinho</nowiki>
  | date  = Jan 9th, 2016
  | added  = Jan 9th, 2016
  | script_version = 0.23
  }}
}}
}}


== Development ==
== Development ==
Note the launcher on '''next''' will be in flux shortly as James will add some new features - support for the [[FlightGear Package Manager|aircraft package manager]] especially, and for specifying some directory locations to support "code only" nightly builds (see [[FlightGear Build Server]]) which use an existing FGData download<ref>{{cite web
If you wish to dig into the package system, and create some tooling so it’s easy to publish releases from a Git repo to a web-host, please do. The current script is in fgmeta; see ‘create_catalog.py’ which runs over FGData of course, but you can imagine something similar for any SCM store containing several aircraft. There’s additional features that can be added of course, such as support for ‘beta’ or ‘testing’ versions of aircraft, being able to exist alongside stable versions. That would require some C++ hacking on the client side but pretty straightforward stuff I think.
|url    = http://sourceforge.net/p/flightgear/mailman/message/33503142/
<ref>http://sourceforge.net/p/flightgear/mailman/message/33550567/</ref>
|title  = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear git</nowiki>
   
|author = James Turner
|date  = Feb 27th, 2015
}}</ref>.
 
{{FGCquote
{{FGCquote
   |This [add-on] screen is work-in-progress, I have moved it already in my local version, but didn’t push the changes yet. There’s new UI around the download location too, and the aircraft-dir changes you mention. For aircraft package support in general, I am hoping that setting FG_AIRCRAFT / —fg-aircraft might not be needed, i.e if aircraft-dir is explicitly set, that would be sufficient. This makes having multiple variants of aircraft co-installed much easier for the package system, but will likely need some code fixes as you already identified.
   |My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33683510/
(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development)
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
     |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |date=<nowiki>2015-03-31</nowiki>
     |date=<nowiki>2015-04-03</nowiki>
   }}
   }}
}}
}}


{{FGCquote
{{FGCquote
   |this is an area I’m actively working on, especially how FG to aircraft version handling in the package system works. My current focus is to generate some test hangars on web-hosts to test against, once that works I will call out for other volunteers (Syd Adams already gracefully offered). Expect some churn in this area, in the next few weeks.
   |The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33683532/
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
     |title=<nowiki>Re: [Flightgear-devel] Non-existent default catalog</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |date=<nowiki>2015-03-31</nowiki>
     |date=<nowiki>2015-04-03</nowiki>
   }}
   }}
}}
}}
{{FGCquote|1= The problem is the initialisation sequence. The QtLauncher starts before the 'dynamic airports'. Therefore the park positions are not available (unless they have been added to the NavDataCache by previous runs of FG, and the NavDataCache is not rebuilt).|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34560946/  | title  = <nowiki>Re: [Flightgear-devel] FGFS Launcher -->selecting Parkpositions ???</nowiki>  | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Oct 22nd, 2015  }}}}
== Issues and limitations ==
Note that even in the optimistic case, there will be some limitations – e.g., multi-window setup will not work in Qt builds without further work<ref name="GUItech"/>.
* [http://forum.flightgear.org/viewtopic.php?f=22&t=26504#p246868 Airplane is in FG root, can't see in flightgear wizard]
* {{ticket|1772|bug}}


{{FGCquote
{{FGCquote
   |The default aircraft catalog download path is http://fgfs.goneabitbursar.com/pkg/<version>/default-catalog.xml, which does not exist for 3.4.0 or 3.5.0, giving a "catalog download failure:" error and an empty Aircraft Center [{{Issue|1737}}].
   |Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33679386/
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=225196#p225196
     |title=<nowiki>[Flightgear-devel] Non-existent default catalog</nowiki>
     |title=<nowiki>Re: How to add sort of addon?  </nowiki>
     |author=<nowiki>Rebecca N. Palmer</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>2015-03-31</nowiki>
     |date=<nowiki>Sat Nov 22</nowiki>
   }}
   }}
}}
}}


{{FGCquote
{{FGCquote
   |The "Add-ons" tab of the launcher has several problems on Linux [see posting for details]
   |The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing [https://en.wikipedia.org/wiki/Package_management_system package management system] that is multi-platform and open source (e.g. [http://sourcey.com/pacm/ pacm] or [http://conda.pydata.org/miniconda.html#miniconda miniconda]). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space.<br/>
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33679374/
But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.<br/>
     |title=<nowiki>[Flightgear-devel] Launcher issues on Linux</nowiki>
<br/>
     |author=<nowiki>Rebecca N. Palmer</nowiki>
And particularly [http://sourcey.com/pacm/ pacm] is looking pretty good actually.<br/>
     |date=<nowiki>2015-03-31</nowiki>
However, historically, the project tends to "re-invent the wheel" more often than not ...
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216665#p216665
     |title=<nowiki>Re: Alternative camera control</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Aug 14</nowiki>
   }}
   }}
}}
}}
{{FGCquote
  |Further investigation found that the launcher *is* trying to add this directory to fg-aircraft (src/GUI/QtLauncher.cxx:772), but that this doesn't work because this option is processed before the launcher is run (intentionally, to allow the launcher to find aircraft in fg-aircraft: src/Main/main.cxx:448).
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33686356/
    |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>Rebecca N. Palmer</nowiki>
    |date=<nowiki>2015-04-01</nowiki>
  }}
}}
{{Appendix}}


[[Category:Core development projects]]
[[Category:Core development projects]]

Revision as of 15:10, 12 April 2016

This article is a stub. You can help the wiki by expanding it.
Integrated Package Manager
Started in ...
Description Provides an integrated package manager for installing/managing and uninstalling aircraft and other fgdata resources
Maintainer(s) Zakalawe
Contributor(s) Zakalawe (since)
Status Under active development as of 03/2015.


Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).

While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

Background

TheTom and Zakalawe have begun working on an aircraft package manager, the backend pieces are mostly there but will need some intensive testing. The UI is implemented via Canvas and Nasal in the form of the Aircraft Center. There is a #define flag you can toggle (in HTTPClient.cxx) to enable the code including the Nasal API; it will download / refresh a catalog, which is generated by the scripts committed to fgmeta. Then you can access the package system from pkg.root in the Nasal Console, using the API defined at the bottom of HTTPClient.cxx[1] [1].


The idea to encourage hangar authors to ideally use some standard tooling to create their XML, or alternatively we need to provide some XML verification tools around it. Given that property-list XML is not easy to check with an XML schema, any suggestions on a ‘catalog compliance check’ are welcome; we could write one in Python using the same scripts used to generate the official catalog.[2]

Issues

Cquote1.png I’ve been working on the package code so it’s ready for 3.6, must admit I’ve not been paying attention to 3.4.1


I have a little bit of time later this evening, I will check the status but I think things are basically ready to roll on Mac and Windows. Once I’ve verified the builds myself I’ll ask here for some other folks to test.


— James Turner (2015-04-24). Re: [Flightgear-devel] When is 3.4.1 planned?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The default aircraft catalog download path is

http://fgfs.goneabitbursar.com/pkg/<version>/default-catalog.xml, which
does not exist for 3.4.0 or 3.5.0, giving a "catalog download failure:"
error and an empty Aircraft Center.


— Rebecca N. Palmer (2015-03-31). [Flightgear-devel] Non-existent default catalog.
(powered by Instant-Cquotes)
Cquote2.png

Objective

Tthe goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed[3].

The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident[4]

The intention is that adding additional ‘hangars’ (aka ‘catalogs’) will be trivial. And anyone can host a hangar, it’s deliberately de-centralised. There is also the expectation that some hangars might have different license terms, e.g. some Creative Commons license which is incompatible with the GPL. (Then we need to decide, how we explain this to users, but right now they download a .zip from a website and don’t care about the license at all).[5]

Then the role of the development team is simply to select which aircraft appear (in each release) in the official catalog (hangar). Obviously we would only select from GPLd aircraft, but beyond that the aircraft could be developed anywhere at all.

And I would expect/hope other people to curate hangars based on their choices - e.g. based on time period (WW2), type of aircraft (gliders) or whatever. Often these people might be the aircraft developers themselves (e.g. FGUK team or Lake Of Constance) but again the code doesn’t care. Of course once the technical system is in place there are some social discussions around this to figure out :) [6]

Security

Please be aware that the code downloads zips, unpacks them, makes calls to unlink files, renames directories, and so on. So, some caution is recommended, and especially, don’t run it as root (while developing it, Zakalawe had it extract a few zips to ‘/‘ or worse due to screwed up path logic).

A code review of the code in simgear/package/Install.cxx to check any security issues or dangerous behaviour would be appreciate. The code /tries/ to be ‘safe’ - extract zip to a temporary folder, and uses rename/unlink to atomically update if the zip extraction succeeds. But it’s only had one pair of eyes on it so far[7].


Cquote1.png Well, if we make a manual catalog.xml from the current fgdata/Aircraft (which I have parts of a script to do), and we treat the current aircraft zip URLs as canonical, that is possible with current code right now - since it can do the zip download + extraction to a directory of our choice. We could throw an (ugly) PUI UI around that, and then if someone with more talent than me wants to Canvas-GUI-ify it, that will be great.

I will attempt to get a prototype version of this working tonight / tomorrow. I don’t promise to produce anything usable but as you say, anything would be an improvement.
— James Turner (2014-05-30). Re: [Flightgear-devel] select/download aircraft.
Cquote2.png

Development

If you wish to dig into the package system, and create some tooling so it’s easy to publish releases from a Git repo to a web-host, please do. The current script is in fgmeta; see ‘create_catalog.py’ which runs over FGData of course, but you can imagine something similar for any SCM store containing several aircraft. There’s additional features that can be added of course, such as support for ‘beta’ or ‘testing’ versions of aircraft, being able to exist alongside stable versions. That would require some C++ hacking on the client side but pretty straightforward stuff I think. [8]

Cquote1.png My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.

(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development)


— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
— Hooray (Sat Nov 22). Re: How to add sort of addon?  .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing package management system that is multi-platform and open source (e.g. pacm or miniconda). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space.

But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.

And particularly pacm is looking pretty good actually.
However, historically, the project tends to "re-invent the wheel" more often than not ...


— Hooray (Thu Aug 14). Re: Alternative camera control.
(powered by Instant-Cquotes)
Cquote2.png