From e45dde6f4e045b2fb216e2f890bcb37f5c580fe9 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sat, 12 Feb 2011 03:53:42 +0000 Subject: Use new-style LV2 includes. git-svn-id: http://svn.drobilla.net/lad/trunk/slv2@2926 a436a847-0d15-0410-975c-d299462d15a1 --- slv2/lv2_ui.h | 372 ---------------------------------------------------------- slv2/slv2.h | 4 +- 2 files changed, 2 insertions(+), 374 deletions(-) delete mode 100644 slv2/lv2_ui.h (limited to 'slv2') diff --git a/slv2/lv2_ui.h b/slv2/lv2_ui.h deleted file mode 100644 index 75ccf22..0000000 --- a/slv2/lv2_ui.h +++ /dev/null @@ -1,372 +0,0 @@ -/************************************************************************ - * - * In-process UI extension for LV2 - * - * Copyright (C) 2006-2008 Lars Luthman - * - * Based on lv2.h, which was - * - * Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis, - * Stefan Westerfeld - * Copyright (C) 2006 Steve Harris, David 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 UIs for plugins. The UIs 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 uiext:  .
-        uiext:ui      .
-        a            uiext:GtkUI .
-      uiext:binary  .
-
- where is the URI of the plugin, is - the URI of the plugin UI and is the relative URI to the shared - object file. While it is possible to have the plugin UI 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 UIs don't have to load the UI code. - A UI MUST specify its class in the RDF data, in this case uiext:GtkUI. The - class defines what type the UI is, e.g. what graphics toolkit it uses. - There are no UI classes defined in this extension, those are specified - separately (and anyone can define their own). - - (Note: the prefix above is used throughout this file for the same URI) - - It's entirely possible to have multiple UIs for the same plugin, or to have - the UI for a plugin in a different bundle from the actual plugin - this - way people other than the plugin author can write plugin UIs independently - without editing the original plugin bundle. - - Note that the process that loads the shared object file containing the UI - 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 UI 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 - UI 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 UI, this extension allows for meta-extensions that - can extend the interface between the UI 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 UI as -
    
-     uiext:requiredFeature  .
-     uiext:optionalFeature  .
-
- These predicates have the same semantics as lv2:requiredFeature and - lv2:optionalFeature - if a UI 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) in a LV2_Feature struct (as defined in lv2.h) to the UI's - instantiate() function. - - These features may be used to specify how to pass data between the UI - and the plugin port buffers - see LV2UI_Write_Function for details. - - There are four features defined in this extension that hosts may want to - implement: - -
-    uiext:makeResident
-
- If this feature is required by a UI the host MUST NEVER unload the shared - library containing the UI implementation during the lifetime of the host - process (e.g. never calling dlclose() on Linux). This feature may be - needed by e.g. a Gtk UI that registers its own Glib types using - g_type_register_static() - if it gets unloaded and then loaded again the - type registration will break, since there is no way to unregister the - types when the library is unloaded. The data pointer in the LV2_Feature - for this feature should always be set to NULL. - -
-    uiext:makeSONameResident
-
- This feature is ELF specific - it should only be used by UIs that - use the ELF file format for the UI shared object files (e.g. on Linux). - If it is required by an UI the UI should also list a number of SO names - (shared object names) for libraries that the UI shared object - depends on and that may not be unloaded during the lifetime of the host - process, using the predicate @c uiext:residentSONames, like this: -
-     uiext:residentSONames "libgtkmm-2.4.so.1", "libfoo.so.0"
-
- The host MUST then make sure that the shared libraries with the given ELF - SO names are not unloaded when the plugin UI is, but stay loaded during - the entire lifetime of the host process. On Linux this can be accomplished - by calling dlopen() on the shared library file with that SO name and never - calling a matching dlclose(). However, if a plugin UI requires the - @c uiext:makeSONameResident feature, it MUST ALWAYS be safe for the host to - just never unload the shared object containing the UI implementation, i.e. - act as if the UI required the @c uiext:makeResident feature instead. Thus - the host only needs to find the shared library files corresponding to the - given SO names if it wants to save RAM by unloading the UI shared object - file when it is no longer needed. The data pointer for the LV2_Feature for - this feature should always be set to NULL. - -
-    uiext:noUserResize
-
- If an UI requires this feature it indicates that it does not make sense - to let the user resize the main widget, and the host should prevent that. - This feature may not make sense for all UI types. The data pointer for the - LV2_Feature for this feature should always be set to NULL. - -
-    uiext:fixedSize
-
- If an UI requires this feature it indicates the same thing as - uiext:noUserResize, and additionally it means that the UI will not resize - the main widget on its own - it will always remain the same size (e.g. a - pixmap based GUI). This feature may not make sense for all UI types. - The data pointer for the LV2_Feature for this feature should always be set - to NULL. - - - UIs 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 UI extension is NOT a lv2:Feature. There is no way for a - plugin to know whether the host that loads it supports UIs or not, and - the plugin must ALWAYS work without the UI (although it may be rather - useless unless it has been configured using the UI in a previous session). - - A UI does not have to be a graphical widget, it could just as well be a - server listening for OSC input or an interface to some sort of hardware - device, depending on the RDF class of the UI. -*/ - -#ifndef LV2_UI_H -#define LV2_UI_H - -#include "lv2.h" - -#define LV2_UI_URI "http://lv2plug.in/ns/extensions/ui" - - -#ifdef __cplusplus -extern "C" { -#endif - - -/** A pointer to some widget or other type of UI handle. - The actual type is defined by the type URI of the UI. - 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 UIs, in various - toolkits. */ -typedef void* LV2UI_Widget; - - -/** This handle indicates a particular instance of a UI. - It is valid to compare this to NULL (0 for C++) but otherwise the - host MUST not attempt to interpret it. The UI 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 - UI 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 UI 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 - and what the host should do with it depends on the value of the @c format - parameter. - - The @c format parameter should either be 0 or a numeric ID for a "Transfer - mechanism". 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 UI 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 UI will work without being able to write to that port or not). - The only exception is when the UI wants to write single float values to - input ports of the class lv2:ControlPort, in which case @c buffer_size - should always be 4, the buffer should always contain a single IEEE-754 - float, and @c format should be 0. - - The numeric IDs for the transfer mechanisms are provided by a - URI-to-integer mapping function provided by the host, using the URI Map - feature with the map URI - "http://lv2plug.in/ns/extensions/ui". Thus a UI that requires transfer - mechanism features also requires the URI Map feature, but this is - implicit - the UI does not have to list the URI map feature as a required - or optional feature in it's RDF data. - - An UI MUST NOT pass a @c format parameter value (except 0) that has not - been returned by the host-provided URI mapping function for a - host-supported transfer mechanism feature URI. - - The UI MUST NOT try to write to a port for which there is no specified - transfer mechanism, or to an output port. The UI is responsible for - allocating the buffer and deallocating it after the call. -*/ -typedef void (*LV2UI_Write_Function)(LV2UI_Controller controller, - uint32_t port_index, - uint32_t buffer_size, - uint32_t format, - const void* buffer); - - -/** This struct contains the implementation of an UI. A pointer to an - object of this type is returned by the lv2ui_descriptor() function. -*/ -typedef struct _LV2UI_Descriptor { - - /** The URI for this UI (not for the plugin it controls). */ - const char* URI; - - /** Create a new UI object and return a handle to it. This function works - similarly to the instantiate() member in LV2_Descriptor. - - @param descriptor The descriptor for the UI that you want to instantiate. - @param plugin_uri The URI of the plugin that this UI 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 UI 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 UI will write a - widget pointer to this location (what type of widget - depends on the RDF class of the UI) that will be the - main UI widget. - @param features An array of LV2_Feature pointers. The host must pass - all feature URIs that it and the UI supports and any - additional data, just like in the LV2 plugin - instantiate() function. Note that UI features and plugin - features are NOT necessarily the same, they just share - the same data structure - this will probably not be the - same array as the one the plugin host passes to a - plugin. - */ - 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 UI object and the associated widget. The host must not try - to access the widget after calling this function. - */ - void (*cleanup)(LV2UI_Handle ui); - - /** Tell the UI 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 @c format parameter, which has the same - meaning as in 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 does not have to be called for every - single change if the host's UI 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. In this case the @c format - parameter should be 0. - - 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 UI's RDF data: - 
-      uiext:portNotification
-      uiext:noPortNotification
-      uiext:plugin
-      uiext:portIndex
-
- For example, if you want the UI with uri - for the plugin with URI - 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 UI: - 
-       uiext:portNotification [ uiext:plugin  ;
-                                                      uiext:portIndex 4 ] .
-
- and similarly with uiext:noPortNotification if you wanted - to prevent notifications for a port for which it would be on by default - otherwise. The UI is not allowed to request notifications for ports of - types 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 UI 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 UI is not interested in any - port events. - */ - void (*port_event)(LV2UI_Handle ui, - uint32_t port_index, - uint32_t buffer_size, - uint32_t format, - 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 UI 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 UI 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 UI 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. -*/ -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 diff --git a/slv2/slv2.h b/slv2/slv2.h index 27f5a03..8318564 100644 --- a/slv2/slv2.h +++ b/slv2/slv2.h @@ -26,8 +26,8 @@ extern "C" { #include #include -#include "lv2.h" -#include "lv2_ui.h" +#include "lv2/lv2plug.in/ns/lv2core/lv2.h" +#include "lv2/lv2plug.in/ns/extensions/ui/ui.h" #if defined _WIN32 || defined __CYGWIN__ #define SLV2_LIB_IMPORT __declspec(dllimport) -- cgit v1.2.1