Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Back to the plugins discussion ... I am really about to get famous here for my unpopular views ;-) Andy Ross wrote: Boris Koenig wrote: Erik Hofman wrote: I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) I think most of the criticism centers on the idea that, even if you had a nice plugin system available, it really isn't going to help you very much with doing extension development. I was specifically thinking of things that would currently require to directly modify the FlightGear sources, in many cases it would be very useful to have the possibility to load an application dynamically and run it *within* FlightGear, think of applications like atlas - if there was a plugin interface available, it could easily integrate completely into FlightGear and would not need to be running separately. Similar applications like flight planners or even applications that serve as flight management computers could also integrate natively into FlightGear. One of the easiest ways to provide a very basic plugin interface would first make sure to provide handles to FlightGear's client area and subsystems so that each module/plugin can easily use these to do specific things. This would not even be terribly complex and could still be pretty useful, e.g. a flight planner plugin would then simply need access to: - FlightGear's client area - FlightGear's Navaids data That way you could already draw your own GUI into FlightGear's window in order to display your flight planner tool which could then make use of all the necessary (navaid) data provided by FlightGear itself. Of course something like that could also be implemented using a scripting language, but more complex applications would probably be also more time-critical and would need to rely on threaded design. It doesn't change the existing Nasal or FGCommand interfaces at all, well, of course I was thinking of a way to enhance that functionality, it shouldn't be that much of a problem to load a library which exports a C function and a function name for Nasal and make that C function then available as a Nasal or FGCommand, but maybe I am wrong here - but even without knowing anything about FlightGear's/Nasal's internals, I could come up with a corresponding example in ANSI C within 30 minutes... So, even if this _is_ really a problem in FlightGear (which I can't believe) one might still fall back to good old C/C++ - which would probably be the case anyway when it comes to dealing with pointers for dynamic function import. and adds an extra layer of complication. This is of course true, but that extra layer is compared to the FlightGear sources itself pretty restricted and would not be really complex. One could start to add a very basic plugin interface at first. And it would be certainly _A LOT_ easier to document a simple plugin interface than writing all the documentation that's still missing for FlightGear. You won't need that much functionality in the beginning - things like access to most of FlightGear's subsystems would probably already be sufficient in the first place. That way a plugin could ask FlightGear to make use of a specific subsystem. The idea of a plugin comes from the commercial software world, where distinct entities (Microsoft and aircraft vendors, for example) need to ship software on different schedules. You're right - but plugins have other advantages that apply also to the non-commercial world, scenarios which you didn't yet mention, e.g.: You can easily incorporate new functionality into a project like FlightGear without having to make any code-changes or the need to recompile the whole application - you usually provide a generic and simplified set of methods to extend an application, this allows also those users who are not that familiar with the internals of a project to make meaningful contributions. This gets particularly interesting with functionality that's very specific and is not needed by every user - a functionality that might not even have the slightest chance to ever get accepted for an official release. So, basically the whole plugin idea is about _dynamic_extensions_ ! Even *opensource* projects make use of support for dynamic extensions, either by really using plugins (i.e. loading binary libraries) - or more widely spread- by using a powerful scripting interface to allow execution of custom scripts within the application context. The current way to make bigger -coding- contributions to FlightGear is to really dive into the sources and find the right place to integrate your stuff. Also, there really seem to be already things integrated which seem to me rather SPECIAL - e.g. things like GPS data processing. So, how many people (regular flightgear users) are ever going to make use of something like that ? Don't get me wrong, I think it's _great_ to have a lot functionality integrated, but on the other hand there are certainly good
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig said: Back to the plugins discussion ... I am really about to get famous here for my unpopular views ;-) It sounds like you are anticipating something here. My recommendation is that you spend quite a bit more time getting familiar with FlightGear. It isn't that your idea or view isn't good, you just haven't come up with an application for it that strikes me as you know that would be really cool (I'm not speaking for anyone else). Once you are into the project a bit more I'm sure you'll find folks receptive, because you'll understand better what's interesting to them and really know better how a new interface would fit in. If you don't have the patience for that approach there is a second option. You could code up an interface, make an example plugin and post it to the list so folks can try. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. I am leaning towards the later (for FligthGear at least). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. I am leaning towards the later (for FligthGear at least). I wouldn't like to see FlightGear becoming the swiss knife of everybody's need. I would prefer spending time to modularize even more FG and put more in SimGear. This way, everybody could use the library in their own program for the purpose they wish. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support. By saying this you imply to be looking at FlightGear in a much too commercial way. If the source is open there is little need for a plugin system. 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. Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support. By saying this you imply to be looking at FlightGear in a much too commercial way. Sorry, you are definitely wrong, besides: there are not only commerical AddOns to X-Plane. I really don't have any commercial intentions. If the source is open there is little need for a plugin system. Well, I've heard that argument several times now - and of course you are right in saying that one COULD directly modify the FlightGear source code in order to incorporate some desired functionality. But do you really want to have to change the whole FlightGear code for some specific functionality ? To get back to the swiss army knife-example: I do think that example becomes legitimate when it comes to very specific requirements or ideas, the only alternative that remains then would be to create a branch of the original FlightGear source in order to add some specific functionality-something I would personally never consider... This is another point: How about people who have suggestions (possibly even a bit extraordinary) but who like these features to be OPTIONALLY being available in all FlightGear versions ? Speaking of myself now: while I pondered about the pros cons for a FlightGear enhancement such as the FliteTutor concept, I would have really love to be able to do this via some kind of plugin structure. This also for the very same reason that we can currently watch here: people feel differently about certain features, enhancements or suggestions. And I do understand this quite well. Let's consider the FliteTutor example again: IF I really start the first coding attempts,I will very likely have to add some commands to Nasal - and I really wouldn't hesitate to do this directly into FlightGear's source, BUT what we have then is ONE modified version with, that some people might still object against to integrate into the real branch. 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). Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others. Okay, that's a point - a point that hasn't yet been made. Personally, I really wouldn't have any problems about releasing any sources - except maybe, because of their lack of elegance ;-) But I think one could really find a solution for that problem, e.g. either by really making a plugin provide the licence under which it is available - and deny those plugins access, which do not specify an acceptable opensource licence OR by selectively maintaining an internal list (within FlightGear) of plugins that FlightGear would load (because they are opensourced). -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
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. The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree. 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. Besides, most everything can be done in FlightGear without touching any code. Only special cases or additions need to be coded in C++. And I'm still not sure whether your flitetutor isn't outgrowing FlightGear's purpose. Adding a basic, menu accessible Flight Tutorial is probably in line with the project, but moving instruments around and even panel design within FlightGear is out of scope of the program I'm afraid. I would love to hear other opinions about that though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: 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 commands So, 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
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote:
Erik Hofman wrote:
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 ?
It's actually quite simple, you create a derived class from SGSubsystem
and you have to define a small set of functions:
class FGFX : public SGSubsystem
{
public:
FGFX ();
virtual ~FGFX ();
virtual void init ();
virtual void reinit ();
virtual void bind ();
virtual void unbind ();
virtual void update (double dt);
}
The init() functions should make sure everything is set and ready so the
update() function can be run by the main loop. The reinit() function
handles everything in case of a reset by the user.
The bind() and unbind() functions are to tie and untie properties.
The you can register this class at the sub system manager:
globals-add_subsystem(fx, new FGFX);
Now the sub system manager calls the update() function of this class
every frame. dt is the time (in seconds) elapsed since the last call.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: Erik Hofman wrote: I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) I think most of the criticism centers on the idea that, even if you had a nice plugin system available, it really isn't going to help you very much with doing extension development. It doesn't change the existing Nasal or FGCommand interfaces at all, and adds an extra layer of complication. Basically, you have to write a little extra code to avoid typing make quite as often. That's not a very good tradeoff. The idea of a plugin comes from the commercial software world, where distinct entities (Microsoft and aircraft vendors, for example) need to ship software on different schedules. It's a solution to a problem that, honestly, we don't have yet. We aren't that big. I think as you get used to the existing architecture, you will find that most of the extensions you are thinking of are best implemented as augmentations (or even rewrites) of pre-existing code instead of pluggable, not-quite-orthogonal extra features. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Well, regarding the clever subsystem architecture - is there any more detailed information available ? It's actually quite simple, you create a derived class from SGSubsystem and you have to define a small set of functions: Thanks for that (REALLY !) But actually I was really asking WHAT subsystems exist, how they are called (names, not programming !) and what their purpose is. I indicated already a couple of days ago, that I wouldn't mind writing some documentation, and I think these details are still missing, one could even present such information in a graphical way (as I mentioned already) Later, one could add the properties that affect a certain subsystem. I think this would really make for some good introduction into FlightGear developing, I would certainly find it easier to dive into the code if such things were generally available. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? That way one wouldn't need to rebuild FlightGear itself in order for a certain feature to be added and you could even keep code separated, in addition one would not necessarily need to have the whole buildtree available in order to implement a specific function for Nasal. And you could still optionally import that plugin code natively into FlightGear-if you want to- it wouldn't make any difference in the end. One would only need to implement some kind of simple plugin structure and a simple mechanism to load all libraries in a specific subfolder and check whether they export a specific Plugin-function - if they do, these functions will be made available as Nasal Commands. One could even go further and use the same technique in order to implement external fgcommands for FlightGear. What do you think ? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
