Boost logo

Boost :

From: Rob & Lori (Rob.Lori_at_[hidden])
Date: 2003-08-08 18:14:32

brock wrote:

>----- Original Message -----
>From: "Rob & Lori" <Rob.Lori_at_[hidden]>
>To: "Boost mailing list" <boost_at_[hidden]>
>Sent: Friday, August 08, 2003 4:10 PM
>Subject: Re: [boost] Re: UI++ [was: GUI sublanguage; Re: GUI/GDI
>>However, this means that porting the GUI library to use, say, DirectX
>>would be MUCH tougher. Basically you'd need to create EVERY single GUI
>>control by scratch. If we instead created the controls by scratch in
>>the library just using an abstract draw rectangle, etc, then not only
>>would porting to DirectX would be simple, but it would also be much
>>easier to port to other platforms as well.
>Somewhere along the line someone is going to have to create EVERY single GUI
>control from scratch if you don't use native widgets. I don't want to be
>that someone :)
Well, if it's going to happen I think it would be best if the Boost
community does this as part of the library, rather than requiring it's
users to impelent this EVERY single time they want to use the Boost GUI
lib for a platform it doesn't already support.

>The thing is, if you are making an application that doesn't want native
>widgets - maybe you're making a game under Direct X - you probably want
>totally custom widgets (not boost widgets). If we are doing a good job of
>design - our layers are well seperated and encapsulated - it should be easy
>for you to use the higher level parts of the library on top of your own
>custom widgets. We would also need (as Mr. Bouchard suggested) a cross
>platform set of drawing tools.
I don't see the need for totally custom widgets for a Direct X game.
You may want a custom look and feel, which could be accomplished if the
Boost GUI lib was written is such away that you could change the 'skin'
to match a particular platform or even allow you to write a custom skins.

However, the general function the widget controls should be the same
whether for a game or application.

And this brings up another point. What if users DO want to change how a
control functions? If we use the native widgets, users are unable to
change this. Instead, they'd have to write platform specific code to
create an entirely new widget, and this must be done for all platforms
you would use this contorl in. However, if Boost imeplements controls
from scratch then all users would have full control over how a control
functions and it would be the same for all operating systems.

>>Also, keep in mind that building our own controls means we'll have
>>instant support for certain controls that may not exist in other
>>platforms, such as the common tabbed user interface, or dockable control
>>bars used in Visual Studio.
>Yes, we have to implement from scratch those controls we want to support
>when they are not on a given platform. We should concentrate on those that
>are common to all (targeted) platforms first, IMHO.
I agree that we should concentrate only on base widgets that are common
to all/most platforms, but keep in mind that sooner or later we'll need
to manually create controls for other platforms. Manually implementing
these controls for all platforms is a lot of extra work and leads to
issues where one "custom" control performs differently on different

>Think of it this way. Say we want to implement our own custom list control
>under windows. Do we make it look like a Win 2000 list control or XP?
>When the user finally upgrades to Win 200X your software looks immediately
>dated anyway.
I can understand that. We COULD design them in such a way that, when
using the Windows version, it would dynamically detect which operating
system the user is running and use the appropriate skin. Of course,
Windows XP allows users to use any type of style they want, so I guess
this really isn't a solution.

Either way we go there are pros and cons, it's just my opinion that
building the controls from scratch will give us much more control and
flexibility and make it easier to port to other platforms.

Rob Geiman

Boost list run by bdawes at, gregod at, cpdaniel at, john at