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