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