Re: [linux-audio-dev] LADSPA and JACK

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA and JACK
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Mar 10 2002 - 04:10:10 EET


>> The problem isn't making chrome easy. It isn't the available
>> widgets. Its the presence of an event loop that is incompatible
>> with another toolkit. At least, thats the problem that I see and
>> was referring to.
 [ ... ]
>Anyway, *why* are people doing this "hidden event loop" thing over
>and over again...? I've implemented several simple GUI toolkits for
>various environments, and I haven't really seen a case where chosing
>between that model and an "open" read_event() + process_event() style
>interface is critical to the implementation. It's basically just a
>matter of wrapping some parts of the loop up as API calls, and then
>moving the loop into the application. I have yet to see a platform
>where it's not possible to use either approach.

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.

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.

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).

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.

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+).

and pigs might fly .... :(

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Mar 10 2002 - 04:01:04 EET