Reece Dunn wrote:
Hi All,
We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required.
[...]
The question is how to make it easy to specify both lightweight and native UI objects.
Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible?
I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider:
I think notus is balancing the platform separation vs. integration issues very well. http://notus.sourceforge.net/ The idea was to define a platform abstraction layer. What is interesting is that the abstraction layer is *parameterized* by traits. Note: the actual platform-dependent implementation is NOT part of traits (the implementation is simply parameterized by traits). The platform is basically a data type that has to provide some interfaces much like type traits in STL. Note: traits can make use of native data types directly. Traits are obviously exposing the native data types to the rest of the library through predefined names. Traits allow the higher levels of the library to process native types *generically*. With traits, the user can easily customize an existing implementation of the abstraction layer or select a different implementation of the layer by simply using traits that an implementation of the layer exists for. Even if necessary, the user can write platform-dependent code at the highest level. For instance if for whatever reasons, the library isn't processing some of the native UI messages, the user can still implement platform-dependent handles at the high level. Eugene