-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcelo E. Magallon Sent: Saturday, January 01, 2005 2:12 PM To: boost@lists.boost.org 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> :)