linuxaudio.org

On Wed, Feb 23, 2011 at 11:03:52AM +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.

well it will have a specialised qt shell for the other toolkits too.
>

quoted text
> 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?

nobody said that.

the library would hand you a Qt widget.
this would be a QtWidget wrapping an external ui, the Qt Widget from a

qt gui, or a gtk widget wrapped in a Qt shell. 
you already have more experience with this wrapping stuff. so far i have

gathered that you have problems with wrapping gtkmm guis, or something ?
this needs solving on the gtk side.

lets please move this discussion to naming the problems, instead of

claiming that it doesnt work.
the goal of the library, is to make the host not need to deal with the

nastities of embedding stuff.

(there are a few broken windowmanagers out there which dont really

support xembed) 
the host will just open the library, and if the library supports the

hosts toolkit, it will hand it out a native widget.

or if thats not possible for some reasons, it will just make the plug

open a toplevel window.
most of the code to do this, is already there. its just scattered.

we just need to put it into a central library with some dlopen stuff, so

that _you_ dont need to link against gtk :)
--

torben Hohn

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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