Updated LV2 GUI extension.

git-svn-id: http://svn.drobilla.net/lad/slv2@974 a436a847-0d15-0410-975c-d299462d15a1

1 files changed, 288 insertions, 346 deletions

diff --git a/slv2/lv2_gui.h b/slv2/lv2_gui.h
index 7b108b3..1fa643c 100644
--- a/slv2/lv2_gui.h
+++ b/slv2/lv2_gui.h
@@ -1,346 +1,288 @@
-/************************************************************************
- *
- * In-process UI extension for LV2
- *
- * Copyright (C) 2006-2007 Lars Luthman <lars.luthman@gmail.com>
- * 
- * Based on lv2.h, which is:
- *
- * Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis, 
- *                         Stefan Westerfeld
- * Copyright (C) 2006 Steve Harris, Dave Robillard.
- *
- * This header is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Lesser General Public License as published
- * by the Free Software Foundation; either version 2.1 of the License,
- * or (at your option) any later version.
- *
- * This header is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
- * USA.
- *
- ***********************************************************************/
-
-/** @file
-    This extension defines an interface that can be used in LV2 plugins and
-    hosts to create GUIs for plugins. The GUIs are plugins that reside in
-    shared object files in an LV2 bundle and be referenced in the RDF file
-    using the triples (Turtle shown)
-<pre>    
-    @prefix guiext: <http://ll-plugins.nongnu.org/lv2/ext/ipgui/1#> .
-    <http://my.plugin>    guiext:gui    <http://my.plugingui> .
-    <http://my.plugingui> guiext:binary <mygui.so> .
-</pre>
-    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.
-    
-    (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. If a GUI is in a separate bundle
-    the first triple above should be in that bundle's manifest.ttl file so that
-    hosts can find the GUI when scanning the manifests.
-    
-    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. See the
-    instantiate() and extension_data() callback pointers for more details.
-    
-    Note that this extension is NOT a Host 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).
-    
-    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.
-*/
-
-#ifndef LV2_GUI_H
-#define LV2_GUI_H
-
-#include "lv2.h"
-
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-
-/** 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.  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.
- */
-typedef void* LV2UI_Widget;
-
-  
-/** 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_Handle;
-
-
-/** 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 instance data. */
-typedef void* LV2UI_Controller;
-
-
-/** This is the type of the host-provided function that the GUI can use to
-    send data to a plugin's input ports. The @c buffer parameter must point
-    to a block of data, @c buffer_size bytes large. The contents of this buffer
-    will depend on the class of the port it's being sent to. For ports of the
-    class lv2:ControlPort, buffer_size should be sizeof(float) and the buffer 
-    contents should be a float value. For ports of the class llext:MidiPort the
-    buffer should contain the data bytes of a single MIDI event, and buffer_size
-    should be the number of bytes in the event. No other port classes are
-    allowed, unless the format and the meaning of the buffer passed to this 
-    function is defined in the extension that specifies that class or in a 
-    separate GUI host feature extension that is required by this GUI.
-    
-    The GUI is responsible for allocating the buffer and deallocating it after
-    the call. There are no timing guarantees at all for this function, although
-    the faster the host can get the data to the plugin port the better. A 
-    function pointer of this type will be provided to the GUI by the host in
-    the instantiate() function. */
-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 arbitrary commands to the plugin. The parameters after the first one
-    should be const char* variables, terminated by a NULL pointer, and will be
-    interpreted as a command with arguments. A function of this type will be 
-    provided to the GUI by the host in the instantiate() function. */
-typedef void (*LV2UI_Command_Function)(LV2UI_Controller   controller,
-                                       uint32_t           argc,
-                                       const char* const* argv);
-
-/** This is the type of the host-provided function that the GUI can use to
-    request a program change in the host. A function of this type will be 
-    provided to the GUI by the host in the instantiate() function. Calling
-    this function does not guarantee that the program will change, it is just
-    a request. If the program does change, the GUI's current_program_changed() 
-    callback will be called, either before or after this function returns
-    depending on whether the GUI host <-> plugin instance communication is
-    synchronous or asynchronous. */
-typedef void (*LV2UI_Program_Change_Function)(LV2UI_Controller controller,
-                                              unsigned char    program);
-
-/** This is the type of the host-provided function that the GUI can use to
-    request that the current state of the plugin is saved to a program.
-    A function of this type will be provided to the GUI by the host in the
-    instantiate function. Calling this function does not guarantee that the
-    state will be saved, it is just a request. If the state is saved, the 
-    GUI's program_added() callback will be called, either before or after
-    this function returns depending on whether the GUI host <-> plugin
-    instance communication is synchronous or asynchronous. */
-typedef void (*LV2UI_Program_Save_Function)(LV2UI_Controller controller,
-                                            unsigned char    program,
-                                            const char*      name);
-
-
-/** */
-typedef struct _LV2UI_Descriptor {
-  
-  /** The URI for this GUI (not for the plugin it controls). */
-  const char* URI;
-  
-  /** Create a new GUI object and return a handle to it. This function works
-      similarly to the instantiate() member in LV2_Descriptor, with the 
-      additions that the URI for the plugin that this GUI is for is passed
-      as a parameter, a function pointer and a controller handle are passed to
-      allow the plugin to write to input ports in the plugin (write_function 
-      and controller) and a pointer to a LV2_Widget is passed, which the GUI
-	  plugin should set to point to a newly created widget which will be the
-	  GUI for the plugin.  This widget may only be destroyed by cleanup().
-      
-      The features array works like the one in the instantiate() member
-      in LV2_Descriptor, except that the URIs should be denoted with the triples
-      <pre>
-      <http://my.plugingui> guiext:optionalFeature <http://my.guifeature>
-      </pre>
-      or 
-      <pre>
-      <http://my.plugingui> guiext:requiredFeature <http://my.guifeature>
-      </pre>
-      in the RDF file, instead of the lv2:optionalFeature or lv2:requiredFeature
-      that is used by host features. These features are associated with the GUI,
-      not with the plugin - they are not actually LV2 Host Features, they just
-      use the same data structure.
-      
-      The same rules apply for these features as for normal host features -
-      if a feature is listed as required in the RDF file and the host does not
-      support it, it must not load the GUI.
-  */
-  LV2UI_Handle (*instantiate)(const struct _LV2UI_Descriptor* descriptor,
-                              const char*                     plugin_uri,
-                              const char*                     bundle_path,
-                              LV2UI_Write_Function            write_function,
-                              LV2UI_Command_Function          command_function,
-                              LV2UI_Program_Change_Function   program_function,
-                              LV2UI_Program_Save_Function     save_function,
-                              LV2UI_Controller                controller,
-                              LV2UI_Widget*                   widget,
-                              const LV2_Feature* const*       features);
-
-  
-  /** Destroy the GUI object and the associated widget. 
-   */
-  void (*cleanup)(LV2UI_Handle gui);
-  
-  /** Tell the GUI that something interesting has happened at a plugin port.
-      For control ports this would be when the value in the buffer has changed,
-      for message-based port classes like MIDI or OSC it would be when a 
-      message has arrived in the buffer. For other port classes it is not 
-      defined when this function is called, unless it is specified in the 
-      definition of that port class extension. For control ports the default
-      setting is to call this function whenever an input control port value 
-      has changed but not when any output control port value has changed, for 
-      all other port classes the default setting is to never call this function.
-
-      However, the default setting can be modified by using the following
-      URIs:
-      <pre>
-      guiext:portNotification
-      guiext:noPortNotification
-      guiext:plugin
-      guiext:portIndex
-      </pre>
-      For example, if you want the GUI with uri 
-      <code><http://my.plugingui></code> for the plugin with URI 
-      <code><http://my.plugin></code> to get notified when the value of the 
-      output control port with index 4 changes, you would use the following 
-      in the RDF for your GUI:
-      <pre>
-      <http://my.plugingui> guiext:portNotification [ guiext:plugin <http://my.plugin> ;
-                                                      guiext:portIndex 4 ] .
-      </pre>
-      and similarly with <code>guiext:noPortNotification</code> if you wanted to 
-      prevent notifications for a port for which it would be on by default 
-      otherwise.
-      
-      The @c buffer is only valid during the time of this function call, so if 
-      the GUI wants to keep it for later use it has to copy the contents to an
-      internal buffer.
-      
-      The buffer is subject to the same rules as the ones for the 
-      LV2_Write_Function type. This means that a plugin GUI may not request a
-      portNotification for a port that has a class other than lv2:ControlPort
-      or llext:MidiPort unless the buffer format and meaning is specified in
-      the extension that defines that port class, or in a separate GUI host 
-      feature extension that is required by the GUI. Any GUI that does that
-      should be considered broken and the host should not use it.
-      
-      This member may be set to NULL if the GUI is not interested in any 
-      port events.
-  */
-  void (*port_event)(LV2UI_Handle   gui,
-                     uint32_t       port,
-                     uint32_t       buffer_size,
-                     const void*    buffer);
-  
-  /** This function is called when the plugin instance wants to send feedback
-      to the GUI. It may be called in response to a command function call,
-      either before or after the command function has returned (depending on
-      whether the GUI host <-> plugin instance communication is synchronous or
-      asynchronous). */
-  void (*feedback)(LV2UI_Handle       gui, 
-                   uint32_t           argc, 
-                   const char* const* argv);
-  
-  /** This function is called when the host adds a new program to its program
-      list, or changes the name of an old one. It may be set to NULL if the 
-      GUI isn't interested in displaying program information. */
-  void (*program_added)(LV2UI_Handle  gui, 
-                        unsigned char number, 
-                        const char*   name);
-  
-  /** This function is called when the host removes a program from its program
-      list. It may be set to NULL if the GUI isn't interested in displaying
-      program information. */
-  void (*program_removed)(LV2UI_Handle  gui, 
-                          unsigned char number);
-  
-  /** This function is called when the host clears its program list. It may be
-      set to NULL if the GUI isn't interested in displaying program 
-      information. */
-  void (*programs_cleared)(LV2UI_Handle gui);
-  
-  /** This function is called when the host changes the current program. It may
-      be set to NULL if the GUI isn't interested in displaying program 
-      information. */
-  void (*current_program_changed)(LV2UI_Handle  gui, 
-                                  unsigned char number);
-
-  /** Returns a data structure associated with an extension URI, for example
-      a struct containing additional function pointers. Avoid returning
-      function pointers directly since standard C++ has no valid way of
-      casting a void* to a function pointer. This member may be set to NULL
-      if the GUI is not interested in supporting any extensions. This is similar
-      to the extension_data() member in LV2_Descriptor.
-  */
-  void* (*extension_data)(LV2UI_Handle gui,
-                          const char*  uri);
-
-} LV2UI_Descriptor;
-
-
-
-/** A plugin 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 
-    @c 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.
-*/
-const LV2UI_Descriptor* lv2ui_descriptor(uint32_t index);
-
-
-/** This is the type of the lv2ui_descriptor() function. */
-typedef const LV2UI_Descriptor* (*LV2UI_DescriptorFunction)(uint32_t index);
-
-
-
-#ifdef __cplusplus
-}
-#endif
-
-
-#endif /* LV2_GUI_H */
-
+/************************************************************************

+ *

+ * In-process UI extension for LV2

+ *

+ * Copyright (C) 2006-2007 Lars Luthman <lars.luthman@gmail.com>

+ * 

+ * Based on lv2.h, which was

+ *

+ * Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis, 

+ *                         Stefan Westerfeld

+ * Copyright (C) 2006 Steve Harris, Dave Robillard.

+ *

+ * This header is free software; you can redistribute it and/or modify it

+ * under the terms of the GNU Lesser General Public License as published

+ * by the Free Software Foundation; either version 2.1 of the License,

+ * or (at your option) any later version.

+ *

+ * This header is distributed in the hope that it will be useful,

+ * but WITHOUT ANY WARRANTY; without even the implied warranty of

+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

+ * Lesser General Public License for more details.

+ *

+ * You should have received a copy of the GNU Lesser General Public

+ * License along with this library; if not, write to the Free Software

+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301

+ * USA.

+ *

+ ***********************************************************************/

+

+/** @file

+    This extension defines an interface that can be used in LV2 plugins and

+    hosts to create GUIs for plugins. 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)

+<pre>    

+    @@prefix guiext: <http://ll-plugins.nongnu.org/lv2/ext/gui#> .

+    <http://my.plugin>    guiext:gui    <http://my.plugingui> .

+    <http://my.plugin>    a             guiext:GtkGUI .

+    <http://my.plugingui> guiext:binary <mygui.so> .

+</pre>

+    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

+<pre>    

+    <http://my.plugingui> guiext:requiredFeature <http://my.feature> .

+    <http://my.plugingui> guiext:optionalFeature <http://my.feature> .

+</pre>

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

+    

+*/

+

+#ifndef LV2_IPGUI_H

+#define LV2_IPGUI_H

+

+#include "lv2.h"

+

+

+#ifdef __cplusplus

+extern "C" {

+#endif

+

+

+/** 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_Widget;

+

+  

+/** 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_Handle;

+

+

+/** 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 void* LV2UI_Controller;

+

+

+/** This is the type of the host-provided function that the GUI can use to

+    send data to a plugin's input ports. The @c buffer parameter must point

+    to a block of data, @c 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 @c 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 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. */

+typedef void (*LV2UI_Write_Function)(LV2UI_Controller controller,

+                                     uint32_t         port_index,

+                                     uint32_t         buffer_size,

+                                     const void*      buffer);

+

+

+/** */

+typedef struct _LV2UI_Descriptor {

+  

+  /** The URI for this GUI (not for the plugin it controls). */

+  const char* URI;

+  

+  /** Create a new GUI object and return a handle to it. This function works

+      similarly to the instantiate() member in LV2_Descriptor.

+      

+      @param descriptor The descriptor for the GUI that you want to instantiate.

+      @param plugin_uri The URI of the plugin that this GUI will control.

+      @param bundle_path The path to the bundle containing the RDF data file

+                         that references this shared object file, including the

+			 trailing '/'.

+      @param write_function A function provided by the host that the GUI can

+                            use to send data to the plugin's input ports.

+      @param controller A handle for the plugin instance that should be passed

+                        as the first parameter of @c write_function.

+      @param widget     A pointer to an LV2UI_Widget. The GUI will write a

+                        widget pointer to this location (what type of widget 

+			depends on the RDF class of the GUI) that will be the

+			main GUI widget.

+      @param features   An array of LV2_Feature pointers. The host must pass

+                        all feature URIs that it and the plugin supports and any

+			additional data, just like in the LV2 plugin 

+			instantiate() function.

+  */

+  LV2UI_Handle (*instantiate)(const struct _LV2UI_Descriptor* descriptor,

+                              const char*                     plugin_uri,

+                              const char*                     bundle_path,

+                              LV2UI_Write_Function            write_function,

+                              LV2UI_Controller                controller,

+                              LV2UI_Widget*                   widget,

+                              const LV2_Feature* const*       features);

+

+  

+  /** Destroy the GUI object and the associated widget. The host must not try

+      to access the widget after calling this function.

+   */

+  void (*cleanup)(LV2UI_Handle gui);

+  

+  /** Tell the GUI that something interesting has happened at a plugin port.

+      What is interesting and how it is written to the buffer passed to this

+      function is defined by the specified transfer mechanism for that port 

+      class (see LV2UI_Write_Function). The only exception is ports of the 

+      class lv2:ControlPort, for which this function should be called

+      when the port value changes (it must not be called for every single 

+      change if the host's GUI thread has problems keeping up with the thread

+      the plugin is running in), @c buffer_size should be 4 and the buffer

+      should contain a single IEEE-754 float.

+      

+      By default, the host should only call this function for input ports of

+      the lv2:ControlPort class. However, the default setting can be modified

+      by using the following URIs in the GUI's RDF data:

+      <pre>

+      guiext:portNotification

+      guiext:noPortNotification

+      guiext:plugin

+      guiext:portIndex

+      </pre>

+      For example, if you want the GUI with uri 

+      <code><http://my.plugingui></code> for the plugin with URI 

+      <code><http://my.plugin></code> to get notified when the value of the 

+      output control port with index 4 changes, you would use the following 

+      in the RDF for your GUI:

+      <pre>

+      <http://my.plugingui> guiext:portNotification [ guiext:plugin <http://my.plugin> ;

+                                                      guiext:portIndex 4 ] .

+      </pre>

+      and similarly with <code>guiext:noPortNotification</code> if you wanted

+      to prevent notifications for a port for which it would be on by default 

+      otherwise. The GUI is not allowed to request notifications for ports

+      for which no transfer mechanism is specified, if it does it should be

+      considered broken and the host should not load it.

+      

+      The @c buffer is only valid during the time of this function call, so if 

+      the GUI wants to keep it for later use it has to copy the contents to an

+      internal buffer.

+      

+      This member may be set to NULL if the GUI is not interested in any 

+      port events.

+  */

+  void (*port_event)(LV2UI_Handle   gui,

+                     uint32_t       port,

+                     uint32_t       buffer_size,

+                     const void*    buffer);

+  

+  /** Returns a data structure associated with an extension URI, for example

+      a struct containing additional function pointers. Avoid returning

+      function pointers directly since standard C++ has no valid way of

+      casting a void* to a function pointer. This member may be set to NULL

+      if the GUI is not interested in supporting any extensions. This is similar

+      to the extension_data() member in LV2_Descriptor.

+  */

+  const void* (*extension_data)(const char*  uri);

+

+} LV2UI_Descriptor;

+

+

+

+/** 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 

+    @c 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.

+*/

+const LV2UI_Descriptor* lv2ui_descriptor(uint32_t index);

+

+

+/** This is the type of the lv2ui_descriptor() function. */

+typedef const LV2UI_Descriptor* (*LV2UI_DescriptorFunction)(uint32_t index);

+

+

+

+#ifdef __cplusplus

+}

+#endif

+

+

+#endif