[Cxxgui-devel] Hello

[David T. <dkt...@te...>]

Hello everybody.

I've just checked-in a changeset that introduces free widgets.  This
breaks the GTK build for the moment; I'm going to reboot shortly and fix
that.

If anybody would like commit privileges, just send me your SourceForge
username.  I'm quite relaxed about who commits what, but I reserve the
right to undo any changes :-).  We'll see how things go.

One thing I'm not very experienced with is ensuring portability.  I
develop on Windows XP with VC++.NET and Debian Sid with g++ 3.  So if
the build doesn't work on other platforms, I won't be particularly
surprised.  Please help me out with this!

A little explanation about how the code works (since this afternoon's
check-in): the public headers are in include/gui.  The implementations
are in src/win32 and src/gtk.  There is a shared implementation file,
src/multithread.cpp, for multi-threaded platforms.  Each platform has a
shared header, for example, src/gtk/gtk.hpp.  Widgets are created via a
factory.  The factory template is declared in include/gui/utils.hpp.
The actual factory is a typedef in the platform's shared header.  Widget
implementations inherit from the implements_widget template class, which
provides registration, this_ptr access, and other niceties.

The "real" widget is a class derived from widget_base.  However, the
user manipulates the real widget via a wrapper class.  For example, the
"real" window implementation, derived from window_base, is manipulated
by the "window" class, which contains a boost::shared_ptr<window_base>.

I'm interested in suggestions for the public interfaces for list
widgets.  They ought to be reasonably compatible with standard
containers.  I think they should simply contain strings.

At this stage, I'm not looking at writing a
serialization/unserialization library for widgets; nor am I looking at
implementing a graphics library.  But don't let that stop you from
writing your own, if you are so inclined :-).  As I mentioned on the
Boost list, I want to allow extensibility on a per-platform basis.  The
idea is that another library could #include the semi-private platform
shared header, and introduce a new widget type into the factory.  The
platform shared header contains an "implementation" ABC that should be
sufficient to extend the library in any way you can think of.

I also don't want to get into developing syntactic sugar for creating
complex windows all in one expression.  That can be done later.

I'm trying to keep one eye on eventually supporting run-time selection
of the backend.

Regards
David Turner


P.S. I would be very interested to see a text-mode backend for the
library, if anyone is interesting in creating one :-).