Subject: Re: [linux-audio-dev] ladspa GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue May 30 2000 - 17:41:56 EEST
>Firstly, in every major linux toolkit I've looked at, we can get access to the
>underlying Xlib toolkit that it is based on. This forms a common denominator
Xlib is not a toolkit. It doesn't support the notion of a "widget" in
any way. Xt was the the first layer to provide the "widget" layer, and
GTK+ at least completely bypasses Xt (thank god).
>that any plugin can use to draw anything it wants. I don't see much need
>for a plugin to use the extra facilities provided by a higher-level toolkit.
>(are there any exceptions to this? I know it works for Xt, X/Athena, Motif,
> Gtk+, Gtk-- and Qt. Tk appears to allow this also.
>Also, are there plugins for which Xlib is simply not sufficient?)
Why do you think that Xt, Xaw, GTK+, Motif, GTK+, and Qt exist ?
Everything they do is done via Xlib, but people generally agree that
its incredbly painful to use Xlib directly for this. Hence: toolkits.
>This provides a sufficient level of toolkit independance for what follows, and
>is more flexible than (and also includes the possibility of) just using
>pixmaps (which I still happen to think is evil).
Can you explan why you think this ?
>A plugin can supply a description of how it wants to look, via some mechanism
>(eg XML or a C API), in terms of a set of agreed upon widgets and some sort
"a set of agreed upon widgets": this is the heard of the problem. Just
what is in this set ? There is no clear way to bound this. The beauty
of the vstGUI-pixmap-based approach is that there is no need to do so.
Now, having said all of the above, I don't think that what follows is
necessarily such a terrible idea:
>standard knob. Controls the plugin through its third port
><Widget Type="Knob" Port="2" x="..." y="..." />
>
>chrome knob
><Widget Type="Knob" ... draw_routine="my_knob_drawing_routine" />
>
>custom oscilloscope
><Widget Type="Visual" ... draw_routine="..." />
>
>eq curve editor
><Widget Type="Custom" ... draw_routine="..." event_handler="eq_curve_event_han
>dler/>
Its certainly true that even in the toolkits, the draw routines
frequently look like calls to Xlib. So this doesn't seem so bad.
HOWEVER: when I started doing my first audio-GUI, I spent a long time
(given no background in GUI's or computer graphics) trying to figure
out how to draw a nice knob. I looked at various image rotation ideas
etc, etc. before realizing that in real life, everybody pre-rotated a
pixmap, stored it in a file or an XPM data structure, and just drew
the result. At least, anybody who wanted a good looking knob.
The same thing applies (though to a lesser extent) to sliders,
switches, buttons, etc.
So, I think that "specific draw routines" really come down to:
foo_draw () {
... figure out which pixmap image to display ...
... display it ...
}
And finally, your model assumes the existence of X. We have already,
it seems to me, completely vetoed this idea.
--p
This archive was generated by hypermail 2b28 : Tue May 30 2000 - 18:17:24 EEST