eviltwin69 at cableone.net
Sun Mar 20 14:20:17 UTC 2005
On Sat, 2005-03-19 at 17:24, Paul Davis wrote:
> >No, imho one of the main advantages is Qt's Signal/Slot mechanism and my=20
> >current implementation has come so far that I can send and receive OSC=20
> >messages with one argument (of type QVariant) via signals and slots.
> i don't want to get into a toolkit war, but gtkmm has been using
> SigC++ since its inception, and although it was loosely inspired by
> the Qt signal/slot system, it is widely acknowledged as superior to it
> in almost every way. it even inspired the boost classes for
> signals+slots, except that they forked it (so to speak) too early -
> sigc++2 is just 100% pure C++ software engineering joy. sigc++ is
> entirely independent of any graphical toolkit - you can use it
> non-graphical applications as well.
Same with Qt. It doesn't have to be graphical.
> >projects without subclassing just by creating the objects and some=20
> >"connect( bla, blub)" lines.
> and using moc ... sigc++ doesn't require any preprocessor.
So? I never have to worry about what happens in the preprocessor.
I didn't write it and I don't have to debug it. It just works, and, it
just works cross platform. Now that Qt is releasing the Windows version
under GPL it will probably get a lot more use.
Having used both GTK and Qt I have to say that Qt is IMHO a much
more polished and mature package. I have yet to run into anything that
wasn't already anticipated by the Qt developers - QProcess, QPrinter,
QSocket, QFtp, QHttp, QBrowser... The one thing that annoys me about
it is that they didn't implement a double or float spinbox (I rolled my
own and they'll have one in 4.0 ;-) The documentation is also much
better. But that's just my opinion. I think that a lot of the choice
in which one you use is dependent on what you are programming. In
Paul's world he needs as much control and efficiency as possible.
Programming simpler applications doesn't require that kind of control -
More information about the Linux-audio-dev