Re: [boost] GUI foundations

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 
>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.
>
>(Are all these libraries equivalent? Arent QT and WxWidgets at a higher 
>level
>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 
>API
>and XWindows initially)
>
>I'm not at all keen on this approach because it is hugely platform 
>dependent,
>like wrapping yourself up in sticky mud. Code is never going to be 
>portable.
>Remember that the ultimate goal is standardisation. There is no standard 
>library
>that is a wrapper for / or has dependencies on an outside commercial 
>library. I
>believe that would be unacceptable. The approach I would take is to require 
>a
>common interface across platforms. Design of a GUI  should start from 
>abstract
>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 
and WTL.

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:

class geometry::rect
{
public:
   /implementation defined/ native();
};

native() -- returns a type that is compatible with the platforms rectangle 
representation that does native <--> geometry::rect conversions. [--example
   geometry::rect area;
   GetClientRect( window.native(), area.native());
   std::cout << "window area = " << area << std::endl;
--end example]

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 >
class button
{
   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 
>version of
> > 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 
>conversion"
>thing is so important. I dont think it would be acceptable either to 
>standards
>committes.

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 
variants).

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 
>the
> > native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you 
>want.
>
>This would be easy to do from any given implementation but would just 
>represent
>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.