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