appkit: Lengthen `NSAnyEventMask` to (-1 as u64) rather than (-1 as u32), to fix the problem whereby windows don't reappear and don't appear on top on startup.
The window restoration feature in Mac OS X from Lion onward prevents
windows from appearing until restoration is complete and the app is
launched. Internally, the persistent UI restorer detects the app launch
by listening to the Carbon event `kAEOpenApplication`, which, as an
Apple event, has the event class `kEventClassAppleEvent`.
Like `-[NSApplication run]` does, Glutin uses the method
`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]` to
pump the application event loop. The event mask provided is an
`NSEventMask`; events that do not match this mask are filtered out. When
pumping the Carbon event loop, the Cocoa framework internally converts
this `NSEventMask` to a Carbon event mask. The logic to perform this
conversion proceeds in two steps:
1. If the provided `NSEventMask` is exactly equal to `NSAnyEventMask`,
then the rest of the logic is skipped and the resulting Carbon event
mask is a null mask--i.e. a mask that matches all events.
2. Otherwise, the framework constructs a blank Carbon mask--that is, a
mask that matches no events at all. The various bits of the
`NSEventMask` are examined, translated to their Carbon equivalents, and
added to the mask. Then that Carbon mask is returned.
In Glutin prior to this patch, our definition of `NSAnyEventMask` was a
mask that effectively matched all events but was not equal to the real
`NSAnyEventMask` that, for example, `-[NSApplication run]` supplies to
`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]`. This
means that our code causes the system to take path (2) above, whereas
standard Cocoa apps take path (1). Now it might seem that these paths
are equivalent, but in fact they are very different. This is because
*there are classes of Carbon events that do not correspond to Cocoa
events selectable via `NSEventMask`*. One of these Carbon-only event
types is Apple events.
This fact is what made Glutin apps prior to this patch go wrong. The
Carbon framework would deliver the `kAEOpenApplication` event to the
application, but it was always masked out and ignored because the
`NSEventMask` we supplied to `-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]` did not translate to a
Carbon event mask that included Apple events. This, in turn, caused the
persistent UI restorer to never notice that the app finished launching.
Thus the flag that inhibited windows from appearing would never be
cleared, and all windows would end up invisible.
This patch fixes the issue by lengthening `NSAnyEventMask` to its true
64-bit value, allowing the expected Carbon event filter to be used
during app startup and enabling the app startup event to be handled
properly.
r? @metajack
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/131)
<!-- Reviewable:end -->
u32), to fix the problem whereby windows don't reappear and don't appear
on top on startup.
The window restoration feature in Mac OS X from Lion onward prevents
windows from appearing until restoration is complete and the app is
launched. Internally, the persistent UI restorer detects the app launch
by listening to the Carbon event `kAEOpenApplication`, which, as an
Apple event, has the event class `kEventClassAppleEvent`.
Like `-[NSApplication run]` does, Glutin uses the method
`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]` to
pump the application event loop. The event mask provided is an
`NSEventMask`; events that do not match this mask are filtered out. When
pumping the Carbon event loop, the Cocoa framework internally converts
this `NSEventMask` to a Carbon event mask. The logic to perform this
conversion proceeds in two steps:
1. If the provided `NSEventMask` is exactly equal to `NSAnyEventMask`,
then the rest of the logic is skipped and the resulting Carbon event
mask is a null mask--i.e. a mask that matches all events.
2. Otherwise, the framework constructs a blank Carbon mask--that is, a
mask that matches no events at all. The various bits of the
`NSEventMask` are examined, translated to their Carbon equivalents, and
added to the mask. Then that Carbon mask is returned.
In Glutin prior to this patch, our definition of `NSAnyEventMask` was a
mask that effectively matched all events but was not equal to the real
`NSAnyEventMask` that, for example, `-[NSApplication run]` supplies to
`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]`. This
means that our code causes the system to take path (2) above, whereas
standard Cocoa apps take path (1). Now it might seem that these paths
are equivalent, but in fact they are very different. This is because
*there are classes of Carbon events that do not correspond to Cocoa
events selectable via `NSEventMask`*. One of these Carbon-only event
types is Apple events.
This fact is what made Glutin apps prior to this patch go wrong. The
Carbon framework would deliver the `kAEOpenApplication` event to the
application, but it was always masked out and ignored because the
`NSEventMask` we supplied to `-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]` did not translate to a
Carbon event mask that included Apple events. This, in turn, caused the
persistent UI restorer to never notice that the app finished launching.
Thus the flag that inhibited windows from appearing would never be
cleared, and all windows would end up invisible.
This patch fixes the issue by lengthening `NSAnyEventMask` to its true
64-bit value, allowing the expected Carbon event filter to be used
during app startup and enabling the app startup event to be handled
properly.
Version 0.3.4 should be yanked because bitflags >= 0.6 is incompatible with Rust <1.8
and this breaks downstream crates.
Unfortunately, we can't depend on bitflags >=0.5, <0.8 because it doesn't compile with
bitflags 0.5-6 because of https://github.com/rust-lang-nursery/bitflags/issues/39.
Update objc dependency to 0.2
I just published version 0.2 of the objc crate, changelog here: https://github.com/SSheldon/rust-objc/blob/master/CHANGELOG.md#020
Main differences are gnustep support, (optionally) more type checking, removed the libc dependency, and fixed a bug in the space reserved for ivars when declaring classes.
No changes required to cocoa, but since it exports a lot of objc types this update is a breaking change and requires a version bump to 0.3.
Testing done: verified everything compiles, tests pass, hello_world example still works, and also tested glutin against objc 0.2.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/120)
<!-- Reviewable:end -->
bors-servo
