Planned Changes

The roadmap regarding some of the planned changes in the CornerStone C++ SDK. This page does not cover planned additions, but rather the issues where we have found that the current design is not the best possible one.

Mostly the changes will be non-disruptive, and old functionality will not be removed. There are some exceptions to this rule, and if possible it makes sense to adjust the programming style so that future changes do not break your code.

Luminous::RenderContext as a Painting Utility

At the moment Luminous::Utils contains a collection of utility functions for rendering lines, circles, rectangles and other standard shapes with OpenGL. The use these features has been sightly painful, as the programmer needs to take the transformation matrix from the RenderContext object, possibly calculate antialiasing parameters, and then pass the information to the functions inside Utils. To simplify the programming work new rendering functions will appear inside the RenderContext, and not in the Utils. The old functionality remain inside Utils, so that old applications will keep compiling.

Schedule: The Luminous::Utils class is no longer expanded, and new functions go to the Luminous::RenderContext.

Implications: Old code will keep working, but as new drawing functions appear in the RenderContext, developers should use those, as it saves some work in the rendering process.

Protected Data Members Will Become Private

Currently there are many classes with protected data members. Many of these data members will be made private, so that child classes cannot access the parameters directly. This is done to enable us to do internal changes inside the widgets and other classes, without affecting the application programmers work.

Schedule: In the new classes there are no protected data members any more. The old classes (for example Widget and CSSBoxModel), will be updated later, at earliest in 1.1.2011.

Implications: To keep their code working with the SDK the developers should avoid the direct use of protected data members, and use the accessor functions instead. Code written with this approach will be compatible with future updates.

Adjust virtual functions processFingers and processHands

At the moment the functions processFingers, and processHands are in fact redundant, there is no practical reason to have two functions, instead of just one. Further, the argument lists for these functions is not 100% necessary as practically the same information is available in the member variables (hand & finger ids). How-ever, having the data in vectors is nicer than having it in the id lists that the member variable keep.

Schedule: The update strategy is being worked on.

Implications: The old virtual functions will be kept around, as a deprecated API, so that old code will keep working.