On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis wrote:
and just to go a little deeper ... this in turn is caused in largest
part by the absence of a single "event loop" abstraction/API on "bare"
unix systems. windows and OS X defined this relatively early in their
lifetimes (OS X from before birth, windows many, many versions back).
This means that there just isn't a clear path to adding "plugins" that
have to interact with event processing on a "bare" unix system. its
not that it can't be done, its just messy. what has happened instead
is that we continue to have different classes of applications dealing
with event-driven programming in very different ways:
* command line apps that don't interact with a mouse+graphical
display at all, just kbd stuff
* applications that use Xlib or some very old widget library that
is very close to the Xlib API in this regard
* applications that use Qt's event loop
* applications that use glib's event loop
* applications that use Qt using glib's event loop (!)
* applications using some other GUI toolkit's event loop
By contrast, on OS X, there is one event loop abstraction, and no
matter what program you use, if it uses event-driven programming (as
almost any user-driven app will do), it uses that single abstraction
at some layer. Thus, dynamically loading a "plugin" that has a GUI
that has to be a part of the overall app is easy - its obvious what
the "touching points" between the host and the plugin are.
This just isn't true on "bare" unix systems, where the insistence on
choice and flexibility and "developer driven" approaches to almost
everything have ruled out such a common core.
Linux-audio-dev mailing list