Re: about RunLoop, joystick support and so on

[Richard Frith-Macdonald]

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.

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