21 Feb
2011
21 Feb
'11
9:27 p.m.
On 02/21/2011 07:20 PM, David Robillard wrote:
On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela
wrote:
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
rncbc(a)rncbc.org
On 02/09/2011 04:49 PM, David Robillard wrote:
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.
On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi
wrote:
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
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.
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).