From: Phlip (pplumlee_at_[hidden])
Date: 2001-04-03 01:46:14
Proclaimed Michael D. Crawford from the mountaintops:
> Might I suggest that a useful approach for Boost to take in making a GUI
> library would be to create a number of reusable components that would be
> useful to anyone writing any kind of application framework.
There are those who route commands thru the Qt slots and signals mechanism
between non-GUI things. But the shame is the Qt engine must be present.
Qt uses a compiler called MOC to interpret special keywords written into
classes & generate the boilerplate code.
SWIG (an adapter between languages, such as C++ and Python), by comparison,
reads a SWIG file to generate boilerplate code. But the effect is (I suspect)
a slot need not have a fixed argument list (like, say, MessageMaps). The
boilerplate code typesafely binds.
> While some application frameworks have advantages over others, choosing a
> particular one sets some major design decisions in stone from the very
> start of a project. It is advantageous that there should be a number of
> different frameworks so that the different alternatives can be explored and
> possibly be readily used.
Boost Python Library defeats SWIG using C++ reflection wrapped as traits.
I posit that a Boost Slots-n-Signals mechanism could use the same reflection,
and bypass the MOC compiler. This would access typesafe slots-n-signals.
Then, inside the samples folder of this project, would be a little quicky
wrapper on Tk (arguably the most portable off-the-shelf C-style GUI out
there). But it would dispatch using Slots-n-Signals instead of C-style
-- Phlip phlip_cpp_at_[hidden] ============== http://phlip.webjump.com ============== -- Set phasers on illin' --
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk