Subject: Re: [linux-audio-dev] LADSPA and JACK
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 10 2002 - 20:11:32 EET
On Sunday 10 March 2002 03.10, Paul Davis wrote:
[...event loop...]
> i think there are a couple of reasons. an event loop featuring only
> one source is trivial to write. it gets more difficult when it
> involves more than one, then more difficult still if the event
> sources are of different "types", and even more difficult if you
> want to code it in a fairly platform independent way.
Yes, I'm perfectly aware of this. However, I still can't see why it
wouldn't be possible to route all input events, regardless of type,
source and interface (polling, blocking reads, signals,...) to a
single place, where everything is reformatted into the toolkit's own
event format.
SDL is doing this on all targets it supports, and although it handles
only a single window, it still supports mouse, joysticks, keyboard
etc, which means that SDL has to talk to several different APIs "at
the same time" on most platforms.
There is some overhead, perhaps, but then again, doing it this way
offers much more control to applications, while still allowing
applications to just pass all events on to a default handler - which
is actually our "second half of the event loop".
> toolkit writers these days are aiming at
> Linux/Windows/Solaris/MacOS compatibility, and this frequently
> means starting with code in a general portability library. for
> GTK+, this means glib, which encapsulates event loop control in a
> completely platform independent way. of course, it isn't used by Qt
> or FLTK, so you can't use it with either of them.
Yeah... If all toolkits had remotely similar ways of "reading"
events, and then functions to handle them, combining two toolkits in
the same applications would usually boil down to picking one of the
"event input" calls, and then hack a translator/dispatcher.
There's still one problem with that, though: How do you find out
which toolkit an event is meant for? (Well, if you never mix toolkits
within the same window, it should be relatively easy...)
> if they don't do this (and note: glib 2.0 has split the event loop
> into several smaller pieces to make it theoretically easier to
> integrate it with other approaches the same problem), then they
> push the task of platform independence on the developer, and they
> also force the developer to handle different event source types.
> keep in mind that under windows you can sleep on a semaphore
> (something sorely missing under POSIX).
That kind of stuff belongs in the "input engine" of the toolkit.
Again, using SDL as on example, it does not expose any of this to
applications, and I don't see why a toolkit would have to.
Event handling callbacks or whatever a toolkit is using, aren't
exposing the underlying implementation, and I don't see how it's
going to make a major difference to the implementation whether you
get out of the toolkit before or after events have been dispatched to
individual widgets. (Except that *before* means that applications can
potentially throw in an extra event dispatcher before the toolkit
takes control again - potentially translating and routing some events
to another toolkit.)
> what would be nicer is a toolkit that knows about various
> portability library event loops, and offers functions to provide
> access to the relevant data in formats that can be used to hook the
> toolkit into those libraries' event loops. for example, a toolkit
> would provide access to its connection to the X server as a
> g_io_channel for glib, and in some other form for, say, Qt.
Maybe we're thinking along the same lines here, at some level? :-)
> AFAIK, this hasn't happened yet. if it did, then you could use GTK+
> directly "inside" the Qt (non-GUI) event loop handler, or FLTK
> "inside" an application using glib (with or without GTK+).
I think one reason for that is licensing issues. Some toolkits just
wouldn't be usable together without legal issues, as they would
technically be linked *together*, just not linked to an application.
GPL + LGPL should be fine, though, a long as you consider the "mix"
as GPL... Thus, most of our favourite toolkits should mix just fine,
as long as we stick to the "most restrictive" of the licences.
However, the strongest reason is probably that there hasn't been
enough interest. (As usual with Free/Open Source!) When thinking
about it, that isn't too surprising, as it hasn't really mattered to
anyone - not until now, that "plugin technology" is creeping into
lots of different applications.
> and pigs might fly .... :(
Maybe it's time they started practicing?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Sun Mar 10 2002 - 20:02:58 EET