Subject: Re: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to maalis 09 2000 - 21:44:57 EST
>When it comes to the GUI-part of it, I have been thinking about the
>possibility to add the GUI code in separate .so-files. This will give you a
>lot of good options:
>
>If there is no .so-frontend, the host application can make a gui by itself,
>that basically just reflects the in and out-ports (parameters and data
>streams), and the ranges on each of the ports. This will allow the user to
>set all the parameters as he want.
>
>If there is an .xml-frontend, the hostapplication has the ability to make a
>"link" between a plugin.so and an .xml-frontend, using the xml-description
>to draw the graphics.
As mentioned previously, Quasimodo does this. Sample description (note
that coordinates are given in percentage units):
<interface height="2">
<label xpos="2.0" ypos="5.0">Fripp</label>
<controller type="knob"
xpos="15.0"
ypos="2.0"
label="Threshold (rms)"
label_position="top"
param="kstart_threshold"
start="0.0"
end="32000.0"
step="1.0"
page="10.0"
/>
<socket
xpos="5.0"
ypos="40.0"
label="L/In"
label_position="top"
param="alin"
direction="input"
>
</socket>
<socket
xpos="15.0"
ypos="40.0"
label="R/In"
label_position="top"
param="arin"
direction="input"
>
</socket>
<socket
xpos="40.0"
ypos="25.0"
label="Loop Trig/In"
label_position="top"
param="klooptriggerin"
direction="input"
>
</socket>
<socket
xpos="50.0"
ypos="25.0"
label="Loop Trig/Out"
label_position="top"
param="klooptriggerout"
direction="output"
>
</socket>
<socket
xpos="75.0"
ypos="40.0"
label="L/Out"
label_position="top"
param="alout"
direction="output"
>
</socket>
<socket
xpos="85.0"
ypos="40.0"
label="R/Out"
label_position="top"
param="arout"
direction="output"
>
</socket>
<pushbutton
xpos="70.0"
ypos="5.0"
label="Record"
label_position="top"
param="krecording"
>
<state>0</state>
<state>1</state>
</pushbutton>
</interface>
>For plugins that need or could benefit from more control, like a 3D mixing
>application, you can supply a .so-file which holds actual GUI code, and make
>the link from the .so-file holding the plugin-code to the .so-file holding
>the GUI-code.
>
>Other obvious pros of taking this kind of approach are: You can have
>multiple frontends to the same plugin, one using GTK+ and one using Qt if
>you must. You can also in .so-files have frontends that takes special care
>when it comes to linking in to the host-application.
Stop for a moment and try to think about how this could work. I did
earlier today, and I got the sense that although I had believed the
same thing you say here, this is actually very, very difficult to get
right. Explain in detail how the plugin's shared library GUI code gets
connected to the X server, which thread runs it, how different
toolkits interact with each other ... i don't this is very easy at all.
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST