RE: [gtkmm] Gtkmm or Qt?

[Dr Mark H Phillips <mark austrics com au>]

Hi Murray,

> >  I'll have to look into gettext to
> > see if the licencing is compatible with our software (non-free)
> > and whether it does everything we need it to.
> 
> It's not a problem.

Okay, sounds good.

> >  (For example
> > we need it to have an elementary understanding of different
> > grammars so that we can create phrases on the fly using parameterized
> > phrases.)
> 
> You assume that that's possible. I don't think any other library can do it.
> printf() is generally used to help with this a bit, and some one wrote a C++
> equivalent, called "composer", I think.

Sounds like Qt and Gtkmm (well, gettext+composer actually) are equal
in this regard.

> > 3. Tools to facilitate generation of translations and easy maintenance
> > of several different language interfaces.
> 
> There are lots of tools. I suggest that you get in touch with the GNOME i18n
> team if you are interested.

Okay, thanks.

> > One thing I'm a bit confused about is... isn't this what libglademm
> > allows?
> 
> libglademm allows visual layout of controls, including properties of those
> controls. Properties can be discovered at runtime.
> 
> libglade (not libglademm) can do automatic signal connection (you enter the
> name of the source code callback function in the GUI designer), but that
> doesn't work with C++, because we need a specific runtime instance too.

Okay, thanks.  So in practice you would manually do some code which
scanned the properties of the controls produced at runtime, check that
the expected structure was really there, and manually create signal to
slot connections?

> >  Probably I'm misunderstanding what libglademm does... but
> > I thought it allowed a GUI to be created at runtime. So wouldn't
> > this mean that you must be able to connect signals and slots 
> > at runtime too?
> 
> No, that would be nice, but it doesn't seem to be conceptually possible.

I would think it should be possible using the FC++ library, albeit with
certain restrictions.  I can think of a few different approaches, but
probably the best way would be along the lines of:

You would statically define all the "commonly used" calling signatures
for callbacks.  You would also define a special "catch all" signature
for everything else.  This would give you compile-time type-safety for
most things and run-time type-safety for everything else.  You could
of course disable the latter if you wished.

You would define a "Connection" object type, whose main data entry
would be a union of FunN<calling signature> types.  These FunN<..>
objects are FC++ "indirect functoids".  Basically, if you say

  Fun3<int, std::string, int> f;

you have created a function f of type

  int f(int, std::string);

except that f is able to be dynamically bound.  You would write
some code that, at run-time, scanned through the libglademm produced
controls, for each control looked for the appropriate calling 
signature and assigned the "f" of the connection to the appropriate
function.  This would be statically type-safe except in the case
of an occurance of a "catch all" signature, in which case you could
either provide run-time type-safety, or simply disallow this.

The great thing about the FC++ library is that the code for doing
the "scanning through the controls at run-time" could be written
using direct functoids.  These are basically functions which give
static polymorphism "automagically".  So you could write one piece
of code which handled all the static calling signatures, without
explicitly having to specify them in that code.  And this code
would be compile-time type safe!!

(For information on FC++ see:
  http://www.cc.gatech.edu/~yannis/fc++/
)

> Again, I don't know of any existing examples of this kind of feature in any
> other toolkit.

As I understand it, this is what QtDesigner in combination with Qt
provides.  (I could be misunderstanding though.)

As you can see above though, I think similar functionality could be
added to libsig++ without modifying the C++ language.

Cheers,

Mark.