Hi Robert & all, Sorry for being intrusive in the topic, but will the new wrappers be selactable in CMake? For instance, if I only need osgGA wrapper, will there be an option to generate only this one, or will all be generated? Of course I can compile only the one I need but if it's selectable in CMake, it may be easier.
Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Robert Osfield" <[email protected]> a écrit : > HI Wang Rui, > > On Mon, Jan 25, 2010 at 9:04 AM, Wang Rui <[email protected]> > wrote: > > I believe the name ObjectWrapperManager and > > DeprecatedDotOsgWrapperManager is good enough at present. Maybe in > the > > future we could rename the first one to DotOsgWrapperManager and > > ObjectWrapper to DotOsgWrapper, to indicate that it's the > recommended > > .osg wrapper manager. > > Today I'll start refactoring the old DotOsgWrapper code so it isn't > so > tightly bound into osgDB::Registry. I would like to start > rationalizing on the headers as well - I don't want to break the > build > for current users, but I also want to have leass headers in osgDB > that > are for deprecated classes. I'll look at the present > deprecated_dotosg_wrappers to see which heads they use and avoid > modifying them as I do my tweak. > > > I just created two heritable OutputIterator and InputIterator base > > classes encapsulating the std::ostream and std::istream in the > osgDB > > namespace. And the binary and ascii successor in the osgPlugins/osg > > subdirectory. This new mechanism reduces the output/input classes' > > size and make them a little more agile, for instance, new XML > support > > could be easily added with a XMLStreamOperator header later. > > > > I also changed some osgDB header macrodefinitions from something > like > > H_DATATYPES to OSGDB_DATATYPES, to keep the code clean. > > > > All updated files are included in the attached tarball, based on > the > > latest SVN. Please have a look at them to decide if the > modifications > > are acceptable. > > I'll dive in now and give some feedback later this morning, possibly > a > bit too late for your day though... > > >> What I'd like to see is an approach like I took with the .ive > plugin - > >> it does mean slightly more code in terms of checking for whether > to > >> abort a read or write compared to using exceptions, but it'll be > less > >> code than a conditional compile approach which tries to do both, > and > >> far easier to maintain. > > > > OK, I'll take a look soon. The newly added OutputIterator and > > InputIterator, which focus on the stream I/O only, may also help > when > > checking and aborting user operations immediately if failed. > > Thanks. > > >> If you wanted could organize a little section on the history side > then > >> please feel free to ping me and others for it. With the nature of > the > >> project I think it's healthy to know that it's not been developed > by a > >> big corporation or a bunch of engineers from a different world. > > > > It would be useful, I'd like to think of that carefully. :) > > > > I'm working on the osgParticle and osgText wrappers now. After that > I > > would write a small tutorial to help the public quickly learn the > new > > format and join it if they want. All the work are hoped to be > finished > > this week. :) > > Excellent. I think once we have a few wrappers in place the rest > should be pretty quick to follow. It'll give me incentive to > complete > the .view format as well. > > Cheers, > Robert. > _______________________________________________ > 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
