Re: [boost] [gui] The Big Picture

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-12-29 16:06:25

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