Allan?
Begin forwarded message:
From: Apple Developer Bug Reporting devbugs@apple.com Date: November 15, 2007 12:41:40 PM PST To: steve@geeksrus.com Subject: Attention: Bug ID 5551893: Spaces needs hints for windows
Hi Steve,
This is a courtesy email regarding Bug ID# 5551893.
<GMT15-Nov-2007 20:37:26GMT> Vanaja Pasumarthi: Engineering has provided the following feedback regarding this issue:
There is an SPI hint that TextMate can use.
NSWindowCollectionBehaviorMoveToActiveSpace
Bug reports requiring your update will appear under ‘My Originated Problems’. Please review this bug report and provide the requested information via the Apple Bug Reporter. Once your report has been updated, Engineering will be alerted of the new information.
Thank you for your assistance in helping us discover and isolate bugs within our products.
Best Regards,
Vanaja Pasumarthi Apple Developer Connection Worldwide Developer Relations
THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE
Bug ID #: 5551893 Bug Title: Spaces needs hints for windows
<GMT21-Oct-2007 18:17:34GMT> Steve Riggins: Summary: TextMate's find dialog opens on wrong space (and btw can you fix radar, this is twice now it has failed to submit a bug report and lost my work. Clipboard ftw).
Steps to Reproduce:
- Go to Space 1
- Launch TextMate
- Switch to space 3
- Command-Space to open LaunchBar (or command-control-space if using
default)
- Open demo file
- Command-F
Expected Results: expected find dialog to open on current space
Actual Results: Space switched to space 1 and then dialog opened.
Notes: This seems to be due to TextMate hiding/showing the Find dialog in order to keep all of it's state (size of text fields, etc) There should be a API hint or NIB hint to tell spaces to show this window on the current space, vs. last space it was on.
On 15 Nov 2007, at 22:30, Steven W Riggins wrote:
Allan?
Next build will set NSWindowCollectionBehaviorMoveToActiveSpace for the find windows.
Though it appears to be buggy, as in, when you move TM to a new space, then hit ⌘F, the find panel will still open in the old space, but focus will not move (like it does now) and pressing ⌘F again, will move the find dialog.
Which makes me think, maybe the default behavior is also buggy because of some term mixup, as the explanation for this (non-default) mode is (emphasis mine):
Making the window _active_ does not cause a space switch; the window switches to the active space
Notice here, that they say “active” not “visible”. I can justify that making a window _active_ should not move the window to the active space (but rather switch to the space of the window). But I find it hard to justify that making a window _visible_, should not move it to the active space.
The mode they suggest, talks about the former, not the latter, and it appears to actually not do the latter (but likely that is a bug, as making the find window visible also makes it active).
I filed a bug on NSWindowCollectionBehaviorMoveToActiveSpace and I will likely file one on the default behavior of windows, but please add the above ‘reply’ to your report, if you don’t mind.
-
Allan Odgaard -
Steven W Riggins