I'm trying to work this out as well. I can't unfortunately answer all your questions, but here's what I've found so far.
The AppKit Release Notes for OS X v10.10 have a brief explanation of what is happening, which I originally saw in the question How to create a custom themed NSButton without subclassing NSButtonCell?.
Gradual deprecation of NSCell
Mac OS X 10.10 takes another step towards the eventual deprecation of
cells. Direct access to the cell of a control is discouraged, and
methods which allow it will be formally deprecated in a subsequent
release. A variety of cell-level APIs have been promoted to various
Control subclasses in order to provide cell-free access to important
functionality. NSLevelIndicator, NSTextField, NSSearchField, NSSlider,
and NSPathControl all have new properties for this purpose. Cell-based
NSTableViews are now deprecated, and view-based NSTableViews should be
used instead. Matrix-based NSBrowsers are also deprecated in favor of
the item-based interface.
The 10.10 documentation does have many NSControl methods crossed out in red. (By the way, I'm not sure if this unambiguously means "deprecated".)
The documentation markings for continuous
and enabled
are misleading, however. I've looked through the header file for NSControl
at the declarations that are crossed out in the docs and there seem to be a few different things going on:
This method is deprecated with NS_DEPRECATED_MAC
:
// Use formatters instead. See -[NSControl formatter] and -[NSControl setFormatter:].
- (void)setFloatingPointFormat:(BOOL)autoRange left:(NSUInteger)leftDigits right:(NSUInteger)rightDigits NS_DEPRECATED_MAC(10_0, 10_0);
These methods appear in an NSDeprecated
category:
@interface NSControl (NSDeprecated)
// Use formatters instead. See -[NSControl formatter] and -[NSControl setFormatter:].
- (void)setFloatingPointFormat:(BOOL)autoRange left:(NSUInteger)leftDigits right:(NSUInteger)rightDigits NS_DEPRECATED_MAC(10_0, 10_0);
+ (void)setCellClass:(Class)factoryId;
+ (Class)cellClass;
- (id)cell;
- (void)setCell:(NSCell *)aCell;
- (id)selectedCell;
- (NSInteger)selectedTag;
- (void)setNeedsDisplay; // Use setNeedsDisplay:YES instead.
- (void)calcSize;
- (void)updateCell:(NSCell *)aCell;
- (void)updateCellInside:(NSCell *)aCell;
- (void)drawCellInside:(NSCell *)aCell;
- (void)drawCell:(NSCell *)aCell;
- (void)selectCell:(NSCell *)aCell;
@end
These methods appear in the documentation as "Available in OS X v10.8 through OS X v10.9", but not in the NSControl header file, so I assume they've been removed completely:
-userInterfaceLayoutDirection
-setUserInterfaceLayoutDirection
These declarations were previously methods, but have been refactored into properties. See this answer for details about what happened to the isEnabled / setEnabled methods. So these declarations are crossed out in the docs, but this is misleading:
@property (getter=isContinuous) BOOL continuous;
@property (getter=isEnabled) BOOL enabled;
I haven't found any good information about how to create an NSControl
subclass without also creating an NSCell
subclass, although apparently NSColorWell
is a cell-less NSControl
.
My current rough conclusion is that NSControl
is coupled fairly strongly to NSCell
, and it isn't sensible to use one without the other. So I'm considering writing an NSView
subclass instead.
I'd also appreciate more information and advice here!
NSControl
without usingNSCell
. Simple becauseNSControl
still relies onNSCell
(even if it is deprecated). If you need to build a unique custom user interface control (say, volume control), then maybe better to subclassNSView
. But, if you need to customise standardNSControl
, then adjustingNSCell
properties or even "lightweight subclassing" of theNSCell
should not be a problem. – Decor