RE: [boost] GUI/GDI template library

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-06 12:33:16

--- Brock Peabody <brock.peabody_at_[hidden]>
wrote:
> I wonder how much we will have to redo when we add
> in support for say
> Mac Os X or another *nix API.  Is it going to be too
> complex to develop
> a single underlying code base that works on all of
> them?  Would we be
> better off developing separate implementations for
> each GUI API?  Do any
> of you with cross platform development experience
> have any opinions
> about this?

Good question!

> 
> Here are the two possibilities as I see:
> 
> Method 1 - common underlying representation method
> 
> layer 1 - target GUI API
> 
> layer 2 - low level GUI API interface wrapper. 
> There is one
> implementation of this wrapper that compiles for all
> target platforms,
> using standard cross-platform development methods. 
> This layer may be
> private to boost (in namespace detail).
> 
> layer 3 - high level boost GUI API.  This is the
> public interface to our
> GUI 'domain specific sublanguage'.  It is
> implemented on top of layer 2.
> 
> 
> Method 2 - N implementations
> 
> layer 1 - target GUI API
> 
> layer 2 - high level boost GUI API.  This is
> implemented directly on top
> of the target GUI API, for each target API, except
> for the parts of the
> sublanguage which can be implemented in terms of
> other parts of the
> sublanguage.
> 
> 
> Method 1 pros
> 
> - maintenance can be done in one place
> - possible sharing of code amongst implementations
> - layer 2 might eventually become another part of
> the public interface
> at a lower level (like phase (3) in Beman's first
> post on this topic).

To the method 1 pros list:
- More user friendly. If the user implements the layer
1, she can use the library with her custom GUI
platform.

> 
> Method 1 cons
> 
> - complexity.  This is my main concern.  I don't
> know if we can
> implement a low level API that works for all GUI
> APIs.
> - we have to implement all intended targets at once.
>  Adding new targets
> affects code referring to existing targets

Sorry why does adding new target affect code referring
to existing targets? Could you give an example?

> 
> Method 2 pros
> 
> - implementation for each target is relatively
> straightforward and self
> contained
> - we can add support for targets at leisure without
> affecting existing
> targets
> 
> Method 2 cons
> 
> - if changes need to be made they will have to be
> made across N code
> bases
> - possible redundancy in various implementations

to the the Method 2 cons list:

- The user won't be able to use the library on top of
a custom GUI (like some requested) unless she writes
it from scratch.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com