Hi Mattias,
I don't really have any strong suggestions for the name.
ExternalData/UserData/ExtraData/PluginData, I don't really know.
Robert.
On 9/26/07, Mattias Linde <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> When reading your reply I can agree that putting something like ColladaOptions
> into osgDB might not be the best thing to do. My thoughts when writing the
> code
> was to change as little as possible and still be able to get access to
> plugin internal stuff and to have the option to pass in another pointer to be
> used.
>
> I'd think adding a std::map to ReaderWriter::Options and some methods to
> operate
> on it (set, get, remove - anything else needed?) would be better than just a
> userdata object.
> But I'm not sure what would be an appropriate name for it. I don't think
> ExternalData
> really describes it since it can be used to pass back data from the plugin.
>
> / Mattias
>
> On Wed, Sep 26, 2007 at 11:51:29AM +0100, Robert Osfield wrote:
> > Hi Mattias,
> >
> > Thanks for the changes. I have done a quick review and am not happy
> > with placing a plugin specific data structure like ColladaOptions into
> > a general purpose library like osgDB. Once one starts going down the
> > road in placing plugin specific data structures in osgDB you'll end up
> > on a slippery slope of messy and difficult to maintain library.
> >
> > I don't have a solution to this problem yet. Perhaps a general
> > purpose UserData object for passing in/out void pointers would be
> > sufficient. Or perhaps one could provide a
> > std::map<std::string,void*> in ReaderWriter::Options base class for
> > passing in and out different types of data, i.e.
> >
> > options->setExternalData("DAE",dataPtr);
> >
> > DAE* daePtr = (DAE*)options->getExternalData("DAE");
> >
> >
> > The aim must be to keep things with a very loose coupling in osgDB,
> > and to make any extensions general purpose.
> >
> > Robert.
> >
> >
> > On 9/26/07, Mattias Linde <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I've attached some suggested changes to the collada plugin:
> > >
> > > I've added a ColladaOptions class which can specify which DAE instance
> > > should
> > > be used. If no options are used when osgDB::readNodeFile is called the
> > > plugin
> > > will work just as before.
> > > (include/osgDB/ColladaOptions and src/osgDB/ColladaOptions.cpp in the
> > > tarball)
> > >
> > > With the colladaoptions one can use an "external" (as in outside of osg)
> > > dae-instance which possibly already holds parsed data or an internal
> > > instance
> > > (the plugin creates one unless it has already done so). The options object
> > > also makes it possible to get a pointer to the dae instance so it can be
> > > used outside of osg.
> > >
> > > src/osgPlugins/dae/ReaderWriterDAE.cpp have been updated to use
> > > ColladaOptions.
> > > daeReader.h and daeWriter.h have one minor change each, a ; was removed
> > > after the
> > > namespace end } which caused a warning.
> > >
> > > CMakeLists.txt have also been updated to link with collada_dom_shared and
> > > collada_dae_shared (if not under win32) instead of collada_dom and
> > > collada_dae.
> > > This is because of collada-dom now supports building shared libs under
> > > linux
> > > (been tested on OS X aswell). Linking with the static libs in the plugin
> > > can (and have) cause problems if the application using osg links with
> > > collada-dom
> > > libraries.
> > >
> > > / Mattias
> > >
> > > _______________________________________________
> > > osg-submissions mailing list
> > > [email protected]
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> > >
> > >
> > >
> > _______________________________________________
> > osg-submissions mailing list
> > [email protected]
> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
