[LV2] friendly reminder 2017 -- was: Qt5 plugin UIs and libsuil

[David Robillard]

On Tue, 2017-03-14 at 12:08 +0100, Stefan Westerfeld wrote:
[...]
> > There are pros and cons to separation, but that aside, external-ui
> > is
> > just a complete shit way to go about it.
> 
> Ok, I think I'll try to implement the out-of-process UI stuff. Not
> sure how
> much spare time I can find for that, so I can't make any promises
> right now.
> 
> In any case, speaking of pointers to plugin instances, many plugins
> use the
> instance access feature, so these will not work with out-of-process
> UIs.

Meh.  UIs which have a hard dependency on instance-access obviously
aren't going to work, but this is inherent, they won't work in other
scenarios either, and it's generally a bad idea for UIs anyway and they
deserve it :)

> Same is true for plugins that combine Gtk and instance access (lots
> of plugins
> do that); suil probably needs to continue to support using Gtk within
> the host
> process in this case.

Suil wouldn't stop supporting embedding, out of process is a slow
fallback for scenarios where it's necessary, or for simple hosts that
don't care.
 
> The only other strategy I see to deal with instance access would be
> to put the
> plugin's DSP and UI code into a seperate process. In this case we can
> guarantee
> that everything works well, but at the cost of reduced efficiency.

Hosts that want to do that out of process plugin business are free to
do so if they please, but mashing all of that crap together into a
support library, to support running UIs out of process that don't
support running out of process is at least two recursive levels of
insanity too deep for my tastes :)

-- 
dr