I love the new "Resume" feature in Lion. After a restart window size and position is exactly how you left it. But during development this is a bit annoying.
If I resize a window in the Interface Builder and restart my application it doesn't have the new size but the old size.
In the past you had to set the AUTOSAVE property to get this kind of behavior but with Resume it all happens automatically. Can I disable resume for my application somehow?
Yes. As documented in the Lion AppKit release notes, you can set the ApplePersistenceIgnoreState user default for your application. (The docs imply that the value isn't significant; it just needs to be set to something.)
An easy way to do this for debug runs only, while preserving the state restoration feature when you use your app normally, is to set it in Xcode. In your scheme's Run action, set a command-line argument for -ApplePersistenceIgnoreState, and, immediately after it, another one with the value (e.g., YES). This makes use of AppKit's feature of reading user defaults from the command-line.
Related
I have a small Swift-based Cocoa app that I'm writing. It's a single window app, something like Spotlight/QuickSilver/Alfred. It's set as NSApplicationActivationPolicyAccessory (docs) (though I've tried the same thing using LSUIElement, which is equivalent). It's activated via a global hot key.
Everything works well, except that when it's active I can't hide the application using NSRunningApplication.currentApplication().hide().
The docs for the hide method say "The property of this value will be NO if the application has already quit, or if of a type that is unable to be hidden." (emphasis mine), and I'm getting a NO back (though I'm actually using Swift, so I'm getting false).
I can understand why a NSApplicationActivationPolicyProhibited app wouldn't be able to be hidden, since it's never active, but it's confusing to me that this would be the case with NSApplicationActivationPolicyAccessory too.
I tried myWindow.orderOut(self);, but that just hides the window without hiding my application and returning focus to the previous app.
I do store a reference to the previously active application, so if need be I can manually activate that app again, but I'm hoping there is a cleaner method of doing this.
Use NSApplication.sharedApplication().hide(nil). One would normally address the application object (instance of NSApplication) rather than an instance of NSRunningApplication to operate on the current app.
The manual solution is to store a reference to the previously active NSRunningApplication instance (called previouslyActiveApplication below), and then activate it when you want to deactivate your NSApplicationActivationPolicyAccessory application, like so:
previouslyActiveApplication!.activateWithOptions(NSApplicationActivationOptions.ActivateIgnoringOtherApps);
I am implementing a Cocoa application which supports the fullscreen mode. If the user quits while working on the fullscreen mode, I need to start the application in fullscreen mode,
While starting the application I check whether the application should start in fullscreen mode then call the toggleFullScreen: on NSWindow. Then the, application goes to the fullscreen mode and comes back to the normal window mode.
User can go to the full screen mode while working without any problem. Any tips on what's going wrong on this?
Make sure you really want to do this. Since Lion, there is a window restoration API that you should be using. See Any NSWindowRestoration examples? for how to use it. The caveat is that if "Close windows when quitting an application" in System Preferences is checked (which it is checked by default since 10.8), the window can only be restored upon reboot if the user chooses to do so.
If the user did not opt in for the window restoration setting throughout the OS across quitting applications, then generally you do not have to expect the window of your app to be restored for them. However, if you think you have a good reason otherwise, then I suggest invoking toggleFullScreen: after windowDidLoad: is called. I can only guess that you're calling it too soon and the window autosave might get in the way. It'd be helpful if you showed the relevant code.
Regardless, you should be implementing window restoration anyway and in the case of the window being restored by the API, you simply don't do anything.
In Mac Lion, the scroll bar hides itself after a few seconds if no activity occurs. I have written an apple script to modify that behavior. I have to turn on the radio button every time my app launches. My question is, I have a cocoa application. Is it possible to keep the scroll enabled for the application always with out having to change the settings in system preferences.I don't want to enable for all the other apps always. And is the only way via the applescript. Or is there a defaults write to enable the scroll bars in lion ?.
I don't know about a defaults key to set up the style.
When you change the Appearance preference panel's "Show scroll bars", all the NSScrollView instances are notified and receive a setScrollerStyle: with the new style (through the NSPreferredScrollerStyleDidChangeNotification notification).
You can achieve the same result by explictly calling setScrollerStyle: on the NSScrollView with the NSScrollerStyleLegacy scroller style.
You can write to defaults to accomplish this.
The key is AppleShowScrollBars and it has three possible values:
Automatic
WhenScrolling
Always
To set it system-wide from the command line, you could do:
defaults write -g AppleShowScrollBars Always
It can also be done programmatically by modifying preferences in any of various ways. It can get a little tricky depending on application sandboxing. This blog post explains it in more detail.
I'm dipping my feet into Cocoa for the first time.
Here's a simple question. OS X Lion supports Resuming of window state when an app is terminated and relaunched. Okay, good and fine.
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not? Or do I have to manage it myself by saving the information in the documents' files?)
For instance, iWork '09 apps do do this sort of thing: if you close a saved document and reopen it, it will restore the window size, location, and scroller position. I don't know if it does this using Lion's Resume per se.
But, in contrast, OS X Lion's TextEdit restores windows when it is quit and restarted, but it does not remember window states when you close a document and reopen it. This makes me suspicious that using Resume without quitting might not be possible automatically (since maybe Pages keeps window states in its proprietary file format, but TextEdit doesn't since it uses plain text, RTF, HTML, etc. files).
I don't have access to the WWDC 2011 videos yet, and neither the OS X release notes, the OS X Application Programming Guide, nor the NSWindowRestoration API docs talk about this specifically.
So the question again: automatically remembering the state of a document window after closing and reopening it without quitting the app (like iWork does)...does Lion's Restore support this?
Thanks a lot!
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not?
Not unassisted, no.
Or do I have to manage it myself by saving the information in the documents' files?)
Or somewhere else, yes.
My untested suggestion is to try using the window-restoration protocol yourself. When closing, send yourself encodeRestorableStateWithCoder:, then stash that data in your document (or wherever you want). When opening a document, if it has restorable state information, pass it to restoreStateWithCoder:.
My app at launch time prompts the user with a template chooser, this works fine on Snow Leopard but on Lion the window never appears maybe due to restoration behaviour.
My app is NSDocument based and I use NSDocumentController to open the window on newDocument:(id)sender
Now on Lion no application delegate related to "untitiled" is called so I don't understard how to make it working
I think XCode 4 is NSDocument based and it shows the Startup Panel, how it does?
Another smart XCode Startup Panel's behaviour consists to show the panel only when no other windows are restored, again how this is implemented in Lion?
You're right to suspect the new restorable state behavior. The app may never be asked to create a new, empty document when relaunched/resumed. This is stated in the release notes:
As part of the restorable windows feature, the application delegate
may not be asked to create an Untitled window at launch in some
circumstances. This was found to cause crashes in certain apps, so
these apps will maintain 10.6 behavior of more often opening Untitled
windows. When these apps are recompiled on 10.7, they will acquire the
10.7 behavior. For maximum compatibility, do not depend on being asked
to create an Untitled window at launch.
They don't mention an alternative, and the document-based app documentation does not appear to have been updated yet with restorable state information.
As to your approach, you could change so that the template chooser is shown as a sheet on a new, empty doc window (like Pages or Instruments, for example). The document's contents are set when the template sheet is completed. This way, each new document shows its template sheet but this only happens if the user requests a new document, rather than relying on a fresh app launch (which you're no longer meant to do).