20 Mar
2005
20 Mar
'05
10:16 a.m.
On Sat, 2005-03-19 at 17:24, Paul Davis wrote:
Same with Qt. It doesn't have to be graphical.
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 -
witness QJackctl.
Jan
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.
projects
without subclassing just by creating the objects and some=20
"connect( bla, blub)" lines.
and using moc ... sigc++ doesn't require any preprocessor.