linuxaudio.org

On 02/21/2011 07:20 PM, David Robillard wrote:

quoted text
> 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

rncbc@rncbc.org
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev