On Mon, 2011-02-21 at 22:53 +0000, Rui Nuno Capela wrote: > On 02/21/2011 08:32 PM, Paul Davis wrote: > > On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela <[email protected]> wrote: > > > >> alas, for some reason, calf and linuxdsp are using it and with great > >> success. should i say more? maybe not. > > > > well, yes and no. notice that its not possible to embed the plugin > > UIs, which is something we even manage to do with Ardour on OSX, where > > we're using GTK and the plugins are using Cocoa or Carbon. this seems > > like a bit of a backwards step - here we are on a platform where we > > control *all* the technology and we can't even get the plugin GUIs to > > embed? shurely shome mishtake ... > > put it another way: > > is there any lv2 plugin which is not using the lv2_external_ui extension > but is xembed-dable and please, do not force the host to link to libgtk > et al. and even show its gui?? i'd like to know :)
The UI simply provides a widget of some type (e.g. GtkWidget). Whatever the host can/does with this is not a feature of the UI. Your question is a bit misleading (it is obviously impossible to use a GtkWidget without linking to Gtk). Technically the answer to your question is yes, since it is possible to XEmbed a GtkWidget. If you mean to point out that the current situation is inadequate, there's no disagreement there - there is currently no good solution to that problem (i.e. hosts /can/ do it, with a lot of work and code duplication, but this is not a good solution). There is indeed a problem here, but it is a host-side one. The question is /what/ should link to Gtk. You say not the host, and I agree. We therefore need something in-between then host and the e.g. Gtk UI implementation. There are two options: * Throw out embedding and various other desirable features, and re-implement this bridging in every single UI (the external UI extension's strategy). Not everyone is happy: nice features become impossible, and copy/paste code duplication is rampant. * Keep all the desirable features when possible, gracefully degrade when not, and implement this bridging once in a library. Everyone is happy: anything possible is, uh, possible, proper code reuse means all hosts work correctly for free, bugs/features need implementing once, implementing a UI or UI support becomes much simpler (increasing adoption), neither host nor UI authors need to care about cross-toolkit compatibility, etc. The latter is What Needs Doing. There is IMO no question about that, it's all win. There are a few details to sort out, though: The proposed library would inherently need to link to Gtk. This means the host doesn't directly link to / depend on Gtk, but the library ends up depending on all toolkits, so from a package perspective every host ends up depending on every toolkit, which is no good. So, the library will need to be implemented in several dynamically loaded modules (ideally packaged separately). I think this is probably the way to go. If even an indirect dynamic linkage like this is a problem (why?), then a process based solution is also possible. This will probably be needed for new stuff like UIs in other languages (e.g. python), remote/web UIs, etc. I don't think doing it this way is wise/necessary for the current crop of hosts/UIS, though (all C/C++), i.e. this is non-pressing future work that shouldn't affect the library API. > oh, and did i say that the gtkmm based ones are even crappier in that > regard? because it also forces you (host) to link to libgtkmm, which is > outrageously and utterly plain nuisance? The Gtkmm initialisation problem does suck(*), but linking to gtkmm is no more outrageous than any other toolkit. Again, just another example of why this all needs to be wrapped up in a library where we can solve it once, correctly. -dr (* There is, however a simple solution I won't go into now that is also useful for a few other similar situations) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
