Re: a broad question

[Paul Davis <pbd Op Net>]

>other apps on the same computer.  The lengths these tools go to
>in replicating real-world controls like dials, which are awful
>to use with a mouse, is both charming and repulsive.

actually, they're extremely wonderful to work with a mouse when
properly designed. my dials use the rms distance from the dial center
as the primary controller, so you can move in any direction, not in a
circle. then i add modifier keys to scale the rate of change. i've
also added code that optionally scales based on the x-axis distance
from the dial center, so that if you move a long way from dial and
then go up and down, you get large changes, but if you are close to
the dial center, you get small ones.

all in all, its a vastly more powerful numeric value controller than
anything offered by a "standard widget set". the same goes for 2D
pucks moved around on a rectangle to control 2 parameters at the same
time. you folks writing spreadsheets, IDE's, editors and system
control panels probably never come across the need to control
parameters in the way that audio stuff does.

>Like Havoc, I understand the advantages of sticking to standard GTK 
>widgets.  But doing so might be suicidal for a nascent standard in 
>the music software world.  Still, I would stay inside a GTK framework
>for the compliance and compatibility reasons Havoc gives.  

his reasons are good ones. but what of the developers who want to
write VST hosts with Qt (or even Motif, god help them)?

>							    For
>this reason, Canvas seems like the way to go, since you should
>be able to mix i18n widgets like text entry boxes together with
>custom cutesy pixmap buttons.  

That won't work. The VSTGUI API wouldn't permit such a
distinction. And besides, the canvas has some oddities if you start
mixing widgets and pixmaps (quite ignoring the phenomenal ugliness of
the GTK+ widgets under the default GTK+ theme to start with :)

>				And since I'm eagerly awaiting 
>the announcement of a GNOME-based VST work-a-like, I don't object
>to restricting plugin-using apps to the GTK main loop.

I refuse to use audio applications that use desktop environments. The
problem space that GNOME & KDE address (at least for now) is
orthogonal to the one faced by audio+MIDI apps. We already have seen a
number of cool applications that have chosen KDE or GNOME for nothing
more than some particular chunk of configuration management or
integration into some kind of app toolbar - the result is that at
least 50% of the linux population can't or won't use them. it makes me
really angry. i think that every person sitting down thinking about
using KDE or GNOME should first ask themselves "is the feature that i
get from the desktop environment worth excluding a huge part of my
potential user base?" i would also differentiate between those parts
of each toolkit that really can be used standalone and those that are
integral to the overall system. i routinely use libxml2, for example,
despite not having GNOME installed on my machine.

sorry to sound so negative when i know you were passing on some
encouragement. but these issues, being down on graphical widgets and
using desktop envs. really gets me worked up :)

--p