#include "lv2.h"
Go to the source code of this file.
Data Structures | |
| struct | LV2UI_Descriptor |
Typedefs | |
| typedef void * | LV2UI_Widget |
| A pointer to some widget. | |
| typedef void * | LV2UI_Handle |
| This handle indicates a particular instance of a GUI. | |
| typedef void * | LV2UI_Controller |
| This handle indicates a particular plugin instance, provided by the host. | |
| typedef void(* | LV2UI_Write_Function )(LV2UI_Controller controller, uint32_t port_index, uint32_t buffer_size, const void *buffer) |
| This is the type of the host-provided function that the GUI can use to send data to a plugin's input ports. | |
| typedef const LV2UI_Descriptor *(* | LV2UI_DescriptorFunction )(uint32_t index) |
| This is the type of the lv2ui_descriptor() function. | |
Functions | |
| const LV2UI_Descriptor * | lv2ui_descriptor (uint32_t index) |
| A plugin GUI programmer must include a function called "lv2ui_descriptor" with the following function prototype within the shared object file. | |
The GUIs are plugins that reside in shared object files in an LV2 bundle and are referenced in the RDF data using the triples (Turtle shown)
@prefix guiext: <http://ll-plugins.nongnu.org/lv2/ext/gui#> .
<http://my.plugin> guiext:gui <http://my.plugingui> .
<http://my.plugingui> a guiext:GtkGUI .
<http://my.plugingui> guiext:binary <mygui.so> .
where <http://my.plugin> is the URI of the plugin, <http://my.plugingui> is the URI of the plugin GUI and <mygui.so> is the relative URI to the shared object file. While it is possible to have the plugin GUI and the plugin in the same shared object file it is probably a good idea to keep them separate so that hosts that don't want GUIs don't have to load the GUI code. A GUI MUST specify its class in the RDF data. In this case the class is guiext:GtkGUI, which is the only class defined by this extension.(Note: the prefix above is used throughout this file for the same URI)
It's entirely possible to have multiple GUIs for the same plugin, or to have the GUI for a plugin in a different bundle from the actual plugin - this way people other than the plugin author can write plugin GUIs independently without editing the original plugin bundle.
Note that the process that loads the shared object file containing the GUI code and the process that loads the shared object file containing the actual plugin implementation does not have to be the same. There are many valid reasons for having the plugin and the GUI in different processes, or even on different machines. This means that you can _not_ use singletons and global variables and expect them to refer to the same objects in the GUI and the actual plugin. The function callback interface defined in this header is all you can expect to work.
Since the LV2 specification itself allows for extensions that may add new types of data and configuration parameters that plugin authors may want to control with a GUI, this extension allows for meta-extensions that can extend the interface between the GUI and the host. These extensions mirror the extensions used for plugins - there are required and optional "features" that you declare in the RDF data for the GUI as
<http://my.plugingui> guiext:requiredFeature <http://my.feature> .
<http://my.plugingui> guiext:optionalFeature <http://my.feature> .
These predicates have the same semantics as lv2:requiredFeature and lv2:optionalFeature - if a GUI is declaring a feature as required, the host is NOT allowed to load it unless it supports that feature, and if it does support a feature (required or optional) it MUST pass that feature's URI and any additional data (specified by the meta-extension that defines the feature) to the GUI's instantiate() function.These features may be used to specify how to pass data between the GUI and the plugin port buffers - see LV2UI_Write_Function for details.
GUIs written to this specification do not need to be threadsafe - the functions defined below may only be called in the same thread as the UI main loop is running in.
Note that this GUI extension is NOT a lv2:Feature. There is no way for a plugin to know whether the host that loads it supports GUIs or not, and the plugin must ALWAYS work without the GUI (although it may be rather useless unless it has been configured using the GUI in a previous session).
| typedef void* LV2UI_Controller |
This handle indicates a particular plugin instance, provided by the host.
It is valid to compare this to NULL (0 for C++) but otherwise the GUI plugin MUST not attempt to interpret it. The host may use it to reference internal plugin instance data.
| typedef const LV2UI_Descriptor*(* LV2UI_DescriptorFunction)(uint32_t index) |
This is the type of the lv2ui_descriptor() function.
| typedef void* LV2UI_Handle |
This handle indicates a particular instance of a GUI.
It is valid to compare this to NULL (0 for C++) but otherwise the host MUST not attempt to interpret it. The GUI plugin may use it to reference internal instance data.
| typedef void* LV2UI_Widget |
A pointer to some widget.
The actual type of the widget is defined by the type URI of the GUI. e.g. if "<http://example.org/somegui> a guiext:GtkGUI", this is a pointer to a GtkWidget compatible with GTK+ 2.0 and the GUI can expect the GTK+ main loop to be running during the entire lifetime of all instances of that GUI. All the functionality provided by this extension is toolkit independent, the host only needs to pass the necessary callbacks and display the widget, if possible. Plugins may have several GUIs, in various toolkits, but guiext:GtkGUI is the only type that is defined in this extension.
| typedef void(* LV2UI_Write_Function)(LV2UI_Controller controller, uint32_t port_index, uint32_t buffer_size, const void *buffer) |
This is the type of the host-provided function that the GUI can use to send data to a plugin's input ports.
The buffer parameter must point to a block of data, buffer_size bytes large. The contents of this buffer will depend on the class of the port it's being sent to, and the transfer mechanism specified for that port class.
Transfer mechanisms are Features and may be defined in meta-extensions. They specify how to translate the data buffers passed to this function to input data for the plugin ports. If a GUI wishes to write data to an input port, it must list a transfer mechanism Feature for that port's class as an optional or required feature (depending on whether the GUI will work without being able to write to that port or not). The only exception is ports of the class lv2:ControlPort, for which buffer_size should always be 4 and the buffer should always contain a single IEEE-754 float.
The GUI MUST NOT try to write to a port for which there is no specified transfer mechanism, or to a port for which the GUI has listed an optional transfer mechanism that the host does not support, or to an output port. The GUI is responsible for allocating the buffer and deallocating it after the call. A function pointer of this type will be provided to the GUI by the host in the instantiate() function.
| const LV2UI_Descriptor* lv2ui_descriptor | ( | uint32_t | index | ) |
A plugin GUI programmer must include a function called "lv2ui_descriptor" with the following function prototype within the shared object file.
This function will have C-style linkage (if you are using C++ this is taken care of by the 'extern "C"' clause at the top of the file). This function will be accessed by the GUI host using the dlsym() function and called to get a LV2UI_UIDescriptor for the wanted plugin.
Just like lv2_descriptor(), this function takes an index parameter. The index should only be used for enumeration and not as any sort of ID number - the host should just iterate from 0 and upwards until the function returns NULL, or a descriptor with an URI matching the one the host is looking for is returned.
1.5.3-20071008