[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about RunLoop, joystick support and so on

From: Richard Frith-Macdonald
Subject: Re: about RunLoop, joystick support and so on
Date: Mon, 12 Feb 2007 11:57:32 +0000

On 11 Feb 2007, at 19:18, Xavier Glattard wrote:

Another oddity of the win32 backend is the use of a good old window procedure. So the events are dispatched twice : first by some calls to DispatchMessage (always to the same window procedure) and then by NSApplication. I'm sure there
is a good reason for that but i can't see it.

I believe that's recommended windows programming. I think DispatchMessage gives other windows code a chance to make use of the information in the messages. So what's actually happening here is that the backend code looks at the messages and does what it wants with them, then it passes them on for other (windows) code to deal with them as well.

As we talk about runLoop and backend you should have a look at XGServerEvent in the X11 backend. The server registers itself in the runLoop but - receivedEvent
doen't use its arguments and pick the event right from X11 with
XPending/XNextEvent (is there an other way to get x11 events ?).

It doesn't use its arguments because it doesb't need any of them ... and it DOES pick the X event from the queue using XPendsing and XNextEvent.

-receivedEvent is called many times from inside the server with null arguments

Yes ... at places where the code just wants to check the X event queue.

(does -receivedEvent really called by the runLoop ?). Sounds weird ?
AFA I understand the backend doesn't use the runLoop the way it should, neither
win32 neither x11. It looks like the implementation of the use of
GSRunLoopWatcher as never been achieved.

No, in fact both backends use the runloop and both use GSRunLoopWatcher which works perfectly. The fact that both backends at certain points chose to poll their respective message queues without asking the runloop to tell them whether there is anything available does not imply anything about

Richard tells Apple is working on a new runLoop mechanism. IMHO rewrite a
backend based on GSRunLoopWatcher or only rewrite GSRunLoopWatcher
implementation (if you really plan to switch to an Apple compatible mechanism
later) would be a waste of time.

According to Apple site NSStream is part of Cocoa Foundations since MacOS X 10.3
and has not been updated since 2006-05-23.
I think of a backend event interface based on NSStream. NSStream would be modified later to use the successor of GSRunLoopWatcher (or nothing : it seems
to me that NSStream and GSRunLoopWatcher do the same job).

Actually I'm *hoping* that Apple will release something to specify clearly how an NSStream subclass (other than those subclasses Apple provide of course) can be tied in to an NSRunLoop. Such an API would be able to take the place of GSRunLoopWatcher. Without that API you can't write new subclasses of NSStream and get their event handing code called when an event becomes available, you can only base code on existing NSStream implementations. eg. if your joystick driver provides an interface like a file (normal on unix and quite common on windows) then you can probably just open an input stream using the relevant file device, but if the joystick has to be accessed signals or shared memory then you have to use the GSRunLoopWatcher api directly.

Of course, if you just get joystick messages/events via the windows message or X events system and you just want to generate joystick NSEvent objects for GUI applications, then you can ignore all this low level stuff and just add some code to the backend display server code where it converts windows messages or X events to NSEvents.

Something like that :

                 |-- GSWin32EventStream <GSBackendEventStream>
NSInputStream <--|
                 |-- GSX11EventStream   <GSBackendEventStream>

[GSDisplayServer -eventStream] would be called by NSApp to get a
NSInputStream<GSBackendEventStream>. Then NSApp would register itself as the
delegate of this NSStream and schedule it in the runLoop.

A GSX11EventStream would get the event with XPending/XNextEvent when the runLoop
polls, then translate it into a NSEvent and send it back to the loop.
A GSWin32EventStream would get the event from another NSStream (which would only select the window message from PeekMessage), then translate and send it back to
the loop.

Not so simple ? Yeah probably ;-)

That sounds quite nice, but basically it's reorganising the incoming half of the GSDisplayServer so that instead of adding events to the application's event queue directly, it provides a stream of NSEvent objects for the application to put in the event queue itsself. In both cases the internal workings would need to be pretty much the same ... 1. ask the runloop to inform the GSDisplayServer instance when there is data available 2. when data is available, pull it off the X event queue or windows message queue 3. make sense of the data, generating the corresponding NSEvent object or objects (if any) 4. add the event to the event queue (current implementation) or store the event in memory owned by a stream object and trigger an event handler in the NSApplication code so that the NSApplication can read the event from the stream and put it in the event queue.

If different sources of NSEvents were going to be used by lots of different pieces of code, the encapsulation of all the work inside a stream interface would be really useful/clean/simple. However, in practice we have a single source of events for a display server, and all those events go into the application's event queue and are pulled out of that queue by the code which needs the events, and this model of operation is inherent in the AppKit/GUI API. So I don't think wrapping events in an NSStream subclass before putting them in the event queue is any help.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]