Boris Koenig wrote:
Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project.
I don't think that would be a major problem, there's other opensource
(GPL'ed) software that makes use of modular enhancements (aka
"plugins")- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a
module needs to provide the licence under which it is available in
order to be loaded (This is a kernel 2.65 addition I think).
I'm still not convinced that a plugin system would be such a great idea for FlightGear.
Well, I am just making suggestion :-)
The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree.
Well, regarding the "clever subsystem architecture" - is there any more detailed information available ?
Also, I have browsed the property tree and read all the docs about the property tree that I could get my hands on, but didn't find any details regarding how to disable subsystems like the FlightDataModelling, (in order to provide some instrument familiarization there would not be any need for such stuff be running in the background)
Adding new code is quite easy, but by introducing a plugin loader we would be put right back into the C world, using structures to pass variables around.
I think you are probably right in saying that FlightGear is already extremely advanced, but adding features by the means of plugins could also be done using some kind of higher level mechanism. But okay, this isn't that important right now. As I mentioned above: I am merely making suggestions.
Besides, most everything can be done in FlightGear without touching any code.
> Only special cases or additions need to be coded in C++.
That's exactly why I would _actually_ love to use the Nasal approach, though things like XML-handling might still be necessary to be added.
And I'm still not sure whether your flitetutor isn't outgrowing FlightGear's purpose.
it isn't meant to do so - it's should be merely an enhancement
Adding a basic, menu accessible Flight Tutorial is probably in line with the project,
Currently, this would be ONE of the supported modes that FliteTutor should be able to work in. By the way: there doesn't seem to be
PUI-PopUp menu supported within the XML resources: how likely is
it, that things like these could be added ?
but moving instruments around and even panel design within FlightGear is out
> of scope of the program I'm afraid.
Yes,regarding that argument you are probably not entirely wrong, if you
remember my original plans for the whole thing (which are also still available on the webpage, I think) you'll notice that I had originally
planned to develop the authoring component using QT - OUTSIDE of
FlightGear itself. Simply BECAUSE OF things like interactive
dragging & dropping of components. While the player would be integrated
within FlightGear - possibly as a set of Nasal scripts.
But again, things like dragging & dropping of panels would already be one of the more advanced features and is not really considered realistic to be implemented in the near future.
I would love to hear other opinions about that though.
You are actually about to give pretty good reasons for a plugin architecture by implying that the FliteTutor concept is a bit "too special" - and as I mentioned above, I do somewhat agree with you, at least regarding these more advanced features - and I haven't even yet mentioned those other utopic suggestions that I received ;-)
The options that I would be left with in such a case would really be mainly:
- either grab, understand and modify the FlightGear
sources in order to start a branch which supports the
necessary additions (unlikely to happen !) - at least add dynamic Nasal extension support by the
means of plugins in order to be able to call some more
advanced Nasal commandsSo, my intention would definitely be to make this whole thing GENERALLY available - I certainly wouldn't start to create "my own" FlightGear version just for some learning stuff to be integrated.
I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels).
--------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
