"Rob & Lori" <[EMAIL PROTECTED]> wrote in message 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!! ;> > > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost