[linux-audio-dev] ladspa GUI proposal

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

Subject: [linux-audio-dev] ladspa GUI proposal
From: Karl JH Millar (kmillar_AT_MIT.EDU)
Date: Fri May 26 2000 - 22:06:30 EEST


I'm still really not convinced about trying to support multiple toolkits. It's
too much work, and we'll end up with a set of Gtk+ plugins, a set of Qt plugins
and a small number that support both or something else. Not very universal

I think there may actually be a reasonable solution to most of this, which is
toolkit independant, allows chrome to be done well, custom widgets to be
created and preserves a consistent feel across (almost?) all plugins.

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
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?)
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).

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
of layout mechanism. If a plugin wants to change the appearance of any of
the standard widgets (knobs, sliders etc), then it may inform the host that
it has its own widget drawing routine, which the host may or may not choose to
use. The host still has the responsibility of accepting user input etc; the
plugin only controls the display. In this way, we allow chrome without
affecting the consistency of the interaction.
(this is at least partly inspired by some of Paul's comments, although I still
despise pixmaps)

In addition, we can allow custom widgets. Logically, there are two types of
custom widgets: those that just draw something (eg oscilloscopes), and those
that are for user interaction (eg an eq curve editor). The first
of these can be done simply by adding a "Visual" widget type, for which the
plugin is entirely responsible for the drawing routine, and doesn't accept any
events. The second one would also require the host to pass on XEvents to, so
it can process user input.
There may need to be some guidelines on how these work, so that input capture
works, and to preserve some level of visual consistency.

In practice, maybe it would look something like this

C functions prototypes:
#include <Xlib.h>

void
my_knob_drawing_routine(LADSPA_handle, Window *window, Display *dpy);

void
eq_curve_event_handler(LADSPA_handle, Window *window, XEvent *event);

XML descriptions

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_handler/>

In practise, a Visual and Custom widgets also need instantiate and destroy
functions as well, and a (void *) to pass around widget specific data.
The sizes of non-standard widgets probably should be requested in the XML
also (although the host of course could ignore such a request).

It's not yet clear to me how the widget and plugin should communicate though.
I think that getting/setting parameters nicely is one of the weak areas of
the ladspa api.

What do people think? Unfortunately I don't have time right now, or I'd knock
up some sample code.

Karl.


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

This archive was generated by hypermail 2b28 : Fri May 26 2000 - 22:36:26 EEST