Re: [NSCursor +setHiddenUntilMouseMoves:]

[Fred Kiefer]

Adrian Robert wrote:
> Hi,
>
> While working on Emacs I found that [NSCursor 
> +setHiddenUntilMouseMoves:] wasn't working for me: whenever a key was 
> typed, the mouse reappeared as if the mouse had moved.  I traced this to 
> the following: when Emacs receives a key event, it halts GNUstep's event 
> loop to allow Emacs's own event loop to continue and process it.  In 
> NSApplication, this causes, at line 1497 in -stop:, a 'null_event' to be 
> posted to the DPSServer, supposedly to "allow one more pass through the 
> loop".  The problem is, later on during this one more pass, line 1664 
> misinterprets this as a valid event of type NSLeftMouseDown (which 
> happens to be zero in the NSEventType enumeration), and calls [NSCursor 
> -setHiddenUntilMouseMoves: NO].
>
> Two possible fixes:
>
>    1) Do not post null_event on -stop:.  I commented this line out with no
>       ill effects, though obviously more testing is needed than that.

Not sure about this, perhaps the null_event is really a left over from a 
very early state of GNUstep. If we could proof this, it would be great 
to get rid of it.

>    2) Delay the updating of [NSCursor setHiddenUntilMouseMoves:] until
>       somewhere around line 1179, i.e., AFTER the initial masked event
>       retrieval from the DPSServer where was posted.  Here, the 
> 'null_event'
>       is already filtered out by an 'if'.

This is no option, as setHiddenUntilMouseMoves: should also work when 
not in the main loop. I think we even should use  in runModalSession: 
instead of DPSGetEvent()

> #2 is the least invasive change, however it would be nice to know the 
> reasons for posting 'null_event' on -stop: and whether it is still 
> needed.  Also, if delaying showing the mouse this long is undesirable, 
> detection for 'null_event' could be inserted into the method at line 1664.

I would like to propose a third solution to the problem:

3) Make null_event different from NSLeftMouseDown.

There are two ways to achive this. Either by creating a different event 
as the null event for example an NSSystemDefined event, which we 
currently use nowhere in GNUstep. Or by changing the integer value for 
NSLeftMouseDown. On MacOSX the events have different values than the 
ones used by GNUstep at the moment. We could move over to use the same 
values (1 for NSLeftMouseDown, instead of 0).
There are two problems arising from this second solution. We will need 
to adjust code in NSEvent that relies on knowing the order of event 
types (code like "> NSLeftMouseDown" and so on) and we break binary 
compatibility with old GNUstep applications with explicit handling of 
event types. This would be a step we should announce offically before we 
do it. On the other hand there were quite a few incompatible change 
requests delayed before the last release of GNUstep and now could be the 
time to include all of them into the next release.

As a decision here may take some time, I would suggest to replace the 
current null_event with a system event and do additional changes as soon 
as we understand more of this.

Fred