Dirk Reiners wrote: > 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 probably just picking a personal knit here, but avoiding the copying of include-files, as per earlier discussion, could go a way good way towards this. I.e. system-files end up under OpenSG/System/, base files in OpenSG/Base, etc. > 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. There's probably more to go into that, maybe Terrain or a Point > node > that I will be working (or rather have somebody working on ;) fairly soon. > > Comments? Splitting the lib into "core" and "complex" nodes makes sense to me. I don't know enough about the big plan here to make any meaningful comment. However, I did mention before that splitting the FieldContainer and the Node/Core (Graphics) stuff makes sense to me as a user. Dunno if that is applicable or not. Cheers, /Marcus ------------------------------------------------------------------------- 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
