[boost] Re: UI++ [was: GUI sublanguage;Re: GUI/GDI templatelibrary]

From: David B. Held (dheld_at_[hidden])
Date: 2003-08-09 01:53:18

"Rob & Lori" <Rob.Lori_at_[hidden]> wrote in message
news:3F342ED8.1060309_at_buckeye-express.com...
> 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
> >templatelibrary]
> >[...]
> > > 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.

The question is, *should* the library be designed with DirectX
compatibility as a goal?  Not a line of code has been written, and
already we're trying to throw in the kitchen sink!! ;>

> > > 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.

What if, instead, we provided a "Layer 0" in which all this custom
widget business could be implemented by those with the time and
resources to do so?  So what would happen is that Layer 1 sees
a *native GUI API*.  It makes calls into that API, and essentially
provides a more or less platform-independent C++ interface to it
that adds whatever nice features we deem appropriate.  So it
seems to me that the Layer 0 could be WinAPI or maybe Qt or
Xlib or Boost.Widget.  Would that make it sufficiently practical
to then port the library to DirectX?

> [...]
> 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.

But I think the point is not for Boost.GUI to *provide* a GUI, but
rather to provide a *C++ interface* to a GUI.  Writing a GUI is
hard enough.  Writing a C++ interface to a GUI is hard enough.
Let's not try to bite off more than we can chew yet. ;>

> [...]
> 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.

I think this should be accomplished with the Boost.Widget library,
which it sounds like you are volunteering to help write. ;>  Then
you will have your JVM competitor with which to provide
skinnable widgets.

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

Yes.  And they should be in Layer 1, which *presumes* an extant
GUI layer that does the actual dirty work of drawing and such.
This is the level at which we see an edit box in GUI Y and say:
"This is an edit box, just like on GUI Z".  And so that is where the
abstraction should kick in, and the library unifies the different
concrete types of edit boxes into a consistent C++ interface
that hopefully interacts naturally with standard C++ containers
and algorithms.  However, who sits down at a computer and
says: "Ah...the 20 pixel high edit box with rounded borders and
3D drop shadow.  Just like on GUI Z"?  That doesn't sound like
the right level of abstraction in which to write Boost.GUI.

> 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.

I think that's a *good* thing.  Why doesn't the OS let you change
it?  We'll use whatever excuse they're using. ;>

>  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.

Or, they'd have to create a widget set for Boost.Widget, and
then it would be portable.

> 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.

Sounds like you have a pretty good handle on the basic design
for Boost.Widget. ;)

> [...]
> 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.

And it's my opinion that building controls from scratch is the
wrong level of abstraction for a doable project which provides a
consistent C++ interface to GUIs.  One of the great things about
C++ is that it knows it is a computer language, and not an OS,
so it doesn't pretend to be an OS (like, *ahem*, other "modern"
languages).  Using the native GUI, widget set and all, just *feels*
like the "C++ Way".  C++ doesn't tell you how your terminal is
supposed to behave, so why should Boost.GUI tell you how your
widgets behave?  Instead, C++ says: "Let it be", and so should
we. ;>  If we want to create a universal GUI, let's do so in another
library, and make sure that the two can play together nicely.

Dave