Re: about RunLoop, joystick support and so on

[Xavier Glattard]

Fred Kiefer <fredkiefer <at> gmx.de> writes:

> 
> Richard Frith-Macdonald schrieb:
> > 
> > On 9 Feb 2007, at 17:55, Xavier Glattard wrote:
> > 
> >>
> >> phew !
> >>
> >> My brain boiled three times (and fried twice) before
> >> i understand anything...
> >> And many pieces of code are still quite obscure to me.
> >> I would not be a very good compiler.
> >> But i found out what you talk about.
> >>
> >> Where you see a performance tweak I see... hum...
> >> In french i would said 'un sac de noeuds' 
> >> (bag of knots)
> > 
> > Well, I'm not sure (would probably need to find the author of that bit
> > of code and ask them), but I can't see any other reason for bypassing
> > the run loop like that.  I *think* all the calls to the 'calback' method
> > could probably be commented out.
> > 
> 
> As I was the original author of the GNUstep Windows backend code I had a
> quick look myself. Much has changed here since I last looked at this
> code, but the callback: method seems to have stayed mostly the same.
> Which of course is bad, when everything around it has changed. When I
> originally wrote that code there wasn't much support for Windows message
> loops in base and not much of it in Cygwin or MinGW. What I implemented
> at that time as direct polling for messages, the code would ask windows
> from time to time, if new messages for the application where available.
> This was a horrible hack, but the best I could do at that time. Later on
> we added the handling for the Cygwin special file "/dev/windows" and
> then the code for Windows message handling in base was improved. All of
> this made the callback: method in back obsolete, but somehow this was
> missed out by the programmers doing these local changes.
> It is great that it finally has been noticed by you. This could lead to
> some simplifications in the code of Win32Server. And while we are at
> that, why not clean up the code for the different implementations of
> GSRunLoopCtxt as well? To me it looks like there is quite a lot of
> duplication going on here, which might be reduced by using subclasses,
> but then, what do I know about that...
> 
> Fred
> 

The state of this code is typically due to many changes by many developpers...
If ones need a proof that GNUstep is opensource, here it is ;-)

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.

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 ?). Moreover
-receivedEvent is called many times from inside the server with null arguments
(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.

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

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 ;-)

Xavier