Content-Type: text/plain; charset=ISO-8859-1
On Mon, Feb 21, 2011 at 7:20 PM, David Robillard wrote:
> On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
As a plugin developer, I'm very much looking forward to this, especially
since I proposed something similar to this a bit ago (
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.
Content-Type: text/html; charset=ISO-8859-1
On Mon, Feb 21, 2011 at 7:20 PM, Da=
vid Robillard <d@dro=
On Wed, 2011-02-09 at 20:05 +0000, Rui Nu=
no Capela wrote:
Just because something right has not been implemented does not =
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). =A0This situation,
however, is crap, and needs fixing.
> what has, and still is, outrageously wrong is that utter cannot-say-wh=
What? =A0The LV2 UI extension is toolkit agnotic. =A0It is not gtk ba=
whatsoever. =A0Permit 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. =A0IT 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. =A0This 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&#=
the entire point. =A0I take it further and don't believe plugin UI auth=
should have to deal with it either.
We can get all the wins without:
=A0* Throwing out UI embedding, which really sucks for a lot of potential
UI designs (window hell sucks).
=A0* Forcing a particular toolkit, which will inevitably piss off everyone<=
who doesn't like that particular toolkit, again really suck for a lot o=
potentially neat UI designs, and thus severely hurt adoption
=A0* Making plugin or host authors
Why throw out nice things if we don't have to? =A0Kludges 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=
I am told it can work these days, unlike in the past. =A0Torben has s=
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 =
Maybe it is indeed unrealistic, at least in some situations. =A0It doesn=
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. =A0I am not sure, nor do I really care so much. =A0My 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 =
union). =A0It is a high, but not top, priority for me right now (somewhere<=
after releasing LV2r4, the new librdf-free slv2, and the LV2 persist
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. =A0This does not depend on making embedding working, since the
fallback will be making an external windows. =A0We simply need something
like (obviously a simplification):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UI =A0 =A0 =A0 =A0 =A0plugin_ui)
Which will return a widget of the requested toolkit type, regardless of
the toolkit the UI is implemented. =A0There's a few possibilities:
=A01) Hooray, the toolkits match, and this will directly return the UI
widget, which you can embed or do whatever else you want with.
=A02) The toolkits do not match, and the library can implement
cross-toolkit embedding. =A0This will return a widget in the requested
toolkit that from the caller's perspective is the same as case 1.
=A03) The toolkits do not match, and cross-toolkit embedding is not
possible. =A0This will do the external UI thing (i.e. make a window, and
return a corresponding widget).
There are, in general, the 3 cases. =A0The jist of the current problem is
that implementers must make a decision that mandates an interface on
other implementers. =A0The 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. =A0The 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
Linux-audio-dev mailing list
a plugin developer, I'm very much looking forward to this, especially =
since I proposed something similar to this a bit ago (http://email@example.com=
.org/14098999.html=A0:) =A0 But the fact that you're capable and wi=
lling to implement this solution means a lot more than my confused half-bak=
ed ideas. =A0I look forward to the day when embedding and cross-toolkitedne=
ss walk hand in hand.