On Wed, Feb 9, 2011 at 11:49 AM, David Robillard <[email protected]> wrote: > FWIW, I would not do this. The external UI extension is the wrong way > of going about this, and momentum towards it is very worrysome... We > need an abstraction layer (i.e. a library) to provide the ability for > any UI to be external. It shouldn't be the host's - and very definitely > not the plugin's - problem to do this. It's a difficult problem to get > just right(*). Even if it wasn't, we'd end up with the same code > implemented all over the place, which is an obvious sign something is > not right... > > The right way is for the plugin UI to provide whatever native UI (e.g. > gtk) it pleases, and a library provides the means to launch it > externally if the host toolkit does not match. This way, the host can > embed the UI if possible (a feature which really is a shame to throw > away), but anyone can use it externally if this is not possible. It is > also possible these days for Gtk to embed Qt, and vice versa, which the > lib could also do... in short, all the tricky business of using an X UI > in a Y host, either embedded or externally, needs to be done in one > place, and done in that one place correctly, so every host/plugin author > doesn't have to repeatedly deal with the same problems. > > After the upcoming LV2r4 (and new librdf-free slv2) is released (soon), > I will take a stab at making this library. All the nitty gritty has > been done by other people already, it just needs to be sanely > amalgamated. > > -dr > > (* and it has recently come up that it seems impossible to get certain > window related things right with the current scheme...)
How would I write an LV2 GUI in python? _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
