[LV2] [PATCH 5/5] add external UI as valid UI

[Kaspar Emanuel]

Thanks for your responses and elaborating on what the situation is
with this extension.

On 4 January 2014 20:27, David Robillard <d at drobilla.net> wrote:
>
> Well, the original one violated the LV2 namespace without permission or
> cooperation, which is not cool, so has an official looking URI, but
> isn't actually.
>
> (For the record, anyone who does this again will be taken out back and
> shot)
>

Was this possibly just a misunderstanding though? All this URI
business is pretty new to me and I could see myself making a mistake
like that. It has been rectified now as far as I understand.

>
> My opinion of the external UI extension is that it is a crap solution,
> because plugin UIs themselves shouldn't be implementing all that
> external communication mechanism.

In my case, my planned plugin (a re-write of SooperLooper) is likely a
bit too complex to make sense as a plugin for some people. For some it
will make more sense as a stand-alone jack client (as SL has been)
that can change it's output and input ports and possibly host plugins
itself.  So my plan is to release both LV2 and standalone and I am
currently focusing on the stand-alone part.

I could likely use LV2 communication even as a stand-alone client but
I have put off doing anything related to LV2 for the time being
because I find I keep reading through the docs and not getting it and
asking people for help and still not getting it. I will take another
swing at it but when it stops being fun the whole project loses it's
point.

I have settled on using Google Protobuf [1] to define the variables
and generate communication code for me, at least for the standalone
part. Its a lot more fun to write code like:

     msg = MyMessage()
     msg.foo = 1
     send(msg.SerializeToString())

than to deal with all the Forges, Frames and Atoms from LV2. I guess I
am wishing for some higher level API to the Atom communication that
will abstract some of the complexity away from me. Maybe a similar
approach to Protobuf could be taken? My .proto file (used to define
the variable I want to share) actually looks very similar to my .ttl
files but with less details.

[1]https://developers.google.com/protocol-buffers/docs/overview

>
> A correct solution would have plugin UIs define their widgets normally,
> e.g. expose a Gtk2UI, then have a SINGLE separate facility, like a
> library, do the wrapping business.  Then, it is embeddable if possible,
> but usable regardless.

I have begun writing my UI in PyQT4 in python and couldn't figure out
yet if and how I could expose the Qt4 widget in a way so I could have
an internal QtUI.

>
> The external UI extension is essentially a kludge to work around doing
> things correctly, and it adds a bunch of redundant code to both UIs and
> hosts.  I don't think it's a particularly suitable inclusion to the core
> spec for these reasons.
>
> Embedding works fine in most cases anyway.  In cases where it does not,
> that should be fixed.  It's also a better user experience (external UIs
> in a single window host like Jalv hardly sense anyway), so incentivising
> properly exposed widgets is good.
>
> I do not recommend implementing external UIs.  To my knowledge there is
> no good reason to do so.  If you must, I highly recommend also exposing
> your widget, in which case it will work fine in Jalv, among others.

I will take another swing at understanding Atom communication and
building an internal UI at some point. Worst case I offer an external
UI but also will keep my definitions of float control ports (something
in LV2 that I understand, hooray!) that will autogenerate an internal
UI. It will be a tad ugly but could also be used a text-only or as an
automation interface.