Re: [boost] GUI foundations (about Boost's position/work on aStandard GUI Library for...)

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
news:BAY101-F230B3798C7C19BD9D8274AA08A0_at_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
of
> 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
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