On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela 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.
> what has, and still is, outrageously wrong is that utter cannot-say-what
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).
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's
the entire point. I take it further and don't believe plugin UI authors
should have to deal with it either.
We can get all the wins without:
* Throwing out UI embedding, which really sucks for a lot of potential
UI designs (window hell sucks).
* Forcing a particular toolkit, which will inevitably piss off everyone
who doesn't like that particular toolkit, again really suck for a lot of
potentially neat UI designs, and thus severely hurt adoption
* Making plugin or host authors
Why throw out nice things if we don't have to? Kludges 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 gtk
I am told it can work these days, unlike in the past. Torben has some
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 me.
Maybe it is indeed unrealistic, at least in some situations. It doesn't
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. I am not sure, nor do I really care so much. My 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 the
union). It 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. This does not depend on making embedding working, since the
fallback will be making an external windows. We simply need something
like (obviously a simplification):
Which will return a widget of the requested toolkit type, regardless of
the toolkit the UI is implemented. There's a few possibilities:
1) Hooray, the toolkits match, and this will directly return the UI
widget, which you can embed or do whatever else you want with.
2) The toolkits do not match, and the library can implement
cross-toolkit embedding. This will return a widget in the requested
toolkit that from the caller's perspective is the same as case 1.
3) The toolkits do not match, and cross-toolkit embedding is not
possible. This will do the external UI thing (i.e. make a window, and
return a corresponding widget).
There are, in general, the 3 cases. The jist of the current problem is
that implementers must make a decision that mandates an interface on
other implementers. The 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. The 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