Hi Marco,
Add a proxy in each wrapper could be a good solution, but application
(like osgDesigner) probably needs more flexibilty in the wrapper managment.
If a wrapper load another wrapper directly, the current flexibility will be
lost. So we must add a DynamicLibrary class (or similare component) and a
WrapperRegistry to store DynamicLibrary objects. I explain it later.
The first Miguel's problem is that he could not create a instance of
osgProducer::Viewer without the osgGA wrapper loaded.
I see no reason for this, osgProducer::Viewer is reflected and the
ObjectInstanceCreator<osgProducer::Viewer> is avalaible.
The limitation caused by the unloaded osgGA wrapper is the unaccess of
osgProducer::Viewer's sub-class' properties and methods.
Isn't it ?.
The load and unload of each wrapper must be managed by a class; this allow
the user to keep a hand on the wrapper (in osgDesigner we use a
WrapperManager) This feature is not allowed by osgIntrospection. If a
wrapper could load another wrapper, we must add a generic way in
osgIntrospection to manage load and unload.
see a example on an Unix platform:
1) application request load of wrapper "osgProducer" to
osgIntrospection::WrapperRegistry
2) osgIntrospection::WrapperRegistry load the "osgwrapper_osgProducer.so"
(note the convertion of wrapper name in a specific plateform file name, like
in the osgintrospection example)
3) "osgwrapper_osgProducer.so" request the load of "osg", "osgGA",
"osgUtil", "osgDB", "osgText" to osgIntrospection::WrapperRegistry
4) osgIntrospection::WrapperRegistry load the "osgwrapper_osg.so",
"osgwrapper_osgGA.so", "osgwrapper_osgUtil.so", "osgwrapper_osgDB.so",
"osgwrapper_osgText.so"
5) ... use osgIntrospection
6) application could unload and reload a wrapper if it's need
unload an unused wrapper (with or without its
wrapper dependancies)
request a list of wrapper's name which is
loaded
resolved dependancies of all wrapper (load the
dependant wrapper if it's not already done)
...
7) ... use osgIntrospection
In brief, do a plugin system ...
Currently, unload wrapper is dangerous and cause a segfault no longer after
the unload. I didn't explain the problem here because this is not a small
explication and this is not the topic. A plugin system could solve this
problem, but it must manage dependency between wrapper and which reflector a
wrapper declare (this could solve the namespace reflection problem too).
The unload and managment of wrapper could not be used in a osg binding
project and an automatic wrapper dependancy loading system is a good
solution, but an editor like osgDesigner need this to allow the user (or any
wrapper developper) to do it's own wrapper, load it, test it, unload it,
modify it , reload it, ...,
Marco, Have you start a new design of osgIntrospection ? If yes, are you ok
to do an open discution on it? I have other request more specific to an
editor project than a osg binding project.
For the name convention, "osgwrapper_" for suffix and ".dll" or ".so" or ...
for prefix is a good thing.
Do you want allow the user to load a wrapper without this naming convention?
If yes, just add a function in WrapperRegistry to load a path instead a
name.
Marco, you are the project leader of osgIntrospection so this is your
decision.
Best Regards
David Callu
2006/11/16, Robert Osfield <[EMAIL PROTECTED]>:
Hi David and Marco,
For stepping in an spotting the real cause and potential solution.
From an OSG perspective I'm happy for osgIntrospection to have helper
functions to assist OSG apps. Perhaps the naming library convetions
could be made default along the lines that the OSG uses, but have this
customizable by client applications.
I'm no expect in osgIntrosepction so I'll defer to you guys to decide
on the way forward.
Robet.
On 11/16/06, Marco Jez <[EMAIL PROTECTED]> wrote:
> Hi Robert, David, Miguel.
>
> As pointed out by David, the problem is not a compile-time dependency,
so
> there is no need to modify genwrapper.conf. Instead, the problem is an
> unsatisfied run-time dependency between wrappers, which has never been
faced
> before. Partly, this behaviour is by design, partly it's not. If you're
> confused enough, I'm going to explain it better in a moment. :-)
>
> osgIntrospection was designed to be totally independent from OSG, and in
> fact it is. One could strip osgIntrospection off OSG without much
effort,
> and this presupposes a certain degree of genericity of the
osgIntrospection
> code. This requirement of genericity is what prevents osgIntrospection
from
> knowing how to load wrapper plugins, because the details of each wrapper
> (the file name and location, for example) are only known within the
outer
> application domain (the OSG domain in this case). In fact, you usually
load
> introspection wrappers by calling functions that are *not* defined in
> osgIntrospection.
>
> Wrappers that reflect OSG classes are, on the contrary, aware of OSG and
its
> classes (it couldn't be otherwise). So, the best place where dependency
> between wrappers could be specified is in the wrappers themselves.
Without
> thinking too much, a possible solution would be to place into each
wrapper a
> global variable of some proxy class that automatically loads dependent
> wrappers when the DLL is loaded. Genwrapper could be patched to do that
> automatically I believe.
>
> Some could argue that this genericity (btw, is "genericity" actually an
> english word?) is not required, and that osgIntrospection should be made
> OSG-aware. This would give osgIntrospection the means for loading
wrappers
> dynamically just as osgDB loads reader/writer plugins on demand. Well, I
> think this would be a reasonable change, even though it would force
external
> projects that use osgIntrospection to be conformant to a certain naming
> scheme and file-level granularity for introspection wrappers.
>
> Thoughts?
> Marco
>
>
> ----- Original Message -----
> From: david callu
> To: osg users
> Sent: Thursday, November 16, 2006 1:59 PM
> Subject: Re: [osg-users] osgIntrospection Problems
>
>
> Hi Robert, Hi Miguel
>
>
>
>
> 2006/11/15, Robert Osfield <[EMAIL PROTECTED] >:
> Hi Miguel,
>
>
> On 11/14/06, Miguel Escriva < [EMAIL PROTECTED]> wrote:
> I have a problem with osgIntrospection Wrappers. There are no
dependencies
> between wrapper libraries.
>
> For example, imagine this scenerio:
> 1.- load osg wrapper
> 2.- load osgProducer wrapper
> 3.- Create a instance of osgProducer.Viewer
>
> BOOM! A exception is throw: (type `N5osgGA16GUIActionAdapterE' is
declared
> but not defined)
> The exception happens because osgGA wrapper is not loaded. I think
Producer
> wrapper should depend from osgGA wrapper.
>
> Thanks for the notification. I have modified the
genwrapper/genwrapper.conf
> file to include osgGA in osgProducer link line, and uploaded the new
> genwrapper to wiki:
>
>
>
> Robert, In the genwrapper.conf you do :
>
> configure library "osgProducer"
> dependency win32-debug "Producerd.lib"
> dependency win32-release " Producer.lib "
> - dependency unix
> "-losgUtil -losgDB -lProducer -losgGA -losgText"
> + dependency unix
> "-losgUtil -losgGA -losgDB -lProducer -losgGA -losgText"
> end
>
> so add the -losgGA. But it is already in the osgProducer line.
>
> To solve the Miguel problem, you must include the -losgwrapper_osgGA
line,
> but this create a dependance between wrapper
>
>
> First, I think is not the good way.
> 1) If osgwrapper_osgProducer didn't need to osgwrapper_osgGA to compile
or
> run well, there are no reason to link osgwrapper_osgProducer with
> osgwrapper_osgGA.
> 2) I think an exception is an run time error (error that can't be
handle at
> compile time), that the program must catch and give to the user, but
that
> only the user can resolved.
> This could be a good way to say to the user, that the osg file he
> loading with osgViewer, require an OpenGL version or extension
unavailable
> on the system. Then the user could continue or stop the application.
> With the wrapper, you could say to the user what is the problem (
try
> { ... } catch(osgIntrospection::Exception & ex) {cout << ex.what() <<
> std::endl; }, and he must solved it
> or try to parse the ex.what() message to search the wrapper you
must
> load to solve the problem.
> 3) If we do dependancies between wrapper, we must do it for all
wrapper.
> And the only one wrapper indepandent of another wrapper will be the
> osgwrapper_osg.
>
> Secondly, perhaps the problem is not in the build dependancies but in
> osgIntrospection.
> The wrapper must give the possibility to create, use and delete (when it
is
> possible) an object that it reflect.
> If the object you want create is not defined, you can't create this only
> because the reflector which do a "new Class" is not loaded.
> But if the object you want create is defined, you have the reflector and
it
> can do a "new Class".
> If the class that you create is defined but the sub-class is not, you
can
> use the class methods and properties, but not the sub-class methodes and
> properties.
> So If the behavious described is the good, there are a problem in
> osgIntrospection.
>
> Marco's help is need here to confirme or not this.
>
>
>
>
>
>
>
>
> http://www.openscenegraph.org/osgwiki/pmwiki.php/Tasks/GenWrapper
>
> I have also updated the osgWrappers and checked them into CVS. These
> changes should fix the above problems, let me know if it doesn't.
>
>
> I have another problem with getAllMethods method in Type class. For
example
> you can get a Type for osg::CollectOccludersVisitor and then call
> getAllMethods(), the result is a exception. The reason that
> osg::CollectOccludersVisitor inherits from osg::CullStack and CullStack
is
> not exported by osgIntrospection.
>
>
> There exists a src/osgWrappers/osg/CullStack.cpp, so it would it seem
that
> osg::CullStack has been exported.
>
>
> in the genwrapper.conf, there are a line for CullStack:
>
> suppress reflector "osg::CullStack"
>
> So the osg::CullStack is not reflected. I remove this line and try to
> understand where is the problem with this reflector.
>
> see you soon
> David
>
>
>
>
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
