[LAD] How to develop guis for LV2?
dave at drobilla.net
Sun Nov 8 20:27:11 UTC 2009
On Sun, 2009-11-08 at 21:13 +0100, Thorsten Wilms wrote:
> On Sun, 2009-11-08 at 14:39 -0500, David Robillard wrote:
> > New idea: it is tempting to define a very simple turtle document format
> > for hosts to signify what they support, then this kind of compatibility
> > information could be automatically generated as well (and in a much more
> > useful form than a human could put together). The information is
> > already there for plugins. As far as I'm concerned the lack of
> > automatically generated documentation (and/or machine readable data in
> > general) is pretty much the sole reason for every single complaint
> > related to this whole thing. This way is also decentralized, but the
> > results for all "known" implementations could be hosted at lv2plug.in
> > (or anywhere else) for convenience.
> > I am surprised I didn't think of this before, but it seems to be a
> > pretty good idea. All that is needed as far as maintenance goes is for
> > hosts to supply a simple turtle document that says "I implement foo and
> > bar and baz extensions". The rest can be compiled into whatever fancy
> > human readable form you want, for every single plugin out there, by a
> > tool. If I provide a template, would anyone be willing to put together
> > these documents? I will gladly write the tool if the data is there, and
> > the problem will be solved, and a convention set that solves it in the
> > future with basically no effort involved.
> As a start, I'll have a try with collecting a list of hosts and plugins
> and what features(/extensions) they provide or require right here on the
> list ;)
> Longterm it might be useful to have a way to query for this locally. For
> an application that builds a matrix for the hosts and plugins you have
> installed. Now, it's clear where to look for plugins, but some
> convention/mechanism would be needed to fin the host RDF files, right?
Ideally, yes, but it would be more productive to just put together this
data now and deal with that later.
Like everything else, it should probably be just bundles distributed,
installed, and discovered, in the usual way.
I will write a vocabulary and simple template later today.
More information about the Linux-audio-dev