RE: [boost] Re: GUI library - another one

From: scott (scottw_at_[hidden])
Date: 2004-03-03 17:09:04

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of David Turner

I was reading these posts to try and stay in touch with as much
as possible. What I'm trying to say here is that my GUI expertise
sucks. The sub-thread regarding window pointers (i.e. shared_ptr)
rang a wee bell and an item below produced a nice resonant <bong>.

> The one problem I forsee with automatic deserialization is connecting
> the signals: because C++ does not really have an adequate metadata
> system, it will be necessary to provide some kind of 
> signal-to-function
> dictionary.  There might be a good metaprogramming framework that can
> achieve this; I don't know.  Possibly judicious use of the factory
> pattern.

Is there no overlap between the "reactive object" requirements and what
you are touching on here? I have effectively applied the ActiveObject
pattern in the limited GUI work that I do and this has taken care of
the routing of signals-to-functions. In the ActiveWorld (TM) I would have
expressed this as message-to-object, i.e. when you say "function" you
are actually referring to a specific method you wish to call on a
window instance?

Maybe the active object approach is interesting for its asynchronous
messaging. Maybe it becomes more so when you consider that
it brings thread control along with it.

If the implementation (in-progress) is not interesting then maybe
the pattern is? Or am I way off base?

Otherwise I like your goals. Personally think there is an unfortunate
difference between a GUI library that provides for quick development
of "typical" applications and a library that tackles movement of pixels
in a spritely fashion. No reason there couldnt be two complementary
libs I s'pose. Good luck.

Note:
I have successfully overlaid ActiveObject templates/classes
onto pre-existing GUI applications. It works.