Subject: Re: [linux-audio-dev] Small example of GUI in .so-files and a more thorough descripting of previous post
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 19:55:18 EST
>1) Check if the plugin has a frontend assigned to it. The host determines
>whether or not it currently supports the requested toolkit, based on
>requirements grabbed from plugin-implementation.
>
>2) If not (or if the user so desires) it checks for an XML-description of
>the UI.
>
>3) If no description is specifies, the host can at will try to present the
>user with a UI that's based on plugin internals.
OK, thats much clearer. My hope was that the plugin could use *any*
toolkit independently of the host ... I understand that this is hard
to do, but that doesn't me from wishing ...
>Personally, I would like to see something that populates a GNOME-canvas (or
>similar) based on a detailed XML-description for most plugins. This is
>obviosly not a good way to do 3D, tho.
Until the GNOME canvas becomes part of GTK, I have resolved to have
nothing to do with it ;) Its a nice widget, for sure, but I don't want
to depend on all the GNOME stuff as well. It annoys me that the GNOME
folk took functionality that even they admit should be in GTK, but
made it part of GNOME instead. Off-topic alert ...
>If I understand you correctly, you're saying that you would like to fatten
>the second layer, by making the host-application add widgets to the user
>interface. I think this is a great idea.
Errr ... I'm not sure I understand your attempt to understand me :)
Ideally, I'd like to see the host play an absolute minimum role in all
things GUI. However, I'm all for libraries that extend common toolkits
to provide useful ("domain specific") widgets for "our sort of thing".
[ ... clipped clip elided ... ]
>This looks like multiple processes to me, do you/we really want to start
>with IPC just to give the plugin a graphical user interface? Am I focusing
>on the wrong part of the post here? Making the plugin-frontend implement its
>own event-collection and passing it through a socket-interface (or pipes, or
>whatever) seems like a rather strange approach to me.
No, the name is misleading. There is no socket in the sense of
IPC. The GTK folks could/should have called it a GtkDock or something.
Its not the multiple processes part that I liked, its the idea of one
object installing its window into another object's GUI framework. For
our purposes, I think of the objects as plugin GUI handlers and some
sort of lowlevel GUI provision in the host. The host would say
either:
1) your X Window window-id is XXXXXX, do what you want with it
OR
2) please send me your X Window window-id
But this is hard to do, I think.
>One of the goals should probably be to have the plugin and the
>plugin-frontend run in the same process-space?
certainly.
>What I meant is _not_ that the host application implements or links to
>multiple widgetsets,
Right, I misunderstood this at the beginning.
even though there are possibly cases where this can be
>done (especially if one takes the step to abstract multiple interfaces into
>a single API).
This is exactly what I don't want. We have at least 3 widget sets with
some support (GTK/Gtk--, Qt, FLTK), all of them having already attempt
to "abstract what a GUI API should be". We should *not* do it over
again.
\begin{rant}
This is something that really annoys me about, say the glib
threads interface. Whats wrong with POSIX P.1003 as an API for
portable threads ? Oh, Windows doesn't do it right, or Solaris has
some minor quirk. Well, I say "tough" - you don't support the portable
API, and you're not supported. Constantly implementing layer after
layer to cover over the cracks and differences is a mistake, IMHO.
\end{rant}.
>>From my point of view it makes sense, I'm not really sure how many plugins
>you really see needing to implement their own plugin-frontends (you obviosly
>know a lot more than me about this, having done a lot of work on Quasimodo),
>but looking at Buzz, for instance, which only uses the third option, I would
>think XML will go a long way for most plugins.
My experience so far has been that every module I write could use a
new widget type, but the need grows less and less as I add more to
libgtkmmext. I think that if you provide a rich, domain-specific set
of widgets for audio apps, an XML spec will work for almost
everything.
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST