> I work out what you mean by remove spaces from subject line
> as I haven't noticed anything like sice. Could you give an example.
>
> As far as I know mailman doesn't modify the subject line save
> for prepending the [osg-users].
In the thread:
"[osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins
directory?"
Your first post in the thread looks like this in my mail client:
"[osg-users] Is it time that we have aOpenSceneGraph/src/3rdPartyPlugins
directory?"
I replied to that post, and I can see in my "sent" folder that the subject
looks just like yours, with only one space missing. But when the message
echoed back to my inbox, a second space was missing, so the subject appears
like so:
"[osg-users] Is it time that we haveaOpenSceneGraph/src/3rdPartyPlugins
directory?"
This all looks fine in your mail client?
I've attached both your original post and my reply. It will be interesting
to see if the attached message subject lines look correct to you in your
client.
-Paul
--- Begin Message ---
Hi All,
Following on from my earlier topic of discussion on OSG packaging
granularity and naming, and picking up on Andreas experiments with a
Firefox plugin, and Cedric's further dev of the Blender Python scripts
for exporting to .osg, and the other community activity on various
plugins for others tools, I feel it's worth discussing how we go about
coordinating and making it more accessible to end users.
Right now we have various projects that use the developed out in the
community that fit the role of plugins to other tools, like modelling
applications to provide OSG exporters, and plugins to browsers. Most
of the these projects will be maintained out in the community, may
have their own project websites, may have a single contributors, or
several, and may be dropped, then picked up by others further down the
line, or just sit annexed out on the wiki. This situation isn't too
much work for me as It means I don't need to spend time coordinating
or maintaining these works, but... often it looks like such projects
come and go in terms of support for latest versions of OSG, or latest
versions of the 3rd party applications, so I'd guess for many OSG
users/developers that aren't straight forward to pick up and use.
One possible solution might be to bring maintenance and distribution
of these 3rd party plugins directly into the core OpenSceneGraph
distribution in the form of a collection of src/3rdPartyPlugins
projects. Some of these might be compilable C++ code such as a
Firefox plugin, while others might be just a collection of scripts
that just need to be installed in a place that a modeller such as
Blender can pick up on. Custom Cmake installer might work well for
taking these built libs/scripts into the appropriate places, as well
as detecting dependencies and only building/installing what you have
supported on your platform.
Another other solution would be see if we can coordinate the
management and software/build and distribution so that a similar
pattern is used by all the various 3rd party plugin projects - to make
it easier to OSG users to navigate to, use and contribute to them.
If we were to got the direct integration route, we'll have to be
careful about how we manage the integration of the sources, testing
and on-going development in such a way as not to increase my own
workload. Strategies to mitigate this workload would be to prepare
the bodies of work so that they fit seamlessly into the OSG build
system/directories structure, so it's just a straight forward task of
my pulling in the software, then once they are ready then integrate
into core OSG, but not before this. One needn't have a perfected
software before integration, but it would at least need to fit
comfortably and non-intrusively into the OSG build. A way of doing
this prep work would be for us to use the branches section of the OSG
svn repository in similar way to how Jeremy and Cedric have been
prepping osgWidget and osgAnimation.
If you do have software that you feel is a candidate for being part of
3rdPartyPlugins collection then please outline what it is, what files
go into it, how it's built, how it might fit into a CMake build
system, what its portability and dependencies are.
Another area I do wonder about is whether we'd be able to share some
components of software between some of the 3rdPartyPlugins as well, I
know that there is Python script for Blender for exporting .osg files
right now, and that Maya supports Python, so I wonder if a .osg file
build class could be written in Python that is shared between both
plugins, and with each just using its own glue code that uses this
builder class to do the OSG output.
Thoughts? Recommendations?
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--- End Message ---
--- Begin Message ---
> One possible solution might be to bring maintenance and
> distribution of these 3rd party plugins directly into the
> core OpenSceneGraph distribution in the form of a collection
> of src/3rdPartyPlugins projects. Some of these might be
> compilable C++ code such as a Firefox plugin, while others
> might be just a collection of scripts that just need to be
> installed in a place that a modeller such as Blender can pick
> up on. Custom Cmake installer might work well for taking
> these built libs/scripts into the appropriate places, as well
> as detecting dependencies and only building/installing what
> you have supported on your platform.
This seems to be the closest to what we have now, for example, I don't build
the collada plugin because the collada dom isn't on my system and cmake
doesn't find it. Such a system gives you (Robert) the choice of maintaining
this code or not, as you see fit, but ultimately it is up to the community
that is using it and has the necessary dependencies. Another benefit is it
allows OSG to continue to grow and develop new support functionality, while
not burdening people using the "traditional core" OSG with having to find a
bunch of dependencies for code that they ultimately will not use.
The only conceivable downside (that I can think of) is that new users might
attempt to use some code that has fallen into a state of disrepair, giving
them a bad out-of-box experience.
-Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--- End Message ---
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
