Jim Wilson wrote:
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.
hmm, depends ...on the point of view ;-)
Actually, I just want to have a discussion of the topic -
the outcome is secondary to me, as I consider it pretty
unlikely for a real plugin system to be implemented that
soon - not so much because of my lack of ability to convince
you guys ;-) but rather because something like that would need
to be designed properly and need a good structure.
My recommendation is that you spend quite a bit more time getting
familiar with FlightGear.
you mean ...instead of writing long eMails ? :-)
you're probably right, but my imaginations were based on a
certain project and I think the overall plugin idea might
very well be useful for other projects as well.
So, I am certainly not against getting familiar with FlightGear,
indeed I did already ask if any of the changes that I mentioned
could get really accepted for an official version - regardless of
how feasible some of the features may seem to some of those who
probably won't need that functionality in general.
Forgive me if I ask for such things BEFORE doing any significant
coding - but if you've read my last posting you'll notice that
this is a necessary precaution as soon as the actual development
work of a roject is tightly bound to another project with
-understandably- different priortities.
In fact, I did ask these questions because I have already made
some smaller changes for testing purposes and also to see how
easy it would really be to add a certain feature. Also, I am
about to investigate possibilities to add a basic XML-handling
mechanism to Nasal.
While the latter can fortunately be tested by means of
external code and does not require immediate changes
to FlightGear itself, things like the mentioned customization
of PUI elements do require to make direct changes to
FlightGear itself (at least as long as I don't want to
cut/paste all the necessary functions/classes...)
Well, on the other hand, the actual discussion was not even
about general plugins anymore, but rather specifically about
using Plugins to add Nasal commands - anyway ...
It isn't that your idea or view isn't good,
well, thanks - the discussion is finally getting interesting ;-)
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).
I see your point but on the other hand that wasn't my
intention either.
Also, it's then pretty unlikely for ONE person to come up with an
idea that is good enough to convince that many people at once: different
views, different attitudes and also different requirements would make that
_quite_ a difficult task.
And then again - IF there is such a thing that appeals to that many
developers/users at once it would certainly *NOT* be a candidate for a
plugin-based implementation but rather would really be added
directly into FlightGear, because many people would want to see
it there - AND NOT optionally available as a plugin.
Which I think is quite understandable.
So, while there are some some people who'd like to see the original
FliteTutor idea to be implemented and while I was even asked to
incorporate the whole thing directly into FlightGear, there are
certainly many other ideas that are more specific and which
would/should not that easily integrate into FlightGear.
In other words: this discussion is not necessarily about the idea for
a project that _I_ have , cause I do think that it should
be possible to create most of the basic functionality using Nasal,
hence I could very well live without a generic plugin interface - even
though I would then be "bound" to FlightGear itself regarding the
actual implementation of the necessary Nasal/FGCommand bindings.
So, try to see the plugin idea as a different issue, which is
not connected to anything else that I've mentioned here so far ;-)
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.
Actually, I don't intend to come up with dozens of new ideas just to
figure out what exactly you folks like and hence what would be a
suitable purpose for a plugin interface ... :-)
I mentioned this already: I am merely making suggestions - so, it
doesn't matter that much to me if there'll be a more powerful
plugin/script interface or not.
I think such a project needs contributions/feedback, and nothing else is
it that I am providing here - it's perfectly acceptable and
*normal* that such feedback is discussed controversially.
Actually, that's what I intended by bringing up that topic.
These are all ideas that I came up with because of a concept
for a possible project, but also because of some experience
with other flight simulators - no matter whether commercial
or not.
I did already mention on the FT-webpages that I would continue
making some development attempts absolutely independet from
any support (or lack thereof), cause I think that such an
application does have a legitimate purpose and I would not
want to give up before making any attempts at all.
Regarding the ideas for a plugin interface this whole issue is
a bit different, as it would certainly affect FlightGear
more aggressively - at least if it is supposed to be laid out properly.
So, from my point of view it would be pointless to make any
significant coding attempts in that regard simply because I
wouldn't know if all the work gets ignored in the end.
That's a possibility I certainly want to circumvent for
understandable reasons.
Something like a plugin interface would not be a separate
project anymore and would require MUCH more talking/desiging
with the FG core developers.
So, this would also cost a lot of YOUR time.
If you don't have the patience
lol, do I make that impression ? :-)
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.
To be honest, I have already made some changes to my local copy of
FlightGear in that direction, though not explicitly a general plugin
interface but rather a very basic library loading mechanism to allow
for external development of the actual code for my ideas related to
FliteTutor - mainly independent from the FlightGear sources itself,
this for several reasons:
- On the one hand I can keep my code separated from
FlightGear *easily*.
- I don't need to rebuild FlightGear for every single
line of added code anymore
- It's easier to remain in sync with the CVS
But actually I don't consider this a sign of impatience, but rather
as an attempt to simplify the development and evaluation of the
existing possibilities.
So, this is currently only about keeping things apart while
creating some basic test code.
Back to your suggestion: I certainly would not mind posting a link
to a modified version of FlightGear to illustrate a basic plugin
interface, but as I mentioned above, I definitely would not want
to put much work into it before having an agreement of some sort.
The drawback being of course that such version of FlightGear would
require a complete rebuild of FlightGear - which takes a while,
so maybe it should be implemented as a CVS branch of the original
sources or something like that to allow easier compilation with
reduced compile time, because one could simply sync a local
FlightGear build tree copy to a different branch and revert
these changes afterwards (if necessary).
Hence my suggestion would be to extend my current copy with
support for dynamic library loading a bit more for illustrative
purposes and make this then available ...
But this would then of course be limited to some very basic
requirements and would not become a fully featured plugin
architecture.
---------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
