Thanks for the feedback. Being "The most commonly requested new feature for C++ ", I am very surprise that I got only one response (yours). Something doesn't add up. "Most debated" or not, inability to reach conclusions is, by itself, an inherent problem. See more down here. "Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F230B3798C7C19BD9D8274AA08A0@phx.gbl...
David Wehite wrote:
In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI".
And the most debated as to how it would work ;)
I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done.
I have, as well as many others, have made attempts into this brave new world ;).
I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them.
(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right? Now, when I say "I don't understand", this is of course not accurate because... (I think at least) I do. Granted that the scale of a type GUI is not anywere near the scale of 'int'. This does not mean that we should give up on it, just because "its hard work"... :-). And we should strive to make it platform independent like any other part of the language. You don't do any "detection" when you use any other library.
(2) String Library -- helpers to interact with native string types (e.g. wxString and ATL::CString) and C++ strings std::[w]string; native version
std::[w]string for platforms that use wide character strings; conversion routines and other helpers.
(3) Colour Library -- there is a discussion of a colour library elsewhere on this list. This is one step to a standard GUI library, but must implicitly (by default?) support the platform being targetted.
(4) Coordinates Library -- holding coordinate primitives: point (with its alias size) and rect are a minimum here; matrix and other transforms? what about interactions with other Boost libraries? 2D/3D support (e.g. the Windows GDI verses DirectX)? mixing different compatible systems?
I would like to do something like:
boost::coord::point2d pos; ::GetCursorPos( pos.native()); // handle POINT <==> point2d conversions
Advanced Libraries --
(5) Graphics -- Mixing different graphical systems (e.g. Win32 GDI, GDI+ and DirectDraw/Direct3D).
I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is.
This should be one of the goals. It should also be possible to hook into
of the
native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want to.
- Reece
It makes perhapse sense to have all (or some) of those above mentioned libraries "first" (as you wrote) and indeed, a GUI library might be the culmination or superset of all or some of these libraries plus perhaps other ones, or just other ones altogether. That would depend on a top view of that GUI library. That is why the architects of such a library, should FIRST discuss what is the overall architecture of such a library, THEN decide what will be the sub-components of it, and so on. Like when you architect, design and build any other thing. But more important then all those things mentioned above, it does not make sense to me, that one (individual) or entire organization, will deal with a gazillion bunch of things, ---------------------------------------------------------------------------- ----------- many of which are small change or infinitesimally irrelevat, less important for developers, ---------------------------------------------------------------------------- ----------- before dealing with the most burning subject for the C/C++ developers comunity - a standard GUI library. Even if "it is hard work" (and excuse me if I can't stop from loughing when I recall that expression...). That is of course, if Bjorne's statement that I quoted is true. I personally strongly beleive it is. But is fair to debate that claim too. David David
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost