Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Wed, 2011-02-23 at 11:03 +0000, Rui Nuno Capela wrote:
> On Wed, 23 Feb 2011 10:57:25 +0100, torbenh <torbenh@email-addr-hidden> 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 <d@email-addr-hidden>
> >> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Feb 23 20:15:02 2011