Spec-Zone .ru
спецификации, руководства, описания, API
Библиотека разработчика Mac Разработчик
Поиск
Сгенерированный документ: 06.08.2014 20:56:55 - 0700
Copyright © 2014 информации о версии OS X Apple Inc Все права защищены.


OS X 10.10 информации о версии Yosemite
Среда разработки приложения какао



Среда разработки приложения Какао (также называемый Набором Приложения или AppKit) является одной из базовых платформ Какао. Это обеспечивает функциональность и связало APIs для приложений, включая объекты для графических интерфейсов пользователя (GUIs), механизмов обработки событий, прикладных служб, и получения и средств состава изображения.

Некоторые главные темы покрыли в этом документе:


Эти примечания применяют к семени 5 из OS X Yosemite, выпущенный в начале августа. Разделы обновили, так как отмечено семя WWDC. Эти примечания еще не покрывают все изменения в Наборе Приложения в OS X 10.10.

Также обратитесь к информации о версии Основы для примечаний по другим важным изменениям в 10,10.

Информация о версии для AppKit от 10,9 и более ранние выпуски может быть найдена здесь.

Отмечание обновило APIs в заголовках

Новый APIs в заголовках отмечен с художественными оформлениями, включающими ссылки на "10_10”:
 NS_AVAILABLE_MAC(10_10), NS_AVAILABLE(10_10, <iOS Release>), NS_CLASS_AVAILABLE(10_10, <iOS Release>), NS_ENUM_AVAILABLE(10_10)
или иногда конструкция:
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_10
...
#endif
Осуждаемый APIs отмечен с:
 NS_DEPRECATED_MAC(<Release when introduced>, 10_10) or  NS_DEPRECATED_MAC(<Release when introduced>, 10_10, "Suggested alternative”)
В 10,10, осуждаемый атрибут был добавлен ко многим ранее мягким устаревшим методам. Знайте о предупреждениях осуждения и измените свой код для использования поддерживаемых альтернатив. Поиск заголовков AppKit для NS_DEPRECATED_MAC и фильтрация для 10_10 приведут к списку затронутых символов.

Проверка версии среды выполнения

Существует несколько способов проверить на новые функции, предоставленные платформами Какао во время выполнения. Нужно искать данный новый класс или метод динамично, и не использовать его если не там. Другой должен использовать глобальную переменную NSAppKitVersionNumber (или, в Основе, NSFoundationVersionNumber):
double NSAppKitVersionNumber;
#define NSAppKitVersionNumber10_0 577
#define NSAppKitVersionNumber10_1 620
#define NSAppKitVersionNumber10_2 663
#define NSAppKitVersionNumber10_3 743
#define NSAppKitVersionNumber10_4 824
#define NSAppKitVersionNumber10_5 949
#define NSAppKitVersionNumber10_6 1038
#define NSAppKitVersionNumber10_7 1138
#define NSAppKitVersionNumber10_8 1187
#define NSAppKitVersionNumber10_9 1265
Одно типичное использование этого должно поставить в тупик () значение и проверку по сравнению со значениями, предоставленными в NSApplication.h. Например:
if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_8) {
/* On a 10.8.x or earlier system */
} else if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_9) {
/* On a 10.9 - 10.9.x system */
} else {
/* 10.10 or later system */
}
Особые случаи или ситуации для проверки версии также обсуждены в информации о версии как надлежащие. Например, некоторые отдельные заголовки могут также объявить числа версий для NSAppKitVersionNumber, где некоторое исправление ошибки или функциональность доступны в данном обновлении, например:
#define NSAppKitVersionWithSuchAndSuchBadBugFix 1138.42

Обратная совместимость

Один механизм обратной совместимости, иногда использующийся в платформах, должен проверить на версию системы, приложение было создано против, и если более старая система, измените поведение быть более совместимыми. Это сделано в случаях, где плохие проблемы несовместимости предсказаны или обнаружены; и большинство из них упоминается ниже в этих примечаниях.

Обычно мы обнаруживаем, где приложение было создано путем рассмотрения версии Системы, Какао, AppKit или платформ Основы, приложение было соединено против. Таким образом, в результате пересоединения Вашего приложения против последнего SDK, Вы могли бы заметить различные способы поведения, некоторые из которых могли бы вызвать несовместимости. В этих случаях, потому что приложение восстанавливается, мы ожидаем, что Вы решите эти проблемы в то же время, что и хорошо. Поэтому при выполнении маленького инкрементного обновления приложения для обращения нескольких ошибок, обычно лучше продолжать основываться на той же среде сборки и библиотеках, пользовавшихся первоначально.

В некоторых случаях мы обеспечиваем значения по умолчанию (предпочтения) настройки, которые могут использоваться для получения старого или нового поведения, независимого от того, против какой системы приложение было создано. Часто эти предпочтения предоставлены для отладки целей только; в некоторых случаях предпочтения могут использоваться для глобального изменения поведения приложения путем регистрации значений (сделайте это где-нибудь очень рано, с - [NSUserDefaults registerDefaults:]).




Раскадровки

AppKit имеет новый API для поддержки функции Storyboarding, представляемой в OS X 10.10.

Класс NSStoryboard (объявленный в NSStoryboard.h) обеспечивает средние значения, чтобы получить доступ к раскадровкам Вашего приложения и инстанцировать контроллеров по имени. (Можно также указать NSMainStoryboardFile в Info.plist приложения, заставляющем именованную раскадровку быть автоматически загруженной, и ее начальный контроллер, который инстанцируют и представленной, во время запуска приложения.) И NSViewController и NSWindowController имеют новое, свойство «раскадровки» только для чтения, возвращающее NSStoryboard (если таковые имеются), которому принадлежит контроллер.

Класс NSStoryboardSegue (объявленный в NSStoryboardSegue.h) инкапсулирует именованное соединение от sourceController до destinationController, в то время как протокол NSSeguePerforming, которому и NSViewController и NSWindowController теперь соответствуют, обеспечивает средние значения для сцепления в механику этих переходов. Когда Ваше приложение выполняет переход, destinationController перехода представлен. Представленный destinationController остается показанным, пока он не отклонен (обычно в ответ на пользовательское действие).

Для увольнения ViewController или WindowController Вы отправляете его (или имейте его, отправляют себя), новый-dismissController: сообщение.-dismissController: объявляется как IBAction, таким образом, можно обеспечить электричеством его как место назначения соединения целевого действия, если Вы желаете.

NSWindowController (Раздел, обновленный начиная с семени WWDC)

NSWindowController имеет новое «contentViewController» свойство, зеркально отражающее «contentViewController» свойство связанного окна. NSWindowController это - часть раскадровки, обязан иметь contentViewController — требование, чтобы редактор раскадровки XCode помог Вам в выполнении, когда Вы перетаскиваете NSWindowController в холст раскадровки.

До OS X 10.10, NSWindowController только получил-windowWillLoad,-loadWindow, и сообщения-windowDidLoad, когда сам NSWindowController выполнил загрузку пера — т.е. когда NSWindowController инстанцировали в коде и дали имя файла пера для загрузки по требованию, когда - сначала требовали окно. Это означало-windowWillLoad,-loadWindow, и-windowDidLoad не будет отправлен NSWindowController, загруженному как одно из пера составляющие объекты файла.

AppKit теперь отправляет-windowWillLoad,-loadWindow, и-windowDidLoad в NSWindowController, это разархивировано от пера, если NSWindowController соединен проводом до связанного окна. Переопределение-windowDidLoad может рассчитывать на все соединения, описанные в установленном пере. Задокументированное поведение-isWindowLoaded изменилось немного для соответствия: Для NSWindowController, разархивированного от пера,-isWindowLoaded сообщает НЕ сначала, затем YES в то время, когда-windowDidLoad вызывается и после того. Для предотвращения двоичных проблем несовместимости вследствие этих изменений в долгосрочном поведении NSWindowController изменения, описанные в этом абзаце только, вступают в силу для приложений, соединенных на или после OS X 10.10 при работе OS X 10.10 или позже.



NSViewController (Раздел, обновленный начиная с семени WWDC)

NSViewController теперь имеет комплект методов для рычагов представления:-viewWillAppear,-viewDidAppear,-viewWillDisappear и-viewDidDisappear. См. комментарии заголовка в NSViewController.h для большего количества подробных данных.

NSViewController теперь имеет метод-viewDidLoad, который может быть переопределен для экземпляров, хотящих знать, когда представление было загружено и может выполнить дополнительную работу установки по мере необходимости. Для поддержания совместимости для приложений, которые могут вызвать их собственное, тождественно названное методами «-viewDidLoad», AppKit вызывает-viewDidLoad только для приложений, соединенных на или после OS X 10.10.

NSWindow теперь имеет contentViewController свойство. Это свойство упрощает присваивать contentView окна с помощью контроллера представления. Существует также удобный метод для создания названного окна: [NSWindow windowWithContentViewController:]. Дополнительную информацию см. в комментариях заголовка NSWindow.h.

NSViewController теперь имеет следующие новые функции, все прокомментировали очень подробно в NSViewController.h:
• Родительский/дочерний контейнер просматривает методы контроллера
• Опции представления контроллера представления
• Опции перехода контроллера представления

NSViewController теперь соответствует протоколу NSUserInterfaceItemIdentification. Это позволяет ему участвовать в Прозрачном Управлении жизненным циклом приложения. Любой NSViewController может теперь использовать комплект методов, объявленных на NSResponder для восстановления состояния: encodeRestorableStateWithCoder: restoreStateWithCoder: invalidateRestorableState, и restorableStateKeyPaths.

NSViewController теперь имеет комплект методов к расположению органов управления для его связанного представления: updateViewConstraints, viewWillLayout и viewDidLayout. Посмотрите заголовок NSViewController.h для получения дополнительной информации.

Следующие изменения вступают в силу для приложений, соединенных на 10,10 и выше:

• NSViewController автоматически добавляет себя в цепочку респондента. Когда представление присваивается, текущий nextResponder представления сохраняется прочь. nextResponder представления тогда установлен быть viewController, и nextResponder viewController установлен быть ранее сохраненным nextResponder. Когда представление имеет вызов к setNextResponder: сделанный, метод будет передан контроллеру представления представления. Если Вы в настоящее время уже делаете свое собственное управление цепочкой респондента, проявляете определенную заботу, поскольку view.nextResponder может уже быть NSViewController. Это может вызвать проблему для приложений, вручную устанавливающих viewController.nextResponder = view.nextResponder, не проверяя, чтобы видеть если view.nextResponder! = viewController; иначе, бесконечный цикл может быть создан, заставив приложение зависнуть. Для отладки они зависают, запустите приложение с «-NSResponderDebugResponderLoops YES». Эта опция проверит цепочку респондента на циклы каждый раз, когда setNextResponder вызывают (обратите внимание на то, что эта опция замедлит реализацию программы).

Другими словами цепочка респондента с контроллерами представления похожа на это:

ChildView-> ParentView-> ViewController ParentView-> ParentView ParentView-> Окно-> WindowController Окна.

• loadView: если бы был «ноль» nibName, ранее не имел бы четко определенного поведения. На 10,10 и позже, если nibName является нолем, NSViewController автоматически попытается загрузить перо тем же именем как имя класса. Это позволяет удобство выполнения [[выделение MyViewController] init] (который имеет ноль nibName), и наличие его автоматически загружают перо именем «MyViewController».


Автоматическое Расположение (Раздел, обновленный начиная с семени WWDC)

Для приложений, соединенных против 10,10 и позже, повторно вычисляя ключевой цикл представления окна, будет расположение любые грязные поддеревья в окне. Ранее, ключевой цикл был бы вычислен с помощью грязных фреймов макета, потенциально приведя к неправильному ключевому циклу представления. Это влияло на разметки, создаваемые с ограничениями, а также с NSStackView.

Ограничения, охватывающие по родительским представлениям (например, кнопка в контейнерном представлении, ограниченном к одноуровневому элементу контейнерного представления), которые создаются в IB, больше не удаляются во время выполнения. Приложения, работающие на системах ранее, чем 10,10, будут все еще иметь эту проблему — обходное решение для приложений, развернутых в более ранних системах, должно создать затронутые ограничения программно.

Ограничения от Ведущего или Заднего фронта одного элемента расположения к Центру X из другого больше неожиданно не ведут себя (такие как порождение невыполнимых ограничений) в средах RTL. Приложения, работающие на системах ранее, чем 10,10, будут все еще иметь эту проблему — обходное решение для приложений, развернутых в более ранних системах, должно использовать явные Левые или правые атрибуты в средах RTL.

NSPopover

Цепочка респондента больше не заканчивается в окне NSPopover. То окно теперь имеет nextResponder своего parentWindow, т.е. окно positioningView.

Содержание легкой сдобы, показанной из безграничных окон и элементов строки состояния, теперь focusable. В этих случаях окно легкой сдобы станет ключевым окном. Переходная легкая сдоба, показанная от этих контекстов, также должным образом закроется.

Если contentView легкой сдобы возвратится НЕ из-acceptsFirstResponder, то легкая сдоба больше не будет делать его первым респондентом. Это может быть использовано для показа текстовой легкой сдобы справки, не заставляя источник потерять первого респондента или ключевое состояние.

При вызове - близкий метод на легкой сдобе теперь заставит дочернюю легкую сдобу быть вызванной закрытая также (в соответствии с прошлой документацией). Вызов-performClose: если легкая сдоба будет иметь вложенную легкую сдобу, все еще перестанет работать.

- popoverWillClose: теперь вызывается на делегате, прежде чем легкая сдоба запросит, анимирует свойство, чтобы определить, должно ли это анимировать. Это позволяет образец всегда наличия, анимирует = нет, и включение его в willClose: и willShow: анимировать показ и закрытие легкой сдобы.

В OS X 10.10, NSPopover теперь располагает довольный сброс к краям легкой сдобы. Ранее это было вставлено (2, 2, 2, 2).

Отделяемые улучшения легкой сдобы

Новый-popoverShouldDetach: NSPopoverDelegate. Это вызывают, когда пользователь начинает перетаскивать легкую сдобу, чтобы определить, нужно ли позволить отсоединиться. Если делегат не реализует этот метод, то поведение по умолчанию будет НЕТ.

Приложение, желающее использовать пользовательское отдельное окно, продаваемое от-detachableWindowFromPopover: должен будет реализовать этот метод для возврата YES, если соединено против 10,10 или выше. Приложения соединились, прежде чем это будет продолжать работать как ожидалось без реализации метода.

Автоматически создаваемые отделяемые окна. Если делегат возвращает YES из-popoverShouldDetach: но не реализует или возвращает ноль из-detachableWindowForPopover: отдельное окно будет автоматически создаваться для отсоединения к. Это снова использует представление contentViewController как его contentView и поддержит подобное легкой сдобе появление с бесшовным переходом во время отсоединения. Во время отсоединения с автоматическим окном,-PopoverShould/Will/DidClose уведомления не будет отправлен. Вместо этого когда автоматическое окно будет закрытым,-popoverShouldClose: даст делегату шанс предотвратить закрытие окна, и уведомления PopoverWill/DidClose будут отправлены, если это действительно закроется. Если-showRelativeToRect:ofView:preferredEdge: вызывается на легкой сдобе, в то время как автоматически создаваемое отдельное окно показано, легкая сдоба не появится, но отдельное окно будет сделано ключевым и упорядочило переднюю сторону. Как только отдельное окно закрывается, вызывая-showRelativeToRect:ofView:preferredEdge: возвратится к показу легкой сдобы.

- detachableWindowForPopover: будет только вызван, как только легкая сдоба будет полностью отдельной, не, когда пользователь начинает перетаскивание. Это означает, что появление легкой сдобы во время перетаскивания будет основываться на самой легкой сдобе, а не финал отсоединил окно.-popoverShouldDetach: должен использоваться, чтобы указать, что легкой сдобе нужно позволить быть перетащенной и отсоединенной.

- popoverShouldClose: когда окно отсоединяется к отдельному окну, больше не вызывается на делегате или легкой сдобе.

Изменения появления легкой сдобы

Для получения возможности настройки появления через NSAppearance свойство появления NSPOPOVER переходит от типа NSPopoverAppearance к NSAppearance. Если Вы планируете развернуться к 10,10 или выше, прежнего считают осуждаемым, и Вы больше не должны устанавливать или читать свойство появления с NSPopoverAppearanceMinimal или NSPopoverAppearanceHUD. Если Вы развертываетесь к 10,10 как минимум, свойство появления объявляется как взятие NSAppearance. Если никакое появление не указано, эффективные значения по умолчанию появления к NSAppearanceNameVibrantLight. Это соответствует видимости, созданной NSPopoverAppearanceMinimal. NSPopoverAppearanceHUD не имеет никакого параллельного стиля в NSAppearance.

NSSplitView

Когда делегат возвратит такой из-splitview:shouldhidedivideratindex: в 10,10, SplitViews с помощью автоматического расположения теперь правильно скроет первые и последние делители. В 10,9 и ранее, этим делителям не удалось бы скрыться.

Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft, в 10,10, SplitViews с помощью автоматического расположения будет уважать. Его подпредставления и делители будут упорядочены справа налево; т.е. подпредставление 0 является самым правым представлением, и делитель 0 является самым правым делителем. SplitViews, не используя автоматическое расположение будет продолжать не упорядочивать представления справа налево.


NSSplitViewController

NSSplitViewController является новым контейнерным классом контроллера представления в 10,10. Это управляет NSSplitView к расположению его дочерние представления контроллера представления. Использование объектов NSSplitViewItem представляет SplitViewController определенные свойства дочернего контроллера представления в NSSplitViewController.

Одно преимущество NSSplitViewController является ленивой загрузкой представлений childViewController. В целом выигрыши в производительности этого могут не быть столь же значительными как ленивая загрузка NSTabViewController, но действительно играют роль в паре ситуаций: (1) при установке SplitViewController и добавлении SplitViewItems, детские представления не будут загружены, пока SplitViewController не загружается, и (2) при добавлении разрушенного SplitViewItem к SplitViewController; представление элемента будет только загружено, как только представление не разрушено (программно или пользователем). Если это никогда не не разрушается, это никогда не загружается SplitViewController.

Использование автоматического расположения с NSSplitViewController позволяет приложению настраивать, заставляет ли крах элемента представления разделения, например, окно оставаться тот же размер или уменьшение, не представляя дополнительного API или требуя, чтобы разработчик выполнил дополнительную работу. Если ограничений, используемых для создания расположения дочерней иерархии представления контроллера представления, недостаточно для описания поведения во время краха/некраха, holdingPriority свойство NSSplitViewItem может быть установлено указать это поведение.

Разрушенное свойство NSSplitViewItems KVC/KVO совместимый. Это позволяет разработчикам делать, вещам нравится, связывают кнопку Пушонофф с разрушенным состоянием элемента. Поскольку кнопка переключается, элемент представления разделения - также. И наоборот: если SplitViewItem является разборным и пользовательский крах элемент (с перетаскиванием или двойным щелчком), состояние кнопки обновляется:
[toggleButton bind:NSValueBinding
toObject:sidebarSplitViewItem
withKeyPath:@"collapsed"
options:@{NSValueTransformerNameBindingOption : NSNegateBooleanTransformerName}];
Так как разрушенное свойство также animatable с прокси аниматора SplitViewItem, привязка могла быть вместо этого записана против свойства аниматора. Это дает весь одинаковый преимущества как предыдущий пример, но теперь когда кнопка переключается, контроллер представления элемента представления разделения будет анимирован в или:
[toggleButton bind:NSValueBinding
toObject:[sidebarSplitViewItem animator]
withKeyPath:@"collapsed"
options:@{NSValueTransformerNameBindingOption : NSNegateBooleanTransformerName}];

NSStackView

Для поддержанного уровнем StackViews представления больше не отсекаются ни к каким частным контейнерным границам. Это изменение только влияет на приложения, соединенные против 10,10. NSStackView теперь переопределяет +requiresConstraintBasedLayout для возврата ДА, позволяя StackViews должным образом функционировать в окнах, не имеющих никаких других ограничений.


Темные Меню (Раздел добавил начиная с семени WWDC),

Темная поддержка меню включена пользователями через Общую предпочтительную область. Это - установка в масштабе всей системы, не на приложение, и это предназначается для применения к небольшому количеству системных элементов — строка меню, меню, прикрепление и переключатель приложения cmd-вкладки. Это не применяется к окнам приложения.

Появление NSStatusItem и Темная поддержка Меню (Раздел добавил начиная с семени WWDC),

Существует много стилистических изменений, добавленных и поддерживаемых NSStatusItem, включая изменения появления для Темных Меню. Шаблонные изображения должны всегда использоваться для обеспечения корректного моделирования на основе различных состояний, которыми элемент состояния может быть в (легкое меню, темное меню, неактивная легкая, неактивная темнота, выбранная, отключенная, и т.д.). appearsDisabled свойство NSStatusBarButton может использоваться, чтобы дать изображению отключенное или «от» взгляда, не имея элемента быть функционально отключенным. - свойство кнопки было добавлено для предоставления доступа в NSStatusBarButton, внутренне созданный и выведенный на экран в элементе состояния. Существующие свойства, ранее переданные этой кнопке, мягко осуждаются и должны быть получены доступ непосредственно через кнопку. Свойство кнопки также позволяет экранное измерение позиции (такой что касается использования с легкой сдобой), не устанавливая пользовательское представление.

Создание стандартного элемента состояния с надлежащим моделированием может быть сделано в только небольшом количестве строки:
NSStatusItem *myStatusItem = [[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength];
gearImage.template = YES;
myStatusItem.button.image = gearImage;
myStatusItem.button.accessibilityTitle = @"My Status Item";
myStatusItem.button.appearsDisabled = networkIsDisabled;
myStatusItem.menu = myStatusItemMenu;

Свойство представления NSStatusItem мягко осуждается, а также API означал поддерживать его использование. Одно только пользовательское свойство представления недостаточно для AppKit для обеспечения, стандартное моделирование для различного элемента состояния утверждает и включает элементы к стили, неуместному в строке меню. Улучшение файла запрашивает, если NSStatusItem & NSStatusBarButton’s API не допускает поведение, которое должно быть стандартизировано и позволено.


NSTabViewController

NSTabViewController является новым контейнерным классом контроллера представления в 10,10. Это обеспечивает:
• Ленивая загрузка невидимых контроллеров представления
• Простая конструкция времени проектирования с Работой с архивами
• Цель для привязки
• Простое/абстрактное сцепление для отображения больших коммутаторов контента
• Способ предоставить стандартному стилю вкладки UI внешние управления

NSTabViewController представляют абстрактную цель для обеспечения переключения содержания. tabViewItems и selectedTabViewItemIndex KVC/KVO совместимый. Это позволяет связывать NSSegmentedControl (или другие связываемые объекты) непосредственно им:
[segmentedControl bind:NSContentBinding toObject:tabViewController withKeyPath:@"tabViewItems" options:nil];
[segmentedControl bind:NSSelectedIndexBinding toObject:tabViewController withKeyPath:@"selectedTabViewItemIndex" options:nil];

Справа налево UI

• Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft, NSComboBox теперь правильно зеркально отразит.
• Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft, NSDatePicker теперь правильно зеркально отразит.
• Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft, NSPopupButton теперь правильно зеркально отразит.
• Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft, NSSearchField теперь правильно зеркально отразит.
• Когда его userInterfaceLayoutDirection будет NSUserInterfaceLayoutDirectionRightToLeft и будет использовать автоматическое расположение, NSSplitView будет расположение его подпредставления справа налево.


Изменения NSDatePicker (Раздел добавил начиная с семени WWDC),

На приложениях, создающих против 10,10 SDK, при работе 10.10 или позже, NSDatePicker и setLocale NSDatePickerCell: и setTimeZone: методы скопируют данную локаль/часовой пояс вместо того, чтобы просто сохранить его.

Когда календарное свойство установлено в NSCalendar, создаваемый с идентификатором NSCalendarIdentifierChinese, NSDatePicker теперь поддерживает китайский лунный календарь.

NSClockAndCalendarDatePickerStyle NSDatePicker теперь поддерживает RTL согласно своей локали.

Изменения поведения свойства NSTokenField

На приложениях, создающих против 10,10 SDK, при работе 10.10 или позже, NSTokenField и setTokenizingCharacterSet NSTokenFieldCell: методы скопируют данный набор символов вместо того, чтобы просто сохранить его.

Изменения поведения свойства NSSpeechRecognizer

На приложениях, создающих против 10,10 SDK, при работе 10.10 или позже, setCommands NSSpeechRecognizer: метод скопирует данный массив вместо того, чтобы просто сохранить его.

Методы NSWorkspace для передающей конфигурации и опций при открытии URL (Section добавил начиная с семени WWDC),

NSWorkspace теперь имеет пару методов для открытия URLs с определенными параметрами конфигурации. См. openURL:options:configuration:error: и openURLs:withApplicationAtURL:configuration:error: в AppKit/NSWorkspace.h.

Изменения поведения NSScreen (Раздел добавил начиная с семени WWDC),

Экземпляры NSScreen являются теперь неизменными — их свойства не изменятся. Для получения обновленной информации как, дисплеев реконфигурированы, прислушиваются к NSApplicationDidChangeScreenParametersNotification и, когда это поступает, получите новые экземпляры NSScreen, которые будут иметь обновленную информацию.

Даже если экземпляры NSScreen не будут идентичны, NSScreen isEqual теперь возвратит YES для того же дисплея.

На приложениях, создающих против 10,10 SDK при работе 10.10 или позже, [экраны NSScreen] возвратят пустой массив, если никакие дисплеи не будут присоединены вместо ноля.


Поддержка Хэндофф в AppKit (Раздел добавил начиная с семени WWDC),

NSUserActivity является новым классом в Основе, инкапсулирующей состояние пользовательского действия в приложении на определенном устройстве в пути, позволяющем тому же действию продолжаться на другом устройстве в соответствующем приложении от того же разработчика. Примеры пользовательских пользовательских действий включают редактирование документа, просмотр веб-страницы или просмотр видеофильма.

Существует новый API на делегате NSApplication для поддержки продолжения действия от NSUserActivity. Существует также userActivity свойство на NSResponder и NSDocument, позволяющем AppKit управлять вызовом-becomeCurrent, и - лишают законной силы, вместе с-updateUserActivityState: и-restoreUserActivityState: методы, которые могут быть переопределены для сохранения собственного состояния в NSUserActivity.

Кроме того, документ базировался, приложения могут поместить NSUbiquitousDocumentUserActivityType в каждую запись CFBundleDocumentTypes в Info.plist, и AppKit автоматически создаст NSUserActivities для документов в iCloud (которые доступны от userActivity свойства). Типы действия, указанные таким образом, не должны появляться в массиве Info.plist NSUserActivityTypes, использующемся для объявления действий, поддерживаемых приложением.

NSUserActivities, сделавшие, чтобы NSUserActivityDocumentURLKey начался их userInfo, могут автоматически продолжаться с помощью openDocumentWithContentsOfURL:display:completionHandler: NSDocumentController. NSDocument поместит свой fileURL в userInfo с NSUserActivityDocumentURLKey в его реализации updateUserActivityState:.

Для получения дополнительной информации см. Foundation/NSUserActivity.h и AppKit/NSUserActivity.h.


NSAppearance

Средство доступа было добавлено для получения имени экземпляра появления.

NSAppearanceNameLightContent был осужден. Использование этого появления будет перенаправлено к появлению Воды по умолчанию.

Вибрирующие появления, NSAppearanceNameVibrantDark и NSAppearanceNameVibrantLight, были добавлены для использования с NSVisualEffectView.

NSTextView

Цвет точки вставки по умолчанию теперь [NSColor controlTextColor]. В появлении Воды этот цвет является черным и поэтому не должен приводить ни к какому изменению в поведении, но в других появлениях (например, Вибрирующая Темнота), это может отличаться.



Устройства распознавания жеста (Раздел, обновленный начиная с семени WWDC)

Устройства распознавания жеста теперь доступны в AppKit. API почти идентичен версии UIKit. См. NSGestureRecognizer.h. Существует NSGestureRecognizer (NSSubclassUse) категория, явно предназначенная для подклассификаторов, чтобы переопределить и вызвать. Неподклассификаторы никогда не должны непосредственно получать доступ к этим методам категории и свойствам.

Следующее считают физическими жестами:
• Нажатие кнопки мыши, перетащите, или выпуск.Примечание: каждая кнопка является независимым потоком жеста.
• Жест, всегда проходящий через NSEventPhaseBegan и NSEventPhaseEnded / NSEventPhaseCancelled (иначе Поворачивают и Увеличивают),
Примечание: в то время как события ScrollWheel имеют значение фазы, фаза не требуется, и таким образом события ScrollWheel не способны получением NSGestureRecognizers.

Распознавание жеста начинается в данный момент, любой из вышеупомянутых физических жестов начинается. В этой точке набор возможных устройств распознавания жеста собран во многом как UIKit. Т.е. набор всех устройств распознавания жеста, присоединенных к протестированному хиту, просматривает и его представления наследователя. (Или запустите с первого представления, найденного после цепочки респондента начиная с первого респондента в случае ключа вниз события). Оттуда, даже если такие события являются запуском различного физического жеста, вся мышь, клавиатура и события жеста направляются к набору устройств распознавания жеста. Это продолжается, пока полный набор конца устройств распознавания жеста (или сбой) или все физические жесты, начавшиеся начиная с первого, не завершился.

Устройства распознавания жеста не видят события, которые вытягивают циклы отслеживания события. Поэтому сообщено, что Ваши события задержки подкласса устройства распознавания жеста типа Вы обрабатываете.

Событие передает от-sendEvent NSAPPLICATION: к любым мониторам события, затем к-sendEvent NSWINDOW: метод тогда к Устройствам распознавания Жеста и наконец к цепочке респондента. Предупреждение: потребление событий, отмечающих конец жеста перед Устройствами распознавания Жеста, обрабатывает их, может заставить устройства распознавания жеста запутываться.

Набор AppKit обеспечил устройства распознавания жеста (и их аналоги UIKit):
• NSPanGestureRecognizer [UIPanGestureRecognizer] - отслеживает мышь, перетаскивают
• NSClickGestureRecognizer [UITapGestureRecognizer] - отслеживает конкретное количество щелчков
• NSPressGestureRecognizer [UILongPressGestureRecognizer] - отслеживает щелчок, и содержать
• NSMagnificationGestureRecognizer [UIMagnificationGestureRecognizer] - отслеживает последовательность события жеста увеличения
• NSRotationGestureRecognizer [UIRotationGestureRecognizer] - отслеживает последовательность события жеста вращения

Примечание: Любой подкласс на 32 бита NSPanGestureRecognizer должен будет быть восстановлен начиная с семени WWDC.

Метод делегата-gestureRecognizer:shouldReceiveEvent: был удален начиная с семени WWDC.

Блокируйте основанное отслеживание события

На NSWindow существует базируемый метод отслеживания события нового блока. Это будет постоянно беговые соревнования с помощью предоставленного блока обработчика отслеживания, пока блок обработчика отслеживания явно не завершит отслеживание.
- (void)trackEventsMatchingMask:(NSEventMask)mask
timeout:(NSTimeInterval)timeout
mode:(NSString *)mode
handler:(void(^)(NSEvent *event, BOOL *stop))trackingHandler;
Если соответствующее событие не существует в конечном счете очередь, то основные блоки потока в указанном runloop режиме до события требуемого типа получены, или тайм-аут истекает. Если тайм-аут истекает, обработчик отслеживания вызывают с нулевым событием. Отрицательный тайм-аут интерпретируется как 0. Используйте NSEventDurationForever для никогда тайм-аута. Отслеживание продолжается, до *остановка установлена в YES в обработчике отслеживания. Этот метод возвраты один раз отслеживание завершается.

Вызовы к-nextEventMatchingMask: … позволяются в блоке trackingHandler. Это часто полезно для быстрого дренажа очереди событий для объединения целей.



NSScrollView (Раздел добавил начиная с семени WWDC),

NSScrollView теперь имеет contentInsets свойство, подобное тому из UIScrollView в iOS. Когда представление прокрутки пересекает заголовок / панель инструментов, обычно это используется с NSFullSizeContentViewWindowMask.

«Автоматически» устанавливает contentInsets свойство представления прокрутки для учета любого перекрывающегося заголовка / панель инструментов. Для наложения с заголовком / панель инструментов, маска стиля окна должна включать NSFullSizeContentViewWindowMask, и строка заголовка не должна казаться прозрачной. Обычно это - NSEdgeInsetsZero. Значения по умолчанию к YES.
@property BOOL automaticallyAdjustsContentInsets;
NSScrollView управляет многими подпредставлениями (contentView, скроллеры, найдите панель, линейки, и т.д.). Это свойство управляет расстоянием, что подпредставления вставляются от представления прокрутки включения во время мозаичного размещения. Когда contentInset, равный NSEdgeInsetsZero, выполняется традиционное мозаичное размещение. Т.е. линейки, заголовки, и т.д... размещаются рядом с кадром contentView, заполняющим остающееся пространство. Когда contentInset не равен NSEdgeInsetsZero, линейкам, заголовку, и т.д... вставляются, как указано. contentView, помещается под этими одноуровневыми представлениями и только вставляется границей представления прокрутки и скроллерами неналожения.Примечание: если automaticallyAdjustsContentInsets == YES тогда какой-либо набор значений здесь будет переопределен во время мозаичного размещения.
@property NSEdgeInsets contentInsets;
Расстояние скроллеры вставляется от края представления прокрутки:
@property NSEdgeInsets scrollerInsets;

NSClipView (Раздел добавил начиная с семени WWDC),

Так как NSClipView является представлением, фактически содержащим содержание с возможностью прокрутки (documentView), NSClipView также получает понятие contentInsets.

Когда ДА, и используемый в качестве contentView NSScrollView, представление прокрутки автоматически установит надлежащий clipView contentInsets, рассматривая contentInsets scrollView, участника и расположение других подпредставлений, таких как линейки и заголовки. Значения по умолчанию к YES.
@property BOOL automaticallyAdjustsContentInsets;
Расстояние, что довольное представление вставляется от представления прокрутки включения. Анимационный с [сам аниматор]. Если automaticallyAdjustsContentInsets == YES тогда какой-либо набор значений здесь будет переопределен во время мозаичного размещения.
@property NSEdgeInsets contentInsets;
Обычно автоматическое поведение по умолчанию сделает правильную вещь при использовании полного довольного окно стиля представления. Для достижения скрытого выпадающего или получения по запросу для обновления разрабатывают UI, устанавливают automaticallyAdjustsContentInsets в НЕ и вручную устанавливают contentInsets. Добавьте скрытое содержание, поскольку подпредставления clipView и места располагают их выше кадра Вашего documentView.



NSPrintSaveJob и координация файла

В Mac OS X 10.9, при печати операций привел к PDF или файлам PostScript, NSPrintOperation будет использовать NSFileCoordinator для надлежащего сотрудничества с другими приложениями, которые могли бы представлять или получать доступ к тому же файлу. Однако это новое поведение вызвало мертвые блокировки в некоторых приложениях, делающих их координацию файла, с тех пор скоординировано запись на том же файле от двух отдельных подсистем не повторно используема

Сценарий, где они происходили бы всегда, включал приложение, правильно делающее скоординированную запись, затем в той записи, выполняющей NSPrintOperation с набором NSPrintSaveJob с явным значением для NSPrintJobSavingURL (URL, предоставленный скоординированной записью). Чтобы повредить эту мертвую блокировку NSPrintOperation на Mac OS X 10.9.2 или позже не выполнят скоординированную запись, если и только если установлены и NSPrintSaveJob и NSPrintJobSavingURL.

Если NSPrintSaveJob будет установлен, но NSPrintJobSavingURL не, то NSPrintOperation все еще выполнит скоординированную запись. То же идет для того, когда работа печати начинается с NSPrintSpoolJob, панель печати выведена на экран, и пользователь принимает решение Сохранить к PDF вместо того, чтобы отправить задание в принтер.

Неосновные вызовы потока - [NSDocumentController typeForContentsOfURL:error:]

До Mac OS X 10.10, это было возможно для - [NSDocumentController typeForContentsOfURL:error:], чтобы быть вызванным на неосновной поток. Это больше не имеет место. Однако, если Ваше приложение предназначается для Mac OS X 10.9 или ранее и переопределяет этот метод, необходимо удостовериться, что метод безопасен быть вызванным на неосновной поток.



Постепенное осуждение NSCell

Mac OS X 10.10 предпринимает другой шаг к возможному осуждению ячеек. Прямому доступу к ячейке управления обескураживают, и методы, позволяющие его, будут формально осуждаться в последующей версии. Множество уровня ячеек, APIs был продвинут на различные подклассы Управления для обеспечения доступа без ячеек к важной функциональности. NSLevelIndicator, NSTextField, NSSearchField, NSSlider и NSPathControl у всех есть новые свойства с этой целью. Основанные на ячейке NSTableViews теперь осуждаются, и основанный на представлении NSTableViews должен использоваться вместо этого. Основанные на матрице NSBrowsers также осуждаются в пользу основанного на элементе интерфейса.


NSPathControl

Для воспрепятствования прямому доступу к ячейкам Mac OS X 10.10 добавляет новый основанный на элементе API к NSPathControl. Это избавляет от необходимости использовать NSPathComponentCell для управления компонентами пути. Кроме того, множество свойств было добавлено к NSPathControl, обеспечивающим доступ к важной функциональности, ранее только доступной через NSPathControlCell.


NSForm

Использование NSForm теперь осуждается. Используйте NSTextField непосредственно и рассмотрите использование NSStackView, если желаема помощь расположения.


NSMatrix

Использование NSMatrix неофициально осуждается. Мы ожидаем добавлять формальные макросы осуждения в последующей версии, но ее использованию обескураживают тем временем. Основное использование NSMatrix для групп переключателей, так вспомните, что для приложений соединился на 10,8 или позже, переключатели, разделяющие те же родительские взгляды, и действие будет действовать в качестве группы.


Слабые цели для NSControl & NSCell

Целевые свойства управления и подклассов ячейки были изменены для обеспечения надлежащего автоматически обнуляющего поведения слабой ссылки для приложений, соединенных на Mac OS X 10.10 и выше. Реализация пытается разместить цели, на которые нельзя безопасно сослаться слабо, но результат состоит в том, что сообщения теперь отправляются в цели в то время, когда они установлены. Если цель ставится к ссылке недопустимого объекта или объекту в процессе освобождения, это может вызвать катастрофические отказы в случаях, которые были ранее безвредны. Одно последствие этого изменения - то, что NSControl теперь имеет конкретную реализацию свойств действия и цели. Это - что-то, чтобы знать, если Вы планируете полагаться на него в 10,10, но также и развертываете свое приложение на предыдущих выпусках.


Новое автоматическое управление ограничением макета API

Под Mac OS X 10.10, теперь возможно непосредственно активировать и деактивировать объекты NSLayoutConstraint, не имея необходимость волноваться о добавлении их к надлежащему представлению наследователя. Это выполняется путем управления новым 'активным' булево свойством NSLayoutConstraint. Методы класса доступны для работы на многократных ограничениях одновременно, которые могут быть намного быстрее. Устаревший API на NSView для добавления и удаления ограничений теперь осуждается.


Расположение изображения в Кнопки

NSButtonCell теперь использует-imageRectForBounds: к изображениям позиции, выведенным на экран в кнопках, для приложений, соединился против Mac OS X 10.10 или позже.



NSTableView/NSOutlineView Общие Обновления

NSTableRowView теперь имеет свойства, чтобы определить, выбрана ли предыдущая и/или следующая строка. Это полезно для рисования выбора по-другому на основе этого состояния.
@property(getter=isPreviousRowSelected) BOOL previousRowSelected;
@property(getter=isNextRowSelected) BOOL nextRowSelected;
NSTableView теперь поддерживает возможность статически разработать содержание таблицы во время проектирования в XCode. Во время выполнения это разархивировано и идентично тому, что Вы разработали.

Можно также динамично создать статическое табличное представление с новым свойством: usesStaticContents.

Обычно, табличное представление будет только иметь в наличии подмножество общего количества потенциально доступных строк (в целом, это ограничивается видимой областью плюс некоторый превысивший ограничения допуск на быстро реагирующую прокрутку). Статическое табличное представление сохраняет все представления добавленными к таблице вокруг когда usesStaticContents=YES. Представления могут динамично быть удалены путем вызова removeRowsAtIndexes:withAnimation:. Источник данных не должен реализовывать numberOfRowsInTableView: когда usesStaticContents=YES. Статичные представления кодируются и декодируются с табличным представлением. Представления могут также динамично быть вставлены в табличное представление при помощи insertRowIndexes:withAnimation: однако, это требует реализации tableView:viewForTableColumn:row: обеспечить недавно вставленное представление, тогда имеющееся в наличии статически.

NSOutlineView также поддерживает возможность быть статически разработанным и работает так же к NSTableView. Однако для динамичного изменения представления схемы необходимо использовать методы: insertItemsAtIndexes:inParent:withAnimation: removeItemsAtIndexes:inParent:withAnimation: и moveItemAtIndex:inParent:toIndex:inParent:. Обеспечьте недавно вставленные элементы путем реализации метода источника данных outlineView:child:ofItem: и укажите, что они расширяемы путем реализации outlineView:isItemExpandable:. Не необходимо реализовать outlineView:numberOfChildrenOfItem при использовании статического представления схемы. Обратите внимание на то, что все предоставленные элементы должны быть encodable (т.е.: реализуйте протокол NSCoding), и уникальный (чтобы однозначно определить строку для данного элемента).

С тех пор 10.5, NSTableViews/NSOutlineViews сконфигурированы как боковые панели (исходные списки) путем установки selectionHighlightStyle в NSTableViewSelectionHighlightStyleSourceList. Это всегда имело побочные эффекты. В частности это будет управлять некоторыми метриками расположения для NSOutlineView и NSTableView. После установки стиля это также установит backgroundColor tableView к специальному внутреннему цвету. До 10,10 этих цветов был голубой градиент. После 10.10, NSVisualEffectView внутренне используется для создания размытого фона. После установки стиля можно было всегда изменять цвет далеко от внутреннего значения по умолчанию; выполнение этого заставит фон размытости не быть показанным (который может быть желаем). На 10,10, устанавливая selectionHighlightStyle в NSTableViewSelectionHighlightStyleSourceList теперь также установит появление в NSAppearanceNameVibrantLight. На 10,10, для исходных списков с помощью rowSizeStyle NSTableViewRowSizeStyleDefault, теперь автоматически управляют intercellSpacing.height. В целом это может варьироваться на основе стиля размера строки набора пользователя по Установкам системы, и важно протестировать каждый размер при создавании “исходного приложения” списка.

Анимации

Большинство анимаций в системе может быть замедлено путем установки NSAnimationSlowMotionOnShift по умолчанию в YES и удержание клавиши Shift. NSTableView ранее имел, используют значение по умолчанию под названием NSTableViewSlowMotion; это больше не используется.


NSWindow (Раздел, обновленный начиная с семени WWDC)

NSWindow имеет некоторый API для управления новым видом окон в OS X.

Первый новый API является titlebarAppearsTransparent; когда установлено в ДА, строка заголовка не рисует свой фон, позволяя все содержание под ним “показать через”. Это только применимо для использования этой опции при включении новой опции NSFullSizeContentViewWindowMask для окна styleMask. NSFullSizeContentViewWindowMask может быть объединен с названными окнами (использующий NSTitledWindowMask), чтобы позволить кадру contentView быть полным размером окна и занимать место под панелью инструментов/строкой заголовка. Выполнение этого может все еще потребовать, чтобы определенные части UI не появились под строкой заголовка/панелью инструментов; чтобы найти что область, используйте contentLayoutRect и contentLayoutGuide. Также обратитесь к примечаниям о contentInsets свойстве, и связал новые функции в NSScrollView, чтобы видеть, как использовать NSFullSizeContentViewWindowMask в усовершенствованных ситуациях.

Другое новое свойство вызывают, titleVisibility и перечислимые опции:
typedef NS_ENUM(NSInteger, NSWindowTitleVisibility) {
/* The default mode has a normal window title and titlebar buttons. */
NSWindowTitleVisible = 0,
/* The always hidden mode hides the title and moves the toolbar up into the area previously occupied by the title. */
NSWindowTitleHidden = 1,
};
Опция NSWindowTitleHiddenWhenActive была удалена начиная с семени WWDC.

В семени WWDC NSScrollView неправильно попытался бы «зеркально отразить» свое содержание, если бы это появилось под строкой заголовка и titlebarAppearsTransparent =YES. Это было фиксировано и больше не будет происходить.

Метод canStoreColor теперь осуждается; в некоторое время это не использовалось.

Новый начиная с семени WWDC: NSWindow никогда не поддерживал клиентские подпредставления добавления ни к чему кроме contentView. Некоторые приложения добавили бы подпредставления к contentView.superview (также известный как представление границы окна). NSWindow теперь зарегистрирует, когда он обнаружит этот сценарий: «Предупреждение NSWindow: добавление неизвестного подпредставления»:. приложения, делающие это, должны будут решить эту проблему, поскольку она предотвращает новые функции на 10,10 от работы должным образом. См. titlebarAccessoryViewControllers для официального API.

NSWindow теперь имеет возможность добавить официально известные подпредставления к области строки заголовка/панели инструментов. Представления должны быть обернуты с новым подклассом NSViewController, названным NSTitlebarAccessoryViewController, и добавлены к окну с «titlebarAccessoryViewControllers» API. Существует ряд методов, чтобы добавить и вставить titlebarAccessoryViewControllers, такой как addTitlebarAccessoryViewController: и removeTitlebarAccessoryViewControllerAtIndex:. Однако можно также использовать «removeFromParentViewController» для простого удаления данного дочернего контроллера представления. NSTitlebarAccessoryViewController имеет свойство для сообщения NSWindow, куда поместить представление (layoutAttribute) и свойство, чтобы определить, как это ведет себя в полном экране (fullScreenMinHeight). NSToolbar fullScreenAccessoryView API теперь осуждается, и клиенты должны использовать этот новый API.

Окна стиля HUD (использующий NSHUDWindowMask) теперь автоматически используют NSVisualEffectView для создания размытого фона. Приложения должны установить NSAppearance с именем NSAppearanceNameVibrantDark на окне для получения вибрирующих и темных средств управления.

NSView

shouldDrawColor теперь осуждается. Это не означало ничто значимое в некоторое время и не должно использоваться.

«GState» класс функций в NSView (и некоторые вспомогательные классы) теперь осуждаются. Во многих случаях они ничего не делали, и их использование не было четко определено.

NSSegmentedControl

NSSegmentedControl (и базовая ячейка) должным образом уважают флаг isBordered за приложения, соединенные на 10,10 и выше. Значение сохраняется с нормальными подпрограммами кодирования. По умолчанию ячейка будет иметь setBordered:YES сделанным в init.


Полупрозрачные Фоны и Вибрация Йосемайта / NSVisualEffectView (Раздел, обновленный начиная с семени WWDC)

Полупрозрачные фоны и связанная «вибрация» в Yosemite поддерживаются новым классом представления, NSVisualEffectView. «Вибрация» описывает составляющий композит режим, делающий специальное смешивание такой как “Плюс Более темный”, “Плюс Легче”, “Цветная Уловка”, и “Окрашивает Запись”. Это автоматически используется системой во многих местах, включая легкую сдобу, “исходный список” и табличные представления боковой панели, и покрывают. Некоторые динамично используют вибрацию на основе их содержания; например, когда определенные особые цвета используются, такие как новые цвета, NSTextField делает: [NSColor labelColor] и [NSColor secondaryLabelColor].

Если необходимо поддерживать вибрацию в одном из собственных представлений, следующим условиям нужно ответить:
• Представление должно содержаться в NSVisualEffectView.
• Представление должно возвратить YES из allowsVibrancy.
• effectiveAppearance представления должен возвратить YES из allowsVibrancy (это означает, что должно быть или появление NSAppearanceNameVibrantLight или NSAppearanceNameVibrantDark). (Обычно Вы устанавливаете появление на окне, или на NSVisualEffectView, и подпредставления наследуют появление.)

Внутренняя реализация NSVisualEffectView размывания и вибрации зависит от blendingMode. Если blendingMode установлен в NSVisualEffectBlendingModeBehindWindow, то размывание достигается путем описания прямоугольника к серверу окна, который должен быть размыт. Области, которые должны быть вибрирующими, также описаны похожим способом. Как только определенная область описана, чтобы быть вибрирующей, ANYTHING, нарисованный в той области, будет нарисован вибрирующий, даже вещи, нарисованные нарисованный перед вибрирующим подпредставлением. Поэтому, как только представление возвращает YES из allowsVibrancy, и это и все его подпредставления всегда будут вибрирующими — подпредставление не может выключить вибрацию путем возврата НЕ из allowsVibrancy. Например: рассмотрите большой квадратный NSView, возвращающийся НЕ из allowsVibrancy, заполняющего его содержание [NSColor blueColor]. Рассмотрите NSTextField, который является поверх этого синего представления, и NSTextField возвращает YES из allowsVibrancy. Квадратный кадр ограничения для NSTextField станет вибрирующим, включая синий цвет ниже, который будет выглядеть неправильным (синий прямоугольник в соответствии с текстом будет более темно-синим). Решения этой проблемы: синее представление должно также быть вибрирующим, и возвратить YES из allowsVibrancy. Или, NSTextField нужно к уклонению вибрации. Отказывание от вибрации может быть сделано одним из следующего: задержка появления к NSAppearanceNameAqua OR с помощью controlTextColor OR, переопределяющего allowsVibrancy и возвращающегося НЕТ. Это возможно к уклонению прямоугольные 100%-е непрозрачные представления путем добавления другого NSVisualEffectView и подпросматривает к нему, которые возвращаются НЕ из allowsVibrancy. Эти перекрывающиеся одноуровневые элементы не будут вибрирующими, но работы ONLY для режима наложения NSVisualEffectBlendingModeBehindWindow. Не то, чтобы это будет только уважать прямоугольную форму.

Если blendingMode установлен в NSVisualEffectBlendingModeWithinWindow, то использование Базовых Слоев анимации требуется. Лучше вызывать view.wantsLayer = YES на родительском представлении, содержащем NSVisualEffectView, поскольку размывание произойдет с ним и дочерние элементы NSVisualEffectView. Размывание для NSVisualEffectView достигается при помощи специальных Базовых фильтров Анимации. Вибрация для определенного подпредставления, возвращающего YES из allowsVibrancy, достигается путем установки layer.compositingFilter. Приложения, имеющие вибрирующие представления, не должны изменять layer.compositingFilter для представления. compositingFilter уровня применяется к, как уровень и все его дочерние элементы составляются к родительскому слою, и не возможно иметь дочернее представление, чтобы НЕ быть вибрирующим. Однако можно добавить одноуровневые представления по вибрирующему представлению; перекрывающиеся одноуровневые представления правильно не будут вибрирующими. Отметьте этот ONLY работы режимом наложения NSVisualEffectBlendingModeWithinWindow.

Не рекомендуется разделить NSVisualEffectView на подклассы и переопределить-drawRect: или-updateLayer.



NSImage изменяется на именованное время жизни изображения

При начале в Mac OS X сохраняются 10,10 именованных изображений. Ранее, названный изображениями был слабо сослан (и иногда кэшировался.) Это позволяет приложениям регистрировать именованное изображение с помощью - [NSImage setName:] API, и получают его позже использование + [NSImage imageNamed:] API. Для достижения того же образца на предшествующих выпусках было необходимо содержать дополнительную ссылку на изображение. Приложения, желающие гарантировать названный изображениями, освобождены, должен вызвать - [NSImage setName:] с нолем, прежде, чем выпустить их ссылку на изображение. Обратите внимание на то, что изменение имени системных иллюстраций или иллюстраций пакета загрузилось через + [NSImage imageNamed:] не поддерживается.

NSImage поддерживают для нарезанных изображений

resizingMode свойство изображения определяет, как то изображение вовлечено в прямоугольник, больше или меньший, чем естественный размер того изображения. Когда вовлечено прямоугольник большего размера NSImageResizingModeTile тиражирует изображение как образец. Когда вовлечено меньший прямоугольник изображение будет отсечен. NSImageResizingModeStretch изменит размеры изображения для адаптации точно указанному прямоугольнику. Когда изображение вовлечено в прямоугольник его собственного размера, оба режима не имеют никакого эффекта. NSImageResizingModeStretch является значением по умолчанию и соответствует поведение предыдущих выпусков.

capInsets свойство позволяет изображению иметь определенные области, расширяющиеся или размещающиеся рядом независимо, на основе resizingMode. В обоих режимах углы, определенные capInsets свойством, нарисованы, не масштабируясь или размещая рядом. Когда resizingMode будет NSImageResizingModeTile, горизонтальные края будут тиражированы вертикально, вертикальные края будут тиражированы горизонтально, и центр изображения будет тиражирован в обе оси. Когда resizingMode будет NSImageResizingModeStretch, горизонтальные края будут расширены вертикально, вертикальные края будут расширены горизонтально, и центр изображения будет расширен на обеих осях.

Обратите внимание на то, что вовлечение изображения в прямоугольник, меньший, чем его естественный размер, заставит края и углы быть расширенными для вписывания в тот прямоугольник.

NSBitmapImageRep поддерживают для свопинга байта данных изображения

В Mac OS X 10.10 NSBitmapImageRep теперь поддерживает явно указание порядка байтов данных изображения. Это может быть выполнено при помощи нового NS16BitLittleEndianBitmapFormat, NS32BitLittleEndianBitmapFormat, NS16BitBigEndianBitmapFormat и перечислений NS32BitBigEndianBitmapFormat. Они ведут себя эквивалентно к перечислениям CGBitmapByteOrder. Установка никакой опции порядка байтов производит поведение, идентичное МАКОСКСУ 10.9. Установка больше чем одной опции порядка байтов недопустима.

Значительно 8-разрядные данные изображения BGRA могут быть выражены путем передачи bitsPerSample=8, samplesPerPixel=4, bitmapFormat=NSAlphaFirstBitmapFormat|NS32BitLittleEndianBitmapFormat, и bitsPerPixel=32 к - [NSBitmapImageRep initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpace:bitmapFormat:bytesPerRow:bitsPerPixel:].

Соответствие NSOpenGLContext к NSLocking

NSOpenGLContext теперь соответствует протоколу NSLocking. - [Блокировка NSOpenGLContext] и - [NSOpenGLContext разблокировали], должен считаться эквивалентным CGLLockContext ([NSOpenGLContext CGLContextObj]) и CGLUnlockContext ([NSOpenGLContext CGLContextObj]).

Метод get NSOpenGLContext для связанного формата пикселя

Теперь возможно получить доступ к формату пикселя, связанному OpenGLContext с помощью - [NSOpenGLContext pixelFormat] метод.

Изменения в - [NSView noteFocusRingMaskChanged] (Раздел добавил начиная с семени WWDC),

- [NSView setNeedsDisplay:] и - [NSView setNeedsDisplayInRect:] раньше вызывал - [NSView noteFocusRingMaskChanged]. В Mac OS X 10.10 это больше не имеет место. Представления должны вручную выполнить вызов - [NSView noteFocusRingMaskChanged]. Это позволяет представлениям перерисовать части себя, напрасно не перерисовывая их фокусирующие кольца, которые могут быть дорогими.

Новые методы NSGraphicsContext CGContext (Раздел добавил начиная с семени WWDC),

В МАКОСКСЕ 10.10 NSGraphicsContext предлагает два новых метода, +graphicsContextWithCGContext:flipped: и-CGContext. Эти методы являются точно тем же как существующим +graphicsContextWithGraphicsPort:flipped: и методы-graphicsPort, за исключением которых они вводятся, чтобы принять и возвратить CGContextRef соответственно. Старые методы будут осуждаться в будущем выпуске.


NSColor (Раздел, обновленный начиная с семени WWDC)

NSColor представляет новую систему, раскрашивает 10.10 для статического текста и связанных элементов: labelColor, secondaryLabelColor, tertiaryLabelColor, и quaternaryLabelColor. Первые два для основных и вторичных элементов статического текста. Эти цвета применяются к новым меткам, вытащенным в Интерфейсном Разработчике. tertiaryLabelColor для отключенных элементов статического текста, и quaternaryLabelColor для больших отключенных элементов статического текста. Эти цвета могут также быть применены к другим связанным элементам UI, где связано и надлежащие; например, quaternaryLabelColor рекомендуется для строк разделителя, а также больших глифов или значков.

Эти новые цвета, а также некоторые существующие системные цвета теперь красят по-другому в зависимости от текущего появления. Обязательно выберите цвета, в то время как надлежащее появление имеет силу, и не кэшируйте их значения отдельного цветового компонента.


Расстановка переносов

Расстановка переносов теперь включена по умолчанию для всего текстового рендеринга и измерения. Фактор расстановки переносов 0.4.

Кроме того, обработка символа мягкого переноса (U+00AD) была изменена. Когда расстановка переносов отключена, в предыдущих версиях OS X мы обработали символ так же, как возможность разрыва строки. Теперь, мы всегда показываем глиф дефиса, переносясь в символе.