On Fri, 2011-03-04 at 11:02 +0000, Pedro Alves wrote:
If we are going to confuse the discussion by talking about external
plugin UI processes as well, then there are /three/ processes involved:
1) The plugin host, e.g. audio engine.
2) The UI host, e.g. graphical host UI program
3) The plugin UI process
Accordingly, there are two 'process splits' involved. The 1..2 split is
necessary. The 2..3 split needs to die, at least as far as UI authors
explicitly implementing this. The "external UI" extension is a kludge
and an error, and a slew of both immediate and long-term problems.
Making it go away needs to happen ASAP. Those things are, in theory,
orthogonal, yes. They aren't in practise because this extension's API is
broken. That's basically the problem.
The current strategy is to abstract all this away from hosts entirely in
host libraries (such as SLV2), since clearly the entire community can
not move forward on this issue when the compatibility problems cut all
the way from plugin UI to host implementations. With the appropriate
abstraction in place, things can move forward gracefully.
As for the implementation details of embedding, assuming you can embed
toolkit X in toolkit Y (which is true of all toolkits for which LV2
plugin UIs currently exist), then using a separate process is simply
bloat. I don't think that is particularly relevant or interesting
though, both Qt and Gtk provide embedding APIs, how they work is a
magical mystery, who cares. The problem is that these issues are
affecting the API which plugin UI authors use to implement their UIs,
and that is a big problem.
Linux-audio-dev mailing list