Subject: [linux-audio-dev] LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: maarten de boer (maarten.deboer_AT_iua.upf.es)
Date: to maalis 09 2000 - 12:56:53 EST
> I think this is an exceptionally bad idea. the vstGUI model is all
> wrong. The only way that a host might conceivably get involved with
> providing a GUI to a plugin is to give it a handle to either an
> XWindow, or if the host was toolkit-specific, some toolkit specific
On the other hand, providing a basic set GUI functions has also
some advantages
- unified look & feel
- memory footage
- compatibility issues (and possible crossplatformness)
But of course, I want to use FLTK, you want to use Gtk--, somebody
want to use Qt, etc. I guess you're right. Your proposed approach
will at least avoid another GUI war :-)
> widget. GTK has a fairly nice "GtkSocket/GtkPlug" pair of widgets just
> for this kind of purpose. Sharing a connection to an X host makes a
> little bit of sense (though actually, not much, because very few X
> servers are truly MT-safe, and the GUI code does not and *cannot* be
> allowed to run in the host thread).
I don't understand this very well.
Don't you mean in the plugin thread?
Anyway, there should be a seperate GUI thread, that's for sure.
So, how would an osciloscope plugin work? This is how I would
do it. The osciloscope copies it's input into a circular buffer
that is big enough so that writing in it (copy from input)
will not interfear with reading from it (displaying it). The
graphical stuff is called periodically from the gui thread, and
that's it. Does that seem the correct approach?
The host should pass raw X events to the plugin, and the plugin
passes these to the appropiate event dispatch function of the
GUI library it uses. I think FLTK can do this with no problems.
And no MT-safety issues here, right?
Maarten
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:05 EST