From 1a661a61925b9ff59947be28ad4be95527079ea1 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sat, 26 Mar 2011 20:31:03 +0000 Subject: Clean up documentation. --- ext/ui.lv2/ui.ttl | 68 +++++++++++++++++++++++++------------------------------ 1 file changed, 31 insertions(+), 37 deletions(-) (limited to 'ext/ui.lv2/ui.ttl') diff --git a/ext/ui.lv2/ui.ttl b/ext/ui.lv2/ui.ttl index 00f4f4b..fdd9ed6 100644 --- a/ext/ui.lv2/ui.ttl +++ b/ext/ui.lv2/ui.ttl @@ -1,8 +1,7 @@ -# In-process UI extension -# +# LV2 UI Extension # Copyright (C) 2010-2011 Lars Luthman # -# based on lv2.ttl, which is +# Based on lv2.ttl, which is # Copyright (C) 2006-2008 Steve Harris, David Robillard # # This extension should be considered a replacement for the earlier @@ -29,7 +28,7 @@ # ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR # OTHER DEALINGS IN THE SOFTWARE. -@prefix ui: . +@prefix ui: . @prefix lv2: . @prefix rdf: . @prefix rdfs: . @@ -38,7 +37,7 @@ a lv2:Specification ; doap:license ; - doap:name "LV2 in-process UI" ; + doap:name "LV2 UI" ; doap:release [ doap:revision "0.1" ; doap:created "2011-03-26" @@ -53,48 +52,43 @@ plugins. The UIs are code that reside in shared object files in an LV2 bundle and are referenced in the RDF data using the triples 
-  @prefix ui: <http://lv2plug.in/ns/ext/ui#> .
-  <http://my.pluginui>  a             ui-gtk:GtkUI ;
-                        lv2:appliesTo <http://my.plugin> ;
-                        ui:binary     <myui.so> .
+  @prefix ui:     <http://lv2plug.in/ns/ext/ui#> .
+  @prefix ui-gtk: <http://lv2plug.in/ns/ext/ui-gtk#> .
+  <http://example.org/my-ui>  a             ui-gtk:GtkUI ;
+                              lv2:appliesTo <http://example.org/my-plugin> ;
+                              ui:binary     <my-ui.so> .
-where <http://my.plugin> is the URI of the plugin, -<http://my.pluginui> is -the URI of the plugin UI and <myui.so> 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. -

+where http://example.org/my-plugin is the URI of the plugin, +http://example.org/my-ui is the URI of the plugin UI and +my-ui.so 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 and the class MUST be a proper -subclass of ui:UI, in this case ui-gtk: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). -

+subclass of ui:UI, in this case ui-gtk: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).

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. It is also possible to have one -UI that works with several different plugins. -

+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. It is also possible to have one UI that +works with several different plugins.

UIs should also be written in such a way that the host may load several instances of an UI, or different UIs, and use them with the same plugin -instance. -

+instance.

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 do 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 the -header lv2_ui.h is all you can expect to work. -

+code and the process that loads the shared object file containing the actual +plugin implementation do 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 the header ui.h is all you +can expect to work.

""". ############## -- cgit v1.2.1