Hi Paul, > In that special case, I think it is OSG itself, which is breaking it's > interface, as the renaming done in the trunk breaks compatibility with > version 2.8.
Cedric will have decided that Status is the more appropriate name than State, the change would not have happened otherwise. Reverting this change won't be moving the API forward. While State may have been in 2.8, it was osgAnimation's first release and subject to flux, one typically can't get complex new components right first time so a little flux is expected till things settle on a solid API. Which really should name things in the OSG that makes the most sense for the class specifics, so I'm not keen to revert something that takes a step backwards. On Sun, May 17, 2009 at 7:35 PM, p...@tcl3d <[email protected]> wrote: > Also I think one should differentiate between "yet another 3rd party > library" and the X windowing system, which on Unix systems is more or less > an essential part of the operating system. X window system is a common components of desktop unix systems, but it most definitely not part of the operating system, something which would be fundamentally not the unix way. These days X mostly takes a back seat role for unix application development, with Qt, Gtk libraries etc. being used more often instead. The OSG uses X11 in osgViewer but this isn't as a public interface so no headers typically spill into application code. Solutions I can think are to add an #define PREVIOUS_Status Status, #undef Status, #define Status PREVIOUS_Status around the header, or to propose to Cedric change the enums to something like ActionStatus, TimelineStatus respectively. State is not really appropriate in this context, especially as the OSG itself has a State object so in OSG terminology it could confuse. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
