cxxgui-devel — Design & development discussion

Re: [Cxxgui-devel] RE: C++ GUI library

[Daniel J. <dan...@em...>]

On Tue, 2004-03-09 at 15:44, David Turner wrote: 
> Please send a mail to the list when you start working on something;
> there's nothing worse than a project where nobody knows what anyone else
> is doing :-).

I better tell you what I've been up to then. As I mentioned on the boost
list, I've been writing some jamfiles for boost build. I've got it
working on linux with GTK, and almost working on windows.

At the moment the code doesn't work on cygwin or visual c++ 6. Which
probably isn't that surprising. I don't know if its worth bothering with
visual c++ 6, since it looks like many of the boost libraries are going
to give up on it over the next year or two.

My sourceforge id is danieljames.

Daniel

[Cxxgui-devel] RE: C++ GUI library

[David T. <Da...@fi...>]

Hi Matt


> I'd like to offer a hand in helping you with you C++ GUI=20
> library.  I've been
> lurking in the Boost newsgroups for a long time now and have=20
> been debating
> when to step in and offer help.  Seeing as I'm a GUI developer at work
> (using an in-house GUI library wrapped around Win32 calls) I=20
> figure I may
> actually be of some use for your baby...  :)

Thank you for your offer :-).  I think the first think to do is join the
mailing list (http://lists.sourceforge.net/lists/listinfo/cxxgui-devel).
Then post your sourceforge user id to the list, and I'll add you as a
developer, which should automatically give you commit privileges.

At the moment I'm puzzling over the design of the list/tree widget.
I'll forward to you an earlier post I made outlining my current plan.  I
suspect that the menu widget will be of a similar level of complexity,
so the design of that needs to be kicked around too.

However, if you want to get started writing actual widgets, there's
plenty to do there, too.  There is also scope to improve the level of
detail provided by the existing widgets, although I definitely don't
want to throw in everything and the kitchen sink.

Please send a mail to the list when you start working on something;
there's nothing worse than a project where nobody knows what anyone else
is doing :-).


> I've had a quick scan of the code and it doesn't look too difficult to
> follow, though more comments would have helped!  ;)

Ah, yes :-).  If you see anything particularly confusing, please either
comment it or tell me about it.  I think it's all pretty
straightforward, though.


Regards
David Turner

[Cxxgui-devel] Design / lists / MVC

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

Hi, everyone

This is my preliminary design for the list widget.  I'm concerned that it
might be too complicated.  Let me know what you think.

The data ("Data") is stored in an unspecified container.

The user must provide an adaptor class, called the Model.  Canned models
for various STL container types will be provided.  The model also supplies
metadata, such as column names.  The Model derived from an ABC called
gui::data_model.

The list widget itself is a view, called gui::data_view.  The user
specifies the model to the view by passing it a pointer to a data_model. 
The view automatically tracks the data.

One problem I have with this design is the following:

std::vector<std::string> my_data;
gui::linear_model<std::vector<std::string> > my_model;
gui::data_view view(my_model);
std::sort(my_data.begin(), my_data.end()); // view not updated
my_model.range_reordered(my_data.begin(), my_data.end()); // view updated
view.update(); // view updated
std::sort(my_model.begin(), my_model.end()); // view updated

I dislike having to work explicitly through the model if the view is to be
updated.

Regards
David Turner

[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 :-).