Re: [LAD] GTK+ vs QT for new Open Source Project.

On Friday, August 14, 2009, Paul Davis wrote:
> On Thu, Aug 13, 2009 at 5:06 PM, Luis
> Garrido<luisgarrido@email-addr-hidden> wrote:
> > Bear in mind that Qt is C++ and signal/slot based, so you'll have the
> > usual problem of integrating GStreamer callbacks using static methods
> > and the user payload at the calls.
>
> gtkmm is signal/slot based too, but because of its closer integration
> with C++ idioms, this particular issue doesn't arise too much. you
> don't need a pre-processor to use libsigc++

Of course you need a pre-processor to use libsigc++. The pre-processor is a
standard part of the C++ (or plain C) compilation chain, for instance
the "cpp" program for the GCC compiler. It takes care of expanding macros,
compile directives and conditional compilation.

Maybe you are thinking about the Qt's "moc" code generator tool. It reads a
C++ header file, and if it finds one or more class declarations that contain
the Q_OBJECT macro, it produces a C++ source file containing the meta-object
code for those classes. This code implements the calls and callbacks for Qt's
native signals and slots, among other things.

MOC is not a pre-processor because it doesn't replace any text in the original
header file before the next compilation step. It is only a code generator.
The original header is a standard C++ header that can be used as-is by a C++
compiler.

> and if you are working in
> C++ for any reason, you should be aware of sigc++. its the greatest
> thing for C++ since boost (and thankfully, boost includes something
> closely modelled on it these days).
> > what toolkit you choose, so I'd favour GTK because of its easy
> > integration with GStreamer and to keep the whole application under the
> > callback paradigm.
>
> signals & slots are a callback mechanism too. they just hide it from
> the programmer with a different kind of abstraction (when this signal
> is "emitted", call the following "slot"). its all just syntactic
> sugar.

The main (functional) difference between the two systems is that Qt's signals
and slots can be manipulated at runtime, while you can't do the same with
libsigc++, that freezes the connections at compile time. Manipulate means
that you can connect and disconnect signals and slots at runtime, store and
retrieve those connections from a text or XML file, and so on. This also
makes Qt's signal/slots a little more expensive in processing time over
libsigc++.

Here is a comparision between them:
http://libsigc.sourceforge.net/benchmark.shtml

Why Doesn't Qt Use Templates for Signals and Slots?
http://doc.trolltech.com/templates.html

Qt's native signal/slot mechanism isn't mandatory to developt Qt-based
applications. It is possible to use Boost, libsigc++ or something else. See:
http://doc.trolltech.com/signalsandslots.html#using-qt-with-3rd-party-signals-and-slots

Regards,
Pedro
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Aug 14 16:15:01 2009