|
From: Dirk R. <di...@in...> - 2007-05-28 00:09:34
|
Hi Dan, Daniel E. Shipton wrote: > Excuse the top posting.. ? > I think that a better option would be to get rid of all the legacy > code for 2.0. Having just finished a big project that was using 2.0 I I assume it was using 1.0 (actually I know it was ;). > can tell you that trying to make your old 1.x code work with 2.0 is a > huge pain...and frankly not worth the hassle. > > A better option would have been to spend the few days to port > everything to 2.0 In the end I probably spent just as much time > fighting all the deprecated interfaces, OSG_1_COMPAT, and deprecated > properties to make them work properly. Can you elaborate on that a little bit? What didn't work, what problems did you have making it work with the compats defined? > Having one codepath is really in everyones *best* interest. There are > to many permutations to test thoroughly as it stands. > > So here are my suggestions: > 1. Get rid of enable_osg1_compat > 2. Get rid of disable_deprecated > 3. Get rid of enable_deprecated_props All of those should be one define, to keep things simple. > 4. Write a GOOD porting guide that covers how to change the 1.x code > into 2.0 code Can you give us some hints what that means? Right now I think you're the one with the most experience in that regard. > Having reflected my last project I also have some other suggestions. > > 1. Get rid of the RenderAction (yet another code path) Agreed. > 2. Documentation for 2.0 creating,editing FC's in 2.0 (ex. FClusterLocal!) FCClusterLocal is actually a big improvement over 1, where those were hard-coded into the Cluster lib. Why you ran into those problems is an open question (did you open a ticket for it BTW?). Yours Dirk |