22 Feb
2011
22 Feb
'11
3:06 a.m.
On Mon, 2011-02-21 at 22:53 +0000, Rui Nuno Capela wrote:
On 02/21/2011 08:32 PM, Paul Davis wrote:
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.
On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
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 :) 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 ... 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)