20,741
edits
FGPythonSys: Difference between revisions
Jump to navigation
Jump to search
→FFGo launcher
(→Vision) |
|||
| Line 210: | Line 210: | ||
=== FFGo launcher === | === FFGo launcher === | ||
{{FGCquote | {{FGCquote | ||
|1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo! | |1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo! | ||
| Line 219: | Line 218: | ||
| date = Aug 4th, 2015 | | date = Aug 4th, 2015 | ||
| added = Aug 4th, 2015 | | added = Aug 4th, 2015 | ||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{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&4 under Python 2&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). | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275923#p275923 | |||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | |||
| author = <nowiki>rominet</nowiki> | |||
| date = Feb 12th, 2016 | |||
| added = Feb 12th, 2016 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{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 FFGo: a new FlightGear launcher</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Feb 12th, 2016 | |||
| added = Feb 12th, 2016 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= One interesting thing that FGPythonSys could probably bring to FFGo would be, I think, FG-compliant parsing of aircraft data. For now, I haven't done that because I found that the interesting metadata (e.g., aircraft radius) is not necessarily in the -set file, but may be included from a different one. And maybe a correct parser for these things must also handle conditions in the XML data, etc. So, despite knowing the declared radius of parking positions, I haven't provided any hint yet in comparison to the selected aircraft's radius for these reasons (and lack of time). | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275923#p275923 | |||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | |||
| author = <nowiki>rominet</nowiki> | |||
| date = Feb 12th, 2016 | |||
| added = Feb 12th, 2016 | |||
| script_version = 0.23 | | script_version = 0.23 | ||
}} | }} | ||