-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]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.