24 Nov
2009
24 Nov
'09
3:28 p.m.
On Tue, Nov 24, 2009 at 12:55:39PM -0500, Paul Davis wrote:
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.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
I'm not quite sure what you mean, but my initial
interpretation of
this suggests a goal that is a little absurd to me. The design of the
event loop is where the design of a GUI toolkit starts, because the
event loop needs to be able to handle things other than X11 (or Aqua
or GDI or whatever) events. If you use an event loop that doesn't do
this well, then you rule out a class of moderately complex
applications from being implemented in the most obvious way.
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
form
while (running)
{
E = wait_for_events();
process_event(E);
}
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
does).
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
them.
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
on X11.
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
means they will translate X11 events and other data
structures from/into their 'portable' format. That's
OK as if they would also provide these translations
as separate functions which then could be used at the
interface between a host and a plugin using different
toolkits.
I don't think that would really address the issue. Take a look at what
Qt did to allow use of the glib event loop, and thus, by extension,
GTK widgets from within a Qt application. It has nothing to do with
event translation - you simply deliver the raw events from whatever
source (or even, just "i/o") into the relevant event loop handlers and
the translation happens in the same place that it would normally do
so. There is no reason to expose this to any higher level - the plugin
is not interested in doing explicit translation in its GUI - it just
wants a normal event stream delivered to it.