On Mon, 2011-02-21 at 20:27 +0000, Rui Nuno Capela wrote:
I said the LV2 UI extension is toolkit agnostic. It is - i.e. it
supports any toolkit.
I did not say all particular LV2 UIs are toolkit agnostic. They are
not. Many are implemented in Gtk, for example. This, however, is not
the problem (as we both agree, i.e. UI authors should be free to do so).
> if you look closer most of those ill-behaved lv2 gtk plugins, the ones i
Well, sure, but you can't say that not having LV2 UIs whatsoever would
be a good thing with a straight face. Nobody's claiming everything has
been done perfectly. I will, however, claim that the freedom for
developers to do their thing does result in real, actual, innovation,
and improvements in the 'LAD platform' that would not occur otherwise,
and history backs me up. That developers can do their proof of concept
implementations is certainly not a bad thing! It's a very, very good
thing, that has been shown to work.
Of course, this freedom comes at a cost, no argument there. We do
indeed need to revise how those proof of concepts were done (with the
benefit of the experience gained) from time to time. Sure beats not
being able to...
That's the cost - the reward is higher quality software (eventually),
more features, and all the well-known wins that come with
distributed/agile software development. Particularly in an open source
world, it's IMO a very wise trade-off.
Anyway, back to practical matters:
> i'm not, and never was, against plugin developers doing their guis with
I fully agree, which is why I just described my proposed solution to the
problem. Again, I don't tend to discuss such things on-list much (the
pointless direction of this discussion being evidence as to why), but
developers need to know a particular technology is not a
wise /long-term/ investment to make the best decisions, and the issue
came up, so...
> , is a
Well, no, because that extension threw out the baby with the bathwater,
and while it solved a pragmatic part of the problem in the short-term,
it made the serious long-term problem here (API) even worse in some
The problem is not how plugin authors have been doing their GUIs at all.
They have been, can, and still should, be implementing them in their
toolkit of choice, such as Gtk. The problem is that it was not
implemented correctly on the host side of things, and instead of solving
this problem once correctly and collectively (library), the external UI
extension kludge screwed up the UI API instead, put the solution in the
wrong place, forced that solution to be constantly re-implemented, and
further fragmented the community. Long term problem => alarm bells =>
Note that the problem here is not the LV2 UI extension, which will not
have to change(*). That it may be the pragmatic choice for plugin UI
authors right now does not change the fact that the external UI
extension was (objectively and without malice) the design screw-up here.
Fair enough, the ability to try and screw it up is a part of that
freedom. I've certainly screwed up my fair share as well. Live and
learn... and revise :)
(* Which, by the way, is a real-life example of the LV2 extension way of
Linux-audio-dev mailing list