GUI Library Proposal for a Proposal
(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 * This would allow it to be in boost, but also be LEAN and not need another framework I believe that if you took both of your thoughts, and accomplished the above bullet points, not only would it be good for boost, but it would really mean that boost had something that was much cooler than what I see available from other (ahem) vendors. I.e. instead of making a boost library that just "provides a layer" over GUI things, this combination would be actually moving the technology forward. (they don't call it "boost" for nothing :) ) I ask that both of you gentlemen seriously consider my proposal. I would also offer to help in any way that I can as I think you both have some really groundbreaking ideas in the realm of GUI frameworks. (fingers crossed) Brian :)
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Torjo Sent: Wednesday, November 03, 2004 9:14 AM To: boost@lists.boost.org Subject: Re: [boost] Re: GUI library - something to think about
struct SomeSettings { int m_aMember; SomeOtherStruct m_struct; vector<string> m_strings; };
the neccessary data adapter definition which you must include in a source file looks like this
IMPLEMENT_CONTAINER_ADAPTER(vector<string>)
BEGIN_DATA_ADAPTER(SomeSettings) PROP(m_aMember) PROP(m_struct) PROP(m_strings) END_DATA_ADAPTER()
Sure thing, but how about *true* bindings? http://www.torjo.com/win32gui/save_dlg.html
(if you download the code, you'll find quite a few examples: examples/smart_dialogs)
Note that you can add correspondences directly to your data + validation code (no macros whatsoever).
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.
I propose that BOTH authors collaborate (on this list) to achieve the following:
Hi Brian, hi all. I am all for collaboration. The Lit Window Library is a high level approach to UI coding. This is not yet apparent since the real stuff is still missing. An upcoming article will delve deeper into this. The point is, it is not meant to be a GUI framework, but a layer _above_ the (any) framework. The framework itself can be abstracted out, although tighter integration with an existing framework would be a good idea. Simply put, I want the Lit Window Library to do for UI coding what the STL and Boost are doing for algorithms. I want to build a library of commonly used UI interface patterns such as the "two list box/four buttons" implementation for the "select m of n" UI pattern or "listbox with two buttons 'up' and 'down'" lets a user change the order of the elements in a list box. Just as noone is coding their doubly linked lists anymore, nobody should have to code all the event handling and data transfering/binding to implement the "select m of n elements" pattern anymore. On another note, the wx community is discussing a "wxTNG", a next generation widget library. I'd love to see collaboration here. Their new approach is going to be a lot cleaner, I think, and the boost library has been mentioned. It would be such a shame if all our efforts went into similar but different projects. I will investigate. Best regards Hajo
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.
Agreed. I have yet to see any C++ GUI library that exploits anything beyond inheritance and very basic templates. I thought boost libraries had to have no external dependancies anyway? On Thu, 4 Nov 2004 20:03:08 -0500, Edward Diener <eddielee@tropicsoft.com> wrote:
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Cory Nelson <phrosty@gmail.com> writes:
Agreed. I have yet to see any C++ GUI library that exploits anything beyond inheritance and very basic templates. I thought boost libraries had to have no external dependancies anyway?
As long as it's just a replaceable implementation plug-in, it's not really a dependency, and it doesn't matter how paleolithic the C++ is. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Cory Nelson wrote:
Agreed. I have yet to see any C++ GUI library that exploits anything beyond inheritance and very basic templates. I thought boost libraries had to have no external dependancies anyway?
maybe you could take a deeper look into win32gui then. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
"Cory Nelson" <phrosty@gmail.com> wrote in message news:9b1d0614041104183987f877b@mail.gmail.com...
I thought boost libraries had to have no external dependancies anyway?
Not necessarily. A boost library should have at least one implementation that doesn't depend on external libraries, but other implementations may. For instance, on Win32, Boost.Threads normally uses native Win32 API calls, but it can be compiled to use the pthreads-win32 library (not sure how well it currently works, however--it has been that way for a long time but I believe it has been a while since anyone tested that configuration). Mike
Edward Diener wrote:
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.
Also, wxWindows is a huge library. If we were to introduce something in boost, I'd very much like it to be as small and light weight (as win32gui is supposed to be), not a collection of multi-megabyte dlls required, just to wrap win32 or what ever the underlying library is. If people want more powerful components, they can be added afterwards, but the underlying library around core OS controls should be as small as possible. Thanks Russell
Bronek Kozicki wrote:
Russell Hind wrote:
If people want more powerful components, they can be added afterwards,
more importantly, these components could be independly developed and distributed. That would "boost" adoption of boost GUI. If there is any, anywany.
Yes, that is what I intended. They shouldn't be part of the base library, so as to keep it small and simple (well as simple as gui's can get). I would like to see, as I think win32gui supports, the ability to use controls from multiple threads. e.g. set the enabled state/text of a button from any thread. I've currently written my own set of wrappers around Borland's VCL library to enable this, but the VCL is a large library and isn't C++, although it does integrate better with C++ than .Net IMHO. Thanks Russell
Yes, that is what I intended. They shouldn't be part of the base library, so as to keep it small and simple (well as simple as gui's can get).
I would like to see, as I think win32gui supports, the ability to use controls from multiple threads. e.g. set the enabled state/text of a
yes , indeed - you can use *any* win32gui window, from any thread. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Edward Diener wrote:
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.
Also, wxWindows is a huge library. If we were to introduce something in boost, I'd very much like it to be as small and light weight (as win32gui is supposed to be), not a collection of multi-megabyte dlls required, just to wrap win32 or what ever the underlying library is.
If people want more powerful components, they can be added afterwards, but the underlying library around core OS controls should be as small as possible.
Thanks
Russell
Honestly, I don't buy into the idea of cross platform GUI at all. I have lots of reasons born out of experience with them that I won't get into here, but in general, I find they are nice for the developer, but poor for the user. I would much rather write my backend code in a cross-platform language, and hook it up to a GUI designed for each platform I support. That is why, at first glance anyway, I like the idea behind the Lit Window design. Most of the backend is GUI neutral, allowing you to do more work in your cross-platform code. In theory, this could be used to simplify the platform specific GUI code that needs to be written. I'd much rather see C++ go a route of making it easier to develop for different GUI libraries than to actually develop one of its own (since I don't think it would get much use anyway). JJared McIntyre
participants (10)
-
Brian Braatz -
Bronek Kozicki -
Cory Nelson -
David Abrahams -
Edward Diener -
Hajo Kirchhoff -
Jared McIntyre -
John Torjo -
Michael Glassford -
Russell Hind