"Rob & Lori" <[EMAIL PROTECTED]> wrote in messageActually 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. ;)
news:[EMAIL PROTECTED]
brock wrote:
----- Original Message -----
From: "Rob & Lori" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
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!! ;>
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.
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.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 this is what everyone thinks Boost.GUI should be used for, then you're right.[...]
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'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. ;)[...]
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.
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!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. ;>
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. :/
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.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.
Hehe, you're killing me man, you really are. ;)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. ;)
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.[...]
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.
Rob Geiman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
