On Fri, 2011-03-04 at 13:53 +0100, Stefano D'Angelo wrote:
This is why abstracting plugin UI toolkit choice from host code is so
important. "Everyone agree on something about " discussions
very definitely lead nowhere (except everyone being irritated and time
So, the coordinated effort is on two fronts:
1) We need a solid, extensible plugin control interface (i.e. messages
via ports) for use by UIs, among other things. This is a requirement of,
but not directly related to, UIs.
2) Host libraries need to abstract away the UI extension and UI toolkit.
The appropriate API is for the host to pass a requested UI type, and the
library should wrap accordingly. The next SLV2 will do this. I do not
know of any other host libraries intended for general use, but if they
exist the same change should happen there.
The plugin UI provides whatever widget it is natively implemented in.
The host requests whatever widget type it is natively implemented in.
UI implementation things like embedding, cross-toolkit wrapping,
separate processes, etc. become an issue only for host library
implementers (of which there is a very small number), and not absolutely
everybody involved. This makes the gigantic community train-wreck that
is plugin UI discussion go away.
The coordinated effort to realise this are:
1) Get hosts using an abstraction layer for UI instantiation
2) Get plugins UIs away from the external UI extension and deprecate it
1 is high priority and important. 2 is just improving implementation
(since the host libraries can implement the external UI extension during
the transition phase, or even indefinitely if it turns out there is a
need for it). 1 needs to happen before suggesting people do 2 makes
Linux-audio-dev mailing list