23 Feb
2011
23 Feb
'11
12:44 p.m.
On Wed, Feb 23, 2011 at 11:03:52AM +0000, Rui Nuno Capela wrote:
On Wed, 23 Feb 2011 10:57:25 +0100, torbenh
<torbenh(a)gmx.de> wrote:
well it will have a specialised qt shell for the other toolkits too.
On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui Nuno
Capela wrote:
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. On Wed, 23 Feb 2011 02:58:56 -0500, David
Robillard <d(a)drobilla.net>
wrote:
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 :)
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 :/
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