
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener
Brian Braatz wrote:
(was RE: [boost] Re: GUI library - something to think about)
Both http://www.torjo.com/win32gui/save_dlg.html
and
http://www.litwindow.com/Library/Documentation/documentation.html
are extremely interesting.
What I see (just after taking a peek at both):
Win32Gui Interesting design No macros Looks tied to Win32Gui
LitWindow Also interesting design Does have macros Also sits on top of WxWidgets, but it looks like the WxWidgets layer could be abstracted out.
I propose that BOTH authors collaborate (on this list) to achieve
the
following:
* Combination of the best of both frameworks * Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation
No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go there, or have anything to do with supporting any other GUI implementation.
[Brian Braatz] PLEASE Re-Read my words. "> > * Combination of the best of both frameworks
* Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation"
If you have a good abstraction - then the ability to "plug in" the underlying implementation (through various mechanisms) means you are not tied to WxWidgets. This also means that conversely, you CAN take advantage of something in WxWidgets (or qt, or win32 or whatever) if you so desire. Boost::gui should not be trying for a kitchen sink approach (like WxWidgets or Qt), but instead would provide a simple and clean abstraction for common functionality. I will always (or frequently) have to write WxWidgets specific code or os specific code, but having a abstraction available from boost would mean most of my code would be portable across framework. I suggest a "first cut" would have a xwindows "plug in" and a win32 plug in, and potentially a WxWidgets and or Qt It is more than practical to have the boost gui abstraction cover the most common concepts. This not only makes it small and easy to implement, but also allows me to write directly to WxWidgets where it makes sense. This is what I would call "having balance" between a standard approach and still allowing for a developer to have the choice to take advantage of specific OS or gui framework feature as they desire. The fact that WxWidgets does not have "modern techniques" is a plus for boost::gui. The fact that WxWidgets is huge and covers a lot of things (and has been around for awhile) is a plus for them. A well designed "gui abstraction layer" would have the following properties: * move the technology of binding forward * Not try to be everything for everybody * allow for the choice of being able to write "boost standard gui code" vs taking advantage of whatever specific thing you are working with These principles, also have the advantage of placing a combination of ltwindows and win32gui in a spot where a combination of the two would in fact meet those properties. AND it would be accomplishable in a short timeframe. And that, is my point :)