Re: [LAD] LADI

On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis <paul(a)linuxaudiosystems.com> 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.