From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-29 04:47:28
Andy Little wrote:
>"Reece Dunn" <msclrhd_at_[hidden]> wrote
> > 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+,
> > cross-platform (wxWidgets, Qt, etc.) and the platform being used for
> > cross-platform GUI. This could be an extension to Boost.Config with
> > platform/win32.hpp, platform/wxwidgets.hpp, etc.
>(Are all these libraries equivalent? Arent QT and WxWidgets at a higher
>than Win32 Api?. Should we also include XWindows in the set of low level
>libraries. BTW My thoughts on C++ GUI was to implement in parallel on Win32
>and XWindows initially)
>I'm not at all keen on this approach because it is hugely platform
>like wrapping yourself up in sticky mud. Code is never going to be
>Remember that the ultimate goal is standardisation. There is no standard
>that is a wrapper for / or has dependencies on an outside commercial
>believe that would be unacceptable. The approach I would take is to require
>common interface across platforms. Design of a GUI should start from
>concepts not implementation needs.
Ok. At the very least it should hook into the platform's low-level API and
be able to interact with (if not targetted for) other libraries such as Qt
I agree that the library should be designed on the abstract level, but it
should also be possible to pass a rectangle object to GetClientRect (or the
equivalent in Mac, PalmOS, etc.) without having to write a lot of
platform-dependant code yourself. This could either be via an extension, or
define something like:
/implementation defined/ native();
native() -- returns a type that is compatible with the platforms rectangle
representation that does native <--> geometry::rect conversions. [--example
GetClientRect( window.native(), area.native());
std::cout << "window area = " << area << std::endl;
That is, I want it to be easy to interact with Win32, XWindows or Mac code
/in a way that is simple for the user/.
I would also like the option of using native control/component types (or at
least in terms of L&F and usability) as well as a cross platform L&F that
Java can produce. Skinnable components at compile time (allowing a run-time
skin option). This would allow you to hook into drawing the component type
(push button, radio button, tree view), sub-element (expand/collapse on the
tree view) and state (hot tracked (mouse over), pressed, inactive/disabled,
normal, selected, other). Thus, you could have:
template< typename Skin >
void draw( canvas & c )
Skin::draw_item( c, ui::radio, ui::selected, ui::pressed );
> > (2) String Library -- helpers to interact with native string types (e.g.
> > wxString and ATL::CString) and C++ strings std::[w]string; native
> > std::[w]string for platforms that use wide character strings; conversion
> > routines and other helpers.
>I would just use std::string. I dont understand why this "native
>thing is so important. I dont think it would be acceptable either to
The Win32 API can use either wide character or narrow versions. Using the
narrow versions on WinNT and above can cause performance issues with the
narrow -> wide -> narrow string conversions done by the OS. Therefore, it
would be useful to have something like a gui::string that is std::string on
narrow character platforms (Win32 built with *A API variants, XWindows,
etc.) and std::wstring on wide character platforms (Win32 built with *W API
This also has an impact on platform Unicode support. The "native conversion"
I was referring to was that you cannot do:
std::wstring str( "foo" );
at the moment. std::basic_string< native-character-type > should be the
string type of preference.
> > 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
>This would be easy to do from any given implementation but would just
>a failure of the GUI library to provide the required functionality.
Ok. If each type had a native() method (see above), I'd be happy.