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

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-07-25 20:17:06

E. Gladyshev wrote:
>> Microsoft has a Windows Template Library, WTL, for
>> Windows specifically,
>> which is template-based but which they barely
>> support for their VC++ users.
>
> The main point of the proposed library is not a
> wrapper.  WTL is just a Win32 wrapper.
> The main idea is to simplify the use of STL containers
> as data sources for UI widgets (in a portable way).
> See my ListControl sample in a prev. message.
> Also the proposed library will help to organize the
> GUI/GDI elements and controlling data structures in a
> consistent (with the C++ standard) way using the
> 'iterator' paradigm.

I understand that.

>
> It seems to me that in our practicle life, we ended up
> with two different worlds in our hands.  One is the
> nice and clean C++ template world which works great to
> program algorithms and data strucures and another one
> is the dirty GUI world that we have to use to present
> our nice data structures. Most of the time when we try
> to bring these two together, the nice structure of C++
> template programming doesn't look so nice anymore.

Again I see what you want to do.

>
> It is a big project but at the end, it should bring
> these two worlds together (at least bit).

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.

Add to this the fact that nearly every C++ programmer already works with a
framework library depending on his implementation of choice. On Windows
alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others
about which I have no knowledde, each tied very closely to a particular C++
compiler, IDE, and implementation. While there may well be C++ programmers
looking for a cross-platform GUI/GDI from Boost, most programmers are
already very comfortable with the framework which comes with their C++
compiler and with the IDE features and tools that make using their "widgets"
very easy. Some of these frameworks, hooked to dialog editors or window
placement tools, allow the programmer to literally draw or place the widget
exactly where it should go and specify both the widget's physical
representation and data representation, and even the structures by which the
data will be passed from and to the widget. The amount of code which must be
written often becomes negligible by the programmer after the design time
interfaces have been set up. Yes, the data structures are pretty primitive
compared to C++ template containers and whatever other good things you might
create, 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.

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 am not trying to argue you against pursuing your goal but simply trying to
point out the difficulties that exist and the barriers against many C++
programmers adopting your implementation as opposed to what they have
already been using.