On Tue, Nov 24, 2009 at 12:55:39PM -0500, Paul Davis wrote:
> I'm not quite sure what you mean, but my initial interpretation of
Seems we are saying the same thing in different terminology, and
using different meanings of the same term such as 'even loop'.
An event loop (as I use the term) is just something of the
E = wait_for_events();
which in a typical multi-threaded and event-driven program
you would find in some form in each thread.
Unless you like using lots of mutexes, it is convenient to
handle most events that have an impact on the global state
of a app in a single thread. This could be mix of X11 events,
notifications from you RT-audio thread, messages from network
threads, or those doing non-RT calculations, etc.
This means that wait_for_events() has to wait for a number
of different things at the same time. One traditional way
to do this is using poll() or select(() on a set of fds.
Or if most of the event sources are threads it could be
done using a inter-thread message service not based on fds
but directly on low-level threading primitives such as
semaphores or condition variables (this is what clxthreads
In process_event() the first selection would be on event
origin. Messages from you other threads for example would
get handled by whatever code you provide for that, while
X11 events would be handled by code provided by the GUI
toolset, delivering them somehow to the objects that need
>From what you write I understand that you call this handling
of X11 events 'the event loop' of a the toolset, which is of
course something quite different than what I understand by
this term and try to explain here. What you call 'the event
loop' (in the discussion about linking GTK and Qt) is not
the loop - it is the dispatching and handling of X11 events.
I agree fully that a developer normally does not wants to
meddle with this - he's using a GUI toolset to take that
work away from him.
The problem I pointed out exists when the 'real' loop (in
the C, C++ sense), in other words the while() thing above,
is completely absorbed into a GUI toolkit. A toolkit should
probably provide this as a convenience, but the user should
also have the option to open up this code and mix in his own
events in any way he prefers. He should e.g. not be forced to
translate all his event/messages sources into e.g. a poll()
based framework just because the toolkit uses a fd to wait
The loop as written above is a multiplexer (the wait_for_events()),
and a demultiplexer (the process_event()). The GUI toolkit is on
an input to the first and on an output of the second. The only
thing that should matter is that the link between these two
points exists, not how it is implemented.
> > 2. Almost all toolkits try to be cross-platform. Which
What do you mean by 'raw events', or a 'normal event stream' ?
Both toolkits would normally represent X11 events in different
ways (GTK seems to remain close to the 'raw' X11 form, don't
know about Qt). They would also represent basic objects (such as
'a window') in different ways. If an event is dispatched in its
GTK form but in the end has to be handled by a Qt object then
some translation will be required somewhere. And indeed the plugin
will not want to do this itself.
What you write seems to suggest that both the GTK and Qt
dispatching mechanism exist at the same time, that they don't
really interface to each other, but that raw X events get
handled either by the one or the other. This will work if
they can somehow work out who should handle what without
tripping on things from the other one. All raw X events have
a destination window ID, and for most cases testing on that
would be all that's required. But again this has nothing do
to with how the event loop (in my sense) is organised.
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Linux-audio-dev mailing list