<div><br><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 7:20 PM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:<br>
> On 02/09/2011 04:49 PM, David Robillard wrote:<br>
> > On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi wrote:<br>
> >><br>
> >> Regarding LV2 hosts other than Ardour: the second in the above list of<br>
> >> fixes should help, however please be aware that IR is at the moment<br>
> >> really not usable without its own GTK UI. In future versions I may<br>
> >> manage to switch to using an external-process LV2 UI which would<br>
> >> result in the plugin UI being completely host toolkit agnostic.<br>
> ><br>
> > FWIW, I would not do this. The external UI extension is the wrong way<br>
> > of going about this, and momentum towards it is very worrysome... We<br>
> > need an abstraction layer (i.e. a library) to provide the ability for<br>
> > any UI to be external. It shouldn't be the host's - and very definitely<br>
> > not the plugin's - problem to do this. It's a difficult problem to get<br>
> > just right(*). Even if it wasn't, we'd end up with the same code<br>
> > implemented all over the place, which is an obvious sign something is<br>
> > not right...<br>
> ><br>
> > The right way is for the plugin UI to provide whatever native UI (e.g.<br>
> > gtk) it pleases, and a library provides the means to launch it<br>
> > externally if the host toolkit does not match. This way, the host can<br>
> > embed the UI if possible (a feature which really is a shame to throw<br>
> > away), but anyone can use it externally if this is not possible. It is<br>
> > also possible these days for Gtk to embed Qt, and vice versa, which the<br>
> > lib could also do... in short, all the tricky business of using an X UI<br>
> > in a Y host, either embedded or externally, needs to be done in one<br>
> > place, and done in that one place correctly, so every host/plugin author<br>
> > doesn't have to repeatedly deal with the same problems.<br>
> ><br>
> > After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),<br>
> > I will take a stab at making this library. All the nitty gritty has<br>
> > been done by other people already, it just needs to be sanely<br>
> > amalgamated.<br>
> ><br>
><br>
> your words, Dave, are wise, but... until that (yours?) lib gets ever<br>
> real, the lv2-external-ui extension won't ever be wrong. sorry to tell<br>
<br>
</div></div>Just because something right has not been implemented does not mean the<br>
existing thing is right... (as your Gtk gripes illustrate)<br>
<br>
Yes, clearly right now (excluding actually implementing the library),<br>
using it is the pragmatic decision if you want a UI that works in a host<br>
of any toolkit (and you don't need to embed UIs). This situation,<br>
however, is crap, and needs fixing.<br>
<div class="im"><br>
> what has, and still is, outrageously wrong is that utter cannot-say-what<br>
> stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)<br>
> lock-in disease--mostly due on ardour being a top reference as a plugin<br>
> host, nevermind being a gtk based one (and damn good at several other<br>
> things too;)<br>
<br>
</div>What? The LV2 UI extension is toolkit agnotic. It is not gtk based<br>
whatsoever. Permit me a bit of yelling for emphasis:<br>
<br>
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK<br>
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND<br>
NEVER WILL BE.<br>
<br>
Sure, you (as a Qt person) don't like that most existing UIs happen to<br>
have been implemented in Gtk. This is a problem with how we have<br>
implemented UIs though, and not a problem with the UI extension itself.<br>
That is, this is precisely the sort of problem that shows we need a<br>
library to abstract this stuff (i.e. you are perfectly free to implement<br>
Qt UIs, but then Gtk host authors have the same gripes).<br>
<br>
I fully agree host authors should not have to deal with this (I<br>
certainly don't want a bunch of Qt crap in my Gtk hosts either), that's<br>
the entire point. I take it further and don't believe plugin UI authors<br>
should have to deal with it either.<br>
<br>
We can get all the wins without:<br>
<br>
* Throwing out UI embedding, which really sucks for a lot of potential<br>
UI designs (window hell sucks).<br>
<br>
* Forcing a particular toolkit, which will inevitably piss off everyone<br>
who doesn't like that particular toolkit, again really suck for a lot of<br>
potentially neat UI designs, and thus severely hurt adoption<br>
<br>
* Making plugin or host authors<br>
<br>
Why throw out nice things if we don't have to? Kludges in<br>
implementations are fine, but kludges that affect what interfaces we<br>
cooperate using are dangerous, particularly in the long term...<br>
<div class="im"><br>
> please, don't give me nice talks about xembed and that stuff about gtk<br>
> and qt widgets being reciprocally embeddable. it just doesn't work for<br>
> the masses. well, in practice, unless you're in some kind ivory tower<br>
> and aim for a very special case or tight coupled application, that is...<br>
<br>
</div>I am told it can work these days, unlike in the past. Torben has some<br>
experiments along those lines that work for him and at least some<br>
others, but one direction (I can't remember which) didn't work for me.<br>
Maybe it is indeed unrealistic, at least in some situations. It doesn't<br>
really matter regardless, the design decision of where the<br>
embed/external/whatever stuff belongs is orthogonal.<br>
<br>
In other words, maybe embedding toolkit X in toolkit Y can work, maybe<br>
it can not. I am not sure, nor do I really care so much. My point is<br>
definitely not that we should all depend on cross-toolkit embedding<br>
working; the important point is that this problem (e.g. using a Gtk UI<br>
in a Qt host) needs solving once, not a million kludgey times in every<br>
host and UI implementation.<br>
<br>
I do intend to write said library myself soon (I don't often talk about<br>
what I/we "will" do, but this is something of an LV2 UI state of the<br>
union). It is a high, but not top, priority for me right now (somewhere<br>
after releasing LV2r4, the new librdf-free slv2, and the LV2 persist<br>
extension).<br>
<br>
The important part, that I am suggesting very much needs doing ASAP, is<br>
that getting a library interface implemented, so people can start using<br>
it. This does not depend on making embedding working, since the<br>
fallback will be making an external windows. We simply need something<br>
like (obviously a simplification):<br>
<br>
OpaqueWidget<br>
lv2_ui_lib_load(ToolkitType requested_toolkit,<br>
UI plugin_ui)<br>
<br>
Which will return a widget of the requested toolkit type, regardless of<br>
the toolkit the UI is implemented. There's a few possibilities:<br>
<br>
1) Hooray, the toolkits match, and this will directly return the UI<br>
widget, which you can embed or do whatever else you want with.<br>
<br>
2) The toolkits do not match, and the library can implement<br>
cross-toolkit embedding. This will return a widget in the requested<br>
toolkit that from the caller's perspective is the same as case 1.<br>
<br>
3) The toolkits do not match, and cross-toolkit embedding is not<br>
possible. This will do the external UI thing (i.e. make a window, and<br>
return a corresponding widget).<br>
<br>
There are, in general, the 3 cases. The jist of the current problem is<br>
that implementers must make a decision that mandates an interface on<br>
other implementers. The library will make this problem go away, and<br>
make these cases implementation details as they should be.<br>
<br>
This is very much a pragmatic path, and not at all an ivory tower / pie<br>
in the sky situation: whether or not a case (particularly 2) can work in<br>
a given situation doesn't really matter - we have gained graceful<br>
degradation and interface stability. The first version will simply<br>
implement cases 1 and 3 - providing the interface is the important part<br>
that will solve the pressing problems with this situation.<br>
<br>
Hopefully someone will figure out and contribute case 2, but this is not<br>
a pressing (i.e. API related / community fragmenting) problem - just a<br>
nicety.<br>
<br>
Peace,<br>
<font color="#888888"><br>
-dr<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Hi David,<div><br></div><div>As a plugin developer, I'm very much looking forward to this, especially since I proposed something similar to this a bit ago (<a href="http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html">http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html</a> :) But the fact that you're capable and willing to implement this solution means a lot more than my confused half-baked ideas. I look forward to the day when embedding and cross-toolkitedness walk hand in hand.</div>
<div><br></div><div>Jeremy</div><meta http-equiv="content-type" content="text/html; charset=utf-8"></div>