Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?)
From: Thomas Hedler (thomas.hedler_AT_fen-net.de)
Date: Tue Sep 18 2001 - 00:14:19 EEST
OK.
Let's bring the discussion to some more objective points:
What do we want from our toolkit:
1) Ease of use to program
(there are some musicians under us, too, aren't they?)
2) Fast graphic engine
3) Maybe compatibility to other platforms (complete with
graphic engine, not only the containers...)
4) Code readability
5) Easy to learn
....a.o.i.
IMHO I have to say that 1,2,3 is not covered by any
libstdc++ or GTK Gui. Because of the Object_Oriented_Wanna_Be
programming in GTK you really don't have readability.
And QT _is_ fast, you have the compatibility, the
ease to program, code readability etc. and the Trolltech guys
offer wonderful documentation and support.
(I know that C++ this needs some
overhead compared to C, but now we have 1GHz CPUs...).
So: let's use QT.
Regards
Thomas
PS: So far I know arts-builder and brahms are 2 apps that are using
selfmade QT widgets.
----- Original Message -----
From: "Tommi Ilmonen" <tilmonen_AT_cc.hut.fi>
To: <linux-audio-dev_AT_music.columbia.edu>
Sent: Monday, September 17, 2001 1:22 PM
Subject: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets
with Qt ?)
> Hi.
>
> The title is (and hopefully remains) a joke.
>
> On Fri, 14 Sep 2001, Paul Davis wrote:
>
> >
> > I just want to mention one reason why I don't like using Qt myself,
> > not as flamebait but just to make it clear. Qt was written before the
> > Standard Template Library (STL) was reasonably standardized. As a
> > result, it contains implementations for things like lists, vectors and
> > many other container classes, that are part of the STL. For similar
>
> I guess it depends on what one is used to. I have always found STL totally
> painful, the headers are unreadable and some of the most simple operations
> take enormous amounts of effort (like removing the n:th element from a
> list). I also like Qt's way of giving giving warnings: "No such list
> element", "Tried to delete object twice" etc. They do make the code a bit
> slower, but the coding becomes a lot faster. And the (very few) critical
> sections can always be optimized with other methods (I don't really
> use Qt within DSP code).
>
> AFAIK STL lack proper unicode support, thus STL strings are not very
> useful for multilingual apps.
>
> STL does have some really nice stuff, but I seldom need/use it anyhow.
>
> At any rate, I find the question of containers is not very important. Qt
> API usually hides the containers from the application developers
> (QString and QStringList are some of the exceptions) so app developers
> are free to use what-ever containers they like -> I do not see a conflict
> between STL and Qt (since std::string is useless from my perspective
> anyhow and strings are the only really obvious place where one is better
> off using one standard only).
>
> ------
>
> Now: let me tell why I do not use GTK.
>
> After getting sick with Motif, Tck/Tk, OTcl/Tk and wxWindows I decided
> that: "Heck this GTK looks really cool, I think I'll write i Gimp plugin
> so I can test how it fits me". I copied one example plugin. I compiled it.
> Great, it worked. I modified the plugin. Then it crashed. I reversed the
> modifications. Then it worked. Then I tried another modification. And it
> crashed. Then I repeated the modify->crash cycle with random success for
> a few hundred times. Then I decided that enough is enough and went over to
> Qt instead. I believe Qt has cost me fewer crashes in two years than GTK
> in a few days. This -- of course -- proves nothing besides the fact that
> GTK is not the idel toolkit for *me*.
>
> PS. Qt 3 is going to make Qt templates fit better to STL thinking...
>
>
> Tommi Ilmonen.
This archive was generated by hypermail 2b28 : Tue Sep 18 2001 - 00:22:21 EEST