linuxaudio.org

On Wed, 2011-02-23 at 11:03 +0000, Rui Nuno Capela wrote:

quoted text
> On Wed, 23 Feb 2011 10:57:25 +0100, torbenh  wrote:

> > On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui Nuno Capela wrote:

> >> On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard

> >> wrote:

> >> >On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:

> >> >>

> >> >>        Speaking of existing work, I vaguely recall mention of a

> >> >>        plugin with a Qt GUI? Where is this, I need one for

> >> >>testing...

> >> >>

> >> >>

> >> >>Take a look at latest svn of CLAM Network Editor. It is apparently

> >> >>able to export networks as LV2 with a Qt GUI. See

> >> >>http://clam-project.org/wiki/Development_screenshots

> >> >

> >> >Interesting. Judging by the fact that they're shown in Ardour,

> >> >they must

> >> >be doing the wrapping in the UI code. It would be nice if the next

> >> >CLAM

> >> >release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)

> >> >switched to a library to do the embedding.

> >> >

> >>

> >> red herring alert! :)

> >>

> >> this features a qt-widget embedded *in* a gtk-widget via gtk-socket

> >> w/e--the lv2 ui plugin produced by the clam framework implicitly

> >> assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a

> >> plain gtk-gnostic ui :)--the host must still get to libgtk et al. to

> >> handle the gtk widget/socket--i'm afraid this is not what Dave

> >> really asked for :/

> >

> > i think this IS what dave asked for :)

> > he can just move the gtk shell code, and move it into his library,

> > and

> > it will be a qt plug :)

> >

>

>  oh come on. do you mean Dave's library will have a so called

>  specialized "gtk shell" for each toolkit out there? wrapping everything

>  under gtk is not what i would call a "pretty good solution" at least the

>  one we've agreed about earlier.

>

>  Fons is right suggesting a common-denominator term: the lv2_ui

>  descriptor should have carried a system window-id instead, in

>  alternative to, a plain toolkit-dependent widget pointer that

>  lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based

>  systems it would cast to a Window type; on windows it would be a HWND;

>  i'm sure there's something native and equivalent on macosx/carbon/cocoa

>  w/e... depending on the system the plugins are built/targeted then the

>  host will/must "know" what to do with that window-id--embed, show, hide,

>  realize, destroy, trap and send events, etc... look, it is this

>  window-id in fact the corner stone for the gtk-socket to xembed a

>  qt-widget on the clam example.

>

>  imnsho, a GtkWidget* is not, cannot and never will be the way to

>  "toolkit agnosticism" :) why is that not obvious to you?

You seem to have forgotten, or decided to ignore, every single solitary

point brought up in this conversation over the night ;)
You are wrong, but why that is so, and what the correct solution is, has

been described plenty enough already, so I won't waste time doing so

once again. If you're just interested in blissfully ignorant trolling

about Gtk gnosticism or whatever, I'll adjust my mental ignore list

accordingly.  If you're actually interested in making the solution

happen, then let's do it:
This is Qt LV2 UIs embedded in Ingen:
http://drobilla.net/files/qt_in_ingen.png
Ingen has absolutely no idea about anything Qt or X11 related

whatsoever, and the float plugin has absolutely no idea about anything

Gtk or X11 related whatsoever. They both just do exactly what their

developers want, without any of the PITA of dealing with foreign

toolkits and window systems and embedding and whatever else. In other

words, this solution is superior.
This, of course, means I wrote that library:
http://svn.drobilla.net/lad/trunk/suil/
I have not tested the Gtk-in-Qt direction yet. You're a Qt host author.

Hint, hint. I got stuck in qtractor autohell and gave up last night.
The relevant code in Ingen is here:
http://svn.drobilla.net/lad/trunk/ingen/src/client/PluginUI.cpp
The "make a UI set" thing is a bit tedious, but is needed to avoid SLV2

<=> Suil dependency. I am thinking that maybe I should make SLV2 depend

on this library(*) and provide a simpler interface there (basically just

suil_instance_new, which is the real meat). The next SLV2 release will

break API slightly anyway. Feedback from you or any other SLV2 users

welcome, I am inclined to break the SLV2 UI related API if it makes it

obvious and trivial for hosts to do the right thing.
-dr
(* The library itself depends on no toolkits, it uses dynamically loaded

modules for all the wrapping, but this depends on packagers doing it

right)
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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