I'm seeing here in changes page that setApplicationIconImage was deprecated. Man I couldn't believe it.
https://developer.apple.com/library/mac/documentation/General/Reference/APIDiffsMacOSX10_10SeedDiff/frameworks/AppKit.html
What is the an alternative for this now? Is there one that works in older versions then 10.10 too? If not its ok i can do version check and do setApplicationIconImage for <= 10.9 and the new way for >= 10.10.
Thanks
The setApplicationIconImage method did not get deprecated or removed.
Apple only changed the header to SHOW it as a property instead.
setApplicationIconImage IS the setter for the property. properties are only syntactic sugar for two 'standard' methods: a getter (applicationIconImage) and a setter (setApplicationIconImage)
you might get an ARC warning nowadays because it can't see setApplicationIconImage so use the dot-notation on ALL platforms -> no need for a runtime check of 10.10/10.9
It looks like maybe they removed the method in favor of a property. So use this instead.
[NSApplication sharedInstance].applicationIconImage = myNewIconImage
From the NSApplication class reference,
Assign an image to this property when you want to temporarily change the app icon in the dock app tile. The image you provide is scaled as needed so that it fits in the tile. To restore your app’s original icon, set this property to nil. Available in OS X v10.0 and later.
Related
I have a simple image view. Which I don't want to be read by the accessibility clients. I tried the solution given here. However this solution didnt work. Also I have one limitation. I want to support OSX 10.9 Hence I cant use accessibilityElement Property provided by AppKit since its only available from 10.10
Please let me know a simple way to make certain elements inaccessible for voiceover clients.
Also I would to know the 10.9 equivalent of accessiblityElement.
Most methods in the NSAccessibility informal protocol were deprecated in 10.10 in favor of property-based accessibility configuration. Prior to 10.10, you would mark elements as accessible (or not) by overriding accessibilityIsIgnored().
In modern versions of macOS, you can use accessibilityElement for this. When seeking to hide an NSControl, though, it's important to use the control's cell to hide the element from all flavors of accessibility. (VoiceOver, Switch Control, Hover Text, etc.) So in the case of an NSImageView you would use:
myImageView.cell?.setAccessibilityElement(false)
The NSTabViewController was only introduced in OS X v10.10, so NSTabView already provides everything you need for creating a tab view. When would you use a NSTabViewController, and is it only there to be subclassed?
I would use NSTabViewController to get rid of a lot of code I used to have to write to have a tab view and transition between those views (most often done in Preference windows in Mac apps).
You'd obviously have to be 10.10 only, but these days that's a safe bet.
As for subclassing it, judging by the api I'd start without sub-classing it. You can set the style, the transition options (a nice benefit of using it!), and then call addTabViewItem: and let it do it's stuff.
If you compare iOS & OS X, you will feel OS X is bit deviated from MVC. OS X default 'new project' opens with AppDelegate as compared to iOS with 'ViewController'!
Now, it seems, Apple decided to make it by adding Controller as well. So that the view NSTabView is controlled by NSTabViewController.
And yes if you design to subclass it and use that should reduce your job. Same thing is mentioned even in Apple Documentation.
Is there a robust way of checking whether the window is currently in its maximized zoom state?
I'm not looking for a notification or delegate method that would tell me when the NSWindow changes its size but need to check at some point whether the current size is the maximized state.
Couldn't find anything straight-forward on NSWindow to achieve that..
You want the zoomed property of the window, whose getter is -isZoomed.
Prior to the 10.10 SDK, this was an informal property. Its getter method was declared directly. There was no related #property declaration. Apple converted a lot of such properties from informal to "declared properties" in the 10.10 SDK. In some cases, the old, stand-alone methods are listed as "deprecated" in the documentation, but that's just a side effect of the conversion. The getter method is still there, still named the same, still callable, and not deprecated. Just the mechanism by which it was declared has changed.
Well, isZoomed is available on 10.0 to 10.9, but... since you're asking this question, I guess you're probably on 10.10, wondering why it's not there. :)
But look at the "discussion" part of the Apple docs for isZoomed:
..snip..
Or maybe don't look at the docs in this case. :) See Ken Thomases' answer.
I have an application where I have defined a custom cell and have overridden the method
- (void) drawWithFrame:inView:
This method was drawing my custom cells without any problems as long as I was building my app using Xcode 3.2 on OS X 10.6 or older.
Now I am attempting to migrate the code to build with Xcode 4+ on OS X 10.8. And what I have found out is that my custom cell is not getting drawn anymore. After putting break points and running the app through the debugger, I realized that the overridden - (void) drawWithFrame:inView: method of the custom cell is not getting invoked at all.
My questions are:
1) What is it that makes this method to not invoke at all on OS X 10.8, while it gets invoked and works perfectly fine on OS X 10.6 or older?
2) What alternative do I have to fix this issue?
Thanks,
Mriganka
I am having the same problem, except i am using xcode 4.x on OSX 10.7
Maybe its an xcode 4.x thing?
What I have noticed is that drawWithFrame on my subclassed NSTextFieldCell does NOT get invoked when i call setEnabled (changing from YES to NO or NO to YES) on the parent NSTextField, after initialization of my NSTextFieldCell, but before drawWithFrame on that NSCell gets invoked automatically.
However, if I call setEnabled (after initializing my subclassed NSTextFieldCell) and no change occurs (ie. setEnabled:YES but it is already set to YES), then drawWithFrame does indeed get invoked.
Unfortunately, i need to perform setEnabled from YES to NO to YES, as i want to disable my NSTextField while a server call is being made, and then enable it on the callback. If the callback is (for example 'wrong password'), i need to custom draw the NSTextFieldCell border red.. and I have to do this by overriding drawWithFrame.
My guess is that setEnabled utilizes NSGraphicsContext and does a savesGraphicsState/restoreGraphicsState (perhaps in error), which throws off the graphics context that is utilized in NSTextFieldCell/drawWithFrame.
My guess is that the NSGraphicsContext within setEnabled is ONLY utilized if a change occurs (setEnabled from YES to NO or NO to YES), since when a change DOES NOT occur, I have no issue… I think this would make sense as there would be no point in rendering new graphics to show the user that the view is not selectable or editable, because it does indeed ALREADY LOOK not selectable or editable.
The answer to my problem was to re-draw manually after i called setEnabled, by calling setNeedsDisplay on the NSTextField.
I think this will probably work for you as well, as it causes the draw to occur manually.
glhf!
-Eric
I have checked the restorable option on my NSWindow
When I move my application and change its size and close/reopen my application it sets the window size and position to the last size and position
but this doesn't happen on every computer where i test it. it only happens to a few computers
they don't have special settings regarding the resume.
Does anybody have any experience with this?
But this doesn't happen on every computer where I test it. It only
happens to a few computers. They don't have special settings regarding
the resume.
Actually, they do. Take a look into the System Preferences > General pane. There should be an option named “Close windows when quitting an application” which is responsible for the restoration behavior. Additionally, in OS X Mountain Lion, Apple changed default behavior and now the app restores its state only when you quit using Command-Option-Q.
So, you probably should check which OS X version is installed on another Mac, and which preference is selected in the General pane. Hope this helps!
One thing you should know is that checking the "Restorable" option in IB only changes a window property. The actual restoring and saving is in your hands.
First, you have to conform to the NSWindowDelegate protocol and implement the
-window:willEncodeRestorableState:state and -window:didDecodeRestorableState:
methods that encode and decode your window properties (For example your windows frame, which you obviously get by calling [myWindow frame]).
You also need to conform to the NSWindowRestoration protocol and implement +restoreWindowWithIdentifier:state:completionHandler:. (make sure you set your class to restoration class, with the setRestorationClass method)
For additional, more in depth, information, you can visit this Apple Documentation document here.
If all you want is to restore the window's frame use setFrameAutosaveName:.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SavingWindowPosition.html