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

 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?

 cya

-- 
 rncbc aka Rui Nuno Capela
 rncbc@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev