On Tue, Nov 24, 2009 at 2:24 PM, wrote:
> An event loop (as I use the term) is just something of the
> In process_event() the first selection would be on event
not at all. what i mean by the event loop is exactly the same as you.
but any general purpose event loop needs way to add and remove event
sources, which can include additional file descriptors, timeouts, the
concept of "idle" and other more esoteric things. so at the core of
any GTK application, for example, is the extremely general purpose
glib event loop. the connection to the X11 display server is just one
source of events that it handles (though clearly, for a GTK app, an
> The problem I pointed out exists when the 'real' loop (in
you can view it that way around if you wish. but i think that its
equally accurate to say that things start with a particular event loop
(in the C, C++ sense) and then the toolkit is built around it.
> He should e.g. not be forced to
the glib event loop has completely abstract notions of what an event
source is. an event source simply has a few simply functions like
"prepare", "ready" and "dispatch".
> The loop as written above is a multiplexer (the wait_for_events()),
the GTK (and now Qt) toolkits simply add handlers for events that come
from the "X11 event source" that they added early in the program's
life. the event loop can be handling other entirely different event
sources using entirely different code - but it is all now centralized
by the single glib event loop. the event loop itself doesn't really
care about what the event types are, or what handles them.
> What do you mean by 'raw events', or a 'normal event stream' ?
raw events: whatever actually happened somewhere in the computer to
make an event source believe that a new event was ready. could be an
X11 event, could be a byte arriving on an arbitrary byte-oriented
communication endpoint, the creation or modification of a file, etc.
"normal event stream" : whatever the GUI toolkit passes around to widgets.
> What you write seems to suggest that both the GTK and Qt
Thats more or less correct, yes.
>This will work if
And they can, by using a variety of mechanisms, none of which are
> All raw X events have
for X events, yes. But the event loop handles things other than X events.
>But again this has nothing do
Agreed. What I consider central is the idea of set of event sources,
and event loop and handlers for events that are injected into the
loop. There is no common framework for this on Unix, there never has
been and as long design policy is made by developers who value choice
and flexibility over single frameworks that enforce consistency, there
almost certainly never will be. Hell, on Unix you can't even wait for
file I/O and/or a signal in the same thread.
Again, contrast this to the situation on OS X where time and again,
when I am wondering just how you are supposed to integrate a
particular kind of event-driven programming into some code, it all
ultimately comes back to a CFRunLoop (which conceptually is not far
from being a thread, although its not).
The unix programming model is awesome for data driven programming. It
just hasn't ever stepped up to provide these kinds of abstractions for
event driven programming.
Linux-audio-dev mailing list