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