Boost logo

Boost :

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]
============== ==============
  --  Set phasers on illin'  --

Boost list run by bdawes at, gregod at, cpdaniel at, john at