RE: [boost] GUI/GDI template library

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-08-06 17:26:33

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of E. Gladyshev
> Sent: Wednesday, August 06, 2003 3:42 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
> 
> 
> --- Brock Peabody <brock.peabody_at_[hidden]>
> wrote:
> > I think now we need to decide which
> > *nix GUI API to use
> > and get started on a proof of concept.
> 
> I am currently working with win32 only. I can take
> care of this one. I think it'll be nice to have
> support for X as well.
> 
> > Maybe we should decide which elements of the layer 1
> > API to implement
> > first.  What do you think about: window, button,
> > edit, and static_text?
> > We can get a simple sub-language running on top of
> > those few controls
> > quickly enough.
> 
> I think it'll be nice to include a container like
> control like list/tree control to demonstrate how they
> could be linked to STL iterators.

Agreed.  I vote for the list control then, I think it's a little more
straightforward.

> 
> I was thinking about starting to work on on the layer
> 2 design first. The idea is to design the layer 2 the
> way we'd like it to be first. It'll provide a set of
> natural requirements for layer 1.

Agreed.  I think the layer 2 interface is where we're going to need the
most feedback from other boosters too.

>  Using these
> requirement, we'll try to design the layer 1
> traits/polices. Then we review it and decide whether
> it could be implemented on win32/X platform. If it
> doesn't work, we'll revisit the layer 2 design again
> and correct the layer 1 requirements. I'd suggest a
> recursive design procedure. :)

Agreed. 
> 
> I think we'll have to establish some basic
> design/implemntation polices/idioms.
> 1. For instance how we handle memory allocations, are
> we going to use std::allocator idiom or just
> new/delete.
> 2. Is the library thread-safe or not.
> 3. Event handling polices (send/post, etc.).

I think we're going to have to allow the users to specify traits at
layer 2 at least.  You could specify things like allocators and and
default behaviours.  Maybe we could even use some sort of named template
parameter mechanism since there are so many different things that can be
specified.  I don't think we need to worry about traits in the first
cycle or two of our recursive (I thought they called it iterative?)
design though.

(2) I'd say the library should be no less thread safe than the
underlying API.  Some APIs may be inherently thread-unsafe (MFC for
instance).

(3) Use function objects ala boost::function<>?