Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with 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 widgets with Qt ?)
From: Jelle (jelle_AT_defekt.nl)
Date: Tue Sep 18 2001 - 18:08:15 EEST


On Mon, Sep 17, 2001 at 09:57:10PM -0400, Paul Davis wrote:

sorry, but this is a long story, I wonder if I have a point here... ;)

> 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".
>
> >5) Easy to learn
>
> 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 ;)

agreed.

> >4) Code readability
>
> Point 4 is completely subjective. How readable you find particular
> expressions depends on your language(s) background and other
> experiences.

agreed as well ;)

> >3) Maybe compatibility to other platforms (complete with
> > graphic engine, not only the containers...)
>
> 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.

Hmm. Well, if point 5) is going to be true, it would be pratical if
the GUI would be portable 3) as well, _if_ you intend to write for
other systems (as I must do sometimes :( ).

Also, not only portabilty to other platforms, but maybe to other
GUI libraries could be usefull.

Plus, "readabilty" can be increased by using another toolkit, such as
wxWindows, altought this is subjective.

> >2) Fast graphic engine
>
> 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.

I would like to second this. Speed really isn't important in GUIs, IMHO,
as long as they stay workable.

I'd rather waste some processor time, than programming time if I can
choose between litte coding -> slow speed or much coding -> fast speed
to achive the same result.

(Ofcourse, the backend should be fast).

> >1) Ease of use to program
>
> 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.

It think the whole idea of USER i.f. as appossed to Programmer i.f.
is that the UI makes life easy for the User and vv.
Ofcourse, in complex programs the UI will require some learning anyhow.
For example, in extent to the widget-thread going on, how much work is it
to implement new widgets? It's likely that we will need a lot of "custom"
widgets, and even more likely that we will need to extent existing widgets.
(such as a treetablesequencer etc).

...

Has anyone ever looked into Mozilla's XUL (XPFE) language?
This basically is XML to describe the layout of dialogs, etc combined
with JavaScript to create the controller.

This has some interesting advantages (in rnd order):

a) Run time loading, server etc...

Imagine a server serving plugins. The plugins will include a GUI which
has to run on the client side. For binary code this means that you have
to supply several objects, one for x86 one for ppc etc. Thus interpreted
GUI logic seems more practical. (send over the XUL file and the client
can run it)

b) Development time, ease of development

It's rather have a extensive/complete UI than a less complete one. And
I'd also rather have it yesterday than today. ;)
I'd imagine developing GUI's in XUL is about as fast as creating webpages.

I'm not sure what is used to layout the actualy dialog but it could be
Gecko? Which also is the downside of XPFE, that widgets are not native
(suchs as Win32, macOS-widgets(?), GTK (or whatever can be considered native
on linux)

Also, XPFE is supposed to be easily extendible using custom widgets written
in C++ or JavaScript (they are infaced using some kind of COM like
API, called XPCOM, also a mozilla product).

If I compare this to wxWindows:
 
 both x-platform
 
 + native widgets (thus app has OS familiar looks and hopefully speedup)
 + faster
 - use of MACROs, MFC like API, binary form
 
 ? not GPL license, i don't know what the license is, but could be bad?

I think XPFE is very usefull for this, but I am personally not to happy
about the non-wrapper/non-native widget approach (which is also used in Qt
if I am not mistaken). There are already a dozen of different GUI toolkits
around (motif, gtk, qt, tcl/kt etc) and that doesn't make linux look very
"standarized".

Also, XPFE doesn't seem very fast at the moment, but there is a lot of
work to be done of the JS engine etc.. so this might(will?) change.

I think java is kinda inbetween XPFE and wxWindows.

*pffw* that should do it for now ;-)

cheers,
Jelle

-- 
defekt


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

This archive was generated by hypermail 2b28 : Tue Sep 18 2001 - 17:11:58 EEST