RE: [boost] Re: Re: GUI/GDI template library

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-07-28 08:35:39

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
Sent: Friday, July 25, 2003 7:17 PM
To: boost_at_[hidden]
Subject: [boost] Re: Re: GUI/GDI template library

> I am not trying to discourage you on working on such a project but the
> differences in GUI widgets and GDI functionality between operating
systems
> is still very great. As a very simple example, realizing that most
examples
> will be much more complex, items in a listbox may be representable by
a
> std::vector or even a std::map in one operating system but may have
much
> more complex requirements in another OS. Besides the issue of mere
> representation of the items in the listbox is the way the listbox gets
> populated with data and the way one reads data from the listbox back
into
> your containers. This also varies from OS to OS. Some OS's use
messages to
> transport data, some use callbacks, some use direct API calls, some
use
> enumerations, some use asynchronous I/O, and there may be other
mechanisms
> for all I know. And this is just a listbox, a very simple widget, and
yet
> you are going to have to write code for this that works for Windows,
Linux,
> Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost
supports.
> Think of more complicated widgets which have been developed like tree
views,
> page controls, list views, track bars, toolbars, edit controls, combo
boxes,
> and many others. On the GDI side there is the drawing of bitmap
images,
> geometrical figures, text, regions, vector images, low-level APIs like
>OpenGl and DirectX, the list goes on and on. The task is daunting.

I don't know about other platforms, but in Windows at least, the API is
very ugly and un-C++ like.  There is a two phase create/destroy process
of objects, the message map system, etc...  I think the thing to do is
to put all of these existing frameworks out of your mind and think of an
idealized GUI interface.  I can make MFC, at least, act like I want it
to.  I would speculate that other libraries are less painful to use and
thus easier to adapt than MFC.  The most critical step for me in making
MFC more friendly was to create wrappers for all the MFC classes so the
programmer could use callbacks (via boost::function) rather than message
maps.

>  but it will be very hard for most C++ programmers to give up their
> RAD and RAD-like tools for manipulation of a library entirely by code.

All of the RAD tools I've used make it easy to quickly create toy
applications and impossible to create real world applications.  If we
can create a library that will reduce the lines of code required to
implement a GUI by a significant factor programmers will happily abandon
their various outdated GUI tools.

> Finally many C++ programmers, being the creators that they are, have
already
> invented C++ template-based mechanisms to use on top of the GUI/GDI
> framework of choice which their compiler and implementation provides.
They
> may be very loath to use another more general template-based framework
no
> matter how good it is.

I disagree - most programmers were probably overjoyed to stop using
CString and CArray and start using the std::string and std::vector<>,
for instance.

Brock