Boost logo

Boost :

From: David W (David.White.7_at_[hidden])
Date: 2005-09-28 16:42:58

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_at_[hidden]> wrote in message
> David Wehite wrote:
> >In his article "The Design of C++0x", published in C/C++ Users Journal,
> >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.
> >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
> ;).
> 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
> PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.)
> 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
(I think at least) I do. Granted that the scale of a type GUI is not anywere
the scale of 'int'. This does not mean that we should give up on it, just
"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
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
> 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+
> DirectDraw/Direct3D).
> >I just want to clarify, that when I say "standard", I mean that as long
> >my application source code adheres to that standard, if I take it and
> >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
> >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
> native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you
> to.
> - Reece
It makes perhapse sense to have all (or some) of those above mentioned
"first" (as you wrote) and indeed, a GUI library might be the culmination or
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.



> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at