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

From: Rob & Lori (Rob.Lori_at_[hidden])
Date: 2003-08-09 09:05:12

David B. Held wrote:

>"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!! ;>
>  
>
Actually I used the DirectX example both because someone else brought up 
whether Boost.GUI could be extended to use it, and I believe Eugene said 
something along the lines of "why not"?  And of course, I happen dabble 
in games so it sure would help me out.  ;)

That being said, I don't think the library should be written with 
DirectX compatibility in mind, but rather to make it easy to port to 
other platforms, even ones they may not already have native GUI controls.

Either way we do it you could still use Boost.GUI with DirectX (which is 
a good thing) but it just makes it a LOT tougher if the programmer must 
create all GUI controls in DirectX first.

>>>>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?
>  
>
That would be a bare minimum way of doing things, I guess.  I mean, it 
definately makes it easier on us when creating Boost.GUI, but I'm still 
not sure it's the "right" way of doing things.  I mean, anyone who wants 
a GUI in DirectX or OpenGL must do all the work themselves, with the 
library just giving them an interface to interact with it, but 
apparently that's what everyone seems to want.

>>[...]
>>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. ;>
>
Well, if this is what everyone thinks Boost.GUI should be used for, then 
you're right.

>>[...]
>>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.
>  
>
I'm willing to help in any way with the project, although I already have 
my plate full with work and two other programming side jobs.  I think I 
need to just quit my job to help work on Boost full time or something.  ;)

>>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. ;>
>  
>
Well, Win32, for example, allows you to change this, but it requires you 
handling much of the drawing of the control manually.  There has been 
many times in my job that I've needed to tweak the way a control works 
to fit our project better.  But if we just use native GUI controls then 
users will be unable to modify this unless they dig down into the 
platform specific GUI code.  But then of course this makes the that GUI 
control platform specific!

So basically, if Boost.GUI uses the native GUI API then users either 
can't modify the way works or even create new controls without breaking 
the multi-platform support.

This may be acceptable to most of the programmers out there, but 
unfortunately it isn't for me.  :/

>> 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.
>  
>
Well, this may work for new controls, but what if the user wants to 
change the way an existing control looks?  He or she could create/use 
Boost.Widget to, say, change the color of the highlight bar in the List 
control from blue to red.  Sure, Boost.Widget could allow this to be 
easily changed, but the user would still need to create functions for 
changing this in the actual interface to Boost.GUI.  But if they add 
functions to that interface, then Boost.GUI would break when compiling 
using any Layer 0 classes other than Boost.Widget.

>>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. ;)
>  
>
Hehe, you're killing me man, you really are.  ;)

>>[...]
>>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.
>
Sigh, it sounds like pretty much everyone is of this same opinion.  Sure 
it makes a nice C++ interface, but it doesn't allow much extensibility, IMO.

Rob Geiman