[LAD] [ANN] IR: LV2 Convolution Reverb

[Rui Nuno Capela]

 On Wed, 23 Feb 2011 10:57:25 +0100, torbenh <torbenh at gmx.de> 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 at drobilla.net>
>> 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 at rncbc.org