RE: [boost] Re: [gui] The Big Picture [and wxWidgets]

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-01-03 17:36:52

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Marcelo E. Magallon
> Sent: Saturday, January 01, 2005 2:12 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: [gui] The Big Picture [and wxWidgets]
> 
> On Sat, Jan 01, 2005 at 01:50:28PM -0700, Brian Braatz wrote:
> 
>  > I will end my thoughts here with the (repeated) suggestion that
>  > making a thin layer above the current WxWindows will allow for a
>  > Boost.Gui in a short timeframe that has an incredible API
interface.
> 
>  Ugh... yet another layer.  wxWidgets has enough of those already :-\
> 
>  Just to understand you, what would be the purpose of such a layer?
> 
>  Marcelo

[Brian Braatz] 
My thoughts:

1- Make a layer that hides WxWidgets- but uses modern template
techniques to present an "new" interface (which uses WxWidgets for an
underlying implementation)
2- Allow access to the underlying WxWidgets if the programmer so desires
3- Eventually, you will have built a new "api" for accessing WxWidgets
4- WxWidgets becomes an underlying "personality" plugged into boost.gui,
it would should then be possible to develop a personality for MFC, OWL,
Foxtrot whatever, either as a part of Boost.gui, or as something a user
of Boost.gui may wish to do on their own.
5- Eventually, a "boost official" personality could be developed to swap
for WxWidgets

This has the advantages of:

1- Get something going quickly
2- can attack the problem one piece at a time
3- gives boost.gui developers an ability to pick and choose which
problems they solve and which they do not.
4- addresses the problem of having a STANDARD interface for common
functionality (boost.gui), but allowing the user to use whatever gui
framework they wish. This gives an application developer the flexiablity
to use the boost.gui layer for 90% of their code, and then "drop into"
the underlying framework if there was something their specifically they
wanted to use.
5- It is much easier to scope out "common functionality" and focus on
that, instead of burning resources on trying to do EVERTHING at once

Example:

I would want to use boost.gui for my MFC app, but I might want to use
the Internet Explorer control for one screen in my app. I can now write
MOSTLY standard code (boost.gui) and then specialize (Mfc IE class)
where I care to. As an app designer, though I have the choice as opposed
to an all or nothing.

This is similar to the concept that that we all like C++, but some folks
run OSX or Windows or Linux. 

I can use BOOST in my app for most things, if I want to use the Win32
thread pooling API, I can, or I may choose to use Boost.Thread.

Motivation:

        Choice of frameworks is kinda like choice of computer language.
It can be personal, political, or just what you are used to. By
positioning boost.gui in such a way as to be open to all categories, not
only will it be easier to establish a standard, it will be easier to get
people to USE boost.gui. I believe it is better for boost.gui to be
something that brings all these pieces together instead of being "Yet
another gui library".

</2Cents> :)