On 02/21/2011 07:20 PM, David Robillard 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). >
Dave, please, you certainly know that most lv2 gtk plugins out there do break this whole "agnostic" paradigm--tell me one which doesn't? yep. the ones on lv2_external_ui. shall i rest my case? no. if you look closer most of those ill-behaved lv2 gtk plugins, the ones i brag about, are committing the mortal sin of realizing a gtk(mm) widget, hardly Xembed-dable. look, it's not even a toplevel window for X sake (nb. the X is for X, not for Christ)--this seems to be a gross mistake from all early lv2 ui extension times when most people involved just wanted to pull up a proof-of-concept gui or something. it turned out the code base has spread like amoeba (i'm avoiding "viral" intentionally:) i'm not, and never was, against plugin developers doing their guis with whatever toolkit they like. it's just that the way they've been doing, and i suspect spreading like a "copy-paste" anti-pattern somehow, is a lot more wrong than using Nedko's lv2_external_ui extension. alas, for some reason, calf and linuxdsp are using it and with great success. should i say more? maybe not. anyway, i do acknowledge and really do empower your ideas, which i also believe will get to a better solution. i just don't take it so lightly, just like you said, like a "Qt guy" shoudln't -- yes, our notion of "crap" is reciprocal, trust me ;) cheers -- rncbc aka Rui Nuno Capela [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
