> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost