Subject: Re: [linux-audio-dev] LADSPA Control GUI metadata
From: xfm_AT_free.fr
Date: Mon Dec 10 2001 - 18:03:58 EET
>>Except when you write the plugin & the XML file AFTER /usr/bin/xmlgui (or
>>xmlgui should know where to find GUI description files before they have been
>>created : setting a well known parameter files directory, for example
>>using /usr/share/whatever/$GUIENGINE/$UNIQUE_ID as parameter files may be an
>>option, of course ) ...
>
>if a LADSPA host initiates the fork/exec of the GUI, it can only
>provide so much information to whatever the GUI is. if the GUI is a
>generic program that reads other files to do its work, that other
>program needs to take care of itself.
OK, it take the point that the host can only provide the plugin identity to the
GUI executable and that that should be sufficient to it to provide an
corresponding GUI.
>if i use perl to implement the GUI, and it needs to know where to find
>some data files, the host can't help with that. same for
>"/usr/bin/xmlgui".
My point was that you may want to provide GUI engines (a little less general
that universal GUIs), and specify a common way to store per-plugin files.
Agreed, the CURSES interface could store them in /opt/share/oracle and the Qt
interface (which, in my opinion, I may find different of the GTK one)
in /var/log/trash. The host can't help with that, but we may ... (only for
consistency and ease of maintenance of distributions XYZ ..)
This archive was generated by hypermail 2b28 : Mon Dec 10 2001 - 17:59:44 EET