Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?)
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Sep 18 2001 - 04:57:10 EEST
>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.
I would never advocate the use of GTK+. I would eagerly advocate the
use of Gtk--, however, which provides a completely C++-idiomatic "thin
layer" over GTK+, so that there is almost no efficiency loss compared
to GTK (since almost everything is inlined), but allows a C++
programmer to work in "comfort".
Point 5 is of little interest to me. The most worthwhile things in
life are rarely easy. The corollary of which, of course, is that some
really hard things are utterly pointless ;)
Point 4 is completely subjective. How readable you find particular
expressions depends on your language(s) background and other
experiences.
Point 3 I could personally care less about. Over on the VST plugin
list a day or so back, I read about a careless pointer bug in a VST
plugin would crash the entire computer system when Cubase exited. So
I'm supposed to care about the ease of porting my s/w to a system
where an application that does "*(random()) = 0xbeefface;" can crash
the computer? And don't get me started on Windows. BeOS is effectively
dead. *BSD might be interesting, except there are no low-latency
patches, and I imagine it suffers from latency issues at least as
badly as main-line Linux does.
Point 2 is pretty much moot - other than tricks with double buffering,
which only affect a small subset of what's typically done with
toolkits, the X Window System is the graphics engine used by GTK and
Qt in almost every context that I (and perhaps we) care about. I'm
intrigued by the framebuffer versions of GTK and Qt, but I don't
really find myself drawn to them and I also doubt that there is much
of a speed difference between them - the tricks for making s/w
graphics engines fast are mostly public domain these days.
Point 1 seems somewhat virtuous, except that to do anything useful
except writing plugins (which is what I'd prefer non-programmers to be
doing), the non-programmer will need to learn about threads, mutexes,
parallel programming in general, and a host of other important but
trivial details. I suppose it helps to not add the needless
complexities of a toolkit to the list, but its not the biggest hurdle
by any means.
But we can agree to disagree. There are more important things in life
to do, or even just in software to do, than arguing about toolkits and
languages and libraries. 's fun, though :)))
--p
This archive was generated by hypermail 2b28 : Tue Sep 18 2001 - 04:56:20 EEST