Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgetswith Qt ?)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgetswith Qt ?)
From: Thomas Hedler (thomas.hedler_AT_fen-net.de)
Date: Wed Sep 19 2001 - 20:32:11 EEST


Of course you right that the time can be better spent than porting
one App to another Toolkit. But there is the problem.
In the moment you have too much choice when you want
to get an App together. I know Linux is about choice, but
here on the list are many people and when every programmer
cooks his own soup we have problems.
Look what Steinberg has done:
the .$%@^# Windows API is covered by _one_ VST API.
In this API the "low-level" graphic engine is embedded.
So every programmer with musical ambitions thinks: look, under Windows I
have
everything I want why should I switch to Linux?
Latency or some other technical issues are no matter anymore.
With Linux the programmer says: "Ahh, this widget would be nice, because of
that...but
it's QT. I need this Widget, but it's GTK. Damn."

I don't have a conclusion for this, I'm really sorry.
The only thing I can dream of, is an PluginAPI like VST.
The graphic engine is here for GTK _AND_ QT, every
musical programmer can write their GUIs independant from
the app. That would be nearly nice together with LADSPA, but I don't know
how
to accomplish this technically and if it is possible _and_ reasonable.

Regards
 Thomas
----- Original Message -----
From: "David Gerard Matthews Jr." <dgm4+@pitt.edu>
To: <linux-audio-dev_AT_music.columbia.edu>
Sent: Tuesday, September 18, 2001 2:34 AM
Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related
widgetswith Qt ?)

> I admit to not having seen benchmarks, but is QT really faster than
> GTK? At least on my system, GNOME (GTK) seems to run faster than KDE
> (QT), but I suppose that's not completely toolkit-dependent.
> FLAMEBAIT ALERT: But seriously, wouldn't the time and effort occupied by
> porting Ardour to QT be better spent by making it more stable, easier to
> install, and more generally "complete"?
> (Apologies if this turns out to only fan the flames...)
> -dgm
> Thomas Hedler wrote:
> >
> > 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.
>
>


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Sep 19 2001 - 20:43:47 EEST