Hi, On Sat, 2007-08-25 at 20:34 -0500, Dirk Reiners wrote: > Hi All, > > after trying to clean up the lib deps a bit I understand better what the > problem > is. ProxyGroup needs SceneFileHandler and forces Group to depend on FileIO, > and > obviously FileIO depends on Group. That's kinda annoying...
aeh I'm confused. SceneFileHandler is in System (for exactly this reason). And nothing else should depend (and does) on FileIO. So if a group uses SceneFileHandler it still only depends on System not on FileIO. > I see a few options: > > - Split off the base pieces that are visible from the outside and put them > inside System. That's the current version, but it breaks down if those pieces > need other libs (which can happen fairly quickly, like FileIO needing > GraphOps > needing Geo needing pretty much the whole thing...). Again confused here FileIO is different from System so why does FileIO needing GraphOps needing Drawables make any difference for System ?? Exept that there is a bug in GraphOps, which was not factored correctly to the new library structure. If you do it right and take out the pieces SceneFileHanlder actually needs you have the high-level glue interface that belongs to SystemLib. Everything else goes somewhere else (Util). So you don't get additional dependencies for SystemLib. So I don't see the breakdown (maybe yet)? > - Split the libs more finely into basic pieces and the parts that need higher > level functions. For a node to need FileIO is a fairly unusual thing, IMHO. Unusual for sure, actually I would go as far as it never ever should happen and if it happens something in the design is really wrong. > The danger is very finely split libs that are hard to understand. I see that > danger > anyway, if we want to get to a point where whatever depends on an external > lib > is in a separate OSG lib, so we will need to have a reasonable way to handle > that. Having info which library a class is in in the docs will go a long way > towards that. I opened a ticket for a way to automate that. > I'm tending towards 2. Splitting the components into base and non-base pieces > seems a bit hard to keep functional, having cleanly split pieces smells > better > to me. For my current problem I would open a new lib OSGComplexNodes to > contain > ProxyGroup. I still don't see the difference, except probably reorganising the directory structure. Could out try again to put ProxyGroup into Groups, after I just fixed GraphOps it should work. Similar I don't see the need for Terrain or Points. I'm cleaning up some GeoClipmap Code right now and I did not ran across any problem that would prevent it from going into Drawable. So all in all I'm still not sure if there really is a problem or if it was just a porting bug ? gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
