linuxaudio.org

--001636499453e77309049cd7c082

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:

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

>

> 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

> > and qt widgets being reciprocally embeddable. it just doesn't work for

> > the masses. well, in practice, unless you're in some kind ivory tower

> > and aim for a very special case or tight coupled application, that is...

>

> 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

> extension).

>

> 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):

>

> OpaqueWidget

> lv2_ui_lib_load(ToolkitType requested_toolkit,

>                UI          plugin_ui)

>

> 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

> nicety.

>

> Peace,

>

> -dr

>

>

> _______________________________________________

> Linux-audio-dev mailing list

> Linux-audio-dev@lists.linuxaudio.org

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

>

Hi David,
As a plugin developer, I'm very much looking forward to this, especially

since I proposed something similar to this a bit ago (

http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.o...

:)

  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.
Jeremy
--001636499453e77309049cd7c082

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Mon, Feb 21, 2011 at 7:20 PM, Da=

vid Robillard <d@dro=

billa.net> wrote:
On Wed, 2011-02-09 at 20:05 +0000, Rui Nu=

no Capela wrote:

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

e list of

quoted text
> >> fixes should help, however please be aware that IR is at the =

moment

quoted text
> >> really not usable without its own GTK UI. In future versions =

I may

quoted text
> >> manage to switch to using an external-process LV2 UI which wo=

uld

quoted text
> >> result in the plugin UI being completely host toolkit agnosti=

c.

quoted text
> >

> > FWIW, I would not do this. =A0The external UI extension is the wr=

ong way

quoted text
> > of going about this, and momentum towards it is very worrysome...=

 =A0We

quoted text
> > need an abstraction layer (i.e. a library) to provide the ability=

 for

quoted text
> > any UI to be external. =A0It shouldn't be the host's - an=

d very definitely

quoted text
> > not the plugin's - problem to do this. =A0It's a difficul=

t problem to get

quoted text
> > just right(*). =A0Even if it wasn't, we'd end up with the=

 same code

quoted text
> > implemented all over the place, which is an obvious sign somethin=

g is

quoted text
> > not right...

> >

> > The right way is for the plugin UI to provide whatever native UI =

(e.g.

quoted text
> > gtk) it pleases, and a library provides the means to launch it

> > externally if the host toolkit does not match. =A0This way, the h=

ost can

quoted text
> > embed the UI if possible (a feature which really is a shame to th=

row

quoted text
> > away), but anyone can use it externally if this is not possible. =

=A0It is

quoted text
> > also possible these days for Gtk to embed Qt, and vice versa, whi=

ch the

quoted text
> > lib could also do... in short, all the tricky business of using a=

n X UI

quoted text
> > in a Y host, either embedded or externally, needs to be done in o=

ne

quoted text
> > place, and done in that one place correctly, so every host/plugin=

 author

quoted text
> > doesn't have to repeatedly deal with the same problems.

> >

> > After the upcoming LV2r4 (and new librdf-free slv2) is released (=

soon),

quoted text
> > I will take a stab at making this library. =A0All the nitty gritt=

y has

quoted text
> > 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). =A0This situation,

however, is crap, and needs fixing.
> what has, and still is, outrageously wrong is that utter cannot-say-wh=

at

quoted text
> stickiness to gtk gore over the lv2-ui interface--it's real pain (=

gasp)

quoted text
> lock-in disease--mostly due on ardour being a top reference as a plugi=

n

quoted text
> host, nevermind being a gtk based one (and damn good at several other<=

br>

quoted text
> things too;)

What? =A0The LV2 UI extension is toolkit agnotic. =A0It is not gtk ba=

sed

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<=

br>

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&#=

39;s

the entire point. =A0I take it further and don't believe plugin UI auth=

ors

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<=

br>

who doesn't like that particular toolkit, again really suck for a lot o=

f

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=

 gtk

quoted text
> and qt widgets being reciprocally embeddable. it just doesn't work=

 for

quoted text
> the masses. well, in practice, unless you're in some kind ivory to=

wer

quoted text
> and aim for a very special case or tight coupled application, that is.=

..

I am told it can work these days, unlike in the past. =A0Torben has s=

ome

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. =A0It doesn&#3=

9;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. =A0I am not sure, nor do I really care so much. =A0My point is<=

br>

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). =A0It is a high, but not top, priority for me right now (somewhere<=

br>

after releasing LV2r4, the new librdf-free slv2, and the LV2 persist

extension).
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):
OpaqueWidget

lv2_ui_lib_load(ToolkitType requested_toolkit,

 =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

nicety.
Peace,
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lis=

ts.linuxaudio.org

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

Hi David,As=

 a plugin developer, I'm very much looking forward to this, especially =

since I proposed something similar to this a bit ago (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio=

.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.
Jeremy
--001636499453e77309049cd7c082--