RE: [boost] GUI/GDI template library

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-08-06 11:57:48

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Beman Dawes
> Sent: Wednesday, August 06, 2003 9:36 AM
> To: Boost mailing list
> Subject: Re: [boost] GUI/GDI template library
> 
[...]

> Given the major differences between underlying GUI API's, your really
need
> to be developing in parallel for both Windows and Linux right from the
> start.

OK.  Does anyone have any suggestions as to which would be a good GUI
API to use under Linux?  Is there one I can develop with under Cygwin?

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?

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).

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

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

Comments?

Brock