Remove legacy items from .gitignore
The items being removed were added in da80902 for temporary files generated by `make`. But the Makefile is later removed in #36, and thus these items are no longer needed.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/148)
<!-- Reviewable:end -->
Implemented NSTabView and NSTabViewItem. Simple example included. Again :)
Hi,
A long time ago I created PR #62, sadly life got in the way and I was unable fix the issues with the PR.
I've updated the code to the current codebase.
Hope this is useful for someone.
Thanks!
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/139)
<!-- Reviewable:end -->
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.
Paul Rouget
