Hi Marco,
2006/11/17, Marco Jez <[EMAIL PROTECTED]>:
Hi David,
I understand your needs of keeping an hand on the loading/unloading
process
and I support the idea of having a wrapper management system.
I was thinking to implement an automatic on-demand loading mechanism that
also allows manual intervention if needed. The automatic part would work
much like osgDB, loading wrappers based on the namespace of the type you
request. For example, if you (or any other code) request information for
type "osgUtil::IntersectVisitor", osgIntrospection would automatically
load
the wrapper named "osgWrapper_osgUtil.dll" (or another name depending on
the
platform). This means the user will never need to load wrapper manually.
But
if manual intervention is required, the user can "subscribe" to
load/unload
events and be notified every time osgIntrospection needs to load or unload
a
wrapper, possibly replacing existing load/unload functionality with his
own
(or disabling it completely). Of course, forced load and unload will also
be
supported.
This is exactly what I want.
In osgDesigner, I use a boost::signal to notify the load/unload event.
Callback will probably best in OSG.
I try to implement a generic PluginManager framework in osgDesigner, but
it's not finish and i must see and try another plugin system to open my mind
and improve my skill. So I will be happy to work on the wrapper manager
system. I will try to design it me too.
As for the new introspection framework, I've started doing some experiments
but I have no concrete design yet. Anyway, the new framework will be
composed of several layers of abstraction, with the lowest reflecting
*only*
things that actually exist in the C++ language and with proper
conversion/lookup semantics. For example, "properties" are not a C++
feature
and so will not be supported by the base layer. Upper abstraction layers
will then be created to support features that don't exist in C++ and to
provide "shortcuts" and syntactic sugar to make things simpler for the
final
user.
really good idea !
The new introspection framework will be a separate, open-source project that
will eventually be integrated into OSG after proper adjustment of coding
style and dependencies. Actually, I think it would be better to keep it
separate from OSG and have OSG depend on it instead, because it is a
generic
library that is not directly connected to 3D graphics.
The framework will depend on Boost libraries. Not only because I like
Boost
so much, but because it contains exactly the constructs I need (such as
Boost.Variant, static visitors and the non-intrusive shared pointer
classes). Rewriting them from scratch when they already exist and are being
used (and reviewed) everyday by C++ gurus, just doesn't make sense to me.
Yes, of course.
With the powerful compile-time features of Boost the new introspection
framework will be much faster than osgIntrospection. It will probably take
longer to compile, however... But run-time performance is more important.
:-)
A compile-time data must be compiled, or do an extra-cost of memory and cpu
at run-time.
Of course, anyone will be able to join the project.
Did you do a wiki page on osg ?
a sourceforge project ?
somewhere to share information, reflection, implementation
...
About the genwrapper, it could be a good idea to avoid the doxygen
dependancy and use GCC_XML or boost::spirit to get the C++ class
Meta-Information?
Regards
David Callu
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
