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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-28 18:29:26

Geoffrey Romer wrote:
>>>(1) Platform -- detection for what GUI library is being used
>>[snip]
>>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?
> 
> Actually, I suspect somebody *did*, when the C language was first
> being designed and standardized, because the behavior of the 'int'
> type is dependent on the support of the platform (the hardware, in
> this case) for integer operations, and the int type had to be defined
> in a way that was flexible enough to take advantage of that capability
> on almost any hardware. That's why int doesn't have a specified number
> of bits- so that it can adapt to the platform. That's one reason C/C++
> code isn't as portable as one might like.

Also, enumeration values, endian issues, floating point sizes and so on.

> The same applies to a standard GUI library, but raised to the Nth
> power. Such a library would have to adapt itself to the GUI
> capabilities provided by the host platform. This doesn't mean
> comitting the library to a single platform, but it does mean enabling
> the library to take advantage of whatever capabilities are present.

This is where the idea of a platform layer comes in. The /platform/ is
the Operating System (Win32, Linux, etc.), base API (Win32 API, GDK,
PalmOS API, etc.) and (optional) C++ abstraction library (wxWidgets, 
WTL, MFC, etc.).

The platform layer would configure the various capabilities of the 
target platform just like Boost.Configure checks what C++ facilities are 
available (e.g. does the compiler support long long? two-phase name 
lookup?) That is not to say that the other layers don't need specialist 
code, but it would allow you to do something like:

#include BOOST_PLATFORM(boost/gui/graphics,canvas.hpp)

and this would resolve to "boost/gui/graphics/wx/canvas.hpp" if you 
target wxWidgets, for example. I attempted something like this in the 
sandbox (boost/gui), however I would most likely rewrite several parts 
of this, keeping some of the tricks like the platform 
detection/delegation logic.

The main reason for the platform layer is to allow mapping from native 
types to a platform neutral type. However, it may be more feasible to 
move most of the implementation into the platform specific area:

// boost/geometry/win32/point2d.hpp
namespace boost::geometry
{
    struct point2d: public POINT
    {
       ...
    };
}}

// boost/geometry/cocoa/point2d.hpp
namespace boost::geometry
{
    struct point2d: public NSPoint
    {
       ...
    };
}}

// boost/geometry/palmos/point2d.hpp
namespace boost::geometry
{
    struct point2d: public PointType
    {
       ...
    };
}}

These can then use the platform-specific names (e.g. size.cx vs 
size.width) and layouts (Windows uses
    area{ top, left, bottom, right };
verses palmos
    area{ topLeft, extent /*i.e. size*/ };
and cocoa (Mac)
    area{ origin, size };

NOTE: Mac uses mathematical orientations, so (0, 0) is bottom left 
whereas Windows has (0, 0) as top left. This knowledge is platform 
dependant, so should we map to a neutral orientation?

There was discussions previously on this subject about using a HTML/CSS 
style specification and being able to specify values like:

    point2d pos( 2 * em, 3 * em );

This would interact with Andy Little's unit library.

Thus, a GUI library would not be the "all encompassing" GUI library, but 
a collection of libraries. Indeed, several "GUI" libraries offer other 
things like thread and filesystem support. These are already a part of 
Boost and are not really part of the GUI.

- Reece