Spec-Zone .ru
спецификации, руководства, описания, API
Библиотека разработчика Mac Разработчик
Поиск

Примечания выпуска Developer OS X:
Среда разработки приложения какао (10.8 и ранее)

Этот документ содержит информацию о версии для OS X 10.8, его обновления, и ранее. См. текущая информация о версии для AppKit прежде, чем обратиться к этому документу, поскольку более свежие изменения в текущем выпуске могли иметь obsoleted некоторые элементы, обсужденные здесь.

Примечания ниже разделяются на следующие разделы:




Отмечает определенный для OS X 10.8

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




Поддержка NSDocument iCloud

В 10,8, находящиеся в NSDocument приложения с правом контейнерных идентификаторов повсеместности получают новую функциональность и UI для упрощения управления документооборотом iCloud.

Когда iCloud включен, и приложение сначала запущено или повторно активировано, и никакие окна не видимы или быть восстановленным, вместо того, чтобы создать новый Документ без названия, NSDocumentController выведет на экран немодальную открытую панель, показывающую библиотеке iCloud пользователя. Оттуда приложение может или открыть существующий документ от iCloud или локальной файловой системы, или создать новый документ. Для поддержки этой новой немодальной открытой панели NSDocumentController добавил-beginOpenPanelWithCompletionHandler: и-beginOpenPanel:forTypes:completionHandler:. Когда iCloud будет включен, Обратите внимание на то, что в настоящее время прежний метод будет только выполнять открытую панель немодально.

Если Ваше приложение переопределяет - [NSDocumentController openDocument:] и вызывает-URLsFromRunningOpenPanel, необходимо переключиться на вызов-beginOpenPanelWithCompletionHandler: вместо этого.

Если Ваше приложение переопределяет - [NSDocumentController runModalOpenPanel:forTypes:] для настройки открытой панели, включая добавление вспомогательного представление, необходимо также переопределить-beginOpenPanel:forTypes:completionHandler: и сделайте ту же настройку там. Для совместимости NSDocumentController будет продолжать вызывать прежнего, если это будет переопределено, когда последний не. В результате панель будет выполнена модально вместо немодально, давая Вашим пользователям субоптимальный опыт.

поддерживающие iCloud приложения также получают UI, чтобы упростить движущиеся документы в облако через перемещение и сохранить панели. Существует также ярлык в меню строки заголовка документа для быстрого перемещения документа iCloud. Этот пункт меню использует новый метод IBAction на NSDocument:-moveDocumentToUbiquityContainer:. Кроме того, как упомянуто в разделе по Проектам, новые документы могут быть сохранены автоматически непосредственно к контейнеру iCloud приложения, в зависимости от предпочтения пользователя.

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

Приложения, не хотящие использовать эти функции для любых из их подклассов NSDocument, могут переопределить + [NSDocument usesUbiquitousStorage] и возвратиться НЕТ. Если все приложение объявило, что подклассы NSDocument возвращаются НЕ из этого метода, то NSDocumentController никогда не будет показывать новую немодальную открытую панель.

Оптимизация сохранения версий NSDocument

В Mac OS 10.7, когда NSDocument решил, что его файл имел право быть сохраненным, поскольку версия до сохранения его синхронно скопирует файл для выполнения сохранения. Для значительно больших файлов это могло вызвать, долго подвешивает то прерывание поток операций пользователя. В приложениях, соединенных на или после 10.8, NSDocument может избежать, чтобы это зависло путем усиления 'резервного' файла, создающегося во время безопасного сохранения.

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

Использование NSDocument - [NSDocument backupFileURL], новый метод в 10,8, для управления этим поведением. Когда текущий файл должен быть сохранен, этот метод только возвращает URL. Когда этот метод возвращает неноль,-writeSafelyToURL:ofType:forSaveOperation:error: должен гарантировать, чтобы исходное содержание файла существовало в том расположении до возврата. Сбой сделать так эквивалентен потере данных, так как пользователь будет неспособен вернуться к их предыдущим версиям. Если Ваш подкласс NSDocument переопределяет-writeSafelyToURL:ofType:forSaveOperation:error: и не вызывает супер, когда Вы соединяетесь против 10,8, необходимо гарантировать, что реализация соблюдает это правило. Также можно переопределить-backupFileURL и возвратить ноль для отключения этой оптимизации. Путем выполнения так,-saveToURL:ofType:forSaveOperation:completionHandler: отступит к старому синхронному методу копии. Приложения, делающие оперативное сохранение и не использовать безопасно сохраняющий метод, будут почти всегда хотеть отключить эту оптимизацию, если стоимость создания 'резервного' файла не будет значительно меньше, чем копия.

Вы не должны переопределять-backupFileURL для возврата пользовательского URL. Ваше переопределение должно или вызвать супер или ноль возврата.

Иногда версии сохраняются после того, как новый файл записан, такой как тогда, когда пользователь выбирает File> Save. В этом сценарии оптимизация файла резервной копии не возможна, таким образом, копия все еще необходима. Однако для приложений, соединенных на 10,8, NSDocument выполнит эту копию на фоновом потоке, оставляя основной поток разблокированным. Чтобы избежать повреждать эти версии путем изменения файла во время этой асинхронной копии, необходимо удостовериться, что любой прямой доступ к файлу документа сделан с-performSynchronousFileAccessUsingBlock: или-performAsynchronousFileAccessUsingBlock:.


Отладка-performActivityWithSynchronousWaiting:usingBlock:-performSynchronousFileAccessUsingBlock: и-performAsynchronousFileAccessUsingBlock:

В Mac OS 10.7, NSDocument добавил эти три APIs для обеспечения надлежащей сериализации доступа к файлу и пользовательского действия при использовании асинхронного сохранения. Когда асинхронному действию или доступу к файлу не удается должным образом вызвать его обработчик завершения, последующее использование этого APIs ожидает навсегда. К сожалению, вследствие асинхронной природы этого APIs, след их зависает, обычно не предоставляет достаточно информации, чтобы отладить проблему и идентифицировать незавершенную работу.

В 10,8, NSDocument обеспечивает инструмент, чтобы помочь Вам более легко отладить эти проблемы. Если Ваше приложение зависает в-performActivityWithSynchronousWaiting:usingBlock: или-performSynchronousFileAccessUsingBlock: прервите отладчик и выполните эту команду:
po _NSDocumentSerializationInfo()
Вывод этой команды будет содержать перечисление всех незавершенных вызовов к ним сериализация APIs, включая рассматриваемый экземпляр документа след, где API был вызван, тип сериализации (доступ к файлу по сравнению с действием), и текущий статус (ожидающий эксклюзивного доступа по сравнению с эксклюзивным доступом предоставлен, но блок еще не был выполнен по сравнению с блоком, выполняется).

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


Новые и обновленные операции NSDocument

В 10,8, NSDocument добавил некоторые новые операции управления документооборотом и улучшил других.

Пользователи могут теперь переместить и переименовать документы из приложения при помощи Перемещения К … и Переименовать … команды из меню File или меню строки заголовка документа. Перемещение К … команде показывает пользователю простую панель, позволяющую пользователю перемещать документ новому каталогу. Переименовывание … команда заставляет заголовок в строке заголовка окна становиться доступным для редактирования, позволяя пользователю изменить заголовок документа. Новый APIs, управляющий этими операциями, является-renameDocument:-moveDocument:-moveDocumentWithCompletionHandler: и-moveToURL:completionHandler:.

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

Определенные документы, которые решает система, не должны быть отредактированы, такие как присоединения из Почтового приложения, будет автоматически дублирован, когда пользователь редактирует их, чтобы избежать изменять оригинал. Это работает, сразу заставив документ быть сохраненным автоматически к ~/Library/Autosave информационный каталог с NSAutosaveElsewhereOperation. autosavedContentsFileURL установлен в то расположение, и fileURL установлен в ноль, таким образом, документ начинает вести себя как двойной документ без имени.

Существует новый API, чтобы запросить и управлять «заблокированным» состоянием документа.-isLocked возвращает YES, когда NSDocument думает, что его файл не может быть отредактирован по причинам включая, но не ограничиваясь этим, «пользователя неизменный» устанавливаемый флаг, недостаточные полномочия и-checkAutosavingSafetyAndReturnError: возврат НЕТ. Можно попытаться разблокировать документ с-unlockDocumentWithCompletionHandler: и-unlockWithCompletionHandler: APIs. NSDocument попытается разблокировать файл путем очистки «пользователя неизменный» флаг и восстановления полномочий записи. Если это не будет достаточно для разблокирования файла, или файл не может быть разблокирован, то работа перестанет работать. Можно попытаться заблокировать документ с-lockDocumentWithCompletionHandler: и-lockWithCompletionHandler: APIs. NSDocument попытается заблокировать файл путем установки «пользователя неизменный» флаг. Если файл не может быть заблокирован, то работа перестанет работать. Существует два отдельных метода IBAction для того, чтобы разблокировать и заблокировать:-unlockDocument: и-lockDocument:. При обеспечении пользовательского UI для этих пунктов меню во время проверки необходимо использовать-isLocked для решения, какое действие должно использоваться.

Для приложений, принимающих +autosavesInPlace, команда Revert была разбита в многократные пункты меню, позволяющие возвращаться к ключевым версиям, не требуя, чтобы пользователь ввел браузер Версий. Эти пункты меню продолжают использовать-revertDocumentToSaved: действие и использование тег пункта меню для идентификации, который выбирает элемент пользователь. Вы не должны пытаться изменить эти пункты меню всегда.

Наконец,-browseDocumentVersions: новый метод IBAction на NSDocument, инициировавшем его запись в браузер Версий.


Проекты NSDocument

В приложениях, соединенных на или после 10.8, когда пользователь редактирует Документ без названия в поддерживающем iCloud приложении, NSDocument автоматически сохранит его к контейнеру повсеместности по умолчанию, как определено [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil], если пользователь в частности не отключил это. В этом случае документ будет сохранен к ~/Library/Autosave информация как нормальный.

После того, как сохраненный к iCloud, эти документы ведут себя очень как регулярные сохраненные документы — у них есть значок прокси в строке заголовка, они могут накопить версии и т.д. Однако, когда пользователь принимает решение Сохранить или Закрыть документ, панель сохранения будет представлена, чтобы позволить пользователю подтверждать автоматически выбранное название и местоположение, присваивать новое, или даже удалять файл. Документы в этом состоянии вызывают «проектами». Если пользователь делает что-то до Сохранения или Близко к указывает, что они хотят, чтобы документ имелся в наличии, документ больше не будут считать проектом и следовательно не покажет панель сохранения на Сохранении или Близко. Перемещение, переименовывая, или блокируя файл или редактируя его в другом приложении является некоторыми примерами того, что может заставить документ прекращать быть проектом. Можно получить и установить черновое состояние документа с новым - [NSDocument isDraft] и - [NSDocument setDraft:] APIs.

Когда недавно создаваемый документ сохраняется как проект, NSDocument вызывает-setFileURL: не влияя на состояние «Edited» документа, как показано в строке заголовка. Ни один из NSSaveOperations в Mac OS 10.7 не допускает это, таким образом, NSDocument в 10,8 определяет новую работу сохранения: NSAutosaveAsOperation. Этот новый NSSaveOperation будет использоваться-autosaveWithImplicitCancellability:completionHandler: при определенных обстоятельствах. Например, новый несохраненный документ, измененный с NSChangeDone, будет использовать NSAutosaveAsOperation вместо NSAutosaveElsewhereOperation. URL, использующийся для NSAutosaveAsOperation, определяется внутренне NSDocument и пытается избежать конфликтов имен путем добавления числа к имени дисплея документа, которое будет постепенно увеличено, пока никакой конфликт не найден.

Некоторые приложения используют-updateChangeCount: заставить NSDocument сохранять автоматически изменения, не происходящие непосредственно от пользователя. Например, при импорте несобственного типа документа, некоторые приложения создают новый документ с импортированным содержанием и вызывают-updateChangeCount: гарантировать, что документ сохраняется автоматически с тем содержанием. Много приложений используют NSChangeDone с этой целью. Однако, так как пользователь явно не вызывал это изменение, это - нежелательный для превращения этого документа в проект. Приложения должны стараться использовать корректный NSDocumentChangeType — в этом случае, NSChangeReadOtherContents — для предотвращения преобразования в проект. Используя NSChangeDiscardable также предотвратит создание проекта.

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

Если подклассы NSDocument одного или более Ваших приложений не должны сохранять документы без названия как проекты, необходимо переопределить + [NSDocument autosavesDrafts] и возвратиться НЕТ.


NSDocument, настраивающий черновые имена по умолчанию

В Mac OS 10.7, все недавно создаваемые документы вызвали «Неназванные» или «Неназванные <число>», пока пользователь не дал им заголовок путем сохранения. В 10,8, NSDocument позволит Вашему приложению заменять «Неназванный» пользовательской строкой, которая является более дескриптивной для Вашего приложения. Например, приложение текстового редактора может принять решение автоматически назвать документы «Резюме», когда они создаются из определенного шаблона, или приложение для обработки электронных таблиц может предпочесть, чтобы новые документы были вызваны «электронной таблицей» вместо «Неназванного». Можно сделать это в приложении путем переопределения - [NSDocument defaultDraftName] и возврата пользовательской локализованной строки. Если необходимо, NSDocument добавит число, чтобы сделать уникальное имя.



CoreAnimation обновляет для NSView (т.е.: CALayer поддержал NSView),

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

• Когда представление поддерживается уровнем, NSTextField был обновлен, чтобы позволить сглаживанию шрифта LCD работать. До 10,8, NSTextField непосредственно вовлек бы текст в содержание уровня; это заставило бы текст представлять неправильно вследствие алгоритма сглаживания шрифта LCD, не имеющего смежные пиксели для сглаживания шрифтов с. Поддержанные уровнем приложения, вручную составляющие текст, должны переместиться в использование NSTextField для получения надлежащего сглаживания шрифта LCD. Один протест состоит в том, что NSTextField действительно требует наследователя, который поддерживается уровнем и непрозрачен; это не должно быть прямое родительское представление, но некоторое представление в цепочке наследователя должно быть непрозрачным для этого, чтобы быть включенным и работа правильно.

• Для приложений, соединяющихся на 10,8, все поддержанные уровнем представления могут выключить сглаживание шрифта LCD для имения текстового рендеринга лучше. В частности, если представление возвратится НЕ из-isOpaque, то AppKit выключит шрифт LCD, сглаживающий прежде, чем вызвать drawRect представления: реализация. Иначе, получение текста на прозрачный уровень будет выглядеть неправильным (обычно, это выглядит более смелым и не гладкое). Однако могут быть некоторые конкретные случаи, где поддержанное уровнем представление знает, что вручную вовлекает текст в непрозрачную область. Для этих представлений рекомендуется, чтобы сглаживание шрифта было явно возвращено на прежде, чем составить текст. Пример:
CGContextRef ctx = NSGraphicsContext.currentContext.graphicsPort;
CGContextSetShouldSmoothFonts(ctx, true);
[@"Tandem Unicycle" drawInRect: ... ];
• До 10,8, вызывая setLayer: на NSView мог не должным образом обновить позицию уровня до изменения размеры, или репозиция представления произошла; это было фиксировано.

• До 10,8, управлял AppKit, уровень будет уничтожен (и удален), когда представление было удалено из окна или переместилось в другое родительское представление. Это имело бы нежелательный эффект проигрывания любого пользовательского сета свойств на уровне. Для любого представления, явно имеющего setWantsLayer:YES, управлял базовый AppKit, уровень не будет уничтожен, и пользовательские свойства слоя набора не потеряются.

• До 10,8, когда AppKit удалил уровень, это управляло, это оставит набор делегата уровня NSView, имевшему уровень. Для приложений, соединенных на 10,8 и выше, делегат будет установлен в ноль, когда он будет удален (только если он «принадлежит» AppKit). Приложение должно повторно присвоить делегата в представлении, если они сохраняют прочь и восстанавливают уровень находившийся в собственности AppKit (в целом, это не рекомендуется, и заставить уровень слоняться поблизости нужно вызвать setWantsLayer:YES).
• До 10,8, управлял AppKit, уровень будет всегда иметь набор layerContentsRedrawPolicy к NSViewLayerContentsRedrawDuringViewResize, когда уровень (лениво) создавался AppKit. Это препятствовало тому, чтобы значение было установлено в более раннее время, прежде чем создавался уровень. В 10,8, это теперь сделано во время инициализации представления (или в-init или в-initWithCoder). Для представлений, размещающих пользовательские уровни (через вызов к setLayer:), layerContentsRedrawPolicy будет все еще установлен в NSViewLayerContentsRedrawNever когда setLayer: вызывается; предполагается, что клиент хочет владеть уровнем и управлением, когда это перерисовывает. Для всего другого регулярного NSView отступающие уровни это требуется, чтобы должным образом устанавливать layerContentsRedrawPolicy (обычно в initWithFrame: или initWithCoder:) . До 10,8, layerContentsRedrawPolicy был закодирован в NIB вместе с другими свойствами представления, несмотря на то, чтобы там быть никаким способом установить его в Интерфейсном Разработчике. На 10,8, layerContentsRedrawPolicy больше не кодируется в NIB и должен быть явно установлен в коде.

• До 10,8, зеркально отраженное представление явно управляло бы позицией уровня путем обновления его каждый вызов к setFrameSize:. Однако это конфликтует с разрешением CoreAnimation сделать анимации типа телосложения на фоновом потоке без ввода от AppKit. Для решения этого AppKit теперь управляет-geometryFlipped на поддержке CALayer. До 10,8, точка привязки была также установлена быть или (0,0) или (0,1) - она варьировалась в зависимости от суперпредставления, являющегося isFlipped или нет. На 10,8, кадр уровня теперь равен кадру представления. Точка привязки также всегда устанавливается быть (0,0), так как позиции теперь равны. Для надлежащего управления зеркально отраженным состоянием уровня переопределите-isFlipped на NSView.

• Когда представление поддерживается уровнем, существует теперь два способа обеспечить содержание уровня. Новый предпочтительный путь состоит в том, чтобы реализовать-wantsUpdateLayer и возвратить YES. Когда это возвратится ДА, новый метод, названный-updateLayer, вызовут. В этой точке является надлежащим непосредственно установить view.layer.contents в изображение (NSImage или CGImageRef), который может должным образом простираться (т.е.: 3 части или 9 изображений части). Чтобы указать, как это должно простираться, используют свойство CALayer contentsCenter. Если дополнительный UI необходим для представления определенного управления, добавьте подпредставления (или подуровни) в - расположение. - расположение вызовут для представлений, отвечающих YES на wantsUpdateLayer, даже если не используется автоматическое расположение. Для получения нового вызова к-updateLayer лишите законной силы представление с setNeedsDisplay:YES. Для получения нового вызова к - расположение вызовите setNeedsLayout:YES. Когда представление поддерживается уровнем, использование wantsUpdateLayer может привести к лучшей производительности. Если методы рисования не будут разделены на подклассы и переопределены, большинство стандартных средств управления AppKit реализует это для возврата YES. Если представление возвратится НЕ из-wantsUpdateLayer, то содержание уровня будет заполнено в тем, что нарисовано в drawRect:.

• С 10,7, путь поддержанные уровнем представления анимационные изменения кадра варьируется в зависимости от значения layerContentsRedrawPolicy. Анимации обычно инициируются с помощью прокси аниматора (т.е.: [[просмотрите аниматора] setFrame:] ). Если layerContentsRedrawPolicy является NSViewLayerContentsRedrawDuringViewResize, то AppKit принимает потребности представления перерисовать на каждом шаге анимации, и это будет управлять анимацией на основном потоке путем вызова setFrame: многократно. Если layerContentsRedrawPolicy будет NSViewLayerContentsRedrawOnSetNeedsDisplay, то AppKit использует Базовую Анимацию для управления анимацией, сделанной неявно на фоновом потоке, и представление не получит setFrame: требование каждого шага анимации. Вместо этого Базовая Анимация расширит содержание уровня на основе того, как свойства установлены на CALayer. Обратите внимание на то, что использование NSViewLayerContentsRedrawOnSetNeedsDisplay заставляет представление работать точно так же, как CALayer был бы для анимации; это означает любые изменения свойства (которые анимируют), немедленно появится в их конечном состоянии, как только выполняется вызов анимации. Другими словами, следующее происходит:
view.layerContentsRedrawPolicy = NSViewLayerContentsRedrawPolicyOnSetNeedsDisplay; // This should be set in init
NSRect frame = view.frame; // Starts out as 100, 100
frame.size = NSMakeSize(300, 300);
[view.animator setFrame:frame]; // Animates the view frame from 100,100 to 300,300
// However, reading back in the view.frame at this point will indicate it is already at 300,300

• Для 10,8 и выше, значение по умолчанию для layerContentsRedrawPolicy варьируется на основе управления управлением в AppKit. Для простого NSView значением будет NSViewLayerContentsRedrawOnSetNeedsDisplay. Для пользовательского NSView, переопределяющего drawRect: значением по умолчанию будет NSViewLayerContentsRedrawDuringViewResize. При использовании-wantsUpdateLayer важно всегда установить layerContentsRedrawPolicy (идеально к NSViewLayerContentsRedrawOnSetNeedsDisplay).This, позволит представлению анимировать изменения кадра с Базовой Анимацией, в противоположность AppKit, управляющему анимацией на основном потоке.

• На 10,8, AppKit будет управлять следующими свойствами на CALayer (оба, когда «размещено уровнем» или «поддержано уровнем»): geometryFlipped, границы, (подразумеваемый) кадр, позиция, точка привязки, преобразовывают, тень*, скрытый, фильтры, и compositingFilter. geometryFlipped только изменяется для приложений, соединяющихся на 10,8 и выше. Используйте надлежащие методы покрытия NSView для изменения этих свойств.

• Когда поддержанное уровнем представление лишено законной силы с setNeedsDisplay: (или setNeedsDisplayInRect:) окно больше не лишается законной силы. Это позволяет просто представление, которое должно перерисовать, чтобы быть перерисованным, и никакие другие. Однако приложения должны заботиться, что они случайно не зависели от побочного эффекта, рисующего, это ранее произошло вследствие родительского представления, лишающего законной силы его дочерние представления.

• Когда представление имело набор layerContentsRedrawPolicy к NSViewLayerContentsRedrawOnSetNeedsDisplay, представление (и уровень), возможно, все еще было случайно лишено законной силы на изменениях кадра. Это было фиксировано для приложений, соединенных против 10,8, и когда NSViewLayerContentsRedrawOnSetNeedsDisplay установлен, приложение должно явно вызвать setNeedsDisplay: на изменениях кадра (при необходимости).

• NSAnimationContext теперь имеет новое свойство, allowsImplicitAnimation, для поддержанных уровнем представлений. Значение по умолчанию нет, и оно автоматически установлено в YES, когда - используется прокси аниматора. Когда ДА, это позволяет любому свойству CoreAnimation animatable быть анимированным. Это допускает вложенные анимации. Другими словами, выполнение [[просматривает аниматора] setFrame:frame], анимирует кадр на 'представлении', но также и любых подпредставлениях также. Обычно это желаемо, поскольку это позволяет автоизменению размеров подпредставлений быть сделанным анимированное, и все анимации, которые будут связаны в том же блоке анимации с той же продолжительностью. Если подпредставление имеет некоторое определенное свойство, они не хотят анимировать, новая группа анимации может легко быть создана для отключения этого поведения. Обратной является также истина; если Вы хотите, чтобы определенное свойство всегда имело анимацию CoreAnimation, то-allowsImplicitAnimation может явно быть установлен в YES. Использование в качестве примера:
[NSAnimationContext runAnimationGroup:^(NSAnimationContext *context) {
   context.allowsImplicitAnimations = YES; // Enable implicit CoreAnimation animations
   // Any operations done in this block will be animated
} completionHandler:nil];
Использование allowsImplicitAnimation очень подобно существующим свойствам в UIKit на iOS: [UIView areAnimationsEnabled] и [UIView setAnimationsEnabled:]

•-cacheDisplayInRect:toBitmapImageRep NSVIEW: будет теперь работать должным образом с поддержанными уровнем представлениями. Для приложений, соединенных против 10,8, уровень будет нарисован с помощью renderInContext CALAYER: позволяя ему представить всех подуровней, включая, которые могут не иметь связанного представления. Это позволяет использование-wantsUpdateLayer и-updateLayer: работать с-cacheDisplayInRect:toBitmapImageRep:.

• При использовании поддержанных уровнем представлений Базовая Анимация анимирует уровень от своего состояния представления до любого состояния, которое Вы устанавливаете на уровне (или представление). Однако иногда анимация поддержанного уровнем представления может не анимировать от желаемого расположения или состояния. Если Ваше представление (и неявно уровень) никогда не имело возможность вывести на экран, это может произойти. Например, рассмотрите этот пример:
NSRect frame = view.frame; // Starts at 0,0 -- the view was already drawn on screen at this location
frame.origin = NSMakePoint(100, 100);
view.frame = frame; // The view should move to 100,100 -- however, it has not drawn yet
frame.origin = NSMakePoint(300, 300);
[[view animator] setFrame:frame]; // The view should animate from point 100,100 to point 300,300
Желаемая анимация от точки 100 100 - 300 300 - однако, что может произойти, представление, анимирует от точки 0,0 к 300 300! Это вызвано тем, что изменения в представлении и деревьях уровня объединяются в NSAnimationContexts/CATransactions. Поскольку невозможно знать наиболее удаленное определение объема контекста анимации / транзакция, изменения могут быть объединены даже когда не явно желаемый. Для обработки этих случаев каждый набор изменений/анимаций, Вы хотите быть видимыми, должен быть изолирован в их собственной группировке анимации. Это заставит представление/уровень представлять с требуемым изменением свойства. Например, это будет работать для осуществления первого рендеринга для случая перед запусками анимации путем объединения в цепочку фактической анимации до конца первой группы анимации:
[NSAnimationContext runAnimationGroup:^(NSAnimationContext *context) {
context.duration = 0;
NSRect frame = view.frame; // Starts at 0,0 -- the view was already drawn on screen at this location
frame.origin = NSMakePoint(100, 100);
view.frame = frame; // The view should move to 100,100 -- however, it has not drawn yet
} completionHandler:^ {
NSRect frame = view.frame; // Now it has drawn at 100,100
frame.origin = NSMakePoint(300, 300);
[[view animator] setFrame:frame]; // This will correctly animate from 100,100 to 300, 300 using the default animation context duration
}];

NSTableView/NSOutlineView

Для Представления Основанный NSTableView (или NSOutlineView), всегда было неправильно получить представление от таблицы в методе делегата tableView:heightOfRow: (или outlineView:heightOfItem:). Теперь, таблица обнаружит, если или этих методов будет вызван из реализации метода делегата, и выдайте исключение (или зарегистрируйте ошибку): viewAtColumn:row:makeIfNecessary: и rowViewAtRow:makeIfNecessary:.

NSControl теперь имеет новый API для показа «подсказок расширения». Это прежде всего доступно для подсказок расширения, которые будут показаны при использовании Представления Основанный NSTableView. Вызовите setAllowsExpansionToolTips:YES, чтобы позволить им быть показанными.

NSTableView теперь имеет метод для регистрации (или соединение) дополнительный NIBs для Представления Основанный NSTableView, названный-registerNib:forIdentifier:. Когда каждый вызывает-makeViewWithIdentifier:owner: идентификатор, сначала таблица посмотрит в своей очереди повторного использования для представления к повторному использованию с тем же самым идентификатором. Если Вы не будете найдены, то это будет тогда искать зарегистрированный NIBs с тем идентификатором. Если NIB найден, это инстанцируют с 'владельцем', переданным методу. Все представления верхнего уровня в инстанцированном NIB тогда помещаются в очередь повторного использования с их текущим идентификатором. Поэтому важно всегда установить идентификатор для всех представлений верхнего уровня в NIB, регистрирующемся в таблице. Определенное представление с требуемым 'идентификатором' тогда возвращается из-makeViewWithIdentifier:owner:. Для определенного идентификатора, при отсутствии доступных представлений для повторного использования, или не не связывались/регистрировали NIBs (или ни одно создаваемое во время проектирования в IB), тогда метод-makeViewWithIdentifier:owner: возвратит ноль. Единственный NIB может быть зарегистрирован многократно с различными идентификаторами; это должно быть сделано для каждого представления верхнего уровня, которое находится в NIB. Соответствующий метод,-registeredNibsByIdentifier, возвратится, NSDictionary со всеми зарегистрировал NIBs. Ключ в словаре будет идентификатором, и значением будет зарегистрированный NIB. Чтобы не зарегистрировать NIB, передайте 'ноль' в для NIB в-registerNib:forIdentifier:.

NSOutlineView

Следующие методы теперь поддерживают быть анимированным через - прокси аниматора:-expandItem:-expandItem:expandChildren:-collapseItem: и-collapseItem:collapseChildren:. Как пример, для анимации расширения определенного элемента: [[аниматор outlineView] expandItem:item];

До 10,8, вызывая-reloadItem: (или-reloadItem:reloadChildren:) если строка изменилась от того, чтобы быть расширяемым к тому, чтобы не быть расширяемым (или наоборот), на NSView Основанный NSOutlineView мог не перезагрузить кнопку треугольника раскрытия.


NSButton / NSButtonCell

Для приложений, соединенных на 10,8, NSButton и NSButtonCell теперь используют льва API drawFocusRingMask и focusRingMaskBounds, чтобы сделать его получение фокусирующего кольца. Ранее, вызов setShowsFirstResponder:YES на NSButtonCell и вручную рисование ячейки включали бы фокусирующее кольцо. На 10,8 это больше не имеет место, ячейка больше явно рисует фокусирующее кольцо. Для настройки фокусирующего кольца переопределите реализацию NSButtonCell drawFocusRingMaskWithFrame:inView:.

NSButton, сконфигурированный как переключатель (с набором-buttonType к NSRadioButton), будет теперь работать в группе переключателей для приложений, соединенных на 10,8 и позже. Для имения работы кнопки в радио-группе используйте то же - действие для каждого экземпляра NSButton и имейте то же суперпредставление для каждой кнопки. То, когда этим условиям удовлетворят, проверяя одну кнопку (путем изменения - состояние к 1), снимет флажок со всеми другими кнопками (путем установки их - состояние к 0).

NSInterfaceStyle

NSInterfaceStyle теперь осуждается. Методы не использовались в AppKit в некоторое время.

Весь «мнемонический» набор методов теперь осуждается. IE, в NSButtonCell: setTitleWithMnemonic: setAlternateTitleWithMnemonic: setAlternateMnemonicLocation: alternateMnemonicLocation, и alternateMnemonic. Методы, берущие заголовок, все еще вызовут setTitle: с амперсандом, разделенным от параметра. Под MacOS эти методы исторически не использовались и ничего не сделали.



Изменение масштаба ScrollView

NSScrollView теперь имеет встроенную поддержку увеличения. Необходимо выбрать - в путем установки allowsMagnification свойства в YES. Когда пользователь выполнит жест повышения, NSScrollView увеличит, центрируясь вокруг расположения мыши. Когда пользователь выполнит умный жест изменения масштаба (двойное касание с 2 пальцами на сенсорных панелях), NSScrollView попытается разумно увеличить содержание под курсором. Однако NSScrollView нуждается в помощи от Вашего представления документа для определения расположения содержания. Посмотрите раздел Smart Zoom ниже для большего количества подробных данных.
/* Allow the user to magnify the scrollview. */
@property BOOL allowsMagnification;
/* This value determines how much the content is currently scaled. To animate the magnification, use the object's animator.
The default value is 1.0.
*/
@property CGFloat magnification;
/* This value determines how large the content can be magnified. It must be greater than or equal to the minimum magnification.
The default value is 4.0.
*/
@property CGFloat maxMagnification;
/* This value determines how small the content can be magnified. The default value is 0.25.
*/
@property CGFloat minMagnification;
/* Magnify content view proportionally such that the entire rect (in content view space) fits centered in the scroll view.
The resulting magnification value is clipped to the minMagnification and maxMagnification values. To animate the magnification,
use the object's animator.
*/
- (void)magnifyToFitRect:(NSRect)rect;
/* Scale the content view such that the passed in point (in content view space) remains at the same screen location once the scaling
is completed. The resulting magnification value is clipped to the minMagnification and maxMagnification values. To animate the
magnification, use the object's animator.
*/
- (void)setMagnification:(CGFloat)magnification centeredAtPoint:(NSPoint)point;
Свойство увеличения заметно. Существуют также уведомления, которые сообщат Вам, когда свойство увеличения будет изменено вследствие пользовательского действия. Это может быть вследствие пользователя, выполняющего жест повышения или умный жест изменения масштаба. Когда анимация увеличения ценит себя через аниматора объекта, эти уведомления не отправляются.
/* This notification is sent at the beginning of a magnify gesture. The notification object is the scroll view performing the magnification.
*/
NSString *NSScrollViewWillStartLiveMagnifyNotification;
/* This notification is sent at the end of magnify gesture. The notification object is the scroll view view performing the magnification.
*/
NSString *NSScrollViewDidEndLiveMagnifyNotification;

Умное увеличение

Существует новый тип NSEvent для умного жеста изменения масштаба (двойное касание с 2 пальцами на сенсорных панелях) вместе с соответствующим методом NSResponder. В ответ на это событие необходимо разумно увеличить содержание.
NSEventTypeSmartMagnify
- (void)smartMagnifyWithEvent:(NSEvent *)event;
NSEventTypeSmartMagnify ограничивается 64 битами только.

Еще лучше позвольте NSScrollView выполнить интеллект для Вас. В Вашем представлении документа NSScrollView реализуйте следующий метод для обеспечения NSScrollView семантической информацией макета содержания.
/* Return the complete rect of the most appropriate content grouping at the specified location. For example, if your content
is divided into three columns, return the entire rect of the column that contains the location. NSScrollView will attempt
to magnify such that the smaller dimension fits inside the scroll view while remaining within the
minMagnification, maxMagnification range.
   If your content layout is sub-divided further than one level deep (for example, two boxes that each contain multiple text
boxes), then use the visibleRect parameter to determine when to provide the rect of a sub-grouping. Always return a rect
for the appropriate grouping. If there is no deeper content grouping, return the rect for the deepest grouping. NSScrollView
will determine when to pan, magnify in, and magnify out.
   Return NSZeroRect for the default behavior.
*/
- (NSRect)rectForSmartMagnificationAtPoint:(NSPoint)location inRect:(NSRect)visibleRect;


Жест беглого взгляда

Существует теперь API для получения жеста Беглого взгляда (также известный как словарь, ищут жест). Пользователь может выполнить этот жест с тремя пальцами единственное касание или надлежащее сочетание клавиш (Cmd-Ctl-D по умолчанию). Существует два новых метода NSResponder: метод события и метод действия.
/* Perform a Quick Look on the content at location in the event. If there are no Quick Look items at the location, call super.
Also, see quickLookPreviewItems: further below.
*/
- (void)quickLookWithEvent:(NSEvent *)event;
/* Perform a Quick Look on the text cursor position, selection, or whatever is appropriate for your view. If there are no Quick Look
items, then call [[self nextResponder] tryToPerform:_cmd with:sender]; to pass the request up the responder chain. Eventually
AppKit will attempt to perform a dictionary look up. Also see quickLookWithEvent: above.
*/
- (void)quickLookPreviewItems:(id)sender;
Для поддержки нового метода респондента события существует также новый NSEventType, NSEventTypeQuickLook. Единственные допустимые свойства и событие NSEventTypeQuickLook:-locationInWindow и - модификаторы. Событие беглого взгляда не входит через нормальный механизм события, поэтому нет никакой соответствующей маски события для него, и при этом Вы не должны пытаться искать его в sendEvent: или с nextEventMatchingMask: … методы.

Примечание: Реализация по умолчанию NSAPPLICATION quickLookPreviewItems: выполнит поиск по словарю. Примечание: Существует ошибка, заставляющая quickLoop методы респондента спрыгивать с NSWindow непосредственно к NSApp обход NSWindowController, NSDocument и NSAppDelegate.


NSPageController

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

NSPageController наследовался от NSViewController. Необходимо присвоить свойство представления представлению в иерархии представления. NSPageController не продает представление. NSPageController действительно вставляет себя в цепочку респондента.

Концептуально, NSPageController управляет сильным ударом между массивом страниц (arrangedObjects). Используя selectedIndex, можно определить, сколько страниц, прямых или обратных, пользователь может перейти.

Существует два режима, которыми NSPageController может управлять в, История и Пользовательский. Основное различие между этими двумя режимами - то, что режим History ожидает, что pageController.view будет содержанием, и режим Custom ожидает, что pageController.view будет быть контейнером для содержания, которое Вы предоставите путем возврата viewControllers в методах делегата.

Режим Истории NSPageController иначе Не Режим Контроллера Представления

Режим History разработан, чтобы быть самым простым способом создать историю UI. NSPageController будет управлять историей (arrangedObjects), снимками и пользовательской навигацией между страницами в истории.

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

Во время сильного удара следующие дополнительные методы делегата вызывают в следующем порядке:
- (void)pageControllerWillStartLiveTransition:(NSPageController *)pageController;
Это - хорошее время, чтобы спрятать информацию, которую необходимо восстановить, такие позиции прокрутки. После возврата из вышеупомянутого метода делегата скрыт pageController.view. В его месте NSPageController показывает частную иерархию представления для анимации ранее взятых снимков истории страницы. Это позволяет NSPageController оставаться быстро реагирующим пользователю без любой работы с Вашей стороны.
- (void)pageController:(NSPageController *)pageController didTransitionToObject:(id)object;
Вызванный после физически успешного сильно ударяют, но прежде чем завершилась анимация. Предоставляемый объект является страницей пользователь, по которому проводят к - новый объект selectedIndex в arrangedObjects. Если необходимо запустить некоторые фоновые задачи загрузки, теперь время, чтобы сделать это, однако, не блокируйте основной поток, или анимация будет заикаться или пауза.
- (void)pageControllerDidEndLiveTransition:(NSPageController *)pageController;
Сильно ударение и все анимации завершаются. Восстановите любую установку прокруток или что-либо еще, что необходимо сделать. pageController.view все еще скрыт в этой точке, и необходимо вызвать-completeTransition на NSPageController, чтобы сказать NSPageController скрывать частное представление перехода и показывать pageController.view. Часто Вы сразу делаете это, однако, если Ваше содержание не готово, можно вызвать это позднее. См. «Завершение Перехода» ниже.

NSPageController Пользовательский Режим иначе Режим Контроллера Представления

Пользовательский режим разработан, чтобы дать Вам больше контроля процессом сильного удара и упростить больше проектов UI, чем просто история. Можно даже использовать пользовательский режим для создания истории UI. В этом режиме pageController.view является контейнерным представлением, и представления содержания продаются viewControllers, предоставленным Вашим делегатом. (Подсказка: Нарисуйте свой фон в этом представлении.) Для включения пользовательского режима необходимо реализовать следующие два метода в делегате:
- (NSString *)pageController:(NSPageController *)pageController identifierForObject:(id)object;
- (NSViewController *)pageController:(NSPageController *)pageController viewControllerForIdentifier:(NSString *)identifier;
NSPageController кэширует контроллеры представления, предоставленные для каждого идентификатора, и только просит, чтобы его делегат создал больше, если Вы не делаете уже существует в его кэше (это очень подобно тому, как представление базировало работу NSTableViews.), Если у Вас есть различные типы представлений, Вы хотите сильно ударить в, затем предоставить различный идентификатор для каждого типа.

Когда необходимый, Вас попросят подготовить viewController со страницей через следующий дополнительный метод делегата. Если Вы не реализуете этот метод, то representedObject viewController установлен возразить.
- (void)pageController:(NSPageController *)pageController prepareViewController:(NSViewController *)viewController withObject:(id)object;
Вас попросят подготовить viewController с нулевым объектом для каждого уникального идентификатора, с которым это встречается. NSPageController будет использовать это для генерации снимка по умолчанию для того идентификатора.

Обычно при использовании пользовательского режима, набор страниц известен, и это - Ваша ответственность установить arrangedObjects и начальную букву selectedIndex.

Во время сильного удара следующие дополнительные методы делегата вызывают интервалом следующим порядком:
- (void)pageControllerWillStartLiveTransition:(NSPageController *)pageController;
Это - хорошее время, чтобы спрятать информацию, которую необходимо восстановить, такие позиции прокрутки. После возврата из вышеупомянутого метода делегата NSPageController берет снимок selectedViewController.view и затем удаляет его из pageController.view. NSPageController заменяет его частной иерархией представления для анимации ранее взятых снимков. В отличие от этого при росте истории, снимки еще могут не существовать для страницы, перемещенной к. В этом случае ранее собранный снимок по умолчанию используется для идентификатора той страницы. Независимо при использовании снимка по умолчанию или ранее собранного снимка фактического содержания, viewController подготовлен к странице, перемещенной к. Этот viewController.view тогда просят привлечь фоновый поток, в то время как сильный удар продолжается (примечание, представление в настоящее время без окон). Как только поточное получение фона завершается, начальный моментальный снимок заменяется недавно сгенерированным снимком.
 - (void)pageController:(NSPageController *)pageController didTransitionToObject:(id)object;
Вызванный после физически успешного сильно ударяют, но прежде чем завершилась анимация. Предоставляемый объект является страницей пользователь, по которому проводят к - новый объект selectedIndex в arrangedObjects. Важный, pageController.selectedViewController еще не был обновлен. В пользовательском режиме этот метод делегата не все, что интересный, однако, Если необходимо запустить некоторые фоновые задачи загрузки, теперь время, чтобы сделать это. Не блокируйте основной поток, или анимация будет заикаться или пауза.
- (void)pageControllerDidEndLiveTransition:(NSPageController *)pageController;
Сильно ударение и все сильно ударяют, анимации завершаются. selectedViewController.view все еще отсоединяется в этой точке, и необходимо вызвать-completeTransition на NSPageController, чтобы сказать NSPageController скрывать частное представление перехода и обновлять selectedViewController. Часто Вы сразу делаете это, однако, если Ваше содержание не готово, можно вызвать это позднее. См. «Завершение Перехода» ниже.

NSPageController, завершающий переход

Как обсуждено выше, NSPageController использует частную иерархию представления во время сильного удара. Когда Вы готовы нарисовать новое содержание, для создания бесшовного перехода к новому содержанию это - ответственность сообщить NSPageController. Идеально, новое содержание должно соответствовать снимок, и пользователь ничего не узнал. Вы говорите NSPageController завершать переход путем вызова-completeTransition. В случае необходимости viewController подготовлен, и затем contentView показан (или добавлен) к иерархии представления, и частное представление перехода скрыто.

Во время инициируемых анимаций NSPageController-pageControllerWillStartLiveTransition и-pageControllerDidEndLiveTransition вызывают на делегате. Обычно во время pageControllerDidEndLiveTransition Вы будете вызывать-completeTransition. Анимации Programatic через прокси аниматора не вызывают методы делегата, и Вы ответственны за вызов-completeTransition, когда завершается анимация. Это легко сделано через обработчик завершения на группировке NSAnimationContext. (см. ниже),

Немедленно изменить selectedIndex:
  pageController.selectedIndex = newIndex;
Анимировать изменение selectedIndex:
  [NSAnimationContext runAnimationGroup:^(NSAnimationContext *context) {
[[pageController animator] setSelectedIndex:newIndex];
} completionHandler:^{
[pageController completeTransition];
}];

Стили перехода NSPageController

Существует три стиля анимации перехода. Эти стили перехода независимы от режима делегата. Совершенно разумно создать стиль истории UI с помощью viewController (пользовательский режим) методы делегата. Просто установите стиль перехода соответственно.

NSPageControllerTransitionStyleStackHistory - Страницы сложены друг на друге. Страницы анимируют к праву показать предыдущую страницу. Следующие страницы анимируют в от права. (См. Safari как пример),

NSPageControllerTransitionStyleStackBook - Страницы сложены друг на друге. Страницы анимируют налево для раскрытия следующей страницы. Предыдущие страницы анимируют в слева. (См. Предварительный просмотр как пример),

NSPageControllerTransitionStyleHorizontalStrip - Страницы размечаются друг рядом с другом в одной длинной горизонтальной полосе

Лучший способ думать о двух стилях перехода штабеля состоит в том, чтобы думать о способе, которым страницы сложены друг на друге. В Книге страница 1 является первой. Страница 2 и последующие страницы сложены под страницей один. При навигации вперед, пользователь сильно ударяет текущая страница для раскрытия следующей страницы. При навигации назад, пользователь сильно ударяет предыдущая страница в и поверх текущей страницы. В Истории страницы сложены в течение долгого времени в обратном порядке. Т.е. страница 2 сложена поверх страницы 1, и страница 3 сложена поверх страницы 2, и т.д. … При навигации назад, пользователь сильно ударяет текущая страница для раскрытия предыдущей страницы. При навигации вперед, пользователь сильно ударяет следующая страница в и поверх текущей страницы.

Уровень NSPageController поддержанный режим

При использовании режима Custom, если pageController.view является уровнем, поддержанные, живые уровни используются во время перехода вместо снимков.

NSPageController отмечает

NSTableView не ориентирован на многопотоковое исполнение! Не говорите NSTableView перезагружать свои данные, в то время как он привлекает второй поток, или он откажет. При использовании режима истории не соединяйте pageController.view проводом к подпредставлению NSSplitView. Когда частное представление перехода будет помещено в иерархию представления, это фактически вызовет 3-е разделение. Можно работать вокруг этого при помощи пустого NSView как подпредставление NSSplitView и размещение реального содержания в подпредставлении пустого представления.


Гладкая прокрутка

Гладкая прокрутка была удалена из пользовательских настроек. Последствие этого - то, что изменилось имя по умолчанию. Любое использование «AppleScrollAnimationEnabled» должно быть заменено «NSScrollAnimationEnabled». Если необходимо определить состояние по умолчанию гладкой прокрутки, следующий код возвратит корректное значение BOOL
  [[NSUserDefaults standardUserDefaults] boolForKey:@"NSScrollAnimationEnabled"];

Ускоренная прокрутка

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



Изменения в загружающихся файлах пера

Чтобы поддерживать новые функции в локализации, некоторые пути загрузки пера в AppKit больше не используют осуждаемый loadNibFile:externalNameTable:withZone: метод. Если Ваше приложение использует определенные альтернативные методы локализации, зависящие от этого метода, вызываемого, и соединяется с Пумой SDK или позже, то локализованные ресурсы не могут быть загружены правильно. Необходимо переключиться на новые функции локализации, которые являются частью Пумы.



Автоматические приоритеты представления расположения

В 10,8, методы NSView setContentHuggingPriority:forOrientation: и setContentCompressionResistancePriority:forOrientation: теперь повысьте исключение, если приоритет является нулем или меньше, или больше, чем NSLayoutPriorityRequired. В 10,7 и ранее, эти значения были тихо приняты, но, возможно, позже привели к катастрофическому отказу.

Автоматическое Расположение улучшения NSSplitView

В 10,8, NSSplitView должным образом уважает ограничения, применился к его подпредставлениям, таким как их минимальные ширины представления. Существует также новый APIs для управления приоритетами содержания, определяющими и NSLayoutPriority, в котором представление разделения содержит свои размеры и также который просматривает размер изменения, если само представление разделения растет или уменьшается.
- (NSLayoutPriority)holdingPriorityForSubviewAtIndex:(NSInteger)subviewIndex;
- (void)setHoldingPriority:(NSLayoutPriority)priority forSubviewAtIndex:(NSInteger)subviewIndex;
Для использования в своих интересах этих улучшений Вы не должны реализовывать ни один из следующих методов NSSplitViewDelegate:
splitView:constrainMinCoordinate:ofSubviewAt:
splitView:constrainMaxCoordinate:ofSubviewAt:
splitView:resizeSubviewsWithOldSize:
splitView:shouldAdjustSizeOfSubview:
Эти методы являются несовместимыми с автоматическим расположением. Можно обычно достигать их эффектов и больше с автоматическим расположением.

Автоматическое Расположение NSTextField, обертывающий улучшения

В 10,8, NSTextField имеет некоторый новый APIs для разрешения лучшей поддержки полей обтекающего текста при автоматическом расположении.
- (void)setPreferredMaxLayoutWidth:(CGFloat)width;
- (CGFloat)preferredMaxLayoutWidth;
Когда Вы просите у поля обтекающего текста его размер, по умолчанию оно размечает, как будто оно имеет бесконечную ширину в наличии, т.е. в одной длинной линии (предполагающий, что оно не имеет никаких символов разрыва строки). Его intrinsicContentSize является тем же: широкий и короткий. Однако при установке предпочтительной максимальной ширины расположения текстовое поле тогда измеряет себя, как будто оно было ограничено rect той ширины (и бесконечная высота). При автоматическом расположении, не принимая никакие другие ограничения определяют его размер, его ширина не превысит его предпочтительное макс., и ее высота будет достаточна для показа всего текстового содержания.

Общий образец должен иметь переносящийся NSTextField, ширина которого является некоторой константой, определенной другими ограничениями, и чья высота должна быть достаточной для показа полного текста в той ширине. Это может быть достигнуто со следующим образцом:
[[textField window] layoutIfNeeded];
[textField setPreferredMaxLayoutWidth:[textField alignmentRectForFrame:[textField frame]].width];
Это работает, пока представление width текстового поля не является динамичным.

Автоматическое Расположение выравнивание NSControl rects

У Льва выравнивание rects, базовые линии и внутренние размеры содержания, о которых сообщают много средств управления, были немного выключены. В 10,8, они были исправлены. В частности NSPopUpButton был изменен для создания отчетов о intrinsicContentSize со значительно меньшим количеством дополнительного дополнения.

AppKit исторически сопротивлялся изменению управления, сообщил cellSize по причинам совместимости на уровне двоичных кодов, даже если изменяется основной объект. intrinsicContentSize предназначается, чтобы всегда быть корректным, и может использоваться в качестве «лучше sizeToFit», не используя автоматическое расположение, как так:
  NSRect alignmentFrame = (NSRect){NSZeroPoint, [control intrinsicContentSize]};
[управление setFrame: [управляйте frameForAlignmentRect:alignmentFrame]];

Знайте, что это только разумно для средств управления, имеющих и естественную ширину и высоту, как NSButtons. Средства управления, которые полностью гибки (такие как NSSlider) сообщат о NSViewNoIntrinsicMetric для своей ширины и/или высоты, и необходимо установить те размерности явно.

Автоматическое расположение и неличные кадры

При автоматическом расположении в 10,7, если представление возвращает YES из translatesAutoresizingMaskToConstraints и того представления, имеет неличный тип телосложения или источник (такой как бесконечность или NaN), исключение было бы повышено при создании соответствующих ограничений. Если не с помощью автоматического расположения, кадр был исторически тихо допущен (хотя представление не появится). В 10,8, автоматическое расположение теперь регистрирует предупреждение и сбрасывает все неличные кадры для обнуления для лучшей совместимости с неавтоматическим поведением расположения.

Конечно, все неличные кадры представления являются ошибками. Для помощи в разыскивании их новое пользовательское значение по умолчанию, NSViewRaiseOnInvalidFrames предоставлены. Если это установлено в ДА, то оба setFrameSize: и setFrameOrigin: (и расширением, setFrameSize:) повысит исключение, если их параметры будут неличными.



NSSharingService

NSSharingService является новым классом в 10,8, который может использоваться для совместного использования элементов к различным видам локальных и удаленных служб. Элементы являются объектами, реагирующими на протокол NSPasteboardWriting, как NSURL, NSImage или NSString. См. интерфейс в <AppKit/NSSharingService.h> для API.

Если NSURL будет файлом URL (указывающий на видео, например), то содержание файла будет совместно использовано. Если URL будет удаленным, то URL самостоятельно будет совместно использован.


Совместное использование интеграции сервисов для NSTextView

Контекстное меню NSTextView по умолчанию содержит совместное использование элементов службы, важных для текущего выбора.

В дополнение к поддержке контекстного меню, - [NSTextView orderFrontSharingServicePicker:] метод действия предоставляет поддержку для услуги средства выбора службы совместного использования, предоставленной NSSharingService. Новый метод NSTextViewDelegate,-textView:willShowSharingServicePicker:forItems: может быть реализован делегатом для дальнейшей настройки использования поведения средства выбора NSSharingServicePicker.


Слабые ссылки ARC

Запускаясь в 10,8, на экземпляры NSWindow, NSWindowController и NSViewController могут указать слабые ссылки ARC.


NSApplication

Если приложение будет запущено, потому что пользователь выбрал уведомление в Центре Уведомления, то NSApplicationLaunchUserNotificationKey будет присутствовать в userInfo словаре NSApplicationDidFinishLaunchingNotification. Его значение является объектом NSUserNotification.
- (void)applicationDidFinishLaunching:(NSNotification *)notification {
NSUserNotification *launchNotification = [[notification userInfo]
objectForKey:NSApplicationLaunchUserNotificationKey];
if (launchNotification) {
// application was launched by a user selection from Notification Center
}
}
NSApplicationLaunchUserNotificationKey заменил NSApplicationRemoteNotificationKey, представленный у Льва, но осуждающийся у Пумы.


Полный экран

Мы теперь позволяем полноэкранному окну занимать внешний дисплей. Это позволяет пользователям указывать, какой дисплей должен содержать полноэкранное окно первым перемещением неполноэкранного окна к желаемому дисплею. Когда полноэкранное окно находится на внешнем дисплее, другие дисплеи покрыты льняными окнами экрана, как прежде. Строка меню может быть показана mousing до вершины внешнего дисплея. Прикрепление автоскрыто и остается на любом краю дисплея, указан в пользовательских настройках. Если Ваше приложение реализует пользовательский полноэкранный переход, с помощью window:startCustomAnimationToEnterFullScreenWithDuration: необходимо выбрать целевой экран для полноэкранного окна путем нахождения экрана, содержащего большинство окна до перехода.

Большая часть базовой архитектуры Пробелов изменилась в 10,8. Это не должно иметь никакого эффекта на Ваше приложение, если Вы используете NSWorkspace и API NSWindow, но можно заметить изменения, если у Вас есть предположения о синхронизации того, когда текущее пространство изменяется во время полноэкранного перехода, например.



Используя NSSavePanel / NSOpenPanel API в Тестовой среде приложения

Когда Вы включаете игру в песочнице приложения для своего приложения (проверкой, «Включают Игру в песочнице Приложения» для цели в XCode), любые вызовы к объектам NSSavePanel и NSOpenPanel перенаправляются к отдельному процессу, выводящему на экран панель Save/Open. Этот процесс является pboxd (иначе «Блок питания»).

Поигравший в песочнице NSSavePanel и NSOpenPanels были представлены у Льва. Нет никаких новых изменений API у Пумы, однако внутренности работались на экстенсивно, чтобы добавить поддержку iCloud и разрешить различное использование и проблемы производительности. Примечания здесь являются подсказками для использования разработчика.

Примечание по осуждаемому APIs:

   Когда Ваше приложение поиграется в песочнице, тонкие аспекты устаревших методов в NSSavePanel и NSOpenPanel не будут работать. Методы замены были доступны некоторое время, Изменение Вашего кода для использования поддерживаемого APIs не будет препятствовать тому, чтобы Вы отключили игру в песочнице приложения в будущем. Теперь было бы хорошее время для учета предупреждений, которые компилятор давал Вам.

Иерархия классов:

Как описано в: Руководство по проектированию Тестовой среды приложения

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

Заявленная иерархия похожа на это:
NSOpenPanel : NSSavePanel : NSPanel : NSWindow : NSResponder : NSObject
Фактическая иерархия (во время выполнения) похожа на это:
NSOpenPanel : NSSavePanel : NSObject
если Вы или кто-либо, кому Вы передаете экземпляр NSOpenPanel или NSSavePanel , предполагаете, что методы NSPanel, NSWindow или NSResponder доступны через тот экземпляр — Ваше приложение может встретиться с методом, не найденным исключением.

Доступность APIs NSWindow на экземпляре NSOpenPanel и NSSavePanel:

У Пумы, в поигравшем в песочнице приложении, можно обработать экземпляр NSSavePanel или NSOpenPanel, как будто это было разделено на подклассы от NSPanel во время трех четко определенных промежутков времени: вызовы Метода делегата, блоки завершения панели и аксессуар просматривают вызовы метода действия.

Ограниченный Доступ к файлу влияет на поддержку Метода делегата:

Как описано в разделе «Powerbox and File System Access Outside of Your Container» Руководство по проектированию Тестовой среды приложения, поигравшее в песочнице приложение имеет ограниченный доступ к файловой системе, только после того как пользователь указывает иначе на основе файла файлом, или Ваше приложение имеет дополнительные права на файлы.  Методы делегата NSOpenPanel и NSSavePanel ведут себя то же при Игре в песочнице Приложения, однако что можно сделать с URLs, предоставленным теми методами, изменился. URLs, переданный этим методам делегата, не может использоваться для получения информации об объектах, к которым относится URLs. Это означает не только, что содержание файла недоступно, но также и объектные метаданные недоступны. Другими словами, обо всем можно сделать с этим URLs, анализируют их как (стандартизированный, структурированный) строки.

NSOpenPanel и NSSavePanel не предназначаются для использования в контейнерном каталоге Поигравшего в песочнице Приложения. Каталог Контейнера приложения является абстракцией, которую конечный пользователь вряд ли будет в состоянии найти со Средством поиска. Поэтому каталог Контейнера приложения не должен быть представлен конечному пользователю в открытую и сохранить панели также. Если Ваше приложение пытается установить первоначальный каталог открытого или сохранить панель к каталогу Контейнера приложения (или подкаталог там), код в pboxd обнаруживает это и перенаправляет панель к корневому каталогу пользователя.

Переименование строки заголовка

Нет никакого общедоступного API для Переименования Строки заголовка за пределами NSDocument. Можно отметить, что, даже если приложение не является поигравшим в песочнице приложением, экземпляр pboxd (иначе «Блок питания») работает, в то время как сеанс Переименования Строки заголовка происходит. Переименование строки заголовка использует pboxd даже в непоигравших в песочнице приложениях.



Изменения для возобновления для приложений

Для улучшения, система запускают производительность, приложения, которые были скрыты во время выхода из системы, будут по умолчанию только частично запущены при возобновлении после перезагрузки. Такие частично повторно запущенные приложения используют намного меньше системных ресурсов. Когда пользователь активируется, приложение запустило этот путь, оно будет полностью восстановлено и обычно вести себя.

Если это поведение является нежелательным для Вашего приложения (например, почтовое приложение может проверять на почту и отображать количество непрочитанных сообщений в его значке панелей, даже если пользователь не взаимодействует с ним), можно использовать Автоматическое Завершение APIs для предоставления информации системе о том, что приложение делает, позволяя ему сделать более надлежащий выбор. Если автоматическое завершение осведомленное приложение отключает автоматическое завершение через - [NSProcessInfo disableAutomaticTermination:] API, OS предположит, что это посреди чего-то, что должно быть возобновлено и полностью повторно запустит его на перезапуске. Как только автоматическое завершение повторно включено через - [NSProcessInfo enableAutomaticTermination:], OS продолжит решать между полным, частичным, или никакой перезапуск для минимизации времени запуска, не нарушая ожидания пользователя.

Примите автоматическое завершение

Автоматическое Завершение является средством, представленным в OS X Lion. Это позволяет лежать в основе процессов, которые будут завершены системой автоматически, независимые от состояния выполнения самого приложения. Мы намереваемся полагаться на Автоматическое Завершение еще больше в будущем и призвать Вас принимать его в своих приложениях. Можно сделать это opt'ing в Автоматическое Завершение через запись Info.plist NSSupportsAutomaticTermination (или вызывающий - [NSProcessInfo setAutomaticTerminationSupportEnabled:YES] вначале), и затем вызывающий - [NSProcessInfo disableAutomaticTermination:] и - [NSProcessInfo enableAutomaticTermination:] по мере необходимости.



NSTextAlternatives

NSTextAlternatives является новым неизменным классом значения, хранящим список альтернатив для части текста и передающим выбор альтернативы через уведомление. Экземпляры NSTextAlternatives присоединены к приписанным строкам как к значению нового атрибута, NSTextAlternativesAttributeName.

В 10,8 вариант использования для NSTextAlternatives является предписанием, но этот класс строго не связывается к предписанию и может использоваться для других целей в будущих выпусках.

Класс имеет два атрибута: primaryString (представляющий текст, фактически выбиравшийся и использовавшийся во входной строке), и alternativeStrings (представляющий альтернативные возможные интерпретации, которые пользователь мог бы выбрать вместо этого). Они являются отдельными, потому что текстовая система должна иметь дело с ними отдельно, с помощью primaryString, чтобы удостовериться, что текст находится все еще в том же состоянии как тогда, когда это вводилось, и представление alternativeStrings через UI, подобный этому в настоящее время используемому для альтернатив исправления.

Когда пользователь выбирает одну из альтернативных строк, текстовое представление вызывает-noteSelectedAlternativeString: на объекте NSTextAlternatives. Подклассы NSTextAlternatives могут сделать то, что они любят в этом методе, но реализация базового класса отправляет уведомлению NSTextAlternativesSelectedAlternativeStringNotification с выбранной альтернативной строкой в пользовательской информации под ключом «NSAlternativeString». Таким образом, произвольные объекты могут прислушаться к пользовательским выборам альтернативных строк.


Дополнительный API для проверки правописания

Существует дополнительный метод для NSSpellChecker:
- (NSString *)languageForWordRange:(NSRange)range
inString:(NSString *)string
orthography:(NSOrthography *)orthography;
Клиенты, имеющие NSOrthography от проверки NSTextCheckingTypeOrthography и хотящие определить определенный язык от нее для определенного слова, например передать в-guessesForWordRange:inString:language:inSpellDocumentWithTag:-correctionForWordRange:inString:language:inSpellDocumentWithTag: или-completionsForPartialWordRange:inString:language:inSpellDocumentWithTag: должен использовать этот метод для получения его. Этот метод публично документируется в 10,8, но является доступной спиной к 10,7.



NSImage

В 10,8 мы добавили API к NSImage и NSCustomImageRep, разрешающему клиентам делегировать получение к блоку:
+[NSImage imageWithSize:flipped:drawingHandler:]
-[NSCustomImageRep initWithSize:flipped:drawingHandler:]
-[NSCustomImageRep drawingHandler]
Этот APIs упрощает создавать изображение (или репутация пользовательского изображения), который делегирует ее получение к блоку. Этот блок вызывается во время получения, позволяя рисующий быть настроенным как подходящий для целевой плотности пикселей контекста, цветового пространства и других свойств. Этот API может заменить многих (но не все) существующее использование lockFocus/unlockFocus. Существующая lockFocus реализация выполняет все получение против представления единого растрового изображения. Когда изображения перемещены между дисплеями различных плотностей пикселей (и до меньшей степени, различных цветовых пространств), это вызывает проблемы.

Как другие типы репутации нерастрового изображения, получение кэшируется как подходящее для целевого контекста. В сущности блок drawingHandler будет вызван в первый раз, когда изображение нарисовано к определенному типу места назначения (1x или 2x экран, например). Последующие операции рисования к тому же типу места назначения снова используют ранее сгенерированный битовый массив.

При рисовании NSImage всегда пытался использовать представление с, по крайней мере, столькими же пикселей сколько целевой прямоугольник. Много приложений пытаются реализовать баннеры и 3 части / 9 изображений части путем протяжения NSImage по намного большей области (обычно только на единственной оси). С добавлением 2x активы эти приложения находят, что эта политика выводит на экран 2x репутация изображения, когда они предпочли бы 1x репутация. Это поведение может быть изменено при помощи нового matchesOnlyOnBestFittingAxis свойства на NSImage. Все еще предпочтительно использовать NSDrawThreePartImage и NSDrawNinePartImage, если это возможно.

Начиная с SnowLeopard было возможно использовать NSImage в качестве содержания CALayer. С недавним быстрым увеличением 2x активы, этот метод все более и более используется для упрощения принятия HIDPI. Этот метод действительно, однако, обращенным к определенным ограничениям:

• contentsGravity уровня должен быть kCAGravityResize, kCAGravityResizeAspect, или kCAGravityResizeAspectFill. Поскольку все другое contentsGravities поведение не определено.
• При растеризации разрешения независимое представление или выборе из многократных представлений, только используется backingScaleFactor представления, размещающего уровень. Это означает, что любые масштабы, представленные путем изменения границ или, преобразовывают уровня, или его наследователи проигнорированы.

В 10,8, NSImage теперь предлагает два новых метода, чтобы более явно иметь дело с contentsScale уровня. Эти методы являются-recommendedLayerContentsScale: и layerContentsForContentsScale:. Эти методы могут использоваться для учета настоящего масштабов в дереве уровня (например, вследствие границ слоев, или уровень преобразовывает). Они также работают на весь contentsGravities.
static void updateLayerWithImageInWindow(NSImage *image, CALayer *layer, NSWindow *window)
{
    CGFloat baseScaleFactor = [window backingScaleFactor]; // This is the scale factor of the screen we are displayed on.
    NSSize imageSize = [image size];
    CGRect layerSize = [layer bounds].size;
    CGFloat additionalLayerScaleFactor = fmax(layerSize.width / imageSize.width, layerSize.height / imageSize.height);
    CGFloat desiredScaleFactor = baseScaleFactor * additionalLayerScaleFactor; // this scale factor is appropriate
    // for the actual pixel bounds of the layer.
    CGFloat actualScaleFactor = [image recommendedLayerContentsScale: desiredScaleFactor]; // Don't use a higher scale
    // factor if the image can't provide it. If the image is resolution independent
    // the return value will be the same as the input.
    id layerContents = [image layerContentsForContentsScale:actualScaleFactor]; // Now we have an appropriately
    // sized object to use as the contents of a layer.
    [layer setContents:layerContents];
    [layer setContentsScale:actualScaleFactor];
}

NSWindow

Когда backingScaleFactor окна и/или цветовое пространство изменяются, с 10.7.3, AppKit отправляет NSWindowDidChangeBackingPropertiesNotification. При работе версии системы, где это новое уведомление доступно, приложения должны использовать его вместо NSWindowDidChangeScreenProfileNotification для наблюдения за изменениями в любом из этих свойств запоминающего устройства. Существует также соответствующий метод делегата.
NSString *NSWindowDidChangeBackingPropertiesNotification;
@protocol NSWindowDelegate <NSObject>
@optional
...
- (void)windowDidChangeBackingProperties:(NSNotification *)notification;
...
@end
userInfo словарь содержит два ключа: NSBackingPropertyOldScaleFactorKey имеет значение NSNumber, указывающее предыдущий backingScaleFactor окна, и NSBackingPropertyOldColorSpaceKey сделал, чтобы NSColorSpace оценил, который указывает предыдущее цветовое пространство окна. Можно сравнить их с backingScaleFactor и цветовым пространством во время уведомления, для определения, какое из этих двух свойств изменилось. Обратите внимание на то, что для обоих возможно измениться.
NSString *NSBackingPropertyOldScaleFactorKey;
NSString *NSBackingPropertyOldColorSpaceKey;

NSView

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

Кроме того, мы внедрили дополнительный метод для делегатов CALayer:
- (BOOL)layer:(CALayer *)layer shouldInheritContentsScale:(CGFloat)newScale fromWindow:(NSWindow *)window;
Когда реализовано, когда представление будет добавлено к окну или изменениям разрешения окна, NSView вызовет этот метод на делегата уровня. NSView делает это путем перечисления дерева уровня, присоединенного к нему и проверки каждого уровня, делегирует поочередно. Обратите внимание на то, что, когда уровень добавляется к уже дереву видимого слоя, этот метод будет *не* быть вызванным. При возврате YES из этого метода NSView установит contentScale уровня для соответствия backingScaleFactor окна, в котором это размещается; и отметьте уровень грязное использование-setNeedsDisplay.


Управление NSImages с многократными представлениями

Использование в своих интересах многократной возможности представления NSIMAGE важно для поддержки высокого разрешения в Ваших приложениях. NSImage имеет средство, чтобы выбрать и загрузить надлежащее представление во время выполнения, в зависимости от контекста, в котором это рисуется. Это также перезагрузит дополнительные представления по мере необходимости, когда спросили вовлечь различные контексты.

Несмотря на то, что NSImages с многократными представлениями может быть создан во время выполнения путем вызова addRepresentation: часто намного проще загрузить такие изображения из файлов. Вызов такой как [NSImage imageNamed:@ «foo»] создаст NSImage, поддержанный всеми файлами образа, названными «foo» в Вашем комплекте приложений, например foo.png, foo.tiff, foo.pdf, и т.д. Кроме того, формат файла размолвки может содержать многократные представления в единственном файле, избавляя от необходимости иметь многократные файлы. Это средство существовало начиная с OS X 10.0.

Когда многократные представления предусматривают единственное изображение, очень важно, чтобы представления у всех был тот же внутренний размер (как возвращено - размер). Поскольку файлы растрового изображения с различным пикселем рассчитывают, это достигается путем установки плотности изображения должным образом. Так как плотность по умолчанию изображений составляет 72 точки на дюйм, устанавливая плотность 2x, файлы к 144 точкам на дюйм достигают этого ограничения. При создании иллюстраций это часто делается путем указания значения разрешения в панели калибровки изображения; программно это сделано путем установки размера NSBitmapImageRep явно к чему-то другому, чем {pixelsWide, pixelsHigh}.

Запускаясь в 10,7, NSImage добавленная поддержка соглашения о присвоении имен iOS для изображений высокого разрешения, что означает [NSImage imageNamed:@ «foo»], также возьмет foo@2x .png. В таких случаях пиксельные размерности 2x изображение должно быть 2x, и NSImage предположит, что плотность дважды больше чем это 1x файл.

Для иллюстраций, прибывающих из пакетов кроме комплекта приложений, 10,7 методов - [NSBundle imageForResource:] может использоваться, чтобы сделать ту же комбинацию отдельных файлов.

Несмотря на эту многофайловую поддержку в NSImage, мы действительно не ожидаем, что Вы будете использовать его очень. Если у Вас есть ресурсы foo.png и foo@2x .png в Ваших ресурсах проекта, XCode по умолчанию собирается прокрутить их вместе в мультипредставление foo.tiff, который содержит обоих во время сборки. Мы рекомендуем этот подход как способ сократить количество файлов в Ваших комплектах приложений поставки.

Инструмент командной строки tiffutil может использоваться для ручного объединения отдельных файлов растрового изображения в единственные файлы размолвки.

Управление приложением и значками документа

Xcode 4.4 предоставляет поддержку для объединения приложения и значков документа, использующих .icns формат файла образа. В Ваших ресурсах проекта Вы обеспечиваете «iconset» папки, содержащие отдельные файлы, которые будут объединены во время изготовления в .icns файлы. Формат для iconset папки описан в документе «Инструкции по высокому разрешению для OS X».

Инструмент командной строки iconutil может использоваться для ручного объединения отдельных растровых файлов в единственные icns файлы.

Обратите внимание на то, что поддержка icns файлов с представлениями высокого разрешения уходит корнями к OS X 10.6, но не 10.5.

NSOpenGL

Методы NSOpenGLContext-setFullScreen и-setOffScreen:width:height:rowbytes: больше ничего не делайте. Это вызвано тем, что функции, на которых они, базируются (CGLSetFullscreen, и CGLSetOffScreen) больше не работают. Проверьте документацию на CGLSetFullscreen и CGLSetOffScreen для заменяющей функциональности.



NSColor

Существует новый метод класса NSColor возвратить более легкий льняной цвет, который должен использоваться для фонов страниц и показал области представления:
+ (NSColor *)underPageBackgroundColor;
Существует два новых метода NSColor для преобразования назад и вперед от CGColorRefs:
+ (NSColor *)colorWithCGColor:(CGColorRef)cgColor;
- (CGColorRef)CGColor;
Эти методы не гарантируют точности туда и обратно.-colorWithCGColor: может возвратить ноль в некоторых случаях (например, он не реализован для пробелов индексированного цвета).-CGColor никогда не будет возвращать ноль, но результатом может быть приближение.

Преобразование цветов с - [NSColor colorUsingColorSpace:] использование произвольных пробелов было ускорено значительно для соответствия скорости преобразования с помощью встроенных пробелов стандартного цвета.



NSProgressIndicator

Когда - [NSApplication userInterfaceLayoutDirection] возвращает NSUserInterfaceLayoutDirectionRightToLeft, индикатор хода выполнения стиля панели теперь поддерживает анимацию прогресса в справа налево конфигурации.


NSRulerView

Значок для правых и левых маркеров вкладки правильно представляется в ориентации вертикального текста.


Новые жесты для NSTextView

NSTextView поддерживает жест Беглого взгляда путем реализации нового APIs NSResponder,-quickLookPreviewItems: и-quickLookWithEvent:. Кроме того, умные увеличивают жест, поддерживается через-rectForSmartMagnificationAtPoint:inRect:.


NSFont

Значением по умолчанию фиксированный шрифт подачи у Пумы является Menlo 11 ПБ. + [NSFont userFixedPitchFontOfSize:] с 0,0 размерами точки теперь возвращает Menlo 11 вместо Монако 10.

Запускаясь с этого выпуска, использование по умолчанию экранных шрифтов прекращено. Текстовый рендеринг и измерение APIs для элементов пользовательского интерфейса, таких как NSStringDrawing и методы NSCell больше подстановочный шрифт не приписывают с их экранными дубликатами шрифта автоматически. Настройка по умолчанию для - [NSLayoutManager usesScreenFonts] теперь НЕ для приложений, соединенных на этом и более поздних выпусках. Можно сохранить приложения, работающие с Поведением льва путем устанавливания нового ключа NSUserDefaults, NSFontDefaultScreenFontSubstitutionEnabled. NSFontDefaultScreenFontSubstitutionEnabled управляет полным экранным поведением замены шрифтов по умолчанию. Когда установлено в ДА, экранная замена шрифтов выполняется всем текстом APIs так же, как на предыдущих выпусках. Значение по умолчанию НЕТ.

Приложения могут сохранить экранный параметр шрифта в документы через NSUsesScreenFontsDocumentAttribute.




Отмечает определенный для Mac OS X 10.7

Некоторые главные темы, затронутые в этом разделе, включают:



Автоматический подсчет ссылок

Automatic Reference Counting (ARC) является новой функцией, позволяющей компилятору генерировать требования, сохраняют, выпускают, и автовыпуск. Это доступно с Xcode 4.2, для Mac OS X и iOS, назад к Mac OS X 10.6 и iOS 4. Однако в этих более ранних системах функция слабой ссылки обнуления ARC не доступна.

На 10,7, некоторые классы Какао включая NSWindow, NSTextView, NSFont и NSImage не поддерживают слабые ссылки обнуления. Много других классов делают.

В отличие от сборки «мусора», ARC не обеспечивает обнаружения цикла или повреждающихся функций. Так же традиционно слабые ссылки, такие как делегаты, выходы или цели должны остаться слабыми по умолчанию под ARC. В большинстве случаев это может означать слабый обнулением, несмотря на то, что в случаях, где рассматриваемый объект является одним из тех, не поддерживающим слабую ссылку обнуления (или Вы хотите развернуться на 10,6), Вам, вероятно, придется использовать слабое необнуление, который обозначен с переменным спецификатором __ unsafe_unretained, или атрибут свойства присваиваются.

Обратите внимание на то, что значения по умолчанию Xcode 4.2 к ARC при создании новых проектов, и в выпуске семени WWDC генерируют объявления выхода, которые сильны (в новых проектах, а также при добавлении новых объявлений выхода от Интерфейсного Разработчика). В большинстве случаев они должны быть изменены на слабый (обнуление или не) для предотвращения циклов, которые могут вызвать утечки.


iCloud

10.7 включает APIs, чтобы позволить приложениям сохранить конфигурационную информацию и документы в iCloud. Основной APIs здесь находится во многих Фундаментальных классах; см. информация о версии Основы.


Два стиля скроллера льва

Лев представляет новые, вдохновленные iOS «Скроллеры наложения», а также модернизировал «Устаревшие» скроллеры, предусматривающие совместимость приложения, доступность и размещение пользовательских настроек. Приложения должны быть подготовлены работать или со стилем скроллера, и для предпочтительного стиля скроллера системы для изменения в течение долгого времени, поскольку пользователь соединяет/разъединяет манипуляторы или вносит изменения в Появление, Сенсорную панель или предпочтения прокрутки Мыши.

Скроллеры «Наложения» составляются на полях contentView NSScrollView, вместо того, чтобы вычесть зарезервированное пространство из потенциальной предметной области NSScrollView. Прокрутите ползунки, появляются автоматически во время прокрутки жеста (а также программно вызванная прокрутка) и исчезают после прокрутки остановок, давая пользователям ненарушенный, фокусируемый на содержании UI. Это автоматическое показывает/скрывает поведение, и координация горизонтальной и вертикальной пары скроллера требует управляющего NSScrollView, обеспечивающего необходимую логику и отношение к предметной области с возможностью прокрутки. Экземпляр NSScroller это используется самостоятельно, не будучи управляемым родительским NSScrollView, может быть сконфигурирован для использования появления скроллера Наложения, но не будет иметь связанного анимированным, показывают/скрывают поведение.

Избегать вмешиваться во взаимодействие пользовательского содержания, просто mousing в края предметной области не заставляет скроллеры Наложения изменяться от скрытого до показанного, так как возможно, что пользователь может предназначить действия мыши в тех полях для базового содержания. Прокрутка жеста, или любой эквивалент клавиатуры или определенное с помощью приложения действие, приводящее к прокрутке, необходима, чтобы заставить скроллеры быть показанными.

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

Скроллеры наложения предлагают знакомые управляемые мышью возможности: mousing в скроллер Наложения пользователи могут перетащить кнопку скроллера (включая [Опцию] +drag для достижения штрафа, прокручивающего), и могут щелкнуть в дорожке скроллера к странице или переходу (согласно «Щелчку пользователя в полосе прокрутки к»: предпочтительная установка появления).

Код приложения может программно запросить показ скроллеров Наложения с помощью нового-flashScrollers метода NSScrollView. Это может быть желательно при изменении размера представления документа или свопинге нового содержания в представление, или дать пользователю смысл текущей позиции в диапазоне с возможностью прокрутки на каждом шаге инкрементной поисковой или подобной работы. (Без явного сообщения-flashScrollers в каждом находят шаг, скроллеры пульсировались бы к видимому только, когда усовершенствование к следующему результату находки, оказывается, вызывает программируемую прокрутку.)-flashScrollers может быть отправлен любое число раз; AppKit объединяет запросы в гладкий скроллер, показывают/скрывают поведение. Вертикальные и горизонтальные скроллеры Наложения NSScrollView всегда показывают и скрываются вместе.-flashScrollers в порядке для отправки в NSScrollView, это использует Устаревший стиль скроллера, и просто не имеет никакого эффекта в этом случае.

Скроллеры наложения разработаны для использования со способными устройствами прокрутки жеста. Для обеспечения совместимости для различных обстоятельств, включая пользователей с потребностями Доступности и системы с манипуляторами «не прокрутка жеста», AppKit также обеспечивает «Устаревший» стиль скроллера. Устаревшие скроллеры были модернизированы для обеспечения появления, подобного, чтобы Наложить скроллеры, и больше не иметь кнопки со стрелкой прокрутки, но иначе функционально идентичны 10.6 скроллерам Воды: Они имеют те же метрики, имеют пространство расположения, зарезервированное для них вместо того, чтобы быть наложенными на contentView, и всегда видимы (кроме тех случаев, когда функция «autohidesScrollers» NSScrollView используется). NSScroller имеет новое «scrollerStyle» свойство, с которым можно консультироваться для определения стиля в использовании определенным экземпляром NSScroller. Соответствующий метод установщика экспериментально предоставлен, но не должен в целом использоваться кроме реализацией NSScrollView.

Предпочтительная панель «Появления» содержит новое, «Показывают полосы прокрутки»: предпочтение, позволяющее пользователям выбрать между Наложением и Устаревшими скроллерами. По умолчанию установка «Автоматически, на основе устройства ввода данных», оставляющего решение до AppKit на основе подключенных аппаратных средств манипулятора, но пользователи могут также выбрать «When scrolling», чтобы предпочесть скроллеры Наложения, или «Всегда» запрашивать Устаревшие скроллеры.

Когда установка «Автоматически …», и больше чем один манипулятор подключается, решение основывается на самом способном манипуляторе, найденном, игнорировав встроенную сенсорную панель, если присутствуют другие манипуляторы. Идея состоит в том, что пользователь, подключающий манипулятор, вероятно, означает использовать его, но мы также не хотим вызывать нейтрализацию к наименьшему количеству общего знаменателя, когда также присутствует сенсорная прокрутка способное внешнее устройство. Устройство сенсорной прокрутки, которому отключили его возможность сенсорной прокрутки в предпочтениях Мыши/Сенсорной панели пользователя, обрабатывается то же как неспособное устройство, но, снова, конфигурация внутренней сенсорной панели игнорируется, когда присутствуют один или несколько внешних манипуляторов. Так, например, если у пользователя есть MacBook Pro с Волшебной подключенной Мышью, возможность сенсорной прокрутки сенсорной панели может быть отключена, не вызывая нейтрализацию к Устаревшим скроллерам, пока Волшебной Мыши включили ее возможность сенсорной прокрутки.

AppKit обновляет скроллеры во время выполнения, чтобы отразить, что изменения в пользователе «Показывают полосы прокрутки»: предпочтение появления, и как манипуляторы (включая беспроводные устройства) соединяется и разъединяется.

Существует два случая, где определенный набор скроллеров вызывается к Устаревшему стилю, даже если предпочтение пользователя установлено «Показать полосы прокрутки: При прокрутке».

Если AppKit обнаруживает присутствие «представления аксессуара» в областях дорожки NSScrollView, скроллеры NSScrollView могут быть вызваны к Устаревшему стилю скроллера. Изменение масштаба, раскрывающееся, который появляется в обертке к постраничному режиму TextEdit, является примером такого вспомогательного представление. Этот метод пошагового перемещения скроллеров в стороне для создания места для дополнительных маленьких информационных представлений или средств управления был полезен, когда скроллеры имели пространство, зарезервированное для них отдельный от предметной области, но не совместимы со скроллерами, находящимися на предметной области и исчезающими если не в использовании. Приложения, хотящие использовать скроллеры Наложения, должны искать альтернативы вспомогательному представления для представления желаемой функциональности. Как только представления аксессуара удалены или перемещены из полей скроллера, ScrollView будет снова иметь право использовать скроллеры Наложения.

Экземпляры подкласса NSScroller для совместимости, принял значение по умолчанию к Устаревшему стилю скроллера и поведению. Подклассы NSScroller могут объявить, что себя скроллер Наложения совместимое использование нового +isCompatibleWithOverlayScrollers API, позволяя настройку относительно появления скроллера Наложения и поведения. См., что комментарии сопровождают этот метод в NSScroller.h для использования и полного набора требований совместимости.



Дополнения NSAnimationContext API

NSAnimationContext теперь имеет «timingFunction» свойство, это походит на CATransaction API's «animationTimingFunction». Анимации инициировали через синтаксис прокси «аниматора», которые не имеют явно указанного timingFunction, наследует timingFunction NSAnimationContext включения, если это не будет ноль (который является значением по умолчанию NSAnimationContext).

Как с существующим свойством «продолжительности», изменяя timingFunction NSAnimationContext вызывает то же изменение в animationTimingFunction базового CATRANSACTION. Также как со свойством «продолжительности», можно изменить timingFunction любое число раз в данном блоке NSAnimationContext-beginGrouping/-endGrouping. Изменения в timingFunction применятся к любым анимациям, впоследствии инициирующимся в том, что группировка NSAnimationContext (пока timingFunction возможно не изменяется снова).

NSAnimationContext также дали новый блок «completionHandler». После того, как набор к ненулевому значению, completionHandler контекста, как гарантируют, вызовут (на основном потоке), как только все анимации, впоследствии добавленные к текущей группировке NSAnimationContext, завершились (или были отменены). Этот API управляет базовым свойством CATransaction «completionBlock» (хотя AppKit может присвоить различный, посреднический completionBlock текущему CATransaction). Увольнение completionHandler NSAnimationContext ожидает всех анимаций, к которым обработчик применяется, независимый от того, оценены ли они AppKit или делегированы к Базовой Анимации для оценки в дереве рендеринга. Если никакие анимации не добавляются, прежде чем текущая группировка NSAnimationContext заканчивается (или completionHandler установлен в различное значение), обработчик будет сразу вызван.

Наконец, NSAnimationContext имеет сопроводительный новый +runAnimationGroup:completionHandler: метод класса. Его использование предусматривает более естественный синтаксис, позволяя Вам указать тело блока завершения после набора действий анимации, завершение которых инициирует блок завершения.

Следующее:
[NSAnimationContext runAnimationGroup:^(NSAnimationContext *context){
    // Start some animations.
[[myView animator] setFrameSize:newViewSize];
[[myWindow animator] setFrame:newWindowFrame display:YES];
} completionHandler:^{
    // This block will be invoked when all of the animations started above have completed or been cancelled.
NSLog(@"All done!");
}];
семантически эквивалентно:
[NSAnimationContext beginGrouping];
    [NSAnimationContext setCompletionHandler:^{
// This block will be invoked when all of the animations started below have completed or been cancelled.
NSLog(@"All done!");
    }];
    // Start some animations.
[[myView animator] setFrameSize:newViewSize];
[[myWindow animator] setFrame:newWindowFrame display:YES];
[NSAnimationContext endGrouping];
“NSAnimationContext *контекст” параметр передает текущий NSAnimationContext потока блоку как удобство, так, чтобы код в блоке, хотящем изменить или запросить свойства текущего контекста, не запрашивал (возможно неоднократно) для [NSAnimationContext currentContext].


Свойство NSWindow «animationBehavior»

В 10,7, мы добавили автоматическую анимацию NSWindow-orderFront:/-orderOut: операции, которыми можно управлять с помощью нового свойства «animationBehavior» NSWindow. По умолчанию animationBehavior NSWINDOW установлен в NSWindowAnimationBehaviorDefault, заставляющий AppKit определять стиль анимации для использования автоматически на основе ее вывода «типа» окна от различных свойств окна. animationBehavior окна может быть установлен в NSWindowAnimationBehaviorNone отключить автоматические анимации Аппкита для окна. (Это может быть полезно, если анимация AppKit вмешивается в анимацию, которую реализует Ваше приложение.) Или, это может быть установлено в одно из других значений NSWindowAnimationBehavior не по умолчанию переопределить автоматический вывод AppKit надлежащего поведения анимации на основе очевидного типа окна.


Пользовательское разархивирование представления и «wantsLayer»

До 10,7, Пользовательское Представление, разархивированное от .nib или .xib файла, всегда получало бы-setWantsLayer: сообщение во время загрузки, независимо от того, был ли разархивированной установкой wantsLayer YES или НЕТ. Получение этого сообщения с параметром НЕ могло вмешаться напрасно в wantsLayer == настройка YES, которую представление могло бы попытаться установить в его-initWithFrame: метод. На 10,7, AppKit только отправит-setWantsLayer: к Пользовательскому Представлению во время разархивирования, если параметр ДА, устраняя эту ловушку.



Более простое управление фокусирующим кольцом

«Фокусирующее кольцо» является Окрашенным водой ореолом, указывающим, что управление является активным первым респондентом, который получит ключевые события. Новый API NSView в 10,7 делает намного проще указать форму фокусирующего кольца, которая будет показана для пользовательского представления при обеспечении AppKit с информацией, которую это должно автоматически гарантировать непротиворечивому стиранию фокусирующего кольца и перерисовке. Эта новая автоматическая модель фокусирующего кольца также приводит к корректным результатам в поддержанном уровнем режиме, ранее ограниченном неспособностью получения фокусирующего кольца расшириться, сокращающем потребность в перерисовке содержания представления во многих случаях, и даже обеспечивающем полезную подсказку для Доступности относительно того, где, вероятно, будет сосредоточено внимание пользователя.
- (void)drawFocusRingMask NS_AVAILABLE_MAC(10_7);
- (NSRect)focusRingMaskBounds NS_AVAILABLE_MAC(10_7);
- (void)noteFocusRingMaskChanged NS_AVAILABLE_MAC(10_7);
Пользовательское представление, хотящее, чтобы фокусирующее кольцо было показано, когда это - активный первый респондент, и это не наследовало то поведение от суперкласса, потребности только указать форму маски фокусирующего кольца. AppKit автоматически определит, когда фокусирующее кольцо должно будет быть показано и стерто (поскольку представление становится и прекращает быть, активный первый респондент - т.е. firstResponder в keyWindow приложения), и вызовет-focusRingMaskBounds и-drawFocusRingMask методы по мере необходимости.

Реализация NSVIEW-drawFocusRingMask ничего не рисует, и ее-focusRingMaskBounds метод возвращает пустой прямоугольник. Для выбора в новые 10,7 моделей рисования фокусирующего кольца представление просто переопределяет-drawFocusRingMask метод для рисования формы, схема которой должна служить шаблоном для фокусирующего кольца и-focusRingMaskBounds для возврата ограничительной рамки той формы (выраженный во внутренней части представления («границы») координатное пространство). Например, простое прямоугольное фокусирующее кольцо, окружающее кадр представления, требовали бы путем простого выполнения:
- (void)drawFocusRingMask {
NSRectFill([self bounds]);
}
- (NSRect)focusRingMaskBounds {
return [self bounds];
}
AppKit автоматически вызовет эти методы в надлежащих случаях, для рендеринга фокусирующего кольца представления. (Удостоверьтесь, что представление приемлемо становиться firstResponder своего окна путем переопределения-acceptsFirstResponder для возврата YES.) Фокусирующее кольцо представляется с помощью стиля, указанного focusRingType представления (который не должен быть NSFocusRingTypeNone, если Вы не хотите подавить получение фокусирующего кольца). Реализация-drawFocusRingMask может предположить, что это рисует во внутренней части представления (границы) координатное пространство, и что цвета заливки и цвета обводки были установлены в произвольный полностью непрозрачный цвет. Это должно только нарисовать желаемую форму фокусирующего кольца (или изображение или другой объект, схема которого определяет маску фокусирующего кольца).

Эта модель обеспечивает альтернативу предыдущему методу фокусирующего кольца, в чем представление было ответственно за определение, когда нарисовать и стереть его собственное фокусирующее кольцо, потребовался, чтобы выполнять его фокусирующее кольцо, рисующее явно как часть его-drawRect: реализация, и должна была использовать специальный-setKeyboardFocusRingNeedsDisplayInRect: метод для обеспечения корректного стирания фокусирующего кольца и перерисовки. Представление, принимающее эти новые 10,7 фокусирующих колец API, больше не должно вызывать NSSetFocusRingStyle () и выполнять его собственное получение фокусирующего кольца в-drawRect: если, работая 10.6 или ранее, так как использование NSSetFocusRingStyle () не заставило бы AppKit отступать к старой модели рисования фокусирующего кольца для представления. Вызов-setKeyboardFocusRingNeedsDisplayInRect: в порядке, но вызовет больше перерисовки, чем необходимый на 10,7, где AppKit в состоянии определить точное покрытие фокусирующего кольца, представляющего на основе маски фокусирующего кольца, и таким образом в состоянии показать, скрыть, и переместить фокусирующее кольцо с минимальной перерисовкой затронутых областей окна. В поддержанном уровнем режиме AppKit рисует фокусирующее кольцо, это реализовало использование этих новых 10,7 API на его собственный уровень, разрешающий фокусирующему кольцу расширяться вне границ слоев поддержки связанного представления и позволяющий фокусирующему кольцу быть эффективно показанным, перемещенным и скрытым, не требуя перерисовки связанного содержания представления.

Третий новый метод,-noteFocusRingMaskChanged, предоставлен для Вас для вызова, когда некоторое состояние, о котором не знает AppKit (такой как, какой из ряда компонентов непредставления содержания Вы считаете «фокусируемыми»), который влияет на форму фокусирующего кольца или где Вы хотели бы, чтобы он был нарисован, изменения. Когда Ваше представление получает-setNeedsDisplayInRect, AppKit автоматически вызывает-noteFocusRingMaskChanged: сообщение (как это происходит, когда представление изменено или перемещено), и когда focusRingType представления изменяется, который покрывает большинство случаев. Только необходимо вызвать-noteFocusRingMaskChanged в случаях, где некоторое собственное изменение внутреннего состояния, о котором не может знать AppKit, влияет на желаемую форму или позицию Вашей маски фокусирующего кольца.

В пользу основанного на ячейке NSControls существует параллельный набор переопределяемого API NSCell:
- (void)drawFocusRingMaskWithFrame:(NSRect)cellFrame inView:(NSView *)controlView NS_AVAILABLE_MAC(10_7);
- (NSRect)focusRingMaskBoundsForFrame:(NSRect)cellFrame inView:(NSView *)controlView NS_AVAILABLE_MAC(10_7);
Нет никакого эквивалента NSCell-noteFocusRingMaskChanged. Когда ячейка решает, что ее маске фокусирующего кольца нужно обновление в ситуации, где содержание ячейки иначе не перерисовывается, это может вызвать [[сам controlView] noteFocusRingMaskChanged].

Новая модель мозаичного размещения для поддержанных уровнем представлений

Обработка больших представлений ставит фундаментальную проблему перед поддержанной уровнем моделью рендеринга, поскольку она подразумевает потребность выделить соразмерно большие запоминающие устройства уровня, которые используют память и могут превысить максимальный допустимый размер текстуры аппаратного обеспечения машинной графики хост-системы. Некоторая форма мозаичного размещения необходима, чтобы позволить необходимым, видимым частям представления быть буферизованными, в то время как потенциально большие области, которые не в настоящее время видимы (например, части представления документа, прокручивающиеся из представления) свободны быть освобожденными буфер, пока они не сделаны видимыми.
В 10,5 и 10.6, модель мозаичного размещения AppKit основывалась на CATiledLayer Базовой Анимации и предположила, что documentView NSScrollView, и только documentView NSScrollView, должны получить мозаичный уровень поддержки. Этот подход разрешил общий падеж большого поддержанного уровнем documentViews, но не адресовал потенциал для других представлений для превышения максимального размера текстуры и шел с асинхронным поведением получения (постепенное появление мозаик, поскольку они были привлечены), который в некоторых случаях не приводил к правильному пользовательскому опыту.
На 10,7, AppKit использует полностью новую, синхронную реализацию мозаичного размещения, устраняющую визуальные артефакты «мозаика, постепенно появляются» связанные с предыдущей моделью, и что автоматически мозаики и уровни поддержки представления немозаик по мере необходимости на основе размера представления, вместо того, чтобы быть связанным к предположению, что documentView только NSScrollView, вероятно, будет большим. Размещающееся рядом поддержанное уровнем представление вызовут для рисования через обычный-drawRect: механизм для рисования частей его содержания, которое будет кэшироваться в мозаики. AppKit автоматически управляет созданием и населением уровней мозаики, находящихся под «уровнем контейнера мозаики», порождают тот AppKit, добавляет как подуровень нормального уровня поддержки представления.
Новая модель мозаичного размещения является автоматической и не требует использования никакого нового API, но реагирует на ряд пользовательских значений по умолчанию, которые могут использоваться для экспериментальной настройки его параметров на основе для каждого процесса. Эти пользовательские значения по умолчанию нужно считать частными и подлежащими изменению в будущих выпусках, но возможность скорректировать их могла бы быть полезной, если стандартные значения оказываются неподходящими для определенного приложения.
NSViewBackingLayerTileSize определяет размер мозаики и значения по умолчанию к 512 (пиксели на стороне). Значения Power-two рекомендуются. (512 * 512 * 4bytes/pixel) = 1 МБ за мозаику. Большие значения производят меньше мозаик и сокращают управление мозаикой наверху, но будут иметь тенденцию тратить впустую больше пространства для представлений, кадры которых не отображаются на целое число мозаик.

NSViewMaxNonTiledBackingLayerSize указывает максимальный размер (в пикселях), которым уровень поддержки представления может быть с обеих сторон, прежде чем представление вынуждено быть размещенным рядом. Значение по умолчанию составляет 2 000 пикселей.

NSViewMaxResidentTiles определяет максимальное количество запоминающих устройств мозаики, которые могут быть выделены для процесса. Когда AppKit достигает этого предела, он начинает отбрасывать содержание невидимых мозаик для создания места для новых видимых мозаик. Значение по умолчанию равняется 64.

NSAppKitBackingLayerTiling управляет новой моделью мозаичного размещения и значениями по умолчанию к YES. Это может быть установлено в НЕ вернуться к 10,6 поведениям мозаичного размещения (использование уровней поддержки CATiledLayer для NSScrollViews' documentViews).

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


NSOpenGL и независимость разрешения

Как часть 10.7's обновленная архитектура Независимости разрешения, отдельные представления имеют новые средние значения для объявления их совместимости с кадровыми буферами с высокой разрешающей способностью. Так как OpenGL является врожденно ориентированный на пиксель API, и много существующего кода OpenGL не функционирует правильно, когда «удивлено» запоминающим устройством с высокой разрешающей способностью, представления OpenGL выполняются в масштабированном режиме по умолчанию и должны в частности выбрать в поддержку с высокой разрешающей способностью.

Средства доступа для этого нового свойства, как объявляют, в категории на NSView в NSOpenGLView.h, подчеркивают, что их уместность ограничена рендерингом OpenGL, но свойство применимо к любому представлению что рендеринг с помощью связанного NSOpenGLContext.
@interface NSView (NSOpenGLSurfaceResolution)
- (BOOL)wantsBestResolutionOpenGLSurface NS_AVAILABLE_MAC(10_7);
- (void)setWantsBestResolutionOpenGLSurface:(BOOL)flag NS_AVAILABLE_MAC(10_7);
@end
«WantsBestResolutionOpenGLSurface» свойство указывает, хочет ли приведенный пример представления и способен к корректной обработке, OpenGL, поддерживающий поверхность (кадровый буфер) разрешением, больше, чем 1 пиксель за точку. Это свойство важно только для представлений, с которыми NSOpenGLContext связывается (включая, но не ограничиваясь этим, NSOpenGLViews); его значение не влияет на поведение других представлений, включая CALayer-поддержанные представления (который может принять решение представить в более высоком поверхностном разрешении, независимом от значения этого свойства. Для совместимости, wantsBestResolutionOpenGLSurface значения по умолчанию к нет, обеспечивая кадровый буфер 1 пикселя за точку независимо от отступающего масштабного коэффициента для дисплея представление занимает. (Когда отступающий масштабный коэффициент> 1.0, представленное поверхностное содержание увеличено до надлежащего очевидного размера.) Установка этого свойства к YES для высказанного мнения дает разрешение AppKit выделить кадровый буфер более высокого разрешения в надлежащих случаях для отступающего масштабного коэффициента и целевого дисплея. AppKit может варьироваться поверхностное разрешение, когда режим отображения изменяется, или представление перемещено в различный дисплей, но с этим набором свойств к YES это способно к выделению поверхности больших, чем 1 пиксель за точку для представления.

Для функционирования правильно с набором wantsBestResolutionOpenGLSurface к ДА, представление должно заботиться для выполнения корректных преобразований между модулями представления и пиксельными модулями при необходимости. Например: установившаяся практика передачи ширины и высоты [сам границы] к glViewport () приведут к неправильным результатам (частичный вместо полного обзора поверхности рендеринга) при поддержке масштабных коэффициентов кроме 1,0, так как параметры к glViewport () должны быть выражены в пикселях. Вместо этого используйте размерности [сам convertRectToBacking: [сам границы]], которые находятся в надлежащем (пиксель) модули.

«WantsBestResolutionOpenGLSurface» свойство архивируется (включенная требуемая архивация).

Для тестирования только, эффект этого свойства может быть переопределен глобально для всех представлений в процессе, с помощью пользовательского значения по умолчанию «NSSurfaceResolution». Если NSSurfaceResolution будет установлен в «Устройство», то все представления, имеющие поверхности (включая не только поверхности OpenGL, но и поверхности рендеринга дерева уровня также) будут выбраны в использование лучшей поверхности разрешения для главного дисплея, на котором представлено представление. Это может использоваться, чтобы быстро оценить, готово ли представление приложений к поверхностям non-1x. Если NSSurfaceResolution будет установлен в «1x», то все представления, имеющие поверхности, будут выбраны в использование 1x (1 пиксель за точку) поверхности, независимые от дисплея или поддержки масштабного коэффициента. Если NSSurfaceResolution будет установлен в какое-либо другое значение, или никакое значение не присутствует для него, то с wantsBestResolutionOpenGLSurface будут консультироваться, как описано выше для представлений, выполняющих рендеринг NSOpenGL, и AppKit отдельно определит надлежащее разрешение для других поверхностей, как также описано выше.



NSView теперь передает необработанный-rightMouseDown: события цепочка респондента

До 10,7, NSView не передавал необработанный-rightMouseDown: события цепочка респондента. На 10,7, NSView передает-rightMouseDown: цепочка респондента, если AppKit не находит, что связанное контекстное меню выводит на экран для представления. Для предотвращения проблем совместимости на уровне двоичных кодов это новое поведение включено только для приложений, соединенных на 10,7 или позже.




Осуждение пиксельных буферов (PBuffers)

Пиксельные Буферы (PBuffers) были осуждены в 10,7. Современные клиенты должны использовать Объекты Кадрового буфера (FBOs) вместо NSOpenGLPixelBuffer и связанных методов. См. GL_EXT_framebuffer_object.



Осуждение NSOpenGLContext-setOffScreen:width:height:rowbytes:

-setOffScreen:width:height:rowbytes NSOpenGLContext: API нужно считать осуждаемым с 10,7. Как отмечено в NSOpenGL.h, этот API вызывает использование программного обеспечения rasterizer, который намного медленнее, чем рендеринг GPU. Обычно намного лучше в наше время использовать нормальный формат пикселя или с внеэкранным окном или с FBO (Объект Кадрового буфера), и затем вызвать glReadPixels () для чтения представленного результата назад в память ЦП (если это - то, где это необходимо).



Изменения для независимости разрешения

Существенные изменения были внесены в базовую графическую модель для независимости разрешения, и поведение приложений Какао, работающих под работой высокого разрешения, было обновлено. Масштабирование содержания пользовательского интерфейса теперь ограничивается интегралом 2x масштабный коэффициент и выключается на настройки дисплея, а не фактор глобального масштаба. Точное пикселем растровое изображение высокого разрешения теперь только должно быть предоставлено в 2x размер, многократный, подобный работе iOS на дисплее Сетчатки.

Пиксельная геометрия базового устройства и запоминающих устройств окна и экранных кадровых буферов была виртуализирована и абстрагирована позади новых основанных на точке координатных пространств для NSWindow и NSScreen. Отношение между пикселями и точками теперь управляется атрибутами режима отображения, в котором работает любой данный дисплей. Когда дисплей сконфигурирован для выполнения в одном из новых режимов «HiDPI», соответствующий объект NSScreen и любые окна, создаваемые на том дисплее, автоматически масштабируются с 2:1 пиксель на отношение поддержки точки.

Импликация этого изменения - то, что под работой высокого разрешения, прямоугольники, размеры и позиции все неизменны от с низким разрешением работы и, как теперь универсально предполагается, находятся в точках. Ранее, координаты события и и система координат основы окна и экранная глобальная система координат, как предполагали, были в пикселях устройства и были в «немасштабированном» пространстве, сравненном с координатами представления. Это больше не имеет место: координаты рамки окна, координаты события и координаты представления, преобразованные в пространство окна, все выражены в точках и не изменяются между работой с низким разрешением и высокого разрешения. Соответствующее масштабирование и отображение на дисплей выполняются автоматически Кварцевым Менеджером окон и NSGraphicsContext, присоединенным к любому данному окну.

Преобразование координатного пространства

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

Все методы ниже определяются на NSView, NSWindow и NSScreen.
/* New methods for converting to and from backing store pixels */
- (NSPoint)convertPointToBacking:(NSPoint)aPoint
- (NSPoint)convertPointFromBacking:(NSPoint)aPoint
- (NSSize)convertSizeToBacking:(NSSize)aSize
- (NSSize)convertSizeFromBacking:(NSSize)aSize
- (NSRect)convertRectToBacking:(NSRect)aRect
- (NSRect)convertRectFromBacking:(NSRect)aRect
Для обеспечения концептуально непротиворечивого отображения между координатами окна и координатами экрана перед лицом экранной виртуализации устройства, два новых метода были внедрены на NSWindow. Под работой высокого разрешения эти методы теперь просто смещают данный прямоугольник на основе позиции окна в экранном пространстве. Никакое преобразование масштабирования не необходимо, так как обе системы координат являются виртуальными и выравниваются в пространстве точки.
- (NSRect)convertRectToScreen:(NSRect)aRect
- (NSRect)convertRectFromScreen:(NSRect)aRect

устаревшие (deprecated) координатные методы преобразования

В результате виртуализации координат окна и координат экрана, понятие 'основной' системы координат было осуждено, вместе с методами, относящимися к тому координатному пространству. Следующие методы были теперь заменены convertToBacking методами, детализированными выше.
/* NSView deprecated methods */
- (NSPoint)convertPointToBase:(NSPoint)aPoint
- (NSPoint)convertPointFromBase:(NSPoint)aPoint
- (NSSize)convertSizeToBase:(NSSize)aSize
- (NSSize)convertSizeFromBase:(NSSize)aSize
- (NSRect)convertRectToBase:(NSRect)aRect
- (NSRect)convertRectFromBase:(NSRect)aRect
/* NSWindow deprecated methods */
- (NSPoint)convertBaseToScreen:(NSPoint)aPoint
- (NSPoint)convertScreenToBase:(NSPoint)aPoint

Примечания совместимости для работы высокого разрешения

Важно отметить, что для максимизации назад совместимости, осуждаемый NSView и методы NSWindow сохранят их исторические совместимые и задокументированные способы поведения.

При выполнении в @2x поведение этих методов все еще останется соответствующим их ранее задокументированной семантике, но будет неизбежный перерыв в совместимости для кода, подающего основанные на пикселе позиции (например, следующий - [NSView convertPointToBase:]) в - [NSWindow convertScreenFromBase:].

Прикладное программное обеспечение вызывая-convertBaseTo/FromScreen: неправильно должен будет принять новые подпрограммы и/или гарантировать, чтобы они воздержались от использования convertTo/FromBase подпрограмм NSVIEW, когда входные позиции обеспечения, и вместо этого используют - [NSView convertPoint:To/FromView:nil] вместо этого. (Примечание: Это - способ, которым все сделали вещи так или иначе до 10,5 когда - [NSView convertTo/FromBase:] был представлен),

Поддержка выровненного получения под работой высокого разрешения

Одна из наиболее распространенных причин того, чтобы сделать код для прорисовки, знающий о его базовой пиксельной геометрии поддержки, состоит в том, чтобы выполнить округление, чтобы гарантировать, что пиксель выровнял получение или расположение. Несмотря на то, что-centerScanRect NSVIEW: был обновлен для работы правильно под работой высокого разрешения, некоторое требование сценариев более трудного управления округляющимся поведением работы выравнивания на каждом краю прямоугольника. Мы представили новый удобный метод удовлетворить эту потребность, созданную поверх услуг, предоставленных NSIntegralRectWithOptions Основы () API.

Этот метод доступен на NSView, NSWindow и NSScreen.
- (NSRect)backingAlignedRect:(NSRect)aRect options:(NSAlignmentOptions)options
Этот метод принимает прямоугольники в локальных (виртуальных) координатах, и гарантируйте, что результат выровненный на границах пикселей запоминающего устройства согласно определенным подсказкам округления, данным в параметре опций. Основа уже предоставляет NSIntegralRect (), который берет прямоугольник и продвигает каждый край, исходящий к самой близкой целочисленной границе. Новый метод является немного более гибкой версией, дающей Вам контроль над тем, как rect массажируется в явление неотъемлемой частью, после того, как входной прямоугольник преобразовывается в надлежащее пространство поддержки.

Определение масштабного коэффициента

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

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

Новый открытый метод будет внедрен, который возвращает эффективное отношение масштаба между виртуальными и физическими координатами для поданного экрана, это - текущий режим. Этот фактор может считаться дополнительным кратным числом пикселей устройства, которые система определила потребность, которая будет использоваться при представлении пользовательского содержания на данном дисплее.
/* NSScreen and NSWindow methods */
- (CGFloat)backingScaleFactor
Этот метод, как ожидают, возвратится 2.0 для масштабируемых режимов отображения высокого разрешения, и 1.0 для всех других случаев.

Идентичный API необходим на NSWindow для создания отчетов об отношении масштабного коэффициента его пикселей запоминающего устройства к виртуальным координатам окна, так как то отношение независимо от своего содержания экрана. Этот метод критически полезен для контекстов, где окно существует, но графический контекст еще может не быть установкой или может быть неоднозначным. Как пример, рассмотрите от экранного окна. AppKit гарантирует, что этот метод даст 'разумный' ответ в зависимости от доступной среды дисплея.

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

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


Граничное изменение размеров окна

В 10,7, окна могут быть изменены от всех краев и углов, и изменять размеры индикатор был удален. Это влияет на все приложения Какао, и никакой новый API не связан с этим поведением. Существующие живые изменяют размеры функций поддержки, продолжают функционировать для всех, изменяют размеры направлений, и методы наиболее успешной практики для живого максимума изменяют размеры производительности, неизменны. setShowsResizeIndicator: метод проигнорирован, и метод NSWindow showsResizeIndicator всегда возвращается НЕТ.

Когда щелчок приведет к изменять размеры работе, и к который направление, курсор также изменяется для указания. Доступные изменяют размеры направлений, определяются от minSize и maxSize окна, и конечно установлен ли NSResizableWindowMask. Ранее было возможно ограничить изменение размеров с методом делегата NSWindow windowWillResize:toSize: но этот подход произведет вводящие в заблуждение курсоры, поэтому предпочтет устанавливать minSize и maxSize в дополнение к (или вместо) этот метод делегата.

NotificationCenter NSWORKSPACE и блоки

В SnowLeopard основанный на блоках API не был надежен для добавления наблюдателей к специальным уведомлениям, продаваемым центром уведомления NSWORKSPACE (таким как NSWorkspaceDidTerminateApplicationNotification). В частности по крайней мере один наблюдатель должен был бы использовать цель - селектор базировал API для уведомления, которое будет успешно получено основанным на блоках API.

В 10,7, это было разрешено, так, чтобы уведомление NSWORKSPACE центрировало работы с основанным на блоках API во всех случаях.

NSWorkspace openURLs: возвращаемое значение

В 10,7, метод NSWorkspace - (BOOL) openURLs: withAppBundleIdentifier: опции: additionalEventParamDescriptor: launchIdentifiers: если идентификатор пакета не обратится к существующему приложению, теперь возвратится НЕ и не откроет что-либо. В SnowLeopard и ранее, это возвратило бы ДА, проигнорировало бы пакет ID и открыло бы URLs с приложениями по умолчанию. Если идентификатор пакета будет нолем или пустой, то это будет использовать приложение по умолчанию для URLs (который является тем же поведением на SnowLeopard и ранее).

Чтобы определить, допустим ли идентификатор пакета, можно использовать absolutePathForAppBundleWithIdentifier: метод.

NSWorkspace setDesktopImageURL: теперь работы с папками

В 10,7, можно передать URL папке к рисунку рабочего стола NSWorkspace API, и рабочий стол циклически повторится через изображения в папке (нерекурсивно). Точно так же desktopImageURLForScreen: API может возвратить URL папке.

Самообслуживание

Прежде 10.7, если бы приложение вызвало свою собственную Службу и Службу, имеет типы возврата, приложение зашло бы в тупик до тайм-аута (или пользовательский Escape хитов). В 10,7, приложение может вызвать свою собственную Службу без мертвой блокировки.


Восстановимое состояние

В 10,7, AppKit поддерживает путь к приложениям для восстановления их состояния, когда повторно запущено. Посмотрите методы в NSWindowRestoration.h для получения дополнительной информации.

Игнорирование существующего восстановимого состояния

. Когда пользовательское значение по умолчанию, ApplePersistenceIgnoreState определяется, существующие восстановимые и Документы без названия состояния проигнорировано, новые восстановимые автосохранения и Документа без названия состояния перенаправляются к временному каталогу, путь которого будет зарегистрирован к консоли. Это пользовательское значение по умолчанию предназначается для автоматизированных тестов, хотящих запуститься с чистой среды, и для отладки.

Управление версиями панели инструментов

В 10,7, когда приложения добавят элементы к своей панели инструментов по умолчанию (возможно, в новых версиях), у пользователей со специализированными панелями инструментов будут новые элементы автоматически добавленными. До 10,7, если бы приложение добавило новый элемент к списку элемента панели инструментов по умолчанию, что новый элемент не появился бы для пользователей со специализированными панелями инструментов. Это вызвано тем, что NSToolbar просто сохранил список элементов на специализированной панели инструментов, таким образом, не было никакого способа различить элемент, удаленный пользователем и элементом, который не был доступен, когда было в последний раз выполнено приложение.

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

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

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

Изменения NSWorkspace recycleURLs для Объемов Без Мусора

В SnowLeopard, если Вы используете использование recycleURLs: на объеме, не поддерживающем мусор, такой как AFP, монтируются, файлы не были бы перемещены, и результатом будет «файл, не найденный» ошибка. В 10,7, этот метод изменился, чтобы предложить пользователю или удалять файлы или отменять. Если файл успешно удален, отмена результатов в NSUserCanceledError, при удалении результатов по ошибке получила из попытки удалить файл, или никакую ошибку.

Текст и поля поиска на панелях инструментов

В 10,7, поля поиска и текстовые поля рисуют немного по-другому, когда они в панелях инструментов, по сравнению с в представлении содержания окна. Вариант панели инструментов требует одной дополнительной точки, таким образом, тексту и полям поиска на панелях инструментов увеличат их высоту автоматически по крайней мере до 23 точек. Кроме того, если NSToolbarItem имеет поле поиска как свое представление, то поле поиска автоматически имеет свой минимальный и максимальный размер, скорректированный к указанным системой стандартным значениям (в настоящее время 140 и 240 точек).

Изменения контекстного меню панели инструментов

В 10,7, NSToolbar больше не позволяет пользователям управлять приоритетом видимости элементов панели инструментов, несмотря на то, что пользователи могут все еще добавить и удалить элементы. Кроме того, пункт меню Remove Item был самостоятельно удален, кроме тех случаев, когда, работая с Речью.

Разделитель панели инструментов и Настраивает удаленные элементы

В 10,7, Настроить элемент Панели инструментов и элемент Разделителя (с вертикальными точками) были удалены из панелей инструментов и палитр настройки, и их идентификаторы элемента проигнорированы.

Справа налево в - [NSMenu popUpMenuPositioningItem:atLocation:inView:]

В 10,7, метод NSMenu popUpMenuPositioningItem:atLocation:inView: расположит меню направо от переданного - в точке, при выполнении в справа налево контекст. См. описание метода в заголовке NSMenu.h для получения дополнительной информации.

NSResizableWindowMask и панели заголовка окна

До 10,7, передавая NSResizableWindowMask NSWindow init методы создал бы окно со строкой заголовка, как будто Вы передали NSTitledWindowMask. В 10,7, это больше не истина: передача NSResizableWindowMask без NSTitledWindowMask создаст окно изменяемого размера без строки заголовка. Для совместимости это изменение только влияет на приложения, скомпилированные на 10,7 или позже, и только влияет на окна, загруженные из перьев, сохраненных на 10,7.

Для максимальной совместимости необходимо, конечно, указать NSTitledWindowMask каждый раз, когда Вы хотите, чтобы окно имело строку заголовка.

Неназванные окна в запуске

Как часть восстановимой функции окон, делегата приложения нельзя попросить создать окно Untitled в запуске при некоторых обстоятельствах. Это, как находили, вызвало катастрофические отказы в определенных приложениях, таким образом, эти приложения поддержат 10,6 поведений чаще вводных окон Untitled. Когда эти приложения будут перекомпилированы на 10,7, они получат 10,7 поведений. Для максимальной совместимости не зависьте от того, чтобы быть попросившимся создать окно Untitled в запуске.

Округленные ширины кнопки всплывающего меню

В 10,7, синяя область индикатора округленных кнопок всплывающего меню была удалена, и таким образом, содержанию кнопки (такому как его заголовок) позволяют занимать больше места. Знайте при разработке на 10,7, что округленная кнопка всплывающего меню, не пристегивающаяся 10.7, может отсечь, когда работается более ранние версии.



Модернизированная модель документа

Mac OS 10.7 представляет модернизированную модель документа в который:
• Пользователь не должен вручную управлять многократными копиями их файлов документов, чтобы быть в состоянии получить старые версии, которые они считали интересным в некоторый момент в прошлом.
• Пользователь не обеспокоен предупреждениями, спрашивающими, что сделать с несохраненными изменениями документа когда заключительные документы или завершающий приложения. (См. другие разделы этой информации о версии для изменений в том, когда будут завершены приложения.)
• Пользователь не должен знать и заботиться для сохранения изменений документа прежде, чем заставить файл документа быть считанным другим приложением. Например, если пользователь перетащит значок документа от Средства поиска и отбросит его в окне редактирования Сообщения электронной почты для создания присоединения тогда, то присоединение будет всегда включать все изменения, которые пользователь внес в документ до той точки. Другими словами, с точки зрения пользователя документ, столь представленный в окне приложения, является просто той же вещью как файл документа, представленный Средством поиска, и наоборот.

Следующие несколько разделов описывают изменения в NSDocument, который необходимо знать собирающийся подать заявку, соответствуют модернизированной модели документа.

NSDocument, сохраняющийся автоматически на месте

Mac OS 10,4 представленных к NSDocument «автоматическое сохранение» документов для защиты от пользователя, теряющего работу вследствие сбоев приложения, паники ядра и сбоев питания. Можно легко создать находящееся в NSDocument приложение, периодически сохраняющее текущее содержание документа файлу рядом с фактическим файлом документа в файловой системе и наличии имени как “Мой Большой (Сохраненный автоматически) Документ”. Сохраненные автоматически файлы содержания для документов, никогда не сохранявшихся и так еще не имеющих файлов документов, входят в ~/Library/Autosave информация. NSDocument заботится об инициировании периодического автоматического сохранения, выборе, куда сохраненный автоматически файл содержания документа идут, вызывая код Вашего подкласса NSDocument для записи файла документа, очистки сохраненных автоматически файлов содержания документа, когда они избыточны, и повторное открытие сохраненных автоматически документов, когда приложение повторно запускается после очевидного неправильного функционирования.

Автоматическое сохранение все еще служит цели защитить от неправильного функционирования, но является теперь также важной частью реализации NSDOCUMENT Mac OS 10.7’s модернизированная модель документа. Был добавлен новый вид автоматического сохранения, сохраняясь автоматически на месте. Автоматическое сохранение на месте отличается от старого вида автоматического сохранения, в котором это перезаписывает фактический файл документа вместо того, чтобы писать отдельный файл содержания документа рядом с ним в файловой системе. Старый вид автоматического сохранения, теперь названного автоматическим сохранением в другом месте, все еще поддерживается для обратной совместимости на уровне двоичных кодов и также для того, когда документ никогда не сохранялся, таким образом, нет никакого файла документа, и автоматическое сохранение требует записи в некоторый другой файл. Вы позволяете сохраниться автоматически на месте, и большое разнообразие новых способов поведения, следующих из него для подклассов NSDocument в Вашем приложении путем переопределения нового метода класса и возврата YES из переопределения:
+ (BOOL)autosavesInPlace;
Так, чтобы переопределения Вашего подкласса NSDocument - сохранили … и записали, что … методы могут различить два вида автоматического сохранения перечислителя NSAutosaveOperation, опубликованного в Mac OS 10.4, был переименован, и был добавлен новый:
    NSAutosaveOperation = 3,
NSAutosaveElsewhereOperation = 3,
    NSAutosaveInPlaceOperation = 4
В Mac OS 10.4 через Mac OS 10,6 «автоматического сохранения» было неправильным употреблением, потому что это не было синонимично с “автоматическим сохранением”, которое будет записью текущих документов документа к файлу документа и обновлению атрибутов NSDocument, которое должно быть сделано, когда это происходит. В Mac OS новое автоматическое сохранение 10.7 NSDOCUMENT на месте действительно является автоматическим сохранением.

Автоматическое сохранение на месте может иногда приводить к пользователю, изменяющему файлы документов, которые они действительно не означали изменять. Защищать, против которого, NSDocument делает сохраняющуюся автоматически безопасность, проверяющую, когда пользователь изменяет документ. Примеры проверяют на документы, которые стары (пользователь действительно хочет отредактировать прошлогоднюю налоговую декларацию?) и проверяющий на документы, которые находятся в папках, где пользователь обычно не редактирует документы (пользователь действительно хочет отредактировать что-то, они просто загрузили?). Можно переопределить новый метод для настройки этой проверки:
- (BOOL)checkAutosavingSafetyAndReturnError:(NSError **)outError;
См. комментарии в <AppKit/NSDocument.h> для подробных данных.

NSDocument сохраняющиеся автоматически изменения

В Mac OS 10.7 способ, которым NSDocument инициировал периодическое автоматическое сохранение для противоаварийной защиты, более сложен, чем простая установка таймера, когда пользователь изменяет документ. Нет никакого способа настроить это поведение кроме использования существующего-setAutosavingDelay: и методы-autosavingDelay в NSDocumentController, но существуют новый метод NSDocument, который можно переопределить для реализации собственного поведения:
- (void)scheduleAutosaving;
Этот метод вызывается-updateChangeCount: и-updateChangeCountWithToken:forSaveOperation:.

Включение сохраняющийся автоматически на месте в Ваших находящихся в NSDocument изменениях приложений, что делает NSDocument, когда пользователь закрывает документ и там не сохраняется изменения. Вместо того, чтобы представить предупреждение, спрашивающее пользователя, что сделать с изменениями, NSDocument просто сохраняет документ автоматически, прежде чем это будет закрыто. То автоматическое сохранение не сделано путем вызова существующего-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: метод. Вместо этого это сделано путем вызова нового метода:
- (void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
completionHandler:(void (^)(NSError *errorOrNil))completionHandler;
См. комментарии в <AppKit/NSDocument.h> для подробных данных.

Вещи наблюдать за при включении NSDocument, сохраняющегося автоматически на месте

Включение сохраняющийся автоматически на месте в Вашем приложении может потребовать других изменений в Вашем подклассе NSDocument. Вот некоторые вещи наблюдать за:

• Включение асинхронного сохранения

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

• Вызов и переопределение устаревших методов

За эти годы много методов NSDocument были осуждены. Особенно, в Mac OS 10,4 новых методов, берущих NSURLs и возвращающих NSErrors, заменили не делающие методы. Необходимо обновить приложение, чтобы прекратить вызывать и переопределять замененные методы. Они перечислены у основания <AppKit/NSDocument.h>.

• Переопределение-revertToContentsOfURL:ofType:error:

Когда Вы позволяете сохраниться автоматически на месте, Вы также включаете сохранение версии. (Если Вы также не переопределяете +preservesVersions для выключения сохранения версии.) С автоматическим сохранением на месте включенного более важно чем когда-либо вызвать супер при переопределении-revertToContentsOfURL:ofType:error: потому что это - реализация по умолчанию NSDOCUMENT того метода, обновляющего состояние документа для отражения то, что происходит во время возвращения со старой версией. Если Вы не делаете, NSDocument мог бы подарить пользователю предупреждения о документе, измененном другим приложением когда дело не в этом.

Ваше переопределение-revertToContentsOfURL:ofType:error: май теперь быть переданным URL, который не является тем же как текущим файлом документа URL и тип файла, который не является тем же как текущим типом файла документа.

• Переопределение различного - пишет … методы

Во время дублирования и возвращения NSDocument может вызвать текущую версию документа, тот, на который смотрит пользователь в тот момент, чтобы быть сохраненным. Выполнение этого иногда требует, чтобы текущее содержание документа было записано в диск. NSDocument не вызывает ни одного из - сохраняют … методы в этом случае. Вместо этого это вызывает-writeSafelyToURL:ofType:forSaveOperation:error: передавая его URL файлу, который станет сохраненной версией, тип файла что [сам autosavingFileType] возвраты и NSAutosaveElsewhereOperation. Ваш подкласс NSDocument должен записать все содержание документа тому файлу. Если Вы не переопределите-writesafelytourl:oftype:forsaveoperation:error, Вы, вероятно, не заметите это: Вы правильно переопределяете один из простых методов записи, которые являются-writeToURL:ofType:error:-fileWrapperOfType:error: и-dataOfType:error: и если-autosavingFileType всегда возвращает надлежащее значение.

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

• Переопределение-keepBackupFile

Вы не должны переопределять-keepBackupFile таким способом, которым он возвращает YES, когда +autosavesInPlace возвращает YES.

• Переопределение-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo:

Когда автоматическое сохранение на месте включено не, все автоматическое сохранение сделано вызовом-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: таким образом, это не хороший метод переопределить для настройки всех видов автоматического сохранения. Рассмотрите переопределение-saveToURL:ofType:forSaveOperation:completionHandler: и проверка переданного - в работе сохранения вводит вместо этого.

• Переопределение-validateUserInterfaceItem: и-validateMenuItem:

Включение автоматического сохранения на месте добавляет всплывающее меню к строке заголовка окон документа. Всплывающее меню имеет действия, которые должны быть проверены экземпляром NSDocument. Если Вы переопределяете-validateUserInterfaceItem: или-validateMenuItem: необходимо удостовериться, что переопределение вызывает супер, когда действие не является тем, которое распознает подкласс.

• Обновление меню File

В приложениях, позволивших сохраниться автоматически на месте, Сохранение Как … и Сохраняющих Все элементы в меню File, скрыты, и пункт меню Duplicate добавляется.

• Значение-setAutosavingDelay NSDocumentController: и методы-autosavingDelay

В приложениях, позволивших сохраниться автоматически на месте, в противоположность старому стилю автоматического сохранения, представленного в Mac OS 10.4, передав значение - [NSDocumentController setAutosavingDelay:] к 0,0 не выключает автоматическое сохранение.


NSDocument асинхронное сохранение

Mac OS 10.7 представляет NSDocument понятие асинхронного сохранения, в котором записи в сохраненный файл делаются на фоновом потоке, таким образом, пользовательский интерфейс приложения остается быстро реагирующим, даже если та запись является медленной. Сохранение теперь сделано новым методом, который не должен сигнализировать успешность или неуспешность, прежде чем это возвратится:
- (void)saveToURL:(NSURL *)url
ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
completionHandler:(void (^)(NSError *errorOrNil))completionHandler;
- saveToURL:ofType:forSaveOperation:error: старое, синхронное, вариант этого метода, осуждается. Если Ваше приложение является переопределяющим, что метод для настройки сохранения Вас должен переопределить этот новый метод вместо этого. Если Ваше приложение должно продолжать работать на версиях Mac OS X, более старого, чем 10,7, можно оставить переопределение старого метода там. Если Вы сделаете это тогда, то NSDocument вызовет старый метод на Mac OS 10.6 и более старый и новый на Mac OS 10.7 и более новый.

Является ли сохранение асинхронным, управляется новым методом, который можно переопределить:
- (BOOL)canAsynchronouslyWriteToURL:(NSURL *)url
ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation;
Этот метод вызывается во время сохранения. Если Ваше переопределение его возвратит YES тогда, то NSDocument создаст отдельный поток записи и вызовет-writeSafelyToURL:ofType:forSaveOperation:error: на нем, но основной поток останется блокированным, пока что-то на потоке записи не вызовет другой новый метод:
- (void)unblockUserInteraction;
Когда этот метод будет вызван, основной поток станет разблокированным, приложение возобновит события пользовательского интерфейса исключения из очереди, и пользователь будет в состоянии продолжать просматривать и редактировать их документ, даже если фактическая запись файла займет время. Правильный момент для вызова этого метода - когда неизменный «снимок» содержания документа был взят так, чтобы запись содержания снимка могла продолжаться безопасно на потоке записи, даже когда пользователь редактирует документ об основном потоке. Во многих приложениях, берущих тот снимок, будет так же просто как создание NSFileWrapper, таким образом, реализация по умолчанию-writeToURL:ofType:error: вызывает - unblockUserInteraction после того, как это вызвало-fileWrapperOfType:error: но прежде, чем записать, что NSFileWrapper в файл. Если Ваш подкласс NSDocument просто переопределяет-fileWrapperOfType:error: или-dataOfType:error: реализовать запись и Ваше переопределение никогда не берет слишком долго для возврата тогда, Вы не должны волноваться о вызове-unblockUserInteraction.

Существует ошибка в комментарии для этого метода в <AppKit/NSDocument.h>. Реализация по умолчанию-fileWrapperOfType:error: не вызывает-unblockUserInteraction. Реализация по умолчанию-writeToURL:ofType:error: с другой стороны, делает.

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

В существенном приложении многопоточную копию на записи трудно реализовать. Чтобы установить более реалистическое равновесие между скоростью отклика, и простота асинхронного машинного оборудования сохранения NSDOCUMENT реализации также поддерживает «копирование остановки на записи» модель, в которой Ваш подкласс NSDocument может попытаться взять упомянутый выше снимок, но часто отменять то создание снимков, и фактически всю работу сохранения, если это занимает много времени, что продолжительное редактирование пользователем документа требует мутации создаваемых снимки объектов. Когда создание снимков должно быть отменено, реализация этого правильно требует реализации ориентированного на многопотоковое исполнение способа отменить создание снимков и также способ распознаться. Надо надеяться, это все еще будет проще для разработчиков приложений, чем копия на записи. Для обнаружения, когда такая отмена создания снимков является подходящей для определенной работы сохранения, можно вызвать новый метод:
- (BOOL)autosavingIsImplicitlyCancellable;
Эти возвраты метода ДА, например, когда периодическое автоматическое сохранение делается для противоаварийной защиты и поэтому ничего плохо, произошли бы, если то автоматическое сохранение должно было быть отменено Вашим копированием остановки на механизме записи. Это возвращается НЕ, когда автоматическому сохранению нужно позволить продолжаться, даже это собирается занять значимое количество времени, когда документ закрывается, например.

Когда сохранение является асинхронным, и пользователю разрешают отредактировать документ, в то время как это - старый метод сохраненного NSDOCUMENT обновления changedness документа после успешного сохранения путем вызова-updateChangeCount и передачи его, NSChangeCleared или NSChangeAutosaved не достаточны. Информация должна быть зарегистрирована о состоянии документа в начале работы сохранения и использоваться в конце. NSDocument теперь делает это, с помощью двух новых методов:
- (id)changeCountTokenForSaveOperation:(NSSaveOperationType)saveOperation;
- (void)updateChangeCountWithToken:(id)changeCount
forSaveOperation:(NSSaveOperationType)saveOperation;
См. комментарии в <AppKit/NSDocument.h> для подробных данных обо всех методах, опубликованных в этом разделе.

NSDocument UI и сериализация доступа к файлу

С асинхронным сохранением для пользователя возможно спровоцировать действие пользовательского интерфейса, которое могло бы представить модальный UI, лист, например, когда асинхронное сохранение собирается привести к сбою и представить собственный ошибочный лист предупреждения, который не работал бы. Эта проблема предотвращена при помощи ряда новых методов:
- (void)performActivityWithSynchronousWaiting:(BOOL)waitSynchronously
usingBlock:(void (^)(void (^activityCompletionHandler)(void)))block
- (void)continueActivityUsingBlock:(void (^)(void))block;
Как правило необходимо использовать эти методы, если подкласс NSDocument поддерживает асинхронное сохранение вокруг производительности действий пользовательского интерфейса, которые могли бы представить модальный UI, как листы, включая ошибочные предупреждения.

Для любого экземпляра NSDocument существуют значения в памяти, которые только целесообразны в контексте текущего состояния файла документа. Проблемы возникают, когда один поток получает или устанавливает эти значения, в то время как различный поток изменяет текущее состояние файла. Эти проблемы предотвращены при помощи различного набора новых методов:
- (void)performSynchronousFileAccessUsingBlock:(void (^)(void))block;
- (void)performAsynchronousFileAccessUsingBlock:(void (^)(void (^completionHandler)(void)))block;
Необходимо использовать эти методы, если подкласс NSDocument поддерживает асинхронное сохранение в коде, принимающем решения на основе значений, изменяющихся действием сохранения документа, и в коде, изменяющем те значения.

- performActivityWithSynchronousWaiting:usingBlock: и-performSynchronousFileAccessUsingBlock: может блокировать основной поток. Иногда то блокирование должно быть прервано. Можно сделать это, с помощью другого нового метода:
- (void)continueAsynchronousWorkOnMainThreadUsingBlock:(void (^)(void))block;
См. комментарии в <AppKit/NSDocument.h> для подробных данных обо всех методах, опубликованных в этом разделе.

Дублирование NSDocument

Часть Mac OS 10.7's новая модель документа является Двойным элементом в меню File, заменяющем существующее Сохранение, Поскольку … элемент, таким образом включая сохраняющийся автоматически на месте в любом подклассе NSDocument в Вашем приложении делает еще две вещи:
• Заставляет NSDocumentController добавить пункт меню Duplicate к меню File Вашего приложения.
• Делает экземпляры из этого, подкласс NSDocument в цепочке респондента скрывает Сохранение Как … элемент в меню File.

Обработка выбора пользователя Двойной элемент сделана тремя новыми методами NSDocument:
- (IBAction)duplicateDocument:(id)sender;
- (void)duplicateDocumentWithDelegate:(id)delegate
didDuplicateSelector:(SEL)didDuplicateSelector
contextInfo:(void *)contextInfo;
- (NSDocument *)duplicateAndReturnError:(NSError **)outError;
- duplicateAndReturnError: вызывает новый метод NSDocumentController для фактического создания нового документа:
- (NSDocument *)duplicateDocumentWithContentsOfURL:(NSURL *)url
copying:(BOOL)duplicateByCopying
displayName:(NSString *)displayNameOrNil
error:(NSError **)outError;
Оба из этих методов работают надежно только, когда только отправленный в экземпляры NSDocument, в котором на месте включено автоматическое сохранение.

Когда NSDocumentController создает новый двойной документ, он определяет свое имя путем вызова другого нового метода NSDocument:
- (void)setDisplayName:(NSString *)displayNameOrNil;
Если Ваш подкласс NSDocument ранее реализовал этот метод, Вы, возможно, должны разместить для реализации NSDOCUMENT и использования этого метода, когда Вы в конечном счете соединяетесь на Mac OS 10.7. См. комментарии в <AppKit/NSDocument.h> и <AppKit/NSDocumentController.h> для подробных данных.

Изменение обработки ошибок NSDocument

Реализации по умолчанию некоторых методов NSDocument возвращают восстанавливаемый NSErrors. Восстановление после некоторых видов ошибок использует ресурсы, как временные файлы, которые не могут быть очищены, прежде чем NSError возвращается. Если такой NSError будет представлен пользователю, то ресурс будет очищен автоматически, независимо от того, какую опцию восстановления пользователь выбирает, но в некоторых редких случаях не является надлежащим представить NSError пользователю. В тех случаях можно инициировать необходимую очистку ресурса путем вызова нового метода:
- (void)willNotPresentError:(NSError *)error;
См. комментарий в <AppKit/NSDocument.h> для подробных данных.

Фиксация Типа файла в - [NSDocument saveToURL:ofType:forSaveOperation:completionHandler:]

Новый-saveToURL:ofType:forSaveOperation:completionHandler: метод имеет функцию что старый-saveToURL:ofType:forSaveOperation:error: метод не делает. Когда переданный - в URL имеет расширение файла, которое не допустимо для переданного - в типе,-saveToURL:ofType:forSaveOperation:completionHandler: внутренне создает новый URL, расширение файла которого допустимо, и использование что вместо этого для работы сохранения. Это передает, это «фиксировало» URL, когда это вызывает-writeSafelyToURL:ofType:forSaveOperation:error:. Если запись успешно выполняется, она удаляет файл, расположенный исходным URL. Это использует - [NSFileCoordinator itemAtURL:didMoveToURL:] должным образом, когда это делает это.

Это полезно в приложениях, типы документов которых могут быть изменены пользовательским действием. Например, когда пользователь добавляет присоединения к документам, в Mac OS 10.7, TextEdit использует в своих интересах это, чтобы более легко преобразовать .rtf файлы в .rtfd.

- saveToURL:ofType:forSaveOperation:error: не делает этого. Кроме того,-saveToURL:ofType:forSaveOperation:completionHandler: не делает этого, когда это вызывает-saveToURL:ofType:forSaveOperation:error: для обратной совместимости на уровне двоичных кодов.

NSDocumentController асинхронное открытие и повторное открытие

Mac OS 10,6 представленных к NSDocumentController понятие параллельного открытия документа, но никакого соответствующего метода был опубликован. В Mac OS 10,7 открытий теперь сделаны новым методом, который не должен сигнализировать успешность или неуспешность, прежде чем это возвратится:
- (void)openDocumentWithContentsOfURL:(NSURL *)url
display:(BOOL)displayDocument
completionHandler:(void (^)(NSDocument *document, BOOL documentWasAlreadyOpen, NSError *error))completionHandler;
Повторное открытие, которое является тем, что происходит во время запуска приложения, когда новое Восстановимое машинное оборудование AppKit состояния восстанавливает документ, который был открыт, когда приложение было в последний раз завершено, теперь также сделано новым методом, который не должен сигнализировать успешность или неуспешность, прежде чем это возвратится:
- (void)reopenDocumentForURL:(NSURL *)urlOrNil
withContentsOfURL:(NSURL *)contentsURL
display:(BOOL)displayDocument
completionHandler:(void (^)(NSDocument *document, BOOL documentWasAlreadyOpen, NSError *error))completionHandler;
- openDocumentWithContentsOfURL:display:error: и-reopenDocumentForURL:withContentsOfURL:error: старое, синхронное, варианты этих методов, осуждаются. Если Ваше приложение переопределяет один из тех методов для настройки открытый или вновь открывается, необходимо переопределить новый метод вместо этого. Если Ваше приложение должно продолжать работать на версиях Mac OS X, более старого, чем 10,7, можно оставить переопределение старого метода там. Если Вы сделаете это тогда, то NSDocument вызовет старый метод на Mac OS 10.6 и более старый и новый на Mac OS 10.7 и более новый.

См. комментарии в <AppKit/NSDocumentController.h> для подробных данных.

Перемещение NSFileWrapper от платформы AppKit до платформы основы

В Mac OS 10.7 класс NSFileWrapper был перемещен от платформы AppKit до платформы Основы. NSFileWrapper (NSExtensions) категория, объявленная в <AppKit/NSFileWrapperExtensions.h>, остается позади. Это включает-setIcon: и - методы значка. Класс NSFileWrapper, включая все другие методы, теперь объявляется в <Foundation/NSFileWrapper.h>.




NSResponder

- (id)supplementalTargetForAction:(SEL)action sender:(id)sender;
Этот метод используется в процессе нахождения цели для метода действия и для нулевой целевой маршрутизации действия и для проверки пользовательского интерфейса (меню, элементы панели инструментов). Это позволяет Вам добавлять не, NSResponder возражает против цепочки респондента действия. Некоторое использование в качестве примера этого API: разрешение делегата управления или плагина для ответа на действия.

Если этот экземпляр NSResponder не делает самостоятельно respondsToSelector:action, то supplementalTargetForAction:sender: вызывается. Этот метод должен возвратить объект, реагирующий на действие; если у этого респондента нет дополнительного объекта, делающего это, реализация этого метода должна вызвать supplementalTargetForAction:sender: super. Реализация NSRESPONDER возвращает ноль. Пример базового внедрения:
- (id)supplementalTargetForAction:(SEL)action sender:(id)sender {
    return [_foo respondsToSelector:action] ? _foo : [super supplementalTargetForAction:action sender:sender];
}
Возврат объекта, не реагирующего на действие, является ошибкой. Обычно этот метод вызывает NSApplication, и NSApplication повышает исключение в этом случае.

NSPrintOperation

Если лист печати безразличен или вял вследствие времени, взятия Вы, чтобы полностью представить страницу, можно проверить этот метод в drawRect и другие методы печати, такие как beginDocument и knowsPageRage: определить, предпочитает ли работа печати скорость по точности. Большинство приложений представляет каждую страницу достаточно быстро и не должно вызывать этот метод. Только используйте этот API после установления того рендеринга высшего качества, действительно делает пользовательский интерфейс безразличным.
enum {
// Render at the best quality you can regardless of how slow that may be
NSPrintRenderingQualityBest,
    // Sacrifice the least possible amount of rendering quality for speed
// to maintain a responsive user interface
NSPrintRenderingQualityResponsive
};
typedef NSInteger NSPrintRenderingQuality;
@implementation NSPrintOperation ...
- (NSPrintRenderingQuality)preferredRenderingQuality;
Это - использование в качестве примера этого API:
- (void)drawRect:(NSRect)rect {
NSGraphicsContext *currentContext = [NSGraphicsContext currentContext];
if (![currentContext isDrawingToScreen]) {
NSPrintOperation *printOperation = [NSPrintOperation currentOperation]
if ([printOperation preferredRenderingQuality] == NSPrintRenderingQualityResponsive) {
// Render with the best possible quality such that the user interface remains responsive
} else {
// Printing, do a full render
}
}
}

События ScrollWheel

Существуют новые методы NSEvent для доступа к дельте события колесика прокрутки, которые допускают более точные значения дельты от Волшебных Мышей и сенсорных панелей. когда событие является типом NSScrollWheel,-deltaX и-deltaY больше не должны использоваться.

Универсальное колесико прокрутки выходит довольно крупный (строка) дельты прокрутки. Т.е. сумма, которую Вы фактически прокручиваете, является высотой строки, умноженной на дельту прокрутки. Некоторые мыши Apple и сенсорные панели обеспечивают намного более точную дельту. Вместо того, чтобы умножиться высотой строки, Вы используете значение дельты прокрутки как есть. Новые-scrollingDeltaX/Y методы всегда возвращают самую точную дельту, предоставленную устройством ввода данных. Можно определить точность-scrollingDelta с новым-hasPreciseScrollingDeltas методом. Когда-hasPreciseScrollingDeltas возвратится нет, умножьте возвращенное значение с методической точностью или высоту строки. Когда-hasPreciseScrollingDeltas возвратится ДА, прокрутите возвращенным значением (в точках).
- (BOOL)hasPreciseScrollingDeltas;
- (CGFloat)scrollingDeltaX;
- (CGFloat)scrollingDeltaY;
Коснитесь способных мышей Apple, и сенсорные панели знают, когда пользователь физически запускает и прекращает прокручивать. AppKit публикует это состояние с помощью нового метода ниже.
enum {
NSEventPhaseNone = 0, // event not associated with a phase.
NSEventPhaseBegan = 0x1 << 0,
NSEventPhaseStationary = 0x1 << 1,
NSEventPhaseChanged = 0x1 << 2,
NSEventPhaseEnded = 0x1 << 3,
NSEventPhaseCancelled = 0x1 << 4,
};
typedef NSUInteger NSEventPhase;
- (NSEventPhase)phase;
События колесика прокрутки вышли от несенсорных устройств прокрутки, которые не могут различить, когда пользователь запускает и заканчивается, жест прокрутки имеют фазу NSEventPhaseNone. Для сенсорных устройств прокрутки первое событие колесика прокрутки в последовательности жеста имеет фазу NSEventPhaseBegan. Последующая прокрутка в последовательности имеет фазу NSEventPhaseChanged. Когда пользователь физически заканчивает жест, заключительное событие колесика прокрутки имеет фазу NSEventPhaseEnded и scrollingDelta 0,0.

Некоторые мыши Apple и сенсорные панели также выпускают события колесика прокрутки импульса. Т.е. аппаратные средства продолжают выпускать события колесика прокрутки даже при том, что пользователь физически больше не прокручивает. AppKit направляет эти события колесика прокрутки к представлению, курсор был закончен, когда они запустили. Для пользовательских ячеек это может не быть достаточно. Когда импульс, прокручивающий, запускается, продолжается и останавливается и дальнейший маршрут события соответственно, Используя новые методы ниже, можно теперь определить.
- (NSEventPhase)momentumPhase;
Для нормального (не импульс) события колесика прокрутки, momentumPhase является NSEventPhaseNone. Когда аппаратные переключатели от пользователя выполнили события прокруток к событиям колесика прокрутки импульса, momentumPhase установлен в NSEventPhaseBegan. Последующие события колесика прокрутки от того устройства имеют momentumPhase NSEventPhaseChanged до затуханий импульса к 0, или пользователь останавливает прокрутку импульса. Заключительное событие колесика прокрутки импульса имеет momentumPhase NSEventPhaseEnded. Все события колесика прокрутки импульса имеют фазу NSEventPhaseNone.


Прокрутка и направление жеста

Существует новая пользовательская настройка для «Перемещения содержания в направлении перемещения пальца». Для выполнения этого deltaX/Y и scrollingDeltaX/Y автоматически инвертируются для событий NSEventScrollWheel согласно предпочтениям пользователя. Направление сильно ударяет, соответствуют направление прокрутки и, как таковые, сильно ударяют, дельты инвертируются. Однако для некоторого использования событий NSEventScrollWheel и NSEventTypeSwipe, поведение не должно уважать пользовательскую настройку. Когда событие было инвертировано и компенсирует путем умножения-1 в случае необходимости, этот метод позволяет Вам определять.
- (BOOL)isDirectionInvertedFromDevice;

Перетаскивание мультиизображения

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

NSDraggingSource и NSDraggingDestinations являются теперь формальными протоколами. Следующие новые классы были представлены. NSDraggingSession, NSDraggingItem и NSDraggingImageComponent. Когда перетаскивание запускается, NSDraggingSession создается. Текущее изображение основанное перетаскивание методов осуждается в пользу нового NSDraggingSession, базировало методы (См. NSView.h и NSDragging.h). Протокол NSDraggingInfo расширен с новыми методами, позволяющими модификации элементам перетаскивания. Новый метод NSView для начала перетаскивания берет массив NSDraggingItems (pasteboardItems, кадры и провайдеры изображения) и создает надлежащую область монтажа для перетаскивания. Текущие методы перетаскивания на NSWindow и NSView неофициально осуждаются в пользу этого нового метода.

Основное перетаскивание запускается путем вызова-beginDraggingSessionWithItems:event:source: на представлении. Этот новый метод возвраты сразу же и фактическое перетаскивание происходит позже. Вызывающая сторона может взять возвращенный NSDraggingSession и продолжать изменять его свойства, такие как-animatesToStartingPositionsOnCancelOrFail. Когда перетаскивание фактически запускается, источник отправляется-draggingSession:willBeginAtPoint: сообщение, сопровождаемое многократным-draggingSession:movedToPoint: сообщения как пользователь перетаскивают. Как только перетаскивание заканчивается или отменяется, источник получает-draggingSession:endedAtPoint:operation: и перетаскивание завершено.

Место назначения перетаскивания работает почти такой же путь как прежде. draggingEntered: draggingUpdated: и т.д... в те же времена вызывают методы. Отправитель для этих сообщений все еще соответствует <NSDraggingInfo>. NSDraggingInfo имеет некоторые новые методы, позволяющие месту назначения перечислять элементы перетаскивания, изменяющие их свойства, такие как кадр и изображение.

Когда DragManager решает, что это - хорошее время для перетаскивания для изменения (или изменение формирования и / или изменение образа), место назначения отправляется-updateDraggingItemsForDrag: сообщение, если реализовано. Ожидание вызова к-updateDraggingItemsForDrag: предпочтительный способ изменить изображение перетаскивания в нужное время.


Жидкость сильно ударяет, отслеживая - API

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

ScrollWheel NSEvents теперь отвечает на - сообщение фазы. Существует 3 типа прокруток: когда пользователь шевелит их пальцами с NSEventPhaseEnded, 1) прокрутки Жеста - они начинаются с NSEventPhaseBegan, имеют много событий NSEventPhaseChanged и оконечный. 2) прокрутки Импульса - они имеют фазу NSEventPhase ни один, но у них есть momentumPhase NSEventPhaseBegan/NSEventPhaseChanged/NSEventPhaseEnded. 3) Устаревшие прокрутки - эти события колесика прокрутки имеют фазу NSEventPhaseNone и momentumPhase NSEventPhaseNone. Когда пользователь запускает, ни остановки, выполняя устаревшие прокрутки, нет никакого способа определить.

NSScrollView обрабатывает все события колесика прокрутки жеста и не передает их цепочка респондента. Часто, отслеживание сильно ударения сделано выше в цепочке респондента, например на уровне WindowController. Для достижения возврата «стиля iOS если не в краю иначе сильно ударьте» поведение, необходимо сообщить NSScrollView, что это должно передать сообщения колесика прокрутки в надлежащих случаях. Вместо того, чтобы вручную установить свойство на NSScrollView, Ваш NSResponder может реализовать следующий метод и возвратить YES.
- (BOOL)wantsScrollEventsForSwipeTrackingOnAxis:(NSEventGestureAxis)axis;
Когда надлежащий контроллер получает-scrollWheel: сообщение с не фазой NSEventNone, можно вызвать следующее сообщение на том экземпляре события, чтобы отследить сильно ударение или прокрутить и к пользовательскому завершению события и к завершению анимации.
enum {
NSEventSwipeTrackingLockDirection = 0x1 << 0,
NSEventSwipeTrackingClampGestureAmount = 0x1 << 1
};
typedef NSUInteger NSEventSwipeTrackingOptions;
@interface NSEvent ...
- (void)trackSwipeEventWithOptions:(NSEventSwipeTrackingOptions)options
dampenAmountThresholdMin:(CGFloat)minDampenThreshold
max:(CGFloat)maxDampenThreshold
usingHandler:(void (^)(CGFloat gestureAmount, NSEventPhase phase, BOOL isComplete, BOOL *stop))handler;
...
Ниже псевдо пример кода сильного удара набора изображений как фото приложение iOS.
- (BOOL)wantsScrollEventsForSwipeTrackingOnAxis:(NSEventGestureAxis)axis {
return (axis == NSEventGestureAxisHorizontal) ? YES : NO;
}
- (void)scrollWheel:(NSEvent *)event {
// NSScrollView is instructed to only forward horizontal scroll gesture events (see code above). However, depending
// on where your controller is in the responder chain, it may receive other scrollWheel events that we don't want
// to track as a fluid swipe because the event wasn't routed though an NSScrollView first.
if ([event phase] == NSEventPhaseNone) return; // Not a gesture scroll event.
if (fabsf([event scrollingDeltaX]) <= fabsf([event scrollingDeltaY])) return; // Not horizontal
    // If the user has disabled tracking scrolls as fluid swipes in system preferences, we should respect that.
// NSScrollView will do this check for us, however, depending on where your controller is in the responder chain,
// it may scrollWheel events that are not filtered by an NSScrollView.
if (![NSEvent isSwipeTrackingFromScrollEventsEnabled]) return;
    if (_swipeAnimationCanceled && *_swipeAnimationCanceled == NO) {
// A swipe animation is still in gestureAmount. Just kill it.
*_swipeAnimationCanceled = YES;
_swipeAnimationCanceled = NULL;
}
    CGFloat numPhotosToLeft = // calc num of photos we can move to the left and negate
CGFloat numPhotosToRight = // calc num of photos we can move to the right
    __block BOOL animationCancelled = NO;
[event trackSwipeEventWithOptions:0 dampenAmountThresholdMin:numPhotosToLeft max:numPhotosToRight
usingHandler:^(CGFloat gestureAmount, NSEventPhase phase, BOOL isComplete, BOOL *stop) {
if (animationCancelled) {
*stop = YES;
// Tear down animation overlay
return;
}
        if (phase == NSEventPhaseBegan) {
// Setup animation overlay layers
}
        // Update animation overlay to match gestureAmount
        if (phase == NSEventPhaseEnded) {
// The user has completed the gesture successfully.
// This handler will continue to get called with updated gestureAmount
// to animate to completion, but just in case we need
// to cancel the animation (due to user swiping again) setup the
// controller / view to point to the new content / index / whatever
} else if (phase == NSEventPhaseCancelled) {
// The user has completed the gesture un-successfully.
// This handler will continue to get called with updated gestureAmount
// But we don't need to change the underlying controller / view settings.
}
        if (isComplete) {
// Animation has completed and gestureAmount is either -1, 0, or 1.
// This handler block will be released upon return from this iteration.
            // Note: we already updated our view to use the new (or same) content
// above. So no need to do that here. Just...
            // Tear down animation overlay here
self->_swipeAnimationCanceled = NULL;
}
}];
    // We keep a pointer to a BOOL __block variable so that we can cancel our
// block handler at any time. Note: You must assign the BOOL pointer to your
// ivar after block creation and copy!
self->_swipeAnimationCanceled = &animationCancelled;
}



Полный экран

У Льва мы добавили поддержку полноэкранного опыта, позволяющего пользователям запускать Windows в полноэкранном режиме, где новое пространство динамично создается для каждого окна в полноэкранном режиме. Это означает, например, что у Вас могут быть окно Safari на рабочем столе и другое окно Safari в полноэкранном пространстве.

Полный экран NSWindow API

Приложение должно указать, может ли окно войти полноэкранный. Обратите внимание на то, что существующие относящиеся к космосу способы поведения набора окна продолжают иметь значение в полноэкранных пробелах также. Например, окно с NSWindowCollectionBehaviorTransient будет автоматически показано на полноэкранном пространстве, если это было видимо на месте на рабочем столе при переходе к полноэкранному режиму. Окно с NSWindowCollectionBehaviorMoveToActiveSpace будет показано в полноэкранном пространстве, если пользователь выполнит действие для показа его, даже если это было ранее показано на месте на рабочем столе. Окно с NSWindowCollectionBehaviorManaged остается присоединенным к пространству, на котором это было сначала показано, пока это не закрывается и вновь открывается.

Windows, принадлежащий другим приложениям, не будет позволен на полноэкранном пространстве, за исключением следует: Windows, принадлежащий приложению UIElement, позволяется на полноэкранном пространстве. Неактивация панелей, принадлежавших другим приложениям, также позволяется на полноэкранном пространстве, но только если их поведение набора окна включает NSWindowCollectionBehaviorFullScreenAuxiliary. В зависимости от природы Вашего окна можно хотеть включать NSWindowCollectionBehaviorCanJoinAllSpaces в поведение набора окна для имения окон квалификации, появляются на полноэкранных пробелах, а также настольных пробелах.

перечисление {
//окно с этим поведением набора будет иметь полноэкранную кнопку в верхней правой из ее строки заголовка
  NSWindowCollectionBehaviorFullScreenPrimary = 1 <<7,
//окна с этим поведением набора могут быть показаны на том же пространстве как полноэкранное окно
  NSWindowCollectionBehaviorFullScreenAuxiliary = 1 <<8
};

Окно может быть взято в или из полноэкранного использования-toggleFullScreen:. Если полноэкранная поддержка приложений, это должно добавить пункт меню «Enter Full Screen» к меню View. Пункт меню теперь доступен через Xcode 4. Можно также добавить элемент программно с toggleFullScreen: как действие, ноль как цель и cmd-ctrl-f как ключевой эквивалент. AppKit автоматически обновит заголовок пункта меню как часть его проверки пункта меню.
- (void)toggleFullScreen:(id)sender;
Полноэкранная кнопка окна представлена как стандартная кнопка окна.
enum {
NSWindowCloseButton,
NSWindowMiniaturizeButton,
NSWindowZoomButton,
NSWindowToolbarButton,
NSWindowDocumentIconButton,
NSWindowFullScreenButton
};
typedef NSUInteger NSWindowButton;
Полноэкранное окно не рисует свою строку заголовка и может иметь специальную обработку для его панели инструментов. styleMask установлен указать, что окно имеет полноэкранное появление.
enum {
  NSFullScreenWindowMask = 1 << 14
};
Уведомления отправляются за полноэкранными изменениями:
NSString *NSWindowWillEnterFullScreenNotification;
NSString *NSWindowDidEnterFullScreenNotification;
NSString *NSWindowWillExitFullScreenNotification;
NSString *NSWindowDidExitFullScreenNotification;
Окно также вызывает новые методы делегата как надлежащие.

Делегат NSWindow полный экран API

NSWindow вызывает следующие методы делегата, поскольку окно вводит и выходит из полноэкранного режима; они дают Вам возможность реконфигурировать расположение окна и выполнить другие операции при необходимости.
- (void)windowWillEnterFullScreen:(NSNotification *)notification;
- (void)windowDidEnterFullScreen:(NSNotification *)notification;
- (void)windowWillExitFullScreen:(NSNotification *)notification;
- (void)windowDidExitFullScreen:(NSNotification *)notification;
Кадр по умолчанию полноэкранного окна заполняет весь экран (включая строку меню и области прикрепления). proposedSize будет расчетным contentSize, оставляя пространство для панели инструментов если настоящее. Делегат окна может реализовать этот метод для обеспечения различного размера содержания для окна. Расположение окна будет определенной реализацией (вероятно, центрируемый), если это не заполнит весь экран.
- (NSSize)window:(NSWindow *)window willUseFullScreenContentSize:(NSSize)proposedSize;
Значение по умолчанию presentationMode для полноэкранного (NSApplicationPresentationFullScreen | NSApplicationPresentationAutoHideDock|NSApplicationPresentationAutoHideMenuBar). Делегат может обеспечить различный набор опций вступить в силу в пространстве, содержащем это полноэкранное окно.
- (NSApplicationPresentationOptions)window:(NSWindow *)window
willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions;
Анимация по умолчанию между окном и его полноэкранным представлением является плавно накладыванием. Со знанием расположения окна прежде и после того, как это войдет полноэкранный, приложение может выполнить намного лучшую работу на анимации. Следующий API позволяет делегату окна настраивать анимацию путем обеспечения пользовательского окна или окон, содержащих уровни или другие эффекты. Если получатель должен остаться видимым на полноэкранном пространстве, для управления окнами на пробелах нам нужен делегат окна для обеспечения списка окон, вовлеченных в анимацию в желаемый z-порядок, и включая сам получатель. Если приложение не делает пользовательской анимации, этот метод может быть не реализован или может возвратить ноль.  window:startCustomAnimationToEnterFullScreenWithDuration: будет вызван только если customWindowsToEnterFullScreen: неноль возвратов.
- (NSArray *)customWindowsToEnterFullScreen:(NSWindow *)window;

Система тогда запускает свою анимацию в полноэкранный, включая переход к новому пространству. Метод ниже вызывают, чтобы запустить окно полноэкранная анимация сразу и выполнить анимацию с данной продолжительностью, чтобы быть в синхронизации с системной анимацией. Этот метод вызывают только если customWindowsToEnterFullScreen: возвращенный неноль.
- (void)window:(NSWindow *)window startCustomAnimationToEnterFullScreenWithDuration:(NSTimeInterval)duration;
В некоторых случаях переход для ввода полноэкранный перестанет работать вследствие того, чтобы быть посреди обработки некоторой другой анимации или пользовательского жеста. Мы попытаемся минимизировать эти случаи, но полагать, что существует потребность в обработке отказа. Этот метод указывает, что была ошибка, и приложение должно очистить любую работу, которую это, возможно, выполнило, чтобы подготовить входить полноэкранный. Это сообщение будет отправлено, указал ли делегат пользовательскую анимацию путем возврата неноля из customWindowsToEnterFullScreen:. Отметьте, хотя это окно будет вынуто из полноэкранного пространства и возвращено к рабочему столу даже в случае возникновения отказов, таким образом, будет особенно важно возвратить любую пользовательскую анимацию неполноэкранному состоянию в случае ошибки. Дело обстоит не так, когда с отказом встречаются при вводе полноэкранный. В случае отказа войти, окно оставляют на месте на рабочем столе.
- (void)windowDidFailToEnterFullScreen:(NSWindow *)window;
Когда окно собирается выйти полноэкранный, следующий API позволяет делегату окна настраивать анимацию. Если получатель должен быть видим во время анимации, для управления окнами на пробелах нам нужен делегат окна для обеспечения списка окон, вовлеченных в анимацию в желаемый z-порядок и включая получатель. Если приложение не делает пользовательской анимации, этот метод может быть не реализован или может возвратить ноль.  window:startCustomAnimationToExitFullScreenWithDuration: будет вызван только если customWindowsToExitFullScreen: неноль возвратов.
- (NSArray *)customWindowsToExitFullScreen:(NSWindow *)window;

Система тогда запускает свою анимацию из полноэкранного, включая переход назад к месту на рабочем столе. Метод ниже вызывают, чтобы сразу запустить анимацию окна и выполнить анимацию с данной продолжительностью, чтобы быть в синхронизации с системной анимацией.  Этот метод вызывают только если customWindowsToExitFullScreen: возвращенный неноль.
- (void)window:(NSWindow *)window startCustomAnimationToExitFullScreenWithDuration:(NSTimeInterval)duration;
В некоторых случаях переход к полноэкранному выходу перестанет работать вследствие того, чтобы быть посреди обработки некоторой другой анимации или пользовательского жеста. Мы попытаемся минимизировать эти случаи, но полагать, что существует потребность в обработке отказа. Этот метод указывает, что была ошибка, и приложение должно очистить любую работу, которую это, возможно, выполнило, чтобы подготовить выходить полноэкранный. Это сообщение будет отправлено, указал ли делегат пользовательскую анимацию путем возврата неноля из customWindowsToExitFullScreen:.
- (void)windowDidFailToExitFullScreen:(NSWindow *)window;

Полный экран NSApplication API

Существует полноэкранная опция представления, NSApplicationPresentationFullScreen. Эта опция представления установлена когда в полноэкранном пространстве.

Делегат окна может также указать, что панель инструментов окна удалена из окна в полноэкранном и автопоказанной со строкой меню включением NSApplicationPresentationAutoHideToolbar в presentationOptions, возвращенном из-window:willUseFullScreenPresentationOptions:.
enum {
    NSApplicationPresentationFullScreen = (1 << 10),
    NSApplicationPresentationAutoHideToolbar = (1 << 11),
};
typedef NSUInteger NSApplicationPresentationOptions;

Многократные мониторы и полный экран

Мы сделали некоторые предположения упрощения для Полноэкранного поведения Льва на многократных мониторах. Многократные мониторы обрабатываются как единый блок Пробелами, и поэтому также обрабатываются как единый блок в Полном экране. Это означает, что все мониторы будут выделены окнам, принадлежащим полноэкранному приложению, и может быть только одно основное полноэкранное окно, видимое за один раз. Дополнительный монитор полезен для окон инспектора.

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




Найдите поддержку панели с NSTextFinder

Mac OS 10.7 включает новый класс под названием NSTextFinder, обеспечивающий стандартный подобный Сафари интерфейс панели находки. NSTextFinder также обеспечивает инкрементную функциональность поиска.

NSTextFinder служит классом контроллера для стандартного Какао, находят панель. NSTextFinder взаимодействует в большой степени с его 'клиентом', который является объектом, обеспечивающим доступ к искавшему содержанию и обеспечивающим визуальную обратную связь для поисковой работы путем приспосабливания протоколу NSTextFinderClient, который будет объяснен позже.


Все пункты меню, связанные с нахождением (Находят …, Найдите, Затем, Считают Предыдущими, Выбор Использования для Находки, и т.д.) будет иметь то же действие, performTextFinderAction: который отправляется вниз цепочку респондента обычным способом. (Примечание: Перед Mac OS 10.7, действие по умолчанию для этих пунктов меню было performFindPanelAction: который необходимо обновить к этому новому действию.) Респондент performTextFinderAction: ответственно за создание и владение экземпляром NSTextFinder. Прежде чем любые другие сообщения отправляются NSTextFinder, необходимо установить его 'клиентское' свойство в объект, реализующий протокол NSTextFinderClient.


Каждый элемент интерфейса пользователя, используемый для нахождения, имеет различный тег, соответствующий надлежащему значению в перечислении NSTextFinderAction (см. ниже). По получении performTextFinderAction: сообщение, респондент должен вызвать следование его экземпляра NSTextFinder:
- (void)performAction:(NSTextFinderAction)action;
Этот метод определит желаемое действие от тега и сделает различные обратные вызовы его клиенту для выполнения того действия. Эти обратные вызовы определяются в протоколе NSTextFinderClient.

Проверка происходит подобным образцом. Респондент должен реализовать validateUserInterfaceItem: и, когда действие элемента является performTextFinderAction: это должно передать тег элемента следующему методу и возвратить результат:
- (BOOL)validateAction:(NSTextFinderAction)action;
Этот метод также сделает различные обратные вызовы своим клиентам для определения, каков надлежащий ответ должен быть. Эти обратные вызовы также определяются в протоколе NSTextFinderClient.


Перечисление NSTextFinderAction, используемое в вышеупомянутых методах, упоминается ниже. Значения от этого перечисления являются копиями от старого перечисления NSFindPanelAction, за исключением значения NSTextFinderActionHideFindInterface. Значения NSFindPanelAction будут отображены на значениях NSTextFinderAction. Их существующие числовые значения будут сохранены этим отображением.
enum {
NSTextFinderActionShowFindInterface = 1,
NSTextFinderActionNextMatch = 2,
NSTextFinderActionPreviousMatch = 3,
NSTextFinderActionReplaceAll = 4,
NSTextFinderActionReplace = 5,
NSTextFinderActionReplaceAndFind = 6,
NSTextFinderActionSetSearchString = 7,
NSTextFinderActionReplaceAllInSelection = 8,
NSTextFinderActionSelectAll = 9,
NSTextFinderActionSelectAllInSelection = 10,
NSTextFinderActionHideFindInterface = 11,
NSTextFinderActionShowReplaceInterface = 12,
NSTextFinderActionHideReplaceInterface = 13
};
typedef NSInteger NSTextFinderAction;

Когда действие будет выполнено, NSTextFinder попросит у своего клиента строки, которую это, как предполагается, ищет. Существует два способа, которыми клиент может обеспечить эту строку. Это может или реализовать - строковый метод, и просто возвратить NSString, или это может реализовать следующие методы:
- (NSString *)stringAtIndex:(NSUInteger)characterIndex effectiveRange:(NSRangePointer)outRange endsWithSearchBoundary:(BOOL *)outFlag;
- (NSUInteger)stringLength;
Эти методы упрощают использовать NSTextFinder с данными, которые не могут быть легко или эффективно сглажены в единственный NSString. В первом методе клиент должен возвратить строку, содержащую символ в данном индексе в концептуальной связи всех строк, которые должны искаться. Например, если бы у клиента были строки «Быстрое», «коричневая лиса», «перепрыгнул через ленивое» и «собаку», и NSTextFinder запрашивает строку в индексе 18, то тогда клиент должен возвратить «коричневую лису», потому что 18-й символ всех строк был связан, вместе будет 'x' у «лисы». Кроме того, клиент должен возвратиться, ссылкой через outRange параметр, effectiveRange возвращающейся строки. В вышеупомянутом примере диапазон «коричневой лисы» {9, 10}, потому что в предполагаемой связи подстрока запускается в индексе 9 и является 10 символами долго.

В некоторых случаях не желательно для соответствия быть найденным, который перекрывает многократные строки, возвращенные вышеупомянутым методом. Например, предположите, что у клиента есть список имен как «Джон Доу» и «Джейн Доу», и т.д. Обычно, если строка связывается вместе как так: «Джон DoeJane Доу», тогда поиск «DoeJane» успешно выполнился бы. Для предотвращения этого обычно нежелательного поведения клиент должен возвратиться ДА, ссылкой через outFlag параметр, при возврате каждой отдельной строки. Это указывает, что существует граница между текущей строкой и следующей строкой, которая не должна быть пересечена при поиске соответствия.


Один из двух подходов, описанных выше, должен быть реализован клиентом, или иначе NSTextFinder не будет в состоянии функционировать. Если оба подхода (так все три метода) реализованы, stringAtIndex:effectiveRange:endsWithSearchBoundary: будет использоваться по умолчанию.


Ниже некоторые свойства, о которых сообщает клиент для использования в-validateAction NSTextFinder: метод. Если какое-либо из этих свойств не будет реализовано, то значение YES будет принято. Возврат НЕ из любого из этих методов отключит действия, требующие их. Для получения дополнительной информации, о котором действия требуют этих свойств, консультируйтесь с заголовком NSTextFinder.h.
@property (getter=isSelectable, readonly) BOOL selectable;
@property (readonly) BOOL allowsMultipleSelection;
@property (getter=isEditable, readonly) BOOL editable;

Когда действие отправляется через-performAction: NSTextFinder, возможно, понадобится дополнительная информация от клиента для выполнения того действия, или это может потребовать, чтобы клиент выполнил некоторые части действия от своего лица. Следующие методы и свойства обеспечивают рычаги потребности NSTextFinder в каждом из действий, которые оно поддерживает. Если клиент не реализует один из этих методов или свойств, то действие, требующее его, будет отключено.
@property (readonly) NSRange firstSelectedRange;
Это свойство требуется для NextMatch, PreviousMatch, Замены, ReplaceAndFind и действий SetSearchString. Если нет никакого выбора, клиент просто должен возвратить его первый выбранный диапазон, или {индекс, 0} для указания расположения точки вставки.
@property (retain) NSArray *selectedRanges;
Это свойство требуется для ReplaceAllInSelection, SelectAll и действий SelectAllInSelection. Массив должен содержать NSRanges, обернутый в NSValues.
- (void)scrollRangeToVisible:(NSRange)range;
Этот метод используется многими действиями, но строго не требуется никем. Этот метод дает клиенту команду прокручивать его представление для создания данного диапазона видимым.
- (BOOL)shouldReplaceCharactersInRanges:(NSArray *)ranges withStrings:(NSArray *)strings;
- (void)replaceCharactersInRange:(NSRange)range withString:(NSString *)string;
- (void)didReplaceCharacters;
Эти методы используются ShowReplaceInterface, Заменой, ReplaceAll действиями ReplaceAndFind и (InSelection). NSTextFinder не имеет возможности непосредственно внести изменения в содержание клиента, таким образом, клиент ответственен за выполнение операций замены в этих методах. Прежде чем работа замены выполняется, NSTextFinder вызывает первый метод, чтобы определить, должна ли замена иметь место. Если это возвратится нет, то данный диапазон не будет заменен. Если метод возвратится или не будет реализован, то NSTextFinder вызовет второй метод, давая клиенту команду выполнить замену. Наконец, третий метод вызовут, если реализовано, чтобы указать, что была завершена замена. Для действий ReplaceAll эти методы можно вызвать многократно, запускающийся с конца строки и перемещающийся к началу, для сохранения индексов соответствий, предшествующих текущему.

Для отображения панели находки «контейнер» для панели находки должен быть указан. «Контейнер» является объектом, соответствующим протоколу NSTextFinderBarContainer, описанному ниже. Можно указать контейнер панели находки использование следующего свойства на NSTextFinder:
@property (assign) IBOutlet id <NSTextFinderBarContainer> findBarContainer;
NSTextFinderBarContainer содержит следующие методы для отображения и обновления панели находки:
@protocol NSTextFinderBarContainer <NSObject>
@required
@property (retain) NSView *findBarView;
@property (getter=isFindBarVisible) BOOL findBarVisible;
- (void)findBarViewDidChangeHeight;
[...]
@end
Когда новый NSTextFinder будет создан и проинструктирован для отображения панели находки, он создаст NSView для панели находки и присвоит это контейнеру через findBarView свойство. Когда контейнер освобожден, от той точки на контейнер владеет тем представлением и должен выпустить его. Когда findBarVisible свойство установлено в YES, контейнер должен сделать панель находки видимой. Контейнер должен реализовать findBarViewDidChangeHeight метод, таким образом, это может изменить местоположение панели находки, когда ее высота изменяется, обычно в ответ на пользовательское действие.

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


Найдите поддержку панели в AppKit

В Mac OS 10.7, NSScrollView теперь соответствует NSTextFinderBarContainer для поддержки панели находки для любого представления документа, искавшего NSTextFinder. Панель находки может быть расположена любой выше или ниже представления документа путем присвоения одного из значений перечисления NSScrollViewFindBarPosition к findBarPosition свойству.

NSTextView также теперь поддерживает панель находки. Панель находки может быть включена или отключена на текстовом представлении со следующими методами:
- (BOOL)usesFindBar;
- (void)setUsesFindBar:(BOOL)flag;
Только одним из usesFindBar и usesFindPanel может быть YES за один раз. Если одно значение будет установлено в ДА, то другой будет установлен в НЕТ.


Обратная связь поиска NSTextFinder

Начиная с Mac OS 10.5, NSTextView использовал анимированный индикатор находки, чтобы дать обратную связь пользователю об успешном действии находки. Индикатор находки мог быть активирован вручную на NSTextView через-showFindIndicatorForRange: метод.

Для обеспечения этой функциональности для клиентов NSTextFinder в Mac OS 10.7 NSTextFinder покажет индикатор находки в подходящее время автоматически при выполнении находки. Однако NSTextFinder должен знать, где показать индикатор, и этому нужно что-то для рисования текстового содержания индикатора находки. Во время инкрементного поиска NSTextFinder должен также знать расположения всех видимых соответствий, таким образом, это может выделить их также. Следующие дополнения к протоколу NSTextFinderClient обеспечивают эти возможности.
@protocol NSTextFinderClient
[...]
@optional
/* This method is used when displaying feedback about find operations to the user.
The client should return the view the contains the character at the given index.
It should also return by reference the entire range of the string displayed by
the view.
*/
- (NSView *)contentViewAtIndex:(NSUInteger)index effectiveCharacterRange:(NSRangePointer)outRange;
/* NSTextFinder uses this method to determine the location to display the find
indicator. The client should convert the given content range to an array of
rectangles in the contentView's coordinate system and return that array. The
given range is guaranteed not to overlap multiple views.
*/
- (NSArray *)rectsForCharacterRange:(NSRange)range;
@end
Первый метод вызывают для определения то, что просматривает содержание, выведен на экран в, по которому будет выведен на экран индикатор находки. Так как содержание может потенциально быть распространено по многократным представлениям (как NSLayoutManager, поддерживающий многократный NSTextViews), метод просит представление в данном индексе и полный спектр строки, содержащейся тем представлением.

Во втором методе клиент должен определить и возвратить прямоугольники, в которых содержание с данным диапазоном выведено на экран в его contentView. Данный диапазон, как гарантируют, не охватит многократные представления содержания. Возвращенные прямоугольники говорят NSTextFinder, где соответствующий диапазон найден, таким образом, это может показать индикатор находки там.

Когда contentView будет изменен, перемещен или удален из иерархии представления, NSTextFinder и NSView обработают индикатор находки правильно. Если Ваше представление содержания прокрутка будет сделано NSScrollView, то индикатор находки будет также обработан для Вас во время прокрутки. Вне этих случаев могут быть некоторые обстоятельства, где индикатор находки должен быть сразу отменен и скрыт, такой как тогда, когда содержание или выбор представления изменяются без ведома NSTextFinder. Индикатор находки может быть отменен с cancelFindIndicator методом на упомянутом ниже NSTextFinder. Если Ваш документ не прокручивается NSScrollView, то необходимо установить findIndicatorNeedsUpdate свойство в YES.

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

NSTextFinder вызовет drawCharactersInRange:forContentView: на его клиенте, если реализован метод. Клиент должен тогда нарисовать требуемые символы (или спросить содержание представления символы, который предоставлен как удобство) в источнике текущего контекста. Если требуемый диапазон символов частично пересекает диапазон глифа, клиент может нарисовать весь глиф, при необходимости для производительности.

Если drawCharactersInRange:ForContentView: не реализован, тогда NSTextFinder будет использовать нормальный NSView рисование механизмов. contentView не должен принимать любые дополнительные меры, чтобы заставить это произойти.

Необходимо нарисовать содержание индикатора находки немного по-другому, чем нормальный, чтобы удостовериться, что это читаемо на фоне индикатора находки. Например, вместо того, чтобы составить текст в его исходном цвете, это должно быть черно. Можно узнать, когда находят, что получение индикатора происходит путем проверки drawingFindIndicator свойства.


Инкрементная поисковая поддержка с NSTextFinder

Типичная функция, использованная в сочетании с панелью находки, является инкрементным поиском. Эта функция позволяет пользователям сразу найти соответствия, поскольку они вводят. В Mac OS 10.7, NSTextFinder обеспечивает эту функцию своих клиентов с минимальным дополнительным API.

Инкрементный поиск может быть включен путем установки incrementalSearchingEnabled свойства на NSTextFinder к YES. Одно только это свойство достаточно, чтобы заставить NSTextFinder начинать искать инкрементно.

Для улучшенной скорости отклика, когда документ будет достаточно длинен, NSTextFinder будет искать документ в фоновом режиме. Для обеспечения потокобезопасности клиент, использующий инкрементный поиск, должен вызвать noteClientStringWillChange на его NSTextFinder, прежде чем любые изменения будут внесены в строку, предоставленную NSTextFinder.

Во время инкрементного поиска выделяются все видимые соответствия. NSTextFinder обеспечивает две альтернативы для выделения. Если Ваш клиент реализует visibleCharacterRanges свойство только для чтения, то по умолчанию серое наложение появится по Вашему contentView контейнера панели находки с прозрачными «дырами», отключенными для каждого соответствия. Этот contentView должен быть суперпредставлением всего contentViews, о котором сообщает NSTextFinderClient. NSScrollView уже реализует это свойство, таким образом, только необходимо реализовать это свойство при использовании различного контейнерного класса. Наконец, этот режим также требует тех же двух методов NSTextFinderClient, использующихся для отображения индикатора находки: contentViewAtIndex:effectiveCharacterRange: и rectsForCharacterRange:. Однако реализация этих методов идентична в обеих целях, таким образом, никакая дополнительная работа не требуется, чтобы поддерживать инкрементный поиск.

Для отключения наложения необходимо установить incrementalSearchingShouldDimContentView свойство в НЕТ. Если Вы делаете, можно все еще показать соответствия от инкрементного поиска при помощи incrementalMatchRanges свойства NSTextFinder. Это свойство является массивом диапазонов, указывающих все инкрементные соответствия, найденные до сих пор. В то время как инкрементный поиск выполняется на фоновом потоке, массив обновляется на основном потоке. Когда содержание этого массива изменяется, можно использовать Наблюдение Значения ключа для получения уведомлений. При использовании NSKeyValueObservingOptionNew и NSKeyValueObservingOptionOld словарь, переданный методу уведомления KVO, обеспечит индексы и диапазоны, добавленные или удаленные.

Можно использовать массив incrementalMatchRanges для отображения соответствий, однако, Вы выбираете, но если Вы принимаете решение выделить их в своем представлении, рекомендуется использовать drawIncrementalMatchHighlightInRect: метод для рисования стандартного выделения.


Инкрементная поисковая поддержка в NSTextView

В Mac OS 10.7, NSTextView предоставляет инкрементную поисковую поддержку. Это отключено по умолчанию, но это может быть включено путем установки incrementalSearchingEnabled свойства в YES. Кроме того, так как инкрементный поиск требует, чтобы панель находки, usesFindBar был установлен в YES для инкрементного поиска быть, происходят.


Перетаскивание NSCollectionView задержка щелкать-и-содержать

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


Перетаскивание Мультиизображения NSCollectionView

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

Для поддержки перетаскивания мультиизображения для источника перетаскивания все, что необходимо сделать, реализовать-collectionView:pasteboardWriterForItemAtIndex:. NSCollectionViewItem ответственен за создание компонентов изображения перетаскивания. Можно настроить его поведение по умолчанию путем переопределения-draggingImageComponents. Можно настроить настройки сеанса перетаскивания как draggingFormation или animatesToDraggingFormationOnBeginDrag путем реализации-collectionView:draggingSession:willBeginAtPoint:forItemsAtIndexes:. Вам можно также сообщить при перетаскивании концов путем реализации-collectionView:draggingSession:endedAtPoint:dragOperation:.

Больше работы требуется, чтобы поддерживать перетаскивание мультиизображения для перетаскивания мест назначения. В первую очередь, необходимо удостовериться acceptDrop: метод использует новый основанный на элементе APIs NSPasteboard. Некоторое время после мультиизображения перетаскивает, вводит Ваше представление набора,-collectionView:updateDraggingItemsForDrag: вызывается на делегате. В том методе необходимо перечислить элементы перетаскивания информации перетаскивания и сделать следующее:

1. Отобразите элемент NSDraggingItem на representedObject для Вашего набора.
2. Создайте новый NSCollectionViewItem с представленным объектом. (Элемент представления набора обычно создается путем копирования itemPrototype. Кроме того, можно создать единственный элемент представления набора и повторное использование это для каждого NSDraggingItem.)
3. Определите целевой тип телосложения для элемента и установите тип телосложения NSDraggingItem.
4. Обновите провайдера компонентов изображения NSDraggingItem с помощью кадра от (3) и-draggingImageComponents NSCollectionViewItem (или другой пользовательский код для генерации компонентов изображения).

Расположение подпредставления NSCollectionView зависит от числа элементов, содержавшихся в наборе. Метод-frameForItemAtIndex: основывается на числе элементов, в настоящее время содержавшихся в наборе. Так как операции перетаскивания обычно изменяют число элементов в наборе, необходимо будет, вероятно, использовать новый-frameForItemAtIndex:withNumberOfItems: метод для вычислений надлежащих типов телосложения.

Чтобы заставить перетащенные изображения анимировать их конечным местам назначения, можно установить animatesToDestination свойство draggingInfo в реализации делегатом validateDrop:. Если Вы делаете, необходимо перечислить элементы перетаскивания информации перетаскивания в acceptDrop: и обновите их с их надлежащими кадрами. Обязательно обновите Ваше представление набора или содержание контроллера массива синхронно в acceptDrop: получить надлежащие анимации.



NSDocument, сохраняющийся автоматически на месте – неумышленный браузер редактирований и версий

NSDocument's, «Сохраняющийся автоматически На месте», устраняет в основном ненужную пользовательскую задачу ручного сохранения документов. Однако, когда сохранение происходит без пользовательского ведома, для неумышленных редактирований становится проще быть сохраненным на диск. Чтобы помочь избежать этой проблемы, когда подкласс NSDocument принимает автоматическое сохранение на месте путем возврата YES из +autosavesInPlace, это будет использовать различную эвристику для определения, когда пользователь, возможно, открыл документ с намерением читать, но не отредактировать его. Когда такой файл будет открыт, NSDocument предупредит пользователя, когда редактирование сделано к документу, предложив им выбор отмены изменения, создания нового документа с изменением или разрешения редактирования, если это возможно. Документ, предотвращающий редактирования, выведет на экран «Заблокированный» в правом углу строки заголовка. Если пользователь намеревается отредактировать документ, он может избежать предупреждения путем щелчка по «Заблокированному» тексту и разрешения редактирования путем выбора «Unlock» во всплывающем меню. Документ, измененный, так как он был в последний раз открыт и поэтому активно сохраняется автоматически на месте, покажет «Отредактированный» в строке заголовка вместо «Заблокированного».

Иногда пользователь может принять решение отредактировать файл, затем решить вернуться те изменения позже. В то время как пользователь работает над сохраненным автоматически на месте документ, NSDocument, неоднократно, сохранит текущее содержание документа диску. Пользователь может получить доступ к этим сохраненным версиям путем выбора «Revert to Saved» из меню File, или путем выбора «Browse All Versions …» из меню, доступного в правом углу строки заголовка окна документа. Это приносит пользователю в интерфейс, выводящий на экран и текущий документ и «штабель» предыдущих версий. Если пользователь принимает решение восстановить предыдущую версию, содержание текущего документа сохраняется на диске, при необходимости, и содержание файла заменяется теми из выбранной версии. Путем содержания функциональной клавиши пользователь может также принять решение восстановить копию предыдущей версии, которая не будет влиять на содержание текущего документа. Так как старые версии документа являются живыми окнами, пользователь может также выбрать и скопировать содержание от них и вставить их в текущий документ. Так как интерфейс браузера версии берет под свой контроль весь экран, можно установить пользовательское значение по умолчанию NSDocumentRevisionsDebugMode в YES для более простой отладки приложения в этом интерфейсе.

Mac OS 10.7 включает несколько APIs, чтобы позволить Вашему приложению настраивать свое поведение в браузере версии. В первую очередь, окно, использующееся в браузере версии, определяется-windowForSheet API. Когда пользователь просматривает старые версии документа, можно также хотеть упростить интерфейс приложения. Можно обнаружить, когда сделать это путем проверки-isInViewingMode метода на NSDocument. Это значение установлено в YES перед Вашим, интерфейс загружается для старой версии документа. Если Вы хотите изменить интерфейс текущего документа, когда это вводит или выходит из браузера версии, можно использовать методы NSWindowDelegate,-windowWillEnterVersionBrowser: и-windowDidExitVersionBrowser: или их эквиваленты NSNotification.

Для адаптации двум окнам документа бок о бок, браузер версии может попытаться изменить размеры и/или масштабировать окна. Когда окно уменьшено масштаб, пользователь может щелкнуть по нему для возвращения его полному размеру. Можно управлять размером окна документа в браузере версии путем реализации-window:willResizeForVersionBrowserWithMaxPreferredSize:maxAllowedSize: метод. Возвращенный размер будет использоваться для определения получающегося размера окон документа в браузере версии. Можно возвратить любой размер из этого метода, но тот размер ограничивается к «максимальному позволенному размеру» гарантировать, что средства управления просмотром версии все еще доступны. Если окно будет больше, чем этот размер и не сможет быть изменено, то исключение будет выдано. «Максимальный предпочтительный размер» параметр указывает самый большой размер, которым окно может быть, не требуя масштабирования. Если этот метод не будет реализован, то браузер версии будет использовать-window:willUseStandardFrame: определить получающийся размер рамки окна.


Зависимость файла NSDocument

Когда файл NSDOCUMENT исчезает из файловой системы, документ может обычно продолжать функционировать должным образом и даже позволять пользователю повторно сохранять его, если весь файл был загружен в память. Когда это происходит с файлом, не полностью загруженным, тогда могут произойти неожиданные ошибки. NSDocument имеет новый метод в Mac OS 10.7 вызванных-isEntireFileLoaded, который предназначается для обеспечения явно заданных знаний о зависимости документа от ее файла. NSDocument может использовать эту информацию, чтобы сделать, вещам нравится, предотвращают извлечение объема или предупреждают пользователя, когда частично загруженный файл исчезает из файловой системы.

Базовое внедрение NSDOCUMENT этого метода возвраты ДА, обеспечивая то же поведение по умолчанию как перед Mac OS 10.7. Если Вы переопределяете-readFromURL:ofType:error: или-readFromFileWrapper:ofType:error: и только для чтения часть файла или обертки файла, необходимо переопределить-isEntireFileLoaded и возвратиться НЕТ. Если в некоторый момент весь файл полностью загружается, то можно начать возвращать YES. Точно так же, если части файла удалены из памяти, необходимо начать возвращаться НЕ снова.


NSSplitView восстановимое состояние

Когда приложение запустится, в Mac OS 10.7, NSSplitView будет участвовать в автоматическом восстановлении состояния путем сохранения кадров его подпредставления и восстановления их. Если необходимо, этот процесс вызовет те же методы NSSplitViewDelegate, используемые для ограничения позиций делителя гарантировать надлежащее расположение. По причинам совместимости NSSplitView не будет участвовать в Mac OS 10.7's автоматическое восстановление состояния, если это не будет присвоено имя автосохранения. Можно определить имя автосохранения в Интерфейсном Разработчике, или в коде с помощью-setAutosaveName: метод.




Изменения для изображений @2x

10.7 содержит некоторые изменения для размещения соглашения о присвоении имен iOS для изображений высокого разрешения. Если Ваш пакет будет содержать файлы, названные foo.png, foo@2x .png, и foo.pdf тогда [то NSImage imageNamed:@ «foo»] возвратит NSImage, поддержанный всеми тремя файлами, если Ваше приложение соединяется против 10,7 SDK.

Это выполняет что-то подобное тому, как iOS обрабатывает изображения с высокой разрешающей способностью, но механика немного отличается. На iOS известно при запуске устройства, являются ли изображения @2x надлежащими. На Mac OS X машина могла бы заснуть и проснуться с различным присоединенным экраном. На iOS [UIImage imageNamed:@ «foo»] загружает foo.png, если Вы работаете на iPhone 3Gs, и это загружается foo@2x .png при работе iPhone 4. На Mac [NSImage imageNamed:@ «foo»] безусловно возвращает объект NSImage, содержащий три объекта NSImageRep, один для каждого из foo.png, foo@2x .png, и foo.pdf. Каждый раз, когда NSImage нарисован, он выбирает представление лучше всего для контекста получения.

Это заботится о + [NSImage imageNamed:], но +imageNamed: только находит ресурсы в основном комплекте приложений, не в платформах или плагинах. Авторы платформы обычно делают что-то вроде этого:
  [[NSImage alloc] initByReferencingURL:[pluginBundle URLForImageResource:@"foo"]]
…, который может только взять один из foo.png, foo@2x .png, и foo.pdf, так как URL является явным. Для обеспечения пути вперед мы добавляем один метод шага для получения изображения:
    @interface NSBundle(NSBundleImageExtension)
    - (NSImage *)imageForResource:(NSString *)name NS_AVAILABLE_MAC(10_7);
    @end
Это может возвратить NSImage, поддержанный многократными файлами, и он может также автоматически вызвать setTemplate: в надлежащих случаях согласно шаблону отображают соглашение о присвоении имен, используемое в +imageNamed:.

Несмотря на NSImage, имеющий эту многофайловую поддержку, мы действительно не ожидаем, что Вы будете использовать его очень. Если у Вас есть ресурсы foo.png и foo@2x .png в Ваших ресурсах проекта, XCode собирается прокрутить их вместе в мультипредставление foo.tiff, который содержит обоих во время сборки. NSImage всегда имел поддержку чтения файлов TIFF с представлениями повторного изображения.

Примечание производительности: NSImage имеет лень в инстанцировании изображений. [NSImage imageNamed:] не делает никакого файла IO вообще, если уже кэшируется содержание пакета. Когда Вы рисуете изображение, мы читаем заголовок каждого файла поддержки, чтобы видеть, насколько большой каждый, и выберите лучший, данный контекст получения. Однако мы избегаем декодировать данные изображения для никогда не выбирающегося представления. Если Вы позволяете XCode собрать Ваши изображения в единственный TIFF, существует только один файл, заголовок которого мы должны считать.

Ошибка в осуждаемом - [NSImage составляют …], методы закрепили условное выражение на соединении с 10,7 SDK

Мы не упоминаем каждое исправление ошибки в информации о версии, но мы действительно пытаемся упомянуть каждый раз, когда мы делаем что-то, что имеет условное выражение поведения на SDK, с которым Вы соединяетесь. Я говорю это для объяснения, почему этот довольно сложный раздел здесь. Если Вы не используете осуждаемый - составляют … методы, можно пропустить к следующему разделу.

Для 10,6, мы переписали внутренности NSImage и исправили много ошибок и странностей. Как, часть которого, мы осудили все методы NSImage, запускающиеся с составного объекта, потому что у них есть удивительная семантика по сравнению с методами, запускающимися с получения. Начиная с - составляют композит, … методы осуждались, мы не пытались изменить их поведение и корректные ошибки в местах, где исправления могли бы испортить приложения в зависимости от ошибок.

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

Так, мы исправили ошибку, условное выражение на приложении, или выполняемом в HiDPI или на нем соединяемый против 10,7 SDK или больше.

Ошибка то, что - [NSImage compositeToPoint:fromRect:operation:fraction:] интерпретировал fromRect в координатах NSImageRep, выбранного для рисования с вместо в координатах NSImage.

Признак - то, что вместо целого изображения в корректном размере, Вы видите просто угол, аварийно завершенный, или Вы видите слишком маленькое изображение. Если Вы поражаете это, переключаетесь на один из методов NSImage, запускающихся с - рисуют … (и также фиксируйте fromRect, так как это, вероятно, неправильно).


Авторасположение какао

10.7 представляет новую систему для расположения, переделывая модель пружин и распорок. Настолько большой этому нужна его собственная информация о версии!




NSApplication и уведомления нажатия Apple

NSApplication может зарегистрироваться для получения уведомлений нажатия, подобных UIApplication на iOS. В настоящее время только уведомления значка поддерживаются на Mac OS X для незапущенных приложений. Запущенные приложения могут интерпретировать данные от сервера нажатия, как желаемый.

Для регистрации для получения уведомлений нажатия используйте:
- (void)registerForRemoteNotificationTypes:(NSRemoteNotificationType)types;
Если успешный, делегат приложения получит сообщение об обратном вызове с непрозрачным блобом данных, представляющим маркер, используемый для передачи с сервером Уведомления Нажатия Apple (читайте, документация относительно Требуют у Уведомлений больше подробных данных о том взаимодействии). Если приложение не открыто, когда уведомление нажатия получено, информация об уведомлении поставлена в userInfo словаре для уведомления NSApplicationDidFinishLaunchingNotification с помощью ключа NSApplicationLaunchRemoteNotificationKey. Если приложение открыто, когда уведомление нажатия получено, делегат получает application:didReceiveRemoteNotification: сообщение.


Изменения появления кнопки

Как часть продолжающегося обновления Воды у Льва Mac OS X, некоторые кнопки выглядят по-другому и могут не выглядеть одинаково в каждом контексте в Вашем приложении. В частности кнопка «Round Textured» не является надлежащей ни в каком контексте кроме непосредственно на фоне текстурированного окна. При использовании этого вида кнопки в табличном представлении или другом контексте рассмотрите изменение его к кнопке «Round Rect».



Методы считывания данных NSPasteboard

Задокументированное поведение NSPasteboard исторически потребовало что - типы или-availableTypeFromArray: будьте отправлены в область монтажа прежде, чем вызвать методы считывания данных-dataForType:-propertyListForType: и-stringForType:. Начало в 10.6 (предыдущий выпуск Mac OS X), вызов этих методов считывания данных выполняют неявную проверку на требуемый тип прежде, чем попытаться считать данные, делание его больше строго потребовало для вызова - типы или-availableTypeFromArray: прежде, чем вызвать методы считывания данных.

NSPasteboard UTI и менеджер/Перетаскивать по Фрагменту Функциональная совместимость менеджера

Поскольку приложения двигают использование UTIs с NSPasteboard, в противоположность типам pboard, приложение, возможно, все еще должно взаимодействовать с существующими приложениями, использующими четыре типа символа OS с устаревшим менеджером по Фрагменту и Перетаскивающими менеджера.

Для взаимодействия с этими устаревшими типами используйте функции, которые, как объявляют в UTTypes.h, генерировали надлежащую строку UTI для данного OSType. Код ниже генерирует надлежащий UTI от вымышленного типа OS 'тест':
CFStringRef flavorString = UTCreateStringForOSType('test');
CFStringRef conformsToType =  (floor(NSAppKitVersionNumber) <=  NSAppKitVersionNumber10_5) ? NULL : kUTTypeData;
CFStringRef utiForConvertedScrapFlavor = UTTypeCreatePreferredIdentifierForTag(kUTTagClassOSType, flavorString, conformsToType);
// Use the utiForConvertedScrapFlavor
CFRelease(flavorString);
CFRelease(utiForConvertedScrapFlavor);
Используя сгенерированный UTI, чтобы читать и записать данные области монтажа позволяет Вашему приложению взаимодействовать с устаревшим менеджером по Фрагменту и Перетаскивать клиенты менеджера.

Две вещи отметить о примере кода:

1. Проверка версии AppKit требуется из-за изменения в поведении между 10,5 и 10.6. Весь UTIs, используемый на области монтажа, должен соответствовать kUTTypeData, но в 10.5 UTIs, сгенерированных внутренне NSPasteboard, не сделал. Это адресовалось в 10,6. Проверка версии гарантирует, что строка UTI, сгенерированная в Вашем коде, будет соответствовать UTI, который появится на области монтажа для того выпуска. Если Ваше приложение поставит только на 10,6 и позже, можно удалить проверку версии и использовать kUTTypeData в качестве последнего параметра UTTypeCreatePreferredIdentifierForTag ().

2. Всегда генерируйте UTI динамично от OSType. Не храните или кэшируйте строку UTI между запусками приложения. Это гарантирует, что Ваш код области монтажа продолжает работать, даже если разработчик унаследованного приложения выпускает новую версию позднее, формально отображающую устаревший OSType на заявленную строку UTI, или если алгоритм для генерации динамического UTIs изменяется в будущей версии ОС.



Дополнительные добавленные исключения NSPasteboard

NSPasteboard и NSPasteboardItem имеют методы для установки NSData, NSString и значений списка свойств. Классы, реализующие протокол NSPasteboardWriting также, обеспечивают значения списка свойств. До 10,7, устанавливая или обеспечивая объект неправильного класса или недопустимые списки свойств, перестал бы работать тихо. Для приложений, соединенных на или после 10.7, эта программная ошибка теперь заставляет исключение быть повышенным.



Доступность

Когда клиент доступности устанавливает AXSelectedRows и AXSelectedColumns NSTableView, поведение теперь правильно зеркально отражает пользовательский выбор строк и столбцов, включая вызов надлежащих методов делегата, таких как-tableView:tableViewselectionIndexesForProposedSelection:.

Когда ее подэлементы не видимы, NSScroller больше не сообщает о дочерних элементах доступности.

NSSecureTextField теперь сообщает о своей Caps Lock и индикаторах Num Lock как дочерние элементы доступности AXImage, если они видимы.

Когда его измерительные модули изменяются, NSRulerView теперь отправляет NSAccessibilityUnitsChangedNotification.

Доступность основанного на представлении NSTableView и NSOutlineView

Mac OS X 10.7 добавляет поддержку использования NSViews вместо NSCells для определения содержания представлений схемы и таблицы. Просмотрите базируемую таблицу и обрисуйте в общих чертах представления, автоматически обеспечивают более богатое и больше полного представления доступности. Это вызвано тем, что интерфейсы сложной таблицы могут теперь быть представлены как состав стандартных представлений AppKit и средств управления, таких как текстовые поля и представления изображения, вместо пользовательских подклассов ячейки. Это позволяет основанной на представлении таблице или схеме использовать в своих интересах встроенную доступность представлений AppKit и средств управления, устраняя необходимость пользовательского кода доступности для поддержки сложных подклассов ячейки.

Об основанных на представлении табличных представлениях сообщают доступности как использующий AXCells в качестве дочерних элементов его строк. (Несмотря на подобную терминологию, AXCell не имеет никакого отношения к NSCell). Это означает, что изменение существующего табличного представления или представления схемы для представления потребует, чтобы находящиеся в AppleScript или основанные на AX сценарии автоматизации пользовательского интерфейса были обновлены для обработки новой структуры.

Доступность и представления ячейки таблицы

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

Если Вы используете представление ячейки таблицы, которое не является подклассом NSTableCellView, добавляя выход 'текстового поля', и свойство строго рекомендуется. AppKit обрабатывает 'текстовое поле' как специальный ключ для любого представления ячейки таблицы и сообщает о значении того свойства как заголовок элемент UI ячейки таблицы.

Изменения в поведении NSAccessibilityPostNotification ()

В 10.7 NSAccessibilityPostNotification () проверяет на клиентских наблюдателей доступности по-другому в зависимости от уведомления. См. NSAccessibility.h для подробного описания изменений поведения.

Доступность NSPopover

Легкая сдоба вывела на экран использование нового класса NSPopover, сообщают себя клиентам доступности, использующим новый NSAccessibilityPopoverRole, постоянный в NSAccessibility.h.

Родитель доступности легкой сдобы является элементом пользовательского интерфейса, от которого появилась легкая сдоба. Поскольку подкласс NSView может иметь подэлементы доступности, AppKit использует эвристику для определения корректного родителя доступности для легкой сдобы, обрабатывая тот элемент как родителя легкой сдобы, и временно делая легкую сдобу дочерним элементом того элемента, в то время как легкая сдоба видима.

Если необходимо переопределить присвоение AppKit по умолчанию родителя доступности легкой сдобы, переопределите-accessibilityAttributeValue: в подклассе NSPopover для возврата различного объекта, реализующего NSAccessibility.

Доступность и автоматическое завершение

Для всех приложений AppKit:
После того, как клиент доступности, такой как VoiceOver, выполнил запрос доступности к приложению, автоматическое завершение будет отключено для того приложения, чтобы гарантировать, что клиенты доступности могут продолжать получать доступ к тому же порядку подачи заявки. Поскольку клиенты доступности, такие как Сценарии GUI также используются для автоматизированного тестирования во время разработки приложений, устанавливая пользовательское значение по умолчанию, NSDisableAutomaticTerminationAfterAccessibilityRequest к НЕ переопределит поведение по умолчанию так, чтобы эти автоматизированные тесты могли быть запущены, автоматически не отключая автоматическое завершение.

Для вспомогательных приложений только:
Если Ваше приложение является клиентом доступности (т.е. те, которые используют AX APIs, который, как находят в платформе HIServices, взаимодействовал с другими приложениями), необходимо рассмотреть, как приложение использует AX APIs, планируя включить Автоматическое Завершение в приложении. Например, если Ваше приложение должно реагировать на уведомления доступности, даже когда оно скрыто, необходимо отключить автоматическое завершение. С другой стороны, если Ваша информация об отображениях приложения об элементе UI под мышью, но не выполняет запросы доступности, когда скрытый, использование AX, APIs не препятствовал бы тому, чтобы Вы включили автоматическое завершение. Дополнительную информацию см. в документации относительно самого Автоматического Завершения.

Доступность и скроллеры наложения

Скроллер наложения сообщает, что атрибут AXHidden указывает, скрыто ли это в настоящее время или видимо. Этот атрибут устанавливаем. Вспомогательное приложение может установить это значение в 'НЕТ' для создания скроллера видимым временно. Обратите внимание на то, что 'НЕТ' является единственным допустимым значением, видимые скроллеры не могут быть вынуждены быть скрытыми со значением 'YES'.



Нажимать-и-содержать для определенных ключей

Новое поведение в масштабе всей системы было реализовано для случаев, в которых пользователь нажимает и удерживает определенные клавиши при редактировании текста. Вместо того, чтобы повторить ключ, это новое поведение обеспечивает механизм для ввода альтернативы (обычно акцентируемый) формы. UI появляется около текста, показывающего эти альтернативные формы, которые могут быть выбраны путем щелчка arrowing, или путем нажатия цифры, соответствующей индексу желаемой формы. Ключи кроме буквы и ключи цифры продолжают повторяться, когда нажато и сохранено.

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


Дополнительный API для автоисправления

Существует новый API на NSSpellChecker для поддержки автоисправления. Во-первых, существует теперь удобный метод, предоставляющий отдельный доступ к результатам исправления, которые иначе были доступны только через объединенные текстовые методы проверки checkString:range:types:options:inSpellDocumentWithTag:orthography:wordCount: и requestCheckingOfString:range:types:options:inSpellDocumentWithTag:completionHandler:.
- (NSString *)correctionForWordRange:(NSRange)range
inString:(NSString *)string
language:(NSString *)language
inSpellDocumentWithTag:(NSInteger)tag;
Во-вторых, существует теперь API, чтобы позволить клиентам сообщать об ответе пользователя на предложенное исправление, так, чтобы программа проверки правописания могла извлечь уроки из этого и скорректировать будущее поведение исправления соответственно. Это используется представлениями, такими как NSTextView и веб-представление и третьи лица, реализующие их собственные представления редактирования текста, что автоисправление поддержки может использовать его также. Тег, язык, слово и исправление должны соответствовать тем от исходного результата исправления, так, чтобы программа проверки правописания могла соответствовать им. Это подразумевает, что для записи ответов должным образом, клиенты должны сохранить оригинальное слово и исходное исправление, по крайней мере, от точки, в которой пользователь принимает его, пока пользователь не редактирует или возвращается он.
enum {
NSCorrectionResponseNone, // No response was received from the user
NSCorrectionResponseAccepted, // The user accepted the correction
NSCorrectionResponseRejected, // The user rejected the correction
NSCorrectionResponseIgnored, // The user continued in such a way as to ignore the correction
NSCorrectionResponseEdited, // After the correction was accepted, the user edited the
// corrected word (to something other than its original form)
NSCorrectionResponseReverted // After the correction was accepted, the user reverted the
// correction back to the original word
};
typedef NSInteger NSCorrectionResponse;
- (void)recordResponse:(NSCorrectionResponse)response
toCorrection:(NSString *)correction
forWord:(NSString *)word
language:(NSString *)language
inSpellDocumentWithTag:(NSInteger)tag;
В-третьих, существует теперь API, чтобы позволить клиентам переводить новый UI в рабочее состояние для автоисправления. Это также используется представлениями, такими как NSTextView и веб-представление и третьи лица, реализующие их собственные представления редактирования текста, что автоисправление поддержки может использовать его также. Этот пользовательский интерфейс используется, чтобы указать, что исправление намеревалось быть сделанным, позволяя пользователю принять или отклонить его; или как только исправление было сделано, для указания исходной формы, позволив пользователю вернуться назад к нему; или вывести на экран многократные альтернативы, из которых пользователь может выбрать тот при желании. primaryString является первой выведенной на экран строкой, исправление или реверсия согласно типу индикатора; alternativeStrings должен быть дополнительными альтернативами при наличии. Только один индикатор за один раз может быть выведен на экран для высказанного мнения и единственной вещи, которую клиент может сделать с индикатором после отображения, это должно отклонить его. Когда индикатор отклонен, вызовут ли пользовательским действием или представлением, блок завершения с acceptedString параметром, являющимся или замещающей строкой, принятой пользователем или нолем, если пользователь не принял замену.
enum {
NSCorrectionIndicatorTypeDefault = 0, // The default indicator shows a proposed correction
NSCorrectionIndicatorTypeReversion, // Used to offer to revert to the original form after a correction has been made
NSCorrectionIndicatorTypeGuesses // Shows multiple alternatives from which the user may choose
};
typedef NSInteger NSCorrectionIndicatorType;
- (void)showCorrectionIndicatorOfType:(NSCorrectionIndicatorType)type
primaryString:(NSString *)primaryString
alternativeStrings:(NSArray *)alternativeStrings
forStringInRect:(NSRect)rectOfTypedString
view:(NSView *)view
completionHandler:(void (^)(NSString *acceptedString))completionBlock;
- (void)dismissCorrectionIndicatorForView:(NSView *)view;
Наконец, существует дополнительный API для поддержки новых предпочтительных настроек глобального пользователя для автоматической текстовой замены и исправления орфографических ошибок. NSTextView теперь по умолчанию будет отслеживать и следовать за этими настройками автоматически, но использование приложений NSTextView может переопределить это, программно используя существующие методы NSTextView, такие как-setAutomaticTextReplacementEnabled: и-setAutomaticSpellingCorrectionEnabled: управлять отдельным текстом настройки представления. Новый API прежде всего для нетекстовых клиентов представления, хотящих отслеживать настройки для себя, с помощью методов класса NSSpellChecker определить их значения, и дополнительно также уведомления для определения, когда изменились настройки.
+ (BOOL)isAutomaticTextReplacementEnabled;
+ (BOOL)isAutomaticSpellingCorrectionEnabled;
NSString * const NSSpellCheckerDidChangeAutomaticSpellingCorrectionNotification;
NSString * const NSSpellCheckerDidChangeAutomaticTextReplacementNotification;

Текстовая проверка регулярного выражения

Существует дополнительный ключ, NSTextCheckingRegularExpressionsKey, чтобы использоваться в словаре опций с объединенными текстовыми методами проверки checkString:range:types:options:inSpellDocumentWithTag:orthography:wordCount: и requestCheckingOfString:range:types:options:inSpellDocumentWithTag:completionHandler:. Этот ключ позволяет клиентам указывать ряд регулярных выражений, которые будут разыскиваться во время текстовой проверки. О результатах сообщат с помощью NSTextCheckingResults типа NSTextCheckingTypeRegularExpression. Нет никаких действий по умолчанию, предоставленных в ответ на эти результаты, но клиенты могут таким образом обнаружить возникновение определенных регулярных выражений в тексте несколько тем же способом, Детекторы Данных в настоящее время обнаруживающим адреса, телефонные номера, и т.д., и примите любые желаемые меры в ответ.



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

Установка таблиц/Основ как исходный список (идентифицированный selectionHighlightStyle NSTableViewSelectionHighlightStyleSourceList) на 10,7 и выше теперь только позволит перетаскиванию начинаться с «содержания» в ячейках. Это определяется при помощи методов NSCell hitTestForEvent:inRect:ofView: и возврат NSCellHitContentArea.

Начиная с Leopard NSTableView поддерживал полные ячейки ширины (которые охватывают все столбцы) путем возврата ячейки из tableView:dataCellForTableColumn:row: когда 'ноль' tableColumn передается в. Когда пользователь щелкнул правой кнопкой по строке, вплоть до Льва NSTableView неправильно передал бы ненулевое значение tableColumn параметру. Это было фиксировано для связанных приложений Льва, но предшествующие приложения должны будут работать вокруг этого путем возврата надлежащей ячейки даже при том, что столбец был передан tableView:dataCellForTableColumn:row: метод.

В 10,7 и более высокие таблицы, поддерживающие переменные высоты строки теперь, имеют значения высоты строки, возвращенные из-tableView:heightOfRow: кэшируемый NSTableView/NSOutlineView до noteHeightOfRowsWithIndexesChanged: (или reloadData), вызывается. Приложения, предназначающиеся 10.6 или более низкая потребность гарантировать реализацию всегда, возвращают то же значение для той же строки (как это можно вызвать многократно для той же строки), до noteHeightOfRowsWithIndexesChanged: / reloadData вызывают.

При разрешении выбора столбца ([tableView setAllowsColumnSelection:YES]), объединенный ни с «одним», стиль выделения выбора (NSTableViewSelectionHighlightStyleNone) ранее вызвал бы катастрофический отказ при выборе строки после выбора столбца. Это было фиксировано для приложений, соединяющихся на 10,7 или выше. Приложения, предназначающиеся 10.6 или ниже, должны выключить выбор столбца с [tableView setAllowsColumnSelection:NO].

Вызов [tableView setSelectionHighlightStyle:NSTableViewSelectionHighlightStyleSourceList] будет иметь побочный эффект изменения backgroundColor к стандартному «исходному цвету» списка и установки draggingDestinationStyle, чтобы быть NSTableViewDraggingDestinationFeedbackStyleSourceList. Это позволяет тому легко устанавливать «исходный список», разрабатывают NSTableView или NSOutlineView. Поскольку приложения соединились меньше на OS ниже, чем 10,7, вызывание setSelectionHighlightStyle к чему-либо еще изменит backgroundColor на [NSColor controlBackgroundColor] и draggingDestinationStyle к NSTableViewDraggingDestinationFeedbackStyleRegular. Если предыдущий стиль был исходным списком, 10.7 теперь правильно только делает это изменение.

NSTableView теперь имеет новое rowSizeStyle свойство. Это в основном для списков боковых панелей/источника для определения непротиворечивого расположения Инструкциями по Интерфейсу пользователя. Установка rowSizeStyle к NSTableViewRowSizeStyleCustom заставляет таблицу вести себя, как это всегда имеет. Для любого другого значения таблица автоматически изменит-rowHeight на основе различных вариантов; например, строки группы могут иметь меньшую высоту строки, чем строки негруппы. Когда rowSizeStyle не будет NSTableViewRowSizeStyleCustom,-rowHeight возвратит стандартную высоту строки для строк негруппы. Переменные высоты строки могут все еще использоваться; рекомендуется возвратить-rowHeight, когда высота по умолчанию необходима, но строки группы потребуют, чтобы пользовательская определенная высота строки была возвращена (т.е.: 20). Представление Основанный TableViews должен использовать NSTableCellView - это будет автоматически расположение текстовое поле и imageView на основе текущего rowSizeStyle, и применять надлежащую «боковую панель / исходный список» приписывает stringValue текстового поля и изображению imageView.

NSTableView / NSOutlineView - Представление Основанный TableView и Анимации

NSTableView и NSOutlineView в Mac OS 10.7 теперь поддерживают использование NSViews вместо NSCells. Поиск «Представления, Основанного» в NSTableView.h, NSOutlineView.h для получения дополнительной информации, и, видит: NSTableRowView.h и NSTableCellView.h.

NSTableView и NSOutlineView теперь имеют методы для вставки строк и элементов, дополнительно с анимацией. Эта работа методов и для «Ячейки Основанное» и для «Представление, Основанный» NSTableView/NSOutlineView, однако, «Ячейка, Основанная» версия должна всегда вызывать-beginUpdates прежде, чем сделать любого, вставляют/удаляют/перемещают вызовы, и затем заканчиваются-endUpdates. Это позволяет NSTableView получать текущее состояние для выполнения анимаций. Вы не должны вносить изменения в свою модель, пока-beginUpdates не вызвал, и необходимо обновить модель, прежде чем вызовут-endUpdates.

NSTextFields в Представлении Основанный TableView можно было изменить-backgroundColor автоматически при редактировании. В частности, если NSTextField не будет ограничен (isBordered == НИКАКОЙ && isBezeled == НЕ) и не нарисует фон (drawsBackground == НЕ), то NSTableView автоматически заставит-backgroundColor быть белым, и установить, чтобы быть нарисованным, когда это отредактирует (т.е.: когда это - firstResponder). Это помогает обеспечить опыт Представления заполненной таблицы для конечного пользователя.

Если gridStyleMask установили NSTableViewSolidHorizontalGridLineMask, NSTableRowView ответственен за рисование нижней строки сетки по горизонтали. Это произойдет автоматически. Однако TableView рисует любые линии сетки ниже последней строки с drawGridInClipRect:. Разделение на подклассы drawGridInClipRect: все еще приемлемые строки, но сетки по горизонтали, должен только быть нарисован мимо последней строки. Строки сетки по вертикали в настоящее время не настраиваемы.

Обратите внимание на то, что Представление Основанный TableView не поддерживает выбор столбца.

Представление Основанные поддержки NSTableView, анимирующие изменения выбора. Это может быть сделано с помощью прокси аниматора и вызвав-selectRowIndexes:byExtendingSelection: такие как: [[аниматор tableView] selectRowIndexes:indexes byExtendingSelection:NO];

NSTableView теперь реализует-cancelOperation: позволить Escape автоматически отменять редактирование текста. Это выполняется путем вызова-abortEditing на NSControl, показывающем текущему полевому редактору. Это действие может быть настроено путем переопределения-cancelOperation: на NSTableView или переопределяющий-abortEditing на управлении, существующем в Представлении Основанный TableView.

Для отключения анимаций создайте группу анимации вокруг кода, для которого Вы хотите, чтобы они были отключены, и устанавливаете продолжительность в 0. IE:
[NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:0];
...
[NSAnimationContext endGrouping];

Синхронизация анимаций с NSTableView

Следующие методы NSTableView могут анимировать:
- (void)insertRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)animationOptions;
- (void)removeRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)animationOptions;
- (void)moveRowAtIndex:(NSInteger)oldIndex toIndex:(NSInteger)newIndex;
- (void)noteHeightOfRowsWithIndexesChanged:(NSIndexSet *)indexSet; // View-based tableview only
Может быть потребность синхронизировать анимации, происходящие в представлении, или с другими вещами за пределами Таблицы. Это может быть сделано путем окружения вызовов с определенным NSAnimationContext, группирующимся, которому уже установили определенную продолжительность. Посмотрите демонстрационное приложение TableViewPlayground для примера. Кроме того, если продолжительность будет 0, то никакая анимация не произойдет.

NSTableView / Перетаскивание Мультиизображения NSOutlineView

NSTableView и NSOutlineView теперь поддерживают перетаскивание мультиизображения. Методы NSOutlineView зеркально отражают NSTableView, но используют 'элемент' вместо этого или 'строку. Существует два компонента к перетаскиванию; будучи источником перетаскивания и местом назначения перетаскивания.

Для источника перетаскивания источник данных должен реализовать tableView:pasteboardWriterForRow: и возвратите объект, реализующий NSPasteboardWriting. Это - все, что требуется, чтобы быть источником. Однако рычаги источника данных также предусмотрены, когда сеанс перетаскивания начинается (tableView:draggingSession:willBeginAtPoint:forRowIndexes:) и концы (tableView:draggingSession:endedAtPoint:operation:). Управлять изображением перетаскивания, метод NSCell draggingImageComponentsWithFrame:inView: вызывается на ячейке, по которой щелкают. Для Представления Основанный TableViews draggingImageComponents NSTableCellView должен использоваться и может быть переопределен для настройки изображения перетаскивания.

Реализация по умолчанию draggingImageComponentsWithFrame:inView NSCELL: генерирует изображение от ячейки и возвратит два компонента: один для NSDraggingImageComponentLabelKey и другого для NSDraggingImageComponentIconKey. Это сделано путем получения части от titleRectForBounds: и imageRectForBounds: соответственно.
Примечание: NSCell в настоящее время имеет проблему, куда он возвратит пустой массив из draggingImageComponentsWithFrame:inView: если ячейка не имеет части изображения. Для работы вокруг этого разделите NSCell на подклассы и переопределите draggingImageComponentsWithFrame:inView: и генерируйте свой собственный NSDraggingImageComponents в возвращенном массиве.

Чтобы быть местом назначения перетаскивания, больше работы требуется, чем быть источником. Реализация tableView:updateDraggingItemsForDrag: для обеспечения перетаскивания отображают представление для исходного содержания, перетащенного по tableView. Обычно это включает использование шаблона NSCell и вызов нового метода NSCell draggingImageComponentsWithFrame:inView:. Для Представления Основанный TableViews должен использоваться draggingImageComponents NSTableCellView. tableView:validateDrop:proposedRow:proposedDropOperation: должен быть реализован как нормальный. В tableView:acceptDrop:row:dropOperation нужно перечислить классы NSDraggingInfo и создать новые объекты модели. Таблица должна быть сказана об изменениях путем выполнения insertRowsAtIndexes:withAnimation: использование параметра анимации NSTableViewAnimationEffectGap для создания разрыва для перетащенного изображения. draggingFrame NSDraggingItem должен быть обновлен к надлежащему-frameOfCellAtColumn:row:.

Посмотрите DragNDropOutlineView (базируемая ячейка) и TableViewPlayGround (базируемое представление) примеры для получения дополнительной информации.

Реализация исходных списков боковой панели с NSOutlineView

Надлежащий способ создать исходную боковую панель списка состоит в том, чтобы использовать NSOutlineView. rowSizeStyle должен быть установлен в NSTableViewRowSizeStyleDefault, и должны быть протестированы все три размера. Элементам, которые не должны быть расширяемыми или разборными пользователем, можно было скрыть ячейку схемы при помощи метода делегата outlineView:shouldShowOutlineCellForItem:. Эти элементы должны быть программно расширены. Элементы заголовка группы создаются при помощи метода делегата outlineView:isGroupItem: и возврат YES. Для обнаружения, что использует rowSizeStyle система можно вызвать [tableView setRowSizeStyle:NSTableViewRowSizeStyleDefault] и затем считать текущую стоимость с: [tableView effectiveRowSizeStyle]. Это возвратит NSTableViewRowSizeStyleSmall, NSTableViewRowSizeStyleMedium или NSTableViewRowSizeStyleLarge как на основе того, что пользователь установил в Установках системы. Нет никакого прямого способа знать размер изображения для значков. Если Вы будете использовать NSTableCellView в Представлении Основанный NSOutlineView, то ячейка автоматически будет установкой с корректными размерами, когда будет установлен rowSizeStyle. Если это не достаточно, то можно сделать предположение для следующих размеров: NSTableViewRowSizeStyleSmall = 16x16, NSTableViewRowSizeStyleMedium = 18x18, и NSTableViewRowSizeStyleLarge=32x32.

Для Ячейки Основанный TableViews набор по умолчанию атрибутов будет применен к stringValue ячейки создание пользовательского attributedStringValue на основе Инструкций по Интерфейсу пользователя. Это сделано прежде, чем вызвать-willDisplayCell, так в целом, рекомендуется не изменить цвет текста или шрифт ячейки в-willDisplayCell:. В Leopard и SnowLeopard, атрибуты были только применены к ячейкам заголовка группы. Для приложений, соединенных на Льве и позже, пользовательские атрибуты будут также применены ко всем другим ячейкам (в частности, падающая тень на 1 пиксель). Для приложений, хотящих этого предварительного льва функции, они могут использовать-willDisplayCell для настройки-attributedStringValue, как желаемый.

Для Представления Основанный TableViews плоскость NSTextField (как установка в Интерфейсном Разработчике XCode) должен быть возвращен для элементов заголовка. Или, альтернативно NSTableCellView может использоваться с - свойство текстового поля должным образом устанавливает к основному NSTextField. Текст должен быть установлен в прописную строку, но не должны быть применены никакие атрибуты; они будут автоматически применены NSOutlineView. Все другие строки должны использовать NSTableCellView, которому сделают надлежащее расположение на основе набора-rowSizeStyle к нему. Кроме того, - свойство текстового поля будет автоматически иметь атрибуты, применился к нему по мере необходимости. В целом исходные списки не должны пускать в ход строки группы, и [обрисовывают в общих чертах setFloatsGroupRows:NO], должен быть вызван.

Чтобы добавить вспомогательное представление к NSTableCellView, находящемуся в исходном списке боковой панели, необходимо будет разделить NSTableCellView на подклассы и выполнить расположение дополнительных представлений в-viewWillDraw. Сначала вызовите [супер viewWillDraw] для имения стандартного расположения текста и выполняемого изображения.

Для создания непрочитанного индикатора или вспомогательный кнопка используйте NSButton (или NSButtonCell) с набором bezelStyle к NSInlineBezelStyle. Этот стиль внешней панели создает встроенное специальное предложение, ищут таблицы. Когда используется в исходном списке, этому применились к надлежащим атрибутам цвета это для появления как непрочитанный индикатор (или окрашенная кнопка). Это будет вести себя как кнопка, только если поставлена цель; иначе, это может использоваться в качестве статического непрочитанного индикатора.-cellSizeForBounds: если ячейка имеет текст, должным образом реализует минимальный размер, требуемый для непрочитанного индикатора. Если ячейка будет иметь изображение, то она примет значение по умолчанию к круговому размеру.

До Льва исходный цвет фона списка был особым цветом, варьировавшимся в зависимости от ключевого состояния окна. На Льве это - теперь градиент.

Отладка NSTableView

Чтобы помочь отладить общие вопросы, можно сделать, чтобы NSTableRowView показал номера строк путем запуска приложения с «-NSTableRowViewShowRows YES» в качестве параметра. Кроме того, это также работает в «Ячейке Основанный» TableView.

Отладка представления основанные изменения NSOutlineView

Чтобы помочь отладить ошибки в вызовах для вставки в NSOutlineView запустите приложение с «-NSOutlineViewValidateChanges YES». Это выполняет некоторую проверку для обеспечения, вставляет/удаляет/перемещает соответствие, что возвратит источник данных. Обратите внимание на то, что это должно только быть включено для тестирования/отладки и вызовет замедление для всех, вставляет/удаляет/перемещает в NSOutlineView. Каждая проверка, окажется, после каждого вызова вставит/удалит или переместится (это НЕ произойдет в конце пакетных обновлений, вызванных в блоке beginUpdates/endUpdates). Об ошибках сообщат путем выдачи исключения.

NSApplication

AppKit теперь имеет возможность сообщить о неперехваченных исключениях. Этим управляет пользовательское значение по умолчанию: NSApplicationShowExceptions (YES/НЕТ). Значение поставки значения по умолчанию НЕТ. В целом это, рекомендуют, чтобы разработчики установили его в YES во время разработки для ловли программных ошибок. Отдельные приложения могут автоматически включить это при помощи [[NSUserDefaults standardUserDefaults] registerDefaults:...] для регистрации опции на. Это может быть установлено со значениями по умолчанию через: 'значения по умолчанию пишут com.yourdomain.app NSApplicationShowExceptions YES'. Это может также глобально быть включено путем записи в глобальный домен.

NSOpenPanel / NSSavePanel

Используя новый метод-beginWithCompletionHandler: в 10,6 требует, чтобы Вы сначала сохранили панель сохранения (или ссылаться на него в блоке обработчика завершения, неявно сохраняющем его). Иначе, панель кратко покажет и затем правильно будет автовыпущена. Для приложений, соединенных на 10,7 и позже, была решена эта проблема, и приложения больше не должны будут явно сохранять панель.

Для приложений, соединенных на 10,7 и выше, URLS, продаваемый от NSSavePanel, может теперь содержать схемы нефайла (т.е.: что-то другое, чем NSURLFileScheme). Это произойдет, если у них не будет физического файла поддержки, такого как вещи в разделе SHARED. Для совместимости, определенные методы делегата (такие как panel:shouldEnableURL:) будет только вызван с нефайлом URLs, и весь другой URLs будет автоматически включен. Рекомендуется, чтобы делегат всегда включил нефайлу URLs, если не желаемо некоторое другое поведение.

NSSavePanel и NSOpenPanel имеют обновленный, надеются соответствовать Средство поиска. Этот взгляд содержит четыре опции представления (включает поток покрытия и опции группы), в то время как классический взгляд имеет только три опции представления и никакой поток покрытия. Углерод базировался, приложения будут всегда использовать классическую опцию. Если у Вас есть приложение, отказывающее в открытую, или сохраните панель, можно выбрать она из использования нового взгляда с пользовательским значением по умолчанию: NSSavePanelUseFinderKit НЕТ. Зарегистрируйте ошибки, сообщив о любых проблемах, с которыми встречаются.

В Автоматических приложениях Сохранения, закрывая все же несохраненное окно документа переводит объединенное в рабочее состояние, предупреждают/сохраняют панель. Так как эта панель включает и кнопку «Do not Save» и файловый браузер, неоднозначность создается для сочетания клавиш cmd-d, который может обозначать и, «не Сохраняют» и «Рабочий стол». Чтобы удостовериться, что пользователи непреднамеренно не теряют свои несохраненные документы, мы приняли решение пойти с «Рабочим столом» для cmd-d и переключились на использование, cmd-удаляют для, «не Сохраняют». Этот новый ярлык должен также работать в большинстве не Автоматические приложения Сохранения.


NSPopover

AppKit теперь имеет новый класс для представления легкой сдобы. Заголовок содержит много из сам документация.

Методы делегата NSPopover

Когда легкая сдоба закрывается, и с делегатом нужно консультироваться, следующая последовательность событий происходит. Во-первых,-popoverShouldClose: метод будет вызван на делегата, если реализовано. Если делегат возвратится то нет, легкая сдоба не будет закрыта. Иначе, если экземпляр легкой сдобы реализует-popoverShouldClose: тот метод будет вызван на экземпляр легкой сдобы и если метод возвратится то нет, легкая сдоба не будет закрыта.

Вследствие ошибки в NSPopover, однако, реализовывая-popoverShouldClose: на экземпляре NSPopover не будет вести себя как ожидалось. Рекомендуется что на данный момент-popoverShouldClose: не должен быть реализован на экземпляре легкой сдобы.

Кроме того,-popoverShouldClose: когда легкая сдоба отсоединяется к окну, в настоящее время неправильно вызывается на делегата легкой сдобы и экземпляр, если реализовано. Вы никогда не должны возвращаться НЕ в этом случае.

Привязка NSPopover

Ошибка в AppKit препятствует тому, чтобы привязка NSPopover работала в первоначальной версии 10,7.


NSButtonCell - Новый стиль внешней панели

NSButtonCell имеет новый стиль внешней панели: NSInlineBezelStyle. Этот стиль внешней панели создает встроенное специальное предложение, ищут таблицы и списки, но может использоваться в любом надлежащем расположении. Когда используется в исходном табличном представлении списка, этому применятся к автоматическим атрибутам цвета это для появления как непрочитанный индикатор (или окрашенная кнопка). Заставить кнопку появиться как метка (т.е.: не реагируют на щелчки), вызовите [buttonCell setHighlightsBy:0].-cellSizeForBounds: если ячейка имеет текст, должным образом реализует минимальный размер, требуемый для непрочитанного индикатора. Если ячейка будет иметь изображение, то она примет значение по умолчанию к круговому размеру.

NSWindow - Приказывающие уйти дочерние окна

Для приложений, соединенных на 10,7 и позже, упорядочивая дочернее окно, теперь сначала удалит себя из его родительского окна. Ранее, упорядочивание дочернего окна неявно упорядочило бы родительское окно также.



NSColor

NSColor теперь имеет два метода класса позволить создать цвета с sRGB или его серыми цветовыми пространствами дубликата. Они создают цвета с colorSpaceName = NSCustomColorSpace и надлежащее цветовое пространство (+ [NSColorSpace sRGBColorSpace] или + [NSColorSpace genericGamma22GrayColorSpace]).

Теперь sRGB цветовое пространство является лучшим соответствием к среде дисплея Mac по умолчанию, чем калиброванное цветовое пространство. Поэтому в целом мы рекомендуем использовать sRGB цветовое пространство для Ваших изображений и в Ваших цветах — это может привести к лучшей точности и производительности.

В NSColor существует изменение в обработке отдельных методов доступа компонента, таких как redComponent и т.д. В 10,6 и ранее, они определяются для работы только над, раскрашивает именованные цветовые пространства NSCalibratedRGB и NSDeviceRGB. (То же для средств доступа компонента в серых цветовых пространствах и цветовых пространствах CMYK.)

В 10,7, эти средства доступа компонента работают над любым пользовательским цветом цветового пространства, имеющим надлежащую базовую модель цветового пространства. Таким образом, например, это означает, что законно отправить-redComponent в цвет, создаваемый с новым sRGB создание метода.

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


NSColorSpace

Метод инициализации initWithColorSyncProfile: теперь принимает ColorSyncProfileRef, а также CMProfileRef как прежде. То, независимо от того, что было передано в этот инициализатор, будет также возвращено, когда будет вызван метод доступа colorSyncProfile.

Если colorSyncProfile вызывается на экземпляры, не создаваемые с initWithColorSyncProfile: тогда colorSyncProfile возвратит экземпляр ColorSyncProfileRef для Связанных приложений льва и экземпляр CMProfileRef для более ранних приложений.

Обратите внимание на то, что ColorSync APIs, которые берут ColorSyncProfileRef также, берет CMProfileRefs в качестве параметров, таким образом, должно хорошо работать смешивание двух типов.


NSTextStorage

Текстовая система будет теперь использовать UTF-8, а не кодирование струны до по умолчанию для любых документов, иначе не имеющих никаких тегов кодирования или подсказок, и которые похожи, что они - допустимый UTF-8.



Вертикальный текст

Mac OS X 10.7 представляет полный вертикальный текст, пишущий поддержку через текстовую Систему Какао. Существует несколько дополнений API для разработчиков приложений для использования в своих интересах этого типографского улучшения.

NSVerticalGlyphFormAttributeName

Этот атрибут NSAttributedString управляет появлением глифа на основе указанного значения ориентации макета. Когда неноль, значение должно быть NSNumber, содержащим целочисленное значение. Значение 1 указывает, что выполнение текста должно быть представлено с вариантом вертикального шрифта при наличии. Механизм расположения и рендеринга в текстовой Системе Какао занимает место, значение NSFontAttributeName с его вертикальным шрифтом возвратилось из-verticalFont метода.
0 указывает горизонтальный шрифт сил независимо от высокоуровневых настроек ориентации макета.

NSFont

Если базовая гарнитура шрифта может обработать текстовую ориентацию макета, NSFont теперь может управлять вертикальными различными экземплярами. С вертикальным шрифтом текстовая матрица повернута мудрые противочасы на 90 градусов. Кроме того, вертикальная замена глифа типографские функции включена по умолчанию. Существует два API для управления представленными экземплярами вертикального шрифта.
- (NSFont *)verticalFont;
- (BOOL)isVertical;

Текстовая ориентация макета

Ориентация строк, представленных NSTextView, определяется текстовым свойством ориентации макета. NSLayoutManager получает доступ к значению ориентации для каждого представления через NSTextContainer. Позволяется иметь различные настройки ориентации для представлений, совместно использующих единственного менеджера по расположению. Новый протокол, NSTextLayoutOrientationProvider, и его тип перечисления значения, NSTextLayoutOrientation, объявляется в NSLayoutManager.h. NSTextContainer и NSTextView соответствуют протоколу NSTextLayoutOrientationProvider.
@protocol NSTextLayoutOrientationProvider
- (NSTextLayoutOrientation)layoutOrientation;
@end
В дополнение к-layoutOrientation методу NSTextView реализует-setLayoutOrientation: и-changeLayoutOrientation: методы.
- (void)setLayoutOrientation:(NSTextLayoutOrientation)theOrientation;
- (void)changeLayoutOrientation:(id)sender;

Чтение и запись текстовой ориентации макета

Новый ключ атрибута текстового документа, NSTextLayoutSectionsAttribute, представлен для чтения и записи текстовой установки ориентации макета для каждого текстового представления. Значение является массивом словарей. Каждый словарь указывает текстовую ориентацию макета для диапазона строки. Два ключа, NSTextLayoutSectionOrientation и NSTextLayoutSectionRange, предоставлены для содержания словаря.

Курсор I-луча для ориентации макета вертикального текста

Когда указатель мыши вводит текстовую область с ориентацией макета вертикального текста, форма должна быть изменена на курсор I-луча, который составляет повернутых 90 градусов. NSCursor имеет новый метод фабрики для типа указателя.
+ (NSCursor *)IBeamCursorForVerticalLayout;

NSRulerView оценивают перевод

NSRulerView имеет встроенное средство для перевода расположения системы координат его клиента к значению линейки. С введением ориентации макета вертикального текста, поворачивающей границы NSTextView, текущая логика неоднозначна для определения намеченной оси для представления значения линейки. Например, с представлением вертикального текста, вертикальная линейка хочет перевести значение координаты x. Для устранения неоднозначности клиентского намерения представления NSRulerView теперь имеет явный перевод значения методы делегата.
- (CGFloat)rulerView:(NSRulerView *)ruler locationForPoint:(NSPoint)aPoint;
- (NSPoint)rulerView:(NSRulerView *)ruler pointForLocation:(CGFloat)aLocation;

Интегрированная поддержка Беглого взгляда NSTextView

NSTextView в Mac OS X 10.7 имеет встроенную поддержку Беглого взгляда присоединений. Существует три новых NSTextView APIs для работы с панелью предварительного просмотра Беглого взгляда.
- (IBAction)toggleQuickLookPreviewPanel:(id)sender;
- (NSArray *)quickLookPreviewableItemsInRanges:(NSArray *)ranges;
- (void)updateQuickLookPreviewPanel;
Тем временем NSTextViewDelegate имеет новый дополнительный метод делегата,-textView:URLForContentsOfTextAttachment:atIndex: для управления содержанием URL для NSTextAttachment. Этот метод делегата может включить и Беглый взгляд и дважды щелкнуть по действию.
- (NSURL *)textView:(NSTextView *)view URLForContentsOfTextAttachment:(NSTextAttachment *)attachment atIndex:(NSUInteger)charIndex;

Рендеринг глифа NSLayoutManager

NSLayoutManager в Mac OS X 10.7 осудил глиф, представляющий примитивный,-showPackedGlyphs:length:glyphRange:atPoint:font:color:printingAdjustment: и представленный следующий новый метод, берущий массив CGGlyph.
- (void)showCGGlyphs:(const CGGlyph *)glyphs
positions:(const NSPoint *)positions
count:(NSUInteger)glyphCount
font:(NSFont *)font
matrix:(NSAffineTransform *)textMatrix
attributes:(NSDictionary *)attributes
inContext:(NSGraphicsContext *)graphicsContext;
- [NSLayoutManager drawGlyphsForGlyphRange:atPoint:] динамично определяет который примитивный для вызова на основе реализации метода экземпляра. Новый примитивный метод вызывается независимо от версии связи платформы если:

- экземпляр имеет переопределенную реализацию старого примитива и не имеет переопределенной реализации нового примитива
- предпочтительное значение NSLayoutManagerForcesShowPackedGlyphs является истиной


Приписанное редактирование с NSTokenFieldCell

NSTokenFieldCell больше не вынуждает-allowsEditingTextAttributes возвратить YES.


Отмеченный рендеринг цвета подчеркивания с NSTextView

При рендеринге NSMarkedClauseSegmentAttributeName NSTextView больше не вынуждает черный NSUnderlineColorAttributeName. Так как NSLayoutManager использует NSForegroundColorAttributeName в отсутствие NSUnderlineColorAttributeName, NSMarkedClauseSegmentAttributeName соответствует основной цвет.


Строка заполнителя в фокусируемом NSTextField

Строка заполнителя теперь выведена на экран даже с фокусируемым NSTextField.


NSSearchField

В то время как поле фокусируется, поисковое меню теперь может быть раскрыто с комбинацией Клавиши со стрелкой вниз команды.


NSSecureTextField

Caps Lock и индикаторы Num Lock теперь представляются с цветом, полученным из цвета текста поля.




Улучшенные текстовые Системные Управления форматированием в панели инспектора

Вместо текущих управлений форматированием в представлении аксессуара линейки, мы представляем панель инспектора, содержащую текстовые управления форматированием во многом как приложения iWork. Эта новая опция доступна через - [NSTextView usesInspectorBar].


Обработка мыши NSRulerView

NSRulerView теперь направляет события от нажатия мыши, происходящие в области маркера в дополнение к области линейки ее клиентам через-rulerView:handleMouseDown:. Это теперь отправляет и NSLeftMouseDown и NSRightMouseDown. Это - клиентская ответственность представления определить правильное поведение.


Маркеры NSTextTab в представлении линейки

Правильная мышь вниз события показывает контекстное меню для выбора текстового типа вкладки у Льва Mac OS X.


NSFontCollection

Мы представили специализированный класс для представления наборов шрифта, NSFontCollection, к которому ранее получают доступ частично через NSFontManager. NSFontCollection является мешком NSFontDescriptor. Можно предать гласности набор шрифта как именованный набор и представленный через UI, такой как панель шрифта и Книга Шрифта.




Отмечает определенный для Mac OS X 10.6

NSApplication presentationOptions API

Новый «presentationOptions» API на NSApplication обеспечивает замену Какао для существующего углерода «SystemUIMode» API (чье использование было обрисовано в общих чертах в TN2062: «Руководство по Созданию Киосков на Mac OS X»). Используя этот API, приложение может запросить определенные способы поведения на элементы интерфейса пользователя системы (Прикрепление, строка меню, переключатель задачи, и т.д.), который будет применяться, когда приложение будет активным приложением и может также наблюдать изменения в этих способах поведения элемента UI, сделанных другими приложениями, когда они активны.

Поддерживаемый набор опций выражен с помощью нового типа битовой маски NSApplicationPresentationOptions, объявленного в NSApplication.h:
/* Flags that comprise an application's presentationOptions */
enum {
NSApplicationPresentationDefault = 0,
NSApplicationPresentationAutoHideDock = (1 << 0), // Dock appears when moused to
NSApplicationPresentationHideDock = (1 << 1), // Dock is entirely unavailable
    NSApplicationPresentationAutoHideMenuBar            = (1 <<  2),    // Menu Bar appears when moused to
NSApplicationPresentationHideMenuBar = (1 << 3), // Menu Bar is entirely unavailable
    NSApplicationPresentationDisableAppleMenu           = (1 <<  4),    // all Apple menu items are disabled
NSApplicationPresentationDisableProcessSwitching = (1 << 5), // Cmd+Tab UI is disabled
NSApplicationPresentationDisableForceQuit = (1 << 6), // Cmd+Opt+Esc panel is disabled
NSApplicationPresentationDisableSessionTermination = (1 << 7), // PowerKey panel and Restart/Shut Down/Log Out disabled
NSApplicationPresentationDisableHideApplication = (1 << 8), // Application "Hide" menu item is disabled
NSApplicationPresentationDisableMenuBarTransparency = (1 << 9) // Menu Bar's transparent appearance is disabled
};
typedef NSUInteger NSApplicationPresentationOptions;
Этот тип используется следующими новыми методами API NSApplication.

Следующее получает или устанавливает presentationOptions, который должен иметь силу для системы, когда это приложение является активным приложением. Только определенные комбинации флагов NSApplicationPresentationOptions позволяются, как детализировано в Информации о версии AppKit и справочной документации для-setPresentationOptions:. Когда дали недопустимая комбинация флагов опции,-setPresentationOptions: повышает исключение.
- (NSApplicationPresentationOptions)presentationOptions;
- (void)setPresentationOptions:(NSApplicationPresentationOptions)newOptions;
Возвращает набор опций представления приложения, которые являются в настоящее время в действительности для системы. Это опции представления, осуществленные в настоящее время активным приложением.
- (NSApplicationPresentationOptions)currentSystemPresentationOptions;
Для большинства приложений начальным значением presentationOptions является NSApplicationPresentationDefault. Если Info.plist приложения указывает значение для ключа LSUIElement, как описано в TN2062, presentationOptions приложения инициализируется к эквивалентной комбинации флагов NSApplicationPresentationOptions вместо этого.

И presentationOptions и currentSystemPresentationOptions KVO-заметны. Клиент, наблюдающий currentSystemPresentationOptions, получит уведомления, когда (1) клиент будет активным приложением и вносит само изменение с помощью любого-setPresentationOptions: или SetSystemUIMode (), (2) другое приложение активно, и вносит такие собственные изменения, и (3) подавание различной заявки активные причины активный набор опций представления измениться. Уведомления не отправляются за неизменениями (например, когда различное приложение становится активным, но имеет тот же набор опций представления как ранее активное приложение).

presentationOptions / currentSystemPresentationOptions API взаимодействует с SystemUIMode API (оба, отражают то же базовое состояние). Комбинация флагов опции, которые Вы передаете-setPresentationOptions: должен удовлетворить тот же набор требований, применяющихся к SystemUI «Режим» и комбинации «Опций», как описано в TN2062. В частности:

NSApplicationPresentationAutoHideDock и NSApplicationPresentationHideDock являются взаимоисключающими: можно указать один или другой, но не оба.

Аналогично, NSApplicationPresentationAutoHideMenuBar и NSApplicationPresentationHideMenuBar являются взаимоисключающими: можно указать один или другой, но не оба.

При указании NSApplicationPresentationHideMenuBar он должен сопровождаться NSApplicationPresentationHideDock. При указании NSApplicationPresentationAutoHideMenuBar он должен сопровождаться или NSApplicationPresentationHideDock или NSApplicationPresentationAutoHideDock.

При указании какого-либо из NSApplicationPresentationDisableProcessSwitching, NSApplicationPresentationDisableForceQuit, NSApplicationPresentationDisableSessionTermination или NSApplicationPresentationDisableMenuBarTransparency, это должно сопровождаться или NSApplicationPresentationHideDock или NSApplicationPresentationAutoHideDock.

Когда-setPresentationOptions: получает newOptions параметр, не соответствующий этим требованиям, он повышает NSInvalidArgumentException.


NSApplicationPresentationOptions и режим FullScreen

На 10,6,-enterFullScreenMode:withOptions NSVIEW: API принимает новую опцию, значение которой указывает NSApplicationPresentationOptions для использования, в то время как представление работает в полноэкранном режиме:
NSString *NSFullScreenModeApplicationPresentationOptions;  // NSNumber numberWithUnsignedInteger:(NSApplicationPresentationOptions flags)
Обратите внимание на то, что присутствие или отсутствие этой опции влияют, получает ли ввод полноэкранного режима для представления дисплеи, и разрешена ли опция NSFullScreenModeSetting, следующим образом:

Когда словарь опций Вы передаете-enterFullScreenMode:withOptions: не содержит значение для NSFullScreenModeApplicationPresentationOptions, AppKit не изменяет опции представления, которые были ранее в действительности при получении полноэкранного представления. AppKit также получает или целевой экран, или (при указании YES для NSFullScreenModeAllScreens), все присоединенные экраны, соответствующие поведению на 10,5. («Получение» экрана берет на себя монопольное управление его в том же смысле, предусмотренном CGDisplayCapture () и связавшем Базовую Графику APIs.)

Когда словарь опций Вы передаете-enterFullScreenMode:withOptions: действительно содержит значение для NSFullScreenModeApplicationPresentationOptions, AppKit не получает дисплеев, начиная с выполнения так предотвратил бы показ presentationOptions-управляемых элементов UI, таких как строка меню и Прикрепление. (Поскольку дисплеи не получены в этом случае, и приложение поэтому не содержит монопольное владение их, опция NSFullScreenModeSetting запрещена; указание его, когда NSFullScreenModeApplicationPresentationOptions будет также указан, вызовет-enterFullScreenMode:withOptions: повысить исключение.) Когда представление выходит от полноэкранного режима через-exitfullscreenmodewithoptions: AppKit осуществляет требуемое значение NSApplicationPresentationOptions при переключении представления в полноэкранный режим и восстановит ранее активную установку NSApplication presentationOptions. Даже если Вы не хотите изменять настройки NSApplication presentationOptions при вводе полноэкранного режима, можно передать [NSApp presentationOptions] для ключа NSFullScreenModeApplicationPresentationOptions как средние значения предотвращения снимка экрана при желании.


NSView-enterFullScreenMode:withOptions: изменения API

На 10,5,-enterFullScreenMode:withOptions NSVIEW: метод выдал бы исключение, если бы представление получения не было в окне, как мог бы иметь место для внеэкранного представления, это создается исключительно в целях того, чтобы быть представленным полноэкранный. Это было неумышленным ограничением. На 10,6,-enterFullScreenMode:withOptions: может теперь быть отправлен в представление, для которого [просматривают окно] == ноль. Для приложений, которые должны также работать 10.5, простое обходное решение должно поместить представление во внеэкранное фиктивное окно.


Импликации NSWindow и Цветового пространства NSScreen поддерживают для NSViews

Большинство представлений вовлекает запоминающее устройство своего окна и поэтому нарисовано в их окне, присвоил NSColorSpace. Несколько видов представлений вместо этого вовлечены в отдельное запоминающее устройство, названное «поверхностью», это составляется на окне, упростить аппаратные средства (GPU) ускорило рендеринг. Это включает представления OpenGL, а также другие виды представлений, что рендеринг через OpenGL как подробность их реализации (в настоящее время, представления, выводящие на экран Базовую Анимацию дерево CALayer, QuickTime QTMovieViews, Кварцевый Композитор Кквивс и ImageKit IKImageBrowserViews, среди других).

Для поверхностных представлений AppKit устанавливает цветовое пространство поверхности, чтобы соответствовать, и отследить изменения в, цветовое пространство окна. Приложения должны поэтому смотреть на-setColorSpace NSWINDOW: и-setDisplaysWhenScreenProfileChanges: APIs для определения цветового пространства, использованного для поверхностного рендеринга в данном окне.

Поддержка анимации целочисленных значений

На 10,6, целочисленные свойства, передаваемые по значению, могут теперь быть анимированы с помощью находящегося в CAAnimation прокси «аниматора» API. Все целые типы поддерживаются: значения BOOL, а также подписанные и варианты без знака символа, короткого, международного, долго, и долго долго, могут анимироваться. Как с анимацией любого пользовательского свойства, убедиться связать подходящий CAAnimation со свойством называют ключ так, чтобы обмен сообщениями через аниматора цели для установки нового значения фактически анимировал. Например, «imageFrameStyle» свойство NSImageView может быть сконфигурировано для анимации, когда изменено через аниматора ImageView как так:
    [imageView setAnimations:[NSDictionary dictionaryWithObject:[CABasicAnimation animation] forKey:@"imageFrameStyle"]];
Любой новый набор значений через аниматора тогда инициирует анимацию:
    [imageView setImageFrameStyle:NSImageFramePhoto];
[[imageView animator] setImageFrameStyle:NSImageFrameButton];
Анимируя введенные целым числом свойства Базовой Анимации CALayers, анимация продолжается на дискретных шагах.


Поддержка анимации значений NSColor

10.5 Информации о версии AppKit неправильно утвердила, что могли быть анимированы NSColor-свойства-передаваемые-по-значению. В то время как приложения, которые, оказалось, соединялись против Кварцевой платформы, обладали преимуществом этой возможности, это не было предоставлено как внутренняя функция AppKit.

Поддержка анимации NSColor-свойств-передаваемых-по-значению, была добавлена к AppKit для 10,6, таким образом, пример кода, представленный в 10.5 Информации о версии AppKit (в соответствии с возглавляющим “протоколом NSAnimatablePropertyContainer”), будет теперь работать, как предназначено над 10,6, независимо от ли ссылки на приложение против Кварцевой платформы.
@implementation MyView
+ (id)defaultAnimationForKey:(NSString *)key {
if ([key isEqualToString:@"borderColor"]) {
// By default, animate border color changes with simple linear interpolation to the new color value.
return [CABasicAnimation animation];
} else {
// Defer to super's implementation for any keys we don't specifically handle.
return [super defaultAnimationForKeyKey:key];
}
}
@end


Изменения планирования оценки анимации

На 10,5, анимации свойства NSView и NSWindow, запланированные через «аниматора» представления/окна, и оцененные AppKit (вместо того, чтобы быть делегированными к Базовой Анимации для потоковой асинхронной оценки), были запланированы для обновления в NSDefaultRunLoopMode.

На 10,6, такие анимации теперь оценены в NSRunLoopCommonModes.

«аниматор» - инициировал анимации, оцененные AppKit, включайте:

- все анимации свойства NSWindow
- все анимации свойства NSView, для не поддерживающихся уровнем представлений
- frameSize представления, для поддержанного уровнем представления, layerContentsRedrawPolicy которого (новый в 10,6) равняется значению по умолчанию NSViewLayerContentsRedrawDuringViewResize
- анимация любого пользовательского свойства, это добавляется NSView или подклассом NSWindow, или любого существующего свойства NSView, с готовностью не отображающегося на соответствующее свойство CALayer (и поэтому не может быть делегирован к Базовой Анимации для оценки),


Изменения в использовании AppKit CATransaction

NSAnimationContext AppKit «группировки» служат очень подобной цели к CATransactions Базовой Анимации, и фактически вызов [NSAnimationContext beginGrouping] выполняет [CATransaction начинаются] (в дополнение к выполнению другой работы), и вызов [NSAnimationContext endGrouping] выполняет [фиксация CATransaction].

На 10,5, AppKit также начал и фиксировал CATransactions в ходе своей собственной древовидной уровнем управленческой деятельности, особенно во время определенных модальных операций отслеживания события, и подавить неявные анимации во время неанимированного представления, поддерживающего обновления свойства слоя.

На 10,6, мы удалили это автоматическое использование CATransaction, чтобы избежать вмешиваться в собственное управление клиента CATransaction - в частности так, чтобы не были неожиданно задержаны изменения, клиентское приложение делает ожидание неявного CATransaction. AppKit вместо этого делает очень экономящее использование [сброс CATransaction], сбрасывая только, прежде чем это будет инициировать явный уровень древовидное получение, и на каждом цикле через модальный цикл отслеживания события. Это изменение делает использование клиентского приложения [сброс CATransaction] более надежный как средние значения, чтобы вынудить изменения дерева уровня посвятить себя дереву рендеринга. Общая философия теперь должна оставить создание явного CATransactions для монопольного использования клиентских приложений.


Параллельное получение представления

Помочь приложениям с особенно высоким получением загружается, чтобы эффективнее эффективно использовать многожильные аппаратные средства при поиске минимизировать требования принятия для кода представления, соответствующего установленным соглашениям поточной обработки AppKit, 10.6 представляет простую модель для параллельного получения представления и сопровождение управления API. Наши результаты до настоящего времени указали, что параллельное получение представления имеет преимущество только при некоторых обстоятельствах, и приложения могут испытать сетевое снижение производительности в случаях, где усиления параллелизма не перевешивают дополнительные включенные издержки, таким образом, использование параллельного получения представления должно сопровождаться расследованиями производительности для измерения результатов. Прогнозные приложения могут хотеть рассмотреть импликации модели потокобезопасности, чтобы сделать проектные решения, которые совместимы с потенциальным усилением этой функции в будущем.

В то время как требования новой модели для безопасно параллельного - значение потокового - получение представления сравнительно просто (см., “что Параллельное Представление Рисует - Импликации Потокобезопасности” ниже), существующий UIs не может быть уверен в 100%-й потокобезопасности из поля, таким образом, мы обеспечиваем механизм API, чтобы позволить клиентам выбрать в к параллельному получению представления, когда желаемый.

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

Установка представления не является рекурсивной в своем эффекте; это указывает threadability рисования для высказанного мнения, не для всего поддерева представления. Потомкам представления можно было сконфигурировать их threadability независимо.

Наша рекомендация состоит в том, что потенциальные клиенты запускают путем поиска ряда более дорогостоящие пользовательские представления в их UIs (обычно те, которые рисуют сложное содержание и/или покрывают большие площади), и попытайтесь включить параллельное получение для тех. Дополнительные представления могут быть отмечены как безопасные для параллельного получения дать систему рисования представления, далее планируя гибкость (это может особенно стоить для потомков основных threadable представлений вследствие неявного наоборот рисующие зависимости от порядка), но включающий это для даже нескольких «более тяжелых» листовых представлений UI часто достаточно для жатвы объема потенциального выигрыша в производительности, где существует такое преимущество.

К классу NSWindow мы добавили булевскую переменную «allowsConcurrentViewDrawing» свойство со следующими методами доступа:
/* Reports whether threading of view drawing is enabled for this window.  Defaults to YES.
*/
- (BOOL)allowsConcurrentViewDrawing;
/* Sets whether threading of view drawing should be enabled for this window.  Defaults to YES.  When this is set to YES,
AppKit's view system is allowed to perform -drawRect: activity for the window's views on threads other than the main thread,
for views that have canDrawConcurrently == YES. When this is set to NO, the window's views will be drawn serially as on 10.5
and earlier, even though some of the views may have canDrawConcurrently == YES.
*/
- (void)setAllowsConcurrentViewDrawing:(BOOL)flag;
К классу NSView мы добавили «canDrawConcurrently» свойство со следующими методами доступа:
/* Reports whether AppKit may invoke the view's -drawRect: method on a background thread, where it would otherwise be invoked
on the main thread. Defaults to NO.
*/
- (BOOL)canDrawConcurrently;
/* Sets whether AppKit may invoke the view's -drawRect: method on a background thread, where it would otherwise be invoked
on the main thread. Defaults to NO for most kinds of views. May be set to YES to enable threaded drawing for a particular
view instance. The view's window must also have its "allowsConcurrentViewDrawing" property set to YES (the default) for
threading of view drawing to actually take place.
*/
- (void)setCanDrawConcurrently:(BOOL)flag;
2.   Рекурсия-viewWillDraw, происходящая в начале “- дисплей...” передача, будет все еще выполняться на основном потоке и завершится последовательно как прежде. Это позволяет потенциально изменение иерархии представления по требованию действие расположения, для которого-viewWillDraw разработан для завершения в безопасной и нормальной однопоточной среде и, как ожидают, не изложит значительное ограничение, потому что действие-viewWillDraw предназначается, чтобы быть сохраненным легким по сравнению с получением.

3. Любой экземпляр представления, имеющий canDrawConcurrently == ДА, в окне, что allowsConcurrentViewDrawing, приемлем делегировать свое получение автоматически к фоновому потоку / работа по усмотрению AppKit. AppKit проследил, чтобы параллельным операциям рисования представления, которые он порождает, сериализировали их завершение по мере необходимости, такой, что наложение представлений (оба одноуровневых элемента и цепочки наследователя/потомка) представляется с корректными результатами.

4. Обслуживание нормального дерева представления, рисующего (“-displayIfNeeded” действие), будет все еще инициироваться и управляться основным потоком, который будет искать на работу рисования представления баланса загрузки путем порождения фоновых работ для определенных приемлемых представлений. Решения, о которых представления отделить к фоновым работам могут базироваться частично выставленные для обозрения измерения получения среди других потенциальных факторов. Присутствие или отсутствие перекрывающихся одноуровневых представлений будут влиять на разделение также. Основной поток завершит остающееся получение дерева представления, и затем блокирует на завершении любых фоновых операций рисования представления, которые это породило прежде, чем сбросить окно и возвратить управление runloop.

Параллельное получение представления - импликации потокобезопасности

Импликации упрощения этой последней точки важны: AppKit должен вызвать точку синхронизации перед сбросом окна так или иначе, для обеспечения всех внесло вовлечение окна для завершения перед сбросом, но это обладает дополнительным преимуществом, что runloop на основном потоке, как гарантируют, будет блокирован во время передачи получения, включая во время любого получения фонового потока представлений в окне. Таким образом за исключением побочных эффектов в чем действие рисования представления может изменить данные, которые это совместно использует вместе с другим представлением, которое может пытаться нарисовать одновременно на другом потоке (хотя, надо надеяться, относительно редкий, это - причина, почему и представление - и уровень окна, запрещающий API, предоставлены), просматривает те справочные данные вне себя, в основном не должен больше касаться данных, изменяющихся из-под них, чем они были с сегодняшним прежде всего основным потоком базируемым получением представления. Если получение представления происходит, то данные модели, что на ссылку представлений можно полагаться, чтобы не быть измененной обработкой событий и другим основным действием потока, в то время как это происходит. Изменения фонового потока в модели должны будут быть скоординированы с представлениями об основном потоке как прежде, с помощью доступных механизмов, таких как блокировки, очереди уведомления, -performSelectorOnMainThread:..., и т.п.

Параллельное получение представления - тестирование функций и дополнительных примечаний

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

«NSEnableConcurrentViewDrawing» может быть установлен в НЕ отключить параллельное представление, рисующее полностью для процесса, возвращаясь к поведению рисования представления Leopard-earlier независимо от allowsConcurrentViewDrawing и canDrawConcurrently настроек на отдельных окнах и представлений. Это принимает значение по умолчанию к YES иначе.

«NSConcurrentViewClasses» может быть установлен в разграниченный запятой список имен классов представления вынудить canDrawConcurrently быть установленным в YES для всех экземпляров тех классов, допуская предварительное испытание этой функции с существующими созданными исполнимыми программами приложения. Обратите внимание на то, что тест класса, используемый здесь, является преднамеренно точным тестом равенства, не isKindOfClass: тест - так включая «NSButton» в списке не заставил бы экземпляры подклассов NSButton быть включенными для параллельного получения. Для принуждения включения параллельного получения и для NSButton и для экземпляров NSPopUpButton нужно было бы включать оба тех имен классов в список.

«NSShowConcurrentViewDrawing» может быть установлен в ДА, который структурирует каждое одновременно нарисованное представление зеленого цвета для визуального подтверждения, что работает параллельное получение представления.

«NSDebugConcurrentViewDrawing» может быть установлен в YES включить некоторый основной диагностический консольный вывод журнала, связанный с параллельным получением представления.

«NSConcurrentViewDrawingMinCores» указывает минимальное число ядер CPU, которые должны быть доступными в хост-системе для AppKit для фактической попытки параллельного получения представления. AppKit сравнивает это значение с [[NSProcessInfo processInfo] activeProcessorCount]. Значение по умолчанию равняется 2.

Пример применения некоторых из этих значений по умолчанию в запуске TextEdit.app:
/Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowConcurrentViewDrawing YES -NSConcurrentViewClasses "NSScroller,NSPopUpButton,NSButton"
Для помощи разработчикам в оценке типичных затрат получения различных представлений AppKit накапливает основную статистику синхронизации для-drawRect представлений: вызовы, теперь показанные как часть - _subtreeDescription информация об отладке. Печать описания поддерева представления окна в gdb как ниже шоу эта статистика, добавленная к строке для каждого представления, создание отчетов о минимальном, среднем (среднее число), и максимальное время получения в миллисекундах. Нарисуйте времена нескольких миллисекунд, и особенно приблизительно больше чем 10 мс, обычно указывайте хорошее потенциальное представление кандидата для параллельного получения. Нарисуйте времена меньше чем одной сотой миллисекунды, обнаруживаются как 0,00 мс. Этот определенный пример (TextEdit с пустым окном документа) не показывает никаким особенно сильным кандидатам на параллельное получение представления.
(gdb) po [[[[[NSApplication sharedApplication] windows] objectAtIndex:0] _borderView] _subtreeDescription]
[ A O P ] h=--- v=--- NSThemeFrame 0x185650 "Untitled" f=(0,0,475,442) b=(-) TIME drawRect: min/mean/max 0.62/0.62/0.62 ms
[ AF ] h=--- v=--- _NSThemeCloseWidget 0x15e840 "Button" f=(8,422,14,16) b=(-) TIME drawRect: min/mean/max 0.04/0.05/0.06 ms
[ AF ] h=--- v=--- _NSThemeWidget 0x15fd00 "Button" f=(50,422,14,16) b=(-) TIME drawRect: min/mean/max 0.06/0.07/0.08 ms
[ AF ] h=--- v=--- _NSThemeWidget 0x15fe50 "Button" f=(29,422,14,16) b=(-) TIME drawRect: min/mean/max 0.04/0.04/0.04 ms
[ A ] h=--- v=--- NSView 0x187840 f=(0,0,475,420) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ AF O ] h=-&- v=-&- ScalingScrollView 0x13c680 f=(0,0,475,420) b=(-) TIME drawRect: min/mean/max 0.03/1.39/2.75 ms
[ AF OGP ] h=--- v=--- NSClipView 0x17c6b0 f=(0,55,460,365) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ AF OG ] h=-&- v=--- NSTextView 0x19db90 f=(0,0,460,365) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ AF O ] h=--- v=--- NSScroller 0x1a2aa0 f=(460,55,15,350) b=(-) TIME drawRect: min/mean/max 0.06/0.07/0.07 ms
[ AF O ] h=--- v=--- NSScroller 0x14c770 f=(-100,-100,479,15) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ AF O ] h=--- v=--- NSRulerView 0x15cf00 f=(0,0,475,55) b=(-) TIME drawRect: min/mean/max 1.51/1.51/1.51 ms
[ P ] h=--- v=--- NSStopTouchingMeBox 0x15a680 "Title" f=(0,0,475,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ ] h=--- v=--- NSView 0x1aaa70 f=(0,0,475,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ P ] h=--- v=--- NSBox 0x17bfc0 "Title" f=(0,-1,388,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ A ] h=--- v=--- NSView 0x14c700 f=(0,0,388,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ AF ] h=--- v=--- NSPopUpButton 0x1a9360 "Spacing" f=(194,-1,85,22) b=(-) TIME drawRect: min/mean/max 0.18/0.19/0.21 ms
[ AF ] h=--- v=--- NSPopUpButton 0x158b80 "Styles" f=(2,-1,85,22) b=(-) TIME drawRect: min/mean/max 0.08/0.10/0.11 ms
[ AF ] h=--- v=--- NSPopUpButton 0x162520 "Lists" f=(279,-1,85,22) b=(-) TIME drawRect: min/mean/max 0.08/0.09/0.10 ms
[ AF ] h=--- v=--- NSSegmentedControl 0x1807f0 f=(88,-3,105,25) b=(-) TIME drawRect: min/mean/max 0.40/0.46/0.52 ms
[ P ] h=--- v=--- NSBox 0x164830 "Title" f=(388,-1,88,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ ] h=--- v=--- NSView 0x1595a0 f=(0,0,88,24) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ P ] h=--- v=--- NSBox 0x188980 "Title" f=(0,0,79,20) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ A ] h=--- v=--- NSView 0x169af0 f=(0,0,79,20) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ P ] h=&-- v=--- NSBox 0x1b6370 "Title" f=(0,0,79,20) b=(-) TIME drawRect: min/mean/max 0.23/0.23/0.23 ms
[ ] h=--- v=--- NSView 0x1673c0 f=(3,3,73,14) b=(-) TIME drawRect: min/mean/max 0.00/0.00/0.00 ms
[ A ] h=--- v=--- NSTabWell 0x180330 f=(4,1,15,13) b=(-) TIME drawRect: min/mean/max 0.02/0.02/0.02 ms
[ A ] h=--- v=--- NSTabWell 0x1847b0 f=(20,1,15,13) b=(-) TIME drawRect: min/mean/max 0.02/0.02/0.02 ms
[ A ] h=--- v=--- NSTabWell 0x1b8bf0 f=(37,1,15,13) b=(-) TIME drawRect: min/mean/max 0.02/0.02/0.02 ms
[ A ] h=--- v=--- NSTabWell 0x1a7a70 f=(54,1,15,13) b=(-) TIME drawRect: min/mean/max 0.01/0.01/0.01 ms
A=autoresizesSubviews, C=canDrawConcurrently, D=needsDisplay, F=flipped, G=gstate, H=hidden (h=by ancestor),
O=opaque, P=preservesContentDuringLiveResize, S=scaled/rotated, W=wantsLayer (w=ancestor wantsLayer), #=has surface
Для предоставления большего количества значимых данных только полные перерисовки представления будут способствовать этой статистике синхронизации. Изменение размеров окна представления является хорошим способом запросить полные перерисовки так как
для сбора рисуют статистику времени, для представлений, в частности не оптимизированных содержание заповедника использование preservesContentDuringLiveResize механизма.

Простой стандартный AppKit NSControls, которые не используют источники данных, и иначе не полагаться на данные вне их собственного во время получения, вероятно, будет безопасен для включения canDrawConcurrently, но еще все формально не исследовался для параллельной безопасности получения. На данный момент рекомендуется, чтобы приложения ограничили включение canDrawConcurrently к их собственным классам представления.

Поддержанное уровнем получение представления еще не использует в своих интересах возможность нарисовать представления одновременно. Это - возможное будущее направление.



NSView-setNeedsDisplay: и-setNeedsDisplayInRect: действие во время получения

Один Mac OS X 10.5, отправляя-setNeedsDisplay: или-setNeedsDisplayInRect: к представлению не мог бы произвести требуемую перерисовку, если окно представления посреди рекурсивной работы дисплея представления, когда поступает запрос. На 10,6, прямоугольники, лишенные законной силы во время дисплея, накапливаются в области стороны, которая будет обслуживаться в последующем цикле дисплея окна. Это новое поведение идет по умолчанию для приложений, соединенных на или после 10.6. Для отладки целей это может быть отключено путем выполнения с пользовательским набором значения по умолчанию «NSWindowsUseDeferredNeedsDisplayRegion» к или вызвано на путем выполнения с этим пользовательским набором значения по умолчанию к YES. Если Вы видите незначительный сбой получения или рисование проблемы производительности, уходящей при выполнении с “-NSWindowsUseDeferredNeedsDisplayRegion НЕ”, зарегистрируйте Радар.



NSView-viewWillDraw и внеэкранное получение

Когда представления были вовлечены в их окно, на Mac OS X 10.5, был только вызван недавно внедренный метод-viewWillDraw. На 10,6,-viewWillDraw также вызывается когда любой-cacheDisplayInRect:toBitmapImageRep: или-displayRectIgnoringOpacity:inContext: используется для рисования представлений альтернативному месту назначения.

10.6 также устраняет проблему, иногда препятствовавшую тому, чтобы сообщения-viewWillDraw были отправлены в распечатывавшиеся представления.


Поддержанный уровнем NSOpenGLViews и форматы пикселя

На 10,6, поддержанный уровнем рабочий режим NSOpenGLView теперь наследовал атрибуты формата пикселя от существующего контекста OpenGL представления. Если представление не имеет существующего контекста OpenGL (например, потому что представление начинает жизнь в поддержанном уровнем режиме, не сначала работая в режиме составления композита традиционного взгляда), проверки AppKit, обеспечивает ли представление-pixelFormat метод. Если так, AppKit вызывает-pixelFormat метод представления и исследует результат создать совместимый формат пикселя OpenGL и контекст для использования в поддержанном уровнем режиме.

NSOpenGLLayer

Mac OS X 10.6 представляет новый класс «NSOpenGLLayer», поддерживающий, полностью обобщил использование OpenGL в поддержанном уровнем режиме.

На Mac OS X 10.5, AppKit поддерживал рендеринг OpenGL в поддержанном уровнем режиме только с помощью NSOpenGLView. Когда приложение установило wantsLayer в YES для NSOpenGLView или одного из его представлений наследователя, AppKit автоматически установил бы подходящий уровень поддержки и контекст OpenGL для рендеринга, с помощью существующего, поддержанного поверхностью контекста OpenGL представления (если таковые имеются) как контекст «доли» (так, чтобы та же текстура IDs и другие ссылки на объект OpenGL перенесла на поддержанный уровнем режим).

На Mac OS X 10.6, добавление NSOpenGLLayer позволяет любому произвольному NSView (не обязательно полученный из NSOpenGLView) представить через OpenGL в поддержанном уровнем режиме - очень, поскольку NSOpenGLContext может быть связан с любым произвольным NSView в не, уровень поддержал режим. Существенные требования для того, чтобы позволять произвольное представление представить через OpenGL в поддержанном уровнем режиме следующие:

1. Подкласс NSOpenGLLayer.

2. В Вашем подклассе NSOpenGLLayer переопределите-openGLPixelFormatForDisplayMask: для возврата автовыпущенного NSOpenGLPixelFormat, подходящего для указанного набора дисплеев и содержания, Вы хотите представить.

3. При необходимости в контексте для совместного использования объектов OpenGL с другим, существующим контекстом, можно также хотеть переопределить-openGLContextForPixelFormat: так, чтобы можно было указать желаемый контекст «доли» при создании нового контекста. (Необходимо возвратить автовыпущенный NSOpenGLContext.) Обратите внимание на то, что можно попросить у NSOpenGLLayer его связанного представления, которое может помочь Вам получить указатель на желаемый контекст «доли».

4. В Вашем классе представления переопределите-makeBackingLayer для возврата автовыпущенного экземпляра подкласса NSOpenGLLayer. Например:
- (CALayer *)makeBackingLayer {
return [[[CubeViewOpenGLLayer alloc] init] autorelease];
}
5. В Вашем классе представления переопределите-setFrameSize: для создания openGLContext тока уровня и - обновляют его, и повторно указать область просмотра OpenGL и GL_MODELVIEW / GL_PROJECTION преобразовывает, как Вы обычно делали бы, когда изменено представление OpenGL. Можно использовать этот тот же метод для получения openGLContext уровня каждый раз, когда необходимо сделать его текущим или передать его по любой другой причине:
- (void)setFrameSize:(NSSize)newSize {
[super setFrameSize:newSize];
    NSOpenGLContext *openGLContext = [(NSOpenGLLayer *)[self layer] openGLContext];
    [openGLContext makeCurrentContext];
[openGLContext update];
[self reshape]; // Assume we've defined a -reshape method that calls glViewport()
// and updates the GL_PROJECTION and GL_MODELVIEW matrices.
}
Существует много дополнительных проблем, вовлеченных в реализацию полностью общего представления OpenGL - то, которое может быть переключено в и из поддержанного уровнем режима по желанию. Необходимые методы, вероятно, будут проиллюстрированы будущим обновлением к примеру кода LayerBackedOpenGLView.



Размещение содержания уровня и политика перерисовки API

Mac OS X 10.6 представляет новый API на NSView, который клиенты могут использовать, чтобы существенно улучшиться, производительность поддержанного уровнем представления изменяют размеры анимаций. Новые методы NSView являются средствами доступа для двух новых свойств: layerContentsRedrawPolicy и layerContentsPlacement.
- (NSViewLayerContentsRedrawPolicy)layerContentsRedrawPolicy;
- (void)setLayerContentsRedrawPolicy:(NSViewLayerContentsRedrawPolicy)newPolicy;
- (NSViewLayerContentsPlacement)layerContentsPlacement;
- (void)setLayerContentsPlacement:(NSViewLayerContentsPlacement)newPlacement;
До 10,6, AppKit не обеспечивал пути к лицам, осуществляющим внедрение или пользователям представлений к экспрессу, как нарисованное содержание представления будет затронуто путем изменения размеров представления, и требовалась ли бы перерисовка содержания представления. Без такой информации AppKit должен был предположить, что содержание представления могло измениться произвольными способами, когда представление было изменено и должно быть перерисовано в каждом промежуточном кадре анимированного, изменяют размеры. В поддержанном уровнем режиме это вынуждает AppKit отклонить анимации изменения размеров представления прочь асинхронного потока render+evaluation Базовой Анимации и реализовать изменение размеров с помощью управляемой таймером анимации на основном runloop AppKit - приводящий и к сокращенной производительности и иногда визуально к, неприятные проблемы синхронизации, когда AppKit-управляется изменяют размеры анимаций, объединены с асинхронными, Базовыми Оцененными анимацией анимациями.

Используя этот новый API, реализация класса представления или код, использующий экземпляры определенного типа представления, может управлять, как изменение размеров обрабатывается, когда представление поддерживается уровнем. Основной механизм реализации для этого является новым layerContentsRedrawPolicy свойством, имеющим следующее объявление и позволенные значения:
enum {
NSViewLayerContentsRedrawNever = 0,
NSViewLayerContentsRedrawOnSetNeedsDisplay = 1,
NSViewLayerContentsRedrawDuringViewResize = 2,
NSViewLayerContentsRedrawBeforeViewResize = 3
};
typedef NSInteger NSViewLayerContentsRedrawPolicy;
Семантика этих режимов:
NSViewLayerContentsRedrawNever — Оставьте содержание уровня в покое. Никогда не отмечайте уровень как нуждающийся в дисплее или рисуйте содержание представления к уровню. Это - способ, которым AppKit обрабатывает предоставленные разработчиками уровни и на 10,5 и на 10.6.
Представление NSViewLayerContentsRedrawOnSetNeedsDisplay — Map-setNeedsDisplay...: действие к уровню и перерисовка влияли на части уровня путем вызова-drawRect представления: но не отмечайте представление или уровень как нуждающийся в дисплее, когда изменится размер представления.
NSViewLayerContentsRedrawDuringViewResize — Измените размеры уровня и перерисуйте представление к уровню, когда изменится размер представления. Если изменение размеры будет анимировано, то AppKit будет управлять самой изменять размеры анимацией и сделает этот resize+redraw на каждом шаге анимации. Когда представление будет отмечено как нуждающийся в дисплее, затронутые части уровня будут также перерисованы. (Этот режим является надмножеством NSViewLayerContentsRedrawOnSetNeedsDisplay.) Это - способ, которым мы обрабатываем AppKit-сгенерированные уровни поддержки представления сегодня.
NSViewLayerContentsRedrawBeforeViewResize — Измените размеры уровня и перерисуйте представление к уровню, когда изменится размер представления. Это будет сделано только один раз в начале изменять размеры анимации, не в каждом кадре анимации. Когда представление будет отмечено как нуждающийся в дисплее, затронутые части уровня будут также перерисованы. (Этот режим является надмножеством NSViewLayerContentsRedrawOnSetNeedsDisplay.)


Для представления, не имеющего никакого связанного уровня, или это было присвоено предоставленный разработчиками уровень с помощью-setLayer NSVIEW: API, значением по умолчанию layerContentsRedrawPolicy является NSViewLayerContentsRedrawNever с сопровождением layerContentsPlacement NSViewLayerContentsPlacementScaleAxesIndependently. Это сообщает AppKit, что ему не позволяют заменить содержание уровня и обеспечивает то же размещение содержания как значение по умолчанию CALAYER contentsGravity установка kCAGravityResize.

Для представления, получившего AppKit-сгенерированный отступающий уровень, AppKit устанавливает layerContentsRedrawPolicy представления в значение по умолчанию NSViewLayerContentsRedrawDuringViewResize, вынуждая содержание представления быть постоянно перерисованным на уровень поддержки представления во время анимированного изменения размеров представления, производящего строго корректный, но не оптимально производительные результаты.

Если Вы знаете, что перерисовка в каждом кадре анимации не необходима для приведения к правильно представленным результатам для определенного представления или готова принять приближение промежуточного появления представления во время потенциально кратких анимаций в обмен на производительность анимации и преимущество гладкости, можно изменить layerContentsRedrawPolicy представления на одно из других поддерживаемых значений. При выполнении этого необходимо также указать желаемый layerContentsPlacement для представления. layerContentsPlacement определяет, как отступающий уровень, существующий кэшируемый довольный, изображение будет отображено на уровень, поскольку изменен уровень. (Это походит, и подкрепленный, contentsGravity свойство CALAYER, как обозначено комментариями ниже.)

Предоставленные значения layerContentsPlacement следующие:
enum {
NSViewLayerContentsPlacementScaleAxesIndependently = 0, // equivalent to kCAGravityResize
NSViewLayerContentsPlacementScaleProportionallyToFit = 1, // equivalent to kCAGravityResizeAspect
NSViewLayerContentsPlacementScaleProportionallyToFill = 2, // equivalent to kCAGravityResizeAspectFill
NSViewLayerContentsPlacementCenter = 3,
NSViewLayerContentsPlacementTop = 4,
NSViewLayerContentsPlacementTopRight = 5,
NSViewLayerContentsPlacementRight = 6,
NSViewLayerContentsPlacementBottomRight = 7,
NSViewLayerContentsPlacementBottom = 8,
NSViewLayerContentsPlacementBottomLeft = 9,
NSViewLayerContentsPlacementLeft = 10,
NSViewLayerContentsPlacementTopLeft = 11
};
typedef NSInteger NSViewLayerContentsPlacement;
Первые три значения указывают, что существующее содержание уровня должно быть выведено на экран масштабируемое одним из трех поддерживаемых способов, когда уровень изменен, в то время как быть сохраненным в центре в границах уровня. Оставление девятью значениями указывает, что вместо того, чтобы быть масштабируемым, содержание уровня должно быть выведено на экран в их существующем размере и прикреплено к одной из девяти канонических позиций относительно нового кадра уровня.


NSOpenGLView незначительные изменения поведения метода

На Mac OS X 10.5 и ранее, вызов NSOpenGLView’s-setPixelFormat: метод с текущим объектом pixelFormat представления как его параметр мог заставить pixelFormat быть освобожденным, если ничто иное не сохранило его. Это было закреплено на 10,6.

То же применилось к-setOpenGLContext NSOpenGLView: метод и его параметр контекста. Это было также закреплено на 10,6. Кроме того, на 10,5 и ранее-setOpenGLContext: вызвал бы-clearGLContext, даже когда данный контекст совпал с существующим openGLContext представления. Для снижения риска поломки совместимости это поведение было сохранено на 10,6 для двоичных файлов приложения, соединенных на 10,5 и ранее. Приложения, соединенные на 10,6 и позже, будут только видеть-setOpenGLContext: вызовите-clearGLContext, когда представление будет фактически переключено на различный контекст.


Новый NSOpenGL-CGL образующие мост методы

Для обеспечения улучшенной функциональной совместимости между NSOpenGL и APIs CGL Mac OS X 10.6 завершает набор CGL-введенного инициализатора и методов получателя, предоставленных NSOpenGLContext, NSOpenGLPixelBuffer и классами NSOpenGLPixelFormat. Используя эти методы, можно инициализировать объект NSOpenGL обернуть объект соответствующего типа CGL, и/или получить CGL возражают, что это обертывается соответствующим объектом NSOpenGL.

Продолжение соглашения, за которым мы следовали предотвращения явного использования типов аргумента CGL в AppKit API, параметрах и возвращаемых значениях, вводится как недействительное * и должно быть брошено клиентами к надлежащему базовому типу (CGLContextObj, CGLPBufferObj или CGLPixelFormatObj) при необходимости. Также после нашего существующего соглашения,-init... и методы получателя, перечисленные здесь, включают имена базовых типов CGL: CGLContextObj, CGLPixelFormatObj и CGLPBufferObj. Объекты CGL сохраняются их владением обертка NSOpenGL для времени жизни обертки NSOpenGL.
@interface NSOpenGLContext
...
- (id)initWithCGLContextObj:(void *)context;
- (void *)CGLContextObj; // 10.3 and later
...
@end
@interface NSOpenGLPixelBuffer
...
- (id)initWithCGLPBufferObj:(void *)pbuffer;
- (void *)CGLPBufferObj;
...
@end
@interface NSOpenGLPixelFormat
...
- (id)initWithCGLPixelFormatObj:(void *)format;
- (void *)CGLPixelFormatObj; // 10.3 and later
...
@end

Рендеринг дерева уровня и модальный Windows

Была устранена проблема, которая могла вызвать мерцание при использовании Базового дерева Слоя анимации, представляющего в модальном окне.


Печать поддержанных уровнем представлений

На Mac OS X 10.5 до 10.5.2, пытаясь распечатать поддержанные уровнем представления произвел бы пустой вывод. Это было фиксировано для 10.5.3 и на 10,6, такой, что печать теперь продолжается таким же образом, как будто представления не были поддержаны уровнем. (Представления вовлечены в контекст печати.)

AppKit в настоящее время не предоставляет автоматическую поддержку печати для автономного, разработчик обеспечил деревья уровня. Для генерации распечатанного вывода в таких случаях необходимо использовать API Базовой Анимации CARenderer вместе с OpenGL, чтобы представить к растровому изображению, и затем распечатать результирующее изображение.


Живое расположение панели инструментов во время настройки

До SnowLeopard панели инструментов не показали бы фактическое расположение, произведенное при реконструкции, добавив или удалив элементы панели инструментов. В SnowLeopard панели инструментов должны показать свое корректное расположение даже во время настройки.

Панели инструментов больше не проверяют для некоторого eventsAs оптимизацию, NSToolbar больше не проверяет для следующих событий: NSLeftMouseDragged, NSRightMouseDragged, NSOtherMouseDragged, NSMouseEntered, NSMouseExited, NSScrollWheel, NSCursorUpdate, NSKeyDown. Кроме того, проверка для событий NSKeyUp и NSFlagsChanged задерживается в течение максимум.85 секунд в SnowLeopard с перезапуском таймера для каждого нового допускающего задержку события. Таким образом, последовательность ключевых событий не инициирует проверки вообще, или до паузы.85 секунд, или до событие кроме NSKeyUp или NSFlagsChanged обрабатывается.

Для инициирования проверки для единственной панели инструментов вручную вызовите - [NSToolbar validateVisibleItems]. Для инициирования проверки для всех панелей инструментов вызовите [NSApp setWindowsNeedUpdate:YES]

Зеркально отраженные изображения на панелях инструментов

Общая, но неправильная практика должна вызвать setFlipped:YES на изображении, что Вы планируете вовлечь зеркально отраженный графический контекст. Это неправильно, потому что, если изображение позже вовлечено в нормальный незеркально отраженный контекст, изображение будет казаться перевернутым. Однако то, Leopard и ранее содержавший ошибка, в который набор изображений на NSToolbarItem (через setImage:) проигнорировал бы их isFlipped свойство. SnowLeopard исправляет эту ошибку для приложений, скомпилированных на SnowLeopard с 10,6 SDK; в результате некоторые изображения, которые должны были нарисовать вверх тормашками в Leopard, начнут делать поэтому, когда будет перекомпилировано Ваше приложение.

Если Вы перекомпилировали свое приложение на SnowLeopard и обнаруживаете, что Ваши изображения элемента панели инструментов рисуют вверх тормашками, то это указывает вызов setFlipped:YES где-нибудь в коде. Необходимо удалить те вызовы и заменить получение изображения методами, правильно обрабатывающими зеркально отраженные контексты. Посмотрите обсуждение setFlipped: в этой Информации о версии для большего количества обсуждения.

Программы проверки правописания должны быть в каталоге Services

В SnowLeopard будут только распознаны программы проверки правописания, если они будут в одном из стандартного каталога Services (/Library/Services, ~/Library/Services, или/System/Library/Services). Это должно предотвратить проблемы совместимости с программами проверки правописания от предыдущих версий OS.

приложения setuid/setgid запрещены

Как меры безопасности, SnowLeopard предпринимает шаги для предотвращения приложений, использующих AppKit от выполнения setuid или setgid. Если AppKit обнаружит, что выполняет issetugid (), то следующее произойдет:

Менее чем 64 бита, это зарегистрирует сообщение и затем выйдет (EXIT_FAILURE).

Менее чем 32 бита, это даст пользователю шанс аутентифицировать как администратор. Если попытка успешно выполнится, то приложение будет работать как нормальное; если пользователь не будет аутентифицировать, или отмены, то это выйдет (EXIT_FAILURE). Если попытка перестанет работать, потому что диалог аутентификации не мог быть показан, то это выполнит соединенный на или после проверки. Приложениям, соединенным перед SnowLeopard, позволят работать; выйдут из приложений, соединенных на или после SnowLeopard.

Это только влияет на приложения, имеющие setuid или setgid набор бита полномочий Unix или приложения, наследовавшие этот бит от ветвления () setugid приложения. Это не влияет на приложения, запущенные через sudo, su, или обычно как корень.

Подсказки на NSTabViewItem

NSTabViewItem теперь поддерживает подсказки по инструменту пользователя относительно самих вкладок. Посмотрите заголовок NSTabViewItem.h для получения дополнительной информации.

Подчеркивание, обработанное как клавиша «минус»

Начиная с Leopard AppKit начал интерпретировать ⌘ = как ⌘ +, если никакой пункт меню не требует ключевого эквивалентного ⌘ + и нажатое =, ключ также имеет + на нем. Если нажатая клавиша имеет и _ и - в SnowLeopard эта поддержка была расширена для интерпретации ⌘ _ как ⌘-.

Новый APIs NSWorkspace

NSWorkspace теперь содержит APIs для сбора информации о метках файла, и для изменения настольного фона. NSWorkspace также содержит новый APIs для дублирования файлов и перемещения их к мусору, которые более мощны и удобны, чем более старый performFileOperation:. Существует дополнительный APIs, не упомянутый в этих примечаниях. Посмотрите заголовок класса NSWorkspace для получения дополнительной информации.

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

NSRunningApplication

SnowLeopard включает новый класс, NSRunningApplication, для проверки и управления запущенными приложениями в системе. Посмотрите заголовок NSRunningApplication в AppKit для получения дополнительной информации.

NSApplication setHelpMenu:

Новый setHelpMenu: API на NSApplication позволяет приложениям определять, какое меню получает Центр внимания для поля поиска Справки. Перо Главного меню по умолчанию, когда создается на SnowLeopard, автоматически установит Меню справки таким же образом как Меню окна.

Проверка NSMenu

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

Эквиваленты функциональной клавиши NSMenu

NSF16FunctionKey через NSF19FunctionKey теперь доступны как ключевые эквиваленты в пунктах меню.

NSMenu performActionForItemAtIndex: выделение и доступность

Метод NSMenu performActionForItemAtIndex: когда вызвано, теперь триггерное выделение в строке меню. Это также отсылает надлежащие уведомления доступности, указывающие, что был выбран элемент.

NSMenu popUpMenuPositioningItem: atLocation: inView:

NSMenu имеет новый метод для появления меню, как будто это была кнопка всплывающего меню. Это предназначается, чтобы быть заменой для функции Углерода PopUpMenuSelect (). Посмотрите заголовок NSMenu.h для получения дополнительной информации.

NSMenu confinementRectForMenu:

NSMenu имеет новый метод делегата confinementRectForMenu: на экране: позволить некоторое управление, где может раскрыться меню. Посмотрите заголовок NSMenu.h для получения дополнительной информации.

NSPopUpButtonCell поддерживает NSImageOnly

Кнопки всплывающего меню теперь поддерживают позицию изображения NSImageOnly, препятствующую тому, чтобы заголовок показал в управлении.

Ключ NSMenu эквивалентное соответствие один на событие

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

Это возможно, хотя вряд ли, что приложения зависели от старого поведения. Например, если переопределение - [NSApplication sendEvent:] измененные ключевые эквиваленты так, чтобы они соответствовали событие, тогда эти ключевые эквиваленты, больше не работали бы в SnowLeopard. Поэтому пользовательское значение по умолчанию «NSAllowMultipleKeyEquivalentSearchesPerEvent» доступно для восстановления поведения Leopard на SnowLeopard.

Приложения Nibless и меню приложения

В Leopard и ранее, приложения, попытавшиеся создать строку меню без пера, получат нежелательное тупиковое меню приложения, которое не могло быть удалено. Для работы вокруг этой проблемы над Leopard можно вызвать недокументированный setAppleMenu: метод и передача это меню приложения, как так:
[NSApp setAppleMenu:[[[NSApp mainMenu] itemAtIndex:0] submenu]];
В SnowLeopard это обходное решение является ненужным и не должно использоваться. Под SnowLeopard первое меню всегда идентифицируется как меню приложения.

Заголовок элемента меню приложения NSApplication

В Leopard первому элементу в главном меню (меню приложения) изменили бы его заголовок к пустой строке. В SnowLeopard это только сделано для приложений, соединенных на Leopard или ранее: новые приложения не будут видеть этот измененный заголовок. Заголовок этого пункта меню проигнорирован в целях дисплея - меню приложения всегда отражает имя приложения.

Элементы главного меню больше особенно не сохраняются во время отслеживания

В Leopard каждый пункт меню, содержавший прямо или косвенно в главном меню, был бы сохранен во время отслеживания меню. Это было неэффективностью, но некоторые приложения передадут пункты меню после удаления их в menuNeedsUpdate:. В SnowLeopard пункты меню в главном меню сохраняются через вызовы к menuNeedsUpdate: и затем только для приложений на 32 бита, скомпилированных на Leopard или ранее. Вы не должны зависеть от пунктов меню, сохраняемых после того, как они будут удалены из главного меню.


Меню служб визуальные изменения

Меню Services теперь Службы категорий на основе их отправлять и получают типы, и показывает значки для Служб. Меню Services также сглажено - больше подменю. При обновлении Службы для SnowLeopard удостоверьтесь, что Служба имеет значок и дескриптивный заголовок, упрощающий идентифицировать Службу в сглаженном меню. Также рассмотрите, как Ваша Служба может быть сделана контекстной, как обсуждено под Службами Contextuality. Посмотрите руководство SysServices для получения дополнительной информации.

Предпочтения служб

SnowLeopard позволяет пользователям включать или отключать отдельные Сервисы. Предпочтительная область доступна от элемента Меню свойства Служб в меню Services, и также через Установки системы.

Службы Contextuality

В SnowLeopard Службы могут появиться только в определенных контекстах. Например, Открыть URL Service появляется, только если выделенный текст содержит URL, Раскрытие в Службе Средства поиска появляется, только если путь к файлу выбран, и Настольная Служба Изображения Набора появляется, только если изображения выбраны в Средстве поиска. contextuality Службы указан в ее Info.plist. Для полного списка путей Служба может быть сделана контекстной, видеть руководство по Системным службам в документации разработчика.

Неконтекстные Сервисы, отключенные по умолчанию

В SnowLeopard Сервисы, которые не являются контекстными, отключены по умолчанию. Им можно повторно включить в Предпочтениях Служб. Поскольку контекстная функция Services является новой в SnowLeoaprd, вся существующая non-Apple Services отключены по умолчанию.

Службы, обновляющиеся для SnowLeopard, будут казаться включенными по умолчанию снова. Служба указывает, что обновляется для SnowLeopard путем добавления ключа NSRequiredContext к его Info.plist, как задокументировано в руководство по Системным службам. Службы, которые не могут ограничить себя определенными контекстами, но все еще хотеть быть включенными для SnowLeopard, могут добавить пустой NSRequiredContext и появятся по умолчанию.

Службы в контекстных меню

В SnowLeopard Службы могут появиться в контекстных меню. Контекстные меню будут обычно показывать подмножество тех Служб, доступных в меню Services.

Следующие Службы не покажут в контекстных меню, даже если они появятся в меню Services:

- Службы, уже имеющие эквивалентные нормальные пункты меню в контекстном меню, те, которые Открывают URL или Look Up in Dictionary.
- Службы, не имеющие ни одного отправление или получающие тип.
- Службы, которые не будут воздействовать на выбор (имеют не, отправляют тип), когда присутствует выбор. Например, если существует выделенный текст, Выбор Получения с Экрана не появляется в контекстных меню.
- Фиксированный список Служб, которые не могут быть сделаны контекстными и появились бы везде, те, которые Делают Новую Липкую Запись или Новую электронную почту С Присоединением.

Все другие Службы, появляющиеся в меню Services, должны также появиться в контекстных меню.

Службы могут быть потоками операций Automator

В SnowLeopard можно создать Службу из потока операций Automator. Для создания Службы потока операций Automator запустите Automator и выберите Service из списка начальных точек. Workflow Services является гражданами первого класса: они могут принять и/или возвратить данные и быть сделаны контекстные через тот же механизм как регулярные рейсы.

Workflow Services должна быть в одном из каталогов Library/Services, которые будут распознаны. Эти каталоги Service живы: добавление или удаление Службы Потока операций от ~/Library/Services/или/Library/Services/заставят меню Services быть сразу обновленным.


Выборка курсора установлена любым приложением

SnowLeopard добавляет метод NSCursor, возвращающий курсор, изображение которого и горячая точка соответствуют те из выведенного на экран в настоящее время курсора в системе, независимо от которой приложение установило, что курсор, и независимо от или Какао или Углерод APIs использовался для установки его: + [NSCursor currentSystemCursor]

Это заменяет осуждаемый QDGetCursorData API.

(Существующее + [NSCursor currentCursor] метод только возвращает курсор, установленный Вашим приложением через методы NSCursor, но не курсорами, установленными другими приложениями или курсорами, установленными Вашим приложением с помощью Углерода API.)

Отображение окна результатов поиска Средства поиска

SnowLeopard добавляет метод NSWorkspace, выводящий на экран окно результатов поиска в Средстве поиска для определенной строки запроса: - [NSWorkspace showSearchResultsForQueryString:]

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

Это эффективно заменяет HISearchWindowShow API Углерода.

Дополнения NSEvent для контроля события

Существуют новые методы класса NSEvent для того, чтобы следить за развитием событий только в Вашем собственном приложении или событиях во всех приложениях:
+ (id)addGlobalMonitorForEventsMatchingMask:(NSEventMask)mask handler:(void (^)(NSEvent *))block;
+ (id)addLocalMonitorForEventsMatchingMask:(NSEventMask)mask handler:(NSEvent *(^)(NSEvent *))block;
+ (void)removeMonitor:(id)eventMonitor;
+addLocalMonitorForEventsMatchingMask позволяет контролировать и модификация всех событий, диспетчеризирующихся через - [NSApp sendEvent:]. +addGlobalMonitorForEventsMatchingMask позволяет контролировать (но не модификация) событий ввода данных пользователем, диспетчеризированных другим приложениям, таким как события от нажатия мыши и события клавиатуры.

Настройка центра внимания для справки

Мы представили API в AppKit, чтобы позволить разработчикам реализовать поиск их собственных Данных Справки. В целом пользователи считают функциональность поиска Справки очень полезной. Однако много крупных приложений не используют Справку Apple API из-за кросс-платформенных требований. Следовательно, важные темы Справки не представлены как часть Меню справки. Новый API позволит разработчикам включать свои собственные темы Справки и в полной мере пользоваться функцией Help.

В Вашем приложении Вы реализуете  протокол NSUserInterfaceItemSearching и затем регистрируете Ваш объект в - [NSApplication registerUserInterfaceItemSearchHandler:]. См. NSUserInterfaceItemSearching.h для API.

NSObjects реализует awakeFromNib

На Mac OS X 10.6 и позже, NSObject обеспечивает реализацию awakeFromNib. Это означает, что можно безопасно вызвать через к [супер awakeFromNib] в переопределенной реализации при работе Mac OS X 10.6 и позже.


Уведомление для Людей, Ищущих-viewWillLoad и Методы-viewDidLoad в NSViewController

Даже при том, что NSWindowController имеет-windowWillLoad, и методы-windowDidLoad для Вас для переопределения класса NSViewController, представленного в Mac OS 10.5, не имеет соответствующего-viewWillLoad и методов-viewDidLoad. Можно переопределить - [NSViewController loadView] для настройки то, что сразу происходит прежде или сразу после загрузки пера, сделанной контроллером представления.

Новая поддержка параллельного документа, открывающегося в NSDocument

NSDocument теперь имеет возможность считать документы одновременно, с помощью фоновых потоков. Новый метод класса был добавлен к NSDocument, чтобы дать Вам контроль над этим:
+ (BOOL)canConcurrentlyReadDocumentsOfType:(NSString *)typeName;
Возвратитесь, могут ли экземпляры класса получения одновременно считать документы указанного типа. Реализация по умолчанию этого метода возвращается НЕТ. Можно переопределить его для возврата YES для включения параллельного открытия документов, но необходимо удостовериться, что документ, читая код может быть безопасно выполнен одновременно в неосновных потоках.

Обратите внимание на то, что механизм NSUndoManager для того, чтобы автоматически создать одну группу на событие UI не сосуществует очень хорошо с использованием NSUndoManager на неосновных потоках. Необходимо отключить регистрацию отмены во время чтения документа, которое является хорошей идеей даже в отсутствие параллелизма. Посмотрите, например, SKTDocument.m в/Developer/Examples/Sketch.

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

Уведомление для Сверхнаездников - [NSDocumentController openDocumentWithContentsOfURL:display:error:]

Начиная с введения - [NSDocumentController openDocumentWithContentsOfURL:display:error:] в Mac OS 10.4 было просто замаскировать ошибки, или в коде Вашего приложения или в его файле Info.plist, той причине - [NSDocumentController typeForContentsOfURL:error:] Также представленный в Mac OS 10.4, для возврата ноля и ошибки неуместно. Реализация по умолчанию-openDocumentWithContentsOfURL:display:error: было единственное место в AppKit от который-typeForContentsOfURL:error: часто вызывался поэтому, если бы Вы переопределили прежний метод и не вызывали супер или последний метод в Вашем переопределении, то Вы не заметили бы таких ошибок. С введением поддержки параллельного документа, открывающегося в Mac OS 10.6 существуют теперь другие места в AppKit от который-typeForContentsOfURL:error: вызывается. Для обратной совместимости на уровне двоичных кодов с Mac OS 10.5 и ранее это сделано только в приложениях, соединенных против Mac OS 10.6. Если Вы замечаете новый документ вводные проблемы в Вашем приложении, когда Вы начинаете соединять его против Mac OS 10,6 SDK, Вы могли бы хотеть начать отлаживать путем наблюдения что-typeForContentsOfURL:error: возвращается.

Уведомление для Сверхнаездников - [NSDocument близко]

Просто переопределяя - [NSDocument близко] обычно не достаточен во многих целях, потому что он часто не вызывается во время завершения приложения. Это для производительности и нет никаких планов изменить это в будущем. Лучше избегать требовать вида очистки ресурса, которая должна быть сделана во время закрытия документа, но, если это неизбежно в Вашем приложении, попытка инициировать такую очистку для документов, которые все еще открыты в Вашем-applicationWillTerminate делегата приложения: метод в дополнение к переопределению - [NSDocument близко]. Оба - [NSDocument близко] переопределения и-applicationWillTerminate: методы делегата приложения между прочим противоречащие новому «Быстрому Уничтожению Приложений» механизм, описанный в информации о версии Основы и который мы хотели бы, чтобы Вы приняли.

Новая возможность для настройки панелей сохранения, представленных NSDocument

В более ранних версиях Mac OS X не было никакого пути к подклассу NSDocument для настройки начального значения поля имени файла в представленных панелях сохранения, даже путем переопределения - [NSDocument prepareSavePanel]. В Mac OS 10.6 NSDocument теперь используют методы NSSavePanel, добавленные в Mac OS 10.6, таким образом, это может позволить этот вид настройки. Если Вы переопределяете-prepareSavePanel и отправляете-setNameFieldStringValue: сообщение к панели NSDocument сохранения не перезапишет значение, это установлено. Это также не перезаписывает набора значений путем отправки-setDirectoryURL: к панели сохранения в Вашем переопределении - [NSDocument prepareSavePanel].

Новая поддержка «сохраняет как PDF …» в печати NSDocument

- [NSDocument printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:] имеет новое поведение в Mac OS 10.6: если переданный - в словаре настроек печати будет иметь запись NSPrintJobDisposition, значением которой является NSPrintSaveJob, указывая, что печатные страницы должны быть записаны в файл PDF, но никакой (новый) NSPrintJobSavingURL или NSPrintSavePath (старый, осуждаемый) запись, указывающая, где файл PDF должен быть записан, то NSDocument представит панель сохранения, спрашивая пользователя, где должен быть сохранен файл PDF. Посмотрите TextEdit - [Документ saveDocumentAsPDFTo:] для примера использования этого.

Исправления ошибок в NSDocumentController

В более ранних версиях Mac OS X - [Документы NSDocumentController] просто возвратили указатель на его внутренний массив документов, которые могли измениться, поскольку документы были открыты или закрыты, требуя invokers делать копию для перечисления в то время как заключительные документы. Это было ошибкой и было фиксировано в Mac OS 10.6. Копия массива документов (автовыпущенный, конечно) теперь возвращается.

В Mac OS 10.5 - [NSDocument displayNameForType:], когда передано UTI для типа, соответствующего другому типу, для которого приложение также имеет запись CFBundleDocumentTypes, мог возвратить имя дисплея для того другого типа. Это было ошибкой и было фиксировано в Mac OS 10.6.

В Mac OS 10.5 - [NSDocument displayNameForType:], когда передано UTI, для которого приложение имеет запись CFBundleDocumentTypes, включающую подзапись CFBundleTypeName, возвратил бы ноль, если бы не было никакой соответствующей записи InfoPlist.strings. Это было ошибкой и было фиксировано в Mac OS 10.6. Если нет никакой соответствующей записи InfoPlist.strings, теперь нелокализованное значение записи CFBundleTypeName возвращается.

В Mac OS 10.5 - [NSDocument typeFromFileExtension:] возвратил бы непредсказуемые значения когда переданный ноль. Это означало что - [NSDocumentController typeForContentsOfURL:error:] мог также возвратить непредсказуемые значения, в приложениях, в которых не все записи Info.plist CFBundleDocumentTypes имеют записи LSItemContentTypes. (См. описание как-typeForContentsOfURL:error: работы в наше время в разделе «Support for UTIs in NSDocumentController» информации о версии AppKit для Mac OS 10.5.) Это было ошибкой и было фиксировано в Mac OS 10.6.

Новая поддержка URLs и хорошего сообщения об ошибке в NSFileWrapper

NSFileWrapper был модернизирован в Mac OS 10.6 и теперь торгует URLs вместо путей и сообщает об ошибках с помощью NSError. Эти старые методы были осуждены:
- (id)initWithPath:(NSString *)path;
- (id)initSymbolicLinkWithDestination:(NSString *)path;
- (NSString *)symbolicLinkDestination;
- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)atomicFlag updateFilenames:(BOOL)updateFilenamesFlag;
- (BOOL)needsToBeUpdatedFromPath:(NSString *)path;
- (BOOL)updateFromPath:(NSString *)path;
- (NSString *)addFileWithPath:(NSString *)path;
- (NSString *)addSymbolicLinkWithDestination:(NSString *)path preferredFilename:(NSString *)filename;
Эти новые методы были опубликованы:
- (id)initWithURL:(NSURL *)url options:(NSFileWrapperReadingOptions)options error:(NSError **)outError;
- (id)initSymbolicLinkWithDestinationURL:(NSURL *)url;
- (NSURL *)symbolicLinkDestinationURL;
- (BOOL)writeToURL:(NSURL *)url options:(NSFileWrapperWritingOptions)options originalContentsURL:(NSURL *)originalContentsURL error:(NSError **)outError;
- (BOOL)matchesContentsOfURL:(NSURL *)url;
- (BOOL)readFromURL:(NSURL *)url options:(NSFileWrapperReadingOptions)options error:(NSError **)outError;
(Мы не публикуем новые замены NSURL/NSError-using для-addFileWithPath: и-addSymbolicLinkWithDestination: потому что новые методы фактически не были бы необходимы, и старые методы были так непопулярны.)

Новые опции NSFileWrapperWritingAtomic и NSFileWrapperWritingWithNameUpdating были опубликованы для использования с-writeToURL:options:originalContentsURL:error:. Они соответствуют атомарно: и updateFilenames: параметры, соответственно,-writeToFile:atomically:updateFilenames: за исключением того, что NSFileWrapperWritingWithNameUpdating, в отличие от updateFilenames:YES, только вызывает-setFilename: быть отправленным в дочерние обертки файла, не сам получатель.

См. комментарии в <AppKit/NSFileWrapper.h> для получения дополнительной информации.

Новая поддержка инкрементной записи в NSFileWrapper

Новый-writeToURL:options:originalContentsURL:error: упомянутый выше метод отличается от теперь осуждаемого-writeToFile:atomically:updateFilenames: метод в этом в имеет дополнительный параметр, в котором можно передать URL, определяющий местоположение предыдущей версии сохраняемого пакета файла. Когда значение того параметра не является нолем, NSFileWrapper пытается избежать ненужного I/O путем простой записи жестких ссылок на файлы вместо того, чтобы фактически выписать их содержание.

Новые опции чтения в NSFileWrapper

Новый-initWithURL:options:error: и-readFromURL:options:error: упомянутые выше сообщения имеют опции: параметры. Возможные варианты:

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

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

Новая поддержка сохранения метаданных в NSFileWrapper

В более ранних версиях Mac OS X единственные атрибуты файла, которые NSFileWrapper когда-либо пытался сохранить при записи, были датой модификации файла и полномочиями POSIX. В Mac OS 10.6 это теперь читает и пишет эти атрибуты:
• Создание и даты модификации
• Сокрытие расширения файла
• Создатель HFS и коды типа файла
• Полномочия POSIX
• Расширенные атрибуты
• Ветвь ресурсов

Поскольку NSFileWrapper торгует тем же видом словарей атрибута как NSFileManager, можно указать значения первых четырех видов атрибута путем вызова-setFileAttributes: передавая словарь со значениями для этих ключей:
• NSFileCreationDate и NSFileModificationDate
• NSFileExtensionHidden
• NSFileHFSCreatorCode и NSFileHFSTypeCode
• NSFilePosixPermissions
Будьте осторожны при использовании-setFileAttributes:. Это не добавляет к набору получателя атрибутов файла, это полностью заменяет его.

Исправления ошибок в NSFileWrapper

В более ранних версиях Mac OS X NSFileWrapper не принимал во внимание факт, что два элемента, имена которых отличаются только случаем, не могут оба быть записаны в тот же каталог в большинстве файловых систем без одной перезаписи другой. Эта ошибка была исправлена в Mac OS 10.6. - [NSFileWrapper addFileWrapper:], например, теперь создаст новое уникальное имя файла для дочернего элемента, предпочтительное имя файла которого «TestyMCTest.test», если уже существует дочерний элемент, уникальное имя файла которого «TestyMcTest.test».

В более ранних версиях Mac OS X, отправляющего-writeToFile:atomically:updateFilenames: к NSFileWrapper сделал бы три вещи для updateFilenames:YES:
• Отправьте-setFilename: к получателю и его дочерним оберткам файла.
• Перечитайте атрибуты файла получателя и его дочерних оберток от элементов файловой системы, просто записанных.
• Повторно отобразите содержание любых регулярных оберток файла к соответствующим файлам, просто записанным.
Последние две вещи не были правильными, и в Mac OS 10.6 они больше не делаются. Переотображение регулярного содержания файла в определенных доставленных неприятностях с приложениями, содержащими файлы, открытые в удивительные времена (память, отображающая файл эффективно, открывает его). updateFilenames:YES теперь правые дела-setFilename: быть отправленным в получатель и его дочерние обертки файла.

Новое Аннулирование Курсора в - [NSSplitView adjustSubviews]

В более ранних версиях Mac OS X - [NSSplitView adjustSubviews] не лишал законной силы курсор представления разделения. Это мешало правильно анимировать расположение делителя путем простой отправки-setFrameSize: к результатам отправки - аниматор к двум подпредставлениям по обе стороны от делителя и разрешению-adjustSubviews вызывается неоднократно во время анимации. В Mac OS 10.6 - [NSSplitView adjustSubviews] теперь вызывает [[сам окно] invalidateCursorRectsForView:self], таким образом, курсор по делителю всегда корректен после такой анимации.

Исправление ошибки в - [NSSplitView minPossiblePositionOfDividerAtIndex:]

Mac OS 10.5 добавил новый-minPossiblePositionOfDividerAtIndex: метод к NSSplitView, а также возможности скрыть делители.-minPossiblePositionOfDividerAtIndex: когда тот делитель hidable, когда передано индекс делителя 0, как предполагается, возвращает нуль минус толщина делителя. (Концептуально пользователь может перетащить самый верхний или крайний левый делитель сразу же главный или левый край представления разделения, если это hidable, и позиция делителя является своим главным или левым краем.) Когда подпредставление выше или налево от делителя было разрушено, в Mac OS 10.5 это вместо этого возвратило нуль. Это было ошибкой и было фиксировано в Mac OS 10.6.

Изменение в вызове делегата NSSplitView ограничительные методы для скрытых делителей

В Mac OS 10.5 NSSplitView передал бы то же самое значение, возвращенное-minPossiblePositionOfDividerAtIndex: или-maxPossiblePositionOfDividerAtIndex: при отправке-splitView:constrainMinCoordinate:ofSubviewAt: или-splitView:constrainMaxCoordinate:ofSubviewAt: соответственно, делегату представления разделения. Поскольку то значение принимает во внимание факт, что скрытый делитель эффективно перемещаем от края представления разделения, это было бы удивительно маленьким или большим, соответственно, для hidable делителей. Это мешало указывать минимальные размеры подпредставлений с помощью относительно простого метода, описанного в <AppKit/NSSplitView.h>. Это было изменено в Mac OS 10.6. Значение передало-splitView:constrainMinCoordinate:ofSubviewAt: или-splitView:constrainMaxCoordinate:ofSubviewAt: теперь то же независимо от того, hidable ли соответствующий делитель. Для обратной совместимости на уровне двоичных кодов это только сделано в приложениях, соединенных против Mac OS 10.6 или позже.

Улучшения NSPrintInfo

Чтобы позволить Вам легко использовать в своих интересах KVO-соответствие NSPrintInfo (не имея необходимость наблюдать словарь атрибутов NSPrintInfo), методы доступа были опубликованы для атрибута масштабирования печати:
- (void)setScalingFactor:(CGFloat)scalingFactor;
- (CGFloat)scalingFactor;
NSPrintInfo теперь так же KVO-совместим для «scalingFactor», как это для «paperSize», «ориентации», и т.д.

Поскольку мы стандартизируем на NSURL как представление расположений файлов в Mac OS 10.6, новый ключ в словарь атрибутов был опубликован:
NSString *NSPrintJobSavingURL;
Значение должно быть NSURL, содержащим расположение, к которому файл задания будет сохранен для использования, когда расположением задания будет NSPrintSaveJob.

  Ключ NSPrintSavePath был осужден.

В более ранних версиях Mac OS X не было никакого способа для Вас указать, что должно быть скрыто расширение имени файла, записанного для расположения задания NSPrintSaveJob. Был опубликован новый ключ для этого:
NSString *NSPrintJobSavingFileNameExtensionHidden;
Значением должен быть булев NSNumber. Значение по умолчанию НЕТ.

Новые подсказки стиля задания в NSPrintPanel

В Mac OS 10.6 две новых подсказки стиля задания были опубликованы для использования с - [NSPrintPanel setJobStyleHint:]. Они соответствуют новому kPMPresetGraphicsTypeAll Базовой Печати и kPMPresetGraphicsTypeNone графическим типам, соответственно. Нет никакой новой подсказки стиля задания, соответствующей kPMPresetGraphicsTypeGeneral Базовой Печати. Нулевая подсказка стиля задания все еще означает ту же вещь как это.
NSString *const NSPrintAllPresetsJobStyleHint;
NSString *const NSPrintNoPresetsJobStyleHint;


Лучший предварительный просмотр

Предварительный просмотр на панели печати теперь рисует Границу уважения, N-Up, Зеркало, Реверса Пэйджа Оринтэйшна и Пэйджа Рэнджа.

Кроме того, текст/средства управления диапазона страницы под предварительным просмотром показывает физические страницы, которые будут распечатаны после учета настроек пользователя для N-Up, Диапазона Страницы, и т.д...


Печать просто выбранного содержания документа

NSPrintPanel может теперь дополнительно добавить опцию радио «Выбора» к списку опций диапазона страницы (Все, From:To: Выбор). Для включения «Выбора» как пользователя выбираемый диапазон страницы в панели печати Добавьте NSPrintPanelShowsPrintSelection к опциям NSPrintPanel при установке работы печати.
- (NSPrintOperation *)printOperationWithSettings:(NSDictionary *)printSettings error:(NSError **)outError {
   ...
   NSPrintOperation *op = [NSPrintOperation printOperationWithView:...
   NSPrintPanel *printPanel = [op printPanel];
   [printPanel setOptions:[printPanel options] | NSPrintPanelShowsPrintSelection];
  ...
}
Для печати только выбора представление, предоставленное NSPrintOperation, должно проверить isSelectionOnly свойство printInfo и корректироваться соответственно при определении диапазона страницы (knowsPageRange:) и рисующий (drawRect:).
- (BOOL)knowsPageRange:(NSRangePointer)aRange {
   NSPrintOperation *curPrintOperation = [NSPrintOperation currentOperation];
   BOOL printSelectionOnly = [[curPrintOperation printInfo] isSelectionOnly];
   ...
}
- (void)drawRect:(NSRect)rect {
   BOOL printSelectionOnly = NO;
   if(![NSGraphicsContext currentContextDrawingToScreen]) {
     NSPrintOperation *curPrintOperation = [NSPrintOperation currentOperation];
      BOOL printSelectionOnly = [[curPrintOperation printInfo] isSelectionOnly];
  }
   ...
}

NSBrowser - Элемент, Основанный только функции

NSBrowser больше не кэширует содержание каждого столбца. Вместо этого это зависит от источника данных для обеспечения быстрых результатов. Одна возможность, которую это включает, состоит в том, что тот же объект может теперь появиться в многократных столбцах. Последствие этого - то, что был удален следующий новый API:
- (NSIndexPath *)indexPathForItem:(id)item;
- (id)parentForItem:(id)item;
- (void)reloadItem:(id)item reloadChildren:(BOOL)flag;
reloadItem:reloadChildren: метод был заменен:
- (void)reloadDataForRowIndexes:(NSIndexSet *)rowIndexes inColumn:(NSInteger)column;
Следующий метод:
- (id)itemAtRow:(NSInteger)row column:(NSInteger)column;
был заменен следующим для обеспечения лучшей непротиворечивости именами методов:
- (id)itemAtRow:(NSInteger)row inColumn:(NSInteger)column;
Можно теперь указать высоту строки:
- (void)setRowHeight:(CGFloat)height;
- (CGFloat)rowHeight;
Также делегат может указать переменные высоты строки путем реализации следующего метода:
- (CGFloat)browser:(NSBrowser *)browser heightOfRow:(NSInteger)row inColumn:(NSInteger)columnIndex;
Делегат должен сообщить NSBrowser изменений высоты строки через этот метод:
- (void)noteHeightOfRowsWithIndexesChanged:(NSIndexSet *)indexSet inColumn:(NSInteger)columnIndex;

NSBrowser - Общий

Обновленный комментарий заголовка для-browser:sizeToFitWidthOfColumn: сообщать разработчикам, что они могут выбрать из предоставления ширины столбца для любого определенного столбца путем возврата-1. Когда NSBrowser получит-1 возвращаемое значение, он сделает свое собственное определение ширины столбца, как будто делегат не реализовывал этот метод.

Новый API, чтобы заставить столбец/строку в точке и один получать кадр.

Находит строку и столбец расположенными в 'точке', возвращая YES, если оба могут быть найдены. Если строка не существует в 'точке', то-1 установлен для строки. Если столбец не существует в 'точке', то-1 установлен для столбца. 'точка', как ожидают, будет в системе координат NSBROWSER. *строкой и *столбец может быть NULL. Корректное значение BOOL возвращается и не NULL *строка или *, столбец (если таковые имеются) заполнен в.
- (BOOL)getRow:(NSInteger *)row column:(NSInteger *)column forPoint:(NSPoint)point;
Возвращает кадр строки в 'строке' / 'столбец' включая область для расширяемой стрелки. Возвращенный NSRect находится в координатном пространстве NSBrowser.
- (NSRect)frameOfRow:(NSInteger)row inColumn:(NSInteger)column;

MultiTouch

В дополнение к жестам разработчики могут теперь получить отдельные касания к мультисенсорной сенсорной панели. Необходимо явно выбрать - в том, для получения новых сенсорных методов респондента. Касания могут или могут не переместить курсор через отдельные события от нажатия мыши. Событие от нажатия мыши может произойти немного прежде или после его связанного сенсорного события.

То же событие, содержащее касания, может также содержать жест. Жест методы NSResponder вызывают в дополнение к новым сенсорным методам NSResponder.


MultiTouch - NSView

Новые методы на NSView позволяют приложению выбирать в получить касания. По умолчанию представления не принимают сенсорные события:
- (void)setAcceptsTouchEvents:(BOOL)flag;
- (BOOL)acceptsTouchEvents;
В некоторых случаях пользователь может оставить ползунок или другое касание к устройству. Если устройство может обнаружить это (MacBook со стеклянной сенсорной панелью) тогда, это отметит касание как отдых. По умолчанию эти касания не поставлены и не включены в набор события касаний. Касания могут перейти в и из отдыха в любое время. Если представление не хочет restingTouches, начался / законченные события моделируются как сенсорный переход от отдыха до активного и наоборот. В общем отдыхе должны быть проигнорированы касания.
- (void)setWantsRestingTouches:(BOOL)flag;
- (BOOL)wantsRestingTouches;

MultiTouch - NSEvent

Существует новый метод на NSEvent для извлечения касаний из события.

Это только допустимо для событий жеста (Жест, Увеличьте, Сильно ударьте, Вращайтесь, и т.д.). Представление может получить все касания, связанные с жестом, не переопределяя сенсорные методы респондента. Возвращаются касания, предназначающиеся для представления или любого из потомков представления. Ноль передачи как представление для получения касаний независимо от их предназначенного представления.
- (NSSet *)touchesMatchingPhase:(NSTouchPhase)phase inView:(NSView *)view;

MultiTouch - NSTouch

NSTouch является снимком определенного касания в некотором экземпляре своевременно. Это очень отличается от iPhone UITouch, сохраняющийся для жизни касания и изменяющийся системой во время ее жизни. Свойство идентификационных данных используется для следования за определенным касанием через его время жизни.

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

NSTouchPhaseBegan:
Палец коснулся устройства. Или, покоящееся касание перешло к активному касанию, и покоящиеся касания не разыскиваются иерархией представления.

NSTouchPhaseMoved:
Палец углубил устройство.

NSTouchPhaseStationary:
Палец касается устройства, но не переместился начиная с предыдущего события.

NSTouchPhaseEnded:
Пальцем пошевелили с экрана. Или, активное касание перешло к покоящемуся касанию, и покоящиеся касания не разыскиваются иерархией представления.

NSTouchPhaseCancelled:
Система отменила отслеживание для касания, как тогда, когда (например), окно, связанное с касанием, оставляет ключ или деактивировано.
enum {
  NSTouchPhaseBegan      = 1 << 0,
  NSTouchPhaseMoved      = 1 << 1,
  NSTouchPhaseStationary   = 1 << 2,
  NSTouchPhaseEnded      = 1 << 3,
  NSTouchPhaseCancelled    = 1 << 4,
  NSTouchPhaseTouching    = NSTouchPhaseBegan | NSTouchPhaseMoved | NSTouchPhaseStationary,
  NSTouchPhaseAny       = NSUIntegerMax
};
typedef NSUInteger NSTouchPhase;
В отличие от iPhone, объекты NSTouch не сохраняются для жизни касания.
@interface NSTouch : NSObject <NSCopying>
Используйте свойство идентификационных данных для отслеживания изменений в определенном касании во время жизни касания. В то время как сенсорные идентификационные данные могут быть снова использованы, они уникальны во время жизни касания, даже когда присутствуют многократные устройства.Примечание: объекты идентификационных данных реализуют протокол NSCopying так, чтобы они могли использоваться в качестве ключей в NSDictionary. Используйте isEqual: сравнить два сенсорных идентификационных данные.
@property(readonly) id<NSObject, NSCopying> identity;
@property(readonly) NSTouchPhase phase;
Нормализованная, абсолютная позиция [0,1] из касания к устройству, где (0, 0) нижняя левая из поверхности устройства.
@property(readonly) NSPoint normalizedPosition;
@property(readonly) BOOL isResting;
Следующее является свойствами NSTouch, но они действительно описывают свойства базового сенсорного устройства.

Цифровой преобразователь, генерировавший касание. Полезный для различения касаний, происходящих от сценария многократного устройства:
@property(readonly) id device;
Диапазон сенсорного устройства в точках (72 пкс/дюйм).Примечание: 0,0 нижняя левая из поверхности:
@property(readonly) NSSize deviceSize;

MultiTouch - NSResponder

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

Примечание: Для больше чем одного из следующих методов возможно быть вызванным для того же события. Порядок, который отправляются методы, не гарантируется.
/* A new set of touches has been recognized. To get the set of touches that began for this view (or descendants
of this view): [event touchesMatchingPhase:NSTouchPhaseBegan inView:self]; Note: this is not always the point
of contact with the touch device. A touch that transitions from resting to active may be part of a Began set.
*/
- (void)touchesBeganWithEvent:(NSEvent *)event;
/* One or more touches have moved. To get the set of touches that moved for this view (or descendants
of this view): [event touchesMatchingPhase:NSTouchPhaseMoved inView:self];
*/
- (void)touchesMovedWithEvent:(NSEvent *)event;
/* A set of touches have been removed. To get the set of touches that ended for this view (or descendants
of this view): [event touchesMatchingPhase:NSTouchPhaseEnded inView:self]; Note: this is not always the point
of removal with the touch device. A touch that transitions from active to resting may be part of an Ended set.
*/
- (void)touchesEndedWithEvent:(NSEvent *)event;
/* The System has cancelled the tracking of touches for any reason.
*/
- (void)touchesCancelledWithEvent:(NSEvent *)event;

NSDatePicker

Пользовательское редактирование текстового средства выбора даты было значительно улучшено. Редактирование поля даты/времени теперь заменяет содержание поля с новыми цифрами. После каждого изменения цифры существует короткий срок, где пользователь может добавить больше или удалить цифры (сбрасывающий время для каждого изменения). Как только тайм-аут произошел, будущие редактирования к полю заменяют текущую стоимость поля. Новое происходящее значение фиксируется, если бы таймер заканчивается или при добавлении еще, что цифры привели бы к недопустимому значению для того поля. Отметьте, если новое значение фиксируется, прежде чем время истекает, новые редактирования не могут произойти, пока тайм-аут не истекает. Возвратите фиксации текущие изменения, и сводит время на нет. Esc возвращается любой не фиксировавшее редактирование. Удалите удалит цифру, но эффективно устанавливает бесконечный таймер до другого изменения, или перемещение фокуса UI происходит.

MultiTouch - NSEvent

Подтипом сгенерированных событий от нажатия мыши касания является теперь NSTouchEventSubtype. Это полезно в при определении, когда проигнорировать события от нажатия мыши в пользу сенсорных событий, когда они оба становятся сгенерированными. Это не применимо к scrollWheel событиям.


Поддержка жеста

Мы добавили типы событий и методы респондента для жестов, как сгенерировано сенсорной панелью на MacBook Air и последнем поколении MacBook Pro.

Дополнения NSEvent для поддержки жеста

    NSEventTypeGesture = 29
    NSEventTypeMagnify = 30,
    NSEventTypeSwipe = 31,
    NSEventTypeRotate = 18,
    NSEventTypeBeginGesture = 19,
    NSEventTypeEndGesture = 20
Событие типа, NSEventTypeGesture используется для события жеста, не продвинутого на его собственный тип события. Событие этого типа имеет дополнительную информацию в наличии в CGEventRef.
Событие типа NSEventTypeBeginGesture и событие типа NSEventTypeEndGesture будет сгенерировано синтаксическим анализатором в запуске и конце потока жестов, несколько аналогичных NSMouseDown и NSMouseUp. Приложения могут использовать NSEventTypeEndGesture, чтобы фиксировать изменение, например сделать более подробное получение или зарегистрировать работу отмены.

Событие типа NSEventTypeMagnify, NSEventTypeRotate, NSEventTypeSwipe, NSEventTypeBeginGesture или NSEventTypeEndGesture будет поставлено представлению под мышью в ключевом окне через методы респондента, описанные ниже.

Можно попросить определенный тип события с помощью-nextEventMatchingMask: или-nextEventMatchingMask:untilDate:inMode:dequeue:.


Эти средства доступа допустимы для всех событий. Когда событие жеста поставлено - [NSApplication sendEvent:] или исключенный из очереди через - [NSApplication nextEventMatchingMask:], это еще не имеет цели окна. В этой точке - окно является нолем, и-windowNumber 0, и-locationInWindow находится в координатах экрана. Прежде, чем диспетчеризировать - [NSWindow sendEvent:], NSApplication ставит цель окна в конечном счете.
- (NSEventType)type;
- (NSUInteger)modifierFlags;
- (NSTimeInterval)timestamp;
- (NSWindow *)window;
- (NSInteger)windowNumber;
- (NSGraphicsContext*)context;
- (NSPoint)locationInWindow;

Существует новое средство доступа, - увеличение, которое возвратит желаемое увеличение для события NSEventTypeMagnify как часть. Увеличение 1 должно быть интерпретировано как увеличение масштабного коэффициента на 100%, например, от 100% до 200%, и отрицательное увеличение должно уменьшить масштабный коэффициент с некоторым минимальным масштабом, осуществленным так, чтобы Вы никогда не могли добраться до 0, например.
- (CGFloat)magnification;
Существующее - средство доступа вращения допустимо для событий NSEventTypeRotate. Вращение относительно, и измеряется в градусах, против часовой стрелки.

Для NSEventTypeSwipe-deltaX и-deltaY средства доступа возвратят сильно ударить направление. non-0 deltaX будет представлять горизонталь, сильно ударяют,-1 для сильно ударяют, право и 1 для сильно ударяет оставленное. non-0 deltaY будет представлять вертикаль, сильно ударяют,-1 для сильно ударяют вниз, и 1 для сильно ударяют.

Ключевые эквиваленты

Фиксация, чтобы препятствовать тому, чтобы события NSKeyUp были отправлены в performKeyEquivalent: был расширен для включения всех приложений, не только основанных на Leopard или позже.

NSTrackingArea

Было изменение в возвращаемом значении - [NSTrackingArea userInfo]. Когда NSTrackingArea установлен реализацией - [NSView addTrackingRect:owner:userData:assumeInside:], - [NSTrackingArea userInfo] возвратит ноль, а не данный userData, который, как объявляют, является указателем и не гарантирован быть объектом. Использование NSTrackingArea для этого метода является подробностью реализации, и приложения обычно получают userData от mouseEntered: или mouseExited: событие. Возврат ноля от - [NSTrackingArea userInfo] для этого случая позволяет реализации mouseEntered: и mouseExited: отправить сообщения в userInfo, чтобы определить, предназначается ли событие для определенного объекта в иерархии классов. До этого изменения не было никакой гарантии, что возврат userInfo был доступным объектом.

При установке курсора для текущего расположения мыши, например после прокрутки или при создании ключа окна, NSWindow теперь отправляет cursorUpdate: через цепочку респондента. Если никакой респондент reponds к cursorUpdate: cursorRect добавил с addCursorRect:cursor: будет использоваться если под мышью. Это изменение позволяет cursorUpdate: сосуществовать с addCursorRect:cursor: но имеет импликации совместимости на уровне двоичных кодов. В частности если представление вызывает invalidateCursorRectForView: от hitTest: это может привести к повторяющемуся образцу лишения законной силы курсора rects и hitTesting для установки текущего курсора. Поэтому изменение для использования cursorUpdate: ограничивается приложениями, соединенными на SnowLeopard или позже.

Дополнения NSResponder для поддержки жеста

Следующие методы NSResponder были добавлены. Сообщение будет отправлено в представление под мышью в ключевом окне.
- (void)magnifyWithEvent:(NSEvent *)event;
- (void)rotateWithEvent:(NSEvent *)event;
- (void)swipeWithEvent:(NSEvent *)event;
- (void)beginGestureWithEvent:(NSEvent *)event;
- (void)endGestureWithEvent:(NSEvent *)event;

NSEvent

Существуют теперь методы класса NSEvent, обеспечивающие доступ к некоторым параметрам настройки системы. Поскольку это средства доступа для параметров настройки системы, переопределения не будут иметь никакого эффекта.
/* the time in which a second click must occur in order to be considered a doubleClick */
+ (NSTimeInterval)doubleClickInterval;
/* the time for which a key must be held down in order to generate the first key repeat event */
+ (NSTimeInterval)keyRepeatDelay;
/* the time between subsequent key repeat events */
+ (NSTimeInterval)keyRepeatInterval;
Существуют также методы класса NSEvent для получения флагов модификатора и состояния кнопки мыши за пределами потока событий.
+ (NSUInteger)modifierFlags;
+ (NSUInteger)pressedMouseButtons;

NSWorkspace

Мы добавили уведомления NSWorkspace для следа дисплея и сна. Немного приложений, вероятно, будут интересоваться этими уведомлениями, но они могут быть полезны для определенных основанных на аппаратных средствах решений получения, например в OpenGL.
NSString * const NSWorkspaceScreensDidSleepNotification;
NSString * const NSWorkspaceScreensDidWakeNotification;
Мы также добавили уведомление NSWorkspace для переключателей пространства. Это уведомление отправляется после того, как переключатель пространства произошел.
NSString * const NSWorkspaceActiveSpaceDidChangeNotification;

NSWindow

Можно теперь спросить, находится ли окно на активном пространстве. Если окно будет внеэкранным вследствие того, чтобы быть минимизируемым или скрытый, например, то-isOnActiveSpace возвратит YES, если упорядочивание окна на экране упорядочит его на активном пространстве. - (BOOL) isOnActiveSpace;

Существует метод класса NSWindow, +windowNumbersWithOptions: для получения чисел окна для всех экранных окон. По умолчанию, +windowNumbersWithOptions: возвращает числа окна для видимых окон, принадлежащих обработке вызовов на активном пространстве. Можно также запросить числа окна на все видимые окна, независимо от владельца, и для окон на всех пробелах.
enum {
   NSWindowNumberListAllApplications = 1 << 0,
   NSWindowNumberListAllSpaces = 1 << 4
};
+ (NSArray *)windowNumbersWithOptions:(NSWindowNumberListOptions)options;
Существует также метод класса получить окно, которое было бы поражено mouseDown в данном screenPoint. Передайте non-0 windowNumber для запуска поиска ниже того окна в z-порядке. Поскольку этот метод использует те же правила в качестве mouseDown hitTesting, окна с прозрачностью в данной точке и окна, игнорирующие mouseEvents, не будут возвращены.
+(NSInteger)windowNumberAtPoint:(NSPoint)point belowWindowWithWindowNumber:(NSInteger)windowNumber;
Существует новый API NSWindow для переопределения поведения по умолчанию, где лист или модальная панель отключают завершение приложения. - (BOOL) preventsApplicationTerminationWhenModal;
- (void)setPreventsApplicationTerminationWhenModal:(BOOL)flag;
Мы добавили уведомление, методы делегата, и средство доступа окна для живого изменяет размеры. Уведомление и соответствующие методы делегата отправляются, когда живое окно изменяет размеры, запускается, делают к mouseDown в изменять размеры углу, и когда это заканчивается вследствие mouseUp.
NSString * const NSWindowWillStartLiveResizeNotification;
NSString * const NSWindowDidEndLiveResizeNotification;
Делегат окна может реализовать требуемые методы ниже, чтобы быть автоматически зарегистрированным для соответствующего уведомления на окне.
- (void)windowWillStartLiveResize:(NSNotification *)notification;
- (void)windowDidEndLiveResize:(NSNotification *)notification;
В то время как мышь снижается в изменять размеры углу,-inLiveResize возвратит YES.
- (BOOL)inLiveResize;
Можно теперь вызвать setFrame:display:animate: на листе, чтобы заставить лист изменять размеры, оставаясь правильно расположенным на окно документа. Окно документа переместится при необходимости для показа листа абсолютно на экране. Анимационным флагом должен быть YES для инициирования этого поведения. Это полезно для, расширяться/разрушаться лист, как мы делаем для сохранения и распечатываем листы, например.
Существует теперь API для отключения перемещения windowServer окна:
- (void)setMovable:(BOOL)flag;
- (BOOL)isMovable;
По умолчанию, если-isMovableByWindowBackground возвращает YES, окна могут быть перетащены их строкой заголовка, панелью инструментов или нижней границей, и содержанием. mouseDown/mouseDragged/mouseUp события, вызывающие перемещение окна, интерпретируются windowServer, и окно перемещено в процесс windowServer, а не в порядка подачи заявки. Так, вплоть до сих пор приложения не имели хорошего способа отключить или настроить перемещение окна. Вызов setMovable:NO отключает перемещение windowServer. При желании можно реализовать управляемое приложением окно, перемещающееся путем обработки mouseDown/mouseDragged/mouseUp событий в подклассе окна. Если окно не подвижно, его относительная экранная позиция также сохраняется в режиме F8 пробелов, но можно все еще перетащить окно к различному пространству в режиме F8.

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

firstResponder NSWINDOW KVO-совместим. Обратите внимание на то, что мы обычно не гарантируем KVO-соответствия для свойств NSWindow и NSView; Вы не должны принимать KVO-соответствие, если в частности не задокументировано.

Автоповедение отображения NSWindow

Автодисплей NSWindow теперь регулируют для появления не более часто, чем интервал синхронизации луча (о 1/60 секунде). На Leopard и предыдущий, отмечая представление как грязное в автоокне экрана заставил бы дисплей окна происходить в конце цикла событий. На SnowLeopard может быть задержан дисплей окна, пока временной интервал синхронизации луча не протек. Это важно для производительности, так как она избегает блокировать основной поток в операциях рисования.

Поведение набора NSWindow

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

Когда окно имеет NSNormalWindowLevel, это получает эти способы поведения по умолчанию:
- окно видимо и можно выбрать в режимах Exposé F9 и F10
- окно видимо во время режима Spaces F8 и связано с одним пространством за один раз. Перетаскивание окна к границе пространства инициировало переключатель пространства
- окно участвует в циклическом повторении окна (cmd-' и ctrl-F4)

Когда окно имеет любой другой уровень окна, это получает эти способы поведения по умолчанию:
- окно скрыто в режимах Exposé F9 и F10
- окно скрыто в режиме Spaces F8 и плавает через переключатели пространства если вне экрана во время переключателя. Перетаскивание окна к границе пространства не инициировало переключатель пространства
- окно не участвует в циклическом повторении окна

Для обеспечения дополнительного управления приложениями у нас есть дополнительные способы поведения набора окна, которые будут использоваться с - [NSWindow setCollectionBehavior:]
enum {
// participates in spaces, exposé. Default behavior if windowLevel == NSNormalWindowLevel
 NSWindowCollectionBehaviorManaged = 1 << 2,
// floats in spaces, hidden by exposé. Default behavior if windowLevel != NSNormalWindowLevel
NSWindowCollectionBehaviorTransient = 1 << 3,
// unaffected by exposé. Stays visible and stationary, like desktop window
 NSWindowCollectionBehaviorStationary = 1 << 4,
};
enum {
 // default behavior if windowLevel == NSNormalWindowLevel
NSWindowCollectionBehaviorParticipatesInCycle = 1 << 5,
 // default behavior if windowLevel != NSNormalWindowLevel
NSWindowCollectionBehaviorIgnoresCycle = 1 << 6
};

NSWindowCollectionBehaviorManaged
- окно видимо и можно выбрать в режимах Exposé F9 и F10
- окно видимо во время режима Spaces F8 и связано с одним пространством за один раз. Перетаскивание окна к границе пространства инициировало переключатель пространства

NSWindowCollectionBehaviorTransient
- окно скрыто в режимах Exposé F9 и F10
- окно скрыто в режиме Spaces F8 и плавает через переключатели пространства если вне экрана во время переключателя. Перетаскивание окна к границе пространства не инициировало переключатель пространства

NSWindowCollectionBehaviorStationary
- окно незатронуто Exposé. Это остается в своей текущей позиции и будет наиболее вероятно покрыто окном экрана Exposé, как рабочий стол.

NSWindowCollectionBehaviorParticipatesInCycle
- окно участвует в циклическом повторении окна (cmd-' и ctrl-F4)

NSWindowCollectionBehaviorIgnoresCycle
- окно не участвует в циклическом повторении окна

Если никакое поведение не было установлено явно, как в Leopard,-collectionBehavior возвратит только поведение, явно установленное через-setCollectionBehavior или NSWindowCollectionBehaviorDefault.

Следующие примеры иллюстрируют, как новые константы взаимодействуют с основанным на окне-уровнем поведением по умолчанию.
[window setCollectionBehavior:NSWindowCollectionBehaviorDefault]
    - окно получит поведение на основе своего уровня окна, как описано выше под «Поведением набора окна на основе уровня окна»
[window setCollectionBehavior:NSWindowCollectionBehaviorCanJoinAllSpaces]
    - окно будет видимо на всех пробелах и будет иметь поведение на основе своего уровня окна для циклического повторения окна и exposé
[window setCollectionBehavior:NSWindowCollectionBehaviorMoveToActiveSpace]
    - когда упорядоченный переднюю сторону, и будет иметь поведение на основе его уровня окна для циклического повторения окна и exposé, окно станет видимым на активном пространстве
[window setCollectionBehavior:NSWindowCollectionBehaviorCanJoinAllSpaces|NSWindowCollectionBehaviorManaged|NSWindowCollectionBehaviorIgnoresCycle]
    - окно будет видимо на всех пробелах, будет видимо и можно выбрать в exposé и не будет участвовать в циклическом повторении окна
[window setCollectionBehavior:NSWindowCollectionBehaviorTransient|NSWindowCollectionBehaviorParticipatesInCycle]
    - будет скрыт в пробелах и exposé, и будет участвовать в циклическом повторении окна

NSWindow модальный уровень окна в приложениях LSUIElement

Модальные окна в приложениях LSUIElement проходят специальное лечение уровня окна, где уровнем окна является NSModalPanelWindowLevel, активно ли приложение владения. Модальные окна, принадлежащие регулярным приложениям, продвинуты на NSModalPanelWindowLevel, когда приложение активно, но восстановленный NSNormalWindowLevel, когда приложение владения неактивно, чтобы препятствовать тому, чтобы модальные окна плавали выше других приложений. Так как приложения LSUIElement соблюдают различные правила активации, активное состояние не требуется для хранения модального окна перед другими окнами.

NSWindow и поддержка Цветового пространства NSScreen (Измененный начиная с WWDC 2009)

NSScreen имеет средство доступа для получения цветового пространства экрана.
@interface NSScreen : NSObject
...
- (NSColorSpace *)colorSpace;
...
@end
Когда цветовое пространство экрана изменяется, NSScreenColorSpaceDidChangeNotification, существует также уведомление, отправленное. Объект уведомления является экраном, цветовое пространство которого изменилось.

В приложениях основывался на Leopard и предыдущий, окно наследует цветовое пространство основного экрана (т.е. экран, содержащий строку меню). Если окно возвратит YES для displaysWhenScreenProfileChanges, то оно вместо этого наследует то цветовое пространство экрана, содержащего большинство окна. displaysWhenScreenProfileChanges:YES является значением по умолчанию для окон в приложениях, основывался на SnowLeopard или позже. Любые из этих способов поведения наследования могут быть переопределены путем явной установки цветового пространства окна, которое может быть желательным для отображения содержания с лучшей точностью.
@interface NSWindow : NSResponder
...
/* -setColorSpace: allows you to specify a colorSpace that matches custom content.  Calling -setColorSpace: with an unsupported colorSpace will raise an exception.
Typically, this would be called immediately after creating the window; changing the colorSpace of a window with backingStore will trigger redisplay
*/
- (void)setColorSpace:(NSColorSpace *)colorSpace;
- (NSColorSpace *)colorSpace;
...
@end

Взаимодействие Углерода/Какао NSWindow

Какао имеет понятие главного окна, отличного от ключевого окна. Исторически, мы не поддерживали главные окна Cocoa в приложениях Углерода; окно Cocoa в приложении Углерода было или ключевым или неактивным. В SnowLeopard мы добавили поддержку главных окон Cocoa в приложениях Углерода. Эта поддержка ограничивается приложениями, соединенными на SnowLeopard или позже так как это имеет импликации совместимости на уровне двоичных кодов.

Константы NSWindowDepth

NSWindow имеет существующий API для получения предела глубины окна:
- (void)setDepthLimit:(NSWindowDepth)limit;
- (NSWindowDepth)depthLimit;
Мы ранее не опубликовали возможные значения для NSWindowDepth. Путем это работало, исторически то, что можно было бы вызвать NSBestDepth с параметрами, указывающими характеристики глубины окна, и NSBestDepth возвратит значение, подходящее для передачи setDepthLimit:.
NSWindowDepth NSBestDepth (NSString *colorSpace, NSInteger bps, NSInteger bpp, BOOL planar, BOOL *exactMatch);
NSWindow теперь публикует поддерживаемые значения для NSWindowDepth. Обратите внимание на то, что это - предел глубины, что означает, что окно может использовать более низкую глубину в зависимости от графики capabilities.enum {
  NSWindowDepth32BitRGB = 0x208,
  NSWindowDepth64BitRGB = 0x210,
  NSWindowDepth128BitRGB = 0x220
};

Отображение содержания словаря

Мы добавили средство для отображения определения или другого содержания словаря для выбора, подобного HIDictionaryWindowShow от Углерода.

Оба-showDefinitionForAttributedString:atPoint: и-showDefinitionForAttributedString:range:options:baselineOriginProvider: покажите окно, выводящее на экран определение (или другой предмет в зависимости от доступных словарей) указанной приписанной строки.

showDefinitionForAttributedString:atPoint: берет attributedString «attrString», и базовый источник той строки в получателе просматривает систему координат «textBaselineOrigin». Этот метод может использоваться для реализации той же функциональности как контекстное меню 'Look Up in Dictionary' NSTextView на пользовательском представлении.

- showDefinitionForAttributedString:range:options:baselineOriginProvider: берет attributedString «attrString», диапазон в той строке (обычно выбранный диапазон) «targetRange», словарь опций «опции» и провайдер источника «originProvider». Если нет никакого выбора, «targetRange» должен быть нулевой длиной, чтобы заставить надлежащий диапазон быть автоматически обнаруженным вокруг данного смещения." опции» могут быть нолем или могут содержать словарь с опциями представления. Если маленькое окно наложения выбрано как представление по умолчанию (см. опцию NSDefinitionPresentationTypeKey для подробных данных), текст перекрытия представляется, запускаясь с источника, указанного блоком originProvider. Блок originProvider должен возвратить базовый источник первого символа в предложенном adjustedRange в системе координат представления получателя. Если получателем является NSTextView, и attrString и originProvider могут быть нолем, когда текстовое представление автоматически предоставит значения, подходящие для отображения определений для указанного диапазона в его текстовом содержании. Этот метод не вызывает прокрутку, таким образом, клиенты должны выполнить любую необходимую прокрутку прежде, чем вызвать этот метод.
@interface NSView(NSDefinition)
- (void)showDefinitionForAttributedString:(NSAttributedString *)attrString
atPoint:(NSPoint)textBaselineOrigin;
- (void)showDefinitionForAttributedString:(NSAttributedString *)attrString
range:(NSRange)targetRange
options:(NSDictionary *)options
baselineOriginProvider:(NSPoint (^)(NSRange adjustedRange))originProvider;
@end
NSDefinitionPresentationTypeKey является дополнительным ключом 'в словаре «опций», указывающем тип презентации дисплея определения. Возможными значениями является NSDefinitionPresentationTypeOverlay, производящий маленькое окно наложения в строковом расположении или NSDefinitionPresentationTypeDictionaryApplication, вызывающий приложение Словаря для отображения определения. Без этой опции определение будет показано в любой из тех форм представления в зависимости от 'Контекстного меню': установка в установках приложения Словаря по умолчанию.
NSString * const NSDefinitionPresentationTypeKey;
NSString * const NSDefinitionPresentationTypeOverlay;
NSString * const NSDefinitionPresentationTypeDictionaryApplication;

Завершение NSApplication

NSApplication теперь отключает оконечное: действие при ожидании делегата для вызова replyToApplicationShouldTerminate: после возврата NSTerminateLater от applicationShouldTerminate:. Цель этого изменения состоит в том, чтобы избежать множественных вызовов applicationShouldTerminate: в то время как приложение делает разовую завершением очистку. Это имеет побочный эффект отключения меню Quit при ожидании делегата. Это должно быть желательным поведением, но ограничивается приложениями, соединенными на SnowLeopard или позже избежать предотвращать завершение приложений, делегаты которых могут не вызывать replyToApplicationShouldTerminate: должным образом.

NSHelpManager

В Leopard и предыдущих выпусках, NSHelpManager сделал автоматическую регистрацию книг справки в основном пакете в его реализациях showHelp: openHelpAnchor:inBook: и findString:inBook:. В SnowLeopard мы добавили API, таким образом, плагин может зарегистрировать свою книгу справки для более позднего использования в поиске справки.

Следующий метод регистрирует одну или более книг справки в данном пакете. Основной пакет автоматически регистрируется-openHelpAnchor:inBook: и-findString:inBook:. Можно использовать-registerBooksInBundle: зарегистрировать книги справки в сменном пакете, например. Info.plist в пакете должен содержать путь к каталогу книги справки, указывающий одну или более папок, содержащих книги справки. Возвраты НЕ, если пакет не содержит книг справки или если регистрация перестала работать. Возвраты YES на успешной регистрации.
- (BOOL)registerBooksInBundle:(NSBundle *)bundle;

Плагин NSDockTile (Измененный начиная с WWDC 2009)

Приложение может настроить свою мозаику прикрепления, если не работающую через плагин, основной класс которого реализует протокол NSDockTilePlugIn. Имя плагина обозначено NSDockTilePlugIn, вводят файл приложения Info.plist, и плагин должен иметь расширение .docktileplugin. Когда мозаика приложения добавляется к Прикреплению, плагин загружается в системном процессе во время входа в систему или. Когда плагин загружается, реализация основного класса-setDockTile: вызывается. Если основной класс реализует-dockMenu,-dockMenu вызывается каждый раз, когда пользователь заставляет меню прикрепления приложения быть показанным. Когда мозаика прикрепления больше не действительна (например, приложение было удалено из прикрепления,-setDockTile: вызывается с нолем NSDockTile.

Обратите внимание на то, что плагин должен иметь свою собственную копию значка приложения, если это не абсолютно переопределяющее получение путем установки его собственного contentView в dockTile.
@protocol NSDockTilePlugIn <NSObject>
@required
- (void)setDockTile:(NSDockTile*)dockTile;
@optional
- (NSMenu*)dockMenu;
@end

Находящийся в NSViewController NSCollectionViewItem

В Mac OS 10.6, суперкласс NSCollectionViewItem был изменен от NSObject до NSViewController. Это было сделано, чтобы улучшиться, как тиражировано прототипное представление. Метод репликации представления, используемый ранее в Mac OS 10,5 работ для многих простых представлений, но некоторых соединений и привязки, не может быть скопирован правильно.

С новым находящимся в NSViewController NSCollectionViewItem это ограничение может быть преодолено путем инициализации прототипа NSCollectionViewItem с именем пера и пакетом, от которого представление может надежно тиражированный.

Преобразование Ваших прототипов NSCollectionViewItem к использованию перьев обычно очень просто. Во-первых, создайте новое пустое перо в Интерфейсном Разработчике. Затем, скопируйте свое прототипное представление в новое перо. Измените класс Владельца Файла нового пера к NSCollectionViewItem и подключите представление к его выходу 'представления'. В новом пере повторно соедините любую привязку от своего представления до NSCollectionViewItem. Сохраните новое перо. В Вашем исходном пере удалите прототипное представление и введите имя своего нового пера (и идентификатор пакета, при необходимости — оставление, это незаполненный будет искать основной пакет) в прототипном инспекторе NSCollectionViewItem, и сохраните перо.

Новый NSCollectionViewItem абсолютно совместим с существующими. Используя основанный на пере прототип представление является дополнительным, и NSCollectionViewItems, заархивированный в 10,5, все еще будет читаем в 10,6.


Перетаскивание NSCollectionView

В Mac OS 10.6, NSCollectionView имеет новое перетаскивание API, подобный существующему APIs для NSTableView, NSBrowser, и т.д. Для NSCollectionView, чтобы быть источником перетаскивания, это должно иметь делегата, реализующего и возвращающего YES из collectionView:canDragItemsAtIndexes:withEvent: и collectionView:writeItemsAtIndexes:toPasteboard:. Для NSCollectionView, чтобы быть местом назначения перетаскивания, это должно иметь делегата, реализующего collectionView:validateDrop:proposedIndex:dropOperation: и collectionView:acceptDrop:index:dropOperation:. Для большего количества подробности см. комментарии в NSCollectionView.h.

Два метода были добавлены к NSCollectionView, который может быть необходимым в Ваших реализациях метода делегата перетаскивания. Первым является itemAtIndex: который возвращает NSCollectionViewItem, связанный с представленным объектом в данном индексе. Если необходимо получить ссылку на определенные подпредставления NSCollectionView, это особенно полезно. Вторым является frameForItemAtIndex: который возвращает кадр, который получатель вычислил для подпредставления в данном индексе. Необходимо всегда использовать этот метод вместо того, чтобы вызвать [[[collectionView itemAtIndex:index] представление] кадр]. Если представление набора пытается лениво загрузить свои элементы, выполнение этого вынудило бы представление создаваться преждевременно. Этот метод особенно полезен в collectionView:draggingImageForItemsAtIndexes:withEvent:offset: метод делегата определить, какие представления находятся в видимой области представления набора.


Исправления ошибок NSCollectionView

Ошибки Signficant в NSCollectionView были исправлены в Mac OS 10.6

Когда NSCollectionView будет изменен, он больше не будет заставлять свое представление прокрутки включения прокручивать к вершине.

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

Для NSCollectionViews, не использующих новые основанные на пере прототипные представления, механизм копирования представления был сделан более надежным. В Mac OS 10.5, могли потенциально быть скопированы представления, прежде чем вся их привязка или другие соединения были загружены из пера.

Когда выбор будет изменен событиями от нажатия мыши, NSCollectionView теперь правильно инициирует уведомления KVO для selectionIndexes.

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


Изменения появления NSSplitView

В Mac OS 10.5, значение по умолчанию - [NSSplitView dividerColor] для тонких делителей было серым цветом, независимо от стиля окна. Это создало обычно нежелательную видимость, когда продвинуто текстурированные окна. В приложениях, соединенных на или после Mac OS 10.6,-dividerColor теперь возвратится [NSColor clearColor] по умолчанию для представлений разделения с тонкими делителями на текстурированных окнах.

Кроме того, NSSplitView прекратил рисовать различные версии впадины делителя. С этого времени это только нарисует недоступную версию, независимо от содержания ключевого состояния окна.


Формальное принятие протокола

В Mac OS 10.6, AppKit переключился на использование формальных протоколов для всех делегатов и источников данных для обеспечения лучшей проверки типа времени компиляции. Методы требуемого протокола отмечены с @required, если это возможно. Остальные отмечены с @optional.

Затронутые классы являются NSAlert, NSAnimation, NSApplication, NSBrowser, NSComboBox, NSComboBoxCell, NSControl, NSDatePicker, NSDatePickerCell, NSDrawer, NSImage, NSLayoutManager, NSMatrix, NSMenu, NSOutlineView, NSPathCell, NSPathControl, NSRuleEditor, NSSavePanel, NSSound, NSSpeechRecognizer, NSSpeechSynthesizer, NSSplitView, NSTableView, NSTabView, NSText, NSTextField, NSTextStorage, NSTextView, NSTokenField, NSTokenFieldCell, NSToolbar и NSWindow

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

• Ваши классы делегата должны объявить соответствие к новым протоколам. Например:
@interface MyDelegate : NSObject <NSApplicationDelegate> ... @end
• Отправка сообщений к [foo делегат] или [foo источник данных], которые не находятся в протоколе делегата, генерирует предупреждение. Это обычно не рекомендуется, так как нет никаких гарантий о классе делегата. Однако можно работать вокруг этого путем кастинга результата [foo делегат] или [foo источник данных] к ID. Кроме того, необходимо всегда выполнять respondsToSelector: проверьте прежде, чем вызвать метод на [foo делегат] или [foo источник данных], который не является @required методом в протоколе.

• Если у Вас есть подкласс одного из этих классов, добавляющего дополнительные методы делегата, необходимо также создать подпротокол и переопределение - делегат и-setDelegate:. Например:
@protocol MySplitViewDelegate;
@interface MySplitView : NSSplitView
- (id <MySplitViewDelegate)delegate;
- (void)setDelegate:(id <MySplitViewDelegate>)delegate;
@end
@protocol MySplitViewDelegate <NSStreamDelegate>
- (void)additionalDelegateMethod;
@end
@implementation MySplitView
- (id <MySplitViewDelegate)delegate {
    return (id <MySplitViewDelegate>)[super delegate];
}
- (void)setDelegate:(id <MySplitViewDelegate>)delegate {
    [super setDelegate:delegate];
}
@end
• Если необходимо предназначаться для Leopard или Тайгера с теми же источниками, необходимо условно объявить пустые протоколы, или иначе компилятор будет жаловаться на недостающие объявления протоколов. Например:
#if MAC_OS_X_VERSION_10_6 > MAC_OS_X_VERSION_MAX_ALLOWED
@protocol NSTableViewDelegate <NSObject> @end
#endif

Новый метод делегата NSSplitView

Чтобы упростить для Вашего приложения поддерживать размер данных подпредставлений разделения просматривают, в то время как представление разделения изменяется, NSSplitView в Mac OS 10.6 имеет новый-splitView:shouldAdjustSizeOfSubview: метод делегата можно реализовать. Это управляет, как-adjustSubviews ведет себя так, Вы не должны переписывать большую часть его поведения по умолчанию в-splitView:resizeSubviewsWithOldSize: метод делегата.

В то время как представление разделения изменено, путем возврата НЕ из этого метода, можно заблокировать размер подпредставления представления разделения. Однако, если представление разделения уменьшится вне точки, что все подпредставления изменяемого размера полностью скрыты, то подпредставления, для которых Вы возвратились НЕ, начнут изменять размеры также, чтобы препятствовать тому, чтобы-adjustSubviews создал недопустимое расположение подпредставления.

Новый стиль делителя разделителя области NSSplitView

В Mac OS 10.6, NSSplitView имеет новый стиль делителя под названием NSSplitViewPaneSplitterDividerStyle. Этот новый стиль существенно отличается, чем «толстый» стиль, потому что это рисует непрозрачный градиент вдоль всей длины делителей, и ее ширина немного меньше. Этот стиль соответствует появление делителей представления разделения во многих создаваемых Apple приложениях.

Инструкции по Интерфейсу пользователя Snow Leopard строго призывают Вас мигрировать далеко от «толстого» стиля до этого нового стиля. Из-за этого при создании нового экземпляра NSSplitView в Интерфейсном Разработчике Вы только будете в состоянии выбрать между «тонкими» и «стилями делителя» разделителя области.

paneSplitter и setPaneSplitter NSSplitView: методы осуждаются в Mac OS 10.6 в пользу нового стиля делителя.



Изменения свойства NSCell controlView

Объявления для controlView и setControlView: находятся на NSCell, но до SnowLeopard хранение для controlView свойства было на уровне NSActionCell. - [NSCell controlView] всегда возвращал ноль и - [NSCell setControlView:] ничего не сделал. Это вызванное множество неожиданных способов поведения.

Для приложений, соединенных на или после SnowLeopard, хранение для этого свойства на уровне NSCell, и средства доступа NSCell ведут себя, как Вы могли бы ожидать. Фиксация ограничивается приложениями, соединенными на или после SnowLeopard. Это вызвано тем, что NSCell не сохраняет свой controlView, таким образом, существуют новые возможности для висячих указателей. Если Ваше приложение сохраняет статический экземпляр NSCell, который Вы используете для рисования во многих различных контекстах, например, Вы, возможно, должны стараться убрать controlView между использованием. Это требование уже было на месте для NSActionCell, таким образом, это - только проблема при использовании чего-то, что не убывает от того класса.

Кроме того, до SnowLeopard NSActionCell распространил свой controlView к его копии в copyWithZone:. Это не корректно и вызывает проблемы. controlView является переходным набором свойств непосредственно перед тем, как нарисована ячейка. Поскольку методы вызываются на ячейку в ходе копирования его, управление первоначальной ячейки обычно заканчивается dirtied и перерисованный. Так как ячейка не сохраняет свой controlView, это вызывает катастрофические отказы, если освобождено исходное представление управления.

Для приложений, соединенных против SnowLeopard SDK или позже, не распространен controlView.

NSImageCell отключил изображения

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

Можно было бы ожидать, что NSImageView сделает это, но NSImageView вместо этого показывает, что это отключено путем рисования его кадра по-другому. Существуют случаи, где Вы хотите это: Когда представление изображения устанавливается как изображение хорошо, изображение может быть пользовательскими данными, которые Вы просто представляете. Это нечетно для затемнения его, особенно когда это достаточно для потускнения изображения хорошо.

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

Это - поведение для приложений, соединенных на или после SnowLeopard. Проверка связи здесь, потому что некоторые приложения действительно отключают представления изображения, не предназначая grayed рисующий. Это могло легко явиться результатом экспериментирования с флажками в Интерфейсном Разработчике.

NSButton

Стиль треугольника раскрытия NSButton теперь в состоянии инвертировать белому на темных фонах и таком путем интерпретации backgroundStyle свойства ячейки.

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

NSImage, CGImage и согласование импедансов CoreGraphics

NSImage изменился существенно внутренне для SnowLeopard способами, которыми разработчики могли бы хотеть знать. Существует также некоторый новый API. Обработка изображений AppKit теперь более близко выравнивается с CoreGraphics.

Основное изменение должно переместиться в непротиворечивое использование CGImage внутренне. Например, в Leopard и предыдущий, - [NSImage lockFocus] вовлек представление во внеэкранном окне. Теперь это вовлекает буфер, и CGImage извлечен из буфера в +unlockFocus. NSImage больше не использует окна вообще в его реализации. Мы полностью осудили NSCachedImageRep, который является подклассом NSImageRep, представляющим получение, поддержанное окном. NSCachedImageRep все еще работает, но AppKit никогда не инстанцирует его внутренне.

Это имеет потенциал для повреждения клиентов. На Leopard и предыдущий, + [NSView focusView] возвратил представление из + [NSImage lockFocus]. Надо надеяться, Вы не знали об этом! Теперь это возвращает ноль. Если Вы смотрели на [[NSView focusView] isFlipped], можно хотеть посмотреть на [[NSGraphicsContext currentContext] isFlipped] вместо этого. Эти два совпадают каждый раз, когда фокус фактически заблокирован на представлении.

Другая проблема, которую мы видели, с клиентами, вызывающими-lockFocus на изображении, затем таща изображение в другом месте прежде, чем вызвать-unlockFocus. Это больше не работает. Сам NSImage не изменяется, пока-unlockFocus не вызывают, как описано выше.

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

Мы добавили метод извлечения CGImages от NSImage, - [NSImage CGImageForProposedRect:context:hints:]. Почему все параметры? Ну, NSImage является потенциально независимым разрешением, и мог удовлетворить многократным представлениям для различных контекстов. Например, NSImage может помочь нарисованный 16x16 битовый массив, а также 512x512 битовый массив. Это позволяет изображению отображать хорошо в больших и очень небольших размерах. CGImage больше походит на единственное основанное на пикселе представление. Думайте о-CGImageForProposedRect:context:hints: как создание снимка того, как NSImage нарисовал бы, если бы попросили подойти к концу *proposedDestRect в переданном контексте.

Снимок является хорошим способом думать о нем, но может привести Вас думать, что метод менее эффективен, чем это действительно. Нет ничего гарантируемого о характеристиках возвращенного CGImage (например, размер пикселя, цветовое пространство) за исключением того, что рисование его в переданном контексте приводит к тем же результатам как рисование исходного NSImage в контексте. В частности если NSImage будет поддержан единственным NSBitmapImageRep, то он будет (вероятно), всегда возвращать один CGImage, это поддерживает битовый массив. Это - допустимый снимок для изображения для любого целевого rect, потому что в этом случае CGImage _does_ получают все получение, к которому NSImage способен.

rect, контекст и подсказки сначала используются для выбора лучшего представления для описанного места назначения, использующего новый API - [NSImage bestRepresentationForRect:context:hints:], тогда репутацию изображения просят относительно CGImage, использующего - [NSImageRep CGImageRepForProposedRect:context:hints:]. NSImage может кэшировать CGImage, то же, как это может кэшироваться для нормального получения и управляемый таким же образом, и CGImage возвращается.

Метод уровня NSImageRep предназначается как точка переопределения для подклассов репутации изображения, естественно имеющих CGImage в наличии. Например, NSBitmapImageRep переопределяет его для возврата CGImage, естественно поддерживающего репутацию. Вы не должны переопределять метод кроме возможно для производительности, все же. Реализация NSImageRep-уровня произведет CGImage путем создания буфера, и вызов - [сам рисует]. Это, вероятно, будет самой лучшей реализацией для представителей, которые не являются естественно поддержанным CGImage. - рисуют, остается единственным методом NSImageRep, который действительно должен переопределить подклассификатор.

Одна тонкость: 'proposedRect' параметр передает указатель на NSRect. В то время как NSImage не, это вызвано тем, что CGImage является обязательно пиксельным интегралом. Для создания CGImage для rect (0.5, 0.5, 4.0, 4.0) без искажения или двойного сглаживания, нам, вероятно, придется произвести 5x5 CGImage, и также расширить proposedRect. Рисование CGImage в-значении в предложенном rect совпадает с рисованием NSImage в в значении из предложенного rect.

Например, этот блок кода
- (void)drawRect {
NSRect dstRect = NSMakeRect(0.5, 0.5, 4.0, 4.0);
CGImageRef cgImage = [pdfBackedImage CGImageForProposedRect:&dstRect context:[NSGraphicsContext currentContext] hints:nil];
// dstRect might be something like {{0.0, 0.0}, {5.0, 5.0}} on return
CGContextDraw([[NSGraphicsContext currentContext] graphicsPort], NSRectToCGRect(dstRect), cgImage);
}
должен произвести получение, эквивалентное (или по крайней мере очень близко к) этот код:
- (void)drawRect {
NSRect dstRect = NSMakeRect(0.5, 0.5, 4.0, 4.0);
[pdfBackedImage drawInRect:dstRect fromRect:NSZeroRect operation:NSCompositeSourceOver fraction:1.0];
}
Последний код лучше, все же. При создании снимка, CGImage может быть более дорогим, чем просто рисование NSImage (хотя мы будем использовать существующий CGImage каждый раз, когда возможный), поэтому предпочтите просто рисовать с - [NSImage drawInRect:fromRect:operation:fraction:] или связанные методы, если Вы действительно не требуете CGImage.

Существует также метод для удобно и эффективно создание NSImage от CGImage, - [NSImage initWithCGImage:size:].

Поведение NSImage: Упрощение кэширования и связанных интерфейсов

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

Для поддержки этого следующие методы осуждаются без замены:
  - (void)setCachedSeparately:(BOOL)flag;
  - (BOOL)isCachedSeparately;
  - (void)setCacheDepthMatchesImageDepth:(BOOL)flag;
  - (BOOL)cacheDepthMatchesImageDepth;
  - (void)setScalesWhenResized:(BOOL)flag;
  - (BOOL)scalesWhenResized;
  - (void)setDataRetained:(BOOL)flag;
  - (BOOL)isDataRetained;
Любой вызов для установки одного из этих свойств может быть удален. Кратко:
isCachedSeparately:
    Это управляло, совместно использовало ли изображение окно кэша с другими экземплярами NSImage. NSImage больше кэши к окнам.
cacheDepthMatchesImageDepth:
    Это управляло битовой глубиной, используемой в создании окон кэша. NSImage больше кэши к окнам. Кэш теперь сгенерирован подходящий для места назначения, где изображение нарисовано, и это не применяется, если изображение вовлечено в контекст, не соответствующий в некотором роде, который привел бы к различному создаваемому кэшу.
scalesWhenResized:
    Можно было бы думать, что-scalesWhenResized будет семантическим свойством, а не кэширующимся флагом, но он действительно имел отношение, были ли кэши лишены законной силы когда - [NSImage setSize:] был вызван. Размер изображения больше не важен для кэширования целей - только размер rect, где изображение нарисовано, важно. В SnowLeopard кэширование NSImage никогда не должно иметь никакого очевидно заметного пользовательского эффекта как изображение, вовлекаемое в различную область размера экрана. Кэширование о производительности.

    Полное поведение, когда свойство было установлено в НЕ, было сложно, но это надежно не достигало препятствования изображению масштабироваться. Это действительно заставляло масштабированное изображение нарисовать глыбовый, иногда.
isDataRetained:
    Когда это было нет, которым это было по умолчанию, изображению разрешили вывести его данные поддержки, когда нарисовано и сохранить что-то только подходящим для контекста это, который это сначала использовалось. Например, когда сначала нарисованный, и данные PDF будет необратимо отброшен, ПОДДЕРЖАННОЕ PDF изображение обычно растеризировалось бы. В SnowLeopard NSImage больше не выводит данные таким способом, которым больше не может восстанавливаться оригинал.

Обратите внимание на то, что - [NSImage setCacheMode:] не осуждается. В частности можно использовать NSImageCacheNever для отключения всего использования кэшей в NSImage. Отключение кэширования может быть оптимизацией, если изображение, как известно, является временным, или если бы там кэшируется имеющий место в другом месте, который сделал бы кэш в потраченной впустую памяти этого уровня.

NSImage: осуждение - [NSImage setFlipped:], добавляя метод рисования, уважающий контекст flippedness

Зеркально отраженный атрибут NSImage широко неправильно понят. Мы осуждаем его для SnowLeopard и заменяем его типичное использование меньшим количеством подверженного ошибкам API.

Свойство описывает ориентацию внутренней системы координат NSImage. Так же, как суперпредставление никогда не заботится о flippedness его подпредставлений, пользователь NSImage не должен заботиться о его flippedness.

Типичный (дефектный) вариант использования должен попытаться вызвать [отображают setFlipped: [NSGraphicsContext currentContext] isFlipped]] только до получения, но это не достигает намеченную цель. Если вызвано перед кэшированием, то представления заканчивают тем, что кэшировались вверх тормашками, и зеркальное отражение поглощено в кэш. Если вызвано после кэширования, это не имеет никакого эффекта - кэшируемое представление, как уже предполагается, включает любое необходимое зеркальное отражение. В прежнем случае, если NSImage нарисован где-нибудь еще позже, он оказался вверх тормашками в месте _that_, также сбивающем с толку, потому что ошибка и выражение ошибки далеко друг от друга. Отсутствие понимания относительно flippedness является также часто источником плохого выполнения кода, в котором люди делают ненужные промежуточные буферы для работы вокруг воспринятых ошибок платформы. Платформа ведет себя согласно проекту, но вопреки ожиданию и семантике не все это полезное. Также трудно изменить семантику - [NSImage isFlipped], потому что много кода очень близко зависит от текущего поведения. Вместо того, чтобы делать попытку этого, мы осудили свойство.

Мы обеспечиваем простой и корректный способ нарисовать изображения в зеркально отраженном или незеркально отраженном контексте, который является методом получения, который может составить контекст flippedness. Мы также добавляем параметр подсказок, соответствующий подсказки в-bestRepresentationForRect:context:hints:.
- (void)drawInRect:(NSRect)dstRect
fromRect:(NSRect)srcRect
operation:(NSCompositingOperation)op
fraction:(CGFloat)alpha
respectFlipped:(BOOL)respectContextIsFlipped
hints:(NSDictionary *)hints;
Передайте YES для respectFlipped для получения необычного нового поведения. Одно примечание для тех, которые понимают CTM и волнуются, что этот метод имеет нечетное взаимодействие, где изменение CTM могло не иметь эффект на получение изображения: Дело обстоит не так. Это поведение ответвлений метода на основе [[NSGraphicsContext currentContext] isFlipped]. Изменение CTM могло бы перевернуть Ваши оси вверх дном, но оно не изменит результат - [NSGraphicsContext isFlipped]. Они являются абсолютно ортогональными.

Второе допустимое использование - [NSImage setFlipped:] должен был указать flippedness контекста, полученного через - [NSImage lockFocus]. Существуют случаи, например таща непосредственно через NSLayoutManager, требующие зеркально отраженного контекста. Для покрытия этого случая добавляем мы
- (void)lockFocusFlipped:(BOOL)flipped;
Это не изменяет состояние самого изображения, только контекст, на котором заблокирован фокус. Это означает, что (0,0) наверху оставлен и положителен вдоль оси Y, снижается в заблокированном контексте.

NSImage: Повреждение изменения в drawAtPoint:fromRect:operation:fraction:

- [NSImage drawAtPoint:fromRect:operation:fraction:] имеет различное поведение для приложений, соединенных на или после SnowLeopard, чем это сделало ранее. Мы исправили ошибку, оказывающую существенное влияние на поведение, но это достаточно странно, и достаточно просто работать вокруг, что мы думаем, что нам может сойти с рук фиксация его. Естественная вещь сделать, если Вы когда-либо встречались с этой ошибкой, состояла в том, чтобы переключиться на выполнение чего-то еще, для не зависимости от нее.

До SnowLeopard,-drawAtPoint:fromRect:... названный-drawInRect:fromRect:... передающим [размер изображения] как размер целевого rect. Если 'изображение' было 100x10, то отрывок
    [image drawAtPoint:NSZeroPoint fromRect:NSMakeRect(0,0,10,10) operation:NSCompositeSourceOver fraction:1.0];
было эквивалентно
    [image drawInRect:NSMakeRect(0,0,10,100) fromRect:NSMakeRect(0,0,10,10) operation:NSCompositeSourceOver fraction:1.0];
который имеет мало смысла. Это даже не сохраняет форматное соотношение источника rect. В приложениях, соединенных на SnowLeopard, отрывок вместо этого эквивалентен
    [image drawInRect:NSMakeRect(0,0,10,10) fromRect:NSMakeRect(0,0,10,10) operation:NSCompositeSourceOver fraction:1.0];
Это, очевидно, может потребовать изменений при перекомпиляции кода так ищите источник drawAtPoint. Изменение не имеет никакого эффекта на приложения, передающие {{0,0}, [размер изображения]} для источника rect, который является тем, что делает большинство приложений. Как с другими методами рисования, берущими источник rects, NSZeroRect обрабатывается как сигнальная метка, означающая 'целое изображение'.

Если Вы передавали частичный источник rect Leopard и ранее, и Вы нуждаетесь в совместимости на Leopard и SnowLeopard, то заменяете Ваше использование-drawAtPoint:fromRect:operation:fraction: с-drawInRect:fromRect:operation:fraction:.

NSImage: Осуждение старых методов рисования

NSImage имеет комплект методов рисования, запускающихся с «получения» и комплекта методов рисования, запускающихся с, «распадаются» или «составляют композит».
- (void)dissolveToPoint:(NSPoint)point fraction:(CGFloat)aFloat;
- (void)dissolveToPoint:(NSPoint)point fromRect:(NSRect)rect fraction:(CGFloat)aFloat;
- (void)compositeToPoint:(NSPoint)point operation:(NSCompositingOperation)op;
- (void)compositeToPoint:(NSPoint)point fromRect:(NSRect)rect operation:(NSCompositingOperation)op;
- (void)compositeToPoint:(NSPoint)point operation:(NSCompositingOperation)op fraction:(CGFloat)alpha;
- (void)compositeToPoint:(NSPoint)point fromRect:(NSRect)rect operation:(NSCompositingOperation)op fraction:(CGFloat)alpha;
Методы «получения» являются более новыми, и обычно, что Вы хотите использовать.

«Составные» методы имеют удивительную семантику. Они устанавливают текущую матрицу преобразования графического контекста, чтобы быть единичной матрицей (или более точно, идентификационные данные, увеличенные масштабным коэффициентом пространства пользователя по умолчанию – думают окно по умолчанию, масштабирующееся с независимостью разрешения) перед получением. Т.е. в масштабированном или повернутом представлении составные методы рисуют, как будто представление не масштабируется или поворачивается.

Это обычно не, что каждый действительно после. Часто люди используют эти методы, потому что они, кажется, производят получение правой стороны в зеркально отраженных представлениях. Если это - то, что Вы после, используйте новый метод - [NSImage drawInRect:fromRect:operation:fraction:respectContextFlipped:hints:] передача YES для respectContextFlipped.

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

NSImage: осуждение-lockFocusOnRepresentation:

Метод NSImage:
- (void)lockFocusOnRepresentation:(NSImageRep *)imageRepresentation;
осуждается, потому что это обычно неправильно понимается и просто тиражироваться. Это не устанавливает репутацию как место назначения получения, это устанавливает изображение как место назначения получения, затем вовлекает репутацию в него. Можно заменить использование
[image lockFocus];
[rep drawInRect:NSMakeRect(0,0,[image size].width, [image size].height)];

NSImageRep: Более гибкое получение

Это дополнение к NSImageRep обеспечивает гибкость получения, эквивалентную NSImage's. До SnowLeopard, один должен был обернуть репутацию с NSImage для рисования с любой работой кроме NSCompositeCopy, например. Это - боль, так как намного более распространено нарисовать с NSCompositeSourceOver.
- (BOOL)drawInRect:(NSRect)dstRect
fromRect:(NSRect)srcRect
operation:(NSCompositingOperation)op
fraction:(CGFloat)alpha
respectFlipped:(BOOL)respectContextIsFlipped
hints:(NSDictionary *)hints;

NSImage: тестирование Хита на непрозрачные области

NSImage получил метод, тестирующий, поражают ли перетаскивания непрозрачную часть изображения.
- (BOOL)hitTestRect:(NSRect)testRectDestSpace
withImageDestinationRect:(NSRect)imageRectDestSpace
context:(NSGraphicsContext *)context
hints:(NSDictionary *)hints
flipped:(BOOL)flipped;
Более точно этот метод отвечает на вопрос, «Если необходимо было нарисовать изображение в переданном целевом rect в переданном контексте, уважая переданный flippedness с переданными подсказками, будете, тест rect в контексте пересекает непрозрачную часть изображения?». Информация о месте назначения получения необходима, потому что NSImage рисует по-другому в зависимости от того, куда это идет. Рассмотрите типичный значок Mac OS X, имеющий 16x16, 32x32 и представления на 256x256 пикселей. Выбор представления нарисовать зависит от места назначения, таким образом, для точного хита, тестирующего также, нужна целевая информация.

Однако контекст и параметры подсказок могут быть опущены, и мы предположим, что контекст устанавливается как контекст окна с масштабированием по умолчанию. Это совпадает с в - [NSImage bestRepresentationForRect:context:hints:] и другие методы NSImage, берущие подобные параметры. Если у Вас нет NSGraphicsContext удобным, но Вы знаете, что то, когда изображение рисует его, в контекст, отличающийся от контекста окна в некотором отношении, можно использовать подсказки для описания того контекста.

Зеркально отраженный параметр вызывается отдельно, а не предоставляется как подсказка, потому что это - критический параметр. Это определяет ориентацию, с которой изображение рисует в целевом rect, и поэтому какую часть изображения Вы поражены, тестируя. При передаче ненулевого контекста Вы, вероятно, хотите передать [контекст isFlipped]. Если у Вас нет контекста удобным, но Вы, вызывают это из представления и хита, тестирующего изображение, которое Вы рисуете в drawRect: тогда необходимо, вероятно, передать [просматривают isFlipped] и rect, где Вы рисуете изображение для imageRectDestSpace.

Существует одно поведение особого случая. Если тест rect имеет {0,0} размер, то этот метод вместо этого тестирует, поражает ли точка источника что-то непрозрачное в изображении. Вы могли думать об этом как о тестировании rect с бесконечно малым размером.

NSImage: Новые стандартные изображения

Мы добавили passel новых имен для использования с + [NSImage imageNamed:]. Поиск AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER около нижней части NSImage.h или взгляда на вкладку «Media» в панели библиотеки Интерфейсного Разработчика.

NSImage: метаданные Ориентации (например, exif) теперь уважаемый по умолчанию

Некоторые форматы файла образа, такие как JPEG, содержат метаданные, описывающие 'ориентацию' данных, поддерживающих изображение. Камера может тегировать свои данные изображения, как повернуто на 90 градусов против часовой стрелки относительно того, что должен видеть пользователь.

NSImage никогда не интерпретировал эти метаданные. Для приложений, соединенных на или после SnowLeopard, мы делаем. Предварительный просмотр и ImageKit интерпретировали эту информацию о 10,5. WebKit в настоящее время не делает. ImageIO, фундаментальная платформа чтения изображения, сообщает информацию, но не составляет ее.

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

Это - главное изменение поведения до некоторой степени, но мы не ожидаем, что он повлияет на очень большое количество кода на практике. Однако, существуют некоторые разработчики, которым будет нужно к условно уклонению для совместимости. Мы представляем новую часть API на NSImage для поддержки их. Это - выглядящий назад метод для выбора из нового поведения.
  - (id)initWithDataIgnoringOrientation:(NSData *)data;
Кому нужно это? Рассмотрите формат документа , это ссылается на изображения. Если документ сохраняется на Leopard, это обычно корректно для него для взгляда, как это сделало на Leopard, когда открыл на SnowLeopard. В графическом редакторе, включающем изображения, пользователь, возможно, вручную повернул изображение для компенсации проигнорированную информацию об ориентации. Если бы приложение начало интерпретировать встроенную ориентацию, изображение закончилось бы дважды повернутое. Посмотрите конец этого раздела для примера того, как обработать этот вид ограничения на совместимость.

Это не все это распространенное для изменения кода, все же. В Mac OS X только AppKit должен был реагировать на изменение. Различие релевантно для обработки изображений загрузки, не к работе с изображениями, и только важно для изображений, которые являются пользовательскими данными в противоположность встроенному в платформу. Изображения, выписанные, скажем, TIFFRepresentation или путем архивации NSImage, всегда находятся в нормализованной ориентации, таким образом, никакие изменения, необходимые при чтении их. Большинство приложений _want_ для интерпретации данных ориентации изображения. Большое исключение является существующими документами, что непосредственно ссылочные файлы образа, прибывшие от нетронутого пользователя.

- [ NSImage initWithDataIgnoringOrientation:] действительно удобный метод. Другой способ проигнорировать ориентацию изображения состоит в том, чтобы использовать CGImageSource ImageIO для создания CGImage, и затем - [NSImage initWithCGImage:size:] для представления его как NSImage. ImageIO сообщает о метаданных ориентации, но автоматически не интерпретирует их.

Мы также обеспечиваем глобальное уклонение. При установке пользовательского значения по умолчанию NSBitmapImageRepRespectOrientation в нет, NSImage будет вести себя старый путь все время. Это - опция последней инстанции для разработчиков, которые не могут обновить затронутый код, используемый их приложением по некоторым причинам.

Вот пример работы, которая могла бы требоваться при перемещении приложения до 10,6 SDK:

Сам AppKit читает и пишет формат RTFD. Вот то, что мы должны были сделать: Во-первых, каждое присоединение изображения в памяти теперь имеет внутренний бит 'noOrient', и мы добавили тег/noorient в дисковом формате файла. Если noOrient установлен, то, когда соответствующее изображение загружается из диска, это загружается - [ NSImage initWithDataIgnoringOrientation:]. Каждый документ RTFD о диске также имеет глобальный тег версии. Для старых версий каждое присоединение изображения неявно noOrient. Когда новое изображение добавляется к документу в памяти, бит не установлен. Наконец, когда мы сохраняем RTFD в нашей текущей версии формата файла, мы выписываем тег/noorient для любого присоединения изображения, на котором это установлено.

NSImage: CALayer принимает NSImage как содержание

Можно теперь вызвать - [CALayer setContents:] с NSImage, поскольку содержание возражает. Ранее Вам был нужен CGImage.

Существует одна тонкость. CoreAnimation создается для работы с растровым объектом, битовым массивом.

Если Ваше изображение прибывает из растрового файла как TIFF тогда нет никакой проблемы, но PDF, например, будет растеризирован. Уровень не масштабируется как PDF. Это масштабируется как битовый массив. Если способ по умолчанию, которым мы производим растровую форму, не удовлетворяет Ваши потребности, можно проявить больше использования управления - [NSImage CGImageForRect:context:hints:]. Это произведет CGImage, который можно установить как содержание уровня.

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

Примечание: Даже перед этим изменением, Вы не могли вызвать - [Содержание CALayer] и предположить, что результатом был CGImage. Метод является введенным ID, и объект возвратился, мог быть один из нескольких различных частных типов в 10,5.

NSImage: Разъяснение договора для поточной обработки

NSImage, NSImageRep и все его подклассы имеют тот же договор поточной обработки как NSMutableDictionary, NSMutableArray, NSMutableString и компания.

Если Вы не вызываете методы видоизменения, изображение может безопасно использоваться от произвольных потоков.

Если Вы _are_, видоизменяющий изображение, необходимо гарантировать, что к изображению не получают доступ ни на каких других потоках, в то время как мутация происходит, или катастрофические отказы риска. У Вас должно быть полное знание какой ссылки изображение и быть в состоянии предотвратить, скажем, привлечение любого другого потока.

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

Путем «видоизменения метода» мы имеем в виду те методы, делающие явную мутацию, как-setSize: или-addRepresentation:. Мы делаем средние методы _not_ как-drawInRect:fromRect:operation:fraction: это может изменить ivars изображения как побочный эффект кэширования и ленивого сбоя и такого. Если изображение будет иметь внутреннее кэширование или лень, то это будет обработано в пути, не повреждающем потокобезопасность. Блокировка внимания на изображение и рисование в ней являются мутацией, однако, как изменяет bitmapData NSBitmapImageRep.

Существует одно существенное исключение к вышеупомянутому правилу: Даже при том, что это - мутация, можно вызвать - [NSBitmapImageRep incrementalLoadFromData:complete:], в то время как другие потоки получают доступ к изображению.

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

NSBitmapImageRep: согласование импедансов CoreGraphics и примечания производительности

Информация о версии выше подробного ядра изменяется на уровне NSImage для SnowLeopard. Существуют также существенные изменения на уровне NSBitmapImageRep, также для производительности и улучшить согласование импедансов с CoreGraphics.

NSImage является довольно абстрактным представлением изображения. Это - в значительной степени просто вещь, которая может нарисовать, хотя это менее абстрактно, чем NSView, в котором это не должно вести себя по-другому базируемые аспекты контекста, это вовлечено за исключением качественных решений. Это - вид непрозрачного оператора, но он может быть проиллюстрирован с примером: при рисовании кнопки в 100x22 область по сравнению с 22x22 область можно ожидать, что кнопка расширит свою середину, но не свои заглушки. Изображение не должно вести себя тот путь (и если Вы попробуете его, то Вы, вероятно, повредитесь!). Изображение должно всегда линейно и унифицированно масштабироваться для заполнения rect, в котором ее нарисованный, хотя оно может выбрать представления и такой для оптимизации качества для той области. Точно так же все представления изображения в NSImage должны представлять то же получение. Не упаковывайте некоторое полностью различное изображение в как репутация.

То отклонение мимо нас, NSBitmapImageRep является намного более конкретным объектом. NSImage не имеет пикселей, NSBitmapImageRep делает. NSBitmapImageRep является блоком данных вместе с информацией о формате пикселя и информацией о цветовом пространстве, позволяющей нам интерпретировать данные как прямоугольную антенную решетку значений цвета.

Это - то же, в значительной степени, как CGImage. В SnowLeopard NSBitmapImageRep исходно поддерживается CGImageRef, в противоположность непосредственно блоку данных. CGImageRef действительно имеет блок данных. В то время как в Leopard NSBitmapImageRep, который инстанцируют от CGImage, распаковал бы и возможно обработал бы данные (который происходит при чтении из формата растровых изображений), в SnowLeopard, который мы очень стараемся просто подвесить на исходный CGImage.

Это имеет некоторые последствия производительности. Большинство хорошо! Необходимо видеть меньше кодирования и декодирования растровых данных как CGImages. Если Вы инициализируете NSImage от файла JPEG, то рисуете его в PDF, необходимо получить PDF того же размера файла как исходный JPEG. В Leopard Вы видели бы PDF размер распакованного изображения. Для взятия другого примера кэши CoreGraphics, включая загрузки на видеокарту, связываются к экземплярам CGImage, таким образом, больше тот же экземпляр может использоваться лучше.

Однако: В некоторой степени операции, которые быстры с NSBitmapImageRep, изменились. CGImages не являются непостоянными, NSBitmapImageRep. При изменении NSBitmapImageRep внутренне он должен будет, вероятно, скопировать данные из CGImage, включить изменения и перепаковать его как новый CGImage. Так, в основном привлечение NSBitmapImageRep быстро, смотреть на или изменение его пиксельных данных не. Это было истиной в Leopard, но это - больше истины теперь.

Вышеупомянутые шаги действительно происходят лениво: Если Вы сделаете что-то, что заставляет NSBitmapImageRep копировать данные из своей поддержки CGImageRef (как вызов bitmapData), то битовый массив не перепакует данные как CGImageRef, пока это не будет нарисовано или пока этому не нужен CGImage по некоторой другой причине. Так, конечно доступ к данным не является концом света и является правильным решением при некоторых обстоятельствах, но в целом необходимо думать о рисовании вместо этого. Если Вы думаете, что хотите работать с пикселями, смотреть на CoreImage вместо этого - это - API в нашей системе, действительно предназначающейся для пиксельной обработки.

Это совпадает с безопасностью. Проблема, которую мы видели с нашими изменениями SnowLeopard, состоит в том, что приложения довольно любят растровые форматы жесткого кодирования. NSBitmapImageRep мог быть 8, 32, или 128 бит на пиксель, это могла быть плавающая точка или нет, это могло быть предварительно умножено или нет, это могло бы или не могло бы иметь альфа-канала и т.д. Эти аспекты указаны с растровыми свойствами, как-bitmapFormat. К сожалению, если кто-то хочет извлечь bitmapData из экземпляра NSBitmapImageRep, они обычно просто вызывают bitmapData, обрабатывают данные, как (говорят) предварительно умноженный RGBA на 32 бита на пиксель, и если это, кажется, работает, прекращает дело.

Теперь, когда NSBitmapImageRep не обрабатывает данные так, как это привыкло для, у случайных представителей растрового изображения, из которых можно схватить, могут быть различные форматы, чем они привыкли для. Некоторые из тех форматов hardcoded могли бы быть неправильными.

Решением является _not_, чтобы попытаться обработать полный спектр форматов, в которых могли бы быть данные NSBitmapImageRep, это слишком твердо. Вместо этого вовлеките битовый массив во что-то чей формат Вы _know _, затем смотрите на это.

Это похоже на это:
NSBItmapImageRep *bitmapIGotFromAPIThatDidNotSpecifyFormat;
NSBitmapImageRep *bitmapWhoseFormatIKnow = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL pixelsWide:width pixelsHigh:height
bitsPerSample:bps samplesPerPixel:spp hasAlpha:alpha isPlanar:isPlanar
colorSpaceName:colorSpaceName bitmapFormat:bitmapFormat bytesPerRow:rowBytes
bitsPerPixel:pixelBits];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setContext:[NSGraphicsContext graphicsContextWithBitmapImageRep:bitmapWhoseFormatIKnow]];
[bitmapIGotFromAPIThatDidNotSpecifyFormat draw];
[NSGraphicsContext restoreGraphicsState];
unsigned char *bitmapDataIUnderstand = [bitmapWhoseFormatIKnow bitmapData];
Это не производит больше копий данных, чем просто доступ bitmapData bitmapIGotFromAPIThatDidNotSpecifyFormat, так как те данные должны были бы быть скопированы из поддержки CGImage так или иначе. Также обратите внимание на то, что это не зависит от исходного рисования, являющегося битовым массивом. Это - способ получить пиксели в известном формате для любого получения, или только получить битовый массив. Это - намного лучший способ получить битовый массив, чем вызов-TIFFRepresentation, например. Это также лучше, чем блокировка внимания на NSImage и использование - [NSBitmapImageRep initWithFocusedViewRect:].

Так, для подведения:
(1) Получение быстро. Игра с пикселями не.
(2) Если Вы думаете, что необходимо играть с пикселями, (a) рассматривают, существует ли способ сделать это с рисованием, или (b) изучают CoreImage.
(3) Если Вы все еще хотите достигнуть пиксели, вовлечь битовый массив, формат которого Вы знаете и смотрите на те пиксели.

Отладка производительности NSImage: NSNewBitmapBackingStore

Самое фундаментальное правило отобразить производительность на Mac OS X является этим: Если Вы видите, что что-то неоднократно рисует на экране, он должен быть нарисован с тем же идентичным объектом изображения каждый раз.

В 10,6 существует закрытая функция, чтобы помочь Вам заметить, не управляете ли Вы этим. NSNewBitmapBackingStore является точкой трубы в AppKit для того, чтобы сделать новый буфер данных изображения. Новые буферы данных изображения означают новые изображения.

Таким образом Вы не хотите видеть, что это функциональное прохождение на каждом кадре во время повторных ситуаций с получением как живой изменяет размеры. DTrace через Инструменты является хорошим способом видеть, происходит ли это. В Инструментах выберите «Build New Instrument …» из меню Instrument. Заполните «AppKit» для Библиотеки и NSNewBitmapBackingStore для функции. Теперь начните записывать в Инструментах и используйте свое приложение в качестве нормального. Вы будете видеть вспышку каждый раз, когда вызвана функция. Поверхностное знание вызовов нормально, но если Вы видите, что оно вызвало неистово тогда, у Вас, вероятно, есть проблема производительности.

Несколько вещей отметить:

(1) Это - закрытая функция. Это означает, что не обязательно будет там в будущем. Вы можете использовать его для отладки, но не компилируете знание его в приложение.
(2) Цель не состоит в том, чтобы избежать видеть эту вызванную функцию, цель состоит в том, чтобы заставить Ваше приложение выполнить лучше. При припадании до Кварцевого уровня для создания изображений, например, можно обойти вызывание этой функции, не делая приложение лучше. Скорее если Вы видите, что эта функция вызывается набор, попытайтесь понять, почему новые изображения создаются и адресуют причину. Другой материал в этой информации о версии может помочь Вам понять.

NSBitmapImageRep известное исправление ошибки: - [NSBitmapImageRep CGImage], более безопасный теперь

В Leopard, - [NSBitmapImageRep CGImage] был бы при большинстве обстоятельств возвращать CGImage, не сохраненный растровой репутацией, но который вызвал бы катастрофический отказ, если бы к его данным получили доступ (например, путем рисования его) после того, как была уничтожена растровая репутация.

Это фиксируется в SnowLeopard.

NSBitmapImageRep: Расширенная поддержка цветового пространства

До SnowLeopard NSBitmapImageRep поддерживал определенные цветовые пространства через свойство имени цветового пространства и данные профиля ICC через - [NSBitmapImageRep valueForProperty:] со свойством NSImageColorSyncProfileData.

Для SnowLeopard мы добавляем поддержку работы непосредственно с цветовыми пространствами.
- (NSColorSpace *)colorSpace;
- (NSBitmapImageRep *)bitmapImageRepByConvertingToColorSpace:(NSColorSpace *)targetSpace renderingIntent:(NSColorRenderingIntent)renderingIntent;
- (NSBitmapImageRep *)bitmapImageRepByRetaggingWithColorSpace:(NSColorSpace *)newSpace;
Оба - [NSBitmapImageRep bitmapImageRepByConvertingToColorSpace:renderingIntent:] и - [NSBitmapImageRep bitmapImageRepByRetaggingWithColorSpace:] может перестать работать, когда они возвратят ноль. Последние определенно _will_ перестали работать, если Вы передаете цветовое пространство, имеющее различную модель цветового пространства, чем получатель. Т.е. если Ваше исходное изображение является sRGB, можно только повторно тегировать с некоторым другим цветовым пространством RGB.

Оба метода возвратят исходное растровое изображение, если оно уже будет иметь требуемое цветовое пространство.

NSComboBox

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

NSDrawThreePartImage принимает нулевые прописные буквы

С 10,6, NSDrawThreePartImage может обработать ноль или для прописной буквы запуска или для заглушки в NSDrawThreePartImage. При передаче ноля для обоих Вы будете размещать изображение заливки рядом или горизонтально или вертикально через указанный rect.



Поддержка изображений EPS

Изображения EPS могут теперь быть считаны без катастрофического отказа, хотя изображения с ограничительной рамкой, указанной в конце файла, вероятно, все еще загрузятся с неправильной ограничительной рамкой.


Повернутый PDFs в образцах

PDFs с / Вращаются, запись теперь правильно выведены на экран повернутые, когда используется в образцах (например, + [NSColor colorWithPatternImage:]).


NSPasteboard

Многократные элементы области монтажа

Исторически, NSPasteboard был в состоянии сохранить многократные представления данных единственного логического элемента. Каждое представление является данными определенного типа, включенного именем типа. В SnowLeopard NSPasteboard добавляет поддержку многократных элементов области монтажа. Каждый элемент представляет единственный логический элемент, который может содержать многократные представления данных. До многократных элементов области монтажа множественное число pboard типы было необходимо для помещения многократных частей данных на единственный логический элемент области монтажа. Например, NSFilenamesPboardType состоит из массива путей к файлам все объединенные в один сериализированный список свойств. Используя многократные элементы области монтажа, аналогичная работа привела бы к многократным элементам области монтажа с каждым файлом URL, представленный единственным элементом области монтажа.

Взаимодействие с NSPasteboard всегда было центрально типом данных, центрировалось вокруг получения и установки данных для определенных типов. Новый API NSPasteboard также допускает высокоуровневые центральные классом операции при тихом разрешении центрального типом взаимодействия при необходимости.

Например, следующий код пишет надлежащие данные из NSAttributedString на общую область монтажа:
    NSAttributedString *attString =...;
NSPasteboard *pboard = [NSPasteboard generalPasteboard];
[pboard clearContents];
[pboard writeObjects:[NSArray arrayWithObject:attString]];
Следующий код считывает данные из каждого элемента области монтажа и создает экземпляр NSAttributedString из каждого элемента, содержащего данные, с которыми может быть инициализирована приписанная строка:
    NSPasteboard *pboard = [NSPasteboard generalPasteboard];
NSArray *desiredClasses = [NSArray arrayWithObject:[NSAttributedString class];
NSArray *attributedStrings = [pboard readObjectsForClasses:desiredClasses] options:nil];
И, для вещей, таких как проверка пункта меню, следующий код проверяет, может ли по крайней мере один экземпляр NSAttributedString быть создан из содержания области монтажа:
    NSPasteboard *pboard = [NSPasteboard generalPasteboard];
NSArray *desiredClasses = [NSArray arrayWithObject:[NSAttributedString class];
BOOL canRead = [pboard canReadObjectForClasses:desiredClasses] options:nil];
Эта функциональность поддерживается двумя новыми протоколами, NSPasteboardWriting и NSPasteboardReading. Эти протоколы соответственно позволяют классу указывать, какие типы данных его экземпляры могут обеспечить для области монтажа, и из каких типов данных его экземпляры могут быть созданы. NSAttributedString классов Какао, NSImage, NSColor, NSURL, NSString и NSSound реализуют этот протокол так, чтобы общие типы области монтажа могли быть просто написаны и читать. Другие классы, такие как классы приложения модели, могут также реализовать эти протоколы и использоваться тем же способом.

См. NSPasteboard.h для получения дополнительной информации и примеры использования многократных элементов области монтажа.

NSPasteboardItem

Несмотря на то, что центральный классом APIs является удобной абстракцией от подробных данных типов данных, существуют времена, когда необходимо взаимодействовать с содержанием области монтажа типом данных. Класс NSPasteboardItem, представленный в SnowLeopard, представляет единственный элемент области монтажа и может содержать многократные представления данных. NSPasteboardItem API очень подобен исходному API NSPasteboard со средствами для получения и установки данных типом, а также добавления провайдера данных для предоставления данных лениво.

NSPasteboardItem реализует протоколы NSPasteboardWriting и NSPasteboardReading. Также, Вы добавляете элементы области монтажа к области монтажа путем вызова-writeObjects: и можно считать элементы области монтажа из области монтажа путем вызова-readObjectsForClasses:options: и указывая класс NSPasteboardItem. Как удобство, метод NSPasteboard-pasteboardItems метод возвратит массив всех элементов области монтажа. Метод проверки NSPasteboard-canReadItemWithDataConformingToTypes: проверит, содержит ли какой-либо элемент области монтажа данные, соответствующие указанным типам. Это поддерживает код доступа записи, не прося и выполняя итерации через все элементы области монтажа.

Некоторые случаи, где Вы, возможно, должны использовать элемент области монтажа непосредственно:
1. Когда набор типов хорошо на определенный класс, которые Вы хотите записать в область монтажа не отображается, например, у Вас может быть пользовательский тип области монтажа, который является списком свойств, не отображающимся непосредственно на класс в Вашем приложении. В этом случае Вы могли бы создать элемент области монтажа, установить список свойств для Вашего пользовательского типа, и затем записать элемент области монтажа в область монтажа.

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

3. Когда чтение области монтажа и места назначения данных не является объектом. Например, если бы Ваше приложение обычно использовало CGImages, то Вы могли бы получить массив элементов области монтажа и выполнить итерации через него, ища данные изображения, получив данные для типа изображения, и создав CGImages.

Экземпляр NSPasteboardItem может быть связан с единственной областью монтажа. При первом создании элемента области монтажа он может быть записан в любую область монтажа. Когда Вы передаете в элементе области монтажа-writeObjects: тот элемент области монтажа становится связанным к области монтажа, в которую он был записан. Когда Вы получаете элементы области монтажа с помощью-pasteboardItems или-readObjectsForClasses:options: возвращенные элементы области монтажа связаны с переданной областью монтажа. Передача элемента области монтажа, уже связанного с областью монтажа в-writeObjects: заставляет исключение быть повышенным. Обратите внимание на то, что, пока элемент области монтажа связан с областью монтажа, все методы для установки данных берут влияние на области монтажа.

Элементы области монтажа предназначаются, чтобы быть временными объектами, используемыми во время единственного взаимодействия области монтажа, не сохраненного на и используемый неоднократно. Элемент области монтажа только допустим до владельца изменений области монтажа. Если элемент области монтажа будет устаревшим, потому что владелец области монтажа изменился, то он возвратит ноль или НИКАКИЕ значения от его методов.

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

См. NSPasteboardItem.h для получения дополнительной информации.

Дополнительные примечания NSPasteboard

- В соответствии с историческим соглашением, абсолютный URLs всегда ожидался на области монтажа. Реализация NSURL протокола NSPasteboardWriting формализует это, не обеспечивая типы или данные, которые будут записаны в область монтажа, если URL не является абсолютный URL.

- В SnowLeopard, фильтруя области монтажа только работают и допустимы на первом элементе на области монтажа.

- В SnowLeopard, ни одном из классов Какао, реализующих запись NSPasteboardWriting и NSPasteboardReading или читающих типы, используемые на областях монтажа NSFontPboard и NSRulerPboard.

UTIs на области монтажа

Весь APIs NSPasteboard, представленный в Snow Leopard, принимает UTIs только и не принимает строки NSPboardType. Новый APIs примет неофициально определенную строку UTI. Это - любая строка, следующая соглашению о присвоении имен для UTIs, но формально не объявляющаяся в Info.plist. Эти неофициальные строки UTI полезны для объявления типов области монтажа, которые являются для внутреннего использования в приложении, так как может не быть желательно формально объявить те типы. Если Вы действительно формально объявляете UTIs для использования на области монтажа, UTIs должен соответствовать типу public.data.

Миграция от pboard вводит к UTIs

Использование типов pboard должно быть заменено использованием UTIs. Типы Pboard будут осуждаться в будущем выпуске. Для всех типов pboard, объявленных в AppKit, см. NSPasteboard.h для миграционного пути для каждого типа pboard. В почти всех случаях миграция состоит из замены типом pboard, постоянным для аналогичной основанной на UTI константы. Основное исключение является типом NSFilenamesPboard, где миграционный путь должен использовать новый многократный элемент области монтажа API, чтобы считать и записать файлу URLs на области монтажа. Для пользовательских типов pboard миграционный путь должен или создать константу, следующую соглашениям о присвоении имен UTI, и используйте его в качестве необъявленного неофициального UTI, или формально объявить что постоянный. Посмотрите ниже для получения дополнительной информации, если другие приложения полагаются на Ваши существующие пользовательские типы pboard.

Движущаяся общественность pboard вводит к UTIs

Для приложений, в настоящее время определяющих общественность pboard тип, на который полагаются другие приложения, следующее необходимо, чтобы гарантировать, что существующие приложения будут продолжать видеть Ваш тип pboard даже после того, как Ваше приложение переместилось от типов pboard до UTIs:

1. Формально объявите, что новая область монтажа вводит UTI как экспортируемое описание типа.
2. Гарантируйте, что заявленный UTI соответствует типу public.data.
3. Добавьте спецификацию тега для тега 'com.apple.nspboard-типа' к описанию типа. Обратите внимание на то, что значение, которое Вы обеспечиваете, должно быть значением литеральной строки типа pboard, не именем константы. Спецификация тега в качестве примера для соединения UTI с типом pboard:
    <key>UTTypeTagSpecification</key>
    <dict>
        <key>com.apple.nspboard-type</key>
        <string>MyCustomPboardType</string>
    </dict>

Осуждение PICTPboardType

NSPICTPboardType осуждается в SnowLeopard. Формат PICT формально осуждался у Тигра вместе с QuickDraw. Приложения не должны явно обеспечивать или искать данные PICT по области монтажа.

Помочь в этом осуждении, если PICT является единственным типом изображения на области монтажа, как, иногда имеет место при копировании изображений с 32-разрядных приложений Углерода, о переведенном типе изображения автоматически сообщит и предоставлен NSPasteboard. Переведенный тип добавляется к массиву типов перед PICT так, чтобы осуждаемый формат PICT не был предпочтительным форматом.

Несмотря на то, что NSPICTPboardType и его эквивалентный kUTTypePICT UTI появятся в массиве типа области монтажа, полученном от существующего API NSPasteboard, он может прекратить сообщаться в будущих выпусках.

Чтение типов изображения от области монтажа

Исторически, TIFF был единственным обычно используемым типом области монтажа для данных изображения. С введением поддержки NSPasteboard UTIs возможно поместить данные изображения любого формата на область монтажа.

Это означает, что при получении данных изображения от области монтажа, что несомненно необходимо будет использовать массив типов, возвращенных [NSImage imageTypes], не только NSTIFFPboardType.

Поскольку назад совместимость для приложений соединилась перед SnowLeopard, если мы считаем данные изображения UTIs на области монтажа, но никакое настоящее данных TIFF, NSPasteboard автоматически обещает и переведет в TIFF. Для приложений, соединенных на SnowLeopard, необходимо обновить код области монтажа, чтобы искать и принять любой тип изображения, а не просто TIFF. Используя новый writeObjects: / readObjectsForClasses:options: методы с NSImage обработают это автоматически.

Обещанные данные и Внезапное Завершение

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

Типы области монтажа, предшествующие Mac OS X

NSPasteboard больше не обещает устаревшие (deprecated) типы области монтажа, которые предшествуют Mac OS X и никогда не были общедоступны в Mac OS X: «Простой тип области монтажа ASCII NeXT», «тип области монтажа NXColor», «тип области монтажа имени файла NeXT», «NXTypedFilenamePboardType».

Используя pbcopy и pbpaste с различными кодировками

Инструменты командной строки pbcopy и pbpaste теперь используют стандартные переменные окружения локали для определения кодировки символов, используемой для чтения и записи строковых данных. См. страницы справочника для подробных данных.

Доступность

Описание доступности NSImage

- Свойство accessibilityDescription

В SnowLeopard NSImage добавляет-accessibilityDescription свойство. Строка должна быть локализованным описанием доступности. Если NSImage имеет описание доступности, элементы интерфейса Cocoa, что изображения на дисплее сообщат об описании доступности. Эта функциональность в настоящее время поддерживается NSImageCell, NSButtonCell и NSSegmentedCell.

Это упрощает для элемента единого пользовательского интерфейса сообщать о различном AXDescriptions, в зависимости от которого показано изображение. Например, в приложении чата, различные изображения могли бы использоваться для создания отчетов о состоянии такой как «онлайн», «оффлайн», «далеко». Теперь, можно установить описание доступности для каждого изображения. Когда Вы изменяетесь, какое изображение выведено на экран, ячейка изображения будет сообщать об описании в настоящее время изображение набора.

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

В Leopard константы были представлены в NSImage.h для именованных образов системы. В SnowLeopard эти изображения теперь имеют описание доступности по умолчанию, обеспечивая дополнительную сумму доступности по умолчанию для обычно используемых изображений.

Файл AccessibilityImageDescriptions.strings

В приложениях большинство изображений, используемых в интерфейсе, называют ресурсами, загруженными с помощью +imageNamed NSIMAGE: метод. При обеспечении .strings файла по имени 'AccessibilityImageDescriptions.strings' это будет проверено на описание доступности. Ключи в .strings файле являются именами изображений как предусмотрено к +imageNamed:. Значения являются описанием доступности.

Путь поиска описания изображения

Если строка описания доступности была установлена программно с помощью-setAccessibilityDescription, когда изображение просят относительно его описания доступности: та строка будет возвращена. Если никакая строка не была установлена программно, строковое значение для того изображения в файле приложения AccessibilityImageDescriptions.strings, если есть будет возвращен. Наконец, если AppKit обеспечит значение по умолчанию для изображения, то то значение будет возвращено.

Дополнительные примечания к описанию доступности

Обратите внимание на то, что вызов +imageNamed: неоднократно с тем же именем возвращает тот же экземпляр NSImage. При изменении описания доступности на именованном изображении описание изменится везде, что используется названный экземпляр изображения. При необходимости в различных описаниях для того же изображения, когда используется в различных местах в UI, используйте доступность переопределенный атрибут для предоставления описания на самом элементе UI.

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


NSMenu и доступность NSMenuItem


В SnowLeopard и NSMenu и NSMenuItem поддерживают метод NSAccessibilityAdditions accessibilitySetOverrideValue:forAttribute:. Поддержка является только для значений типа NSString и предназначается, чтобы позволить добавлять AXDescription к пункту меню или пункту меню, содержащему изображение вместо текста.

Ролевые изменения NSLevelIndicator

В SnowLeopard NSLevelIndicator сообщает о новых ролях доступности и подролях.
Дискретные и непрерывные полные стили сообщают о новом NSAccessibilityLevelIndicatorRole как о своей роли. Они также сообщают о новых атрибутах NSAccessibilityWarningValueAttribute и NSAccessibilityCriticalValueAttribute.
Стиль индикатора уместности теперь сообщает о NSAccessibilityRelevanceIndicatorRole как о своей роли.
Стиль индикатора оценки продолжает сообщать о своей роли ползунка, но с NSAccessibilityRatingIndicatorSubrole.

Изменения в установке AXValue текстового представления или текстового поля

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

Новые уведомления доступности представления схемы

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

Дополнительные методы атрибута массива

У клиентов доступности, таких как VoiceOver долго была возможность получить количество или подмассив для любого атрибута доступности, значение которого является массивом. Кроме того, различные внутренние операции доступности полагаются на получение индекса дочернего элемента элемента. Реализация платформы по умолчанию для каждой из этих операций вызывает-accessibilityAttributeValue: получать целый массив значений, и затем выполняет надлежащую работу. Если эти новые методы будут реализованы, то они будут использоваться вместо этого. Для объектов доступности со многими дочерними элементами или многих значений в любом атрибуте массива, результаты к этим методам могут иногда вычисляться, не генерируя целый массив значений, которые могут улучшить производительность.
/* Given an accessibility child of an object, return the index of that child in the parent.
*/
- (NSUInteger)accessibilityIndexOfChild:(id)child;
/* Return the count of an accessibility array attribute.
*/
- (NSUInteger)accessibilityArrayAttributeCount:(NSString *)attribute;
/* Return a subarray of values of an accessibility array attribute.  Note this method does not take a range.
The max count is the maximum desired number of items requested by an accessibility client.
This number may be beyond the bounds of your array.
*/
- (NSArray *)accessibilityArrayAttributeValues:(NSString *)attribute index:(NSUInteger)index maxCount:(NSUInteger)maxCount;

Разные изменения доступности

- NSTableView и подклассы теперь правильно возвращают выбранные столбцы доступности, не индексы выбранного столбца.

- Для табличного представления со скрытыми столбцами AXColumn теперь сообщает о корректном AXIndex.

- NSProgressIndicator больше ошибочно сообщает об атрибуте AXChildren доступности.

- NSScroller больше не сообщает о своем атрибуте AXChildren дважды.

- Кнопки вида теперь правильно сообщают о своей роли AXButton с AXSortButton как подроль.

- Постоянный NSAccessibilitySortButtonRole был осужден и NSAccessibilitySortButtonSubrole, постоянный добавленный.

- Постоянный NSAccessibilityUnknownOrientationValue добавил, чтобы соответствовать AX API.

- Круговые ползунки теперь сообщают о своем AXOrientation как о AXUnknownOrientation.

- AXBusyIndicators и AXProgressIndicators теперь имеют атрибут AXOrientation. Стиль панели сообщает о AXHorizontalOrientation, вращающийся стиль сообщает о AXUnknownOrientation.

- NSAccessibilityPlaceHolderValueAttribute добавил. Интерфейсные элементы со строками заполнителя сообщают о значении заполнителя с помощью этого атрибута.

Разные изменения доступности

- Установка AXFrontmost к истине на приложении Какао теперь выявляет все окна, как это происходит в приложениях Углерода.



Текстовая проверка

Snow Leopard включает новое средство, известное как текстовая проверка, обеспечивающая объединенный интерфейс для множества типов проверки, включая проверку правописания, проверку правописания, обнаружение URL, умные кавычки, дату и обнаружение адреса через Детекторы Данных и других. Среди прочего это средство допускает автоматическую идентификацию языков, используемых в части текста, так, чтобы проверка правописания могла продолжиться без пользователя, имеющего необходимость к тексту метки относительно языка.

Основной интерфейс для этого средства доступен в NSSpellChecker в форме методов
- (NSArray *)checkString:(NSString *)stringToCheck
range:(NSRange)range
types:(NSTextCheckingTypes)checkingTypes
options:(NSDictionary *)options
inSpellDocumentWithTag:(NSInteger)tag
orthography:(NSOrthography **)orthography
wordCount:(NSInteger *)wordCount;
- (NSInteger)requestCheckingOfString:(NSString *)stringToCheck
range:(NSRange)range
types:(NSTextCheckingTypes)checkingTypes
options:(NSDictionary *)options
inSpellDocumentWithTag:(NSInteger)tag
completionHandler:(void (^)(NSInteger seqNumber, NSArray *results, NSOrthography *orthography, NSInteger wordCount))block;
которые запрашивают объединенную текстовую проверку данный диапазон данной строки. checkingTypes должен быть битовой маской проверки типов от заголовка Основы NSTextCheckingResult.h, описав, какие типы проверки желаемы. Словарь опций позволяет клиентам передавать в опциях для определенных типов проверки. В то время как возвращаемое значение является массивом объектов NSTextCheckingResult, описывающих определенные элементы, найденные во время проверки и их отдельных диапазонов, орфография и wordCount параметры возвращают эти два атрибута диапазона в целом. Первый метод здесь вызывает проверку синхронно и сразу возвращает результаты; вторые запросы, проверяющие в фоновом режиме и возвраты, заканчиваются в некоторой более поздней точке к блоку обработчика завершения. Блок обработчика завершения будет вызван в произвольном контексте; если работа завершения должна быть выполнена на основном потоке, клиент должен будет устроить это через performSelector метод или эквивалент. Возвращаемое значение второго метода является монотонно увеличивающимся порядковым номером, который может использоваться для отслеживания запросы в рейсе, и который будет предоставлен как параметр блоку завершения.

NSTextCheckingResult и NSOrthography являются двумя новыми классами, определенными в Основе для использования с текстовой проверкой. Экземпляр NSTextCheckingResult представляет что-то, что было найдено во время проверки - слово с ошибками, предложение с грамматическими проблемами, обнаруженным URL, прямая кавычка, которая будет заменена изогнутыми кавычками и т.д. NSOrthography является классом, используемым для описания лингвистического содержания части текста, специально для целей проверки правописания и проверки правописания. Это описывает (a), пишущий сценарий текста, содержит, (b) доминантный язык и возможно другие языки для каждого из этих сценариев и (c) доминирующий сценарий и язык для текста в целом. Результаты автоматического определения языка описаны с помощью NSOrthography. Дополнительную информацию см. в информации о версии Основы на этих двух классах.

NSSpellChecker имеет дополнительные методы
- (NSArray *)userPreferredLanguages;
- (BOOL)automaticallyIdentifiesLanguages;
- (void)setAutomaticallyIdentifiesLanguages:(BOOL)flag;
- (NSArray *)guessesForWordRange:(NSRange)range inString:(NSString *)string language:(NSString *)language inSpellDocumentWithTag:(NSInteger)tag;
- (NSArray *)userQuotesArrayForLanguage:(NSString *)language;
- (NSDictionary *)userReplacementsDictionary;
упростить использование текстовой проверки и автоматического определения языка. Записи в списке availableLanguages являются всеми доступными языками проверки правописания в порядке пользовательской настройки, как описано в информационном словаре программы проверки правописания, обычно сокращения языка, такие как en_US. userPreferredLanguages будет подмножеством availableLanguages, как выбрано пользователем для использования с проверкой правописания, в предпочтительном порядке. Если automaticallyIdentifiesLanguages будет ДА, то текстовая проверка будет автоматически использовать их в качестве надлежащих; иначе, это будет использовать язык, установленный setLanguage:. Более старый checkSpellingOfString:... и checkGrammarOfString:... методы будут использовать язык, установленный setLanguage: если их вызывают с нулевым параметром языка.

Существуют также следующие методы для поддержки пользовательского интерфейса, связанного с текстовой проверкой:
- (NSPanel *)substitutionsPanel;
- (NSViewController *)substitutionsPanelAccessoryViewController;
- (void)setSubstitutionsPanelAccessoryViewController:(NSViewController *)accessoryController;
- (void)updatePanels;
- (NSMenu *)menuForResult:(NSTextCheckingResult *)result
string:(NSString *)string
options:(NSDictionary *)options
atLocation:(NSPoint)location
inView:(NSView *)view;
вместе с константами
NSString *NSTextCheckingOrthographyKey;
NSString *NSTextCheckingQuotesKey;
NSString *NSTextCheckingReplacementsKey;
NSString *NSTextCheckingReferenceDateKey;
NSString *NSTextCheckingReferenceTimeZoneKey;
NSString *NSTextCheckingDocumentURLKey;
NSString *NSTextCheckingDocumentTitleKey;
NSString *NSTextCheckingDocumentAuthorKey;
использоваться в качестве ключей в словарях опций для checkString:..., requestCheckingOfString:..., и menuForResult:... методы, описанные выше. Все эти ключи являются дополнительными.

Панель замен обеспечивает интерфейс для различной вспомогательной функциональности, связанной с текстовой проверкой. Это может иметь вспомогательное представление, если вспомогательное контроллер представления установлено для него. updatePanels метод является тем, который должны вызвать клиенты, когда любое из их изменений состояния относительно написания, грамматики или текстовой проверки, которая могла бы влиять на написание или панель замен; например, если клиент изменяется, включена ли одна из текстовых функций проверки, она должна вызвать этот метод на совместно используемой программе проверки правописания. menuForResult:string:options:atLocation:inView: метод возвращает меню, содержащее элементы контекстного меню, подходящие для определенных видов обнаруженных результатов (особенно результаты даты/времени/адреса). Аргумент строки является дополнительным; если предоставлено, это должно быть строковое содержание диапазона, обнаруженного результатом. Если действие в конечном счете потребует подъем временного окна, расположение в представлении будет использоваться.

NSTextCheckingOrthographyKey может использоваться для предоставления NSOrthography указание орфографии, которая будет использоваться в качестве начальной точки для проверки орфографии, или как орфография, если не включена проверка орфографии. Значение для NSTextCheckingQuotesKey должно быть NSArray, содержащим четыре строки, которые будут использоваться с NSTextCheckingTypeQuotes (открывающий двойную кавычку, закрывая двойную кавычку, открывая одинарную кавычку, и закрывая одинарную кавычку в том порядке). Значение по умолчанию, используемое, если этот ключ не присутствует, принято от пользовательских настроек и может быть определено через-userQuotesArrayForLanguage: метод. Значение для NSTextCheckingReplacementsKey должно быть NSDictionary, содержащим замены, которые будут использоваться с NSTextCheckingTypeReplacement; если это не будет указано, то значения будут приняты от предпочтений пользователя, и эти значения по умолчанию могут быть получены через метод-userReplacementsDictionary.

NSTextCheckingReferenceDateKey, NSTextCheckingReferenceTimeZoneKey, NSTextCheckingDocumentURLKey, NSTextCheckingDocumentTitleKey и ключи NSTextCheckingDocumentAuthorKey могут использоваться для указания метаданных, связанных с текущим документом для использования с NSTextCheckingTypeDate, NSTextCheckingTypeAddress и NSTextCheckingTypeLink. NSTextCheckingReferenceDateKey может использоваться для предоставления NSDate, который будет использоваться в качестве референта для относительных дат, и NSTextCheckingReferenceTimeZoneKey может использоваться для предоставления NSTimeZone, который будет использоваться в качестве референта для дат без часовых поясов; текущая дата и часовой пояс будут использоваться, если они не будут указаны. Эти ключи могут использоваться, если определенная информация доступна о документе - например, зона даты и времени ее состава, для чего-то как почтовый документ. NSTextCheckingDocumentURLKey может использоваться для указания NSURL, связанного с документом, NSTextCheckingDocumentTitleKey NSString представление заголовка, связанного с документом и NSTextCheckingDocumentAuthorKey NSString представление имени автора, связанного с документом. Они особенно полезны с-menuForResult:string:options:atLocation:inView: метод, предоставляющий пункты меню, подходящие для контекстного меню, которое будет выведено на экран для обнаруженного элемента в данном расположении в представлении.


Текстовая регистрация в NSTextView

Кроме того, существуют методы на NSTextView для поддержки его использования текстовой проверки.
- (void)setAutomaticDataDetectionEnabled:(BOOL)flag;
- (BOOL)isAutomaticDataDetectionEnabled;
- (void)toggleAutomaticDataDetection:(id)sender;
- (void)setAutomaticDashSubstitutionEnabled:(BOOL)flag;
- (BOOL)isAutomaticDashSubstitutionEnabled;
- (void)toggleAutomaticDashSubstitution:(id)sender;
- (void)setAutomaticTextReplacementEnabled:(BOOL)flag;
- (BOOL)isAutomaticTextReplacementEnabled;
- (void)toggleAutomaticTextReplacement:(id)sender;
- (void)setAutomaticSpellingCorrectionEnabled:(BOOL)flag;
- (BOOL)isAutomaticSpellingCorrectionEnabled;
- (void)toggleAutomaticSpellingCorrection:(id)sender;
- (NSTextCheckingTypes)enabledTextCheckingTypes;
- (void)setEnabledTextCheckingTypes:(NSTextCheckingTypes)checkingTypes;
Включение автоматического обнаружения данных включает обнаружение и даты и элементов адреса/телефонного номера; включение автоматической замены тире включает автоматическое преобразование последовательностей ASCII '-' к типографским тире; включение автоматической текстовой замены включает автоматическую замену множества элементов статического текста на основе пользовательских настроек; и включение автоматического исправления орфографических ошибок включает автоисправление определенных орфографических ошибок. Кроме того, текстовая проверка теперь используется для непрерывной проверки правописания и проверки правописания, автоматического обнаружения ссылки и автоматической замены кавычки.-enabledTextCheckingTypes и-setEnabledTextCheckingTypes: методы позволяют состоянию всех этих форм проверки быть полученным или установленным сразу.
- (void)orderFrontSubstitutionsPanel:(id)sender;
- (void)checkTextInSelection:(id)sender;
- (void)checkTextInDocument:(id)sender;
-orderFrontSubstitutionsPanel: метод переносит на следующий период панель, предоставленную NSSpellChecker, позволяющим управление различными включенными типами замены. Например, это предоставляет пользователю возможность использовать-checkTextInSelection: и-checkTextInDocument: методы действия. Обычно текстовая проверка происходит в фоновом режиме, и результаты, заменяющие текст, применяются только к тексту, введенному пользователем, но эти два метода заставляют в настоящее время включаемый текст, проверяющий типы быть сразу примененным к выбору или к документу, соответственно, и результаты, заменяющие текст, применяются независимо от источника текста.
- (void)checkTextInRange:(NSRange)range types:(NSTextCheckingTypes)checkingTypes options:(NSDictionary *)opts;
- (void)handleTextCheckingResults:(NSArray *)results
forRange:(NSRange)range
types:(NSTextCheckingTypes)checkingTypes
options:(NSDictionary *)options
orthography:(NSOrthography *)orthography
wordCount:(NSInteger)wordCount;
checkTextInRange:types:options: и handleTextCheckingResults:forRange:orthography:wordCount: методы вызовет NSTextView как надлежащие, когда текстовая проверка будет запущена и когда результаты получены, соответственно. Они не предназначаются, чтобы быть вызванными клиентами, но могут быть переопределены, чтобы наблюдать или изменить текст, проверяющий поведение. Тот же вид наблюдения или модификации также будет доступен делегату, с помощью двух новых методов делегата NSTextView
- (NSDictionary *)textView:(NSTextView *)view
willCheckTextInRange:(NSRange)range
options:(NSDictionary *)options
types:(NSTextCheckingTypes *)checkingTypes;
- (NSArray *)textView:(NSTextView *)view
didCheckTextInRange:(NSRange)range
types:(NSTextCheckingTypes)checkingTypes
options:(NSDictionary *)options
results:(NSArray *)results
orthography:(NSOrthography *)orthography
wordCount:(NSInteger)wordCount;
это вызовет checkTextInRange:types:options: и handleTextCheckingResults:forRange:orthography:wordCount: соответственно.


Двунаправленный текст

Snow Leopard включает много новых средств для поддержки записи и редактирования двунаправленного текста, такого как иврит или арабский язык. Во-первых, существует новый приписанный строковый атрибут, NSWritingDirectionAttributeName, предназначенный для обеспечения высокоуровневой альтернативы включению явных двунаправленных управляющих символов, таких как LRE, RLE, LRO, RLO и PDF в тексте. Это дает приписанную строку, эквивалентную тому, что в HTML было бы выражено такими конструкциями как <dir промежутка = «буква»> </промежуток>, <dir промежутка = «rtl»> </промежуток>, <bdo dir = «буква»> </промежуток>, и <bdo dir = «rtl»> </промежуток>..

Значение этого атрибута должно быть массивом NSNumbers, каждый из которых должен иметь значение 0, 1, 2, или 3, рассмотренный как состоящий из любого NSWritingDirectionLeftToRight (= 0) или NSWritingDirectionRightToLeft (= 1) плюс одна из новых констант NSTextWritingDirectionEmbedding (= 0) или NSTextWritingDirectionOverride (= 2). Этот массив представляет последовательность вложенного двунаправленного embeddings или переопределений, в порядке от наиболее удаленного до самого внутреннего, с 0 (NSWritingDirectionLeftToRight | NSTextWritingDirectionEmbedding) соответствие паре LRE/PDF в простом тексте или <dir промежутка = «буква»> </промежуток> в HTML, 1 (NSWritingDirectionRightToLeft | NSTextWritingDirectionEmbedding) соответствие паре RLE/PDF в простом тексте или <dir промежутка = «rtl»> </промежуток>, 2 (NSWritingDirectionLeftToRight | NSTextWritingDirectionOverride) соответствие паре LRO/PDF в простом тексте или <bdo dir = «буква»> </промежуток>, и 3 (NSWritingDirectionRightToLeft | NSTextWritingDirectionOverride) соответствие паре RLO/PDF в простом тексте или <bdo dir = «rtl»> </промежуток> в HTML.

В целом должно быть очень немного ситуаций, требующих использования больше чем одного уровня двунаправленного embeddings или переопределений, но в случае необходимости NSWritingDirectionAttributeName будет поддерживать вложение до максимальной глубины вложения, предусмотренной Unicode двунаправленный алгоритм. Для определения значения для этого атрибута для данного символа отметьте все embeddings или переопределения, которые должны примениться к тому символу, в порядке их вложения от наиболее удаленного до самого внутреннего, и для каждого добавляют NSNumber к массиву, значение которого указывает тип встраивания или переопределения, как описано выше.

Намерение состоит в том, что новый атрибут должен использоваться в предпочтении к вставке явных двунаправленных управляющих символов в тексте, каждый раз, когда текст редактируется, даже если не используется обогащенный текст; т.е. эти атрибуты считаются полезными даже с простым текстом из-за трудностей редактирования текста, содержащего явные управляющие символы. Когда содержание текстового хранения фактически преобразовывается в формат файла простого текста для хранения или обмена, тогда атрибут должен был бы быть заменен явными двунаправленными управляющими символами, и аналогично при загрузке простого текста в текстовое хранение для редактирования, явные двунаправленные управляющие символы должны будут быть заменены подходящими значениями атрибута. NSTextView сделает это автоматически на копии и вставке и NSAttributedString на преобразовании в и от внешних форматов. В некоторых случаях NSTextView может автоматически применить этот атрибут к тексту, вводящемуся в двунаправленных контекстах, где это необходимо для разрешения случаев неоднозначности в направленности. Пользователи просто слева направо текста никогда не должны встречаться с этим атрибутом.

Кроме того, существуют новые методы действия, определенные на NSResponder и реализованные в NSTextView для установки значений и NSWritingDirectionAttributeName и существующей основы уровня абзаца запись направления, определенного на NSParagraphStyle.
- (void)makeBaseWritingDirectionNatural:(id)sender;
- (void)makeBaseWritingDirectionLeftToRight:(id)sender;
- (void)makeBaseWritingDirectionRightToLeft:(id)sender;
- (void)makeTextWritingDirectionNatural:(id)sender;
- (void)makeTextWritingDirectionLeftToRight:(id)sender;
- (void)makeTextWritingDirectionRightToLeft:(id)sender;
Первые три из них устанавливают основу уровня абзаца запись направления на NSParagraphStyle к NSWritingDirectionNatural, NSWritingDirectionLeftToRight или NSWritingDirectionRightToLeft соответственно. Последние три из них устанавливают новый символьный уровень NSWritingDirectionAttributeName. В частности, makeTextWritingDirectionNatural: удаляет NSWritingDirectionAttributeName и makeTextWritingDirectionLeftToRight: и makeTextWritingDirectionRightToLeft: установите его в сингл слева направо или справа налево встраивающий соответственно. (Никакие методы действия не предоставлены для установки двунаправленных переопределений, или к вложенному множеству embeddings или переопределениям.)

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

Предыдущий общедоступный метод действия для записи направления,-toggleBaseWritingDirection: больше не рекомендуется для использования и будет формально осуждаться в будущем.


Дополнительные методы привязки клавиш

Существует четыре новых дополнительных метода привязки клавиш, определенные на NSResponder и реализованные в NSTextView,
- (void)moveToLeftEndOfLine:(id)sender;
- (void)moveToRightEndOfLine:(id)sender;
- (void)moveToLeftEndOfLineAndModifySelection:(id)sender;
- (void)moveToRightEndOfLineAndModifySelection:(id)sender;
предназначенный для привязки с cmd-и cmd-shift-left/right стрелкой, для устранения неоднозначности прежних похожих методов, выраженных с точки зрения начала и конца строки в случаях двунаправленного текста.

Существует также много других методов привязки клавиш, также определенных на NSResponder и реализованных в NSTextView, присутствовавших и связавших с ключами в течение некоторого времени, но не явно общедоступные:
- (void)moveToBeginningOfLineAndModifySelection:(id)sender;
- (void)moveToEndOfLineAndModifySelection:(id)sender;
- (void)moveToBeginningOfParagraphAndModifySelection:(id)sender;
- (void)moveToEndOfParagraphAndModifySelection:(id)sender;
- (void)moveToEndOfDocumentAndModifySelection:(id)sender;
- (void)moveToBeginningOfDocumentAndModifySelection:(id)sender;
- (void)pageDownAndModifySelection:(id)sender;
- (void)pageUpAndModifySelection:(id)sender;
- (void)moveParagraphForwardAndModifySelection:(id)sender;
- (void)moveParagraphBackwardAndModifySelection:(id)sender;
- (void)scrollToBeginningOfDocument:(id)sender;
- (void)scrollToEndOfDocument:(id)sender;
- (void)insertSingleQuoteIgnoringSubstitution:(id)sender;
- (void)insertDoubleQuoteIgnoringSubstitution:(id)sender;
Эти методы были теперь обнародованы.


Методы NSLayoutManager

NSLayoutManager теперь имеет метод
- (NSUInteger)characterIndexForPoint:(NSPoint)point
inTextContainer:(NSTextContainer *)container
fractionOfDistanceBetweenInsertionPoints:(CGFloat *)partialFraction;
аналогичный glyphIndexForPoint:inTextContainer:fractionOfDistanceThroughGlyph: но выраженный в условиях индекса символа. Метод возвращает индекс символа, подпадающего под данную точку, выраженную в системе координат данного контейнера; если никакой символ не находится под точкой, самый близкий символ возвращается, где самый близкий определяется согласно требованиям выбора мышью. Однако это не просто эквивалентно взятию результата соответствующего индексного метода глифа и преобразования его к индексу символа, потому что в некоторых случаях единственный глиф представляет больше чем один выбираемый символ, например fi глиф лигатуры. В этом случае в глифе будет точка вставки, и этот метод возвратит один символ или другой, в зависимости от того, находится ли указанная точка налево или право на ту точку вставки. В целом этот метод возвратит только индексы символа, для которых существует точка вставки. Элементарная дробь является частью расстояния от точки вставки логически перед данным символом к следующему, который может быть или вправо или налево в зависимости от направленности.

Кроме того, существует новый метод
- (void)fillBackgroundRectArray:(NSRectArray)rectArray count:(NSUInteger)rectCount forCharacterRange:(NSRange)charRange color:(NSColor *)color;
используемый в качестве примитива для получения rect-drawBackgroundForGlyphRange:atPoint: для того, чтобы фактически заполнить rects определенным цветом фона, необходимы ли вследствие атрибута цвета фона, выбранное или отмеченное выделение диапазона, блочное художественное оформление или какая-либо другая заливка rect тому методу. Как с-showPackedGlyphs:..., диапазон символов и цвет просто для информационных целей; цвет будет уже выбран в состоянии графики. По какой-либо причине при изменении его необходимо восстановить его прежде, чем возвратиться из этого метода. Вы никогда не должны вызывать этот метод, но Вы могли бы переопределить его. Реализация по умолчанию просто заполнит указанный массив rect. Графической работой, используемой для этой заливки, управляет проверка ссылки; по причинам совместимости это будет NSCompositeCopy для приложений, соединенных до Snow Leopard и NSCompositeSourceOver для приложений, соединенных на Snow Leopard или позже. Приложения могут управлять работой, используемой, или изменить получение путем переопределения этого метода в подклассе NSLayoutManager.


Объединение отмены NSTextView

NSTextView теперь имеет метод
- (BOOL)isCoalescingUndo;
соглашаться с предыдущим-breakUndoCoalescing. Когда объединение отмены происходит, новый метод разрешает клиентам определять.


NSTextList, начинающий номер изделия

NSTextList теперь имеет два метода
- (void)setStartingItemNumber:(NSInteger)itemNum;
- (NSInteger)startingItemNumber;
для предоставления стартового номера изделия для данного списка. Значение по умолчанию равняется 1. Это значение будет использоваться только для упорядоченных списков и игнорироваться в других случаях.


Константы NSAttributedString

Существующие явно выраженные типы документов NSDocumentTypeDocumentAttribute и NSDocumentTypeDocumentOption с точки зрения ряда констант, определенных к NSAttributedString. В Snow Leopard существуют новые константы, NSFileTypeDocumentAttribute и NSFileTypeDocumentOption, тот экспресс та же информация с точки зрения UTIs в масштабе всей системы. Где они используются для вывода в выражении типа документа, считанного, и тип файла и тип документа будут предоставлены; как введено, однако, при указании типа, который будет записан или тип, который будет вызван на загрузке, эти два являются взаимоисключающими.

Строка NSAttributed также имеет два новых атрибута метаданных, NSManagerDocumentAttribute и NSCategoryDocumentAttribute.



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

NSTableView и NSOutlineView теперь поддерживают автокалибровку столбцов таблицы, когда Вы дважды щелкаете по изменять размеры делителю, который является непосредственно направо от данного столбца. По умолчанию NSTableView выполняет итерации каждой строки в таблице, получает доступ к ячейке через preparedCellAtRow:column: и запросы-cellSize, чтобы найти, что надлежащая самая большая ширина использует. Для производительности рекомендуется, чтобы программист реализовал новый метод делегата (-tableView:sizeToFitWidthOfColumn: или-outlineView:sizeToFitWidthOfColumn:) для быстрого определения размера.

indentationPerLevel свойство на NSOutlineView теперь работает лучше на приложения, соединенные на SnowLeopard или выше. Ранее, это расположило бы каждый уровень с отступом indentationPerLevel - включая элементы на уровне 0. Это имеет нежелательный побочный эффект расположения с отступом слишком много, когда значение было большим, и недостаточно показать треугольник раскрытия, когда значение было маленьким. В SnowLeopard-связанных-приложениях, если indentationPerLevel больше, чем 0, уровень 0 будет иметь определенную ширину, содержащую достаточно комнаты для треугольника раскрытия на основе текущего selectionHighlightStyle. Все другие уровни будут должным образом расположены с отступом 'indentationPerLevel'.

NSTableView теперь имеет метод для корректного лишения законной силы ячеек для перерисовки:-reloadDataForRowIndexes:columnIndexes:. Метод эффективно восстановит изображение только строки/столбцы, которые фактически видимы.

NSTableView теперь поддерживает ограничение переупорядочения определенных столбцов с новым методом делегата:-tableView:shouldReorderColumn:toColumn:.

Для приложений, соединенных на SnowLeopard и позже,-cellSizeForBounds: (и впоследствии-cellSize), возвратит корректную ширину для NSTableHeaderCells. Ранее, если бы связанный NSTableColumn имел набор sortDescriptorPrototype, это не возвратило бы размер, достаточно большой для индикатора вида.

Mac OS 10,5 Leopard представил фокусировку подъячейки. SnowLeopard теперь позволяет управление разработчика подъячейкой, фокусирующейся с несколькими методами.-shouldFocusCell:atColumn:row: может быть переопределен, чтобы управлять, может ли фокусироваться ячейка.-focusedColumn является фокусирующимся определенным столбцом. Обратите внимание на то, что фокус только показан для-selectedRow (при наличии). Наконец, фокусируемые ячейки позволяют щелкать через клавишу «Пробел», и метод предоставлен для разработчиков, чтобы вызвать или переопределить:-performClickOnCellAtColumn:row:.

Когда меню присваивается экземпляру NSTableView, Leopard представил выделение пользовательского меню. Подклассификаторы, переопределяющие-menuForEvent: и возвратитесь, новый экземпляр меню заставил бы NSTableView неправильно выделяться. Ранее, это наблюдало бы за NSMenuDidEndTrackingNotification всего за одним меню, и теперь это наблюдает за всеми меню для исправления этой проблемы. Для совместимости Leopard рекомендуется, чтобы Вы не создавали новый экземпляр меню, и вместо этого использовали текущий как показано в демонстрационном приложении DragNDropOutlineView.

На Leopard, expandItem NSOutlineView: метод начал позволять 'ноль' как опцию развернуть все элементы от корня. Перед Leopard это вызвало бы утверждение. При развертывании приложения на выпуске перед Leopard Вы не должны использовать expandItem:nil, как это будет утверждать.

Обновления NSTableViewSelectionHighlightStyle: существует теперь стиль подсветки, не рисующий выделения вообще, но все еще позволяющий строкам быть выбранными: NSTableViewSelectionHighlightStyleNone. NSTableViewSelectionHighlightStyleSourceList был также обновлен, чтобы больше не отменить выбор всех строк при щелчке по вакууму в табличном представлении.

Даже если выравнивание для ячейки будет установлено в правую сторону, для приложений, соединенных на SnowLeopard или позже, NSTableHeaderCell будет всегда рисовать индикатор вида на правой стороне. Ранее, когда выравнивание было установлено вправо, это нарисовало бы его слева.

Для приложений, соединенных на SnowLeopard или позже,-rowAtPoint: правильно возвратится-1, если точка передала, за пределами горизонтальных границ представления. Ранее, только вертикальные границы были проверены.

NSTableView теперь имеет новое draggingDestinationFeedbackStyle свойство. Одно из значений NSTableViewDraggingDestinationFeedbackStyle приемлемо для него. Опция NSTableViewDraggingDestinationFeedbackStyleSourceList является подходящей для исходных списков или вещей, появляющихся, поскольку источник перечисляет, но не использует исходный список, выделяющий стиль (такой как AddressBook). NSTableViewDraggingDestinationFeedbackStyleRegular является теперь стандартным взглядом по умолчанию, отличающимся от Leopard путем рисования существенного раунда - rect синий фон вокруг целевых строк отбрасывания. Для совместимости этот стиль будет значением по умолчанию для приложений, соединяющихся на SnowLeopard или позже. Другие приложения будут использовать NSTableViewDraggingDestinationFeedbackStyleSourceList, который был значением по умолчанию, ищут Leopard. Приложения, предназначающиеся для Leopard, могут все еще получить взгляд SnowLeopard первым выполнением [tableView respondsToSelector:@selector (setDraggingDestinationFeedbackStyle:) ] проверьте прежде, чем вызвать метод. Существует также опция NSTableViewDraggingDestinationFeedbackStyleNone не показать «обратную связь отбрасывания». Этот стиль является подходящим для подклассов то, что управлять получением самих и отключить получение NSTableView по умолчанию.

До SnowLeopard NSTableView и NSOutlineView всегда пытались бы включить живой - изменяют размеры довольный кэширование, даже если подкласс переопределил preservesContentDuringLiveResize и возвратился НЕТ. На SnowLeopard это теперь работает для возврата НЕ из preservesContentDuringLiveResize для предотвращения живой - изменяют размеры кэширования изображения. До SnowLeopard можно было отключить его путем переопределения-drawRect: и делая только вызывающий [супер drawRect:rect]. Если Ваше приложение предназначается для предшествующих выпусков, рекомендуется сделать обоих.

Для приложений, соединяющихся на SnowLeopard и выше, NSOutlineView правильно установит бит «isItemExpanded:item» для элемента к YES только AFTER, отправляющий outlineViewItemWillExpand: уведомление. Точно так же NSOutlineView правильно установит бит «isItemExpanded:item» для элемента ни к КАКОМУ единственному AFTER, отправляющему outlineViewItemWillCollapse: уведомление. Для приложений, соединяющихся против OS до SnowLeopard, бит будет неправильно установлен прежде, чем отправить уведомление.

Всегда было неправильно возвратить отрицательное количество строки из методов делегата NSTableView и NSOutlineView. Для приложений, соединяющихся на SnowLeopard и выше, возвращая отрицательное количество, будет теперь утверждать для помощи разработчику в отладке таких проблем.

Когда строка будет выбрана, для приложений, соединенных на SnowLeopard и позже, треугольник раскрытия (ячейка схемы) в NSOutlineView правильно будет белым. Возможно переопределить это поведение путем реализации-willDisplayOutlineCell: явно установить backgroundStyle ячейки схемы к NSBackgroundStyleLight. IE:
- (void)outlineView:(NSOutlineView *)outlineView willDisplayOutlineCell:(id)cell
forTableColumn:(NSTableColumn *)tableColumn item:(id)item {
// This explicitly makes the disclosure triangles always be dark
[cell setBackgroundStyle:NSBackgroundStyleLight];
}
NSTableView и NSOutlineView автоматически добавят атрибуты к простому тексту для исходного списка (NSTableViewSelectionHighlightStyleSourceList) стиль подсветки (selectionHighlightStyle). На Leopard были добавлены эти атрибуты, прежде чем backgroundStyle был установлен на ячейке, иногда производя неправильно окрашенные клетки на строках, сразу следовавших за ячейкой строки группы. Это было закреплено на SnowLeopard и может работаться вокруг на Leopard со следующим методом делегата:
- (NSCell *)outlineView:(NSOutlineView *)outlineView
dataCellForTableColumn:(NSTableColumn *)tableColumn item:(id)item {
NSCell *result = tableColumn != nil ? [tableColumn dataCell] : nil;
if (result != nil) {
[result setBackgroundStyle:NSBackgroundStyleLight];
}
return result;
}
На Leopard, когда Вы щелкаете правой кнопкой по строке в NSTableView, который является «строкой группы» (т.е.: столбец-1, указывая, что он охватывает через все строки), он неправильно вызовет preparedCellAtColumn:row: со значением столбца, которое не является-1. Это было закреплено на SnowLeopard для надлежащего вызова его с-1, но приложения, которые должны предназначаться для Leoaprd, должны будут принять это изменение во внимание и быть подготовлены к неправильному вызову.

NSSavePanel / NSOpenPanel - NSURL и Блоки

NSSavePanel и NSOpenPanel теперь имеют свойства NSURL, методы делегата. Кроме того, новые основанные на блоке методы доступны для отображения панелей. Эти версии должны использоваться вместо non-NSURL версий, которые будут осуждаться в будущем выпуске. Старые версии и их замены:
    NSSavePanel:
        имя файла-> URL
        каталог-> directoryURL
        requiredFileType-> Всегда первый элемент в allowedFileTypes

        panel:isValidFilename:-> panel:validateURL:error:
        panel:directoryDidChange:-> panel:didChangeToDirectoryURL
        panel:compareFilename:width:caseSensitive:-> Осуждаемый и не должен использоваться по причинам производительности
        panel:shouldShowFilename:-> panel:shouldEnableURL:

        beginSheetForDirectory:file:modalForWindow:modalDelegate:didEndSelector:contextInfo:-> beginSheetModalForWindow:completionHandler:
        runModalForDirectory:file:-> runModal

    NSOpenPanel:
        имена файлов-> URLS
        beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:-> beginSheetModalForWindow:completionHandler:
        beginForDirectory:file:types:: modelessDelegate:didEndSelector:contextInfo:-> beginSheetModalForWindow:completionHandler:
        runModalForDirectory:file:types:-> runModal
        runModalForTypes:-> runModal

Вы заметите, что существует теперь три приемлемых способа показать открытое или сохранить панель:
  - (NSInteger)runModal;
- (void)beginSheetModalForWindow:(NSWindow *)window completionHandler:(void (^)(NSInteger result))handler;
- (void)beginWithCompletionHandler:(void (^)(NSInteger result))handler;
Методы больше не берут каталог или начальный тип файла. Вместо этого свойства могут быть установлены предшествующий вызов вышеупомянутые методы. До SnowLeopard не было никакого способа установить начальное имя файла; это может теперь быть сделано с:
  - (NSString *)nameFieldStringValue;
- (void)setNameFieldStringValue:(NSString *)value;
Вызов setNameFieldStringValue: если-isExtensionHidden будет установлен в YES, заставит 'значение' быть обработанным немного, чтобы быть приемлемым именем файла, возможно включая сокрытие расширения, базируемого.

Вы заметите, что версия NSOpenPanel не имеет никакого способа показать включенные «типы файлов». Приложения, соединяющиеся на SnowLeopard, могут теперь использовать allowedFileTypes/setAllowedFileTypes: который ранее не использовался для NSOpenPanel. См. заголовок комментирует для получения дополнительной информации.

Использование в качестве примера нового блока базировало методы:
    // Run a modeless open panel for pdf file types:
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
openPanel.allowedFileTypes = [NSArray arrayWithObject:@"com.adobe.pdf"];
[openPanel beginWithCompletionHandler:^(NSInteger result) {
if (result) {
NSLog(@"Picked: %@", openPanel.URLs);
}
}];
    // Run a sheet modal for 'window' that allows saving as a jpeg
NSSavePanel *savePanel = [NSSavePanel savePanel];
savePanel.allowedFileTypes = [NSArray arrayWithObject:@"jpg"];
savePanel.nameFieldStringValue = @"foo.jpg";
[savePanel beginSheetModalForWindow:window completionHandler:^(NSInteger result) {
if (result) {
NSLog(@"Save as: %@", savePanel.URL);
}
}];
Примечания совместимости: Если делегат реализует и старые и новые методы делегата, то новые методы делегата будут использоваться на SnowLeopard, в то время как более старые методы делегата будут использоваться на более старых версиях OS.

NSSavePanel / NSOpenPanel - Общие Обновления

NSSavePanel и NSOpenPanel теперь имеют сочетание клавиш для показа скрытых файлов: cmd-shift-period. Скрытые файлы будут показаны только, в то время как тот экземпляр открыт.

Используя только UTIs для включения типов файла приложения в открытой панели не работал над Leopard (com.apple.application-пакет, com.apple.application-пакет, com.apple.application-файл). Работа вокруг должна была включать расширение «приложения» во включенные типы файлов. На SnowLeopard, вся работа UTIs правильно, но для приложений, предназначающихся для Leopard как минимальная операционная система, должно также быть включено расширение «приложения».

NSOpenPanel теперь поддерживает Беглый взгляд. Выберите любые файлы и нажмите клавишу «Пробел» для вызова Quick Look.

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

Открытые и сохраняют панель, теперь позволяет соединяться с совместно используемыми серверами. Боковая панель также теперь содержит раздел SEARCH FOR.

Панель сохранения теперь уважает опцию Finder за, «Показывают все расширения файла». Если это будет установлено, то флажок «Hide Extension» будет скрыт, и расширение будет всегда показываться, всегда возвращая YES из-isExtensionHidden.

Для приложений, соединяющихся на SnowLeopard и выше: NSSavePanel теперь отслеживает кадр accessoryView. Программист может динамично внести изменения в кадр, и панель будет должным образом расположение. Кроме того, анимированные изменения могут быть сделаны с помощью прокси аниматора, такого как: [[аниматор accessoryView] setFrame:frame].

NSPathControl / NSPathCell

NSPathCell неправильно вызвал бы [openPanel setCanChooseDirectories:YES] когда собирающийся показать NSOpenPanel. На 10,6, это правильно установит значение в YES, только если allowedTypes содержит 'public.folder' или является нолем.

Для связанных приложений SnowLeopard NSPathCell правильно возвратит надлежащую высоту из - (NSSize) cellSizeForBounds: (NSRect) ограничивает для NSPathStyleStandard и NSPathStyleNavigationBar.

Когда свойство URL является файлом URL, NSPathComponentCell (и впоследствии NSPathCell и NSPathControl) больше не кодирует свойство изображения. Вместо этого это захватывает надлежащее изображение от NSWorkspace. Ранее, если бы файл не существовал, ранее, то изображения набора обнаружились бы. Теперь, надлежащие текущие изображения будут использоваться от файловой системы, и если файл в URL больше не будет существовать, то это покажет универсальное изображение. Необходимо повторно сохранить перья на SnowLeopard для нового кодирования для вступления в силу.

NSPathCell теперь должным образом выделит NSPathComponentCell, по которому щелкают по тому, когда показано контекстное меню. Установка Correctly меню может быть сделана одним из двух способов: установите - свойство меню для NSPathCell (или NSPathControl - это вперед setMenu: к ячейке). В делегате меню можно получить доступ к clickedPathComponentCell и обновить меню на основе ячейки, по которой щелкнули. В действии меню можно получить доступ к clickedPathComponentCell и обработать действие на основе элемента, по которому первоначально щелкнули. Также каждый NSPathComponentCell может иметь - набор свойства меню, и надлежащее меню будет возвращено из NSPathCell через-menuForEvent:inRect:ofView:. Подклассы NSPathControl, NSPathCell и NSPathComponentCell не должны переопределять-menuForEvent:/-menuForEvent:inRect:ofView: если они хотят выбрать в это поведение. Обратите внимание на то, что это поведение должно только использоваться на приложениях, предназначающихся для SnowLeopard или выше, поскольку это не будет работать должным образом над Leopard.

NSBrowser

NSBrowser теперь проходит через открытые методы-moveLeft: и-moveRight: при изменении столбцов в ответ на левую/правильную стрелку клавиатуры.

На связанных приложениях SnowLeopard,-scrollColumnToVisible: будет теперь всегда пытаться прокрутить запуск столбца к видимому rect. Ранее, если бы часть столбца была уже видима, это ничего не сделало бы.

На связанных приложениях SnowLeopard NSBrowser возвратит YES из-acceptsFirstResponder, если браузер не был установлен отказаться от первого состояния респондента с: - [браузер setRefusesFirstResponder:YES]. Ранее, это только приняло бы первое состояние респондента, если бы это имело по крайней мере один столбец, принявший первое состояние респондента. Это лишило возможности устанавливать NSBrowser как первого респондента в IB.

На связанных приложениях SnowLeopard NSBrowser правильно примет пустой индексный набор к selectRowIndexes:inColumn: позволить отмену выбора всех индексов в данном столбце. Ранее пустой индексный набор был бы проигнорирован.


NSBrowser - Контекстное меню

NSBrowser теперь должным образом поддерживает свойство меню. - [NSBrowser setMenu:] распространен к подпредставлениям матриц NSBrowser, где это необходимо, чтобы гарантировать, что меню доступно во всех расположениях. Настройка - [NSBrowser menuForEvent:] не будет иметь никакого эффекта, поскольку отдельные подпредставления обрабатывают меню. Если необходимо настроить меню, рассмотрите использование делегата NSMenu вместо этого.

В то время как контекстное меню выведено на экран, можно вызвать - [NSBrowser clickedRow] и - [NSBrowser clickedColumn] для определения, которым ячейка была под мышью, когда контекстное меню было выведено на экран. Если ни по какой ячейке не щелкнули, возвращаемое значение обеих этих функций будет-1.

NSBrowser - Удобные методы

В Leopard и более ранних выпусках, ширина столбца по умолчанию NSBrowser была установлена путем передачи индекса столбца-1 к - [NSBrowser setWidth:ofColumn:], и полученный путем передачи-1 к - [NSBrowser widthOfColumn:]. Существуют теперь первоклассные методы для доступа к этому свойству: - [NSBrowser setDefaultColumnWidth:] и - [NSBrowser defaultColumnWidth].

NSBrowser - Появление

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

При предназначении для отбрасывания во всем браузере путем установки столбца отбрасывания в-1, прямоугольник выделения будет нарисован вокруг всего управления.

NSApplication - Полный доступ клавиатуры

При реализации составных средств управления, таких как NSTableView, может быть полезно заставить текущее состояние полного доступа клавиатуры определять, каково поведение Вкладки управления должно быть. NSApplication теперь имеет-isFullKeyboardAccessEnabled метод, который возвратит текущее состояние того, чтобы сходить с системной предпочтительной области Клавиатуры.



Привязка и обрабатывающий уведомления KVO

NSBindingDebugLogLevel

Обязательный уровень журнала отладки теперь распознает значения, больше, чем 1. С пользовательским набором значения по умолчанию к 2, Привязка Какао зарегистрирует каждый раз, когда обрабатывается уведомление KVO. Результат похож:

    «Привязка какао: <YourBoundView: 0x101ed6930> связывающий 'isIndeterminate' обрабатывающее уведомление наблюдателя от объектного YourObservedObject 0x101ebed90 для keyPath your.observed.keyPath».


Java какао

Среда выполнения Java для запуска приложений Какао была удалена в SnowLeopard.


NSColorSpace

Этот новый метод возвращает список цветовых пространств, доступных в системе, которые выведены на экран цветной панелью в порядке, они выведены на экран в цветной панели. Не возвращает произвольные цветовые пространства, которые, возможно, были созданы на лету, или пробелы без пользователя визуализуемые имена. Модель передачи == NSUnknownColorSpaceModel для получения всех цветовых пространств. Если никакие цветовые пространства не доступны для указанной модели, пустой массив возвращается.
+ (NSArray *)availableColorSpacesWithModel;

NSColorSpace

Этот новый метод возвращает серое цветовое пространство с 2,2 гаммами. Это зеркально отражает kCGColorSpaceGenericGrayGamma2_2, добавленный в Кварце:
+ (NSColorSpace *)genericGamma22GrayColorSpace;

NSColor

NSColors будет теперь всегда должным образом сравнивать isEqual: (и возвратите тот же хеш) после архивации/разархивирования. Ранее в некоторых случаях (и чаще в 64-разрядном), цвет не сравнил бы isEqual: с его разархивированным дубликатом.

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


64-разрядное Преобразование

Существует теперь улучшенный инструмент для преобразования приложений Какао к 64-разрядному:

    /Developer/Extras/64BitConversion/ConvertCocoa64

Базовая функциональность очень подобна сценарию вершин, поставившему с Leopard; однако, это - сценарий Ruby, который выполнит вершины для Вас на указанных исходных файлах, и также очистит некоторые ненужные предупреждения, что вершины вставляют в Ваш код.

Использование этого (или некоторый специализированный вариант, подходящий для Ваших потребностей, или просто некоторого другого автоматизированного инструмента по Вашему выбору), настоятельно рекомендовано для преобразования объема первой передачи источников Какао к 64-разрядному. В нашем опыте один за другим ручные попытки преобразования могут привести к ошибкам, происходящим от скопировать/вставить или контроль, и автоматизированные преобразования избегают этих видов проблем.


NSApplication

- userInterfaceLayoutDirection является новым интерфейсом NSApplication, возвращающим направленность расположения по умолчанию потока интерфейса обычного пользователя для запущенного приложения. Метод возвращает NSUserInterfaceLayoutDirectionRightToLeft при выполнении с локализациями, такими как арабский или иврит, который должен иметь источник макета интерфейса пользователя на правом краю системы координат.


NSBezierPath

- cachesBezierPath и-setCachesBezierPath: методы, как теперь официально объявляют, осуждаются.


NSCell

NSCell теперь имеет-userInterfaceLayoutDirection и-setUserInterfaceLayoutDirection:. Это новое свойство описывает направленность расположения в ячейке. Для подклассов NSCell, имеющих многократные визуальные компоненты в экземпляре отдельной ячейки, это свойство должно указать направленность или поток компонентов.

Новый метод NSCell,-fieldEditorForView: теперь вызывается - [NSWindow fieldEditor:forObject:] метод, позволяющий NSCell, разделяет на подклассы для простого обеспечения пользовательского полевого редактора объект. Если-fieldEditorFoView: возвращает ненулевое значение, оно используется для редактирования объекта ячейки. Значение по умолчанию implmentation возвращает ноль.

Новое свойство NSCell,-usesSingleLineMode, определяет поведение расположения для текстовых ячеек. Когда-usesSingleLineMode == ДА, текстовая Система Какао вызывает к тексту в одной строке путем игнорирования строки/разделителей абзацев и обработки переносящихся режимов повреждения строки как режима отсечения. Полевой редактор объект, как ожидают, отфильтрует символы строки/разделителя абзацев, вводящие в значение ячейки от пользовательских действий. Кроме того, базовая позиция для текста становится фиксированной.


NSFontManager

-changeAttributes: сообщение действия теперь предназначено к [цель NSFontManager].


NSGraphicsContext

- focusStack и-setFocusStack: методы осуждаются.
Существует новый тип NSImageInterpolation, NSImageInterpolationMedium, добавленный.


NSProgressIndicator

- animationDelay,-setAnimationDelay: и - анимационный: методы осуждаются.


NSSearchFiedlCell

Все новые экземпляры NSSearchFieldCell используют однострочный режим. Экземпляры NSSearchFieldCell, разархивированные от файлов пера, создаваемых в пред10.6 системах с режимом разрыва строки отсечения, интерпретируются для использования однострочного режима.


NSSecureTextField

NSSecureTextField принимает ввод из различных источников неввода с клавиатуры, таких как Палитра символов.


NSRulerView

NSRulerView теперь маркеры расположения от права, когда присоединено к справа налево wirting стиль абзаца направления.


NSTextFieldCell

NSTextFieldCell теперь заполняет свой фон NSCompositeSourceOver вместо NSCompositeCopy.


NSTextInputClient

Существует новый дополнительный метод,-drawsVerticallyForCharacterAtIndex: это может сообщить системе Ввода текста, представляет ли протокол, приспосабливающий клиенту, символ в индексе вертикально.


NSTextInputContext

Новый класс NSTextInputContext представляет интерфейс системе Ввода текста Какао. Это представляет состояние или контекст, уникальный для его объекта клиента, такого как состояние привязки клавиш, сеанс связи метода ввода, и т.д. Каждый NSTextInputClient, совместимый объект (обычно подкласс NSView) переносит свой собственный экземпляр NSTextInputContext. Если подкласс представления соответствует протоколу NSTextInputClient, реализация по умолчанию - [NSView inputContext] управляет экземпляром автоматически.

Объект клиента должен взаимодействовать со своим NSTextInputContext для обработки вводов текста. Клиенты, как ожидают, отправят-handleEvent: сообщение для всего ключа/событий от нажатия мыши получено. - [NSView interpretKeyEvents:] метод отправляет сообщение за ключевыми событиями. Кроме того,-invalidateCharacterCoordinates должен быть, отправляют каждый раз, когда визуальное расположение клиентских изменений (т.е. изменения рамки окна, прокрутки представления, и т.д.).


Входные системные классы оригинального текста и протокол

Исходная система Ввода текста Какао, представленная в Mac OS X 10.0, теперь осуждается. NSInputServer заменяется платформой Набора Метода ввода. Функциональности NSInputManager интегрируются в класс NSTextInputContext. Протокол NSTextInput заменяется протоколом NSTextInputClient, представленным в Mac OS X 10,5 Leopard.

Отображения для осуждаемых методов NSInputManager:
+cycleToNextInputLanguage: и +cycleToNextInputServerInLanguage: покрыты более прямым входным источником APIs, такой как selectedKeyboardInputSource свойство.
- markedTextAbandoned: заменяется-discardMarkedText
- handleMouseEvent: заменяется-handleEvent:.

- markedTextSelectionChanged:client:-wantsToInterpretAllKeystrokes,-wantsToHandleMouseEvents, и-wantsToDelayTextChangeNotifications больше не необходимы.


NSTextTab

Позиции табуляции NSDecimalTabStopType возвращают NSNaturalTextAlignment из - выравнивание для приложений, соединенных против библиотек Mac OS X 10.6 SnowLeopard. Это позволяет корректному расположению десятичной табуляции войти справа налево стиль абзаца. Приложения могут указать NSDecimalTabUsesNaturalAlignment == использование YES NSUserDefaults для принуждения нового поведения.


NSTokenField

Поведение для обработки пробельных символов, таких как пространство, вкладка, и т.д. между маркерами и маркированием символов изменило в Mac OS X 10,5 Leopard. В 10,4, те символы были тихо обрезаны перед маркированием. С 10,5, те символы оставляют нетронутыми и включенными в маркеры. Если пробельное поведение обрезки желательно, делегат мог бы реализовать-tokenField:representedObjectForEditingString: и выполните обрезку в методе.
Для сохранения совместимости на уровне двоичных кодов с Тайгером первый пост-Leopard, AppKit теперь выполняет обрезку если-tokenField:representedObjectForEditingString: реализован его делегатом, или двоичный файл соединяется против выпусков перед Leopard.



Отмечает определенный для Mac OS X 10.5

Новые функции и существенные изменения в AppKit





64-разрядный

Leopard содержит 64-разрядные версии многих системных платформ, включая создание и выполнение многих приложений Какао как 64-разрядные. Существуют некоторые изменения API в Какао для размещения этого. Большинство вследствие введения двух новых типов, NSInteger и NSUInteger, как способ представлять целые числа «размера адреса» и на 32 и на 64-разрядный. NSInteger определяется как «интервал» на 32-разрядном и «длинное» на 64-разрядном, и NSUInteger является своим дубликатом без знака. Почти весь Основанный на какао APIs был обновлен для использования NSInteger или NSUInteger вместо международного или интервала без знака. NSInteger походит на тип CFIndex CoreFoundation.

(Обратите внимание на то, что рано в Leopard, NSInteger и NSUInteger назвали NSInt и NSUInt, соответственно. Эти старые названия были удалены перед заключительным выпуском Leopard.)

Продвижение, приложения должны использовать эти новые типы (и CGFloat - видят ниже) вместо интервала, интервала без знака и плавания, так как это сделает возможное перемещение к 64-разрядному намного проще. Мы рекомендуем это даже для приложений, которые должны работать на Тайгере; они могут выполнить это со своими собственными, определениями Только для тигра этих типов.

У нас есть сценарий преобразования в/Developer/Extras/64BitConversion, чтобы помочь преобразовать приложения Какао в 64-разрядный. Информация об этом сценарии и Какао 64-разрядное усилие в целом может быть найдена в 64-разрядном Руководстве по Переходу для Какао.

В целом должно быть возможно использовать ту же исходную основу и для 32 и для 64-разрядных версий приложения или платформы. Выполнение этого сценария на Вашей исходной основе для преобразования источников в 64-разрядный должно все еще позволить им создать и работать правильно под 32-разрядным. В случае необходимости можно сделать:
#if __LP64__
...
#endif
как способ сделать 64-разрядный определенный код.


В APIs, где термин «интервал» появился как часть имени метода (например, «intValue»), термин «целое число» используется для представления этого нового типа NSInteger, в то время как «интервал» продолжает относиться к собственному международному типу (который является 32-разрядным и под 32 и под 64). Таким образом методы как intValue, numberWithInt: scanInt: и т.д. продолжайте брать или возвращать ints, в то время как методы, такие как integerForKey: в NSUserDefaults были изменены для взятия NSInteger. Мы добавляем много методов дубликата в Основе и AppKit, берущих или возвращающих параметры NSInteger или NSUInteger.

Новые методы в Основе:

NSCoder:
 - (void)encodeInteger:(NSInteger)intv forKey:(NSString *)key;
- (NSInteger)decodeIntegerForKey:(NSString *)key;
NSString:
 - (NSInteger)integerValue;
NSScanner:
 - (BOOL)scanInteger:(NSInteger *)ptr;
NSNumber:
 - (NSInteger)integerValue;
- (NSUInteger)unsignedIntegerValue;
- (id)initWithInteger:(NSInteger)value;
- (id)initWithUnsignedInteger:(NSUInteger)value;
+ (NSNumber *)numberWithInteger:(NSInteger)value;
+ (NSNumber *)numberWithUnsignedInteger:(NSUInteger)value;
Для AppKit это означает следующие новые методы и в NSCell и в NSControl:
- (NSInteger)integerValue;
- (void)setIntegerValue:(NSInteger)val;
- (void)takeIntegerValueFrom:(id)sender;
У нас также есть следующие новые константы в NSObjCRuntime.h:
 #define NSIntegerMax   LONG_MAX
#define NSIntegerMin LONG_MIN
#define NSUIntegerMax ULONG_MAX

Обратите внимание на то, что проектом, обработка включенной архивации целочисленных типов не строга. Целочисленное количество, записанное с любым из encodeInteger:forKey: encodeInt32:forKey: или encodeInt64:forKey: может быть считан назад с помощью любого из целочисленных методов декодирования. Если значение является слишком большим для чтения использования указанного метода декодирования, исключение повышено.

Для большинства интегральных значений мы рекомендуем использование encodeInteger:forKey: и decodeIntegerForKey:. Для значений, диапазоны которых больше, чем, что 32-разрядные целые числа со знаком могут содержать, Int64: варианты продолжают быть более надлежащим выбором, даже на 32-разрядном.

Существует дополнительная архивация и другие соображения в присутствии 64-разрядных изменений в нашем APIs. 64-разрядное вышеуказанное Руководство по Переходу имеет больше информации об этой теме и больше.


CGFloat

Другое существенное изменение в Какао APIs является введением типа CGFloat в Кварце. Это заменяет использование плавания и определяется как дважды для 64-разрядного. Обратите внимание на то, что это не изменение, продиктованное 64-разрядным перемещением; однако, мы используем в своих интересах перемещение для представления этого нового типа. Цель CGFloat состоит в том, чтобы обеспечить более высокую точность и диапазон в графических значениях для 64-разрядных приложений. Этот тип заменяет использование всех графических типов плавающих в Какао APIs, включая тех в NSGeometry.h Основы.

Другое изменение в NSGeometry.h является redeclaration NSRect, NSPoint и NSSize использование Кварцевых дубликатов, CGRect, CGPoint и CGSize. К сожалению, вследствие соображений совместимости на уровне двоичных кодов, это изменение сделано для 64-разрядного только. Обратите внимание на то, что подписи типа Objective C этих типов таким образом расходятся в 64-разрядном от этого на 32 битах.


Перечислимое удаление имени

Как часть 64-разрядной очистки, мы добавили явно измеренные типы, где мы ранее использовали перечисления. Например, мы пошли от:
typedef enum NSAlertStyle {
NSWarningAlertStyle = 0,
NSInformationalAlertStyle = 1,
NSCriticalAlertStyle = 2
} NSAlertStyle;
к
enum {
NSWarningAlertStyle = 0,
NSInformationalAlertStyle = 1,
NSCriticalAlertStyle = 2
};
typedef NSUInteger NSAlertStyle;
Последний удостоверяется, что NSAlertStyle остается фиксированным размером и со знаком независимо от того, как изменяется перечислимое содержание.

В выполнении этого мы удалили перечислимые имена из перечислимых объявлений, таким образом, любая попытка использовать «перечислимый NSAlertStyle» теперь перестанет работать. Переключитесь на использование определения типа вместо этого, которое является фиксированным размером.

NSOpenGL и 64-разрядный

Объявления AppKit API в NSOpenGL.h были изменены для использования стандартных типов OpenGL (Вспышка, GLsizei, GLenum, и Глбитфилд) вместо явного «интервала» C и «длинных» типов, чтобы помочь упростить переход к 64-разрядному. Эффективные размеры и со знаком из параметров и возвращаемых значений остаются тем же как прежде для 32-разрядной разработки.

APIs удален в 64-разрядном AppKit

Много классов были удалены в 64-разрядной версии AppKit:

- NSMenuView - можно использовать настройки NSView на NSMenuItem
- NSMovieView - используют QTKit
- NSMovie - Доступный с очень ограниченной функциональностью (см. здесь); используйте QTKit
- NSQuickDrawView - QuickDraw не поддерживается в 64-разрядном
- NSSimpleHorizontalTypesetter - Осуждаемый некоторое время теперь, используйте новые средства NSTypesetter

Кроме того, много ранее осуждаемых отдельных APIs были также удалены из 64-разрядного AppKit, включая связанные символы PostScript старого Дисплея, экспортируемые исключительно для совместимости на уровне двоичных кодов под 32-разрядным.


Objective C 2.0

Leopard включает Objective C 2.0, который приносит много новых функций к языку и время выполнения: Быстрое перечисление, сборка «мусора», расширения класса, свойства, метод и атрибуты класса и дополнительные методы на протоколах.

Существует много дополнительных функций во время выполнения, доступных в 64-разрядном только: Более строгое управление доступом на частных переменных экземпляра и классах, «нехрупких» переменных экземпляра и C++ совместимые, «стоившие нулем» исключения (которые являются очень дешевыми для установки, но дорогой для броска).

 Важно отметить, что все эти функции только для Leopard. См. Objective C 2,0 документации для полного изложения на этих функциях.

Обратите внимание на то, что многие Objective C APIs в Leopard еще не приняли эти функции. Но в будущих выпусках, Вы, вероятно, будете видеть:

- @property раньше объявлял свойства
- Объявления делегата переключились из неофициальных протоколов (категории на NSObject) к формальным протоколам с дополнительными методами
- Увеличенная ограниченная видимость частных символов во время выполнения

Последняя точка особенно важна, так как она предотвратила бы приложения с помощью этих символов от запуска в будущих выпусках. Как всегда: не получайте доступ к необъявленному APIs в своих приложениях. Это включает необъявленные классы, методы и переменные экземпляра. Если Вы имеете сильную необходимость в частном API и не имеете никакого обходного решения, сообщите нам.


Соедините интерфейсом с разработчиком 3.0

Инструменты разработчика Leopard включают новую версию Interface Builder (IB). IB 3.0 имеет перепроектированный интерфейс, много улучшенной интеграции с XCode и возможности получить доступ еще к многим функциям AppKit в Ваших файлах пера, чем прежде.

IB 3.0 поддерживает три форматов файлов. 2.x формат файла является тем же форматом файла, это использовалось в Интерфейсном Разработчике ранее. Это может быть отредактировано IB 2.0 и развертываемо на более ранних версиях Mac OS X. 2.x формат файла не поддерживает некоторые новые функции IB, такие как возможность отредактировать пользовательские подклассы ячейки и панели инструментов. 3.x формат файла поддерживает все новые функции, также развертываем на более ранних версиях Mac OS X, но может только быть отредактирован с IB 3.0. IB 3.0 также поддерживает текстовый, человекочитаемый формат, названный форматом «xib». Этот формат эквивалентен 3.x формат, но это является Более SCM-дружественным. Это компилируется вниз в 3.x файл во время изготовления.

Для того, чтобы отредактировать и разработать Ваш проект на Leopard только, мы рекомендуем формат xib, так как это обеспечивает лучший опыт времени разработки. Если необходимо разработать проект на Тайгере, но отредактировать перья на Leopard только, то можно использовать 3.x формат. Наконец, если Вы хотите быть в состоянии продолжать редактировать Ваши файлы пера на Тайгере, можно придерживаться 2.x формат. Во всех этих случаях файлы могут быть развернуты на Тайгере, но некоторые функции, поддерживавшие IB 3.0, могут не работать над более ранними системами. IB имеет средства для предупреждения Вас в тех случаях.


Базовый рендеринг дерева слоя анимации

Leopard AppKit обеспечивает средние значения для рендеринга Базового дерева Слоя анимации в границах любого данного NSView. Клиенты должны только обеспечить корневой CALayer дерева уровня, которое будет выведено на экран, затем включит дерево уровня, представляющее для того же представления:
    [view setLayer:rootLayer];
    [view setWantsLayer:YES];
AppKit отвечает путем установки Базового средства рендеринга Анимации, анимирующего и составляющего дерево уровня на фоновом потоке.

Базовое средство рендеринга Анимации продолжает свою асинхронную работу, пока рендеринг дерева уровня не отключен для представления (через setWantsLayer: сообщение с параметром НЕ), или представление скрыт или удален из окна. Вывод на экран представления или добавление представления, имеющего wantsLayer, включили к окну, рендерингу дерева уровня резюме.

Для сохранения системных ресурсов AppKit также приостанавливает дерево уровня, представляющее за представления в данном окне, когда окну приказывают уйти, и для всех представлений в процессе, когда сеанс входа в систему пользователя выключается через функцию «Fast User Switching». В таких случаях дерево уровня, представляющее автоматически, возобновляет, когда окно упорядочивается, въезжают задним ходом, или когда сеанс входа в систему пользователя переключается, въезжают задним ходом, как надлежащий.

См. документацию для новой Базовой Анимации платформы QuartzCore API для получения дополнительной информации о создании дерева уровня, возможностях и использовании.

Новые средства анимации представления и поддержанное уровнем получение представления

В дополнение к поддержке рендеринга определяемых пользователем Базовых деревьев Слоя анимации Leopard AppKit принимает парадигмы API, подобные Базовой Анимации, чтобы позволить клиентам запрашивать анимацию представления и свойств окна, и также добавляет новый «поддержанный уровнем» режим для рендеринга и анимации деревьев представления. Использование поддержанного уровнем режима не требуется, чтобы использовать новый находящийся в CAAnimation API AppKit, но действительно включает использование дополнительных новых визуальных обработок для представлений (на представление полная альфа, тени и возможность применить Базовые фильтры Изображения к представленному содержанию), и ускоряет анимацию неизменения размеров представлений на цену кэширования их представленного содержания в CALayers на представление.

В рендеринге традиционного взгляда дерево представления окна нарисовано наоборот в запоминающее устройство окна. Нарисованное содержание представления таким образом предварительно составляется в единственное запоминающее устройство таким способом, которым обновление любой данной части окна требует перерисовки затронутых частей всех представлений, способствующих результату. В новом «поддержанном уровнем» режиме рисования представления, теперь поддерживающемся в Leopard, каждому из представлений в поддержанном уровнем поддереве представления нарисовали его содержание к его собственному уровню в AppKit создаваемое и управляемое дерево CALayer. Это переносит дополнительную стоимость памяти, порядка (4 * пиксели, широкие * пиксели высоко) байты на представление, которое должно быть взвешено при рассмотрении, ли и где использовать поддержанный уровнем режим в пользовательском интерфейсе приложения, но в ответ это позволяет уже представленному содержанию представления быть перемещенным более эффективно во время анимаций, так как, содержание только должно быть re-compositied вместо того, чтобы быть повторно представленным с нуля.

Большинство стандартных представлений и средств управления, которые обеспечивают AppKit и другие платформы Какао Mac OS X, в состоянии функционировать в поддержанном уровнем режиме в Leopard, за исключением определенных специализированных представлений, таких как WebKit WebViews и Кварцевый Композитор Кквивс, использование которого в поддержанном уровнем режиме в настоящее время не поддерживается.

Пределы размера уровня и плиточные слои

Одно свойственное ограничение рендеринга содержания представления в Базовый Слой анимации - то, что размер обычного CALayers ограничивается максимальным размером текстуры OpenGL, поддерживаемым аппаратным обеспечением машинной графики хост-системы. На самом актуальном аппаратном обеспечении машинной графики эффективный предел составляет 2046x2046 пикселей, вне которых перестанет работать создание уровня размера. Заботу нужно поэтому соблюдать, чтобы обеспечить, чтобы поддержанные уровнем представления не превышали этот предел размера.

Для обхождения этого ограничения для потенциально больших представлений документа AppKit нанимает CATiledLayers для служения в качестве отступающих уровней для представлений документа NSScrollViews. Этот специализированный тип слоя кэширует свое содержание в сетке «мозаик» (размера по умолчанию 256x256 пикселей), которые нарисованы, поскольку они становятся видимыми, и могут быть собраны «мусор», когда они выходят из представления. С точки зрения пользователя мозаики добавляются асинхронно, поскольку они показаны во время прокрутки. Визуальное появление дополнения мозаики может быть минимизировано путем включения «drawsBackground» свойства для включения NSScrollView (или, эквивалентно, его NSClipView), и выбор цвета фона, наиболее близко соответствующего нарисованное содержание представления документа.

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

Используя поддержанные уровнем представления

Руководство по быстрому началу работы для начала экспериментировать с этой функциональностью:

1. Выберите представление, которое будет служить корневым представлением для Базового Основанного на анимации рендеринга представления, и включать Базовый Основанный на анимации рендеринг для того представления (и неявно его потомки) путем выполнения [theRootView setWantsLayer:YES];

2. Свойства представлений и окон, для которых поддерживается автоанимация, могут быть анимированы путем обмена сообщениями через целевой объект (представление или окно) прокси «аниматора»:
    [[someDescendantOfTheRootView animator] setFrame:newFrame];
Для указания продолжительности вместо глобального значения по умолчанию 0,25 секунд включите такие сообщения в NSAnimationContext, указывающий продолжительность для анимации:
    [NSAnimationContext beginGrouping];
    [[NSAnimationContext currentContext] setDuration:0.25];
    [[someDescendantOfTheRootView animator] setFrame:newFrame];
    [NSAnimationContext endGrouping];
Основные параметры анимации по умолчанию предоставлены для следующих свойств NSView и NSWindow, таких, что они анимируют автоматически, когда присвоено новое целевое значение через представление или аниматора окна:

для NSView: alphaValue, кадр, frameOrigin, frameSize, frameRotation, frameCenterRotation, границы, boundsOrigin, boundsSize, backgroundFilters, contentFilters, compositingFilter, тень

для NSWindow: alphaValue, кадр

Некоторые дальнейшие примечания относительно новой анимации и визуальных дополнений свойства к NSView следуют в «NSAnimationContext», «новые свойства NSView», и «дополнения NSAnimation» разделяют.

NSAnimationContext

NSAnimationContext является новым классом в Leopard. NSAnimationContexts походят на CATransactions Базовой Анимации и также несколько подобны в полном понятии NSGraphicsContexts. Каждый поток поддерживает свой собственный штабель экземпляров nestable NSAnimationContext, с каждым новым экземпляром, инициализированным как копия экземпляра ниже его (так, наследовав его текущие свойства). В настоящее время NSAnimationContext существует в единственной цели содержать продолжительность по умолчанию, которая будет использоваться для «аниматора» - инициируемые в прокси анимации.

Каждый поток запускается с текущего NSAnimationContext, чья продолжительность по умолчанию составляет 0,25 секунды (то же значение по умолчанию, используемое Базовой Анимацией), означая, что операции набора значений для animatable свойств объектов, проходящих через прокси «аниматора», анимируют с той продолжительностью по умолчанию. Для анимации с различной продолжительностью раздел кода начал бы новый NSAnimationContext с желаемой продолжительности, выполнил бы желаемые операции набора значений через прокси «аниматора» или прокси, затем закрыл бы контекст, когда сделано:
    [NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:1.0]; // Animate enclosed operations with a duration of 1 sec
[[aView animator] setFrame:newFrame];
[NSAnimationContext endGrouping];
NSAnimationContexts может быть вложен, позволив данному блоку кода инициировать анимации с помощью его собственной указанной продолжительности, не влияя на анимации, инициируемые путем окружения кода.
    [NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:1.0]; // Animate enclosed operations with a duration of 1 sec
[[aView animator] setFrame:newFrame];
...
[NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:0.5]; // Animate alpha fades with half-second duration
[[aView animator] setAlphaValue:0.75];
[[bView animator] setAlphaValue:0.75];
[NSAnimationContext endGrouping];
...
[[bView animator] setFrame:secondFrame]; // Will animate with a duration of 1 sec
[NSAnimationContext endGrouping];
Так как прокси «аниматора» может быть передан для кодирования, который ожидает обычный объект вида цели прокси (в настоящее время, NSView или NSWindow), это могло бы при редких обстоятельствах быть необходимым подавить анимацию для кода, явно не проходящего через объекты прокси «аниматора». Это может быть выполнено с помощью контекста анимации с продолжительностью нуля:
    [NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:0.0]; // Makes value-set operations take effect immediately
[aViewOrMaybeAnAnimator setFrame:newFrame];
[NSAnimationContext endGrouping];

Новые свойства NSView

Leopard AppKit добавляет некоторые новые свойства к NSViews, описанным ниже с их соответствующими методами доступа.
- (void)setWantsLayer:(BOOL)flag;
- (BOOL)wantsLayer;
«WantsLayer» свойство определяет, должны ли представление и его потомки быть составлены и анимировали использование Базового дерева Слоя анимации, включение использования усовершенствованной анимации и составления композита эффектов. Значения по умолчанию к НЕТ. Установка этого свойства к YES для представления rootmost, для которого желаемо Базовое Основанное на анимации составление композита, является всем, что это необходимо для активации Базовой Основанной на анимации буферизации представления, составления композита и анимации для данного поддерева представления. Поддерево представления, как тогда говорят, «поддерживается уровнем», так как каждое мнение высказано соответствующий Базовый Слой анимации, служащий его запоминающим устройством.
- (CALayer *)layer;
Если представление поддерживается уровнем, - метод уровня возвращает соответствующий AppKit представления создаваемый и управляемый CALayer. Вызывающие стороны могут использовать возвращенный указатель для обмена сообщениями уровня непосредственно, как средние значения получения доступ к функциям, не реэкспортированным как свойства NSView. Может возвратить ноль для представления, это в настоящее время отмечается, как размещено уровнем, если AppKit еще не вывел на экран представление впервые и таким образом создал уровень представления. Для самого обычного использования анимации кадров и содержания представлений и применения эффектов, осведомленности об и прямого доступа к нижележащим слоям представлений вряд ли будет необходим, поскольку AppKit будет в состоянии управлять ими автоматически.
- (void)setLayer:(CALayer *)newLayer;
-setLayer: метод устанавливает данный CALayer, чтобы быть уровнем поддержки представления. Это заставляет представление отделять от его ранее присвоенного уровня (если таковые имеются), удаляя тот уровень из его окружающего дерева уровня и выпуская ссылку представления на уровень. Новый уровень берет позицию старого уровня в дереве уровня (или просто добавляется к дереву уровня в надлежащем месте, если это не заменяет существующий слой). Представление сохраняет свой уровень, но AppKit поддерживает только слабую ссылку от уровня назад к представлению. Этот метод управляет обеими ассоциациями.

- setLayer: публикуется для обеспечения использования, где у разработчика есть произвольное дерево уровня, это не связывается к поддереву представления и автоматически не управляется AppKit и хочет представить это в представлении (см., «что Базовое Дерево Слоя анимации Представляет»).
- (void)setAlphaValue:(CGFloat)viewAlpha;
- (CGFloat)alphaValue;
Устанавливает полное значение непрозрачности, с которым представление и его потомки составляются в их суперпредставление (аналогичный alphaValue окна). Значения по умолчанию к 1,0. Эта установка может варьироваться независимо от возвращаемого значения класса для-isOpaque, и реализация последнего не должна принимать alphaValue представления во внимание, так как AppKit консультируется с обоими значениями при необходимости. alphaValue представления будет влиять и на Базовое составление композита Основанного на анимации и традиционного взгляда.
- (NSShadow *)shadow;
- (void)setShadow:(NSShadow *)shadow;
Устанавливает дополнительную тень, которая будет нарисована позади поддерева представления. Значения по умолчанию к нолю. Эта установка только имеет эффект для Базового Основанного на анимации составления композита представления. Обратите внимание на то, что, несмотря на то, что теневая модель Базовой Анимации использует те же параметры в качестве Кварцевой тени, представленные результаты могут отличаться от тех достигнутый Кварцевый рендеринг тени использования. NSShadow используется здесь просто в качестве надлежащей инкапсуляции Какао для идентичного набора теневых параметров.


Следующие три пары методов доступа могут использоваться для применения произвольных Базовых эффектов фильтра Изображения для представлений, поддерживающихся CALayers. Как указано Базовой Анимацией, концептуальная модель, используемая, чтобы применить операции фильтра и объединить их результаты:
   maskop(mask, compositeop(layerop(layer), backgroundop(background)), background)
- (CIFilter *)compositingFilter;
- (void)setCompositingFilter:(CIFilter *)filter;
Устанавливает CIFilter, который будет использоваться для составления композита поддерева представления по (возможно отфильтрованный) фон. Значения по умолчанию к нолю, подразумевающему, что должен использоваться источник - по составлению композита. Эта установка только имеет эффект для Базового Основанного на анимации составления композита представления.
- (NSArray *)contentFilters;
- (void)setContentFilters:(NSArray *)filters;
Позволяет содержанию представления проникнуться дополнительная цепочка CIFilters прежде чем быть составленным в место назначения рендеринга. Предоставленный массив фильтров не должен быть подключен к друг другу, как они будут соединены последовательно автоматически Базовой Анимацией. Значения по умолчанию к нолю. Эта установка только имеет эффект для Базового Основанного на анимации составления композита представления.
- (NSArray *)backgroundFilters;
- (void)setBackgroundFilters:(NSArray *)filters;
Позволяет фону позади поддерева представления проникнуться дополнительная цепочка CIFilters, прежде чем поддерево представления будет составлено в него. Предоставленный массив фильтров не должен быть подключен к друг другу, как они будут соединены последовательно автоматически Базовой Анимацией. Значения по умолчанию к нолю. Эта установка только имеет эффект для Базового Основанного на анимации составления композита представления.

Поддержанные уровнем представления и внеполосное получение

Для обычного случая представлений, вовлеченных совместно используемое запоминающее устройство окна, исторически было возможно вовлечь область окна, которую представление занимает по желанию, путем блокировки внимания на представление, получение и разблокирование фокуса:
    [view lockFocus];
/* Perform some drawing. */
[view unlockFocus];
Это иногда использовалось для замены некоторого анимированного контента в ответ на обратный вызов таймера, например.

Вследствие по сути различной семантики буферизации для дерева уровня основанный рендеринг этот метод не может использоваться поддержанными уровнем представлениями. Вместо этого необходимо выполнить все необходимое получение в-drawRect: и использование-setNeedsDisplay: и/или-setNeedsDisplayInRect: запрашивать обновления по мере необходимости. Это обычно - предпочтительный метод так или иначе, так как он избегает потенциальных несоответствий с - находящееся в drawRect: получение, позволяет другим представлениям вносить потенциально необходимое содержание в затронутую область окна и позволяет AppKit объединить обновления для большей эффективности.

Предотвращение проблем синхронизации с поддержанными уровнем анимациями представления

Когда представление изменено, содержание, которое оно рисует, может ответить потенциально произвольными способами. Поэтому прокси «аниматора» AppKit основанная анимация API просит, чтобы представления изменения размеров перерисовали свое содержание на каждом шаге по пути, обеспечили корректные результаты.

Когда используется с поддержанными уровнем представлениями, это может привести к проблемам синхронизации, где единственное представление, может казаться, «дрожит», когда его frameOrigin и frameSize одновременно анимированы, или где разрывы между смежными представлениями анимации колеблются, потому что перемещение frameOrigin каждого представления анимируется на фоновом потоке Базовой Анимацией. Такие проблемы синхронизации могут быть исправлены путем обеспечения, чтобы покадровые анимации представления инициировались с помощью-setFrame: обменивайтесь сообщениями аниматору каждого представления, вместо того, чтобы пройти через-setFrameOrigin: и/или-setFrameSize: отдельно. Это выдает AppKit для анимации и frameOrigin и frameSize, изменяет себя, так, чтобы результаты остались в синхронизации в течение анимации.

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

Поддержанная уровнем оптимизация NSImageView

Для сложных представлений, анимаций, заставляющих тип телосложения часто изменять результат в субоптимальной производительности анимации. Когда размер представления изменяется, он должен перерисованный для каждого кадра анимации, часто понижающей framerates. NSImageView является хорошим примером этого, начиная с рендеринга изображений может быть дорогим. NSImageView был оптимизирован в определенных случаях для изменения размеров анимаций. Следующее является рядом условий, которым нужно удовлетворить для оптимизации для вступления в силу:

• Представление изображения должно быть недоступным для редактирования и иметь стиль рамок NSImageFrameNone.
• Представление изображения должно содержать стандартный NSImageCell AppKit и drawRect представления: метод не должен быть переопределен.
• Представление должно быть поддержано уровнем и должно использовать уровень, который AppKit создает для него (значение, что Вы не можете предоставить своему собственному уровню-setLayer:).
• «Лучшая» репутация изображения (согласно-bestRepresentationForDevice:), поскольку изображением представления должен быть NSBitmapImageRep, NSCachedImageRep, NSPICTImageRep или NSCGImageRep.
• imageScaling представления должен быть NSImageScaleProportionallyUpOrDown с imageAlignment в центре или NSImageScaleAxesIndependently или NSNSImageScaleNone с любым imageAlignment. Обратите внимание на то, что значением по умолчанию imageScaling является NSImageScaleProportionallyDown, не позволяющий оптимизации вступать в силу.

Смещение «needsDisplay» прямоугольники в представлении

Следующий метод позволяет сместиться грязного rects представления получения в единственной работе. Эффект этого метода состоит в том, чтобы получить все грязные прямоугольники представления получения, очистить все грязные прямоугольники в intresection указанного clipRect и границ представления, сместить полученные прямоугольники на данные смещения «дельты», отсечь результат к пересечению clipRect и границ представления, и добавить результирующие прямоугольники назад к представлению.
- (void)translateRectsNeedingDisplayInRect:(NSRect)clipRect by:(NSSize)delta;
Этот метод должен редко быть необходим, но может быть полезен для клиентов, реализующих их собственную логику копии на прокрутке.

Пиксельное выравнивание и преобразовывающий координаты представления к и от «основного» пространства

В Leopard NSView обеспечивает новый набор методов, которые должны использоваться при выполнении пиксельного выравнивания содержания представления. Они обеспечивают средние значения для преобразования геометрии к и от «основного» координатного пространства, выравнивающегося пикселем с запоминающим устройством, в которое рисуется представление:
- (NSRect)convertRectToBase:(NSRect)aRect;
- (NSPoint)convertPointToBase:(NSPoint)aPoint;
- (NSSize)convertSizeToBase:(NSSize)aSize;
- (NSRect)convertRectFromBase:(NSRect)aRect;
- (NSPoint)convertPointFromBase:(NSPoint)aPoint;
- (NSSize)convertSizeFromBase:(NSSize)aSize;
Для рендеринга традиционного взгляда, в котором иерархия представления нарисована сглаженная в запоминающее устройство окна, это «основное» пространство совпадает с системой координат окна, и результаты использования этих новых методов совпадают с геометрией преобразования к и от представления «ноль» с помощью существующего - тайный [Rect/Point/Size]: Просмотреть: методы.

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

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

При использовании поддержанных уровнем представлений в масштабном коэффициенте пользовательского интерфейса кроме 1,0, обратите внимание на то, что размерности представления и размерности его соответствующего уровня поддержки будут варьироваться согласно масштабному коэффициенту, так как границы CALayer всегда выражаются в пикселях, в то время как размерности NSView остаются выраженными в точках. У большинства клиентов поддержанных уровнем представлений не будет потребности выполнить операции непосредственно в пространстве уровня, но для тех, которые делают важно использовать предыдущие методы для преобразования геометрических количеств между пространством представления и уровнем («основное») пространство в надлежащих случаях.

Ответ на сокрытие/Вывод на экран представления

Сокрытие или вывод на экран высказанного мнения с помощью-setHidden: API влияет на эффективную видимость всех ее порожденных представлений. Leopard добавляет два новых метода NSView, которые клиенты могут переопределить при желании для имения их пользовательских классов представления, реагируют на становление эффективно скрытый или нескрытый vis-à-vis-setHidden: API:
- (void)viewDidHide;
- (void)viewDidUnhide;
Когда его «isHiddenOrHasHiddenAncestor» состояние пойдет от НЕ до YES, представление получит сообщение «viewDidHide». Это может произойти, когда представление или наследователь отмечены, как скрытый, или когда представление или наследователь соединены в новую иерархию представления.)

Когда его «isHiddenOrHasHiddenAncestor» состояние пойдет от YES до НЕТ, представление получит сообщение «viewDidUnhide». (Это может произойти, когда представление или наследователь отмечены как не скрытый, или когда представление или наследователь удалены из его содержания иерархии представления.)

Выполнение нарисованного непосредственно перед тем, как просматривает действие

NSView имеет новый метод «-viewWillDraw» API в 10,5, который может быть переопределен для выполнения любого действия на последней минуте, которое могло бы быть желаемо в начале иерархии представления «-дисплей...» работа.
- (void)viewWillDraw;
Чаще всего действие, которое будет выполняться в это время, состоит из некоторой комбинации расположения представления (присваивающий новые типы телосложения и/или позиции к представлениям) и отмечающий дополнительные области представления как нуждающийся в дисплее (обычно как результат выполнения расположения содержания непредставления, такие как текстовые глифы, графика или веб-контент). Желаемый эффект состоит в том, чтобы выполнить такие вычисления по требованию, задержанный, пока их результаты не собираются фактически быть необходимыми, допуская тот же вид обновления, объединяющего выигрыши в производительности, которые мы получаем с самим задержанным механизмом дисплея, вместо того, чтобы вынудить расположение содержания быть выполненным сразу, когда содержание установлено или задержано до последующей передачи получения.

В начале рекурсивного дисплея части или всей иерархии представления, всегда инициирующейся одной из восьми общественности NSVIEW «-дисплей...» методы, AppKit рекурсивно вызывает вниз иерархию представления, отправляя сообщение-viewWillDraw в каждое из представлений, которые могут быть вовлечены в работу дисплея.

Реализация по умолчанию NSVIEW этого метода является самостоятельно механизмом для рекурсии и позволяет сверхнаездникам, которых рекурсивно вызывает гибкость для заголовка - или хвост - рекурсивно вызывают как лучшие иски потребности операций, которые они должны выполнить. Концептуально, реализация NSVIEW похожа:
@implementation NSView
- (void)viewWillDraw {
    if (any descendant of self overrides "-viewWillDraw") {
        for (each subview that intersects the window area being drawn in back-to-front order) {
            [subview viewWillDraw];
        }
    }
}
@end
Таким образом, переопределение этого метода могло сделать:
- (void)viewWillDraw {
    /* Perform some operations before recursing for descendants. */
    /* Now recurse to handle all our descendants. Overrides must call up to super like this. */
    [super viewWillDraw];
    /* Perform some operations that might depend on descendants already having had a chance to update. */
}
Во время рекурсии-viewWillDraw, отправки-setNeedsDisplay: и-setNeedsDisplayInRect: сообщения к представлениям в иерархии, это собирается быть нарисованным, допустимы и поддерживаются и будут влиять на оценку AppKit общей площади, которая будет представлена в той передаче получения.

При желании реализация-viewWillDraw может использовать существующий-getRectsBeingDrawn:count NSVIEW: метод для получения списка прямоугольников, связавших зону поражения, позволив ему ограничить ее усилия той областью.

Установка подпредставлений представления

NSView имеет новый-setSubviews: метод API в 10,5, который может использоваться для переупорядочения подпредставлений представления, удалите существующие подпредставления и/или добавьте новые подпредставления все через единственную точку входа API:
- (void)setSubviews:(NSArray *)newSubviews;
С этим отдельным методом каждый может:
- переупорядочьте существующие подпредставления получателя
- добавьте или удалите подпредставления из получателя
- потенциально замените все предыдущие подпредставления получателя с совершенно новым набором представлений
- потенциально удалите все предыдущие подпредставления получателя, оставляя его ни с одним (думайте» [aView setSubviews: [Массив NSArray]]»)

Представления в массиве «newSubviews» могут любой комбинацией существующих подпредставлений получателя, подпредставлений других представлений или представлений, в настоящее время не имеющих никакого суперпредставления. Если «newSubviews» является нолем или содержит какие-либо двойные записи,-setSubviews: выдает исключение недействительного аргумента. (До семени Leopard 2007 года WWDC,-setSubviews: если бы какое-либо из новых подпредставлений уже было подпредставлением некоторого представления, также повысил бы исключение. Это теперь позволяется, и просто приводит к представлениям, удаляемым из их предыдущих суперпредставлений прежде чем быть добавленным как подпредставления получателя.)

Учитывая допустимый «newSubviews» параметр,-setSubviews: выполняет любую сортировку массива подпредставлений, дополнение подпредставления, и действие удаления подпредставления необходимо для отъезда получателя с требуемым новым массивом подпредставлений. Таким образом любой элемент «newSubviews», который уже не является подпредставлением получателя, добавляется. Любой элемент существующего массива «подпредставлений» представления, который не находится в «newSubviews», удален. И любые представления, которые находятся в обоих «подпредставлениях» и «newSubviews», просто перемещены в массив подпредставлений по мере необходимости, не будучи удаленным и повторно добавлены.-setSubviews: метод также отмечает затронутые области представления/окна как нуждающийся в дисплее для отражения нового z-упорядочивания.

Представления, фокусирующие кольца и производительность получения

Чтобы помочь гарантировать корректную перерисовку фокусирующих колец, AppKit может автоматически нарисовать дополнительные части окна вне тех, которые код приложения отметил как нуждающийся в дисплее. Если focusRingType свойство представления того первого респондента установлено в значение кроме NSFocusRingTypeNone, это может сделать это для первого представления респондента в ключевом окне приложения. Любое представление, которое может стать первым респондентом, но не рисует фокусирующее кольцо, должно иметь свой набор focusRingType к NSFocusRingTypeNone для предотвращения ненужной дополнительной перерисовки.

Протокол NSAnimatablePropertyContainer

NSAnimatablePropertyContainer является новым протоколом в Leopard, в настоящее время принимаемом NSView и NSWindow. Методы в NSAnimatablePropertyContainer следующие:
- (id)animator;
- метод аниматора возвращает объект прокси для получателя, который может использоваться для инициирования подразумеваемой анимации изменений свойства. «Аниматор» объекта должен быть обработан, как будто это было самим объектом и может быть передано любому коду, принимающему объект в качестве параметра. Отправка KVC-совместимых сообщений «набора» к прокси инициирует анимацию для автоматически анимированных свойств ее целевого объекта, если активный NSAnimationContext в текущем потоке будет иметь значение продолжительности, больше, чем нуль, и анимация для использования для ключа свойства найдена-animationForKey: поисковый механизм, определенный ниже. Автоматически анимированные свойства объекта - те для который [theObject animationForKey:] находит и возвращает CAAnimation вместо ноля, часто потому что [[theObject класс] defaultAnimationForKey:] указывает анимацию по умолчанию для ключа.

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

Для общего конкретного случая анимации представлений:
Инициирование анимации через «аниматора» проксирует объектные работы и при Базовом составлении композита Основанного на анимации и при традиционного взгляда. Главная разница при Базовом Основанном на анимации составлении композита - то, что для внутренних геометрических свойств, таких как «кадр» представления, вся анимация обрабатывается на Базовом уровне Анимации, означая, что свойство представления будет сразу установлено в желаемое целевое значение, и представление не будет видеть последовательные промежуточные значения. Эффект анимации в таких случаях чисто визуален и существует только в «бэкэнде» дерева рендеринга Базовой Анимации. Напротив, под стандартным не уровень поддержанное составление композита представления, анимации свойства представления выполняются на уровне AppKit, и в течение тех анимаций представления получат операции набора значений для последовательных промежуточных значений. Это - также истина для анимации всех определенных разработчиками свойств, и при составлении композита поддержанного уровнем и при традиционного взгляда и анимации.
- (NSDictionary *)animations;
- (void)setAnimations:(NSDictionary *)dict;
Дополнительный словарь «анимаций» контейнера animatable свойства отображает ключи NSString на значения CAAnimation. Когда возникновение, соответствующее ключ, стреляет для представления,-animationForKey: первые взгляды в этом словаре для анимации, которые выполнятся в ответ.
- (id)animationForKey:(NSString *)key;
Когда возникновение, указанное «ключевыми» огнями для объекта,-animationForKey: консультируется для нахождения анимации, если таковые имеются, который должен быть выполнен в ответ. Как его Базовый дубликат Анимации, - [CALayer actionForKeyPath:], этот метод является точкой трубы, определяющей стандартный порядок, в котором поиск анимации продолжается и не является тем, который должны были бы обычно переопределять клиенты. Этот метод сначала проверяет словарь «анимаций» получателя, затем отступает к +defaultAnimationForKey: для класса получателя.
+ (id)defaultAnimationForKey:(NSString *)key;
Как описано выше,-animationForKey: затем консультируется с методом класса +defaultAnimationForKey: когда его поиск словаря «анимаций» экземпляра не поднимает анимацию для использования для данного изменения свойства.

+defaultAnimationForKey NSVIEW: метод возвращает анимацию по умолчанию, которая должна быть выполнена, когда возникновение, указанное «ключевыми» огнями для представления, где «ключ» обычно называет свойство, значение которого изменяется. Для каждого из собственных animatable свойств NSVIEW реализация NSVIEW возвращает подходящий CAAnimation по умолчанию, который будет использоваться. Для всех других ключей этот метод возвращает ноль.

Разработчик, реализующий пользовательский подкласс представления, может включить автоматическую анимацию добавленных свойств подкласса путем переопределения этого метода, и наличие его возвращает желаемый CAAnimation по умолчанию для использования для каждого из ключей свойства интереса. Переопределение должно подчиниться супер для любых ключей, которые оно в частности не обрабатывает, упрощая наследование спецификаций анимации по умолчанию.
@implementation MyView
+ (id)defaultAnimationForKey:(NSString *)key {
if ([key isEqualToString:@"borderColor"]) {
// By default, animate border color changes with simple linear interpolation to the new color value.
return [CABasicAnimation animation];
} else {
// Defer to super's implementation for any keys we don't specifically handle.
return [super defaultAnimationForKeyKey:key];
}
}
@end

NSCollectionView

Новый класс представления был добавлен для упрощения интересных анимаций: NSCollectionView. Можно установить или связать содержание представления набора с массивом объектов. Для каждого объекта представление набора создаст NSCollectionViewItem, поочередно управляющий представлением, использующимся для отображения значений его «представленного объекта». Все представления автоматически создают расположение для вмещения всех элементов в его содержание, и анимирует их, если содержание изменится (например, если содержание будет переупорядочено, то это будет двигать элементы в новые позиции).

Обычно элементы представления набора создаются из «прототипа», установленного как «itemPrototype» выход в Интерфейсном Разработчике. Поскольку представление набора просматривает элемент, можно использовать стандартные средства управления/представления для формирования «составного» представления. Например, можно сгруппировать NSImageView и NSTextField в NSBox для формирования модуля, выводящего на экран изображения и имена для него. Для установки представления, используемого набором, просматривают элемент, Вы обычно используете выход «представления».

Для заполнения набора просматривают представление элемента со значениями от представленного объекта, Вы будете обычно создавать привязку из представления (или любое из подпредставлений) к «representedObject» элемента представления набора (пример: Вы могли связать привязку значения текстового поля к ключу «representedObject.name» элемента представления набора). Также Вы могли разделить NSCollectionViewItem на подклассы и сделать его источником данных или делегатом одного из представлений.

Обратите внимание на то, что в ранних семенах Leopard (включая 2006 WWDC) NSCollectionView был известен как NSGridView, и NSCollectionViewItem был NSLayoutItem. Как предвещается в информации о версии, эти классы изменились; однако, изменения ограничиваются строго двумя классами и несколькими изменениями имени метода:

- layoutView в NSLayoutItem стал collectionView
- minGridSize, maxGridSize, и соответствующие методы установщика стали minItemSize, maxItemSize, setMinItemSize: и setMaxItemSize:
- newLayoutItemForRepresentedObject: теперь newItemForRepresentedObject:
- layoutItemPrototype и setLayoutItemPrototype: теперь itemPrototype и setItemPrototype:

Старые названия были удалены в окончательной версии Leopard.


Независимость разрешения

На Leopard независимость разрешения (иначе «HiDPI») является функцией разработчика. Можно использовать QuartzDebug в/Developer/Applications/Performance Инструментах для установки масштабного коэффициента пространства пользователя в 1,25, 1.5, 2.0, или 3.0, затем запустить приложение. Пользовательский интерфейс Вашего приложения будет масштабироваться масштабным коэффициентом пространства пользователя.

Большинство стандартных средств управления теперь нарисовано в высоком разрешении, позволяющем им казаться четкими при выполнении с включенным масштабированием пространства пользователя.

Кроме того, много стандартных изображений теперь доступны во включающей графике с высокой разрешающей способностью для появления четкими, когда масштабируется. Имена этих изображений объявляются в NSImage.h. Обратите внимание на то, что важно использовать эти изображения только в цели, обозначенной именем, так как фактическая диаграмма может измениться в будущих выпусках. Посмотрите раздел NSImage для большего количества информации.

Существуют некоторые известные проблемы с неинтегральными масштабными коэффициентами 1,25 и 1.5.

- Большая часть получения должна произойти на интегральных границах пикселей, но представления автоматически не ограничиваются упасть на границы пикселей
- Если мозаичное изображение является интегральным пикселем, измеренным и скорректированным по мере необходимости для предотвращения пиксельных трещин, изображение, размещающее рядом также, выглядит самым корректным
- Отслеживание rects на нецелочисленных границах может генерировать mouseEntered: событие, в то время как мышь все еще немного вне дробных границ или mouseExited: в то время как мышь все еще немного в дробных границах.
- Если заглушки вертикально или горизонтально не выравниваются с заливкой, некоторые средства управления на неграницах пикселей, возможно, неровно оборвали края
- Если scrollView находится на негранице пикселей, текст может дрожать при прокрутке

Можно использовать - [NSView centerScanRect:] для расположения представления или rect в представлении о границах пикселей. На Тигре этот метод использовал NSIntegralRect, развернувший данный прямоугольник, исходящий по мере необходимости для приземления на интегральные пиксельные значения. На Leopard этот метод является сохранением размера, приводящим к лучшему поведению расположения, когда применено к смежные прямоугольники. Это изменение применяется только к приложениям, соединенным на Leopard или позже по причинам совместимости. Также можно преобразовать в использование координат окна - [NSView convertRectToBase:], вокруг результата к интегральным значениям с округлением правил, удовлетворяющих Вашим потребностям, затем преобразовывают назад для просмотра использования координат - [NSView convertRectFromBase:].

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

NSOpenGL и независимость разрешения

Приложения и платформы, стремящиеся стать независимыми от разрешения, могут встретиться с проблемами с использованием OpenGL, вследствие того, что много API-функций OpenGL, таких как glViewport (), ожидают свои параметры в пиксельных модулях. Код, приученный к выполнению под масштабным коэффициентом пользовательского интерфейса 1,0, может содержать скрытые ошибки, где размерности представления были неправильно обработаны, как будто они были в пиксельных модулях. Для масштабных коэффициентов кроме 1,0, различие между единицами пространства представления и устройством (пиксель) модули становится намного более важным для надлежащего наблюдения.

Образец общего использования в Основанных на какао приложениях OpenGL, например, должен был передать размерности границ представления непосредственно glViewport (), который ожидает получать его параметры в пиксельных модулях:
- (void)reshape {
NSSize bounds = [self bounds];
    // This is technically INCORRECT, because bounds is not expressed in pixel units.
glViewport(0, 0, bounds.size.width, bounds.size.height);
}
Чтобы помочь упростить переход к независимости разрешения для приложений, использующих эту общую кодовую комбинацию, Leopard AppKit автоматически конфигурирует границы любого представления, имеющего связанный NSOpenGLContext (таким образом, NSOpenGLViews, а также обычные NSViews, вовлеченные в использование NSOpenGLContext) так, чтобы границы были выражены в пиксельных модулях, согласно текущему масштабному коэффициенту пользовательского интерфейса. Так, например, если приложение будет иметь NSOpenGLView, тип телосложения которого 100x100 точки, и то приложение запущено в масштабном коэффициенте пользовательского интерфейса 1,25, то кадр NSOpenGLView останется 100x100 точки, но о его границах сообщат как 125x125. Это включает обычно используемые конструкции кода такой, поскольку вышеупомянутые - изменяют метод для функционирования правильно без изменений кода.

В то время как это автоматическое обходное решение может быть достаточным для обеспечения совместимости для многих приложений, идеальное решение для клиентского кода OpenGL для выполнения корректных преобразований модуля при необходимости. Например, вышеупомянутые - изменяются, метод был бы более правильно записан как:
- (void)reshape {
// Convert up to window space, which is in pixel units.
NSSize boundsInPixelUnits = [self convertRect:[self bounds] toView:nil];
    // Now the result is glViewport()-compatible.
glViewport(0, 0, boundsInPixelUnits.size.width, boundsInPixelUnits.size.height);
}
Код, который предназначается для Mac OS 10.5 и позже может использовать-convertRectToBase: метод вместо того, чтобы преобразовать в ноль представления, имеющий преимущество корректного приведения к результату в пиксельных модулях независимо от того, поддерживается ли представление уровнем. (Если представление поддерживается уровнем,-convertRectToBase: преобразовывает в координатное пространство запоминающего устройства уровня, вместо к координатному пространству окна.)

Текстовый рендеринг и независимость разрешения

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


NSRuleEditor

NSRuleEditor является новым управлением AppKit, представленным в Leopard. NSRuleEditor позволяет пользователю конфигурировать «правила», подобные правилам в Почте или в окне поиска Средства поиска, путем выбора из раскрывается, управляя пользовательскими представлениями, и добавлением, удалением или реконструкцией строк.

NSRuleEditor:
- Вложение поддержек и невложенные режимы
- Добирается доступное раскрывается/просматривает от его делегата
- Совместимо с привязкой
- Автоматическая генерация поддержек NSPredicates
- Поддерживает гибкую локализацию через строковый файл или словарь

См. NSRuleEditor.h и документация для большего количества информации об этом новом классе.


NSPredicateEditor

NSPredicateEditor является подклассом NSRuleEditor, специализированного для работы с предикатами. В отличие от NSRuleEditor, NSPredicateEditor не зависит от своего делегата для заполнения его строк (и не вызывает методы делегата заполнения). Вместо этого его строки заполняются от его objectValue, который является NSPredicate.

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

NSPredicateEditor представляет одно свойство, rowTemplates, который является массивом NSPredicateEditorRowTemplates.
- (void)setRowTemplates:(NSArray *)rowTemplates;
- (NSArray *)rowTemplates;
Разработчики будут обычно конфигурировать NSPredicateEditor с некоторым NSPredicateEditorRowTemplates, или программно или в Интерфейсном Разработчике, и затем устанавливать и получать NSPredicates на NSPredicateEditor. Об изменениях в предикате объявляют с обычным механизмом цели/действия.


NSMenu

Новая настройка меню APIs

Leopard теперь позволяет приложениям устанавливать пользовательское представление для пункта меню через следующие новые методы NSMenuItem:
- (void)setView:(NSView *)view;
- (NSView *)view;
Пользовательское представление принимает все аспекты получения пункта меню. Обработка события от нажатия мыши обычно обрабатывается для представления, включая мышь вниз, мышь, перемещенную мышь, вводимая мышь, мышь, из которой выходят, мышь, перетащенная, и события колесика прокрутки. В нелипком режиме отслеживания (управляющий меню с удерживаемой кнопкой мыши), представление получит mouseDragged: события. Посмотрите заголовочный файл NSMenuItem.h для получения дополнительной информации о представлениях пользовательского элемента меню.

Анимация в представлениях пункта меню

Представления в пунктах меню могут быть анимированы с обычными механизмами, такими как вызов - [NSView setNeedsDisplay:] или - [Дисплей NSView] в повторяющемся таймере. Но знайте, что отслеживание меню происходит с циклом выполнения, работающим в NSEventTrackingRunLoopMode, таким образом, любые таймеры, которые Вы добавляете, должны быть установлены стрелять в то время как в тот режим.

Новые методы делегата и уведомления

Меню теперь уведомят своих делегатов, когда они будут открыты или закрываются, и когда они выделяют или не выделяют элементы во время отслеживания меню. См. NSMenu.h для получения дополнительной информации об этих новых методах делегата.

Удаление протокола NSMenuItem

Все использование id <NSMenuItem> было удалено из AppKit в Leopard. Приложения должны переключиться на класс NSMenuItem.

NSMenuItem приписал усечение заголовка

В версиях Mac OS X до Leopard NSMenuItems с чрезмерно длинными приписанными заголовками был бы отсечен против края меню. В Leopard приписанные заголовки NSMenuItem будут усеченными значением по умолчанию с помощью стиля усечения «NSLineBreakByTruncatingMiddle». Можно переопределить это путем указания различного режима разрыва строки для NSParagraphStyle, присоединенного к приписанной строке заголовка.

validateItem: больше вызванный

Исторически, AppKit вызвал validateItem: метод для проверки пунктов меню, если validateMenuItem: и validateUserInterfaceItem: не были реализованы. Это поведение никогда не документировалось, и оно теперь отключено для приложений, основывался на Leopard. Приложения, полагающиеся на validateItem: должен переключиться на validateMenuItem: или validateUserInterfaceItem:.

validateMenuItem: только обращенный ключевые эквиваленты соответствия

Перед Leopard, вводя ключевой эквивалент заставил бы AppKit пытаться проверить каждый пункт меню в меню (через validateMenuItem:). Как оптимизация, AppKit теперь только проверит элемент с соответствующим ключевым эквивалентом. Приложения должны использовать методы делегата NSMENU лениво заполнить меню.

Командная клавиша = обработанный как +

Как особый случай, если никакой пункт меню не будет требовать ⌘ = как ключевой эквивалент, то ввод ⌘ = инициирует любой ⌘ + ключевой эквивалент, если нажатое = ключ будет совместно использован с + ключ. Например, на раскладке клавиатуры США, нажимая «=» ключ, смежный с «-», включает строку числа, инициирует любой ⌘ + ключевой эквивалент, но «=» ключ выше клавиатуры не будет. Если раскладка клавиатуры не имеет никого «+» и «=» символы на том же ключе, это не применяется.

Ключевой эквивалентный uniqueing

AppKit пытается гарантировать, чтобы многократные пункты меню не имели того же ключевого эквивалента, потому что иначе пользователь мог бы случайно вызвать тот, ожидая вызывать другой. Это вызывают ключевым эквивалентным uniqueing. У Тигра меню кнопки всплывающего меню были uniqued с главным меню (и в Leopard, это было расширено, чтобы также покрыть сегментированные средства управления). Однако пункты меню, которые, как думают, являются псевдонимами друг друга, могут теперь совместно использовать тот же ключевой эквивалент в Leopard. (Пункты меню считаются псевдонимами, если у них есть то же действие). Таким образом, в Leopard, Вы можете иметь «Полужирный» в кнопке всплывающего меню и также в главном меню, и оба покажут ⌘B как ключевой эквивалент.

Проходят через отключенные ключевые эквиваленты

До Leopard были бы проигнорированы ключевые эквиваленты, соответствующие отключенным пунктам меню. В Leopard Ваше приложение теперь имеет возможность обработать их. Например, ключевой эквивалент для управления-K на отключенном пункте меню больше не будет блокировать emacs ярлык в NSTextView в Leopard.

С поддерживают в ключевых эквивалентах

Немецкий sharfes s символ (ß) теперь поддерживается как ключевой эквивалент.

Ключевые Эквиваленты Пункта меню в неримских Сценариях

У Тигра и ранее, ключевые эквиваленты неправильно интерпретировались следующим образом: Символы были извлечены как Макрочеловек, и получающиеся значения интерпретировались, как будто они были в кодировании приложения. Это не было проблемой в приложениях, работающих с кодировкой символов Макрочеловека, но вызовет проблемы в других случаях. (Кодировка символов по умолчанию приложений часто зависит от выбора локализации пользователя.)

Например, указание ключевого эквивалента наклонной черты влево «\» (U+005C) привело бы к ключу знака иены, эквивалентному (U+00A5) при выполнении при японской локализации, потому что значение наклонной черты влево в Макрочеловеке соответствует значение иены в Макджэпэнезе: оба - 0x5C в соответствующих наборах символов. Это было единственным способом получить ключ иены, эквивалентный в Тайгере.

В Leopard ключевые эквиваленты и наборы символов обрабатываются правильно. Для указания эквивалентного ключа иены укажите строку Unicode, содержащую иену (U+00A5).

Для совместимости на уровне двоичных кодов Leopard вернется к поведению Тайгера для приложений, соединенных перед Leopard. При обновлении приложения для Leopard необходимо гарантировать, что при работе Leopard ключевая эквивалентная строка содержит символы, которые Вы хотите вместо символов MacRoman, соответствующих кодовые точки Вашего символа в кодировании приложения.

Изображения состояния реализованы

Методы NSMenuItem setOnStateImage: setOffStateImage: и setMixedStateImage: теперь работайте, как задокументировано.

Никакие плагины CMM в 64-разрядном

NSMenu не пытается загрузить менеджера по Контекстному меню плагины в 64-разрядных приложениях. Нет никакого открытого интерфейса для создания 64-разрядных плагинов CMM в Leopard.

Существующие ранее переопределения - [NSMenuItem isHidden]

Во время тестирования некоторые приложения, как находили, имели существующие ранее реализации - [NSMenuItem isHidden], вмешавшийся в новый Leopard API того же имени. По причинам совместимости AppKit не вызовет - [NSMenuItem isHidden] на приложениях, основывался на Тайгере или ранее. При создании приложения на Leopard AppKit вызовет метод, и можно видеть странное поведение, такое как исчезновение меню. Мы рекомендуем, чтобы Вы не переопределили - [NSMenuItem isHidden] и удалили любые существующие переопределения в точке, что Вы основываетесь на Leopard.

Заголовки меню в строке меню

Рассмотрите главное меню приложения, экземпляр NSMenu. То меню содержит NSMenuItems, такой как пункт меню File, и пункт меню File имеет подменю типа NSMenu, содержащий элементы такой как Новое, Открытое и т.д.

У Тигра начальная метка, появляющаяся в строке меню, была взята из заголовка подменю. Но вследствие ошибки, изменения в заголовке этого меню не влияли на строку меню; вместо этого, заголовок родительского элемента использовался вместо этого. Так, например, заголовок подменю File определяет начальную метку, но изменить метку, необходимо изменить заголовок самого элемента Файла.

Для совместимости Leopard сохраняет это поведение для приложений, основывался на Тайгере. Однако приложения основывались на Leopard, найдет, что строка меню последовательно отражает заголовки подменю. Заголовки самих элементов в главном меню проигнорированы. Для максимальной совместимости и с Тайгером и с Leopard, необходимо установить и заголовок пункта главного меню и заголовок его подменю к той же вещи.

Это примечание только применяется к элементам, которые являются в mainMenu NSAPPLICATION и их непосредственных подменю. Заголовки других меню не имеют никакого эффекта.

- [NSApplication currentEvent] набор, когда меню, отслеживающее концы

Для приложений, соединенных на или после того, как, Leopard, - [NSApplication currentEvent] отразит событие, заставившее отслеживание меню заканчиваться во время действия выбранного пункта меню.

representedObject в NSPopUpButtonCell и NSMenuItemCell

В Leopard NSMenuItemCell и NSPopUpButtonCell передают обоим setRepresentedObject: и representedObject к их текущему NSMenuItem. (До Leopard NSMenuItemCell и NSPopUpButtonCell передали бы representedObject, но не setRepresentedObject:)

NSPopUpButtonCell setImagePosition:

NSPopUpButtonCell теперь уважает следующие позиции изображения: NSImageOnly, NSImageLeft, NSImageRight, NSImageOverlaps. До Leopard NSPopUpButtonCell всегда рисовал с позицией NSImageLeft.

Неограниченный NSPopUpButtonCells

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

Параметр привязки Тега Размещения Содержания NSPopupButton

Привязка содержания для NSPopupButton имеет новую опцию, Тег Размещения Содержания. Это обеспечивает способ смешать статические пункты меню с динамично сгенерированными пунктами меню в раскрывающемся. Когда эта опция будет установлена в ненулевое целочисленное значение, привязка содержания только поместит динамический контент вместо одного пункта меню в раскрывающемся, значение тега которого соответствует значение опции.

Типичное использование для этого должно поместить некоторые динамично сгенерированные пункты меню в одну часть раскрывающегося, и следование или предшествовать им с разделителем меню и статическим пунктом меню «действия».

NSStatusItem

Для непротиворечивости с NSCell и NSControl, - [NSStatusItem sendActionOn:] теперь возвращает старую маску.


NSToolbar

NSToolbar - Соедините интерфейсом с поддержкой Разработчика

Соедините интерфейсом с Разработчиком 3 поддержки, создающие элементы панели инструментов и панели инструментов. Однако можно хотеть обеспечить дополнительные элементы панели инструментов программно. Для выполнения этого соедините выход делегата NSToolbar желаемому делегату и обычно реализуйте методы делегата NSToolbar. Значение по умолчанию и позволенные идентификаторы элемента будут объединением создаваемых в Интерфейсном Разработчике и возвращенных Вашим делегатом.

Пункты меню NSToolbar - Show/Hide

В версиях Mac OS X до Leopard соедините интерфейсом с элементами, включая пункты меню, имевшие toggleToolbarShown: набору как их действие изменили бы их заголовки, чтобы «Показать, что Панель инструментов» или «Скрывает Панель инструментов». Для приложений, соединенных на или после Leopard, AppKit только зеркально отразит, «Показывают Панель инструментов» для «Сокрытия Панели инструментов» (или их локализованные изменения) и наоборот, как надлежащей. Пустой заголовок будет также изменен. Непустыми заголовками кроме локализованных вариантов этих строк должно управлять Ваше приложение.

NSToolbar - Ключевые эквиваленты могут соответствовать на панелях инструментов

Перед Leopard только NSPopUpButtons на панелях инструментов мог реагировать на ключевые эквиваленты. В Leopard AppKit теперь уважает ключевые эквиваленты всех средств управления на (видимых) панелях инструментов, не просто кнопки всплывающего меню.

NSToolbar - Размеры значения по умолчанию NSToolbarItem

С Leopard, если Вы вызываете setView: на NSToolbarItem не вызвав setMinSize: или setMaxSize: элемент панели инструментов установит свой минимальный и максимальный размер, равный типу телосложения представления.

NSToolbar - Архивация представления

У Тигра NSToolbar всегда «копировал» бы Ваше представление элемента панели инструментов при отображении его в палитре настройки с NSKeyedArchiver. В Leopard NSToolbar только скопирует Ваше представление при установке представления о двух различных элементах панели инструментов сразу. Например, скажите, что Вы выделяете точно одно представление (возможно, в пере) и всегда передаете его - [NSToolbarItem setView:] в Вашем toolbar:itemForItemIdentifier:willBeInsertedIntoToolbar: метод. Если то представление будет в активном элементе панели инструментов, и Вы выводите на экран палитру настройки, то NSToolbar скопирует то представление один раз. Если то представление не будет в активном элементе панели инструментов, и затем Вы выводите на экран палитру настройки, то NSToolbar не скопирует представление для палитры настройки, но скопирует то представление в точке, пользователь перетаскивает соответствующий элемент панели инструментов от палитры на панель инструментов.

Если Вы всегда гарантируете, чтобы Вы передали новые представления в setView: тогда NSToolbar никогда не будет копировать представление.

NSToolbar - mouseDownCanMoveWindow

До Leopard только текстурированные и объединенные окна были перемещаемы своей панелью инструментов. В Leopard все окна перемещаемы своими панелями инструментов. Приложения, поместившие пользовательские представления в панели инструментов и не переопределявшие isOpaque или mouseDownCanMoveWindow, могут найти, что их представления неожиданно становятся перемещаемыми в дополнение к ответу на щелчки. Если все следующее является истиной, для предотвращения этого mouseDownCanMoveWindow, как полагают, возвращается НЕ:

- Приложение было соединено на Тайгере или ранее.
- Представление находится в элементе панели инструментов.
- Представление не переопределяет mouseDownCanMoveWindow.
- Окно не текстурируется или объединенный заголовок/панель инструментов.


NSSound

NSSound имеет дополнительные функции на Leopard и позже. Они включают возможность получить продолжительность звука, изменить объем звука, установить и получить расположение воспроизведения в звуке и заставить звук циклично выполняться. См. документацию или комментарии в заголовке NSSound.h для больше об этом новом APIs.

У Тигра NSSound охотно создал бы «звук» для любого допустимого файла Quicktime, включая изображения. В Leopard init методы NSSOUND теперь возвратят ноль для файлов, не имеющих звуковой дорожки.


NSSpeechSynthesizer

NSSpeechSynthesizer теперь обеспечивает полный доступ к полномочиям синтезатора Apple, включая полный доступ к сторонним синтезаторам, совместимым с платформой Синтеза речи Apple. Разработчики могут теперь получить и установить отдельные свойства синтезатора, паузу и продолжать речь, остановить речь на определенных границах, удобно установить уровень и свойства объема, указать внешние словари и получить дополнительные обратные вызовы для событий синхронизации и ошибок. Разработчики какао, которые раньше должны были использовать Синтез речи Углерода API для получения доступа к определенным функциям синтезатора, должны теперь быть в состоянии использовать класс NSSpeechSynthesizer вместо этого.

Также новый для Leopard Алекс, английская речь, эффективно использующая усовершенствованную технологию Apple для поставки естественной интонации даже на очень быстрых говорящих уровнях.


NSViewController

Новый класс, NSViewController, был добавлен к AppKit в Mac OS 10.5. Это служит примерно той же цели как NSWindowController, но для представлений вместо окон. Это:
• Делает тот же вид управления памятью объектов верхнего уровня, которые NSWindowController делает, проявляя ту же заботу для предотвращения ссылочных циклов, когда средства управления связываются с владельцем файла пера, которого NSWindowController начал брать в Mac OS 10.4.
• Имеет универсальное «представленное объектное» свойство, чтобы упростить для Вас устанавливать привязку в пере к объекту, который еще не известен во время загрузки пера или легко доступный к коду, это делает загрузку пера.
• Имеет реализацию значения ключа, связывающего NSEditor неофициальный протокол, так, чтобы объекты, которым принадлежат контроллеры представления, могли легко заставить связанные элементы управления в представлениях фиксировать или отбросить изменения, которые вносит пользователь.
• Имеет свойство «заголовка», потому что мы ожидаем, что это будет использоваться во многих ситуациях, где пользователю дают возможность выбрать из нескольких именованных представлений.

NSViewController предназначается, чтобы быть очень допускающим повторное использование. Например, как описано ниже,-addAccessoryController NSPageLayout и NSPrintPanel: методы каждый берет контроллер представления и устанавливает представленный объект в NSPrintInfo, который должен быть показан пользователю. Когда пользователь отклоняет панель печати, NSPageLayout и NSPrintPanel, каждый отправляет сообщения NSEditor в каждый вспомогательный контроллер представления, чтобы гарантировать, что изменения пользователя фиксировались или отбрасывались должным образом. Заголовки аксессуаров получены от контроллеров представления и показаны пользователю в выпадающих меню, из которых может выбрать пользователь. Если Ваше приложение должно динамично связать относительно сложные представления с объектами, что они представляют пользователю, Вы могли бы быть в состоянии снова использовать NSViewController похожими способами.

NSViewController является подклассом NSResponder, но контроллеры представления никогда не делают себя следующими респондентами управляемых представлений. Это - ответственность объекта, помещающего управляемое представление в окно для вставки контроллера представления в цепочку респондента, если это стоило бы. Например, после получения представления от контроллера представления и добавления его к суперпредставлению с - [NSView addSubview:], можно установить следующего респондента подпредставления в контроллер представления, и затем установить, просматривают следующего респондента контроллера к суперпредставлению.


NSPageLayout и аксессуар NSPrintPanel просматривают улучшения

NSPageLayout и NSPrintPanel всегда имели-setAccessoryView: методы, позволяющие Вам указывать пользовательские области, которые будут показаны в установке страницы и панелях печати, соответственно. Однако не было никакого способа указать соответствующий заголовок, который должен появиться во всплывающем меню панели областей. Также не было никакого способа связать сводный текст, который должен быть показан для пользовательских настроек печати области в панели печати или добавить больше чем одну такую область к панели. Наконец, с введением встроенного предварительного просмотра к NSPrintPanel в Mac OS 10.5 (описанный в следующем разделе), мы должны обеспечить способ для Вас инициировать перерисовку предварительного просмотра, когда пользователь изменяет параметры печати, что Вы представляете пользователю во вспомогательном представления.

Новые методы были добавлены к классу NSPageLayout для использования в своих интересах нового класса NSViewController:
- (void)addAccessoryController:(NSViewController *)accessoryController;
- (void)removeAccessoryController:(NSViewController *)accessoryController;
- (NSArray *)accessoryControllers;
Когда панель установки страницы представлена пользователю каждый вспомогательный, контроллер автоматически отправляется-setRepresentedObject: сообщение с NSPrintInfo этого объекта. Каждый контроллер также автоматически отправляется - сообщение заголовка. Если это возвращает ноль, краткое название приложения используется во всплывающем меню, позволяющем пользователю выбрать вспомогательное представление.

Немного отличающиеся новые методы были также добавлены к классу NSPrintPanel:
- (void)addAccessoryController:(NSViewController<NSPrintPanelAccessorizing> *)accessoryController;
- (void)removeAccessoryController:(NSViewController<NSPrintPanelAccessorizing> *)accessoryController;
- (NSArray *)accessoryControllers;
Они очень подобны их эквивалентам NSPageLayout, кроме вспомогательного, которому контроллер должен также приспособить новому протоколу NSPrintPanelAccessorizing, имеющему всего два метода:
- (NSArray *)localizedSummaryItems;
Возвратите текст, суммирующий настройки, что пользователь выбрал использование этого представления аксессуара панели печати, и это должно появиться в сводной области панели печати. Это должен быть массив словарей (не ноль), каждый из которых имеет запись NSPrintPanelAccessorySummaryItemNameKey и запись NSPrintPanelAccessorySummaryItemDescriptionKey, значения которой являются строками. Представление аксессуара панели печати должно быть KVO-совместимым для «localizedSummaryItems», потому что NSPrintPanel наблюдает, что он сохраняет то, что это выводит на экран в его актуальном представлении Summary. (В Mac OS 10.5 нет никакого способа для пользователя видеть Ваш вспомогательный представление и представление Summary одновременно, но это не могло бы всегда быть истиной в будущем.)
- (NSSet *)keyPathsForValuesAffectingPreview;
Возвратите ключевые пути для свойств, значения которых влияют на то, что нарисовано во встроенном предварительном просмотре панели печати. NSPrintPanel наблюдает эти, ключ соединяет каналом и перерисовывает предварительный просмотр, когда изменяются значения для любого из них. Например, если Вы пишете вспомогательному представление, позволяющее пользователю включить и выключить печать номеров страниц в панели печати, Вы могли бы обеспечить реализацию этого метода, возвращающего набор, включающий строку как «pageNumbering», как в классе PrintPanelAccessoryController TextEdit. Этот метод протокола является дополнительным, потому что не необходимо, если Вы не используете встроенный предварительный просмотр NSPrintPanel, но если Вы используете предварительный просмотр, почти наверняка необходимо реализовать этот метод должным образом также.

Из-за требований этого протокола, которые диктуют факты обеспечения хорошего пользовательского интерфейса при настройке панели печати, необходимо всегда разделять NSViewController на подклассы при добавлении модернизированного представления аксессуара к панели печати.

Новые строки NSPrintPanelAccessorySummaryItemNameKey и NSPrintPanelAccessorySummaryItemDescriptionKey для использования реализациями метода NSPrintPanelAccessorizing-localizedSummaryItems.

-setAccessoryView: и методы-accessoryView теперь осуждаются и в NSPageLayout и в NSPrintPanel.

Также осуждаемый-readPrintInfo NSPageLayout и методы-writePrintInfo, и-updateFromPrintInfo NSPrintPanel и-finalWritePrintInfo методы. Они никогда не были очень полезны. NSViewController обеспечивает функциональность, которую те методы, как предполагалось, обеспечили; можно реализовать переопределение - метод просмотра сделать Ваш вспомогательным UI представления соответствующий информации печати, которая будет представлена, и переопределения KVB-commitEditing и-commitEditingWithDelegate:didCommitSelector:contextInfo: методы для создания представленной информации печати соответствующей показу значений в Вашем вспомогательный представление.

Новые методы NSPrintPanel для управления предварительным просмотром и какие стандартные средства управления появляются

в Mac OS 10.5 новая функция предварительного просмотра была добавлена к системе печати AppKit. Панель печати теперь имеет представление, показывающее пользователю изображение страниц, которые будут распечатаны. Это идет по умолчанию, но можно выключить его в приложении. Посмотрите обратное примечание совместимости на уровне двоичных кодов в конце этого раздела для получения дополнительной информации.

Во многих приложениях не является надлежащим представить панели установки страницы пользователю, или даже включать Установку Страницы... элемент в меню File, но не было никакого другого простого способа позволить пользователю указать параметры установки страницы, которые будут использоваться при печати. (Новое уведомление UI: если Ваше приложение постоянно не хранит параметры установки страницы на основе на документ или имеет некоторый механизм для соединения их с тем, что другой вид крупномасштабных объектов приложение может иметь дело с, это, вероятно, не должен иметь панели установки страницы вообще.) Кроме того, некоторые приложения должны представить панели печати, не включающие стандартные поля для разрешения пользователю указать число копий или диапазон страниц, которые будут распечатаны.

Так, В Mac OS 10.5, новое перечисление и новые методы были добавлены к классу NSPrintPanel так, чтобы можно было управлять предварительным просмотром и какие стандартные средства управления появляются в панели печати. Посмотрите заголовочный файл и документацию для получения информации об этих опциях.
enum {
NSPrintPanelShowsCopies = 0x01,
NSPrintPanelShowsPageRange = 0x02,
NSPrintPanelShowsPaperSize = 0x04,
NSPrintPanelShowsOrientation = 0x08,
NSPrintPanelShowsScaling = 0x10,
    NSPrintPanelShowsPageSetupAccessory = 0x100,
    NSPrintPanelShowsPreview = 0x20000
};
typedef NSInteger NSPrintPanelOptions;
- (void)setOptions:(NSPrintPanelOptions)options;
- (NSPrintPanelOptions)options;
В Mac OS 10.5 - возвратится сообщение опций, отправленное недавно создаваемому NSPrintPanel (NSPrintPanelShowsCopies | NSPrintPanelShowsPageRange), если это не создавалось NSPrintOperation, когда это также возвратит NSPrintPanelShowsPreview. Чтобы позволить Вашему приложению использовать в своих интересах средства управления, которые могут быть добавлены по умолчанию в будущих версиях Mac OS X, получите опции от панели печати, которую Вы только что создали, включите и выключите флаги, о которых Вы заботитесь о, и затем устанавливаете опции.

Обратное примечание совместимости на уровне двоичных кодов: поведение, описанное выше, применяется к приложениям, соединяющимся против Mac OS 10.5 или позже. Если приложение установило представление аксессуара панели печати, в любом приложении, соединенном против Mac OS 10.4 или ранее, проигнорирована опция NSPrintPanelShowsPreview. До Mac OS 10.5 не было никакого API, который позволил бы Вам заставлять предварительный просмотр быть перерисованным, когда пользователь изменяет настройки печати с помощью вспомогательного представление, и если предварительный просмотр не перерисовывает тогда, это показывает неточную информацию, и это не хуже, чем никакой предварительный просмотр вообще.

Другие улучшения NSPrintPanel

Так, чтобы можно было изменить заголовок кнопки по умолчанию в панели печати от «Печати» до чего-то еще, два новых метода были добавлены к NSPrintPanel:
- (void)setDefaultButtonTitle:(NSString *)defaultButtonTitle;
- (NSString *)defaultButtonTitle;
Заголовок кнопки по умолчанию в панели печати. Можно переопределить заголовок стандартной кнопки, «Печать» при использовании NSPrintPanel таким способом, которым печать фактически не собирается происходить, когда пользователь нажимает ту кнопку.

Так, чтобы можно было изменить привязку к справке для кнопки вопросительного знака в панели печати для указания на что-то настроенное для приложения, два других новых метода были добавлены к NSPrintPanel:
- (void)setHelpAnchor:(NSString *)helpAnchor;
- (NSString *)helpAnchor;
HTML помогает привязке для панели печати. Можно переопределить стандартную привязку кнопки справки панели печати.

-runModal метод NSPrintPanel всегда использует NSPrintInfo текущего NSPrintOperation, таким образом, не было никакого способа представить модальную приложением панель, использующую любой другой NSPrintInfo. В Mac OS 10.5 новый метод был добавлен для фиксации этого:
- (NSInteger)runModalWithPrintInfo:(NSPrintInfo *)printInfo;
Реализация по умолчанию-runModal теперь просто вызывает [сам runModalWithPrintInfo: [NSPrintOperation currentOperation] printInfo]].

Средство доступа для NSPrintInfo, это представляется пользователю для редактирования, было также добавлено:
- (NSPrintInfo *)printInfo;
Простое средство доступа. Ваши-beginSheetWithPrintInfo:... делегируют, может использовать это так, это не должно сохранять указатель на NSPrintInfo в другом месте при ожидании пользователя для отклонения панели печати.

Доступ к базовым базовым объектам печати от NSPrintInfo

В предыдущих версиях Mac OS X не было никакого общедоступного способа добраться, Печать Ядра (ранее известный как «Диспетчер печати») возражает, что NSPrintInfo фактически создается поверх. Для упрощения для Вас делают к точно тем же вещам, которые PMPrintSettingsGetValue ()/PMPrintSettingsSetValue () функции, добавленные в Mac OS 10.4, позволяют Вам сделать, новый метод был добавлен к NSPrintInfo в Mac OS 10.5. Самая непосредственная проблема, которую решает этот метод, состоит в том, что не было никакого пути к Вашим представлениям аксессуара для помещения настроек в место, где они могут быть сохранены и восстановлены системным предварительно установленным механизмом печати:
- (NSMutableDictionary *)printSettings;
Настройки печати информации печати. Можно поместить значения в этот словарь для хранения их в любой предварительной установке, которую пользователь создает при редактировании этой информации печати с панелью печати. Такие значения должны быть объектами списка свойств. Можно также использовать этот словарь для получения значений, установленных другими частями системы печати, как диалоговое расширение печати драйвера принтера (тот же вид значений, возвращающихся Диспетчером печати Углерода PMPrintSettingsGetValue () функция). Другие части системы печати часто используют строки ключа как «com.apple.print. PrintSettings. PMColorSyncProfileID», но точки как те в строках ключа не работал бы хорошо с KVC, таким образом, те точки заменяются подчеркиваниями в ключах, появляющихся в этом словаре, как в «com_apple_print_PrintSettings_PMColorSyncProfileID». Необходимо использовать то же соглашение при добавлении записей в этот словарь.

Поскольку существует значительное количество функциональности, представленной Ядром, Распечатывающим API, который не достаточно обычно применим, чтобы быть представленным AppKit API, новые методы были добавлены к NSPrintInfo в Mac OS 10.5 для предоставления доступа к базовым Базовым объектам Печати:
- (void * /* PMPrintSession */)PMPrintSession;
- (void * /* PMPageFormat */)PMPageFormat;
- (void * /* PMPrintSettings */)PMPrintSettings;
Возвратите Печать Ядра PMPrintSession, PMPageFormat или объект PMPrintSettings, соответственно. Возвращенный объект является всегда соответствующим состоянию NSPrintInfo в данный момент, метод вызывается, но не обязательно сразу обновляется если другие методы NSPrintInfo как-setPaperSize: и-setPaperOrientation: вызываются. Возвращенный объект всегда будет допустим (в Базовом смысле Печати). При установке каких-либо значений в возвращенном PMPageFormat или PMPrintSettings, необходимо позже вызвать-updateFromPMPageFormat или-updateFromPMPrintSettings, соответственно. Вы не должны также вызывать PMSessionValidatePageFormat () или PMSessionValidatePrintSettings (), если Вы делаете это. Вы не должны вызывать PMRelease () для возвращенного объекта, кроме, конечно, для балансирования любых вызовов PMRetain () Вы делаете.
- (void)updateFromPMPageFormat;
- (void)updateFromPMPrintSettings;
Учитывая, что PMPageFormat NSPrintInfo или PMPrintSettings были изменены чем-то другим, чем сам NSPrintInfo, обновляет NSPrintInfo, чтобы быть непротиворечивым.

Соответствие наблюдения кодирования и значения ключа значения ключа NSPrintInfo

Несмотря на какой в комментарии для - [NSPrintInfo printSettings] в <AppKit/NSPrintInfo.h> говорится, KVC/KVO-compliance NSPrintInfo не действительно достаточно завершен, чтобы быть полезным в Mac OS 10.5. Можно добавить наблюдателя значения ключа для ключевого пути к NSPrintInfo, но, например, наблюдатель не будет последовательно уведомляться относительно изменений, внесенных пользователем, когда NSPrintInfo будет представлен NSPrintPanel.

Улучшения NSPrintOperation

В предыдущих версиях Mac OS X должность печати, которую системное использование печати было получено путем вызова - [NSView (NSPrinting) printJobTitle:]. Поскольку часто не программно удобно сделать такую информацию доступной для печатных представлений, новые методы были добавлены к NSPrintOperation в Mac OS 10.5, так, чтобы код, создающий работу печати, мог просто установить должность печати сразу же и не иметь для отъезда его где-нибудь, печатное представление может найти его:
- (void)setJobTitle:(NSString *)jobTitle;
- (NSString *)jobTitle;
Если должность установлена, она переопределяет что-либо, что могло бы быть получено путем отправки печатного представления [NSView (NSPrinting) printJobTitle] сообщение.

В предыдущих версиях Mac OS X-currentPage метод позволил Вам узнавать точно, какая страница распечатывается во время выполнения работы печати, но не было никакого простого способа определить, сколько страниц распечатываемый документ имеет. В Mac OS 10.5 новый метод был добавлен, чтобы позволить Вам сделать это:
- (NSRange)pageRange;
Первый номер страницы не мог бы быть 1, в зависимости от того, что печатное представление возвратило, когда отправлено - [NSView (NSPrinting) knowsPageRange:] сообщение.

Поддержка многократных ориентаций страницы на работу печати

В то время как задание распечатывается, в Mac OS 10.5 можно теперь изменить ориентацию страниц. Чтобы сделать так, Ваше печатное представление должно сделать свое собственное разбиение на страницы и указать так путем возврата YES, когда отправлено-knowsPageRange: сообщения. Затем когда отправлено-rectForPage: сообщения, это может изменить ориентацию текущей информации печати работы печати, и Какао учтет изменение. Например: [[[NSPrintOperation currentOperation] printInfo] setOrientation:theNewOrientation].

устаревшие (deprecated) Методы NSPrintOperation и Исправление ошибки в - [NSPrintOperation printPanel]

В Mac OS 10.5-setAccessoryView: и методы-accessoryView теперь также осуждаются в NSPrintOperation.

Также осуждаемый-setJobStyleHint: и-jobStyleHint: методы. Вместо того, чтобы отправить одно из тех сообщений в NSPrintOperation, просто вызовите - [NSPrintOperation printPanel] и отправьте их возвращенному NSPrintPanel вместо этого. - [NSPrintOperation printPanel] был обновлен, чтобы создать и возвратить новую панель печати, если ни один еще не был установлен. (Это обычно просто возвращало бы ноль прежде.)

Исправления ошибок в - [NSPrintInfo paperName], - [NSPrintInfo setPaperName:], и - [NSPrinter pageSizeForPaper:]

В Mac OS 10.2 через Mac OS 10.4 была ошибка в - [NSPrintInfo paperName], который заставит его возвращать неправильные бумажные имена. Например, это могло бы возвратить «na-букву» или «Букву», когда это должно возвратиться, «LetterSmall» (помните, бумага «имена», возвращенные-paperName, не для показа пользователям; используйте-localizedPaperName для получения тех). Аналогично, - [NSPrintInfo setPaperName:] мог установить газету, имевшую тот же размер как именованная бумага, но другое имя. Эти проблемы были особенно примечательны, когда принтер поддерживает многократные «бумаги», имеющие те же размеры, но различные области изображения. Ошибка была исправлена в Mac OS 10.5.

В более ранних версиях Mac OS X - [NSPrinter pageSizeForPaper:] только работал, когда переданные строки, которые являются бумажными именами, не бумагой IDs, в смыслах, установленных Ядром, Распечатывающим API. В Mac OS 10,5 этих методов теперь всегда работают когда переданная бумага IDs (вид строки, теперь всегда возвращаемой - [NSPrintInfo paperName]). Для обратной совместимости на уровне двоичных кодов это возвращает те же значения, которые это имело бы в Mac OS 10.4, если передано бумажное имя.

Исправления ошибок в Отмене NSPrintOperation/NSPrintPanel

В более ранних версиях Mac OS X была ошибка, в которой задание печати будет отправлено в принтер даже при том, что пользователь поразил Кнопку отмены в панели прогресса печати, если уже начался рендеринг последней страницы задания. Эта ошибка была исправлена в Mac OS 10.5.

Была также ошибка, в которой вызов [[[NSPrintOperation currentOperation] printInfo] setJobDisposition:NSPrintCancelJob] из переопределений NSView (NSPrinting) методы не предотвращал часть задания печати, уже представленного от того, чтобы быть отправленным в принтер. Эта ошибка была также исправлена в Mac OS 10.5. Можно теперь программно отменить текущую работу печати в переопределениях любого из NSView (NSPrinting) методы.

В более ранних версиях Mac OS X не было никакого способа различить пользовательскую отмену и отказ при вызове - [NSPrintOperation runOperationModalForWindow:delegate:didRunSelector:contextInfo:] или - [NSPrintPanel beginSheetWithPrintInfo:modalForWindow:delegate:didEndSelector:contextInfo:]. В Mac OS 10,5 этих методов всегда устанавливают расположение задания представленной информации печати к NSPrintCancelJob, когда пользователь отменил панель печати, как - [NSPrintOperation runOperation] и - [NSPrintPanel runModal] всегда имеют. Если приложение соединяется против Mac OS 10.4 или ранее, для обратной совместимости на уровне двоичных кодов это только сделано. В случае NSPrintOperation «представленная информация печати» является той, которая может быть получена с - [NSPrintOperation printInfo], не тот, переданный в том, когда создавался NSPrintOperation.

Была ошибка, в которой NSPrintOperation создал с информацией печати, расположением задания которой был NSPrintCancelJob, никогда не будет приводить к выводу, независимо от того, какая кнопка пользователь раньше отклонял панель печати. Эта ошибка была исправлена.

Уведомление для разработчиков, работающих с печатью полей

«Поля Принтера» в панели Custom Page Sizes смутно называют. Они не поля в смысле NSPrintInfo, или в смысле Microsoft Word, AppleWorks или любого приложения, позволяющего пользователю установить поля страницы документа. Они - ширины и высоты областей страницы, лежащих за пределами области изображения для формата бумаги. Другими словами, панель Custom Page Sizes дает Вам возможность моделировать аппаратные ограничения при определении нового формата бумаги. Можно использовать - [NSPrintInfo imageablePageBounds] метод для получения области страницы, окружающейся полями принтера.


Поддержка универсальных идентификаторов типов (UTIs) в находящихся в NSDocument приложениях

Если Ваше приложение требует Mac OS 10.5, это может прекратить использовать их, устаревший Info.plist вводит свои записи CFBundleDocumentTypes:
CFBundleTypeExtensions
CFBundleTypeMIMETypes
CFBUndleTypeOSTypes
NSExportableAs

Это может вместо этого использовать LSItemContentTypes и (новый для Mac OS 10.5) ключи NSExportableTypes и объявить соответствующий UTIs как надлежащий в его Info.plist. Объявление UTIs в файлах Info.plist описано <http://developer.apple.com/macosx/uniformtypeidentifiers.html>. Для каждой записи CFBundleDocumentTypes, имеющей подзапись LSItemContentTypes, проигнорированы одноуровневые подзаписи с упомянутыми выше ключами. (Фактически парсинг Info.plist Какао всегда игнорировал подзаписи CFBundleTypeMIMETypes. В Mac OS 10.5 это продолжает. LaunchServices обращает внимание на них хотя, кроме тех случаев, когда существует одноуровневый элемент LSItemContentTypes. Так, в Mac OS 10.5 Какао и LaunchServices соблюдают те же правила об игнорировании одноуровневых элементов LSItemContentTypes.)

Если Ваше приложение использует ключ LSItemContentTypes, это должно также использовать ключ NSExportableTypes где применимо. Записи NSExportableTypes служат той же цели как записи NSExportableAs и являются аналогично подзаписями записей CFBundleDocumentTypes, но их значения являются массивами UTIs вместо массивов имен типов свободной формы старого стиля.

Использование этих ключей становится дополнительным:
CFBundleTypeName
CFBundleTypeIconFile
Для каждой записи CFBundleDocumentTypes, имеющей подзапись LSItemContentTypes, можно обеспечить подзаписи с помощью этих ключей для переопределения значка по умолчанию и доброй строки, которая иначе следовала бы из объявлений UTI. Как всегда имел место, любое использование CFBundleTypeName должно сопровождаться записью в файлах приложения InfoPlist.strings.

Значения подзаписей CFBundleTypeRole и NSDocumentClass не изменились в Mac OS 10.5.

Для каждой записи CFBundleDocumentTypes, имеющей подзапись LSItemContentTypes, UTIs используются в качестве программируемых имен типов NSDocument и NSDocumentController, как описано ниже, вместо значения любой подзаписи CFBundleTypeName, которая могла бы также присутствовать.

Если приложение соединяется против Mac OS 10.4 или ранее, для обратной совместимости на уровне двоичных кодов ни одно из этого нового поведения не берет влияние. Запись CFBundleDocumentTypes, не имеющая никакой подзаписи LSItemContentTypes вообще, имеет то же значение к Какао как в Mac OS 10.4.

Отладка подсказки: В Mac OS 10.5 можно узнать то, что NSDocumentController думает, что это найдено в Info.plist приложения путем выполнения 'объекта печати [[NSClassFromString («NSDocumentController») sharedDocumentController] _typeDescriptions]' в gdb (использующий Консоль отладки XCode, например). Не пытайтесь вызвать или переопределить - _typeDescriptions в Вашем приложении. Это там только в этой цели отладки и может исчезнуть в любое время.

Поставка подсказки: Если Вы хотите использовать в своих интересах UTIs в своем приложении, но работать на нем все еще и Mac OS 10.4 и Mac OS 10.5, можно просто добавить LSItemContentTypes (и NSExportableTypes, где это необходимо) подзаписи в Info.plist, и затем обновить переопределения NSDocumentController и методов NSDocument так, чтобы они распознали UTIs как имена типов в дополнение к виду имен типов документов, всегда использовавшихся в Mac OS 10.4. Старайтесь добавить подзаписи LSItemContentTypes во все записи CFBundleDocumentTypes Info.plist приложения, хотя, или вещи мог стать более сложным. См. описание нового поведения-typeForContentsOfURL:error: вниз ниже, например.

Поддержка UTIs в NSDocumentController

В Mac OS 10.5 NSDocumentController поддерживает UTIs. В следующих параграфах «объявленный приложением» UTI является тем, объявляющимся в правильно построенной подзаписи LSItemContentTypes правильно построенной записи CFBundleDocumentTypes Info.plist в приложении, соединяющемся против Mac OS 10.5 или позже. «Распознанный» UTI объявляется приложением или соответствует одному из объявленных приложением UTIs.

Ни один из методов NSDocumentController, осуждавшихся в Mac OS 10.4, не был обновлен для обработки UTIs должным образом. Необходимо прекратить вызывать и переопределять устаревшие методы использовать в своих интересах UTIs в приложении.

- makeUntitledDocumentOfType:error:-makeDocumentWithContentsOfURL:ofType:error: и-makeDocumentForURL:withContentsOfURL:ofType:error: все теперь принимают распознанный UTIs, поскольку тип представляет в виде строки, в дополнение к виду имен типа документа, принятых в Mac OS 10.4. Последние два метода были также обновлены для надлежащей обработки нераспознанных типов также. (Поскольку-typeForContentsOfURL:error: мог бы теперь возвратить тип urecognized.)

- URLsFromRunningOpenPanel теперь, для каждой записи CFBundleDocumentTypes, объявляющей открываемый тип документа (как в, имеет CFBundleTypeRole Редактора, или Средство просмотра, как в Mac OS 10.4) с объявленным приложением UTIs, передает те UTIs в-runModalOpenPanel:forTypes:. Для каждого CFBundleDocumentTypes, объявляющего открываемый документ без распознанного UTIs, это все еще передает расширения файла и закодированные типы файлов HFS как в Mac OS 10.4.

- runModalOpenPanel:forTypes: nows принимает весь допустимый UTIs в массиве строк типа, в дополнение к расширениям файла и закодированным типам файлов HFS, принятым в Mac OS 10.4.

- defaultType выбирает запись CFBundleDocumentTypes и полагает что тип документа быть типом по умолчанию, как в Mac OS 10.4. Как только это сделало тот выбор, это теперь возвращает первый объявленный приложением UTI для того типа, если существует кто-либо, или имя типа документа, вида возвратилось в Mac OS 10.4, если нет. (Таким образом, порядок элементов в массиве LSItemContentTypes действительно имеет значение, как порядок элементов в массиве CFBundleDocumentTypes всегда имеет.)

- typeForContentsOfURL:error: теперь использование - [NSWorkspace typeOfFile:error:] для обнаружения UTI файла, расположенного URL. (Таким образом, это могло бы возвратить нераспознанный UTI. Собственные вызовы AppKit его принимают тот факт во внимание.) Для обратной совместимости на уровне двоичных кодов это, однако, первые попытки та же вещь, которую это сделало в Mac OS 10.4 (вызывают-typeFromFileExtension: возможно дважды, передавая строку типа файла HFS для второго вызова), если существуют какие-либо записи CFBundleDocumentTypes Info.plist, не имеющие подзаписей LSItemContentTypes.

- documentClassForType: теперь признает, что любой распознал UTI как строку типа. Как в Mac OS 10.4 это отправляет сообщение +readableTypes в каждый класс, названный в результатах вызова-documentClassNames, и возвращает первый класс, читаемые типы которого включают тот, соответствующий переданный - в типе. «Соответствия» для UTI означают, «соответствует», вместо просто «равно». (Таким образом, этот метод будет работать, даже когда передано UTI, явно не объявляющийся в Info.plist приложения, но соответствующий тому, который является.)

- displayNameForType: теперь принимает весь допустимый UTIs как строку типа, в дополнение к виду имен типа документа, принятых в Mac OS 10.4. Это возвращает ноль, когда передано недопустимый UTI. Для обратной совместимости на уровне двоичных кодов это продолжает не возвращать ноль, когда передано non-UTI.

- fileExtensionsFromType: и-typeFromFileExtension: не изменились, но осуждаются.-fileExtensionsFromType: не работает, когда передано UTI.-typeFromFileExtension: только работы, когда передано расширение файла использовало в записи CFBundleDocumentTypes, не имеющей подзаписи LSItemContentTypes. В целом, если каждая из записей CFBundleDocumentTypes Info.plist приложения будет иметь допустимую подзапись LSItemContentTypes, и приложение не вызывает устаревшие методы как-fileNamesFromRunningOpenPanel, то эти методы никогда не будут вызываться из Какао.

Поддержка UTIs в NSDocument

В Mac OS обработка 10.5 NSDOCUMENT типов является соответствующей NSDocumentController. Каждый неосуждаемый метод NSDocument, берущий тип: или ofType: параметр теперь принимает распознанный UTIs, поскольку тип представляет в виде строки, в дополнение к виду имен типа документа, принятых в Mac OS 10.4.-setFileType: и - тип файла: фактически не интерпретируйте имя типа файла всегда, таким образом, они хорошо работают с UTIs.

Ни один из методов NSDocument, осуждавшихся в Mac OS 10.4, не был обновлен для обработки UTIs должным образом. Необходимо прекратить вызывать и переопределять устаревшие методы использовать в своих интересах UTIs в приложении.

+readableTypes, +writableTypes, и-writableTypesForSaveOperation: все теперь возвращают UTIs для записей CFBundleDocumentTypes с объявленным приложением UTIs и типы документов вида, возвращенные в Mac OS 10.4 для тех, которые не делают.

+isNativeType: теперь принимает весь допустимый UTIs как строку типа, в дополнение к виду имен типа документа, принятых в Mac OS 10.4. Если переданный - в UTI будет соответствовать распознанному UTI для рассматриваемого класса документа, НЕТ иначе, это возвратит YES.

Новый метод был добавлен к NSDocument, потому что - [NSDocumentController fileExtensionsFromType:] осуждается:
- (NSString *)fileNameExtensionForType:(NSString *)typeName saveOperation:(NSSaveOperationType)saveOperation;
Для указанного типа и детали отчасти сохраняют работу, возвращают расширение файла, которое может быть добавлено к основному имени файла. Если тип является UTI или, для обратной совместимости на уровне двоичных кодов с Mac OS 10.4 и ранее, вызывает [[NSDocumentController sharedDocumentController] fileExtensionsFromType:typeName] и выбирает первое расширение файла в возвращенном массиве если нет, реализация по умолчанию этого метода вызывает [[NSWorkspace sharedWorkspace] preferredFilenameExtensionForType:typeName].

Можно переопределить этот метод для настройки добавления расширений имен файлов NSDocument. В Mac OS 10.5 это только вызывается от двух мест в Какао: 1)-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: использование этот метод при создании нового имени файла для сохраненного автоматически содержания. 2) - [NSDocument (NSScripting) handleSaveScriptCommand:] использует этот метод при добавлении расширения имени файла, указанного сценарием. Во всех других случаях имя любого сохраненного файла будет полностью указано пользователем с панелью сохранения (знают ли они это или не).

Поддержка UTIs в NSPersistentDocument

В Mac OS обработка 10.5 NSPersistentDocument типов является соответствующей NSDocumentController и NSDocument's. Каждый метод NSPersistentDocument, берущий аргумент строки типа теперь, принимает распознанный UTIs, в дополнение к виду имен типа документа, принятых в Mac OS 10.4.

Поддержка UTIs в NSOpenPanel

В Mac OS 10.5 NSOpenPanel поддерживает UTIs. Следующие методы все теперь принимают весь допустимый UTIs как тип, представляют в виде строки, в дополнение к расширениям файла и закодированным типам файлов HFS, принятым в Mac OS 10.4:
-beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:
-beginForDirectory:file:types:modelessDelegate:didEndSelector:contextInfo:
-runModalForDirectory:file:types:
-runModalForTypes:
NSOpenPanel позволит пользователю выбрать файлы, типы которых соответствуют идентифицированным переданным - в UTIs. Так, можно позволить пользователю выбрать любой файл образа путем передачи в UTI как public.image. Знайте, однако, что набор типов, соответствующих другому, может быть расширен любым приложением, установленным на компьютере, таким образом, это не могло бы быть хорошей идеей, если Ваше приложение фактически должно открыть файлы, пользователь выбирает с открытой панелью. Обычно Вы передадите в UTIs для более конкретных типов, как public.tiff, com.adobe.pdf, или com.apple.sketch2.

Поддержка UTIs в NSSavePanel

В Mac OS 10.5 NSSavePanel поддерживает UTIs. Следующие методы теперь принимают или возвращают весь допустимый UTIs, поскольку тип представляет в виде строки, в дополнение к расширениям файла, принятым и возвратившимся в Mac OS 10.4 (закодировал типы файлов HFS, никогда не были допустимые значения для этих методов):
-setAllowedFileTypes:
-setRequiredFileType:
-allowedFileTypes:
-requiredFileType:

Поддержка UTIs в NSWorkspace

В Mac OS 10.5 NSWorkspace поддерживает UTIs.-iconForFileType: теперь принимает весь допустимый UTIs как строку типа, в дополнение к расширениям файла и закодированным типам файлов HFS, принятым в Mac OS 10.4.

Несколько методов были добавлены к NSWorkspace:
- (NSString *)typeOfFile:(NSString *)absoluteFilePath error:(NSError **)outError;
Учитывая абсолютный путь к файлу, возвратите универсальный идентификатор типа (UTI) файла, если можно быть определены. Иначе, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему не мог быть определен тип файла. Если файл в конце пути будет символьной ссылкой, то тип самой символьной ссылки будет возвращен, не тип соединенного файла. Можно вызвать этот метод для получения UTI существующего файла.
- (NSString *)localizedDescriptionForType:(NSString *)typeName;
Учитывая UTI, возвратите строку, которая описывает тип документа и является подходящей представить пользователю или нолю для отказа. Можно вызвать этот метод для получения имени типа, который должен быть показан пользователю, на предупреждении о неспособности приложения обработать тип, например.
- (NSString *)preferredFilenameExtensionForType:(NSString *)typeName;
Учитывая UTI, возвратите лучшее расширение файла для использования при создании файла того типа или ноля для отказа. Можно вызвать этот метод, когда приложение имеет только базовое имя файла, это пишется, и это должно добавить расширение файла так, чтобы тип файла мог быть надежно идентифицирован позже.
- (BOOL)filenameExtension:(NSString *)filenameExtension isValidForType:(NSString *)typeName;
Учитывая расширение файла и UTI, возвратите YES, если расширение файла является допустимым тегом для идентифицированного типа, НЕТ иначе. Можно вызвать этот метод, когда приложение должно проверить, может ли расширение файла использоваться для надежной идентификации типа позже. Например, NSSavePanel использует этот метод для проверки любого расширения, которое пользователь вводит в поле имени файла панели.
- (BOOL)type:(NSString *)firstTypeName conformsToType:(NSString *)secondTypeName;
Учитывая два UTIs, возвратите YES, если первое «соответствует» к второму в универсальной иерархии идентификатора типа, НЕТ иначе. Этот метод будет всегда возвращать YES, если две строки будут равны, таким образом, можно также использовать его с другими видами имени типа, включая объявленных в записях CFBundleTypeName Info.plist в приложениях, не использующих в своих интересах поддержку UTIs, добавленного к Какао в Mac OS 10.5. Можно вызвать этот метод, когда приложение должно определить, может ли это обработать файл известного типа, возвращенного-typeOfFile:error: например. Используйте этот метод вместо того, чтобы просто сравнить UTIs для равенства.

Поддержка UTIs в NSPasteboard

В Mac OS 10.5 NSPasteboard поддерживает UTIs. Каждый метод NSPasteboard, берущий строку типа или параметр строкового массива типа теперь, принимает UTIs как строки типа, в дополнение к виду имен типов области монтажа, принятых в Mac OS 10.4.

- типы теперь возвращают массив, содержащий UTIs, а также имена типов области монтажа, которые были бы возвращены в Mac OS 10.4.

Когда один из-pasteboard:provideDataForType владельцев области монтажа Вашего приложения: методы вызываются, это будет все еще всегда передаваться та же строка, указанная в многообещающем вызове-declareTypes:owner: или-addTypes:owner.

Когда-availableTypeFromArray: встречается с UTI в массиве типа, предоставленном для него, это возвратит это UTI, если точный UTI будет существовать где-нибудь в массиве области монтажа типов. Если никакой тип области монтажа не будет соответствовать UTI точно, то первый тип на области монтажа, соответствующей UTI, будет возвращен.

Поддержка UTIs в NSView и NSWindow

Аналогично, в Mac OS 10.5 NSView и NSWindow поддерживают UTIs. NSView и-registerForDraggedTypes NSWINDOW: методы теперь принимают UTIs как строки типа, в дополнение к виду имен типов области монтажа, принятых в Mac OS 10.4.-dragPromisedFilesOfTypes:fromRect:source:slideBack:event NSVIEW: метод теперь принимает UTIs как строки типа, в дополнение к виду расширений файла, принятых в Mac OS 10.4.

Для UTIs, зарегистрированного как перетащенные типы, соответствие UTI проверяется вместо равенства, чтобы определить, нужно ли месту назначения перетаскивания дать шанс обработать перетаскивание. Например, представление с UTI kUTTypeImage зарегистрировалось, поскольку перетащенному типу вызовут его методы назначения перетаскивания для обработки перетаскивания в его границах, когда область монтажа перетаскивания будет содержать любой тип, соответствующий kUTTypeImage.

Поддержка UTIs в службах

Можно теперь указать объявленный UTIs вместо типов области монтажа как элементы массивов NSSendTypes или NSReturnTypes в разделе описаний Служб Info.plist приложения.

Поддержка UTIs в прочих условиях классы AppKit

В более ранних версиях Mac OS X, этих четырех классов:
NSImage
NSImageRep
NSSound
NSAttributedString (в категории NSAttributedStringKitAdditions)

все имели пар методов, возвращающих любой массивы строк типа файла (расширения файла и закодированные типы файлов HFS) или строк типа области монтажа. В Mac OS 10.5, к этим методам присоединяются единственные новые методы что просто возвращаемые массивы UTIs. Кроме того, к методам NSImageRep, берущим тип файла или строки типа области монтажа, присоединяется новый метод, просто берущий UTIs.

Важно иметь в виду при работе с UTIs, который простая строковая проверка равенства не является корректным способом проверить, «соответствует» ли тип, идентифицированный одним UTI ", типу, идентифицированному другим. См. описание - [NSWorkspace type:conformsToType:] в разделе «Support for UTIs in NSWorkspace».

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

Поддержка UTIs в NSImage

В NSImage, этих новых методах:
+ (NSArray *)imageTypes;
+ (NSArray *)imageUnfilteredTypes;
присоединитесь к этим методам, которые могли бы быть осуждены в будущем выпуске Mac OS X, но еще не являются:
+ (NSArray *)imageFileTypes;
+ (NSArray *)imagePasteboardTypes;
+ (NSArray *)imageUnfilteredFileTypes;
+ (NSArray *)imageUnfilteredPasteboardTypes;
(Старые методы еще не осуждаются, потому что у Вас могла бы все еще быть причина переопределить их, потому что-initWithContentsOfFile:-initWithContentsOfURL:-initByReferencingFile:-initByReferencingURL:-initWithPasteboard: и +canInitWithPasteboard: методы еще не были обновлены для использования UTIs при решении, какой подкласс NSImageRep нужно инстанцировать. То же является истиной - [NSBundle (NSBundleImageExtension) pathForImageResource:].)

Поддержка UTIs в NSImageRep

В NSImageRep, этих новых методах:
+ (Class)imageRepClassForType:(NSString *)type;
+ (NSArray *)imageTypes;
+ (NSArray *)imageUnfilteredTypes;
присоединитесь к этим методам, которые могли бы быть осуждены в будущем выпуске Mac OS X, но еще не являются:
+ (Class)imageRepClassForFileType:(NSString *)type;
+ (Class)imageRepClassForPasteboardType:(NSString *)type;
+ (NSArray *)imageFileTypes;
+ (NSArray *)imagePasteboardTypes;
+ (NSArray *)imageUnfilteredFileTypes;
+ (NSArray *)imageUnfilteredPasteboardTypes;
(Старые методы еще не осуждаются, потому что у Вас могла бы все еще быть причина переопределить их, потому что +imageRepsWithContentsOfFile: +imageRepWithContentsOfFile: +imageRepsWithContentsOfURL: +imageRepWithContentsOfURL: +imageRepsWithPasteboard: +imageRepWithPasteboard: и +canInitWithPasteboard: методы еще не были обновлены для использования UTIs при решении, какой подкласс NSImageRep нужно инстанцировать, или можно ли подкласс инстанцировать, в случае последнего метода.)

Поддержка UTIs в NSSound

В NSSound, этом новом методе:
+ (NSArray*)soundUnfilteredTypes;
замены эти устаревшие методы:
+ (NSArray *)soundUnfilteredFileTypes;
+ (NSArray *)soundUnfilteredPasteboardTypes;

Поддержка UTIs в категории NSAttributedStringKitAdditions AppKit на NSAttributedString

В NSAttributedString (NSAttributedStringKitAdditions), этих новых методах:
+ (NSArray *)textTypes;
+ (NSArray *)textUnfilteredTypes;
замените эти устаревшие методы:
+ (NSArray *)textFileTypes;
+ (NSArray *)textPasteboardTypes;
+ (NSArray *)textUnfilteredFileTypes;
+ (NSArray *)textUnfilteredPasteboardTypes;
-initWithURL:options:documentAttributes:error:-initWithPath:documentAttributes: и-initWithURL:documentAttributes: методы были все обновлены для использования UTIs в надлежащих случаях. Поэтому имейте NSMutableAttributedString (NSMutableAttributedStringKitAdditions)-readfromurl:options:documentattributes:error: и-readFromURL:options:documentAttributes: методы.


Переписанное безопасное сохранение NSDocument и устранение ошибки для того, чтобы сохранить документы, изменяющиеся от простых файлов до пакетов файла

- [NSDocument writeSafelyToURL:ofType:forSaveOperation:error:] был переписан для использования нового FSPathReplaceObject CarbonCore () функция. Некоторые виды метаданных, как расширенные атрибуты и списки управления доступом, будут теперь чаще должным образом сохранены во время сохранения документа, особенно пакетов файла. Кроме того, безопасное сохранение документа теперь немного более безопасно, особенно когда диск, записанный в, полон. Например, Ваши пользователи больше не будут видеть, что их документы переименовываются с «~» на конце и оставили тот путь, когда документ, сохраняющий сбои, потому что существует недостаточно пространства на диске для сохранения новой версии документа.

В Mac OS 10.4 и ранее была ошибка, в которой будет неправильно функционировать NSDocument, когда документ, который был простым файлом на диске, был перезаписан с пакетом файла того же имени во время работы сохранения. (Некоторые приложения используют то же расширение файла и для плоского файла и для основанных на каталоге вариантов того, что концептуально, насколько пользователь заинтересован, тот же формат файла.) Эта ошибка была исправлена в Mac OS 10.5.

NSDocument, проверяющий на измененные файлы при том, чтобы экономить время

В Mac OS 10.5 - [NSDocument saveDocumentWithDelegate:didSaveSelector:contextInfo:] теперь проверяет, чтобы видеть, был ли файл документа изменен, так как документ был открыт или последний раз сохранен или вернулся, в дополнение к проверке перемещение файла, переименование и повреждение, которое это сделало начиная с Mac OS 10.1. Когда это обнаруживает модификацию файла, это представляет предупреждение, говоря, что пользователь «Файл этого документа был изменен другим приложением, так как Вы открыли или сохранили его», дав им выбор сохранения или не сохранения. Для обратной совместимости на уровне двоичных кодов это только сделано в приложениях, соединенных против Mac OS 10.5 или позже.

При обновлении приложения для соединения против Mac OS 10.5 имейте в виду, что является обычно более надлежащим вызвать один из NSDocument's - сохраняют … методы в коде приложения, чем один из - пишет … методы. - пишут, что … методы там прежде всего для Вас для переопределения.-saveToURL:ofType:forSaveOperation:error: который является методом, это предназначается, чтобы всегда быть вызванным во время сохранения документа, вызывает-setFileModificationDate: с новой датой модификации файла после того, как это было записано (только для NSSaveOperation и NSSaveAsOperation).

Аналогично, является обычно более надлежащим вызвать один из NSDocument's - возвращаются … методы в Вашем коде кода приложения, чем один из - считал … методы. - читает, … методы там прежде всего для Вас для переопределения.-revertToContentsOfURL:ofType:error: который является методом, это предназначается, чтобы всегда быть вызванным во время перечитывания открытого документа, вызывает-setFileModificationDate: с датой модификации файла после того, как это было считано.

Исправление ошибки в - [NSDocument isDocumentEdited] и Новый Констант, Используемый с - [NSDocument updateChangeCount:]

В предыдущих версиях Mac OS X была ошибка, в которой сохранение документа, отмена изменений, и затем создание равного количества новых изменений заставили бы документ казаться неизмененным. Если бы пользователь закрыл документ, то он был бы просто закрыт без предупреждения о несохраненных изменениях, которые были бы потеряны. Это произошло в любом приложении, в котором документ не отправлял [сам updateChangeCount:NSChangeCleared] во время сохранения документа (который Вы, как предполагается, не должны делать). Эта ошибка была исправлена в Mac OS 10.5, на основании NSDocument, теперь проводящего различия между выполнением и восстановлением изменений. Это больше не вызывает [сам updateChangeCount:NSChangeDone], когда это получает NSUndoManagerDidRedoChangeNotification. Теперь это вызывает [сам updateChangeCount:NSChangeRedone] вместо этого. (NSChangeDone все еще используется для NSUndoManagerWillCloseUndoGroupNotification.) NSChangeRedone является новым, и объявленный в <AppKit/NSDocument.h>.

Для обратной совместимости на уровне двоичных кодов NSDocument только использует NSChangeRedone вместо NSChangeDone в приложениях, соединенных против Mac OS 10.5 или позже, или если-updateChangeCount: не переопределяется.

Исправление ошибки в NSDocument для Nested Undo Manager Groups

В предыдущих версиях Mac OS X была ошибка, в которой поддержка отмены NSDOCUMENT не принимала во внимание вложенного менеджера по отмене группы. Каждый NSDocument просто отправил бы себя [сам updateChangeCount:NSChangeDone] сообщение каждый раз, когда это получило NSUndoManagerWillCloseUndoGroupNotification от своего менеджера по отмене. Это заставило бы его неправильно рассчитывать, сколько изменений пользователь внес так, чтобы, например, делая одно невыполнимое изменение представленным многократными действиями во вложенных группах отмены, и затем отменяя то изменение, все еще показал документ, как изменено. Эта проблема была особенно примечательна в основанных на документе Базовых Применениях данных, потому что использование NSManagedObjectContext вложило менеджера по отмене группы. Это было фиксировано в Mac OS 10.5. NSDocument теперь проверяет уровень группировки менеджера по отмене, когда это получает NSUndoManagerWillCloseUndoGroupNotification, и только вызывает-updateChangeCount: если уровень вложенности - меньше чем два.

Исправление ошибки в - [NSDocument writeToURL:ofType:error: Использование] NSFileWrapper

В Mac OS 10.4, - [NSDocument writeToURL:ofType:error:] передал НЕ как последний параметр при вызове - [NSFileWrapper writeToFile:atomically:updateFilenames:]. В Mac OS 10.5 это теперь передает YES так, чтобы обертке файла и любым оберткам файла, которые это содержит, обновили их имена файлов во время сохранения. - [NSDocument writeToFile:ofType:], то, которое осуждалось в Mac OS 10.4, не было обновлено похожим способом.

Исправление ошибки в Использовании NSDOCUMENT - [NSDocument autosavingFileType]

В Mac OS 10.4, - [NSDocument autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo:] вызвал бы [сам autosavingFileType] первый раз, когда документ был сохранен автоматически, создайте сохраненный автоматически файл содержания URL с помощью подразумеваемого расширения файла, и затем продолжите использовать тот URL для всех последующих автосохранений. Если бы-autosavingFileType был переопределен для возврата различных значений в разное время, то это могло бы привести к несоответствиям. Например, новая версия TextEdit в Leopard, использующем автоматическое сохранение, могла закончить тем, что сохранила пакет файла RTFD автоматически с «.rtf» расширением файла. (Поскольку это переопределяет-autosavingFileType для учета присоединений, добавляемых к документу.) Это было ошибкой и было фиксировано в Mac OS 10.5. NSDocument теперь последовательно использует результат вызова-autosavingFileType при определении, где сохраниться автоматически.

Уведомление для Сверхнаездников - [NSDocument autosavingFileType]

Если Вы не осторожны, даже с ошибкой, исправленной упомянутый выше, переопределяя-autosavingFileType, может привести к неправильному поведению во время повторного открытия сохраненных автоматически документов. - [NSDocument initForURL:withContentsOfURL:ofType:error:], то, которое вызывается во время повторного открытия сохраненных автоматически документов после катастрофического отказа, берет два URLs, но только имя типа сохраненного автоматически файла содержания. Реализация по умолчанию вызывает [сам setFileType:] с тем именем типа, но это часто - не правильное решение, если-autosavingFileType возвратил что-то другое, чем - тип файла во время автоматического сохранения документа. При переопределении-autosavingFile, вероятно, необходимо переопределить-initForURL:withContentsOfURL:ofType:error: также, и заставьте переопределение вызвать-setFileType: с типом фактического файла документа, после вызова супер. Посмотрите Класс документа TextEdit для примера того, как сделать это.

Уведомление для сверхнаездников чтения NSDocument и методов записи

Если Вы разделяете NSDocument на подклассы и переопределяете какой-либо из этих методов для чтения:

- readFromData:ofType:error:
- readFromFileWrapper:ofType:error:
- readFromURL:ofType:error:

Или любой из них для записи:

- dataOfType:error:
- fileWrapperOfType:error:
- writeToURL:ofType:error:
- writeToURL:ofType:forSaveOperation:originalContentsURL:error:
- fileAttributesToWriteToURL:ofType:forSaveOperation:originalContentsURL:error:
- writeSafelyToURL:ofType:forSaveOperation:error:

Или любой из методов, осуждавшихся в пользу них в Mac OS 10.4:

- dataRepresentationOfType:
- fileAttributesToWriteToFile:ofType:saveOperation:
- fileWrapperRepresentationOfType:
- initWithContentsOfFile:ofType:
- initWithContentsOfURL:ofType:
- loadDataRepresentation:ofType:
- loadFileWrapperRepresentation:ofType:
- readFromFile:ofType:
- readFromURL:ofType:
- writeToFile:ofType:
- writeToFile:ofType:originalFile:saveOperation:
- writeToURL:ofType:
- writeWithBackupToFile:ofType:saveOperation:

Не вызывайте-fileURL (или - имя файла, метод, осуждавшийся в фаворе если это в Mac OS 10.4), - тип файла или-fileModificationDate из Ваших переопределений. Во время чтения, обычно происходящего во время объектной инициализации, нет никакой гарантии, что свойства NSDocument как расположение или тип файла были установлены все же. Ваш переопределенный метод должен быть в состоянии определить все, что он должен сделать чтение от передаваемых параметров. Во время записи Ваш документ можно просить записать его содержание в различное расположение или использование различного типа файла. Снова, Ваш переопределенный метод должен быть в состоянии определить все, что он должен делать записи от передаваемых параметров.

Если Ваше переопределение не может определить всю информацию, этому нужно от передаваемых параметров, рассмотрите переопределение другого метода. Например, если Вы видите потребность вызвать-fileURL из переопределения-readFromData:ofType:error: возможно необходимо вместо этого переопределить-readFromURL:ofType:error:. Для другого примера, если Вы видите потребность вызвать-fileURL из переопределения-writeToURL:ofType:error: возможно необходимо вместо этого переопределить-writeToURL:ofType:forSaveOperation:originalContentsURL:error:.

Уведомление для Сверхнаездников - [NSDocument displayName]

Некоторые приложения имеют подклассы NSDocument, переопределяющих-displayName для настройки заголовков окон, связанных с документом. Это обычно - не правильное решение. Используйте подкласс NSWindowController и переопределение - [NSWindowController windowTitleForDocumentDisplayName:] вместо этого. Если еще более глубокая настройка требуется переопределение - [NSWindowController synchronizeWindowTitleWithDocumentName]. Имя дисплея документа используется в нескольких других местах, где пользовательское значение, которое приложение могло бы хотеть использовать в качестве заголовка окна, является обычно не надлежащим:
- На ошибочных предупреждениях, которые могут быть представлены во время возвращения, сохранения или печати документа.
- На предупреждениях, которые будут представлены во время сохранения документа, если документ был перемещен, переименован, или вставил мусор.
- На предупреждении, которое будет представлено, когда пользователь попытается закрыть документ с несохраненными изменениями.
- Как значение по умолчанию, показанное в «, Сохраняют Как»: поле панелей сохранения.
Это может использоваться еще в большем количестве мест в будущих выпусках Mac OS X.

Уведомление для Сверхнаездников - [NSDocument init]

Если Вы разделяете NSDocument на подклассы и переопределяете-init, удостоверьтесь, что Ваше переопределение никогда не возвращает ноль. При работе Mac OS 10.4 это, вероятно, вызовет катастрофический отказ в AppKit. В Mac OS 10.5 это заставит AppKit представлять ошибочное предупреждение, которое не очень полезно для пользователя (например, «Никакой документ не мог быть создан».). Если, например, Вы хотите предотвратить создание или открытие документов при обстоятельствах, уникальных для Вашего приложения, переопределите определенный метод NSDocumentController вместо этого. Считайте следующий раздел прежде, чем сделать так.

Уведомление для сверхнаездников методов, возвращающих NSErrors ссылкой

В Mac OS 10.4 мы опубликовали много новых методов тот возврат NSErrors. Например, в NSDocumentController:
- (id)openUntitledDocumentAndDisplay:(BOOL)displayDocument error:(NSError **)outError;
- (id)openDocumentWithContentsOfURL:(NSURL *)absoluteURL display:(BOOL)displayDocument error:(NSError **)outError;
и т.д. Когда переопределение таких методов заботится для соблюдения этого правила: метод, берущий ошибку: (NSError **), outError параметр должен, если это возвращает значение, сигнализирующее отказ (обычно ноль или НЕ), и если outError! =NULL, набор значение *outError для указания на NSError. Это не ответственность кода, вызывающего такие методы к нолю - инициализируют переменную, адрес которой взят и передан как параметр ошибок, именно так это может безопасно проверить, чтобы видеть, не является ли значение переменной больше нолем после вызова.

Если Вы переопределяете такой метод для предотвращения некоторого действия, но Вы не хотите, чтобы ошибочное предупреждение было представлено пользователю, возвратите ошибку, доменом которой является NSCocoaErrorDomain и чьим кодом является NSUserCancelledError. Сам AppKit последовательно представляет NSErrors пользователю с машинным оборудованием, описанным в <http://developer.apple.com/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/index.html>. Если Ваше приложение не переопределяет ошибочные методы представления AppKit новыми способами, использование этого машинного оборудования последовательно приводит к вызовам - [NSApplication presentError:] или - [NSApplication presentError:modalForWindow:delegate:didPresentSelector:contextInfo:]. Оба из этих методов тихо игнорируют ошибки NSCocoaErrorDomain/NSUserCancelledError. Так, например:
- (id)openDocumentWithContentsOfURL:(NSURL *)absoluteURL display:(BOOL)displayDocument error:(NSError **)outError {
    /* The user double-clicked on a document in the Finder or something, but we don't want to
open it yet if our application's custom licensing panel (for example) is being shown
as an application-modal dialog right now.
*/
id openedDocument = nil;
if (_licensingPanelIsShown) {
/* Defer the opening of the document until the user has dismissed the licensing panel.
*/
    ... Left as an exercise to the reader ...
        /* We're about to return nil, so we _must_ set *outError to something, unless of course outError is NULL.
Return an error that won't result in the presentation of an error alert. Regular Cocoa memory
management rules dictate that the invoker of this method is not responsible
for releasing the NSError, but of course +[NSError error:code:userInfo:] returns an autoreleased
object, so this is all correct.
*/
if (outError) {
*outError = [NSError errorWithDomain:NSCocoaErrorDomain code:NSUserCancelledError userInfo:nil];
}
} else {
/* Just do the regular Cocoa thing. We don't have to touch outError here.
NSDocumentController's implementation of this method has
to follow the rules too, so it sets *outError if it returns nil and outError!=NULL.
*/
openedDocument = [super openDocumentWithContentsOfURL:absoluteURL display:displayDocument error:outError];
}
return openedDocument;
}

Уведомление для Сверхнаездников Методов, Следующих за delegate:didSomethingSelector:contextInfo: Образец

Существуют методы в AppKit, особенно в NSDocument и классах DocumentController, что у всех есть в значительной степени те же три параметра:
- Объект делегата, который будет уведомлен, когда была завершена работа метода.
- Селектор метода для вызова, чтобы сделать уведомление.
- «Информация контекста», которая является просто значением для пасования назад делегату, таким образом, она может продолжить большую полную работу, свободную память, и т.д.

Каждый метод является этим путем, потому что лист может быть показан во время работы, выполняемой методом. Такие методы должны возвратиться, прежде чем пользователь отклонил лист (из-за способа, которым диспетчеризация пользовательского события сделана в AppKit), когда результат работы все еще неизвестен. delegate:didSomethingSelector:contextInfo: образец используется так, чтобы результат мог быть передан объекту, запросившему работу, когда наконец известен результат.

Можно обнаружить потребность переопределить один из этих методов в приложении. Это просто, когда переопределение должно добавить некоторое пользовательское поведение прежде, чем вызвать реализацию суперкласса, но действительно не очевидно, как записать переопределение, когда пользовательское поведение следует за вызовом метода суперкласса. Вот пример того, как сделать это в подклассе NSDocument:
- (void)canCloseDocumentWithDelegate:(id)delegate
shouldCloseSelector:(SEL)shouldCloseSelector
contextInfo:(void *)contextInfo {
    /* No matter what happens, the original delegate must be messaged (to prevent memory leaks, at the
very least). Because we're not going to pass the passed-in parameters to super, we have
to record them somewhere. The easy place to record them is in the NSInvocation we're going
to create anyway to message the original delegate. The method selected by shouldCloseSelector
must have the same signature as...
           - (void)document:(NSDocument *)document shouldClose:(BOOL)shouldClose contextInfo:(void *)contextInfo;
        ...and that dictates how we build our invocation. We don't set a value for the shouldClose:
argument (atIndex:3) because we don't know the value yet.
*/
NSInvocation *originalDelegateInvocation = [NSInvocation invocationWithMethodSignature:
[delegate methodSignatureForSelector:shouldCloseSelector]];
[originalDelegateInvocation setTarget:delegate];
[originalDelegateInvocation setSelector:shouldCloseSelector];
[originalDelegateInvocation setArgument:&self atIndex:2]; // document:
[originalDelegateInvocation setArgument:&contextInfo atIndex:4]; // contextInfo:
    /* Do the regular NSDocument thing, arranging to take back control afterward. We must retain
the invocation object here because contextInfo: arguments are not automatically retained.
*/
[super canCloseDocumentWithDelegate:self
shouldCloseSelector:@selector(thisDocument:shouldClose:contextInfo:)
contextInfo:[originalDelegateInvocation retain]];
}
- (void)thisDocument:(NSDocument *)document shouldClose:(BOOL)shouldClose contextInfo:(void *)contextInfo {
NSInvocation *originalDelegateInvocation = (NSInvocation *)contextInfo;
    // Is the document about to be closed?
if (shouldClose) {
        // Here we can do all sorts of things with this document that's about to be closed.
    }
    /* A little bit of UI advice: changing the value of shouldClose here might result in confusing
behavior. For example, if the user hit the Save button in a "Do you want to save the changes..."
panel, and the save succeeded, and shouldClose is YES, canceling closing by changing
shouldClose to NO before messaging the delegate would be an odd thing to do.
*/
    // Tell the original delegate that the decision to close this document or not has been made.
[originalDelegateInvocation setArgument:&shouldClose atIndex:3];
[originalDelegateInvocation invoke];
    // Balance the retain we did up above.
[originalDelegateInvocation release];
}

Исправление ошибки для Разового выходом NSDocument/NSPersistentDocument Зависает При использовании Привязки

В Mac OS 10.4 была ошибка в NSDocument, который заставит приложение зависать если:
- Окно документа имеет контроль с привязкой со свойством документа или, в приложении CoreData, управляемом объекте в контексте управляемого объекта персистентного документа.
- Пользователь редактирует использование управления, но не заставляет редактирование фиксироваться (как в, типы в поле редактирования, но не поражает вкладку).
- Пользователь пробует к выходу приложение.
- Пользователь нажимает кнопку Save в, «Вы хотите сохранить изменения...?» предупреждение это представлено.
Эта ошибка была исправлена в Mac OS 10.5.

Новое поведение в NSWindowController во время закрытия окна

В предыдущих версиях Mac OS X каждый NSWindowController зарегистрировался для NSWindowWillCloseNotification из его окна и затем сделал много вещей, когда это получило уведомление, если это имело документ (как удаление себя от контроллеров окна документа и попытки закрыть документ). Этот способ сделать вещи вызвал несколько проблем, включая:
• Другие получатели NSWindowWillCloseNotification нашли бы, что контроллер окна уже не имел никакого документа, когда они получили свое уведомление.
• NSWindowController не получил бы NSWindowWillCloseNotification, и документ не будет закрыт, если контроллер окна был делегатом окна, и затем делегат окна был сброшен (из-за пути - [NSWindow setDelegate:] вычеркивает из списка предыдущего делегата как наблюдателя уведомлений).

В Mac OS 10.5 NSWindow, имеющий контроллер окна теперь, отправляет ему личное сообщение, когда окно сделало (не, будет), близко, фиксируя тех и другие проблемы. NSWindowControllers больше не регистрируются для или зависят от получения NSWindowWillCloseNotification.

Кроме того, изменение, это подобно одному в - [NSWindowController dealloc], было внесено, и сам контроллер окна теперь выпущен вместо автовыпущенного (для балансирования [сам, сохраняют], который контроллер окна делает прежде, чем отправить-removeWindowController:self в его документ). Для обратной совместимости на уровне двоичных кодов новое поведение только сделано в приложениях, соединенных против Mac OS 10.5 или позже.

Исправления ошибок в - [NSWindowController dealloc]

- [NSWindowController setWindow:] заставляет окно управлять следующим респондентом как разработанного окна. Однако это могло привести к NSWindow обмен сообщениями зомби NSWindowController, в зависимости от которого объект был освобожден сначала. Если контроллер окна имеет окно и является его следующим респондентом, в Mac OS 10.5, - [NSWindowController dealloc] решает эту проблему путем отправки окна-setNextResponder:nil.

В предыдущих версиях Mac OS X, - [NSWindowController dealloc] автовыпустил окно и объекты верхнего уровня от пера, которое это загрузило. Это сделало напрасно трудным отладить ошибки программирования в приложениях. В Mac OS 10.5 - [NSWindowController dealloc] теперь выпускает объекты окна и объекты верхнего уровня вместо этого. Для обратной совместимости на уровне двоичных кодов новое поведение только сделано в приложениях, соединенных против Mac OS 10.5 или позже.

Уведомление для Людей, Настраивающих Перья, Имеющие Владельцев Файла NSWindowController

NSWindowController никогда не зависел от того, чтобы быть делегатом управляемого окна для выполнения его работы. NSWindowController даже не реализует методов делегата NSWindow. Подкласс NSWindowController является прекрасным местом для помещения реализаций методов делегата NSWindow, и если Вы сделаете так, то необходимо будет, вероятно, соединить выход делегата окна в пере владельцу файла пера, экземпляру подкласса NSWindowController, но Вы не должны делать так на учетной записи NSWindowController.

Новое поведение для имен автосохранения кадра NSWindowController

В предыдущих версиях Mac OS X, - [NSWindowController setWindow:], который обычно вызывается во время загрузки пера, всегда определяет имя автосохранения кадра окна к собственному имени автосохранения кадра контроллера окна. Это было значительным неудобством, потому что это означало, что всегда эффективно игнорировалось имя, которое Вы определяете в Разработчике Интерфейса использования окна. В Mac OS 10.5 - [NSWindowController setWindow:] теперь только определяет имя автосохранения кадра окна, если ее собственное является чем-то другим, чем ноль или пустая строка. Это означает, что имя автосохранения кадра окна теперь полезно, даже когда окно загружается контроллером окна. Можно все еще явно вызвать - [NSWindowController setWindowFrameAutosaveName:], если по некоторым причинам необходимо переопределить имя автосохранения кадра окна во время выполнения. Для обратной совместимости на уровне двоичных кодов новое поведение только сделано в приложениях, соединенных против Mac OS 10.5 или позже.


Улучшения NSSplitView

Несколько улучшений были сделаны к NSSplitView в Mac OS 10.5. Для получения дальнейшей информации на всех методах, упомянутых здесь, см. комментарии в <AppKit/NSSplitView.h>.

Так, чтобы можно было программно установить позицию делителя к произвольной позиции, новому-setPosition:ofDividerAtIndex: метод был добавлен.

Так, чтобы можно было программно запросить диапазон полезных значений, которые могут быть переданы-setPosition:ofDividerAtIndex: или реализуйте относительно сложные способы поведения в методах делегата представления разделения, новом-minPossiblePositionOfDividerAtIndex: и-maxPossiblePositionOfDividerAtIndex: методы были добавлены.

Можно программно упасть в обморок подпредставление путем вызова-minPossiblePositionOfDividerAtIndex: или-maxPossiblePositionOfDividerAtIndex: и передача результата к-setPosition:ofDividerAtIndex:.

Упростить для Вас позволять пользователю упасть в обморок подпредставления путем двойного щелчка по делителям, новому-splitView:shouldCollapseSubview:forDoubleClickOnDividerAtIndex: метод делегата был добавлен.

Автоматическое сохранение позиций делителя и разрушающееся подпредставление были добавлены к NSSplitView. Этим управляет новый-setAutosaveName: и-autosaveName: методы.

NSSplitView теперь помещает запись NSSplitViewDividerIndex в пользовательские информационные словари уведомлений NSSplitViewWillResizeSubviewsNotification и NSSplitViewDidResizeSubviewsNotification, которые он отправляет и передает-splitViewWillResizeSubviews делегата: и-splitViewDidResizeSubviews: методы, когда пользователь перетаскивает делитель или дважды щелкнул по делителю для разрушений подпредставления, или когда-setPosition:ofDividerAtIndex: вызывается.

Так, чтобы можно было легко сконфигурировать представления разделения с тонкими делителями, NSSplitView теперь имеет-setDividerStyle: и методы-dividerStyle. Двумя возможными стилями является NSSplitViewDividerStyleThick и NSSplitViewDividerStyleThin. Значение по умолчанию является толстым.

В случае, если цвет делителя NSSplitView по умолчанию не выглядит хорошим в в контексте UI Вашего приложения, NSSplitView теперь имеет-dividerColor метод. Это вызывается - [NSSplitView drawDividerInRect:], и возвраты значение на основе стиля представления разделения. Можно переопределить его для настройки.

Примечание: - [NSSplitView dividerColor] изменился начиная с семени 2007 года WWDC. Это теперь возвращается [NSColor clearColor] вместо [[сам окно] backgroundColor] для толстого стиля делителя. Кроме того, для обратной совместимости на уровне двоичных кодов это ведет себя по-другому в приложениях, соединенных против Mac OS 10.4 или ранее. В тех более старых приложениях это возвращает [[сам окно] backgroundColor] если [сам isOpaque] возвраты ДА, ноль иначе. - [NSSplitView isOpaque] также изменился начиная с семени 2007 года WWDC. В приложениях, соединенных против Mac OS 10.5 или более новый, это возвращает YES, если цвет делителя непрозрачен и (потому что NSSplitViews не рисуют фоны, но действительно корректируют их подпредставления для покрытия всего кроме делителей), все подпредставления непрозрачны. В приложениях, соединенных против Mac OS 10.4 или более старый, это возвращает YES, если бы все подпредставления непрозрачны, и [сам dividerThickness] возвращается, та же реализация по умолчанию NSSplitView значения-dividerThickness возвратилась бы, и [сам isPaneSplitter] возвращает YES.

Тонкие делители было бы трудно перетащить, если пользователь должен был точно щелкнуть по ним их. Чтобы дать пользователю большую область для щелчка «эффективная» область тонких делителей больше, чем нарисованная область, двумя точками в любом направлении, в Mac OS 10.5. Так, чтобы можно было настроить это поведение, когда кража щелчков мышью далеко от смежных средств управления не является надлежащей, например, существует новый-splitView:effectiveRect:forDrawnRect:ofDividerAtIndex: метод делегата можно реализовать.

Кроме того, можно поместить делитель «дескриптор» в UI, чтобы дать пользователю другой способ перетащить делитель. Так, чтобы можно было указать на представление разделения на область дескриптора и позволить ей управлять перетаскиванием делителя (и курсор мыши также), существует новый-splitView:additionalEffectiveRectOfDividerAtIndex: метод делегата можно реализовать.

Общий образец UI теперь должен обеспечить кнопку, чтобы показать и скрыть одно подпредставление или другое из представления разделения, и полностью скрыть делитель, когда скрыто подпредставление между ним и краем окна. Чтобы упростить для Вас делать это существует новый-splitView:shouldHideDividerAtIndex: метод делегата можно реализовать.

Исправления ошибок в NSSplitView

В Mac OS 10.5 некоторые долгосрочные ошибки были исправлены в NSSplitView.

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

NSSplitView теперь использует - [NSView setHidden:] при разрушении и неразрушении подпредставление вместо того, чтобы установить источник кадра подпредставления где-нибудь далеко, далекого пути. Один результат состоит в том, что средства управления внутри разрушились, подпредставления больше не могут содержать на ключевой фокус и больше не могут поэтому вмешиваться в поведение переключения вкладок окна.

Доступность: из-за использования NSSplitView - [NSView setHidden:], разрушился, подпредставления автоматически больше не присутствуют в иерархии доступности.

- [NSSplitView adjustSubviews] теперь надежно разделяет пространство к неразрушенным подпредставлениям, даже когда их общая ширина (в вертикальных представлениях разделения) или высота (горизонталь) является нулем, когда это вызывается.

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

NSSplitView теперь использует +resizeLeftCursor и +resizeRightCursor NSCURSOR в надлежащих случаях, вместо того, чтобы просто использовать +resizeLeftRightCursor все время. То же идет для +resizeUpCursor и +resizeDownCursor вместо +resizeUpDownCursor.

Уведомление для программирования с NSSplitView

Если Ваше приложение должно знать, когда подпредставление разрушено или расширено, регистр для NSSplitViewDidResizeSubviewsNotification, или реализуйте-splitViewDidResizeSubviews: метод делегата и использование - [NSSplitView isSubviewCollapsed:]. Например, не предполагайте, что представление будет разрушено вскоре после того, как делегат возвратил YES, когда отправлено-splitView:canCollapseSubview:.


NSWindow

Мы добавили API, чтобы указать, что окно может стать видимым перед входом в систему. Windows, который должен быть показан как часть входа в систему UI, должен иметь этот набор свойств. Настройка по умолчанию НЕТ.
- (BOOL)canBecomeVisibleWithoutLogin;
- (void)setCanBecomeVisibleWithoutLogin:(BOOL)flag;
Мы добавили API для управления совместным использованием содержания окна.-setSharingType: указывает, может ли содержание окна быть считано и/или записано из другого процесса. Типом совместного использования значения по умолчанию является NSWindowSharingReadOnly, что означает, что другие процессы могут считать содержание окна (например, для получения окна), но не могут изменить его. При установке типа совместного использования окна в NSWindowSharingNone так, чтобы содержание не могло быть получено, окно также не будет в состоянии участвовать во многих системных службах, таким образом, эта установка должна будет использоваться с осторожностью. При установке типа совместного использования окна в NSWindowSharingReadWrite другие процессы могут и считать и изменить содержание окна.
enum {
    NSWindowSharingNone = 0, // Window contents may not be read by another process
    NSWindowSharingReadOnly = 1, // Window contents may be read but not modified by another process
    NSWindowSharingReadWrite = 2 // Window contents may be read or modified by another process
};
typedef NSUInteger NSWindowSharingType;
- (void)setSharingType:(NSWindowSharingType)type;
- (NSWindowSharingType)sharingType;
Мы также добавили-setPreferredBackingLocation: установить предпочтительное расположение для запоминающего устройства окна. В целом Вы не должны использовать этот API, если не обозначено измерением производительности. Значение по умолчанию предпочло, чтобы расположением был NSWindowBackingLocationDefault, что означает, что система определяет, сохранено ли запоминающее устройство окна в VRAM или оперативной памяти. Можно использовать этот API для установки предпочтительного расположения для запоминающего устройства окна, но система может выбрать различное расположение. Можно использовать-backingLocation для нахождения текущего расположения запоминающего устройства окна.
enum {
    NSWindowBackingLocationDefault = 0,        // System determines if window backing store is in VRAM or main memory
    NSWindowBackingLocationVideoMemory = 1,        // Window backing store is in VRAM
    NSWindowBackingLocationMainMemory = 2        // Window backing store is in main memory
};
typedef NSUInteger NSWindowBackingLocation;
- (void)setPreferredBackingLocation:(NSWindowBackingLocation)backingLocation;
- (NSWindowBackingLocation)preferredBackingLocation;
- (NSWindowBackingLocation)backingLocation;
Мы также добавили API, чтобы упростить настраивать поведение значка документа в панели заголовка окна. До Leopard Вы могли вызвать - [NSWindow setTitleWithRepresentedFilename:] или - [NSWindow setRepresentedFilename:], чтобы указать, что окно представляет файл в данном пути. Это вызывает два способов поведения: окно показывает значок документа, подходящий для данного пути к файлу. Этот значок перемещаем, и создает псевдоним, копию или универсальное представление файла, когда отброшено. Во-вторых, значок документа и заголовок формируют cmd-активируемую-по-щелчку область. Cmd-щелчок в этой области показывает всплывающее меню. Выбор элемента из этого меню заставляет его быть показанным в Средстве поиска.

В Leopard мы добавили API для разрешения значка документа для любого окна учитывая URL. Если Вы вызываете setRepresentedURL: с допустимым ненолем URL окно покажет значок документа в строке заголовка. Если URL будет представлять имя файла или другой ресурс с известным значком, то тот значок будет использоваться в качестве значка документа. Иначе значок документа по умолчанию будет использоваться. Значок может быть настроен с помощью [[NSWindow standardWindowButton:NSWindowDocumentIconButton] setImage:customImage]. Если URL не будет нолем, и его путь не пуст, то окно будет иметь всплывающее меню, которое может быть показано через щелчок команды по области, содержащей значок документа и заголовок. По умолчанию это меню выведет на экран компоненты контура URL. Присутствием и содержанием этого меню может управлять метод делегата window:shouldPopUpDocumentPathMenu:. Если URL будет нолем или будет иметь пустой путь, то окно не покажет значок документа и не будет иметь всплывающее меню в наличии через щелчок команды.
- (void)setRepresentedURL:(NSURL *)url;
- (NSURL *)representedURL;
Если окно будет иметь representedURL, то окно по умолчанию покажет всплывающее меню пути для щелчка команды по прямоугольнику, содержащему кнопку значка документа окна и заголовок окна. Делегат окна может реализовать-window:shouldPopupDocumentPathMenu: переопределять поведение NSWINDOW по умолчанию для всплывающего меню пути. Возврат НЕ будет препятствовать тому, чтобы было показано меню. Возврат YES заставит окно показывать, что меню передало этому методу, который по умолчанию будет содержать пункт меню для каждого компонента контура representedURL. Если representedURL не будет иметь никаких компонентов контура, то меню не будет иметь никаких пунктов меню. Перед возвратом ДА, делегат окна может настроить меню путем изменения пунктов меню. пункты меню могут быть добавлены или удалены, и каждый заголовок пункта меню, действие, или цель может быть изменена.
- (BOOL)window:(NSWindow *)window shouldPopUpDocumentPathMenu:(NSMenu *)menu;
Делегат окна может реализовать-window:shouldDragDocumentWithEvent:from:withPasteboard: переопределять поведение перетаскивания значка документа NSWindow по умолчанию. Делегат может запретить перетаскивание путем возврата НЕТ. Перед возвратом нет, делегат может реализовать его собственное использование поведения перетаскивания - [NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:]. Также делегат может включить перетаскивание путем возврата ДА, например для переопределения поведения NSWINDOW по умолчанию запрещения перетаскивания отредактированного документа. Наконец, делегат может настроить содержание области монтажа прежде, чем возвратить YES.
- (BOOL)window:(NSWindow *)window
shouldDragDocumentWithEvent:(NSEvent *)event
from:(NSPoint)dragImageLocation
withPasteboard:(NSPasteboard *)pasteboard;
NSWindow теперь имеет метод для получения экземпляра мозаики прикрепления, позволяющего Вам управлять некоторыми аспектами мозаики прикрепления, соответствующей миниатюризированному окну. Для дальнейшего обсуждения посмотрите раздел NSDockTile.
- (NSDockTile *)dockTile;
- [Центр NSWindow] теперь использует различный алгоритм для расположения окон. Эффект этого изменения состоит в том, что окно, высота которого близко к или больше, чем 2/3 видимой экранной высоты, будет теперь расположено вертикально в пути, который является соответствующим меньшим окнам.

Действие стандартной кнопки на панели инструментов теперь проходит через общественность toggleToolbarShown: метод, передавая кнопку на панели инструментов как отправителя.

Поддержка была добавлена для стиля окна Heads Up Display (HUD). Окно HUD может быть создано с помощью NSHUDWindowMask. Окно должно быть NSPanel или подклассом. NSHUDWindowMask может быть объединен с другими стилями окна для создания безграничного или названного окна с определенным появлением и поведением. И названное и безграничное окно плавает выше других окон и частично прозрачно. Они hide-deactivate, что означает окно HUD, только будет видим, когда его приложение владения будет активно. Следующие комбинации допустимы:
NSHUDWindowMask
    | NSBorderlessWindowMask - безграничное окно с прозрачностью HUD и уровнем окна
или
    | NSTitledWindowMask | NSUtilityWindowMask - назвал окно с прозрачностью HUD и уровнем окна
        и любое следующее:
        | NSClosableWindowMask - назвал окно с рамкой для закрытия HUD, прозрачностью и уровнем окна
        | NSResizableWindowMask - названное окно с HUD изменяет размеры угла, прозрачности и уровня окна
        | Когда это окно будет ключевым окном, NSNonactivatingPanelMask - никакой эффект на появление, но приложение владения не обязательно не будет активен

следующее не допустимо

    NSMiniaturizableWindowMask - не поддерживаемый
    NSTexturedBackgroundWindowMask - не поддерживаемый
    NSDocModalWindowMask - не поддерживаемый
    NSUnifiedTitleAndToolbarWindowMask - не поддерживаемый

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

Мы изменили появление окна. Строка заголовка окна и фон панели инструментов нарисованы с темным градиентом когда ключевой или основной, и более легким градиентом, когда неактивный. NSUnifiedTitleAndToolbarWindowMask styleMask больше не имеет эффекта, так как все окна с панелями инструментов теперь имеют объединенный взгляд. Windows, styleMask которого включает NSTexturedBackgroundWindowMask, имеет фон окна, также темнеющий, когда ключевой или основной и светится, когда неактивный и может иметь второй градиент в разделе ниже содержания окна. Windows, styleMask которого не включает NSTexturedBackgroundWindowMask, имеет фон окна, который является существенной заливкой и не изменяется когда ключевой, основной, или неактивный.

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

В Leopard текстурированные окна имеют градиент на верхнем и нижнем разделе окна, где металл был ранее видим.

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

Если автоматическое вычисление градиента окна не приводит к корректным результатам, автоматическое вычисление может быть отключено с-setAutorecalculatesContentBorderThickness:NO. Если этот метод вызовут, также не устанавливая толщину границ содержания для данного края, то толщина границ содержания на том краю будет 0. Толщина границ содержания может быть установлена путем вызова-setContentBorderThickness:forEdge:. Также подкласс окна может переопределить-contentBorderThicknessForEdge:. Если-setContentBorderThickness:forEdge: кроме вызывают автоматическое вычисление NSWINDOW и autorecalculatesContentBorderThicknessForEdge: возвраты YES для данного края, поведение не определено. (Т.е. NSWindow, вероятно, перезапишет пользовательское значение).

Нетекстурированным окнам можно также теперь сказать нарисовать градиент фона окна в границе на нижней части окна. По умолчанию нетекстурированные окна не имеют никакой нижней границы.

- setContentBorderThickness:forEdge: и contentBorderThicknessForEdge: используйте систему координат содержания окна, таким образом, они находятся в точках, а не пикселях. Обратите внимание на то, что contentBorder не включает строку заголовка или панель инструментов, таким образом, окно, просто хотящее градиент в строке заголовка и панели инструментов, будет иметь contentBorderThickness 0 для NSMaxYEdge.

Вызов-setContentBorderThickness:forEdge:NSMinXEdge/NSMaxXEdge повысит исключение. Аналогично вызов-setAutorecalculatesContentBorderThickness:NO forEdge:NSMinXEdge/NSMaxXEdge повысит исключение. В нетекстурированном окне только, вызывая-setContentBorderThickness:forEdge:NSMaxYEdge повысит исключение, как будет, вызывая-setAutorecalculatesContentBorderThickness:NO forEdge:NSMaxYEdge. Это только допустимо для установки толщины границ содержания главного края в текстурированном окне.

Поведение-setContentBorderThickness:forEdge:NSMinYEdge и-setAutorecalculatesContentBorderThickness:NO forEdge:NSMinYEdge для нетекстурированных окон сделает следующее: главный градиент будет повторен в нижней границе, линии разделителя будут проведены между содержанием и нижней границей, и нижний угол будет округлен. Другие методы на нетекстурированных окнах или неиспользованных краях возвратятся 0.0 или YES.

- (недействительный) setContentBorderThickness: (CGFloat) толщина forEdge: (NSRectEdge) край;
- (CGFloat) contentBorderThicknessForEdge: (NSRectEdge) край;

- (недействительный) setAutorecalculatesContentBorderThickness: флаг (BOOL) forEdge: (NSRectEdge) край;
- (BOOL) autorecalculatesContentBorderThicknessForEdge: (NSRectEdge) край;

Мы осудили API, добавленный ранее в Leopard для Пробелов, и заменили его более общей формой. Windows имеет различное поведение под Пробелами на основе этого API.

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

Окна NSWindowCollectionBehaviorCanJoinAllSpaces могут считаться пространственно-независимыми. При упорядочивании окна все-пространства на экране оно упорядочивает на экране в текущем пространстве. Если Вы тогда переключаете пробелы, окно все-пространства обнаруживается в новом пространстве. При переключении фокуса на окно все-пространства Вы остаетесь в текущем пространстве. Строка меню является примером этого вида окна.

Окна NSWindowCollectionBehaviorMoveToActiveSpace видимы только на одном пространстве за один раз, но перемещаются в активное пространство при необходимости. При упорядочивании окна MoveToActiveSpace на экране это становится связанным с активным пространством (который является текущим пространством). Если Вы тогда переключаете пробелы, окно не обнаруживается в новом пространстве. При переключении фокуса назад на окно MoveToActiveSpace это становится видимым в активном пространстве, вместо того, чтобы вызвать переключатель пространства как нормальное окно был бы. AppKit находят, что панель является примером этого вида окна.
enum {
NSWindowCollectionBehaviorDefault = 0,
NSWindowCollectionBehaviorCanJoinAllSpaces = 1 << 0,
NSWindowCollectionBehaviorMoveToActiveSpace = 1 << 1
};
typedef NSUInteger NSWindowCollectionBehavior;
- (void)setCollectionBehavior:(NSWindowCollectionBehavior)behavior;
- (NSWindowCollectionBehavior)collectionBehavior;
setCanBeVisibleOnAllSpaces/canBeVisibleOnAllSpaces API, представленный ранее в Leopard, осуждается в пользу setCollectionBehavior:/collectionBehavior
-(void)setCanBeVisibleOnAllSpaces:(BOOL)flag    AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER_BUT_DEPRECATED;
-(BOOL)canBeVisibleOnAllSpaces AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER_BUT_DEPRECATED;
NSBackingStoreRetained больше не поддерживается как тип запоминающего устройства. Windows, создаваемый с типом запоминающего устройства NSBackingStoreRetained, будет тихо продвинут на NSBackingStoreBuffered. В реализации МАКОСКСА NSBackingStoreRetained не имеет никаких преимуществ в поведении, или производительность по NSBackingStoreBuffered, и на некоторых аппаратных средствах может вести себя значительно хуже вследствие производительности доступа кадрового буфера дисплея.

Листы

Так как семя в сентябре 2007 10,5 мы представили новый эффект листа для стандартных окон. Листы теперь присоединяются под довольным граница, включающая строку заголовка, панель инструментов и любую дополнительную толщину границ содержания на главном краю. Больше нет никакого «слота» в точке подключения между листом и окном. Вместо этого существует тень на главном краю листа, где это соединяется с окном. Если нет никакой границы панели инструментов или содержания кроме строки заголовка, лист расположен ниже строки заголовка.

Вследствие проблем совместимости дополнительная толщина границ содержания только принята во внимание для расположения листа, если это было установлено явно. Т.е. если окно возвращает YES из [сам autorecalculatesContentBorderThicknessForEdge:NSMaxYEdge], автоматически вычисленная толщина границ содержания не включена при расположении листа.

NSScreen

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


NSAlert

Мы добавили поддержку NSAlert для флажка утаивания и вспомогательного представление. setShowsSuppressionButton: указывает, должно ли предупреждение содержать флажок утаивания. Значение по умолчанию НЕТ. Этот флажок обычно используется, чтобы дать пользователю опцию не показать это предупреждение снова. Если показано, кнопка утаивания будет иметь локализованный заголовок значения по умолчанию подобным, «Не показывают это сообщение снова». Можно настроить это использование заголовка [[предупреждают suppressionButton] setTitle:] . Когда предупреждение отклонено, можно получить состояние кнопки утаивания, использование [[предупреждает suppressionButton] состояние] и хранит результат в пользовательских значениях по умолчанию, например. Эта установка может тогда быть проверена прежде, чем показать предупреждение снова. По умолчанию кнопка утаивания расположена ниже информативного текста, и выше вспомогательного представление (если таковые имеются) и предупредительные кнопки, и выровнена по левому краю с информативным текстом. Однако, не рассчитывайте на размещение этой кнопки, так как это могло бы быть перемещено, если предупредительный пользовательский интерфейс панели изменяется в будущем. При необходимости во флажке в целях кроме текста утаивания рекомендуется создать собственное использование вспомогательного представление.
- (void)setShowsSuppressionButton:(BOOL)flag;
- (BOOL)showsSuppressionButton;
suppressionButton возвращает кнопку утаивания, которая может быть настроена, включая заголовок и начальное состояние. Можно также использовать этот метод для получения состояния кнопки после того, как предупреждение отклонено, который может быть сохранен в пользовательских значениях по умолчанию и проверен прежде, чем показать предупреждение снова. Для показа кнопки утаивания в предупредительной панели необходимо вызвать-setShowsSuppressionButton:YES.
- (NSButton *)suppressionButton;

setAccessoryView: устанавливает вспомогательное представление, выведенное на экран в предупредительной панели. По умолчанию вспомогательное представление расположено ниже информативного текста и кнопки утаивания (если таковые имеются) и выше предупредительных кнопок, выровненных по левому краю с информативным текстом. Если Вы хотите настроить расположение вспомогательного представление, необходимо сначала вызвать - расположение. Посмотрите обсуждение - расположение для получения дополнительной информации.
- (void)setAccessoryView:(NSView *)view;
- (NSView *)accessoryView;
Следующий метод может использоваться, чтобы указать, что предупредительная панель должна сделать непосредственное расположение, переопределив поведение по умолчанию разметки лениво прежде, чем показать панель. Необходимо только вызвать этот метод, если Вы хотите сделать свое собственное расположение после того, как это возвращается. Необходимо вызвать этот метод только после окончания с настройкой NSAlert, включая установку сообщения и информативного текста и добавления кнопок и вспомогательного представление в случае необходимости. Можно сделать изменения макета после этого метода возвраты, в частности для корректировки кадра вспомогательного представление. Обратите внимание на то, что стандартное расположение предупреждения может измениться в будущем, таким образом, настройка расположения должна быть сделана с осторожностью.
- (void)layout;

[предупредите, что setIcon:nil] теперь восстанавливает значок приложения, как задокументировано. До этого изменения, [предупреждают, что setIcon:nil] фактически удалил бы значок из предупреждения.


Если alertWithError: вызывается с нолем NSError, это теперь возвратит предупреждение, выводящее на экран универсальное сообщение об ошибке, а не пустую и запутывающую панель. При нормальных обстоятельствах нулевой параметр такому методу нужно считать программной ошибкой и должен привести к исключению. Однако, так как с ошибками периода выполнения, с которыми этот метод, как предполагается, помогает, не всегда встречаются во время тестирования, и так как проблема уже происходит в контексте пользовательской погрешности нивелировки, о которой должен знать пользователь, выведение на экран предупреждения остается разумным подходом. Ясно проблема должна быть решена путем нахождения и фиксации подсистемы, которой не удается должным образом создать NSError.


NSDockTile

Мы добавили новый класс, NSDockTile, который может использоваться для настройки поведения мозаики прикрепления и для NSApplication и для NSWindow.

NSDockTile имеет размер, соответствующий размеру запоминающего устройства в прикреплении, которое может быть больше, чем текущий размер мозаики и определяется текущим масштабным коэффициентом пространства пользователя. В настоящее время это 128x128 в системе с масштабным коэффициентом пространства пользователя 1.0, но Вы не должны делать предположения об этом размере, остающемся тем же в будущем.

Можно добавить contentView к мозаике прикрепления. Если Вы хотите вовлечь мозаику прикрепления, необходимо сказать мозаике прикрепления отображать, и необходимо нарисовать целую мозаику. Определенное системное действие также заставит мозаику прикрепления изменять размеры и/или отображать. Любое применение идентификационных знаков будет применено после дисплеев мозаики прикрепления.

Вы можете значок мозаика прикрепления с локализованной строкой, представляющей количество. Можно также указать, должна ли мозаика показать значок приложения.

Существующий API для управления мозаикой прикрепления (устанавливающий значок приложения, меню мозаики прикрепления, значок миниокна и минизаголовок окна) не будет заменен мозаикой прикрепления API в этой точке. Будущее направление могло быть должно переместить все управление мозаикой прикрепления в NSDockTile.
@interface NSDockTile : NSObject
- (NSSize)size;
- (void)setContentView:(NSView *)view;
- (NSView *)contentView;
- (void)display;
- (void)setShowsApplicationBadge:(BOOL)flag;
- (BOOL)showsApplicationBadge;
- (void)setBadgeLabel:(NSString *)string;
- (NSString *)badgeLabel;
- (id)owner;
@end
См. <AppKit/NSDockTile.h> и документация для получения дальнейшей информации относительно NSDockTile.


NSApplication

Как NSWindow, NSApplication теперь имеет метод для получения экземпляра мозаики прикрепления. Это позволяет Вам управлять некоторыми аспектами мозаики прикрепления, соответствующей приложению. Для дальнейшего обсуждения посмотрите раздел NSDockTile прямо выше.
- (NSDockTile *)dockTile;
Поскольку приложения основывались на Leopard или позже, значок мозаики прикрепления теперь восстанавливается его состоянию по умолчанию, когда приложение завершается, означая, что метки значка и такой удалены автоматически. Некоторые приложения ранее выполнили это путем вызова RestoreApplicationDockTileImage. Это является несовместимым с NSDockTile на Leopard, таким образом, необходимо изменить приложение при выполнении этого. Если необходимо восстановить значок мозаики прикрепления на Тигре в Leopard совместимый путь, можно сделать так путем вызова - [NSApp setApplicationIconImage:nil].


Отслеживание областей

Мы создали новую модель для отслеживания мыши и обновлений курсора. NSTrackingArea будет инкапсулировать информацию, используемую для создания trackingRects сегодня, включая rect (относительно границ представления), владелец (который получит события, сгенерированные от имени trackingArea), userInfo словарь и опции, как описано ниже. Обратите внимание на то, что NSTrackingArea соответствует NSCoding и NSCopying.

NSTrackingArea может использоваться как традиционный trackingRect, который генерирует mouseEntered и mouseExited события, поскольку мышь приближается и из области. Это может также использоваться для cursorUpdates, который будет отправлен в представление под мышью, когда мышь приблизится или из области. Наконец, это может использоваться для регистрации для mouseMoved событий для всего движения мыши в области. Эти опции могут быть объединены с поразрядным или устанавливать единственный NSTrackingArea, предоставляющий все три возможности.

Можно получить NSTrackingArea, генерировавший mouseEntered или mouseExited использование события - [событие trackingArea].

NSTrackingArea может быть активным только, когда его представление является firstResponder, или когда представление находится в ключевом окне, или когда представление находится в любом окне в активном приложении, или всегда. Некоторые из этих опций не работают с некоторыми типами. Например, Вы не можете запросить cursorUpdates в неактивном приложении.

Как с традиционным trackingRects, можно указать, хотите ли Вы предположить, что мышь внутри или снаружи trackingArea. Кроме того, trackingArea может быть установлен для пребывания в синхронизации с visibleRect представления, тогда делающего одну из наиболее распространенных ситуаций тривиальной. Наконец, в то время как кнопка мыши снижается (т.е. во время перетаскивания мыши), можно запросить mouseEntered и mouseExited события быть сгенерированным.
@interface NSTrackingArea : NSObject <NSCopying, NSCoding>
- (NSTrackingArea *)initWithRect:(NSRect)rect
options:(NSTrackingAreaOptions)options
owner:(id)owner
userInfo:(NSDictionary *)userInfo;
- (NSRect)rect;
- (NSTrackingAreaOptions)options;
- (id)owner;
- (NSDictionary *)userInfo;
@end
См. <AppKit/NSTrackingArea.h> и документация для получения дальнейшей информации относительно NSTrackingArea.

Следующий API был добавлен к NSView:
- (void)addTrackingArea:(NSTrackingArea *)trackingArea;
Представление или другой объект создают NSTrackingArea, затем добавляет его к представлению с помощью этого API. Не предназначенный, чтобы быть переопределенным.
- (void)removeTrackingArea:(NSTrackingArea *)trackingArea;
Этот API используется для удаления trackingArea из представления. Не предназначенный, чтобы быть переопределенным.
- (NSArray *)trackingAreas;
Получите список trackingAreas, добавленных к представлению. Не предназначенный, чтобы быть переопределенным.
- (void)updateTrackingAreas;
Это будет отправлено в представление, когда что-то изменилось, который, вероятно, потребует перерасчета trackingAreas, например изменение в размере visibleRect. Перемещение представления в или из окна не заставит это сообщение быть отправленным, за исключением того, что это будет отправлено один раз, когда представление будет сначала создано и добавляется к окну. Должен быть переопределен представлением, чтобы удалить и добавить его области отслеживания, и должен вызвать супер.

Третья часть API улучшает арбитраж курсора путем добавления метода респондента,-cursorUpdate:. Когда событие NSCursorUpdate получено для окна, оно направляется к представлению под мышью, с помощью нормального hitTesting. Представление под мышью получает cursorUpdate: сообщение. Если представление не реализует cursorUpdate, это ведет себя как другие методы респондента события-: реализация NSResponder отправит его в nextResponder. Если представление реализует cursorUpdate: но решает не обработать определенное событие, оно должно вызвать супер.

Следующий API был добавлен к NSResponder:
- (void)cursorUpdate:(NSEvent *)event;
Переопределение для установки курсора. Если cursorRects допустимы, реализация по умолчанию использует cursorRect. Если никакой cursorRect не вызывает супер, для повышения цепочки респондента.

Следующий API был добавлен к NSEvent и допустим для событий NSMouseEntered и NSMouseExited. Обратите внимание на то, что это не допустимо для событий NSMouseMoved.
- (NSTrackingArea *)trackingArea;
- trackingArea может быть отправлен NSMouseEntered, NSMouseExited или событию NSCursorUpdate. Это не допустимо для события NSMouseMoved. Если событие было сгенерировано trackingRect старого стиля,-trackingArea возвратит ноль.


Мы исправили ошибку в интерпретации флага assumeInside для отслеживания rects добавленный через - [NSView addTrackingRect:owener:userData:assumeInside:]. На Тайгере и предыдущем, передающем YES для assumeInside флаг привел к противоречивым результатам. Если мышь была первоначально вне отслеживания rect, когда отслеживание rect было добавлено, никакое событие не было сгенерировано, и mouseEntered событие было иногда сгенерировано, когда мышь ввела отслеживание rect через последующий mouseMoved. Если мышь будет первоначально вне отслеживания rect, на Leopard, передавая YES для флага assumeInside заставит mouseExited событие быть сгенерированным. mouseEntered будет сгенерирован, когда мышь введет отслеживание rect, если это было первоначально снаружи. Если это новое поведение вызывает проблему для Вашего приложения, можно получить поведение Тайгера путем установки пользовательского значения по умолчанию NSTigerBehaviorForTrackingRects в YES.


NSEvent

Мы добавили, что методы для преобразования между NSEvent и углеродом EventRef.-eventRef допустимы для всех событий и возвращают EventRef, соответствующий NSEvent. EventRef сохраняется NSEvent, так будет допустимо, пока NSEvent допустим, и будет выпущен, когда освобожден NSEvent. Можно использовать RetainEvent для расширения времени жизни EventRef с соответствующим ReleaseEvent, когда Вы сделаны с ним. Если не будет никакого EventRef, соответствующего NSEvent, то-eventRef возвратит NULL. +eventWithEventRef: возвращает автовыпущенное соответствие NSEvent EventRef. Когда NSEvent освобожден, EventRef сохраняется NSEvent и будет выпущен. Если нет никакого соответствия NSEvent EventRef, +eventWithEventRef: возвратит ноль.
- (const void * /* EventRef */)eventRef;
+ (NSEvent *)eventWithEventRef:(const void * /* EventRef */)eventRef;
Мы также добавили методы для преобразования между NSEvent и CGEventRef.-CGEvent допустим для всех событий и возвращает автовыпущенный CGEventRef, соответствующий NSEvent. Если Вы хотите управлять временем жизни CGEventRef, необходимо сохранить его. Если не будет никакого CGEventRef, соответствующего NSEvent, то-CGEvent возвратит NULL. + eventWithCGEvent: возвращает автовыпущенное соответствие NSEvent CGEventRef. Если нет никакого соответствия NSEvent EventRef, +eventWithCGEvent: возвратит ноль. Преобразование от NSEvent до CGEventRef может быть с потерями, и Вы не должны пытаться использовать погрузочно-разгрузочное оборудование ключевого события, предоставленное CGEventRef.
- (CGEventRef)CGEvent;
+ (NSEvent *)eventWithCGEvent:(CGEventRef)cgEvent;
Существует теперь метод, чтобы включить или отключить объединение мыши и метод для запросов текущего состояния. Объединение мыши идет по умолчанию.
+ (void)setMouseCoalescingEnabled:(BOOL)flag;
+ (BOOL)isMouseCoalescingEnabled;
Если Вы создадите свое приложение на Leopard, и Ваше приложение устанавливает обработчик событий на целевом использовании монитора события GetEventMonitorTarget, то следившее за развитием событие будет отправлено в обработчик событий, который Вы установили, а не на - [NSApplication sendEvent:]. Поскольку приложения основывались на Тайгере или предыдущий, следившее за развитием событие будет отправлено в sendEvent:. Можно переопределить это поведение по умолчанию установкой NSDispatchMonitoredEvents. Если NSDispatchMonitoredEvents будет то ДА, событие будет отправлено в sendEvent:; если нет, это будет отправлено в установленный обработчик событий.

События NSScrollWheel будут теперь отправлены в окно под мышью, активно ли окно. В предыдущей версии Mac OS X события NSScrollWheel были только отправлены в окно под мышью, если окно имело ключевой фокус, за исключением служебных окон, получивших события NSScrollWheel, даже когда неактивный.


Ключевые эквиваленты

Мы решили проблему, куда события NSKeyUp были отправлены в performKeyEquivalent: если не снизилась командная клавиша. Если бы получатель не проверял тип события на NSKeyDown, эта проблема могла заставить ключевой эквивалент выполняться дважды. Фиксация применяется только к приложениям, основывался на Leopard или позже, для сохранения совместимости на уровне двоичных кодов для любого приложения, которое, возможно, зависело от старого поведения.

Флаги модификатора теперь сохраняются в событиях <esc> NSKeyDown. До этого изменения NSWindow разделил бы флаги модификатора от <esc> ключевого события прежде, чем вызвать-performKeyEquivalent:. Мы не ожидаем, что приложения будут зависеть от этого поведения, но если необходимо проигнорировать флаги модификатора на событиях <esc> keyDown, можно переопределить-performKeyEquivalent: сделать так.

В - [NSWindow sendEvent:] мы теперь отправляем keyDown: первому респонденту, даже если установлен модификатор командной клавиши. Событие NSKeyDown только достигнет этой точки, если это не было распознано как ключевой эквивалент. Один эффект этого изменения состоит в том, чтобы включить пользовательские записи привязки клавиш с модификаторами командной клавиши. Изменение применяется только к приложениям, основывался на Leopard или позже, для сохранения совместимости на уровне двоичных кодов для любого приложения, которое, возможно, зависело от старого поведения.

NSApplication теперь отправляет событие клавиши Ctrl в performKeyEquivalent: прежде, чем отправить keyDown: событие через цепочку респондента. Это позволяет событиям клавиши Ctrl использоваться в качестве эквивалентов клавиши меню более надежно. До этого изменения событие клавиши Ctrl, имевшее emacs привязку клавиш, не будет отправлено в performKeyEquivalent: если фокус был в NSTextView.


Перетаскивание

- [NSDraggingInfo slideDraggedImageTo:] теперь реализован для поведения, как задокументировано. Это изменение включено только для приложений, основывался на Leopard или позже избежать изменять поведение более старых двоичных файлов способами, которые могут быть неправильными.

- draggingEnded теперь реализован для приложений, соединенных на Leopard или позже.


NSDatePicker

Режим NSDatePicker - Range

NSDatePicker теперь реализует существующий выбор диапазона дат API для миникалендарного средства выбора даты стиля. Это включено путем вызова setDatePickerMode: и передача в NSRangeDateMode. Диапазон представлен датой начала (NSDate; доступный через dateValue) и временной интервал (NSTimeInterval; доступный через timeInterval). Если средство выбора даты является средством выбора даты стиля текстового поля, setDatePickerMode: неэффективно, и timeInterval возвращается 0.0 как прежде. Если средство выбора даты находится в NSSingleDateMode, то timeInterval всегда возвращается 0.0.

Диапазоны даты могут быть выбраны в миникалендарном интерфейсе путем перетаскивания через календарные дни или путем щелчка при нажатой клавише Shift. Месяцы календаря будут также совершенствоваться или отступать, поскольку мышь перетаскивается ниже или выше области, где календарные дни выведены на экран.

NSDatePicker - Маленькие и мини-размеры

Стили текстового поля NSDatePicker теперь поддерживают небольшие и мини-размеры элемента управления через-setControlSize: метод. Однако это только влияет на размер внутренней ячейки степпера. Размер текстового поля определяется размером его шрифта и числом выведенных на экран компонентов даты.

NSDatePicker - Текстовое поле только разрабатывает

NSDatePicker теперь поддерживает третий стиль: NSTextFieldDatePickerStyle. Это идентично NSTextFieldAndStepperDatePickerStyle каждым способом, кроме него не выводит на экран степпер.

NSDatePickerCell - Производительность создания

Скорость создания NSDatePickerCell была значительно улучшена, решительно сократив количество NSDateFormatters, создаваемого внутренне.

NSDatePicker - Улучшения арифметики дат

Реализация арифметики дат NSDatePickerCell изменилась существенно в Leopard, отказываясь от использования устаревшего класса NSCalendarDate (который только поддерживает Григорианский календарь и приводит к неточным результатам для дат в удаленном прошлом - например, в течение многих лет приблизительно 1500) в пользу полностью современной находящейся в NSCalendar реализации, подкрепленной библиотечными подпрограммами ICU. Это устраняет значительные проблемы редактирования для дат Григорианского календаря при обеспечении существенных улучшений локализации для негригорианских календарей.


Текст

Новые форматы текстового документа

Текстовая система теперь имеет поддержку чтения и записи и OASIS, Открытый формат документа Текста документа и Office ECMA Открывают формат текстового документа XML. AppKit/NSAttributedString.h имеет две новых константы для этого, NSOfficeOpenXMLTextDocumentType и NSOpenDocumentTextDocumentType./usr/bin/textutil команда была обновлена для поддержки обоих форматов.

Импорт NSAttributedString HTML

Начиная с Тигра NSAttributedString использовал WebKit для всего импорта документов HTML (но не для экспорта). Так как загрузка документа WebKit не ориентирована на многопотоковое исполнение, это не было безопасно использовать на фоновых потоках. Для приложений, соединенных на Leopard и позже, если NSAttributedString используется для импорта документов HTML о вторичном потоке, использование WebKit будет передано основному потоку через performSelectorOnMainThread:withObject:waitUntilDone:. Это делает такое использование ориентированным на многопотоковое исполнение, но оно требует, чтобы основной поток выполнил цикл выполнения в одном из общих режимов. Это поведение может быть переопределено путем установки NSRunWebKitOnAppKitThread по умолчанию в любой YES (для получения нового поведения независимо от связи) или НЕ (для получения старого поведения независимо от связи).

В версиях до Leopard импорт NSAttributedString HTML установил бы NSBackgroundColorDocumentAttribute в [NSColor whiteColor] в случаях, в которых HTML не указывал цвет фона. Это будет продолжать быть истиной для приложений, соединенных на версиях системы до Leopard, но на Leopard и позже, для приложений, соединенных на Leopard и позже, никакой NSBackgroundColorDocumentAttribute не будет установлен в этих случаях.

NSMutableAttributedString отмечают

Метод - [NSMutableAttributedString readFromURL:options:documentAttributes:error:], как ожидают, заменит текст получателя с содержанием желаемого файла. (Состояния документации: «Устанавливает содержание получателя от файла в URL».)

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

Сценарии NSTextStorage

Для приложений, соединенных на Leopard или позже, мы теперь проверяем на нулевой шрифт в сценариях вызовов и обрабатываем его как Helvetica 12. Это влияет на шрифт вызовов, имя шрифта, fontSize, setFontName: и setFontSize:.


Расположение состоящее из нескольких несмежных участков

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

Расположение состоящее из нескольких несмежных участков не включено автоматически, потому что прямые клиенты NSLayoutManager обычно полагались на предыдущее поведение - например, путем принуждения расположения для данного диапазона глифа, и затем предположения, что были бы поэтому размечены предыдущие глифы. Клиенты, использующие NSLayoutManager только косвенно - например, те, кто использует NSTextView, непосредственно не вызывая базового менеджера по расположению - могут обычно включать расположение состоящее из нескольких несмежных участков без труда. Клиентское использование NSLayoutManager непосредственно должно будет исследовать их использование перед включением расположения состоящего из нескольких несмежных участков.

Методы, непосредственно касавшиеся расположения состоящего из нескольких несмежных участков, следующие:
- (void)setAllowsNonContiguousLayout:(BOOL)flag;
- (BOOL)allowsNonContiguousLayout;
- (BOOL)hasNonContiguousLayout;
Первое позволяет расположению состоящему из нескольких несмежных участков быть включенным и выключенным, и второе исследует состояние той установки. Обратите внимание на то, что включение флага разрешает, но не требует, чтобы менеджер по расположению использовал расположение состоящее из нескольких несмежных участков, и это может фактически принять решение не сделать так в зависимости от конфигурации менеджера по расположению. Кроме того, могут быть времена, в которые нет никакого расположения состоящего из нескольких несмежных участков, такой как тогда, когда расположение завершено; третий метод позволяет менеджеру по расположению сообщать об этом клиентам.

Кроме того, существует много новых методов, которые особенно полезны при работе с расположением состоящим из нескольких несмежных участков. Ранее, генерация глифа и расположение были неявными побочными эффектами вызовов, запрашивающих ту информацию. Это все еще имеет место, но с возможностью расположения состоящего из нескольких несмежных участков не всегда очевидно, какая часть документа будет затронута. Новые методы позволяют этому быть указанным явно, несмотря на то, что менеджер по расположению сохраняет право генерировать глифы или выполнить расположение для большей части документа как надлежащее. В частности если расположение состоящее из нескольких несмежных участков не будет использоваться, то затронутый диапазон будет всегда уходиться корнями к началу документа.
- (void)ensureGlyphsForCharacterRange:(NSRange)charRange;
- (void)ensureGlyphsForGlyphRange:(NSRange)glyphRange;
- (void)ensureLayoutForCharacterRange:(NSRange)charRange;
- (void)ensureLayoutForGlyphRange:(NSRange)glyphRange;
- (void)ensureLayoutForTextContainer:(NSTextContainer *)container;
- (void)ensureLayoutForBoundingRect:(NSRect)bounds inTextContainer:(NSTextContainer *)container;

Новая реализация NSLayoutManager

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

Например, setCharacterIndex:forGlyphAtIndex: номинально позволяет произвольное отображаться между глифом и индексами символа. Это фактически никогда не имело место; всегда были неявные ограничения, в том смысле, что другая функциональность NSLayoutManager перестала бы работать в присутствии бессмысленного отображения глифа к символу. Теперь, однако, возможно утвердить ограничения и, в конечном счете, осуществить их путем повышения исключения, когда они нарушены. Основное ограничение - то, что поток глифа никогда может работать относительно символьного потока. Многократные глифы могут отобразиться на отдельный символ или многократные символы к единственному глифу, но все глифы для данного символа должны следовать за всеми глифами для предшествующих символов и предшествовать всем глифам для следующих символов. Глифы, которые иначе не имели бы символа (такого как дефисы) присваиваются символу для самого близкого предыдущего глифа, имеющего символы, и символы, которые иначе не имели бы глифов, присваиваются глифу для самого близкого предыдущего символа, имеющего глифы. Генератор глифа акций и наборное устройство пытаются сохранить непосредственное отображение символа к глифу, по мере возможности, включением дополнения записи NSNullGlyph; например, если бы символы 'f' и 'я' представлен 'fi' лигатурой, тогда поток глифа включал бы 'fi' глиф лигатуры, сопровождаемый нулевым глифом так, чтобы было два глифа для соответствия этих двух символов. Однако это ни не гарантируется, ни требуется в целом.

Основные методы для исследования отображения символьного глифа являются characterIndexForGlyphAtIndex: и новый метод
- (NSUInteger)glyphIndexForCharacterAtIndex:(NSUInteger)charIndex;
это теперь играет симметричную роль. Таким образом characterIndexForGlyphAtIndex: возвращает индекс для первого символа, связанного с указанным глифом и glyphIndexForCharacterAtIndex: возвращает индекс для первого глифа, связанного с указанным символом. Ни в том, ни в другом случае есть ли любой специальный режим для нулевых глифов. В 'fi' случае лигатуры, например, если бы нулевое дополнение используется, то эти методы сообщили бы об идентификационных данных, отображающихся между глифом и индексами символа. Оба метода также принимают индексы вне последнего знака или глифа; они возвращают индекс, экстраполируемый из последнего фактического символа или индекса глифа. Таким образом, если существуют идентификационные данные, отображающиеся между глифом и индексами символа, то оба characterIndexForGlyphAtIndex: и glyphIndexForCharacterAtIndex: будет всегда возвращаться результаты численно равняются их параметрам.

Более сложные методы glyphRangeForCharacterRange:actualCharacterRange: и characterRangeForGlyphRange:actualGlyphRange: с другой стороны действительно примите нулевые глифы во внимание. Например, для рассмотрения 'fi' случая лигатуры снова, если glyphRangeForCharacterRange:actualCharacterRange: должны были быть вызваны с диапазоном символов длины 1 покрытием или 'f' или 'я', получающийся диапазон глифа будет включать и 'fi' глиф и нулевой глиф, и фактический диапазон символов включал бы и 'f' и 'меня', изображают. Аналогично, если characterRangeForGlyphRange:actualGlyphRange: должны были быть вызваны с диапазоном глифа длины 1 покрытием или 'fi' глиф или нулевой глиф, получающийся диапазон символов будет включать и 'f' символ и 'меня', изображают, и фактический диапазон глифа включал бы и 'fi' глиф и нулевой глиф.

Оба метода также имеют специальный режим для диапазонов нулевой длины. Например, в 'fi' случае лигатуры, если glyphRangeForCharacterRange:actualCharacterRange: должны были быть вызваны с диапазоном символов длины 0, прежде чем 'f', результатом будет диапазон глифа нулевой длины перед 'fi' глифом. Однако, если, если glyphRangeForCharacterRange:actualCharacterRange: должны были быть вызваны с диапазоном символов длины 0 между 'f' и 'мной', результатом будет диапазон глифа нулевой длины после нулевого глифа, и фактический диапазон символов был бы диапазоном нулевой длины после того, как 'я' изображает. В целом диапазон символов нулевой длины в мультипоследовательности символов отображается на диапазон глифа нулевой длины после того, как последний глиф связался с последовательностью с нулевой длиной фактический диапазон символов после последнего знака последовательности. То же описание применяется к characterRangeForGlyphRange:actualGlyphRange: Обмен ролью символа и индексов глифа.

В целом символ и индексы глифа теперь играют симметричную роль в отображении символьного глифа и glyphRangeForCharacterRange:actualCharacterRange: и characterRangeForGlyphRange:actualGlyphRange: ведите себя симметрично друг другу. Оба glyphRangeForCharacterRange:actualCharacterRange: и characterRangeForGlyphRange:actualGlyphRange: также примите индексы вне последний знак или глиф, но результаты, которые они возвращают, являются усеченными после последнего знака или глифа вместо того, чтобы быть экстраполируемым. Это соответствует их роли в, например, вычисляя диапазоны выделенных символов или глифов.

Другим аспектом разъясненного NSLayoutManager является аннулирование. Ранее между твердым и мягким аннулированием расположения было различие; ожидалось, что любое изменение в тексте вызовет твердое аннулирование области, фактически изменившейся, сопровождаемый мягким аннулированием всех последующих частей документа, так как они могли бы переместиться вследствие изменения. Обычно это происходило бы автоматически в результате сообщений изменения, отправленных текстовым хранением менеджеру по расположению, но любой бывший должный вызвать аннулирование расположения вручную должен был уважать различие. В Leopard, однако, что больше не требуется различие; твердое аннулирование расположения является единственным необходимым видом, и эквивалент мягкого аннулирования располагается автоматически. В результате новый метод
- (void)invalidateLayoutForCharacterRange:(NSRange)charRange actualCharacterRange:(NSRangePointer)actualCharRange;
был предоставлен для замены существующего invalidateLayoutForCharacterRange:isSoft:actualCharacterRange: как эквивалент последнего с мягким набором флага к НЕТ. Для кода, предназначенного для работы Leopard только может использоваться новый метод. Для кода, предназначенного для работы и Leopard и на Тайгера, старый метод должен использоваться как прежде, в двух вызовах, сначала с мягким набором флага к нет, для диапазона, фактически изменяемого, и впоследствии с мягким набором флага к ДА, для диапазона после измененной части, до конца документа.

Кроме того, менеджер/наборное устройство расположения, которого коммуникация была разъяснена путем добавления нового метода NSLayoutManager для использования наборного устройства, чтобы позволить ему указывать явно, когда части потока глифа зависят от расположения - например, потому что им вставили дефисы. Вызовы наборного устройства
- (void)invalidateGlyphsOnLayoutInvalidationForGlyphRange:(NSRange)glyphRange;
чтобы указать, что определенный диапазон глифов зависим от расположения, и поэтому глифы должны быть лишены законной силы в следующий раз, когда их расположение лишено законной силы, так, чтобы они были регенерированы прежде чем быть размеченным снова.

Кроме того, новый объемный менеджер по NSLayout метод был добавлен, чтобы позволить наборному устройству устанавливать расположения для многих диапазонов глифа сразу:
- (void)setLocations:(NSPointArray)locations
startingGlyphIndexes:(NSUInteger *)glyphIndexes
count:(NSUInteger)count
forGlyphRange:(NSRange)glyphRange;
Все индексы глифа должны лечь в указанном диапазоне глифа, первый из них должен быть равен glyphRange.location, и остаток должен увеличиться монотонно. Каждое расположение будет установлено как расположение для диапазона, начинающегося в соответствующем индексе глифа и продолжающегося до последующего индекса глифа, или до конца диапазона глифа для последнего расположения. Таким образом этот метод эквивалентен вызову setLocation:forStartOfGlyphRange: для ряда диапазонов, покрывающих все глифы в glyphRange.

NSLayoutManager setShowsInvisibleCharacters:

- setShowsInvisibleCharacters: метод теперь функционален и пробельные символы замены или с LOZENGE U+25CA или с FULL STOP U+002E в зависимости от доступности глифа шрифта рендеринга.

Потокобезопасность NSLayoutManager

Вообще говоря, данный менеджер по расположению (и связанные объекты) не должен использоваться больше чем на одном потоке за один раз. Большинство менеджеров по расположению будет использоваться на основном потоке, так как это - основной поток, на котором их текстовые представления выводятся на экран, и так как фоновое расположение происходит на основном потоке. Если это предназначается, что менеджер по расположению должен использоваться на фоновом потоке, сначала удостоверьтесь, что текстовые представления, связанные с тем менеджером по расположению (если таковые имеются), не будут выведены на экран, в то время как менеджер по расположению используется на фоновом потоке, и во-вторых, выключите фоновое расположение для того менеджера по расположению, в то время как это используется на фоновом потоке.

Разные новые методы NSLayoutManager

Соглашаться с существующим defaultLineHeightForFont: NSLayoutManager предал гласности
- (CGFloat)defaultBaselineOffsetForFont:(NSFont *)theFont;
чтобы позволить клиентам получать базовую линию смещает подходящий для определенного шрифта в определенном менеджере по расположению, учитывая его поведение наборного устройства и другие настройки.

Кроме того, это также предало гласности методы
- (BOOL)usesFontLeading;
- (void)setUsesFontLeading:(BOOL)flag;
то управление, будет ли менеджер по расположению использовать продвижение, как указано шрифтом. Значение по умолчанию ДА, так как в большинстве случаев это является надлежащим, но существуют некоторые случаи, где это не; например, для текста UI фиксированное продвижение часто указывается инструкциями по расположению UI. Все три из этих методов являются доступным возвращением к Mac OS X 10.2.

Некоторые дополнения были сделаны к NSLayoutManager временными методами атрибута, чтобы быть параллельными большему количеству методов атрибута NSAttributedString.
- (id)temporaryAttribute:(NSString *)attrName atCharacterIndex:(NSUInteger)location effectiveRange:(NSRangePointer)range;
- (id)temporaryAttribute:(NSString *)attrName atCharacterIndex:(NSUInteger)location
longestEffectiveRange:(NSRangePointer)range inRange:(NSRange)rangeLimit;
- (NSDictionary *)temporaryAttributesAtCharacterIndex:(NSUInteger)location
longestEffectiveRange:(NSRangePointer)range inRange:(NSRange)rangeLimit;
- (void)addTemporaryAttribute:(NSString *)attrName value:(id)value forCharacterRange:(NSRange)charRange;
Существует новый метод NSLayoutManager для получения точек вставки оптом для данного фрагмента строки. Ранее rects, используемые для индикатора точки вставки, были получены путем вызова rectArrayForCharacterRange:withinSelectedCharacterRange:inTextContainer:rectCount: или основанный на глифе эквивалент с диапазоном нулевой длины; это все еще доступно, но это имеет ограничение, что только одна точка вставки может быть получена за один раз. Существует много случаев, в которых хочет получить многократные точки вставки сразу - например, когда каждый пытается переместиться от одного до другого. Метод
- (NSUInteger)getLineFragmentInsertionPointsForCharacterAtIndex:(NSUInteger)charIndex
alternatePositions:(BOOL)aFlag
inDisplayOrder:(BOOL)dFlag
positions:(CGFloat *)positions
characterIndexes:(NSUInteger *)charIndexes;
позволяет клиентам получать все точки вставки для фрагмента строки в одном вызове. Вызывающая сторона указывает фрагмент строки путем предоставления одного индекса символа в нем и может выбрать, получить ли основные или альтернативные точки вставки, и должны ли они быть в логическом или в порядке дисплея. Возвращаемое значение является числом возвращенных точек вставки. Каждый указатель передал в, должен или быть NULL или иначе указать на достаточную память для содержания стольких же элементов, сколько существуют точки вставки во фрагменте строки (который не может быть больше, чем число символов + 1). Буфер позиций передал в, будет заполнено в позициями точек вставки, в порядке, указанном, и буфер charIndexes передал в, будет заполнено в соответствующими индексами символа. Позиции указывают поперечное смещение относительно источника rect's фрагмента строки. Внутреннее кэширование используется, чтобы гарантировать, что повторные вызовы к этому методу для того же фрагмента строки (возможно с отличающимися значениями для других параметров) не будут значительно более дорогими, чем единственный вызов.

Наконец, существует новый метод делегата NSLayoutManager,
- (NSDictionary *)layoutManager:(NSLayoutManager *)layoutManager
shouldUseTemporaryAttributes:(NSDictionary *)attrs
forDrawingToScreen:(BOOL)toScreen
atCharacterIndex:(NSUInteger)charIndex
effectiveRange:(NSRangePointer)effectiveCharRange;
Это отправляется, когда менеджер по расположению рисует и должен решить, использовать ли временные атрибуты или нет. Делегат возвращает словарь временных атрибутов, которые будут использоваться, или ноль для подавления использования временных атрибутов в целом. effectiveCharRange параметр и в и диапазон измерений ссылкой для тех атрибутов. Поведение по умолчанию, если этот метод не реализован, состоит в том, чтобы использовать временные атрибуты только при рисовании на экран, таким образом, реализация для соответствия того поведения возвратила бы attrs, если toScreen является YES и ноль иначе, не изменяясь effectiveCharRange.

NSTextView

Новое свойство, allowedInputSourceLocales, управляет источниками ввода текста, включенными для экземпляра NSTextView. К свойству могут получить доступ следующие методы доступа. Существует meta идентификатор локали, NSAllRomanInputSourcesLocaleIdentifier, доступный для указания входных источников, ограничивающихся для римского редактирования сценария.
- (NSArray *)allowedInputSourceLocales;
- (void)setAllowedInputSourceLocales:(NSArray *)localeIdentifiers;
Команда - удаляет, теперь связывается с-deleteToBeginningOfLine:.


NSTextView находят панель

Стандартная панель находки для NSTextView теперь отслеживает последний раз используемый, находят и заменяют строки, и выводит на экран их пользователю в NSComboBox.

В дополнение к связывающимся строкам поиска через область монтажа находки стандартная панель находки для NSTextView теперь также передает метаданные параметра поиска, включая чувствительность к регистру и опции соответствия подстроки. Эти метаданные сохранены в plist, поскольку NSFindPanelSearchOptionsPboardType оценивают глобальной областью монтажа находки. Также, приложения сторонних производителей могут сохранить дополнительные ключи в этом plist для передачи дополнительных метаданных, как желаемый поддерживать различные параметры поиска, характерные для панелей находки многих сторонних приложений. NSTextView.h содержит AppKit-предоставленные ключи и значения.

NSTextView находят индикатор

NSTextView теперь поддерживает новую индикацию стиля ромба относительно результатов находки с новым методом
- (void)showFindIndicatorForRange:(NSRange)charRange;
это заставляет временный индикатор или индикаторы появляться вокруг видимой части (ей) указанного диапазона. Индикаторы автоматически исчезнут после определенного периода времени, или когда метод вызывают снова, или когда любое из многих изменений происходит с представлением (таким как изменения в тексте, чтобы просмотреть размер или просмотреть позицию). Обратите внимание на то, что этот метод самостоятельно не прокручивает указанный диапазон, чтобы быть видимым; любая желаемая прокрутка должна быть сделана, прежде чем этот метод вызывают, сначала потому что метод действует только на видимую часть указанного диапазона, и второй, потому что прокрутка заставит индикаторы исчезать. Вызов этого метода с диапазоном нулевой длины будет всегда удалять любые существующие индикаторы.

Разные новые методы NSTextView

NSTextView включает много новых флагов для управления его поведением.
- (void)setDisplaysLinkToolTips:(BOOL)flag;
- (BOOL)displaysLinkToolTips;
- (void)setAllowsImageEditing:(BOOL)flag;
- (BOOL)allowsImageEditing;
- (void)setAutomaticQuoteSubstitutionEnabled:(BOOL)flag;
- (BOOL)isAutomaticQuoteSubstitutionEnabled;
- (void)toggleAutomaticQuoteSubstitution:(id)sender;
- (void)setAutomaticLinkDetectionEnabled:(BOOL)flag;
- (BOOL)isAutomaticLinkDetectionEnabled;
- (void)toggleAutomaticLinkDetection:(id)sender;
Флаг для отображения подсказок ссылки управляет, предоставит ли текстовое представление автоматически место назначения ссылки как подсказка для текста с атрибутом ссылки. Значением по умолчанию для этого является YES; клиенты, не желающие этого, должны явно отключить его. В связанном изменении NSTextView больше не будет автоматически открывать файл: URLs в ссылках; по умолчанию, файл: URLs будет показан в Средстве поиска. Клиенты, желающие переопределять это, должны реализовать textView:clickedOnLink:atIndex: (как делегат) или clickedOnLink:atIndex: (в подклассе).

Флаг редактирования изображение управляет, должны ли текстовые присоединения, представляющие изображения, позволить их содержанию быть отредактированным встроенное в тексте, если они поддерживают это, и текстовое представление доступно для редактирования. Текстовые присоединения акций в настоящее время не имеют поддержки этой функции, но могут сделать так в будущем.

Автоматическая замена кавычки, когда это включено, заставляет кавычки ASCII и апострофы быть автоматически замененными на контексте - и языковозависимое основание с более типографским способом точными символами. Автоматическое обнаружение ссылки, когда это включено, заставляет строки, представляющие URLs, введенный в представлении быть автоматически превращенными в ссылки к тому URLs. Кроме того, существующее умное скопировать/вставить функциональность имеет недавно разглашенный метод действия,
- (void)toggleSmartInsertDelete:(id)sender;
В поддержку автоматического обнаружения ссылки существует новый метод на NSAttributedString,
- (NSURL *)URLAtIndex:(NSUInteger)location effectiveRange:(NSRangePointer)effectiveRange;
если текст в расположении, кажется, строка, представляющая URL, это возвращает URL из содержания текста в данном расположении. Если никакой очевидный URL не найден, диапазон измерений является диапазоном строки URL, или текста не-URL.

Для соглашений с новой функциональностью точки вставки NSLayoutManager существует новый метод NSTextView
- (NSUInteger)characterIndexForInsertionAtPoint:(NSPoint)point;
который берет точку, в поле зрения координирует и возвращает индекс символа, подходящий для размещения выбора нулевой длины для точки вставки, когда мышь по данной точке. Методы протокола NSTextInput обычно не подходят для использования кроме связанных с методами ввода текста и методом протокола NSTextInput characterIndexForPoint: не исключение; это предназначается только для использований, связанных с методами ввода текста. Новый characterIndexForInsertionAtPoint: должен использоваться для точек вставки, связанных с щелчками мышью, перетащить события, и т.д. В других целях лучше использовать методы NSLayoutManager, как продемонстрировано во множестве примеров кода.

Существует новый метод делегата NSTextView
- (NSMenu *)textView:(NSTextView *)view menu:(NSMenu *)menu forEvent:(NSEvent *)event atIndex:(NSUInteger)charIndex;
который позволяет клиентам управлять контекстным меню через делегата, вместо того, чтобы иметь необходимость разделить на подклассы и переопределить menuForEvent:. Параметр меню является контекстным меню, которое иначе обеспечил бы NSTextView, и charIndex параметром является индекс символа, по которому щелкнули правой кнопкой.

Наконец, существует новый тип области монтажа, используемый NSTextView при копировании и вставке множественных выборов.
NSString *NSMultipleTextSelectionPboardType;
Этот тип используется только, когда область монтажа представляет множественный выбор. Содержание для этого типа должно быть массивом NSNumbers, один для каждого поддиапазона выбора, указав число абзацев, содержавшихся в каждом поддиапазоне. Содержание простого или обогащенного текста области монтажа будет строкой, представляющей содержание каждого поддиапазона, связанного с концами абзаца, промежуточными их (где они уже не заканчивают в концах абзаца); это объединилось с количествами абзаца в NSMultipleTextSelectionPboardType, достаточно для определения, какие части содержания связаны с который поддиапазон. Этот механизм был выбран, потому что это непротиворечивое через простой и обогащенный текст, и через различные представления обогащенного текста. Количества могут быть проверены на непротиворечивость путем сравнения общего количества абзацев в содержании простого или обогащенного текста области монтажа с общим количеством чисел в массиве NSMultipleTextSelectionPboardType; если эти два не соответствуют, то содержание NSMultipleTextSelectionPboardType должно быть проигнорировано.

Стили дополнительного списка

У Тигра форматы маркера NSTextList поддерживали следующие ключевые слова спецификатора нумерации: десятичное число, более низкий римлянин, верхний римлянин, более низкая альфа, верхняя альфа, более низко-шестнадцатеричная, верхне-шестнадцатеричная, и восьмеричная. Кроме того, это также поддерживало следующие постоянные ключевые слова спецификатора: поле, проверьте, окружите, ромб, диск, дефис, квадрат. Эти ключевые слова выровненные соответствующих черновых CSS3 значений типа стиля списка. В Leopard форматы маркера NSTextList также поддерживают следующие дополнительные ключевые слова спецификатора нумерации: десятичный начальный нуль, более низкий греческий язык, верхний греческий язык, более низкий русский язык, верхний русский язык, cjk-идеограмма, hiragana, hiragana-iroha, katakana, katakana-iroha, cjk-earthly-branch, и cjk-heavenly-stem.

NSTypesetter

Существует новый NSLayoutManager-интерфейс API, заменяющий-layoutGlyphsInLayoutManager:startingAtGlyphIndex:maxNumberOfLineFragments:nextGlyphIndex:. Когда его установкой-allowsNonContiguousLayout является YES, NSLayoutManager отправляет это сообщение в наборное устройство.
- (NSRange)layoutCharactersInRange:(NSRange)characterRange
forLayoutManager:(NSLayoutManager *)layoutManager
maximumNumberOfLineFragments:(NSUInteger)maxNumLines;

Последнее видимое усечение строки

Если все содержание не может вписаться в указанную ограничительную рамку, текстовая Система Какао теперь позволяет последней видимой строке добавлять символ замещающего знака. Поведением можно управлять с-truncatesLastVisibleLine для текстовых ячеек.-lineBreakMode должен быть или NSLineBreakByWordWrapping или NSLineBreakByCharWrapping для этой опции вступить в силу.. Кроме того, флаг NSStringDrawingTruncatesLastVisibleLine может быть указан к NSStringDrawing APIs, которые берут NSStringDrawingOptions. Флаг NSStringDrawingUsesLineFragmentOrigin должен также быть указан для флага усечения для вступления в силу.
- (BOOL)truncatesLastVisibleLine;
- (void)setTruncatesLastVisibleLine:(BOOL)flag;

NSFont

Платформа AppKit больше не сохраняет экземпляры NSFont, и они подвергаются стандарту, сохраняют/выпускают схему. Для отладки цели можно использовать ключ NSDisableFontDeallocation. Когда значение ДА, экземпляры шрифта не освобождены. Кроме того, установкой NSFontDebugLevel к не0 значениям в отношении пространства памяти, ранее занятого NSFont, более настойчиво предъявляют претензии, чтобы позволить находить сверхвыпущенные экземпляры легко.

NSFontDescriptor

Существует новый API-matchingFontDescriptorWithMandatoryKeys соответствия дескриптора шрифта: это возвращает самый подходящий нормализованный экземпляр.

Мы позволяем следующий атрибут и ключи словаря. Они позволяют приложениям создавать дескрипторы шрифта, имеющие настройки функции шрифта не по умолчанию.
NSString *NSFontFeatureSettingsAttribute;
NSString *NSFontFeatureTypeIdentifierKey;
NSString *NSFontFeatureSelectorIdentifierKey;

NSFontManager

NSFontManager теперь имеет следующие 4 новых открытых метода. Можно использовать-currentFontAction и-convertFontTraits: определить действие-convertFont: выполнил бы. С новыми методами доступа для целевого свойства можно теперь перенаправить цель для действия, вызванного-sendAction методом.
- (NSFontAction)currentFontAction;
- (NSFontTraitMask)convertFontTraits:(NSFontTraitMask)traits;
- (void)setTarget:(id)aTarget;
- (id)target;

Обработка RTF

Писатель RTF теперь предпочитает кодировки шрифта Microsoft по сценариям Mac. Сгенерированные данные RTF имеют намного лучшую совместимость с реализациями читателя RTF на Windows.


NSInputManager

Автоматическая загрузка пакетов, расположенных в папках InputManagers, теперь официально не поддерживается. Условия для допустимого менеджера по вводу пакет далее сжаты. Эта функциональность, вероятно, будет отключена в будущем выпуске.

1. Допустимая установка теперь ограничивается/Library/InputManagers папкой только. Пакеты в других расположениях тихо проигнорированы.

2. Все файлы в пакете и самой/Library/InputManagers папке должны принадлежать полностью администраторская группа и пользователь. Никакие файлы в пакете не могут иметь группу или другие полномочия записи.

3. Процессы, работающие с полномочием пользователя root (getuid () == 0 или geteuid () == 0), не могут загрузить менеджера по вводу пакета.

4. Процессы, работающие с полномочием группы колеса, не могут загрузить менеджера по вводу пакета.

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

6. Процесс не должен быть испорчен путем изменения пользователя, или ID группы (проверил issetugid ()).

7. Никакие 64-разрядные процессы не могут загрузить менеджеров по вводу пакета.

Протокол NSTextInputClient

Существует новый протокол, NSTextInputClient, для объектов, готовых участвовать в системе Ввода текста Какао. Протокол заменяет старый протокол, NSTextInput, и позволяет соответствовать, объекты использовать в своих интересах различную систему предоставили функциональности. Платформа Какао использует новый протокол каждый раз, когда это принято объектом респондента. Для подклассов NSTextView предпочтен новый протокол, если любой из методов NSTextInput не переопределяется, и ни один из новых методов не переопределяется.

Существует теперь приписанное свойство строки общественности, NSMarkedClauseSegmentAttributeName, для передачи сегментов пункта в отмеченном тексте.


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

Проверка правописания является новой функцией, связанной с существующей функциональностью проверки правописания. Любой сервер проверки правописания имеет опцию также обеспечения проверки правописания путем реализации метода делегата NSSpellServer
- (NSRange)spellServer:(NSSpellServer *)sender checkGrammarInString:(NSString *)stringToCheck
language:(NSString *)language details:(NSArray **)details;
Возвращаемое значение предназначается, чтобы быть диапазоном следующего предложения или другого грамматического модуля, содержащего разделы, которые будут отмечены для грамматики, так как проверка правописания обычно должна выполняться предложение за предложением. Подробный параметр дополнительно возвращает ссылкой массив словарей, каждый описывающий грамматическую проблему обнаружил в предложении (так как единственное предложение может содержать больше чем одну проблему). В этих словарях будут распознаны следующие ключи:
NSString *NSGrammarRange;
NSString *NSGrammarUserDescription;
NSString *NSGrammarCorrections;
Значение для ключа NSGrammarRange должно быть NSValue, содержащим NSRange, поддиапазон диапазона предложения, используемого в качестве возвращаемого значения, расположение которого должно быть смещением с начала предложения - так, например, NSGrammarRange для первых четырех символов полного диапазона предложения должен быть {0, 4}. Значение для ключа NSGrammarUserDescription должно быть NSString, содержащим описательный текст о том диапазоне, чтобы быть представленным непосредственно пользователю; это предназначается, что пользовательское описание должно предоставить достаточно информации, чтобы позволить пользователю исправлять проблему. Значение может также быть предоставлено для ключа NSGrammarCorrections, состоя из NSArray Нсстрингса, представляющего потенциальные замены для исправления проблемы, но ожидается, что это может не быть доступно во всех случаях. Рекомендуется, чтобы NSGrammarUserDescription были предоставлены во всех случаях; при любых обстоятельствах или NSGrammarUserDescription или NSGrammarCorrections должны быть предоставлены для чего-то, чтобы быть представленными пользователю. Если NSGrammarRange не будет присутствовать, то он, как будет предполагаться, будет равен полному диапазону предложения. Дополнительные ключи могут быть добавлены в будущих выпусках.

Соответствующий клиентский метод на NSSpellChecker
- (NSRange)checkGrammarOfString:(NSString *)stringToCheck
startingAt:(NSInteger)startingOffset
language:(NSString *)language
wrap:(BOOL)wrapFlag
inSpellDocumentWithTag:(NSInteger)tag
details:(NSArray **)details;
подобный существующим методам проверки правописания. NSSpellChecker также имеет новый метод,
- (NSArray *)availableLanguages;
подходящий для использования с существующим - язык и-setLanguage:. Это возвращает список доступных языков для проверки правописания в формах, указанных серверами написания; обычно они будут сокращениями языка, такими как «франк» или «en_GB» вида, используемого NSBundle для идентификации локализаций.-setLanguage: метод предпочтительно принимает один из них, но попытается найти неточное соответствие для любого значения, которое это дано. Также новый методы NSSpellChecker
- (void)learnWord:(NSString *)word;
- (BOOL)hasLearnedWord:(NSString *)word;
- (void)unlearnWord:(NSString *)word;
это предоставляет клиентский доступ к изучению и забытию функций программы проверки правописания. learnWord: метод не является фактически новым, но является недавно общедоступным; это всегда присутствовало на NSSpellChecker. Другие методы являются новыми, но был предыдущий эквивалент unlearnWord: названный forgetWord:.

NSTextView имеет методы для управления его использованием проверки правописания,
- (void)setGrammarCheckingEnabled:(BOOL)flag;
- (BOOL)isGrammarCheckingEnabled;
- (void)toggleGrammarChecking:(id)sender;
Если проверка правописания будет включена, то она будет выполняться рядом с проверкой правописания, каждый раз, когда текстовое представление проверяет орфографию, или постоянно или вручную.

Средние значения также теперь предоставлены для управления дисплеем написания и индикаторов грамматики на тексте, используемом для выделения частей текста, отмечающихся для проблем грамматики или написания. Эти области обозначены временным атрибутом на менеджере по расположению, с помощью ключа
NSString *NSSpellingStateAttributeName;
Этот ключ является доступным возвращением к Mac OS X 10.2, но изменилась его интерпретация. Ранее, любое ненулевое значение заставило бы индикатор написания быть выведенным на экран. Для Mac OS X 10.5, (целочисленное) значение будет обработано как составляемый из следующих флагов:
enum {
NSSpellingStateSpellingFlag = (1 << 0),
NSSpellingStateGrammarFlag = (1 << 1)
};
Существует новый метод на NSTextView для установки состояния написания, которое могут вызвать клиенты или переопределить подклассификаторы.
- (void)setSpellingState:(NSInteger)value range:(NSRange)charRange;
Этот метод поочередно вызывает новый метод делегата NSTextView,
- (NSInteger)textView:(NSTextView *)textView shouldSetSpellingState:(NSInteger)value range:(NSRange)affectedCharRange;
который позволяет делегату управлять любым изменением в значении состояния написания.


Текст и эффекты изображений: - [NSCell backgroundStyle]

До Leopard Вы, возможно, заметили, что текст бледнеет в выбранных строках табличного представления. Механизм, управлявший этим поведением, к сожалению, был тайным. Таблица установила бы цвет подсветки ячейки к alternateSelectedControlColor и установила бы ячейку, которая будет выделена. Если бы цвет был alternateSelectedControlColor, ячейка тогда анализировала бы свой цвет подсветки, и использовала бы белый текст.

Другой текстовый эффект произошел в приложениях такой как 10.4's Адресная книга. Текст выглядел выгравированным, когда продвинуто металлическая поверхность окна. Это было сделано с пользовательским получением.

Для Leopard этот вид поведения формализован и расширен с помощью API, - [NSCell setBackgroundStyle:]. Это предоставляет ячейке метаданные, которые могут использоваться для принятия хороших решений относительно получения. Существует только четыре возможных стиля фона: легкий, темный, повышенный и пониженный. Большинство фонов легко. Выбранные строки таблицы, для 10,5, темные, таким образом, текст нарисует белый. Металлическая поверхность повышена, таким образом, текст, рисующий непосредственно на ней, должен выглядеть выгравированным. Некоторые поверхности ниже, чем плоскость получения ячейки, когда текст должен выглядеть рельефным.

Существует несколько включенных методов. - [NSCell backgroundStyle] описывает фон, продвинутый в методе - [NSCell drawWithFrame:inView:]. - [NSCell interiorBackgroundStyle] описывает фон, продвинутый в методе - [NSCell drawInteriorWithFrame:inView:]. Каково различие? - [NSCell drawWithFrame:inView:] основной высокоуровневый метод рисования ячейки - он рисует целую ячейку. Один из методов, которые это вызывает, - [NSCell drawInteriorWithFrame:inView:], который рисует внутреннее содержание как текст и изображения. Если кнопка нарисует внешнюю панель, то - [NSCell backgroundStyle] опишет поверхность, которую привлекает кнопка, в то время как - [NSCell interiorBackgroundStyle] опишет поверхность самой внешней панели.

Рассмотрите кнопки закладок в Safari 3.0. Это - стандартный стиль кнопки, доступной в Интерфейсном Разработчике. Кнопки помещаются в поверхность металлического выхода, повышенную относительно кнопки, таким образом,-backgroundStyle является NSBackgroundStyleRaised. Когда кнопка перечислена или нажата, она рисует внешнюю панель, и внешняя панель, кажется, ниже, чем внутреннее содержание кнопки. Так, когда кнопка не перечислена,-interiorBackgroundStyle возвращает NSBackgroundStyleRaised, и текст выглядит выгравированным. Когда кнопка перечислена,-interiorBackgroundStyle возвращает NSBackgroundStyleLowered, и текст выглядит рельефным.

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

Полный список backgroundStyle-связанных методов для Leopard - [NSCell backgroundStyle], - [NSCell setBackgroundStyle:], - [NSCell interiorBackgroundStyle], и - [NSSegmentedCell interiorBackgroundStyleForSegment:].

Текст и эффекты изображений: - [NSCell backgroundStyle] ответственность разработчика

Основная идея со стилями фона - это: «Он, кто знает то, на что похоже искусство, ответственен за описание его к тому, что привлекает вершину». Часто, это - AppKit, рисующий искусство. Все кнопки, рисующие внешние панели, опишут их с возвратом из - [NSButtonCell interiorBackgroundStyle]. Если Вы обратите внимание на это значение, то Вы получите некоторую независимость от изменений в искусстве платформы при выполнении пользовательского привлечения поверхности кнопки. Это могло бы включать выбор изображения для рисования, или даже обработка изображения с CoreImage фильтрует выбранный на основе backgroundStyle и другого состояния.

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

Нет никакого метода set для - [NSButtonCell interiorBackgroundStyle], потому что возвращаемое значение могло только быть неправильным при переопределении получения ячейки. При переопределении получения ячейки можно переопределить-interiorBackgroundStyle также.

Обычно это - ответственность управления вызвать - [NSCell setBackgroundStyle:] на ячейке прямо прежде, чем нарисовать его. Например, NSTableView установит backgroundStyle на своих ячейках, прежде чем он привлечет их. Это обычно легко или темно, но может также быть повышено или понижено в случае строк группы в исходных списках, и потенциально в другом месте. Если у Вас есть подкласс пользовательского элемента управления, необходимо вызвать-setBackgroundStyle на ячейках прежде, чем привлечь их.

Протест: Большинство средств управления AppKit не делает никакого собственного получения. Ячейка делает все получение. В этих случаях Вы хотели бы, чтобы backgroundStyle суперпредставления был наследован на подпредставлении некоторым способом, но нет никакой поддержки этого в Leopard. Так, в некоторых случаях необходимо будет помочь, и иногда соединять проводами стиль фона, который было бы более хорошо анализировать. Например, при размещении безграничного NSTextField непосредственно в поверхность окна, Вы, вероятно, захотите иметь вызов контроллера setBackgroundStyle:NSBackgroundStyleRaised на текстовой ячейке для получения выгравированного текста. Ячейки кнопки и сегментированные ячейки, обычно использующиеся в определенном контексте, имеют начальную букву backgroundStyle, который соответствует то использование, но не стесняйтесь изменять его, если это не корректно. Например, кнопки с NSRecessedBezelStyle начинаются с NSBackgroundStyleRaised.


Текст и эффекты изображений: - [NSImage isTemplate]

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

Это расширяется в Leopard с новым свойством метаданных, - [NSImage isTemplate]. Изображение является 'шаблоном', если это - черная и ясная маска, которая не должна быть представлена пользователю непосредственно, но всегда обрабатываться в конечную форму. Это подобно глифу в шрифте. Если ячейке дают шаблонное изображение, она может выполнить намного более сложные эффекты чем обычно, подобный сделанным с текстом. Изображение может быть темным большую часть времени, белым в выбранной строке табличного представления, и выгравированное или рельефным тот же способ, которым текст.

Шаблонное свойство не влияет на способ, которым рисует изображение. Это - метаданные, на которые может посмотреть сложный клиент. Единственный сложный клиент в AppKit для 10,5 является NSCell. Если необходимо произвести NSImage с предварительно представленными эффектами, нарисуйте с ячейкой в изображение.

Хороший пример шаблонной обработки изображений происходит в кнопке, показывающей наборы закладок в Safari 3.0. Это - в значительной степени кнопка AppKit акций. Существует единственный шаблонный набор изображения на нем, который является значком книги. То единственное изображение кажется выгравированным или рельефным в зависимости от того, перечислена ли кнопка (действительно на-interiorBackgroundStyle ячейки).

Для маркировки изображения как шаблон вызовите - [NSImage setTemplate:]. Как удобство, в приложениях соединился на или после 10.5, любое изображение, прочитанное диска через - [NSImage imageNamed:], чьи концы имени в «Шаблон» будут отмечены как шаблон, поскольку он создается. Это упрощает использовать шаблонные изображения в Интерфейсном Разработчике. Просто удостоверьтесь свой конец имен файла образа в «Шаблоне».

Один определенный эффект стоит вызвать, потому что Вы будете видеть его и вероятно задаваться вопросом точно, что инициировало его: Если шаблонное изображение привлечет повышенный фон и, как будет также предполагаться, будет наблюдать, то оно нарисует с синим свечением. Думайте об изображении как о полупрозрачной серой части пластмассового сокращения на поверхность ячейки с синей подсветкой позади него, когда будет идти ячейка. Это произойдет, например, в выбранных сегментах NSSegmentedControl с NSSegmentStyleTexturedRounded и NSSegmentSwitchTrackingSelectAny (что означает, что сегменты ведут себя как флажки). Вы не можете полагаться на это свечение, происходящее ни в каком определенном месте, потому что искусство платформы может измениться, но AppKit обещает продолжать делать что-то надлежащее.

Для NSButtonCell ячейка - изображение будет обработано для взгляда 'на' том, если состоянием ячейки будет NSOnState, его showsStateBy маска содержит NSContentsCellMask (что означает 'дополнительное изображение использования и заголовок, когда на'), и это не имеет alternateImage. В Интерфейсном Разработчике сделайте кнопку 'Toggle' и дайте кнопке изображение. Это также устанавливает highlightsBy маску, но это, вероятно, будет тем, что Вы хотите.

Можно отметить, что не возможно и использовать отличное художественное произведение в качестве alternateImage на кнопке или сегментированном управлении и также получить синее свечение. Это может несколько ограничивать, но должно иметь тенденцию удостоверяться, что этот эффект используется только в надлежащих случаях. Этот эффект помогает пользователю различить кнопку, показывающую действие и кнопку, показывающую состояние чего-то. Большинство кнопок в OS является действиями. Однако всегда было трудно отличить те кнопки, дающие состояние. Синее свечение передает состояние очень эффективно. Смотрите на кнопку календаря в левом нижнем углу iCal в 10,5. Когда мини-панель календаря не показана, кнопка показывает выгравированный миникалендарь. Пользователь мог бы думать об этом, поскольку или действие 'показывает миникалендарь' или как состояние, 'миникалендарь прочь'. К счастью обе интерпретации соглашаются с эффектом нажатия кнопки - это должно показать календарь. Как только пользователь нажимает кнопку, корректная интерпретация становится очень ясной: свечения значка календаря, синие, когда показана область. Это, очевидно, показывает состояние, и пользователь поймет, что, если он щелкает тогда по кнопке, выключит, и панель календаря будет скрыта.

Текст и эффекты изображений: NSStatusItem

Стоит упомянуть отдельно, что NSStatusItem является шаблонным здравым смыслом изображения. При использовании шаблонных изображений для элементов состояния Вы получите рендеринг, подходящий для вида строки меню в Leopard и вне. К сожалению, если Вы используете пользовательское представление в элементе состояния, у нас нет API для распространения стиля фона от элемента состояния до представления. Необходимо будет соединить стили фона проводами.

Метрики NSButton

- [NSButton sizeToFit] применился к кнопкам со стилем внешней панели, NSRecessedBezelStyle или NSRoundRectBezelStyle теперь производят кнопки, которые являются на два пикселя более узкими, чем кнопки, произведенные на Тайгере. Новые кнопки имеют те же размерности как те в панели закладок Safari.

sizeToFit существенно отличается для кнопок с NSCircularBezelStyle для приложений, соединенных на и после Leopard. Тигр 'регулярный' размер для этой кнопки был очень большим, действительно слишком большим, чтобы использоваться где угодно. Что вызвали, 'маленький' размер был чем-то, что будут обычно вызывать 'регулярное', и выглядело корректным рядом с другими регулярными размерными средствами управления.

В Leopard кнопки с NSCircularBezelStyle доступны в регулярных, маленьких и мини-размерах, где искусство для маленьких и мини-размеров является новым, и регулярный размер - то, что раньше вызывалось маленькое. Для совместимости искусство, выбранное во время получения, больше не на основе отмеченного controlSize ячейки кнопки, это основывается на размере кадра, в котором нарисована ячейка. Крупнейшее искусство, помещающееся в предоставленный кадр, будет использоваться, включая очень крупное искусство, которое было доступно в Тайгере. Результат - то, что (1) существующие кнопки должны продолжать рисовать их способ, которым они сделали, (2), новые кнопки будут меньшими. Это - плохая идея, однако, вызвать sizeToFit во время выполнения на круговых кнопках в приложении, соединенном на Leopard, но это должно работать на Тайгере также. Вызов sizeToFit произведет визуально различные кнопки при работе Тайгера по сравнению с Leopard. Если необходимо сделать это, запишите собственную подпрограмму калибровки и вызовите ее вместо sizeToFit.


Стандартные изображения

Leopard включает много изображений стандарта это, разработчики могут счесть полезным. Эти изображения доступны как имена для использования с - [NSImage imageNamed:]. Например, NSImageNameBookmarkTemplate является изображением, используемым в Safari для кнопки, показывающей представление наборов закладки. См. NSImage.h для всех имен.

Строковые значения констант также документируются так, чтобы изображения могли использоваться в Интерфейсном Разработчике. Строковое соответствие NSImageNameBookmarkTemplate «NSBookmarkTemplate». Обратите внимание на то, что это изображение является шаблоном и соответствует шаблонному соглашению о присвоении имен, как обсуждено в разделе информации о версии по - [NSImage isTemplate].

Большинство изображений называют определенная функция или ситуация, где они предназначаются, чтобы использоваться. В некоторых случаях иллюстрации могут быть более универсальными, чем имя. Например, изображение для NSImageNameInvalidDataFreestandingTemplate является стрелкой в 10,5. Не используйте изображение за пределами функции, для которой оно предназначается - иллюстрации могут измениться между выпусками. Недопустимое изображение данных могло измениться на желтую точку восклицания в треугольном значке. Если нет никакого изображения, доступного для ситуации, Вы интересуетесь, зарегистрируйте ошибку и используйте свое собственное искусство тем временем.

Существует неофициальное соглашение о присвоении имен, используемое с некоторыми изображениями. Если изображение имеет «Автономный» на имя, это применимо как маленькое встроенное изображение без любой дополнительной внешней панели. Например, Safari использует NSImageNameStopProgressTemplate (X для 10,5) как кнопка остановки в bezeled кнопке на панели инструментов, в то время как это использует NSImageNameStopProgressFreestandingTemplate (X в кругу для 10,5) в окне загрузок, где это кажется встроенным с индикатором хода выполнения.

Стандартные изображения главным образом предоставлены как удобство. Используйте их, если они удовлетворяют Вашу потребность, но если они не делают тогда, пользовательское искусство хорошо. Например, можно найти, что Вы хотите различную толщину обводки для большего или меньшего изображения с «добавлением» или «удаляете» кнопку. Было бы замечательно, если AppKit мог бы разместить это, но использовать Ваше собственное искусство, если это лучше.

Стандартные Изображения: - [NSButtonCell setImageScaling:] и - [NSSegmentedCell setImageScaling:forSegment:]

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

Для помощи с этим NSButton и NSButtonCell получили imageScaling свойство, и NSSegmentedControl и NSSegmentedCell получили-imageScalingForSegment: и-setImageScaling:forSegment: методы.

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

Масштабирование изображения не имеет никакого влияния на поведение-sizeToFit.

Мы также изменили значения, доступные в перечислении NSImageScaling, потому что нам было нужно одно значение, которое не было доступно, и два из существующих значений не хорошо назвали.
enum {
NSImageScaleProportionallyDown = 0, // Scale image down if it is too large for destination. Preserve aspect ratio.
NSImageScaleAxesIndependently, // Scale each dimension to exactly fit destination. Do not preserve aspect ratio.
NSImageScaleNone, // Do not scale.
NSImageScaleProportionallyUpOrDown // Scale image to maximum possible dimensions while (1) staying within destination area
// and (2) preserving aspect ratio
};
typedef NSUInteger NSImageScaling;

Метаданные расположения NSImage

NSImage теперь поддерживает alignmentRect свойство, обеспечивающее метаданные, которые клиент может использовать, чтобы помочь определить расположение. Нижняя часть rect дает базовую линию изображения. Другие края дают подобную информацию в других направлениях.
- (NSRect)alignmentRect;
- (void)setAlignmentRect:(NSRect)rect;
alignmentRect изображения не имеет никакого эффекта на методы, такие как drawInRect:fromRect:operation:Fraction: или drawAtPoint:fromRect:operation:fraction:. Скорее заинтересованный клиент может использовать alignmentRect для улучшения расположения где применимо.

20x20 изображение значка телефона со свечением могло бы указать alignmentRect {{2,2}, {16,16}}, который исключает свечение. NSButtonCell использует в своих интересах alignmentRect для размещения изображения в то же визуальное расположение как 16x16 значок телефона без свечения. 5x5 звезда, которая должна представить высоко, когда выровнено с текстом, могла бы указать rect {{0,-7}, {5,12}}.

Значение по умолчанию alignmentRect изображения {{0,0}, imageSize}. rect корректируется когда setSize: вызывается.

Многослойное получение изображения

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

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

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

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

NSCell автоматическое расширение кадр ToolTip

NSCell имеет некоторый новый API для поддержки подсказок расширения в определенных средствах управления:
- (NSRect)expansionFrameWithFrame:(NSRect)cellFrame inView:(NSView *)view;
- (void)drawWithExpansionFrame:(NSRect)cellFrame inView:(NSView *)view;
Подсказка расширения позволяет видеть усеченный текст в специальном плавающем окне, которое подобно, но отличается от нормального ToolTip. В настоящее время, когда текст является усеченным, NSTableView, NSOutlineView и NSBrowser выводят на экран подсказки расширения. Если у Вас есть ячейка, которая будет выведена на экран в одних из этих средств управления, рекомендуется реализовать вышеупомянутые методы, чтобы должным образом поддерживать функцию подсказки расширения. По умолчанию методы должным образом реализованы в NSTextFieldCell и NSBrowserCell. NSCell будет всегда возвращать NSZeroRect и предотвращать расширение. Для примера того, как реализовать его, посмотрите демонстрационное приложение SimpleBrowser.

Клиенты NSTableView, NSOutlineView и NSBrowser могут предотвратить расширение ячейки на определенной строке/столбец при помощи новых методов делегата, объявленных в надлежащих заголовочных файлах.

NSCell отметил текстовую поддержку

Изменение содержания подклассов NSCell больше не вызывает подтверждение отмеченного текста (также известный как встроенная дыра), если новое содержание не фактически отличается от оригинала.

Существует новый API NSCell, говоря его полевому редактору отправить текстовые уведомления изменения. NSTextFieldCell также обеспечивает-setWantsNotificationForMarkedText:
- (BOOL)wantsNotificationForMarkedText;
Ошибка представила в Тайгере что различные методы калибровки NSCELL, такие как-cellSizeForBounds: игнорирование размеров границ, меньших, чем 0,0, фиксируется.

NSTextFieldCell

- [NSTextFieldCell accessibilityPerformAction:] теперь пытается выполнить NSAccessibilityConfirmAction для ячеек без связанного действия. Это использует-currentEditor и-selectedCell, чтобы определить, связывается ли текущий полевой редактор с сам.

Новое свойство, allowedInputSourceLocales, управляет источниками ввода текста, включенными для экземпляра NSTextView. К свойству могут получить доступ следующие методы доступа. Существует meta идентификатор локали, NSAllRomanInputSourcesLocaleIdentifier, доступный для указания входных источников, ограничивающихся для римского редактирования сценария.
- (NSArray *)allowedInputSourceLocales;
- (void)setAllowedInputSourceLocales:(NSArray *)localeIdentifiers;
NSTextFieldCell больше не отключает себя временно в-trackMouse:inRect:ofView:untilMouseUp:. Это - ответственность приложения теперь для надлежащей установки конфигурации вызова действия через-sendActionOn: метод.

Для предотвращения противоречивого рендеринга рендеринг цвета фона отключен для округленной внешней панели экземпляры NSTextFieldCell.

Пул автовыпуска в - [NSCell trackMouse:inRect:ofView:untilMouseUp:]

Для приложений, соединенных на или после Leopard, NSCell использует внутренний пул автовыпуска в то время как цикличное выполнение по событиям в-trackMouse:inRect:ofView:untilMouseUp:. Это не должно иметь никакого эффекта на приложение, что уже методы исправляют управление памятью, за исключением того, что использование памяти временно не поднимется, в то время как пользователь, скажем, вычищает NSSlider назад и вперед. Однако приложение, которое не всегда тщательно относительно управления памятью, возможно, недавно выразило ошибки. Если нажатие кнопки заставляет делегата NSTableView получать заключительный автовыпуск, и программист не старается вызвать [tableView setDelegate:nil] для очистки несохраненной обратной ссылки, приложение могло отказать, если tableview пытается передать свой источник данных перед концом runloop цикла.

Архив, читающий для очень старых ячеек

До Leopard NSCell имел остаточную поддержку чтения очень старых невключенных архивных данных, сохраненных до Mac OS X 10.0. Эта поддержка была удалена. Попытка считать такой NSCell теперь выдаст исключение. Между прочим, в случае, если Вы пропустили его, необходимо действительно использовать включенную архивацию. Невключенный archiver не сохраняет свойств объектов, добавленных в последних нескольких версиях ОС. Если бы мы сделали, то те архивы не были бы читаемы на более ранних версиях OS.


NSBitmapImageRep - Создание с пользовательским цветовым профилем

Теперь возможно создать NSBitmapImageRep с произвольным цветовым профилем ICC. Указанный профиль будет использоваться, когда образ будет нарисован и будет также сохранен с изображением, когда это кодируется к растровому формату данных изображения, такому как TIFF.

Чтобы сделать это для NSBitmapImageRep, создающегося с нуля с помощью одного из «-initWithBitmapDataPlanes:...» методы инициализатора, клиентский код, должно передать NSCalibratedRGBColorSpace инициализатору, и затем предоставить данные профиля ICC как объект NSData использование-setProperty:withValue: метод и ключ свойства NSImageColorSyncProfileData:
NSBitmapImageRep *bitmapImageRep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:planes
/* ...more parameters... */
colorSpaceName:NSCalibratedRGBColorSpace
/* ...more parameters... */
];
[bitmapImageRep setProperty:NSImageColorSyncProfileData withValue:iccProfileData];
Можно также установить новый профиль нового цвета для NSBitmapImageRep, инициализирующегося от существующего TIFF, PNG, и т.д. файл с помощью того же «-setproperty:withvalue»: метод.

Профиль ICC может быть получен как NSData из экземпляра NSColorSpace с помощью «-ICCProfileData» метода доступа:
NSColorSpace *colorSpace = [NSColorSpace sRGBColorSpace];
NSData *iccProfileData = [colorSpace ICCProfileData];
Это может также быть получено путем инициализации экземпляра NSData с содержанием файла профиля «.icc»:
NSData *iccProfileData = [NSData dataWithContentsOfFile:@"/System/Library/ColorSync/Profiles/sRGB Profile.icc"];

NSBitmapImageRep - Создание из CIImage

AppKit теперь включает метод инициализатора для создания NSBitmapImageRep от Базового Изображения объект CIImage:
- (id)initWithCIImage:(CIImage *)ciImage;
CIImage требуется, чтобы быть конечной степени (в противном случае-initWithCIImage: повышает исключение).-initWithCIImage: метод производит NSBitmapImageRep, пиксельные размерности которого равняются степени входящего CIIMAGE.

Обратите внимание на то, что, если данный CIImage является результатом Базовой работы фильтра Изображения, оценка которой была задержана, вызвав-initWithCIImage: заставит рецепт изображения быть оцененным (представленный) так, чтобы результирующие пиксели изображения могли быть получены, таким образом, этот метод, как могут ожидать, займет время, чтобы выполниться и возвратиться, в зависимости от сложности цепочки фильтра и доступности Базового Ускоряющего изображение аппаратного обеспечения машинной графики в хост-системе.

NSBitmapImageRep - Создание из CGImage, получение CGImage

AppKit также включает новый метод инициализатора для создания NSBitmapImageRep от Кварца CGImage:
- (id)initWithCGImage:(CGImageRef)cgImage;
NSBitmapImageRep, создающийся таким образом, сохраняет данный CGImage как свое основное базовое представление, отражая свойства CGIMAGE как его собственное и с помощью CGImage для рисования, когда спросили нарисовать.

Так как CGImageRef просто сохраняется NSBitmapImageRep, на его резидентные данные изображения ссылаются вместо того, чтобы быть скопированным. Если NSBitmapImageRep просят относительно его пиксельных данных (через-bitmapData или-getBitmapDataPlanes: сообщение), это обяжет путем распаковки копии содержания CGIMAGE к внутреннему буферу. Результирующие пиксельные данные нужно считать только для чтения. Изменение его через возвращенный указатель (и) не заставит CGImage быть воссозданным.

Независимо от того, как это создавалось, NSBitmapImageRep можно теперь попросить возвратить автовыпущенное собственное представление CGImage:
- (CGImageRef)CGImage;
Если NSBitmapImageRep уже не имеет собственного представления CGImage, Используя этот метод может заставить CGImage создаваться. После того, как создаваемый, CGImage принадлежит NSBitmapImageRep, который ответственен за выпуск его, когда освобожден сам NSBitmapImageRep.

NSBitmapImageRep - Цвет фона нейтрализации для вывода JPEG

NSBitmapImageRep.h объявляет дополнительный атрибут NSBitmapImageRep, доступный на Leopard, который может использоваться для указания цвета фона нейтрализации для использования при кодировании изображения к данным/формату файла, не поддерживающим альфа-каналы:
NSString* NSImageFallbackBackgroundColor  AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER; // JPEG output (NSColor)
Это позволяет клиентам указывать цвет фона для использования для данных изображения, которые это выписано, если закодированный NSBitmapImageRep имеет альфа-канал. Это соответствует kCGImageDestinationBackgroundColor свойству, определенному платформой ImageIO.


Новые свойства NSBox

NSBox теперь поддерживает универсальное цветное получение поля через четыре новых свойства:
- (CGFloat)borderWidth;
- (void)setBorderWidth:(CGFloat)borderWidth;
- (CGFloat)cornerRadius;
- (void)setCornerRadius:(CGFloat)cornerRadius;
- (NSColor *)borderColor;
- (void)setBorderColor:(NSColor *)borderColor;
- (NSColor *)fillColor;
- (void)setFillColor:(NSColor *)fillColor;
Эти свойства только применяются к полям типа NSBoxCustom. 'Пользовательское' слово относится к этим полям, не имеющим никакого отношения к инструкциям по интерфейсу пользователя для Mac OS X. Также, стиль должен использоваться экономно. Это может быть полезно для простого пользовательского получения, или как плакат некоторого вида, но не должно использоваться в качестве общего поля группировки управления.

Этот стиль поля может быть полезным в сочетании с новым классом Leopard NSCollectionView. NSCollectionView поддерживает единственный и множественный выбор, но не рисует ничего для указания самого выбора. Та ответственность делегирована к представлениям, которые она содержит. Пользовательское поле может использоваться для рисования простой подсветки выделения.

Одна проблема с использованием, которое NSBox для рисования подсветки выделения в NSCollectionView - то, что нужно быть в состоянии переключить продвигание и от соответствия выбранному свойству NSCollectionViewItem. Для поддержки этого случая мы добавили еще одно свойство к NSBox:
- (BOOL)isTransparent;
- (void)setTransparent:(BOOL)flag;
Свяжите прозрачное свойство с выбранным свойством NSCollectionViewItem. Семантика прозрачного свойства NSBOX совпадает с семантикой прозрачного свойства NSBUTTON.


NSGradient

Экземпляры нового класса NSGradient поддерживают создание цветового градиента с многократными цветными остановками и рисование себя как линейный или или радиальный градиент. Градиент определяет переход между цветами в расположениях от 0,0 до 1,0. Начальный цвет считается в расположении 0.0, конечный цвет в 1,0. Дополнительные цветные остановки могут быть расположены в позициях между 0,0 и 1.0. Цветовой градиент в состоянии нарисовать себя во множестве путей как линейный градиент и как радиальный градиент.

Определяемый инициализатор берет NSArray цветов для градиента и массива C, содержащего CGFloats со значениями между 0,0 и 1.0 для указания расположений цветов в градиенте. Кроме того, цветовое пространство градиента предоставлено. Все, если цвета будут преобразованный в это цветовое пространство. Если никакая цветная остановка не будет расположена в 0,0 или 1.0, то цвет самой близкой цветной остановки будет нарисован к надлежащему концу градиента.
- (id)initWithColors:(NSArray *)colorArray atLocations:(CGFloat *)locations colorSpace:(NSColorSpace *)colorSpace;
Три дополнительных инициализатора обрабатывают общие падежи. Первые взятия запуск и конечный цвет для создания двухцветного градиента. Вторые взятия массив цветов, и расположат предоставленные цвета с интервалами в равных интервалах от 0,0 до 1,0. Треть берет завершенный нолем список переменной длины пар цвета/расположения. Универсальное цветовое пространство RGB будет использовано для градиентов, создаваемых с этими init методами.
- (id)initWithStartingColor:(NSColor *)color endingColor:(NSColor *)endingColor;
- (id)initWithColors:(NSArray *)colorArray;
- (id)initWithColorsAndLocations:(NSColor *)firstColor, ...;
Как только цветовой градиент определяется, он может использоваться для рисования и линейных и радиальных градиентов.

Методы рисования допускают получение линейных и радиальных градиентов в прямоугольнике и пути. Учитывая прямоугольник или путь, удобный метод вычислит надлежащие расположения и сделает надлежащее отсечение.

Для линейных градиентов может быть указан угол градиента в rect или пути.
- (void)drawInRect:(NSRect)rect angle:(CGFloat)angle;
- (void)drawInBezierPath:(NSBezierPath *)path angle:(CGFloat)angle;
Для радиальных градиентов может быть указана относительная центральная позиция, использование NSZeroPoint указывает радиальный градиент, центрируемый в прямоугольнике или пути, ограничивающем rect. Радиальный градиент, нарисованный этими методами всегда, рисует от внутренней точки до внешнего круга с внутренней точкой в центре внешнего круга.

Относительная центральная позиция позволяет разработчику пропорционально корректировать центр радиального градиента относительно прямоугольника или пути, ограничивающего rect. Относительная центральная позиция отображает точку - (1.0,-1.0) к источнику прямоугольника и точки (1.0, 1.0) к максимальным значениям x и y прямоугольника. Центр ограничения rect отображается на относительную центральную позицию (0, 0).
- (void)drawInRect:(NSRect)rect relativeCenterPosition:(NSPoint)relativeCenterPosition;
- (void)drawInBezierPath:(NSBezierPath *)path relativeCenterPosition:(NSPoint)relativeCenterPosition;
Эти методы рисования обеспечивают простой способ нарисовать заливки градиента. Разработчики, желающие другого поведения получения, могут использовать примитивные методы рисования, описанные ниже, и создать дополнительные удобные методы как категории, вычисляющие, где примитивные методы должны нарисовать.

Два примитивных метода рисования отображаются близко на получение Кварцевых штриховок. Обратите внимание на то, что, так же, как с Кварцевыми штриховками, эти примитивные методы рисования не выполняют отсечения перед получением.

Каждый примитивный метод рисования выбирает варианты: параметр. Определяются две опции:
    NSGradientDrawsBeforeStartingLocation
    NSGradientDrawsAfterEndingLocation
Эти опции управляют, расширяется ли получение, прежде и после градиента запускают и заканчивают расположения. Эти опции только присутствуют для примитивных методов рисования, так как rect и центральные путем методы рисования гарантируют, что весь rect или путь заполнены градиентом. Эти рисующие примитивные методы рисуют линейный градиент и радиальный градиент, соответственно.
- (void)drawFromPoint:(NSPoint)startingPoint toPoint:(NSPoint)endingPoint options:(NSGradientDrawingOptions)options;
- (void)drawFromCenter:(NSPoint)startCenter radius:(CGFloat)startRadius
toCenter:(NSPoint)endCenter radius:(CGFloat)endRadius options:(NSGradientDrawingOptions)options;

Много методов предоставлены прежде всего для обеспечения создания средств управления, редактирующих/создающих градиенты. Эти методы возвращают число цветных остановок, получают доступ к цвету и расположению каждой остановки, возвращают цветовое пространство градиента и определяют интерполированный цвет в определенном расположении между 0,0 и 1.0 в цветовом градиенте.
- (NSInteger)numberOfColorStops;
- (void)getColor:(NSColor **)color location:(CGFloat *)location atIndex:(NSInteger)index;
- (NSColorSpace *)colorSpace;
Переопределение этого метода для обеспечения различных значений цвета не будет влиять на базовое вычисление цветового градиента и не будет влиять, как нарисован цветовой градиент.
- (NSColor *)interpolatedColorAtLocation:(CGFloat)location;

NSTableView/NSOutlineView

NSTableView и NSOutlineView теперь должным образом обрабатывают альфу backgroundColors. Кроме того, можно выбрать цвет к [NSColor clearColor] для переживания к области позади Вас (т.е.: сделайте его прозрачным), но обратите внимание на то, что необходимо также установить drawsBackground в НЕ на содержании NSScrollView, такого как: [[tableView enclosingScrollView] setDrawsBackground:NO].

Документация правильно утверждает, что можно программно выбрать многократные строки, даже если allowsMultipleSelection был установлен в нет, но это не было фактически позволено. На связанных приложениях Leopard это фиксируется, и можно вызвать [таблица selectRowIndexes:indexes byExtendingSelection:YES] или [таблица selectRow:row byExtendingSelection:YES] и правильно выбрать многократные строки, даже если allowsMultpleSelection установлен в НЕТ. Документация правильно утверждает, что можно progmatically отменить выбор всех строк независимо от того, позволяется ли пустой выбор, но это не было фактически позволено. Это также фиксируется для связанных приложений Leopard.

Таблицы теперь поддерживают навигацию межъячейки следующим образом:

- Переключение вкладок вперед к таблице фокусирует всю таблицу.
- Удар Пространства попытается к 'performClick': на NSButtonCell в выбранной строке, если существует только один экземпляр в той строке.
- Если существует тот, переключение вкладок снова фокусирует первое «focusable» (1) ячейка.
- Если недавно фокусируемая ячейка может быть отредактирована, редактирование начнется.
- Удар Пространства вызывает 'performClick': на ячейке и наборах значение источника данных впоследствии, если изменено. (2)
- Если текстовая ячейка редактирует, удар Входят, будет фиксировать редактировать, и фокус будет возвращен к tableview, и Tab/Shift-tab будет фиксировать редактирование и затем выполнять новое поведение цикла табуляции.
- Переключение вкладок только снабдит вкладками через единственную строку
- Как только последняя ячейка подряд достигнута, вкладка возьмет фокус к следующему focusable управлению.
- Назад переключение вкладок в таблицу выберет последнюю focusable ячейку.

(1) focusable ячейка обычно определяется как [ячейка isEnabled] && [ячейка isSelectable] в столбце таблицы, который доступен для редактирования. Однако NSTextFieldCells также проверяют, можно ли строка выбрать, и tableView:shouldEditTableColumn:row: возвраты YES (если реализовано делегатом). NSImageCells не может фокусироваться. NSButtonCells только проверяют если [ячейка isEnabled].
(2) Сделать эту работу с NSPopUpButtonCell, performClickWithFrame:inView: вызывается.

NSTableView/NSOutlineView - Изменения делегата

Следующие два новых метода делегата Leopard, представленные в WWDC, были переименованы от:
- (NSIndexSet *)tableView:(NSTableView *)tableView
selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes
byExtendingSelection:(BOOL)extend;
- (NSIndexSet *)outlineView:(NSOutlineView *)outlineView
selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes
byExtendingSelection:(BOOL)extend;
к:
- (NSIndexSet *)tableView:(NSTableView *)tableView
selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes;
- (NSIndexSet *)outlineView:(NSOutlineView *)outlineView
selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes;
В выпусках до Mac OS 10.5, для следующего метода делегата:
- (void)tableView:(NSTableView*)tableView didDragTableColumn:(NSTableColumn *)column;
tableColumn параметром неправильно был бы NSTableColumn, существовавший в исходном индексе перетащенного столбца. Для приложений, соединенных на или после Leopard, tableColumn правильно будет перетащенным столбцом.

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

До Leopard NSTableView и NSOutlineView не убрали бы область монтажа перетаскивания перед вызовом:
- (BOOL)outlineView:(NSOutlineView *)outlineView writeItems:(NSArray *)items toPasteboard:(NSPasteboard *)pboard;
или
- (BOOL)tableView:(NSTableView *)tableView writeRowsWithIndexes:(NSIndexSet *)rowIndexes toPasteboard:(NSPasteboard *)pboard;
В Leopard это теперь уберет область монтажа. Необходимо объявить типы, с которыми Вы поддерживаете для перетаскивания:
    NSMutableArray *types = [[pboard types] mutableCopy];
// Add our custom type and leave the ones NSOutlineView supports in the list.
[types addObject:MyType];
// Make ourselves the owner. For any types we don't handle we can forward to NSOutlineView/NSTableView.
[pboard declareTypes:types owner:self];
Новый метод делегата:
- (BOOL)tableView:(NSTableView *)tableView
shouldTrackCell:(NSCell *)cell
forTableColumn:(NSTableColumn *)column
row:(NSInteger)row;
даже если строка не можно выбрать или выбрана, позволяет ячейке быть прослеженной. Это позволяет Вам, делают табличное представление, которое не позволит никаким строкам быть выбранными, но все еще позволять пользователю взаимодействовать с ячейками, столь же замеченными ниже (использующий представление схемы как пример):
- (BOOL)outlineView:(NSOutlineView *)ov shouldSelectItem:(id)item {
return NO;
}
- (BOOL)outlineView:(NSOutlineView *)ov shouldTrackCell:(NSCell *)cell forTableColumn:(NSTableColumn *)column item:(id)item {
return YES;
}
Другой пример не должен позволять ячейкам кнопки флажка изменять выбор, но все еще позволять им щелкнуться и прослеженными. [NSApp currentEvent] всегда будет корректен, когда этот метод вызовут, и можно использовать его для выполнения дополнительного тестирования хита текущего расположения мыши. Посмотрите демонстрационное приложение DragNDropOutlineView для примера того, как сделать это.

В outlineView:shouldSelectItem: и tableView:shouldSelectRow: можно теперь получить доступ к clickedRow и clickedColumn для наблюдения, по какой строке и столбцу щелкнули, если метод отправляется в ответ на начальное событие щелчка. В той точке, [NSApp currentEvent] также будет допустимо.

Для Leopard (и выше) связанные приложения, следующий метод делегата перетаскивания вызовут только, когда dragOperation или отменят изменения расположения:
- (NSDragOperation)outlineView:(NSOutlineView *)outlineView
validateDrop:(id <NSDraggingInfo>)info
proposedItem:(id)item
proposedChildIndex:(NSInteger)index;
До Leopard это постоянно вызывать, который не необходим.

NSTableView/NSOutlineView - Введите для Выбора

NSTableView и NSOutlineView теперь тип поддержки для выбора (также известный как инкрементный поиск). Посмотрите заголовок для новых методов делегата.

NSTableView/NSOutlineView - Нерабочее состояние

Для приложений, соединенных на Leopard, NSTableView и NSOutlineView теперь должным образом, поддерживает [NSControl isEnabled] и [NSControl setEnabled: флаг (BOOL)].

Отключенный NSTableView будет:
- Откажитесь от первого состояния респондента
- Не делают любое отслеживание в mouseDown
- Не позволяют редактировать любых столбцов
- Отключите выбор строк и столбцов
- Отключите перетаскивание строк и столбцов
- Не позволяют переупорядочивать строк или столбцов
- Вызовите [NSCell setEnabled:NO] для каждой рисующейся ячейки
- Кроме того, NSTextFieldCell будет привлечен с цветом недоступного текста
- Нарисуйте представление заголовка с цветом недоступного текста

Установка NSTableView/NSOutlineView, который будет включен или отключен, будет идти, все NSTableColumns включают или отключают dataCell и headerCell того NSTableColumn. Можно переопределить включенное/нерабочее состояние из ячеек в willDisplayCell методе делегата.

NSTableView/NSOutlineView - Тестирование Хита ячейки, Перетаскивание и Редактирование Ячейки

NSTableView теперь использует новый хит NSCell, тестирующий API для выполнения определенных действий. Пользовательский NSCell разделяет на подклассы в приложениях, соединяющихся на или после того, как Leopard должен должным образом реализовать-hitTestForEvent:inRect:ofView:; см. NSCell.h для получения дополнительной информации.

NSTableView выполняет тестирование хита в ячейках, чтобы сделать следующие действия:
- Перетаскивание: NSTableView вызывает hitTestForEvent:inRect:ofView в canDragRowsWithIndexes:atPoint. Если ячейка хита возвратит NSCellHitTrackableArea, то определенная строка будет прослежена вместо перетащенного.
- Редактирование ячейки: Когда NSTableView получит мышь вниз, редактирование единственного щелчка текста (как Средство поиска) произойдет, если будет только одна строка, выбранная, и ячейка возвращает NSCellHitEditableTextArea.

Посмотрите демонстрационное приложение DragNDropOutlineView для примера того, как должным образом реализовать методы NSCell.

NSTableView/NSOutlineView - Единственный щелчок для редактирования

NSTableView и NSOutlineView теперь ведут себя как Средство поиска и позволяют единственному щелчку помещать его в режим редактирования. Это сделано путем вызова-hitTestForEvent:inRect:ofView: и проверяя, возвращает ли ячейка NSCellHitEditableTextArea. Это позволяет Вам устанавливать doubleAction и выполнять некоторую различную задачу, когда doubleAction вызывается (например, Средство поиска открывает файлы при двойном щелчке и редактирует через единственный щелчок). Если doubleAction не установлен, редактирование все еще позволяется через двойной щелчок.

NSTableView/NSOutlineView - Поддержка контекстного меню

NSTableView и NSOutlineView теперь имеют лучшую поддержку контекстного меню. Посмотрите демонстрационное приложение DragNDropOutlineView для примера того, как должным образом сделать контекстные меню с TableView.

Ключевая вещь отметить состоит в том, что clickedRow и clickedColumn теперь оба будут допустимы, когда будет раскрыто контекстное меню. Кроме того, можно динамично установить всплывающее меню для определенной ячейки/столбец в методе делегата willDisplayCell:. NSTableView обрабатывает это путем надлежащего переопределения menuForEvent: устанавливая clickedRow/clickedColumn и вызывая [NSCell menuForEvent:inRect:ofView] для нахождения корректного меню. Если никакое меню не было возвращено, меню для NSTableView будет использоваться. Если Вы щелкаете правой кнопкой по выбору элементов, все элементы выделяются. Нужно проверить, чтобы видеть, является ли clickedRow одной из выбранных строк, и если это, тогда делают работу меню на всех выбранных строках. Когда действие будет отправлено от NSMenuItem, clickedRow и clickedColumn свойства все еще будут допустимы.

NSTableView/NSOutlineView - rowHeight

Для приложений, соединенных на или после Leopard, высоты строки по умолчанию для NSTableView, создаваемого с [[, выделение NSTableView] init] будет установлено правильно для начального шрифта, используемого ячейкой по умолчанию в NSTableColumn. NSTableView, создаваемым в Интерфейсном Разработчике на Тигре и больше уже, установили rowHeight правильно для определенного выбранного шрифта.

NSTableView/NSOutlineView - Полные ячейки Ширины и вид строки группы

NSTableView и NSOutlineView теперь имеют нового делегата, API для создания «строки группы» смотрит. См. NSTableView.h/NSOutlineView.h и демонстрационное приложение DragNDropOutlineView для примера того, как использовать новые методы делегата.

tableView:dataCellForTableColumn:row: позволяет Вам легко возвращать пользовательскую ячейку для любой определенной строки, не имея необходимость разделять NSTableColumn на подклассы. Кроме того, можно возвратить ячейку, которая охватит всю ширину табличного представления («полная ширина» ячейка).

Если Вы возвращаете YES из tableView:isGroupRow: тогда «стиль» строки группы будет нарисован для той строки. «Стиль» строки группы зависит от selectionHighlightStyle и нарисует по-другому для различных стилей.

NSTableView/NSOutlineView - Столбец rects

Так как столбцы таблицы теперь могут быть скрыты (см. ниже), columnsInRect: метод осуждается в пользу того, который может возвратить ряд индексов столбца, а не просто диапазона:
- (NSIndexSet *)columnIndexesInRect:(NSRect)rect;

NSTableView/NSOutlineView - selectionHighlightStyle:

Существует новое свойство, названное selectionHighlightStyle с основной целью позволить «исходному списку», выделяющему стиль быть автоматически принятым с минимальной работой.

Если стиль будет установлен в NSTableViewSelectionHighlightStyleSourceList, то это нарисует выбранные пункты с «исходным списком», выделяющим стиль. Кроме того, установка NSTableViewSelectionHighlightStyleSourceList на NSOutlineView также изменит следующие свойства для соответствия инструкций HI: backgroundColor, indentationPerLevel, rowHeight и intercellSpacing. Если требуется изменить какое-либо из этих свойств, необходимо сделать так после вызова [outlineView setSelectionHighlightStyle:NSTableViewSelectionHighlightStyleSourceList]. Кроме того, объединение «строк группы» с «исходным списком», выделяющим стиль, произведет стандартный взгляд заголовка раздела путем реализации-outlineView:isGroupItem: и возврат YES для заголовков раздела. Для не показа треугольника раскрытия переопределите-frameOfOutlineCellAtRow: и возвратите пустой rect. Вы также захотите не позволить ему быть разрушенным путем возврата НЕ из метода делегата-outlineView:shouldCollapseItem:. Когда треугольник раскрытия не будет показан для заголовка раздела, элемент автоматически будет нес отступом. При использовании «исходного списка», выделяющего стиль, рекомендуется нарисовать ячейки со значками на 16x16 пкс.

Одно дополнительное примечание: выбранные пункты в «исходных списках» должны быть полужирными, и NSTableView автоматически преобразует значение NSString в NSTextFieldCell, чтобы быть полужирным; однако, это может конфликтовать со средствами форматирования с ячейкой, ожидающими NSString вместо NSAttributedString. Если редактирование ячейки заставляет заголовок нарисовать пробел, несомненно, исследуют любые средства форматирования, присоединенные к ячейке.


NSTableColumn

NSTableColumns теперь имеют:
- (void)setHidden:(BOOL)hidden;
- (BOOL)isHidden;
Столбцы, которые скрыты все еще, существуют в - [NSTableView tableColumns], массив и - [NSTableView numberOfColumns] включает столбцы, которые скрыты. Скрытые столбцы не включены в индексы, возвращенные новым columnIndexesInRect: метод.

Если autosaveTableColumns установлен в YES, состояние сохраняется с другой информацией об автосохранении.

Можно также теперь установить подсказку для заголовка столбца:
- (void)setHeaderToolTip:(NSString *)string;
- (NSString *)headerToolTip;

NSSavePanel/NSOpenPanel

NSSavePanel и NSOpenPanel теперь поддерживают переупорядочение перетаскивания и вставку элементов на боковой панели. Кроме того, можно перетащить любой из файлов в боковую панель или Средство поиска.

NSSavePanel и NSOpenPanel теперь поддерживают режим «представления в виде значков». Выбор значка позволяет пользователю изменять расположение метки и размер значков.

Для выбора файлов cmd-i покажет информационную панель Средства поиска, и CMDR покажет расположение в Средстве поиска.

NSSavePanel и NSOpenPanel могут еще раз показать скрытые файлы путем установки пользовательского значения по умолчанию. Например, можно использовать 'значения по умолчанию, пишут-g AppleShowAllFiles 1' для отображения скрытых файлов в панелях.

В NSSavePanel Ctrl-Tab теперь быстро снабдит вкладками Вас к списку файлов из текста редактирования имени. Ctrl-Shift-Tab возвратит Вас туда, где Вы были.

NSSavePanel и NSOpenPanel теперь имеют опции расширенного поиска. Щелкните плюс кнопка, расположенная направо от поисковых кнопок расположения для настройки поиска. Поиски могут теперь быть сохранены к боковой панели для использования во всех приложениях, или просто Вашем приложении. Можно также отредактировать существующие поиски и повторно сохранить их.

NSOpenPanel теперь позволяет Вам просматривать свой iLife и связанные носители. Надлежащие элементы носителей на боковой панели выведены на экран на основе типов, переданных открытой панели.


NSPathControl, NSPathCell, NSPathComponentCell

AppKit теперь имеет новый контроль, позволяющий Вам легко представлять путь, быть им путь файловой системы или виртуальный тракт.

NSPathControl поддерживает три стиля:
- NSPathStyleStandard, тот же стиль, замеченный в NSOpenPanel/NSSavePanel/Finder, когда поиск сделан и файл, выбран.
- NSPathStyleNavigationBar (иначе «навигационная цепочка»), который подобен тому, что iTunes имеет в Музыкальном магазине iTunes.
- NSPathStylePopUp, стиль, только показывающий последний компонент контура и использующий раскрывающееся, чтобы вывести на экран полный путь и позволить пользователю выбирать новый путь.

Основное взаимодействие с управлением сделано через [NSPathControl setURL:url], который является оберткой вокруг [NSPathCell setURL:url]. Управление автоматически поддерживает перетаскивание, которое может быть далее настроено через методы делегата. Свойства ячейки могут легко быть modfied через методы доступа. NSPathCell также работает хорошо в NSTableView/NSOutlineView, однако, автоматическая анимация не будет работать, когда стиль будет установлен в NSPathStyleStandard или NSPathStyleNavigationBar. См. соответствующие заголовочные файлы для получения дополнительной информации.

NSPathCell

Когда NSPathCell установили стиль в NSPathStylePopUp, если это будет содержать 0 pathComponentCells, то это будет использовать placeholderString для раскрывающейся кнопки. Ранее, это не использовало бы раскрывающуюся кнопку и просто нарисует строку.

Когда NSPathCell установили стиль в NSPathStylePopUp, если ячейка имеет границу (т.е.: [ячейка setBordered:YES]), это нарисует «круглую внешнюю панель» граница вокруг раскрывающейся кнопки. Ранее, это никогда не рисовало бы границу.


NSDictionaryController

Существует новый класс контроллера: NSDictionaryController. Это может использоваться для редактирования содержания словаря как пар ключ/значение в табличных представлениях, например. Контроллер позволяет конфигурировать «включенные ключи» (ключи, всегда видимые в выведенном на экран массиве пар ключ/значение, ли настоящее в словаре содержания или не) и «исключенные ключи» (ключи, всегда скрытые в выведенном на экран массиве пар ключ/значение). Для поддержки локализации контроллеры словаря позволяют устанавливать локализованный ключевой словарь, который может указать таблицу меток дисплея для каждого ключа (и будет обычно читаться из таблицы строк).

NSDictionaryController предлагает привязку для словаря содержания, а также включенных ключей, исключенных ключей, и локализовал ключевой словарь (что означает, что объект, обеспечивающий словарь содержания, может также обеспечить включенные, исключенные, и локализованные ключи одновременно, потенциально динамично вычисленный на основе словаря содержания).


NSTreeController

NSTreeController теперь обеспечивает лучший доступ к выведенным на экран объектам содержания в форме объектов NSTreeNode. NSTreeNode разработан для представления отдельного узла в древовидной структуре данных. Каждый экземпляр NSTreeNode обертывает единственный representedObject и поддерживает ссылку на ее родительские и дочерние узлы. NSTreeNodes также знают, где они относительно корневого узла дерева. Эта информация о расположении, представленная NSIndexPath и, возвращается indexPath методом NSTreeNode.

У Тигра arrangedObjects метод NSTreeController возвратил непрозрачный прокси, который разработчики, как предполагалось, не использовали непосредственно. В Leopard arrangedObjects метод возвращает прокси, реагирующий на методы NSTreeNode
- (NSArray *)childNodes;
и
- (NSTreeNode *)descendantNodeAtIndexPath:(NSIndexPath *)indexPath;
С этими двумя методами теперь возможно переместиться по расположенному дереву древовидного контроллера.

При помощи NSTreeNodes для обертывания представленных объектов NSOutlineView, связанный с NSTreeController, может вывести на экран тот же представленный объект в многократных строках.

Когда связано с NSTreeController, элементами строки NSOutlineView будет NSTreeNodes. Это применяется к Вашему делегату представления схемы или источнику данных - элементы, переданные Вашим методам делегата/источника данных, являются экземплярами NSTreeNode. То же является истиной для NSBrowsers, связанного с NSTreeController и методами делегата браузера. Можно использовать расположение узла (indexPath) в расположенном дереве, выводимом на экран, или базовый объект модели для узла (representedObject) для принятия решений в коде делегата.


Эффективно используя NSTreeNode, NSTreeController также представляет два новых метода для движущихся узлов от одного места до другого.
- (void)moveNode:(NSTreeNode *)node toIndexPath:(NSIndexPath *)indexPath;
- (void)moveNodes:(NSArray *)nodes toIndexPath:(NSIndexPath *)startingIndexPath;
Когда узел будет перемещен от одного расположения до другого, его представленные объекты в новом и старом родителе будут обновлены с помощью Кодирования Значения ключа и childrenKeyPath древовидного контроллера. Вы призваны использовать эти методы, чтобы изменить отношения в дереве, вместо того, чтобы изменить представленные объекты непосредственно. Это гарантирует лучшую обработку выбора и улучшится, обрисовывают в общих чертах возможность представления поддержать элемент «расширенное» состояние.

NSTreeNodes может использоваться за пределами NSTreeController для поддержания оперативного дерева объектов. Когда создается за пределами древовидного контроллера, древовидные узлы не имеют понятия childrenKeyPath и так автоматически не обновляйте отношения их объектов модели.

Средство доступа NSTreeController selectedObjects, не точное если не объекты удаления через NSTreeController, удаляет:

Существует известная ошибка в selectedObjects средстве доступа NSTreeController, означающем, что при определенных обстоятельствах, содержание selectedObjects точно не отражает выбор контроллера. Когда объект удален путем видоизменения отношения одного из объектов модели treeController вместо того, чтобы использовать deleteObjectAtArrangedIndexPath, это может произойти: метод того, чтобы удалять: метод IBAction. Если эта ошибка влияет на Вас, потенциальное обходное решение должно заменить использование кода как
[treeController selectedObjects]
с кодом как
[[treeController selectedNodes] valueForKey:@"representedObject"]
Это произведет массив, точно представляющий выбранные объекты treeController, даже если объекты удалены через управление контейнерами отношения объектов модели.


NSArrayController

NSArrayController теперь имеет API к автоматически re-sort/filter массивы содержания, когда изменяются объекты в нем.
- (void)setAutomaticallyRearrangesObjects:(BOOL)flag;    // default: NO
- (BOOL)automaticallyRearrangesObjects;
- (NSArray *)automaticRearragementKeyPaths;
Этот метод возвращает массив ключевых путей, инициировавших автоматическую реконструкцию от дескрипторов вида и фильтрующих предикаты; подклассы могут переопределить этот метод для настройки поведения по умолчанию (например, если дополнительные критерии расположения используются в пользовательских реализациях-rearrangeObjects).
- (void)didChangeArrangementCriteria;
Этот метод вызывается самим контроллером когда любые критерии расположения изменения объектов (дескрипторы вида или предикаты фильтра) для сброса ключевых путей для автоматической реконструкции; если дополнительные критерии расположения используются в пользовательских реализациях-rearrangeObjects и тех критериев изменение, подклассы должны вызвать этот метод.


NSObjectController setUsesLazyFetching:

NSObjectController и его подклассы, когда в режиме объекта, могут теперь выбрать «лениво». С включенным поведением контроллер попытается выбрать только мелкую сумму данных от доступных персистентных хранилищ. Это может обеспечить огромное улучшение использования памяти при контакте с большим количеством данных по диску, но просто подмножество тех данных должно быть в памяти.

Когда установлено для использования ленивой выборки контроллер выберет объекты в пакетах - объем партии по умолчанию равняется 96. Можно изменить объем партии по умолчанию для приложения путем установки значения для пользовательское значение по умолчанию «com.apple. CocoaBindings. LazyFetchBatchSize». Если Вам обяжут табличные представления с набором контроллера массива использовать ленивую выборку, то размер объема партии контроллера будет расти, как растет видимое количество строки табличных представлений.

Добавьте, Вставьте, и операции Remove на контроллере, что ленивая выборка использования ведет себя так же к тем же операциям на регулярном контроллере. Различие - то, что это быстрее для сортировки arraycontroller использование ленивой выборки если
- все ключи в массиве sortDescriptors моделируются, не переходные свойства
- все селекторы в массиве sortDescriptors, выдержите сравнение: или caseInsensitiveCompare:
- в контексте управляемого объекта контроллера нет никаких изменений


Уведомления KeyValueObserving для IBOutlets во время загрузки Пера

До 10,5, когда переменная экземпляра выхода была установлена на объекте во время Ниба, загружающегося, не будет отправлено никакое соответствующее уведомление KVO. Это означало, что зарегистрировал наблюдателей KVO, и привязка не будет уведомлена, что изменился наблюдаемый ivar. Это могло привести к плохому поведению или выводящий на экран устаревшие данные.

Когда переменная экземпляра IBOutlet будет установлена во время Ниба, загружающегося, для приложений, соединенных на или после 10.5, наблюдатели получат уведомления KVO. Наблюдатели должны ожидать получать уведомления KVO для наблюдаемого объекта, прежде чем вызовут awakeFromNib метод наблюдаемого объекта.


NSAccessibility

Интеграция какао/Углерода

В Leopard информация доступности Какао теперь правильно сообщается для окон Cocoa, используемых в приложении Углерода, а также представлениях Какао, встроенных в окна Carbon через новый Углерод HICocoaView.

Доступность панели инструментов

Основанные на изображении элементы панели инструментов всегда появлялись в иерархии доступности как единственный AXButton с меткой элемента панели инструментов, служащего AXTitle кнопки. В Leopard определенные конфигурации основанных на представлении элементов панели инструментов будут также представлены автоматически в иерархии доступности этим способом:
- Представление элемента является NSButton, сообщающим о себе доступности как AXButton.
- Представлением элемента является NSSegmentedControl с единственным сегментом.
- Группа элемента панели инструментов имеет NSSegmentedControl как свое представление и имеет то маркированный подэлемент на сегмент.

Для основанных на представлении элементов панели инструментов, не вписывающихся в эти особые случаи, метка элемента панели инструментов будет автоматически присоединена к представлению элемента как к AXTitleUIElement в Значке и текстовом режиме отображения, и как режим AXDescription in Icon Only представления.

Новые константы доступности

NSAccessibilityGridRole является ролью, которая должна использоваться для пользовательских интерфейсов как миниатюры и браузеры носителей, представляющие сетку элементов. Дочерним элементам сетки упорядочивают. Сетка походит на список доступности с добавлением трех новых атрибутов: NSAccessibilityRowCountAttribute и NSAccessibilityColumnCountAttribute, возвращающие число строк и столбцов в сетке, соответственно и NSAccessibilityOrderedByRowAttribute, возвращающем значение булевого числа, указывающее, упорядочивают ли дочерним элементам крупнейшую строку, или главный столбец.

NSAccessibilityTimelineSubrole является подролью NSAccessibilitySliderRole и должен использоваться для временных шкал носителей, таких как фильм в формате QuickTime или воспроизведение аудио и воспроизведение видео и редактирующие средства управления. Временная шкала может иметь многократные стоимостные показатели как дочерние элементы для представления различных маркеров на временной шкале - например, текущее время, в точке, и точка для редактирования видео. Если многократные стоимостные показатели присутствуют, у каждого должно быть описание доступности.

Когда значение элемента не предоставляет достаточно информации для вспомогательных приложений, дополнительный NSAccessibilityValueDescriptionAttribute атрибута должен использоваться. Например, ползунки в энергетической предпочтительной области Средства сохранения представляют значения, включающие «1 минуту», «1 час», «2 часа 20 минут», и «никогда». Числовое значение ползунка не передает эту информацию, таким образом, должен использоваться дополнительный атрибут описания значения. Строковые значения атрибута должны быть локализованы, нижний регистр, и максимально краткие для передачи информации.

Дополнительный атрибут NSAccessibilitySelectedTextRangesAttribute возвращает массив диапазонов выделенного текста. NSTextView поддерживает выбор многократных диапазонов текста, а также этого нового дополнительного атрибута. Существующий NSAccessibilitySelectedTextRangeAttribute все еще возвращает первый выбранный текстовый диапазон.

NSAccessibilityDisclosureTriangleRole является новой ролью доступности для треугольников раскрытия.


NSColor

Выяснение colorWithAlphaComponent: на NSDeviceRGBColorspace и NSDeviceWhiteColorSpace цвета возвратили бы результаты в своих калиброванных дубликатах. Это было теперь фиксировано.


NSColorSpace

NSColorSpace теперь имеет методы, чтобы создать из и возвратить CGColorSpace. Если NSColorSpace не может быть представлен как CGColorSpace, Обратите внимание на то, что метод для возврата CGColorSpace мог бы возвратить NULL. Кроме того, создание NSColorSpace от CGColorSpace не гарантирует будущих идентификационных данных указателя CGColorSpace.

NSColorSpace также имеет методы для возврата sRGB и цветовых пространств Adobe1998.

Утечка CMProfileRef была фиксирована в - [NSColorSpace initWithICCProfileData:].


NSColorPanel

Протокол NSColorPickingCustom теперь позволяет указать подсказку для кнопки на панели инструментов:
- (NSString *)buttonToolTip;
и установка минимального размера для Вашего средства выбора:
- (NSSize)minContentSize;
NSColorPanel не позволит изменять размеры меньший, чем этот размер. По умолчанию, если Вы должным образом устанавливаете атрибуты автокалибровки в IB для Вашего представления, Вы ничего не должны будете делать.


Службы

У нас теперь есть много NSErrors для создания отчетов об ошибках служб. Как другой NSErrors в NSCocoaErrorDomain, эти ошибки прибывают готовые с презентабельными пользователем сообщениями об ошибках, и по большей части они будут автоматически пузыриться до пользователя через ошибочное машинное оборудование представления Какао, таким образом, не будет необходимо никакое действие разработчика. Отдельные коды ошибки могут быть найдены в AppKitErrors.h.

NSUpdateDynamicServices () функция функционален в Leopard. Когда NSUpdateDynamicServices () вызывают, приложения должны сразу видеть обновленные службы, не будучи должен быть завершенными и повторно запущенными. Службы также обновляются при входе в систему.


NSScroller

Помочь улучшить однородность API,-setFloatValue:knobProportion NSSCROLLER: метод осуждается в пользу использования отдельного-setDoubleValue: и-setKnobProportion: средства доступа, добавленные в Leopard. Для поддержания совместимости на уровне двоичных кодов AppKit будет продолжать вызывать переопределения-setFloatValue:knobProportion:. Код, который предназначается для Mac OS 10.5 и позже должен использовать-setDoubleValue: и-setKnobProportion: вместо этого, и устраните любые переопределения-setFloatValue:knobProportion:. Код, который должен остаться совместимым с Mac OS 10.4 и ранее должен продолжать использовать-setFloatValue:knobProportion:.


NSUserInterfaceValidations

Объявления интерфейса для NSApplication, NSButton, NSDocument, NSDocumentController, NSMatrix, NSMovieView, NSTableView, NSTextField и NSWindow теперь правильно показывают свое соответствие протоколу NSUserInterfaceValidations.


NSTabView

До Leopard NSTabViewItem, добавленный к многократным представлениям вкладки, произведет несоответствия. Для основанных приложений или после Leopard, элементы представления вкладки автоматически удалены из старого представления вкладки, когда добавлено к новому.


Изменения поведения NSLevelIndicator

До Mac OS X 10.5, NSLevelIndicatorCell проигнорировал свой доступный для редактирования флаг; все ячейки были эффективно доступны для редактирования. В 10,5 мы обращаем внимание на флаг для приложений, соединенных на Leopard и позже. Значение по умолчанию - [NSLevelIndicator isEditable] и было нет, таким образом, необходимо явно установить флаг для ячеек, которые должны быть доступными для редактирования.


NSRulerView

В прошлом метод-moveRulerlineFromLocation:toLocation: сразу обработанное получение для временных строк на линейке, которая могла вызвать ухудшение производительности, когда временные линии были проведены в сочетании с автоматической синхронизацией луча. Теперь, временные линии проведены во время-drawRect:.

Использование-moveRulerlineFromLocation:toLocation: остается неизменным с несколькими протестами. Каждое расположение новой строки нарисовано не больше, чем один раз. Нет, однако, теперь никакой гарантии, что каждое расположение новой строки будет нарисовано - если определенное расположение будет установлено быть нарисованным и затем установленным быть стертым прежде-drawRect: происходит, то расположение никогда не рисуется. Кроме того, любой подкласс, использующий значение по умолчанию-moveRulerlineFromLocation:toLocation: но реализации-drawRect: должен будет переопределить-moveRulerlineFromLocation:toLocation: обработать строку линейки, подходящую к концу их собственный-drawRect: метод.


NSBrowser

NSBrowser теперь поддерживает перетаскивание. Посмотрите пример приложения AppKit «SimpleBrowser» для примера того, как использовать API и считать комментарии в NSBrowser.h. API очень подобен перетаскиванию API для NSTableView.


NSTokenField

NSTokenField был переписан, и были исправлены многочисленные ошибки. Маркеры теперь показывают значок выпадающего меню независимо от состояния выбора. Приложения могут установить предпочтительную установку NSTokenAttachmentUsesDynamicPulldownIcon для сохранения поведения перед Leopard.


NSGraphicsContext

NSGraphicsContext теперь имеет цвет, представляющий поглощенный API:
- (NSColorRenderingIntent)colorRenderingIntent;
- (void)setColorRenderingIntent:(NSColorRenderingIntent)renderingIntent;

NSBezierPath

Существуют теперь удобные методы для создания округленных прямоугольных контуров:
+ (NSBezierPath *)bezierPathWithRoundedRect:(NSRect)rect xRadius:(CGFloat)xRadius yRadius:(CGFloat)yRadius;
- (void)appendBezierPathWithRoundedRect:(NSRect)rect xRadius:(CGFloat)xRadius yRadius:(CGFloat)yRadius;

- containsPoint: метод теперь соблюдает вьющееся правило, возвращенное из-windingRule.


NSProgressIndicator

NSProgressIndicatorSpinningStyle и определенные индикаторы хода выполнения теперь представляют стиль круга определенный индикатор, найденный в Почте и XCode. Индикаторы хода выполнения стиля вращения теперь должным образом используют увеличенные изображения для рендеринга NSRegularControlSize. Приложения, динамично создающие индикаторы хода выполнения для 16x16 изображение теперь, должны явно установить размер элемента управления в NSSmallControlSize.

Потоковая настройка анимации для недавно создаваемых индикаторов идет по умолчанию теперь независимо от стиля.


NSWorkspace

Метод NSWorkspace selectFile: inFileViewerRootedAtPath: больше не следует за символьными ссылками. Это теперь покажет символьную ссылку в Средстве поиска вместо того, на что это указывает. Если Вы хотите показать соединенный файл, используйте - [NSString stringByResolvingSymlinksInPath] для разрешения любых символьных ссылок прежде, чем вызвать метод NSWorkspace.

setIcon: forFile: опции: метод на NSWorkspace установит 512x512 значки, если NSExclude10_4ElementsIconCreationOption не будет установлен в опциях.

Метод NSWorkspace getFileSystemForPath: isRemovable: isWritable: isUnmountable: описание: введите: теперь возвращает значимые значения в описании: и type:. (До Leopard эти значения всегда были нолем.)


NSMovie/NSMovieView в 64-разрядном

Для 64-разрядного NSMovie и NSMovieView были осуждены в пользу QTMovie QTKIT и QTMovieView. Однако, потому что NSMovies может существовать в архивах, которые, возможно, должны быть считаны или записаны 64-разрядными приложениями, ограниченная функциональность была предусмотрена NSMovie в 64-разрядном для включения этого.

NSMovies может быть разархивирован в 64-разрядном как ожидалось, но из-за отсутствия NSMovieView, они не полезны самостоятельно. Для упрощения перехода к QTMovie и QTMovieView существующий-QTMovie метод на NSMovie был изменен для возврата ссылки на объект QTMovie в 64-разрядном. Этот экземпляр QTMovie содержит те же данные фильма, которые содержал исходный NSMovie.

В назад целях совместимости NSMovie может быть создан в 64-разрядном использовании-initWithMovie: метод, измененный для 64-разрядного для принятия экземпляра QTMovie. Архивы, содержащие эти объекты NSMovie, назад совместимы с NSMovies в 32-разрядном.

Обратите внимание на то, что NSMovie в 64-разрядном не поддерживает фильмы, на которые ссылается URLs.-initWithCoder: должным образом считает архивы, содержащие эти фильмы, но возвратит ноль вместо допустимого объекта NSMovie.


TextEdit

Приложение TextEdit в 10,5 было изменено для использования NSDocument. Это таким образом обеспечивает много опций, предоставленных или активированных NSDocument, таких как корректное отслеживание файла и автоматическое сохранение. Кроме того, это продолжает быть витриной для текстовой системы Какао и выделяет многие свои новые функции. Можно найти больше информации в файле README в/Developer/Examples/AppKit/TextEdit.


«открытый» лакомый кусочек

Спасибо за чтение настолько далеко! Если Вы - пользователь Терминальной или командной строки, несомненно, проверят некоторые новые функции в «открытом». Например, «открываются,-h» будет теперь искать и открывать заголовочные файлы в XCode (или Ваш редактор по умолчанию для заголовочных файлов).



Отмечает определенный для Mac OS X 10.4

Новые функции AppKit в Тайгере

Следующее является некоторыми новыми функциями в Тайгере.


Основа:

Часть другого нового Mac OS X APIs для знания:



NSDatePicker и NSDatePickerCell

AppKit имеет новую дату/контроль времени, API которой объявляется в NSDatePicker.h и NSDatePickerCell.h. В настоящее время эта пара класса обеспечивает два стиля даты/контроля времени: «текстовое поле и степпер» стиль, который подобен знакомому управлению «ClockDate» Углерода, и графическим «часам и календарю» вариант как те, которые появляются в «Дате и Время» панель System Preferences.

Средство выбора даты «objectValue» является NSDate. «-DateValue/-setDateValue»: пара средства доступа обеспечивает специфичный для типа эквивалент наследованному «-objectValue/-setObjectValue»: методы.

Средство выбора даты дополнительно имеет в настоящее время не использующиеся атрибут «режима» и атрибут «timeInterval». Эти атрибуты существуют для поддержки возможности режима управления «диапазона дат» в будущем. Временной интервал не применим, и всегда обнуляйте, когда управление находится в NSSingleDateMode (единственный режим, поддерживаемый в настоящее время предоставляемыми стилями управления). В NSRangeDateMode это укажет продолжительность диапазона, расширяющегося вперед своевременно от dateValue ячейки.

Атрибут «datePickerElements» экземпляра определяет, какие компоненты его значения он считает specified/specifiable. Эта установка составлена поразрядным осуществлением операции ИЛИ вместе один или больше значений «DatePickerElementFlag», объявленных в NSDatePickerCell.h. Это влияет и на дисплей и на поведение редактирования, как подходящие для стиля управления датой в использовании.
typedef unsigned int NSDatePickerElementFlags;
enum {
/* Time Elements */
NSHourMinuteDatePickerElementFlag = 0x000c,
NSHourMinuteSecondDatePickerElementFlag = 0x000e,
NSTimeZoneDatePickerElementFlag    = 0x0010,
    /* Date Elements */
NSYearMonthDatePickerElementFlag    = 0x00c0,
NSYearMonthDayDatePickerElementFlag    = 0x00e0,
NSEraDatePickerElementFlag        = 0x0100,
};
Для случая, где часть «времени» значения даты не имеет интереса, например, это могло быть установлено в NSYearMonthDayDatePickerElementFlag. NSTimeZoneDatePickerElementFlag и NSEraDatePickerElementFlag были объявлены для возможного будущего использования и еще не имеют никакого эффекта.

Средство выбора даты также имеет «календарь», «локаль» и «часовой пояс», которые влияют на отображение даты и редактирование. У Тигра функциональность средства выбора даты поддерживает Грегорианское отображение даты формата и редактирование только, но календарь и настройки локали будут использоваться для поддержки других календарей и форматов даты в будущем.

Средство выбора даты имеет «minDate» и «maxDate», который может использоваться для наложения простого ограничения диапазона на возможные значения, которые может принять средство выбора даты. (Оба значения по умолчанию к нолю, означая, что значение даты неограничено.) Клиенты могут наложить более сложные ограничения в дополнение к этому основному ограничению диапазона путем обеспечения объекта делегата, проверяющего предложенные изменения в значении ячейки. Средство выбора даты никогда не позволяет себе входить в состояние, где его текущая стоимость не удовлетворяет ограничения, наложенные minDate, maxDate, и методом проверки делегата (если предоставленный). Его-setObjectValue:/-setDateValue: и-setTimeInterval: средства доступа аналогично ограничат свои полученные параметры к допустимым значениям.

Подпись дополнительного метода делегата:
- (void)dateCell:(NSDatePickerCell *)aDatePickerCell
validateProposedDateValue:(NSDate **)proposedDateValue
timeInterval:(NSTimeInterval *)proposedTimeInterval;
Если средству выбора даты присвоят делегата ему, и делегат реагирует на этот селектор, то этот метод будет вызван каждый раз, когда пользователь пытается внести изменение в значение средства выбора даты, давая делегату возможность утвердить, изменить, или отклонить изменение.

«proposedDateValue» указывает на предложенный новый dateValue. «proposedTimeInterval» указывает на предложенный новый timeInterval, который всегда будет нулем, если ячейка не будет в NSDateRangeMode. Конструкторы могут счесть полезным консультироваться с текущим dateValue NSDatePickerCell и timeInterval для сравнения, определить, какое из этих значений (потенциально один или оба) ячейка предлагает изменить.

На записи в этот метод делегата запуск и конечные точки предложенного диапазона, как гарантируют, будут находиться между minDate NSDatePickerCell, и maxDate, и *proposedTimeInterval, как гарантируют, будет неотрицательным. Делегат может уехать *proposedDateValue нетронутый, чтобы принять его или заменить его указателем на другой экземпляр NSDate. (Заменяющее значение должно быть автовыпущено или иначе не потребовать последующей версии.) Аналогично, этот метод может оставить proposedTimeInterval нетронутое, чтобы принять его или заменить его значение через предоставленный указатель.


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

Существует новое маркерное полевое управление, ведущее себя как поле адреса в Mail.app. Новые поддержки виджета, маркирующие на основе набора символов (запятая по умолчанию) и на редактировании конца. Кроме того, если запятая находится в наборе символов маркирования, мы присоединяемся к маркерам для множественного выбора с помощью запятой; Иначе, мы присоединяемся к пространству. Мы вызываем текстовое завершение после указанной задержки.

Маркеры перемещаемы. По умолчанию мы помещаем маркеры на область монтажа с помощью NSStringPboardType (присоединенный таким же образом как выбор со множественным маркерным доступом).

Используйте setObjectValue NSCONTROL/NSCELL: метод для установки массива маркерного поля представленных объектов. Если массив содержит объекты кроме Нсстрингса, необходимо реализовать tokenField:displayStringForRepresentedObject: метод делегата.

Известные проблемы NSTokenField:
- NSTokenFieldCell не полностью функциональны в NSTableView/Matrix.
- Ячейка NSTokenField должна быть подклассом NSTokenField.

См. NSTokenField.h и NSTokenFieldCell.h для полного API.


NSLevelIndicator/NSLevelIndicatorCell

Существует теперь управление индикатором уровня и соответствующий класс ячейки. Это управление может вывести на экран один из 4 стилей способности, ранжирования или уместности. Полный стиль может или быть непрерывным или дискретным. Занимающее место появление подобно ранжированию 'звезд' iTunes, и ранжирование уместности может использоваться для отображения поиска, занимающего место в таблице.

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

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

По умолчанию изображение ячейки является нолем, но если-setImage: это заменяет звезды по умолчанию пользовательским изображением для стиля NSRatingLevelIndicatorStyle. Установка изображения не имеет никакого эффекта на другие стили. Изображение освещается для выделенного выбора, и точки для пустых спотов все еще нарисованы. Изображение не расширяется, никакое пространство не добавляется между изображениями.

Посмотрите ячейку для описаний методов управления:
@interface NSLevelIndicator : NSControl
- (double)minValue;
- (void)setMinValue:(double)minValue;
- (double)maxValue;
- (void)setMaxValue:(double)maxValue;
- (double)warningValue;
- (void)setWarningValue:(double)warningValue;
- (double)criticalValue;
- (void)setCriticalValue:(double)criticalValue;
- (NSTickMarkPosition)tickMarkPosition;
- (void)setTickMarkPosition:(NSTickMarkPosition)position;
- (int)numberOfTickMarks;
- (void)setNumberOfTickMarks:(int)count;
- (int)numberOfMajorTickMarks;
- (void)setNumberOfMajorTickMarks:(int)count;
- (double)tickMarkValueAtIndex:(int)index;
- (NSRect)rectOfTickMarkAtIndex:(int)index;
@end
Вот объявление ячейки:
enum {
NSRelevancyLevelIndicatorStyle,
NSContinuousCapacityLevelIndicatorStyle,
NSDiscreteCapacityLevelIndicatorStyle,
NSRatingLevelIndicatorStyle
} NSLevelIndicatorStyle;
@interface NSLevelIndicatorCell : NSActionCell
- (id)initWithLevelIndicatorStyle:(NSLevelIndicatorStyle)levelIndicatorStyle;
Создайте новую ячейку со стилем индикатора. Значением по умолчанию для-init является NSRelevancyLevelIndicatorStyle. Значение по умолчанию и минимальное значение 0, максимальное значение по умолчанию зависит от стиля. Для непрерывных стилей максимум 100.0. Для дискретных это 5.0
- (void)setLevelIndicatorStyle:(NSLevelIndicatorStyle)levelIndicatorStyle;
- (NSLevelIndicatorStyle)levelIndicatorStyle;
Получите/дисплей аппарата стиль. Не будет влиять на значения. Установка уведомит управление включением для обновления.
- (double)minValue;
- (void)setMinValue:(double)minValue;
- (double)maxValue;
- (void)setMaxValue:(double)maxValue;
Это те же имена методов как NSSlider и минута набора / макс. значения для ранжирования. Установка уведомит управление включением для обновления.
- (double)warningValue;
- (void)setWarningValue:(double)warningValue;
- (double)criticalValue;
- (void)setCriticalValue:(double)criticalValue;
Они устанавливают и получают 'предупреждение' и 'критические' значения, куда индикатор идет от зеленого до желтого к красному. Порядок значений определяет, какая сторона является зеленой и какая сторона является красной. Если критическое значение больше, чем значение предупреждения, то индикатор является зеленым ниже предупреждения, желтым выше этого, но ниже критического, и красный выше. Если критическое значение является меньше, чем значение предупреждения, индикатор является красным, когда значение ниже критического значения, желтого до критического значения, и затем зеленого к максимальному значению. Если значения являются тем же, индикатор является всегда зеленым.
- (void)setTickMarkPosition:(NSTickMarkPosition)position;
- (NSTickMarkPosition)tickMarkPosition;
- (void)setNumberOfTickMarks:(int)count;
- (int)numberOfTickMarks;
- (NSRect)rectOfTickMarkAtIndex:(int)index;
- (double)tickMarkValueAtIndex:(int)index;
Эти методы для меток идентичны NSSliderCell APIs с тем же поведением. Определите номер галочек к 0 для не имения любого. Значение по умолчанию 0. Если индекс вне диапазона, исключение повышено. Установка уведомит управление включением для обновления при необходимости.
- (void)setNumberOfMajorTickMarks:(int)count;
- (int)numberOfMajorTickMarks;
Мы также позволяем большие или 'главные' метки. Количество должно быть меньше чем или равно числу меток. Установка уведомит управление включением для обновления при необходимости. Главные метки будут нарисованы вместо незначительных.


Разрешение независимый UI

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

В AppKit мы намереваемся сконцентрироваться на «платформе, масштабирующей» модель (как описано в «Разрешении Независимый UI» информация о версии), который окнами причин по умолчанию, которые будут масштабироваться. Одно коренное изменение в этом режиме - то, что при рисовании на экран, 1 точка в основной системе координаты окна больше не является обязательно тем же как 1 пикселем в запоминающем устройстве окна. Несмотря на то, что мы предназначаем большую часть поддержки этого режима, который будет предоставлен AppKit, существуют некоторые вещи, которые приложения должны будут сделать сами или не упустить, как обрисовано в общих чертах ниже.

Для тестирования разработчики могут изменить разрешение дисплея с помощью Кварцевого приложения Отладки (расположенный в папке Инструменты/Developer/Applications/Performance). Обратите внимание на то, что, потому что работа для поддержки независимости разрешения и в Какао и в Углероде является продолжающейся, и еще не завершитесь, существуют различные проблемы получения при выполнении с неинтегральными масштабными коэффициентами в Тайгере. Когда Кварц 2D Предельное ускорение включен, это - особенно истина.

Применение масштабного коэффициента

Windows масштабируется с помощью трансформации в системе координат высокоуровневого представления (frameView). Размерности кадра frameView равны размерностям рамки окна, как в немасштабированном случае, но размерности границ frameView масштабируются путем деления размерностей кадра scaleFactor. Для неинтеграла scaleFactors, кадр сохранен интегралом, но границам позволяют иметь дробный компонент. Так, например, 100x100 окно будет иметь frameView, границы которого 80x80 для userSpaceScaleFactor 1,25. Мы полагаем, что рамка окна находится в пикселях и границах frameView, чтобы быть в точках. Рисование в содержании окна тогда сделано в точках. Обратите внимание на то, что это подразумевает, что все представления в окне масштабируются, но мы решили, что представления, чьи только масштабирование является этой основой, масштабирующейся в целях независимости разрешения, возвратятся НЕ из-isRotatedOrScaledFromBase, так, чтобы прокрутка, и т.д. будет продолжать проходить через быстрый путь.

Импликации для расположения представления и калибровки окна

Приложения не должны предполагать, что рамка окна и содержавшие кадры представления используют те же системы координат. Например, приложения, использующие рамку окна для расположения представлений, не получат корректные результаты. Аналогично, приложения, вычисляющие изменение в рамке окна, базировали выставленный для обозрения размер (например, при добавлении вспомогательного представления) будет неправильным. Один механизм для преобразования между системами координат правильно - [NSView convertRect/Size/Point to/fromView:nil]. Другой - [NSWindow frameRectForContentRect:] и его инверсия - [NSWindow contentRectForFrameRect:].

Изображения

Каждый imageRep, содержащий растровые данные, указывает свой собственный DPI, так как это имеет и размер в точках и пиксельную ширину и высоту. imageRep с 72 DPI имеет корреспонденцию 1-1 между точками и пикселями. imageRep с 144 DPI имеет в два раза больше пикселей, чем точки в обеих размерностях. Мы теперь создаем cachedImage представителей с масштабным коэффициентом целевого окна. Для окна с userSpaceScaleFactor 1,25, cachedImageRep 100x100 точки сообщили бы о размере 100x100, и pixelWidth и pixelHeight 125.

Составление композита

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

Пример 1 - составление композита 72 точек на дюйм 100x100 исходное изображение для просмотра в 1.25x масштабировал окно

72 точки на дюйм 100x100 исходное изображение будут содержать 100x100 пикселей. Когда составлено в 100x100 rect в представлении в масштабированном окне, это изображение будет масштабироваться для заполнения 125x125 пикселей в окне с помощью надлежащего алгоритма интерполяции. Любая координата преобразовывает на целевом представлении кроме масштабирования окна, будет проигнорирован.

Пример 2 - составление композита 90 точек на дюйм 100x100 исходное изображение для просмотра в 1.25x масштабировал окно

90 точек на дюйм 100x100 исходное изображение будут содержать 125x125 пикселей. Когда составлено в 100x100 rect в представлении в масштабированном окне, это изображение точно приспособит 125x125 пикселей в окне, таким образом, не будет необходима никакая интерполяция. Любая координата преобразовывает на целевом представлении кроме масштабирования окна, будет проигнорирован.

Пример 3 - создание кэшируемой репутации изображения от 72 точек на дюйм 100x100 исходное изображение

72 точки на дюйм 100x100 исходное изображение будут содержать 100x100 пикселей. Кэшируемая репутация изображения будет создаваться с размером 100x100, но будет содержать 125x125 пикселей. Исходное изображение будет масштабироваться для адаптации размеру пикселя кэшируемой репутации изображения, с помощью надлежащей интерполяции. Когда кэшируемая репутация изображения будет позже вовлечена в масштабированное окно, это будет от 1 до 1 копии от кэшируемых пикселей репутации изображения до целевых пикселей окна.

Контакт с неинтегральными координатами представления

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

API для «режима» масштабирования приложения

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

Это - значение по умолчанию, масштабирующееся от пространства пользователя до пространства устройства на данном экране:
@interface NSScreen : NSObject
...
- (float)userSpaceScaleFactor
...
@end
Так как масштабному коэффициенту применяются к отдельные окна, мы также обеспечиваем метод для выяснения у окна его масштабирование. По умолчанию этот масштабный коэффициент будет равен масштабному коэффициенту NSScreen, на котором окно создавалось, или самый высокий масштабный коэффициент доступного NSScreens, если никакой экран не был указан во время создания. (Обратите внимание на то, что для обозримого будущего масштабный коэффициент всего NSScreens будет равен в любой момент времени):
@interface NSWindow : NSResponder
...
- (float)userSpaceScaleFactor
...
@end
Могло бы также быть необходимо позволить создание окон без масштабного коэффициента, специально для пользовательских окон. Можно создать немасштабированное окно путем указания styleMask NSUnscaledWindowMask во время создания.

Немасштабированное окно тогда возвратилось бы 1.0 для-userSpaceScaleFactor.

Влияние на существующий API

И NSWindow и NSScreen определяют-deviceDescription метод, Этот метод возвращает NSDictionary, содержащий ключ NSDeviceResolution. NSDeviceResolution исторически содержал NSSize (72.0, 72.0). В масштабированной системе NSDeviceResolution будет содержать NSSize (72.0*userSpaceScaleFactor, 72.0*userSpaceScaleFactor).


NSAnimation

Эта синхронизация реализаций базового класса для анимации в Какао. Существует один подкласс, доступный для анимации представления. Анимация может работать в основном потоке события в блокировании режима (т.е. не возврат, пока не сделано) в неблокировании режима так, чтобы события были все еще приняты и в отдельном частном потоке.
typedef enum {
NSAnimationEaseInOut, /* s-curve, default */
NSAnimationEaseIn,
NSAnimationEaseOut,
NSAnimationLinear
} NSAnimationCurve;
typedef enum {
NSAnimationBlocking,
NSAnimationNonblocking,
NSAnimationNonblockingThreaded
} NSAnimationBlockingMode;
typedef float NSAnimationProgress;                      // value in range 0..1
extern NSString *NSAnimationProgressMarkNotification;   // has single entry in user info dictionary
extern NSString *NSAnimationProgressMark; // NSNumber(float) with NSAnimationProgress
@interface NSAnimation
- (id)initWithDuration:(NSTimeInterval)duration animationCurve:(NSAnimationCurve)animationCurve;
- (void)startAnimation;
- (void)stopAnimation;
- (BOOL)isAnimating;
Запускает и останавливает анимацию. Не сбрасывает прогресс, когда остановлено. Если в прогрессе 1,0, вызывая-startAnimation запускается снова в прогрессе 0.0. Можно играть анимацию без представления, цели или действия. Если режим установлен в NSAnimationBlocking, то-startAnimation только возвращается после того, как анимация работала. Делегат может все еще остановить анимацию при выполнении при необходимости. Когда-startAnimation вызывают, анимация сохраняет себя и затем автовыпущена на-stopAnimation.
- (NSAnimationProgress)currentProgress;
- (void)setCurrentProgress:(NSAnimationProgress)progress;
Установите/получите текущий прогресс (оценивает 0.0... 1.0). Может измениться при выполнении. Из диапазона значения прикрепляются к 0,0 или 1.0. Метод-setCurrentProgress вызывают при игре для изменения прогресса для следующего кадра. Подклассы должны переопределить, чтобы получить значение и сделать их действие. Это действие может быть во вторичном потоке, если требуется.
- (void)setDuration:(NSTimeInterval)duration;
- (NSTimeInterval)duration;
Установите/получите продолжительность эффекта. Продолжительность находится в секундах. Может измениться при выполнении. Отрицательные величины повышают исключение. Если набор продолжительности проходит текущее время, и анимация играет, анимация заканчивается.
- (NSAnimationBlockingMode)animationBlockingMode;
- (void)setAnimationBlockingMode:(NSAnimationBlockingMode)animationBlockingMode;
Установите/получите режим для рабочей анимации. Вступит в силу в следующий раз, когда анимация запускается. Не имеет никакого эффекта если анимация, уже работающая. Значением по умолчанию является NSAnimationBlocking. Если установлено в NSAnimationBlocking, анимация выполняется в основном потоке в пользовательском режиме цикла выполнения, блокирующем UI. Если анимацией является выполненный NSAnimationNonblocking тогда, анимация выполняется в основном потоке в общих режимах цикла выполнения или тех указанных в-runLoopModesForAnimating. NSAnimationNonblockingThreaded порождает новый поток, выполняющий анимацию.
- (void)setFrameRate:(float)framesPerSecond;
- (float)frameRate;
Установите/получите частоту кадров (обновления/секунда) эффекта. Частота кадров не гарантируется. Может быть изменен при выполнении и будет использоваться в следующем кадре. Значение должно быть положительным. Значение 0,0 средних значений максимально быстро (в настоящее время ограничиваемый 30 кадр/с). Отрицательные величины повышают исключение.
- (void)setAnimationCurve:(NSAnimationCurve)curve;
- (NSAnimationCurve)animationCurve;
Установите/получите кривую анимации. Предопределенные кривые линейны, осторожно вводят (замедлитесь, поскольку мы достигаем конца), ослабьте (медленно убыстряются, запускаются), и упростите in/outS-curve. Если делегат реализует-animation:valueforprogress: эта установка проигнорирована. Недопустимые значения повышают исключение.
- (float)currentValue;
Это - текущая стоимость эффекта на основе текущего прогресса. Это получено из кривой анимации или от делегата. Это - установка только для чтения. Подкласс может переопределить этот метод для обеспечения пользовательской кривой. Текущая стоимость может быть меньше чем 0,0 или больше, чем 1,0. Например, позволяя размеру быть больше тогда 1.0, можно было сделать 'резиновый эффект', где временно, размер представления больше, чем финал.
- (void)setDelegate:(id)delegate;
- (id)delegate;
Установите/получите делегата. Это - слабая ссылка - делегат не сохраняется.
- (NSArray *)progressMarks;
- (void)setProgressMarks:(NSArray *)progressMarks;
Они устанавливали/получали все метки прогресса сразу. Массив содержит список NSNumbers, содержащего NSAnimationProgress (плавания). Если нет никакого набора меток прогресса,-progressMarks возвращает пустой массив. Передача в ноле к-setProgressMarks: очистит все метки прогресса..
- (void)addProgressMark:(NSAnimationProgress)progress;
- (void)removeProgressMark:(NSAnimationProgress)progress;
Эти набор и ясные 'метки прогресса'. Они используются, чтобы уведомить делегата или отправить уведомление, что была достигнута определенная точка прогресса. Они могут использоваться для синхронизации анимаций (например, запуск новой анимации, когда первый достиг средней точки.) Если анимация играет, уведомления только отправляются. Их можно вызвать во время игры анимации. Уведомление отправляется, как только точка прогресса передается так, фактический currentProgress может отличаться от точки метки requsted. Допустимые интервалы от 0,0 до 1,0. И 0,0 и 1,0 метки всегда будут, отправляют. Если времена достаточно близки вместе, многократные метки могут быть отправлены во время единственного кадра..
- (void)startWhenAnimation:(NSAnimation *)animation reachesProgress:(NSAnimationProgress)startProgress;
- (void)stopWhenAnimation:(NSAnimation *)animation reachesProgress:(NSAnimationProgress)stopProgress;
- (void)clearStartAnimation;
- (void)clearStopAnimation;
Это соединяет другую анимацию с этим. Когда соединенная анимация достигает определенной точки прогресса, запусков анимации и/или остановок. Можно было только установить одну анимацию как анимацию запуска и один набор как анимация остановки. Установка нового желания уберет старое. Можно также убрать старый с помощью-clearStartAnimation или-clearStopAnimation.
- (NSArray *)runLoopModesForAnimating;
По умолчанию это возвращает ноль. Пользовательский подкласс может переопределить для возврата определенного списка выполненные режимы цикла для выполнения таймера анимации в. Если это возвращает ноль, анимация выполняется в любом значении по умолчанию, модальном, и режимы отслеживания события. Проигнорированный, если режим анимации не установлен в NSAnimationNonblocking.

Методы делегата
- (BOOL)animationShouldStart:(NSAnimation *)animation;
- (void)animationDidStop:(NSAnimation *)animation;
- (void)animationDidEnd:(NSAnimation *)animation;
Когда анимация достигает значения прогресса 1,0, обращенный запускают/останавливают анимацию и.-animationShouldStart: может возвратиться НЕ для отмены запуска.-animationDidStop: когда анимация явно останавливается, вызывается.-animationDidEnd: вызывается, когда это заканчивается путем достижения значения прогресса 1,0. Только вызванный, если фактическое изменение происходит (т.е. не вызовет-animationShouldStart: уже играя)
- (float)animation:(NSAnimation *)animation valueForProgress:(NSAnimationProgress)progress;
Делегат может обеспечить значения пользовательской кривой. прогресс всегда будет от 0,0 до 1,0.
- (void)animation:(NSAnimation *)animation didReachProgressMark:(NSAnimationProgress)progress;
Вызванный, когда анимация достигает ранее отмеченного значения прогресса. Фактический текущий прогресс может пройти, тот передал в. Может также использовать уведомление NSAnimationProgressMarkNotification.


NSViewAnimation

Это - единственный общедоступный подкласс NSAnimation. Это берет массив словарей, копирующихся, и анализирует словарь. Словарь содержит цель, требующуюся и которая может быть окном или представлением. Это берет дополнительный запуск и/или кадр конца который если не определенное использование текущий кадр когда запуски анимации. Это может дополнительно взять эффект, который будет, постепенно появиться или представление или окно. Если цель является представлением, и эффект состоит в том, чтобы постепенно исчезнуть, или кадр конца пуст, представление скрыто в конце. Если эффект состоит в том, чтобы постепенно появиться, и кадр конца непуст, и представление запускается скрытый, это выводится на экран в конце. Если нет никакого эффекта, кадр представления изменяется при анимации. Если цель является окном, в окне так же упорядочивают или. Анимация неблокирует по умолчанию, продолжительность 0,5 секунд и простоты в - изгибается.
APPKIT_EXTERN NSString *NSViewAnimationTargetKey;       // NSWindow* or NSView* (required)
APPKIT_EXTERN NSString *NSViewAnimationStartFrameKey; // NSValue*(NSRect) (optional)
APPKIT_EXTERN NSString *NSViewAnimationEndFrameKey; // NSValue*(NSRect) (optional)
APPKIT_EXTERN NSString *NSViewAnimationEffectKey; // NSString*(effect strings)(optional)
APPKIT_EXTERN NSString *NSViewAnimationFadeInEffect;
APPKIT_EXTERN NSString *NSViewAnimationFadeOutEffect;
@interface NSViewAnimation
- (id)initWithViewAnimations:(NSArray *)viewAnimations;
- (NSArray *)viewAnimations;
- (void)setViewAnimations:(NSArray *)viewAnimations;
@end

Расширения AppKit для поддержки использования CoreImage API (Раздел добавил начиная с WWDC),

Следующий API был добавлен для упрощения более удобного использования функциональности CoreImage приложениями Какао.

Существует новый подкласс NSImageRep, названный NSCIImageRep, позволяющим создать NSImage, ссылающийся на CIImage, как в следующем примере кода:
CIImage ciImage = [aCIFilter valueForKey:@"outputImage"];
CGRect extent = [ciImage extent];
/* Be careful here. A CIImage can have infinite extent. The following is OK only if you know your CIImage is of finite extent. */
NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize(extent.size.width, extent.size.height)];
NSCIImageRep *ciImageRep = [NSCIImageRep imageRepWithCIImage:outputImage];
[image addRepresentation:ciImageRep];
Результирующий NSImage должен быть применимым в любом контексте, где требуется NSImage. CoreImage автоматически представит результат по требованию. Обратите внимание на то, что экземпляры CIImage являются неизменными, поэтому когда изменение внесено в параметр CIFilter, влияющий на выходное изображение фильтра, новый «outputImage» нужно требовать от фильтра и нового NSCIImageRep, созданного из него.

NSCIImageRep.h также добавляет три новых метода к CIImage через категорию. Первое позволяет клиентам создать CIImage из NSBitmapImageRep:
@interface CIImage (NSAppKitAdditions)
- (id)initWithBitmapImageRep:(NSBitmapImageRep *)bitmapImageRep;
Оставление два обеспечивает удобные средние значения для рендеринга всех или части CIImage в текущий NSGraphicsContext. Они ведут себя тождественно к подобным методам в NSImage:
- (void)drawInRect:(NSRect)rect fromRect:(NSRect)fromRect operation:(NSCompositingOperation)op fraction:(float)delta;
- (void)drawAtPoint:(NSPoint)point fromRect:(NSRect)fromRect operation:(NSCompositingOperation)op fraction:(float)delta;
@end
NSGraphicsContext имеет новый метод,-CIContext, который возвращает связанный CIContext, который может использоваться для рендеринга в NSGraphicsContext. CIContext создается по требованию и остается существующим для времени жизни его владения NSGraphicsContext. При желании CIContext можно попросить освободить ресурсы, которые он содержит путем отправки ему сообщения-clearCaches или-reclaimResources.

Новые методы были добавлены для упрощения преобразования между NSColor, и типы CIColor (объявления находятся в NSColor.h):
@interface NSColor (NSQuartzCoreAdditions)
+ (NSColor *)colorWithCIColor:(CIColor *)color;
@end
@interface CIColor (NSAppKitAdditions)
- (id)initWithColor:(NSColor *)color;
@end
NSColor может быть преобразован в CIColor, пока это не цвет образца. CIColor может всегда преобразовываться в NSColor.

См. Базовую документацию Изображения для получения дополнительной информации об использовании Базовой функциональности Изображения.


Новое Находящееся в NSResponder Ошибочное Представление (Раздел добавил начиная с WWDC),

Новый механизм был добавлен к Какао для включения удобных для пользователя ошибочных предупреждений, которые информативны, пользуются надлежащим преимуществом листов и легко настраиваемы. Какао предоставляет настройку путем публикации переопределяемого метода NSResponder и метода делегата NSApplication, который может быть реализован. Такой метод будет обычно исследовать переданный - в объекте NSError и, с помощью домена NSERROR и кодировать для определения, какая ошибка состоит в том, чтобы быть представлена, возвратите различный объект NSError в подходящих случаях. Существующий атрибут underlyingError NSERROR делает выполнимым заменить один NSError другим, который более презентабелен, не уничтожая информации об исходной обнаруженной причине проблемы.

Иногда является надлежащим подарить пользователю опции восстановления после ошибки и действовать соответственно после того, как пользователь выбрал одну из опций. Например, NSDocument, когда сохраненный документ, как находят, заблокирован, может предложить переопределять блокировку и сохранять так или иначе (это не делает хотя в Тайгере). Какао поддерживает этот вид функциональности с localizedRecoverySuggestion, localizedRecoveryOptions и атрибутами recoveryAttempter, добавленными к классу Основы NSError и которые соблюдают различные классы AppKit, торгующие NSErrors. Посмотрите раздел «NSError» информации о версии Основы.

Три новых метода были добавлены к классу NSResponder:
- (void)presentError:(NSError *)error modalForWindow:(NSWindow *)window
delegate:(id)delegate didPresentSelector:(SEL)didPresentSelector contextInfo:(void *)contextInfo;
Представьте ошибочное предупреждение пользователю как модальная документом панель. Когда пользователь отклонил предупреждение, и любое восстановление, возможное для ошибки и выбранное пользователем, было опробовано, отправьте выбранное сообщение указанному делегату. Метод, выбранный didPresentSelector, должен иметь ту же подпись как:
- (void)didPresentErrorWithRecovery:(BOOL)didRecover contextInfo:(void *)contextInfo;
Реализация по умолчанию этого метода всегда вызывает [сам willPresentError:error], чтобы дать подклассификаторам возможность настроить ошибочное представление. Если существует никакой следующий респондент, NSApp, это тогда передает сообщение, передавая специализированную ошибку, следующему респонденту или. Переопределение NSAPPLICATION этого метода вызывает [[NSAlert alertWithError:theErrorToPresent] beginSheetModalForWindow:window modalDelegate:self didEndSelector:selectorForAPrivateMethod contextInfo:privateContextInfo]. Когда пользователь отклонил предупреждение, восстановление ошибки attempter отправляется-attemptRecoveryFromError:optionIndex:delegate:didRecoverSelector:contextInfo: сообщение, если ошибка имела опции восстановления и делегата восстановления.

Ошибки, для которых ([[ошибочный домен] isEqualToString:NSCocoaErrorDomain] && [код ошибки] == NSUserCancelledError) особый случай, потому что они фактически не представляют ошибки и не должны быть представлены как таковые пользователю. Переопределение NSAPPLICATION этого метода не представляет предупреждение пользователю для этих видов ошибок. Вместо этого это просто вызывает делегата, указывающего didRecover == НЕТ.

Между цепочкой респондента в типовом приложении и различными переопределениями этого метода в классах AppKit, объектам дают возможность представить ошибки в заказах как они:

Для окон, принадлежавших документам:
представление-> суперпредставления-> окно-> контроллер окна-> документ-> контроллер документа-> приложение

Для окон, имеющих контроллеры окна, но не связанных с документами:
представление-> суперпредставления-> окно-> контроллер окна-> приложение

Для окон, не имеющих никакого контроллера окна вообще:
представление-> суперпредставления-> окно-> приложение

Можно вызвать этот метод для представления ошибочных листов предупреждения. Например, собственное Какао - [NSDocument saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo:] вызывает этот метод, когда он только что вызвал-saveToURL:ofType:forSaveOperation:error: и тот метод возвратился НЕТ.

Вы, вероятно, не должны переопределять этот метод, потому что у Вас нет способа надежного предсказания, будет ли этот метод по сравнению с-presentError вызван для определенной ошибки. Необходимо вместо этого переопределить-willPresentError: метод, описанный ниже.
- (BOOL)presentError:(NSError *)error;
Представьте ошибочное предупреждение пользователю, как модальная приложением панель, и возвратите YES, если восстановление после ошибки было сделано, НЕТ иначе. Этот метод ведет себя во многом как предыдущий кроме него, не возвращается, пока пользователь не отклонил предупреждение и, если ошибка имела опции восстановления и делегата восстановления, делегат восстановления ошибки был отправлен-attemptRecoveryFromError:optionIndex: сообщение.

Можно вызвать этот метод для представления ошибочных диалоговых окон предупреждения. Например, Какао, собственное [NSDocumentController openDocument:] вызывает этот метод, когда он только что вызвал-openDocumentWithContentsOfURL:display:error: и тот метод возвратил ноль.

Вы, вероятно, не должны переопределять этот метод, потому что у Вас нет способа надежного предсказания ли этот метод по сравнению с-presenterror:modalforwindow:delegate:didpresentselector:contextinfo: будет вызван для любой определенной ошибки. Необходимо вместо этого переопределить-willPresentError: метод, описанный ниже.
- (NSError *)willPresentError:(NSError *)error;
Учитывая, что получатель собирается представить ошибку (возможно, просто передав его следующему респонденту), возвратите ошибку, которая должна фактически быть представлена. Реализация по умолчанию этого метода просто возвращает по ошибке переданный.

Если, например, его локализованное описание или информация о восстановлении неподобающе универсально, возвращая более определенную, можно переопределить этот метод для настройки представления ошибок путем исследования по ошибке переданного и. Когда Вы переопределяете этот метод, всегда проверяют домен NSERROR и код для различения между ошибками, представление которых Вы хотите настроить, и те Вы не делаете. Для тех Вы не просто возвращаете [супер willPresentError:error]. Не принимайте решения на основе локализованного описания NSERROR, предложения восстановления или опций восстановления, потому что это обычно - не хорошая идея попытаться проанализировать локализованный текст.

NSDocument и NSDocumentController не являются подклассами NSResponder, и документы и совместно используемый контроллер документа не находятся в цепочке респондента по историческим причинам. NSDocument и NSDocumentController, тем не менее, реализуют три новых метода, описанные выше, и ошибочные презентационные сообщения по умолчанию передаются, как будто документы и совместно используемый контроллер документа находятся в цепочке респондента. (NSWindowController также переопределяет ошибочные методы представления, чтобы помочь заставить это произойти.)

Во многих приложениях будет надлежащим переопределить-willPresentError: в подклассе NSWindowController, NSDocument или NSDocumentController, но в некоторых приложениях будет самым простым настроить некоторое ошибочное представление на основе на приложение. Так, чтобы Вы не разделяли NSApplication на подклассы для этого был добавлен, новый метод делегата приложения:
- (NSError *)application:(NSApplication *)application willPresentError:(NSError *)error;
Учитывая, что объект приложения собирается представить ошибку, возвратите ошибку, которая должна фактически быть представлена.

Можно реализовать этот метод делегата настроить представление любой ошибки, представленной приложением, пока никакой код в приложении не переопределяет-presentError:modalForWindow:delegate:didPresentSelector:contextInfo: или-presentError: в пути, которые препятствуют ошибкам быть переданными к объекту приложения. Ваша реализация этого метода делегата должна последовать совету, данному для переопределения - [NSResponder willPresentError:], за исключением того, что это должно просто возвратить по ошибке переданный вместо [супер willPresentError:error].


Новый Ошибочный Метод Представления в NSAlert (Раздел добавил начиная с WWDC),

Мы май в будущем добавляет к NSError еще больше атрибутов, предназначающихся для вклада представлению ошибки пользователю. В этом случае это было бы идеально, если NSErrors, перенос таких атрибутов был представлен должным образом, таким образом, новый метод был добавлен к NSAlert для сокращения потребности в NSErrors, который будет выбран независимо кодом, который наивен из будущих дополнений NSError:
+ (NSAlert *)alertWithError:(NSError *)error;
Учитывая NSError, создайте NSAlert, который может использоваться для представления ошибки пользователю. Локализованное описание ошибки, предложение восстановления и опции восстановления будут использоваться для установки текста сообщения предупреждения, информативного текста и заголовков кнопки, соответственно.


Обработка ошибок NSDocument/NSDocumentController (Раздел, обновленный начиная с WWDC)

В предыдущих выпусках NSDocument Какао Mac OS X и представленных предупреждений классов NSDocumentController, которые не были информативны, и было очень трудно настроить их. Оба класса были обновлены для использования в своих интересах класса NSError, добавленного к Какао в Mac OS 10.3. Методы были добавлены и к классам, и к методы были осуждены. Новые методы все последовательно торгуют NSURLs, заменяя смешение ранее существовавшего путей и URLs.


Новые Методы NSDocument для Обработки ошибок (Раздел, обновленный начиная с WWDC)

- (id)initWithContentsOfURL:(NSURL *)absoluteURL ofType:(NSString *)typeName error:(NSError **)outError;
Инициализируйте документ, расположенный URL, указанного типа, и возвратите его в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему не мог быть инициализирован документ. Реализация по умолчанию этого метода вызывает [сам init], [сам readFromURL:absoluteURL ofType:typeName error:outError], [сам setFileURL:absoluteURL], [сам setFileType:typeName], и [сам setFileModificationDate:theModificationDate].

Этот метод заменяет-initWithContentsOfFile:ofType: и-initWithContentsOfURL:ofType: которые теперь осуждаются. Для обратной совместимости на уровне двоичных кодов-initWithContentsOfFile:ofType: все еще вызывается, когда надлежащий, если это переопределяется.-initWithContentsOfURL:ofType: никогда не вызывается ниоткуда в Какао, как в Mac OS 10.3 и ранее.
- (BOOL)revertToContentsOfURL:(NSURL *)absoluteURL ofType:(NSString *)typeName error:(NSError **)outError;
Отбросьте все несохраненные модификации документа и замените содержание документа путем чтения файла или пакета файла, расположенного URL, указанного типа, и возвратите YES в случае успеха. Если не успешный, возвратитесь НЕ после установки *outError к NSError, инкапсулирующему причину, почему не мог вернуться документ. Если документ имеет менеджера по отмене, [[сам undoManager] removeAllActions], реализация по умолчанию этого метода вызывает [сам readFromURL:absoluteURL ofType:typeName error:outError], [сам setFileModificationDate:theModificationDate], [сам updateChangeCount:NSChangeCleared], и. Это также удаляет сохраненные автоматически файлы содержания, когда они стали устаревшими.

Этот метод заменяет-revertToSavedFromFile:ofType: и-revertToSavedFromURL:ofType: которые теперь осуждаются. Для обратной совместимости на уровне двоичных кодов-revertToSavedFromFile:ofType все еще вызывается когда надлежащий, если переопределено.-revertToSavedFromURL:ofType: никогда не вызывается ниоткуда в Какао, как в Mac OS 10.3 и ранее.
- (BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)typeName error:(NSError **)outError;
- (BOOL)readFromFileWrapper:(NSFileWrapper *)fileWrapper ofType:(NSString *)typeName error:(NSError **)outError;
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError;
- (BOOL)writeToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName error:(NSError **)outError;
- (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError **)outError;
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError;
Методы, предназначающиеся, чтобы быть дополнительно переопределенными таким же образом как non-NSError-returning методы, которые они заменяют. См. комментарии в <AppKit/NSDocument.h> для подробных данных.

Замененные методы являются-readFromFile:ofType:-loadFileWrapperRepresentation:ofType:-loadDataRepresentation:ofType:-writeToFile:ofType:-fileWrapperRepresentationOfType: и-dataRepresentationOfType:. Они все теперь осуждаются. Для обратной совместимости на уровне двоичных кодов старые методы все еще вызываются когда надлежащий, если переопределено. Также осуждаемый-readFromURL:ofType: и-writeToURL:ofType: которые никогда не вызываются ниоткуда в Какао, как в Mac OS 10.3 и ранее.
- (BOOL)writeSafelyToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
error:(NSError **)outError;
- (BOOL)writeToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
originalContentsURL:(NSURL *)absoluteOriginalContentsURL
error:(NSError **)outError;
- (NSDictionary *)fileAttributesToWriteToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
originalContentsURL:(NSURL *)absoluteOriginalContentsURL
error:(NSError **)outError;
Больше методов, предназначающихся, чтобы быть дополнительно переопределенными таким же образом как non-NSError-returning методы, которые они заменяют. См. комментарии в <AppKit/NSDocument.h> для подробных данных.

Замененные методы являются-writeWithBackupToFile:ofType:saveOperation:-writeToFile:ofType:originalFile:saveOperation: и-fileAttributesToWriteToFile:ofType:saveOperation:. Они все теперь осуждаются. Для обратной совместимости на уровне двоичных кодов старые методы все еще вызываются когда надлежащий, если переопределено.
- (void)setFileURL:(NSURL *)absoluteURL;
- (NSURL *)fileURL;
Средства доступа для расположения дискового представления документа. Метод установки фактически не переименовывает документ, это только для записи расположения документа во время начального открытия или сохранения. Реализация по умолчанию-setFileURL: просто записывает URL так, чтобы реализация по умолчанию-fileURL могла возвратить его. Реализация по умолчанию-fileURL возвращает то, что было сохранено предыдущим вызовом реализации по умолчанию-setFileURL:.

Как часть параллельного усилия последовательно использовать NSURLs, эти методы заменяют-setFileName: и - имя файла, которые теперь осуждаются. Для обратной совместимости на уровне двоичных кодов старые методы все еще вызываются когда надлежащий, если переопределено.
- (void)saveToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
delegate:(id)delegate didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo;
Сохраните содержание документа файлу или пакету файла, расположенному URL, отформатированным к указанному типу, поскольку деталь отчасти сохранят работу. Когда сохранение будет завершено, независимо от успешности или неуспешности, отправьте сообщение, выбранное didSaveSelector делегату с contextInfo как последний параметр. Метод, выбранный didSaveSelector, должен иметь ту же подпись как:
- (void)document:(NSDocument *)document didSave:(BOOL)didSaveSuccessfully contextInfo:(void *)contextInfo;
Реализация по умолчанию этого метода сначала удостоверяется, что любой редактор зарегистрировал Привязку Какао использования NSEditorRegistration, неофициальный протокол фиксировал свои изменения (за исключением операций автосохранения), затем вызывает [сам saveToURL:absoluteURL ofType:typeName forSaveOperation:saveOperation error:&anError] и, если НЕ возвращается, представляет ошибку пользователю в модальной документом панели прежде, чем передать делегата.

Как часть параллельного усилия последовательно использовать NSURLs, этот метод заменяет-saveToFile:saveOperation:delegate:didSaveSelector:contextInfo: который теперь осуждается. Для обратной совместимости на уровне двоичных кодов старый метод все еще вызывается когда надлежащий, если переопределено.


Новые Методы NSDocumentController для Обработки ошибок (Раздел, обновленный начиная с WWDC)

- (id)openUntitledDocumentAndDisplay:(BOOL)displayDocument error:(NSError **)outError;
- (id)makeUntitledDocumentOfType:(NSString *)typeName error:(NSError **)outError;
- (id)openDocumentWithContentsOfURL:(NSURL *)absoluteURL display:(BOOL)displayDocument error:(NSError **)outError;
- (id)makeDocumentWithContentsOfURL:(NSURL *)absoluteURL ofType:(NSString *)typeName error:(NSError **)outError;
Методы, предназначающиеся, чтобы быть дополнительно переопределенными таким же образом как non-NSError-returning методы, которые они заменяют. См. комментарии в <AppKit/NSDocumentController.h> для подробных данных.

Замененные методы являются-openUntitledDocumentOfType:display:-makeUntitledDocumentOfType:-openDocumentWithContentsOfFile:display: и makeDocumentWithContentsOfFile:ofType:. Они все теперь осуждаются. Для обратной совместимости на уровне двоичных кодов старые методы все еще вызываются когда надлежащий, если переопределено. Также осуждаемый-openDocumentWithContentsOfURL:display: и-makeDocumentWithContentsOfURL:ofType: которые никогда не вызываются ниоткуда в Какао, как в Mac OS 10.3 и ранее.
- (id)documentForURL:(NSURL *)absoluteURL;
Учитывая URL, возвратите открытый документ, пакет файла или файла которого расположен URL или нолем, если нет такого открытого документа. Реализация по умолчанию этого метода запрашивает каждый открытый документ для нахождения того, соответствия URL которого, и возвращает первое, URL которого действительно соответствует.

Как часть параллельного усилия последовательно использовать NSURLs, этот метод заменяет-documentForFileName: который теперь осуждается. Для обратной совместимости на уровне двоичных кодов старый метод все еще вызывается когда надлежащий, если переопределено.

- fileNamesFromRunningOpenPanel: также осуждается. Это больше не вызывается-openDocument: если это не переопределяется. Существующий-URLsFromRunningOpenPanel: метод теперь используется вместо этого.

Наконец,-setShouldCreateUI: и-shouldCreateUI осуждаются, потому что, как используется NSDocumentController в прошлом они не полезны.-shouldCreateUI все еще вызывается также осуждаемым-openUntitledDocumentOfType:display:-openDocumentWithContentsOfFile:display: и-openDocumentWithContentsOfURL:display: методы, и также новый-openUntitledDocumentAndDisplay:error: и-openDocumentWithContentsOfURL: display:error: методы, но только для обратной совместимости. Если Ваш подкласс NSDocument отправляет себе сообщение-makeWindowControllers во время инициализации, и Вы используете-setShouldCreateUI: чтобы препятствовать NSDocumentController отправлять другое сообщение-makeWindowControllers, Вы должны, рассматривая фиксацию Вашего подкласса NSDocument, потому что NSDocuments никогда не должен должен быть вызывать-makeWindowControllers во время инициализации.


Использование NSSaveAsOperation вместо NSSaveOperation в NSDocument

- saveDocumentWithDelegate:didSaveSelector:contextInfo: теперь вызывает-runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo: с NSSaveAsOperation вместо NSSaveOperation, когда панель сохранения будет представленной. При проверке saveOperation == NSSaveOperation, также не проверяя [сам имя файла] или [сам fileURL] теперь допустимо для приложений, требующих Тайгера.


Изменитесь на стандартное представление аксессуара панели сохранения NSDOCUMENT

Формат файла, раскрывающийся в стандартном представлении аксессуара панели сохранения, установленном NSDocument больше, не включает элементы типа файла только для экспорта для NSSaveOperation и NSSaveAsOperation. Те элементы всегда отключались, но потому что пользователь не мог возможно заставить их становиться включенными путем выполнения чего-то в панели сохранения, не было надлежащим включать их.


Изменитесь на представление NSDocumentController документа, открывающего ошибки

В предыдущих выпусках Mac OS X NSDocumentController представил бы ошибочное предупреждение, если бы документ, выбранный пользователем с открытой панелью, не мог бы быть открыт, но это не представило бы то же предупреждение, когда открытие документа было опробовано в результате пользователя, дважды щелкающего по значку документа в Средстве поиска или перетаскивающего значка документа на значок приложения. Это было фиксировано. NSDocumentController теперь последовательно представляет ошибочное предупреждение каждый раз, когда документ, открывающий сбои. Для обратной совместимости на уровне двоичных кодов NSDocumentController не делает этого в приложениях, соединенных против Mac OS 10.3 или ранее, потому что несколько приложений работали вокруг проблемы путем представления ошибочных собственных предупреждений (и два ошибочных предупреждения не лучше, чем одно).


Новый Инициализатор NSDocument Только Для Новых Документов (Раздел, обновленный начиная с WWDC)

В предыдущих выпусках Mac OS X не было никакого инициализатора NSDocument, который будет вызван, когда новый документ создавался, но не, когда открывался документ. Такой инициализатор был добавлен:
- (id)initWithType:(NSString *)typeName error:(NSError **)outError;
Инициализируйте новый пустой документ указанного типа и возвратите его в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему не мог быть инициализирован документ. Реализация по умолчанию этого метода просто вызывает [сам init] и [сам setFileType:typeName].

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


Новые Методы NSDocument для Дат Модификации Файла (Раздел, обновленный начиная с WWDC)

Новые методы NSDocument были добавлены для отслеживания даты модификации файла документа на диске:
- (void)setFileModificationDate:(NSDate *)modificationDate;
- (NSDate *)fileModificationDate;
Метод-fileModificationDate возвращает последнюю известную дату модификации дискового представления документа.-setFileModificationDate: вызывается реализациями по умолчанию-initWithContentsOfURL:ofType:error:-initForURL:withContentsOfURL:ofType:error:-revertToContentsOfURL:ofType:error: и-saveToURL:ofType:forSaveOperation:error:. В будущем выпуске-saveDocumentWithDelegate:didSaveSelector:contextInfo: может протестировать дату модификации файла и предупредить пользователя, когда они могут собираться перезаписать модификации чем-то другим, чем текущее приложение.


Новый метод NSDocument для всего сохранения документа

Новый метод был добавлен к NSDocument так, чтобы можно было переопределить его, чтобы сделать вещи прежде и после того, как любой сохраняет работу:
- (BOOL)saveToURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation error:(NSError **)outError;
Сохраните содержание документа файлу или пакету файла, расположенному URL, отформатированным к указанному типу, поскольку деталь отчасти сохранят работу и возвратят YES в случае успеха. Если не успешный, возвратитесь НЕ после установки *outError к NSError, инкапсулирующему причину, почему не мог быть сохранен документ.

Реализация по умолчанию этого метода вызывает [сам writeSafelyToURL:absoluteURL ofType:typeName forSaveOperation:saveOperation error:outError]. Если это возвращается ДА, это также вызывает некоторую комбинацию-setFileModificationDate:-setFileType:-setFileURL:-updateChangeCount: и-setAutosavedContentsFileURL: как подходящий для отчасти сохраняют работу. Это также обновляет информацию что-saveDocumentWithDelegate:didSaveSelector:contextInfo: использование для проверки на модификацию, переименование, перемещение, удаление и повреждение открытых документов, и удаляет сохраненные автоматически файлы содержания, когда они стали устаревшими. Поскольку этот метод делает несколько различных вещей, и потому что вещи, вероятно, изменятся в будущих выпусках Mac OS X, Ваше переопределение этого метода должно фактически всегда вызывать супер, просто добавляя новое поведение прежде или после сохранения.


Автоматическое сохранение документа

Поддержка автоматического сохранения документов была добавлена к Какао. Поддержка принимает форму дополнительного периодического поведения автоматического сохранения, нового поведения автоматического сохранения в выходящее из приложения время, и нового NSDocument и методов NSDocumentController, которые можно вызвать и переопределить для настройки поведения.


Новые методы NSDocumentController для автоматического сохранения

Два новых метода были добавлены к NSDocumentController так, чтобы можно было включить периодическое автоматическое сохранение и управлять, как часто документы периодически сохраняются автоматически:
- (void)setAutosavingDelay:(NSTimeInterval)autosavingDelay;
- (NSTimeInterval)autosavingDelay;
Временной интервал в секундах для периодического автоматического сохранения. Значение 0 указывает, что периодическое автоматическое сохранение не должно быть сделано вообще. NSDocumentController будет использовать это число в качестве количества времени для ожидания между обнаружением, что документ не сохранил автоматически изменения и отправку документа-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: сообщение. Значение по умолчанию 0. Можно изменить его для включения периодического автоматического сохранения.

Два новых метода, вызывающиеся при повторном открытии сохраненных автоматически документов, были добавлены к NSDocumentController:
- (BOOL)reopenDocumentForURL:(NSURL *)absoluteDocumentURL
withContentsOfURL:(NSURL *)absoluteDocumentContentsURL error:(NSError **)outError;
Вновь откройте документ, расположенный URL путем чтения содержания для документа от другого URL, представьте его пользовательский интерфейс и возвратите YES в случае успеха. Если не успешный, возвратитесь НЕ после установки *outError к NSError, инкапсулирующему причину, почему не мог быть вновь открыт документ. Реализация по умолчанию этого метода решает, что тип вновь открываемого документа, отправляет-makeDocumentForURL:withContentsOfURL:ofType:error: для инстанцирования его, затем вызывает-addDocument: записывать его открытие. Это тогда отправляет документу сообщения-showWindows и-makeWindowControllers.
- (id)makeDocumentForURL:(NSURL *)absoluteDocumentURL withContentsOfURL:(NSURL *)absoluteDocumentContentsURL
ofType:(NSString *)typeName error:(NSError **)outError;
Инстанцируйте документа, расположенного URL, указанного типа, но путем чтения содержания для документа от другого URL, и возвратите его в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему нельзя было инстанцировать документ. Реализация по умолчанию этого метода вызывает-documentClassForType: узнать класс документа для инстанцирования, выделяет объект документа и инициализирует его путем отправки ему-initForURL:withContentsOfURL:ofType:error: сообщение.


Новые методы NSDocument и перечислители для автоматического сохранения

Новые методы были добавлены к NSDocument. Новый NSDocumentChangeTypes и новый NSSaveOperationType были добавлены также:
- (BOOL)hasUnautosavedChanges;
Возвратите YES, если документ имеет изменения, не сохраненные автоматически, НЕТ иначе, как определено историей предыдущих вызовов-updateChangeCount:. Реализация по умолчанию этого метода возвращается НЕ сразу после вызова-updateChangeCount:NSChangeCleared или-updateChangeCount:NSChangeAutosaved. Если различное число-updateChangeCount:NSChangeDone и-updateChangeCount:NSChangeUndone вызовов было сделано с тех пор, это тогда возвратит YES. (-updateChangeCount:NSChangeReadOtherContents не имеет никакого эффекта на то, что возвращает реализация по умолчанию этого метода.)
- (void)autosaveDocumentWithDelegate:(id)delegate didAutosaveSelector:(SEL)didAutosaveSelector contextInfo:(void *)contextInfo;
Сохраните содержание документа автоматически в надлежащем расположении, и затем отправьте сообщение, выбранное didAutosaveSelector делегату с contextInfo как последний параметр. Метод, выбранный didAutosaveSelector, должен иметь ту же подпись как:
- (void)document:(NSDocument *)document didAutosave:(BOOL)didAutosaveSuccessfully contextInfo:(void *)contextInfo;
Если ошибка происходит при автоматическом сохранении, о ней нужно сообщить пользователю, обычно в модальной документом предупредительной панели, прежде чем делегат будет передан с succeeded:NO.

Реализация по умолчанию этого метода выясняет, куда сохраненное автоматически содержание документа должно пойти и вызывает [сам saveToURL:autosavedDocumentContentsURL ofType: [сам autosavingFileType] forSaveOperation:NSAutosaveOperation delegate:inDelegate didSaveSelector:inDidAutosaveSelector contextInfo:inContextInfo].
- (NSString *)autosavingFileType;
Возвратите тип документа, который должен использоваться для работы автосохранения. Реализация по умолчанию просто возвращает [сам тип файла], таким образом, для никогда не сохраненный документирует этот метод, возвратит первый тип в массиве, возвращенном [[сам класс] writableTypes], или ноль, если массив будет пуст. Можно переопределить этот метод и возвратить ноль в переопределении для завершенного отключения автоматического сохранения отдельных документов (NSDocumentController не отправит-autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: к документу, не имеющему никакого типа файла автоматического сохранения.) Можно также переопределить его, если приложение определяет тип документа, который специально предназначен для автоматического сохранения. Например, тот, эффективно представляющий содержание документа _changes_ вместо полного содержания документа.
- (void)setAutosavedContentsFileURL:(NSURL *)absoluteURL;
- (NSURL *)autosavedContentsFileURL;
Расположение последний раз сохраненного автоматически содержания документа. Реализация по умолчанию-setAutosavedContentsFileURL: записывает URL и уведомляет совместно используемый контроллер документа, что этот документ должен быть автовновь открыт, если приложение завершено быстрым выходом из системы (функция не в Тайгере) или отказывает, прежде чем документ сохраняется. Реализация по умолчанию-autosavedContentsFileURL просто возвращает то, что было сохранено предыдущим вызовом реализации по умолчанию-setAutosavedContentsFileURL:.

Например,-saveToURL:ofType:forSaveOperation:error: вызывает-setAutosavedContentsFileURL: записывать, когда автоматическое сохранение было сделано, и оба метода как часть удаления сохраненного автоматически содержания документа, когда регулярная операция Save или Save As была сделана успешно.-revertToContentsOfURL:ofType:error: также вызывает их как часть удаления сохраненного автоматически содержания документа.

Во время автоматического сохранения нового NSSaveOperationType используется:
NSAutosaveOperation
Запись текущего содержания документа к файлу или пакету файла, который является отдельным от текущего документа, не изменяя текущий документа. Обратный код совместимости на уровне двоичных кодов в NSDocument гарантирует, что это значение никогда не передается переопределениям методов, берущих NSSaveOperationTypes. NSSaveToOperation всегда используется в тех случаях вместо этого.

После успешного автоматического сохранения-updateChangeCount: с новым NSDocumentChangeType должен быть вызван:
NSChangeAutosaved
Значение для передачи, чтобы указать, что содержание документа было сохранено автоматически. Например,-saveToURL:ofType:forSaveOperation:error: использование это для успешного NSAutosaveOperation.

Был добавлен новый метод, который можно переопределить для настройки повторного открытия сохраненных автоматически документов:
- (id)initForURL:(NSURL *)absoluteDocumentURL withContentsOfURL:(NSURL *)absoluteDocumentContentsURL
ofType:(NSString *)typeName error:(NSError **)outError;
Инициализируйте документ, расположенный URL, указанного типа, но путем чтения содержания для документа от другого URL, и возвратите его в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему не мог быть инициализирован документ. Реализация по умолчанию этого метода вызывает [сам readFromURL:absoluteDocumentContentsURL ofType:typeName error:outError], [сам setFileURL:absoluteURL], [сам setAutosavedContentsFileURL:absoluteDocumentContentsURL], [сам setFileType:typeName], и [сам setFileModificationDate:theModificationDate]. Это также вызывает [сам updateChangeCount:NSChangeReadOtherContents], если два URLs не идентичен, так, чтобы-isDocumentEdited всегда возвратил YES, пока пользователь не сохранит или возвращается документ.

Для упрощения принятия сохраняющейся автоматически функции, представленной в Mac OS 10.4, реализация по умолчанию этого метода вызывает [сам initWithContentsOfFile: [путь absoluteDocumentContentsURL] ofType:typeName], если-initWithContentsOfFile:ofType: переопределяется и URL использует «файл»: схема. Это все еще вызывает [сам setFileModificationDate:theModificationDate] и [сам updateChangeCount:NSChangeReadOtherContents] в этой ситуации. Это все еще также вызывает [сам setFileURL:absoluteURL], для перезаписи неправильного вызова-setFileName: то, что переопределение-initWithContentsOfFile:ofType: вероятно, сделал.

absoluteDocumentURL будет нолем, если инициализация будет сделана как часть повторного открытия сохраненного автоматически документа, когда сохраненный автоматически документ никогда не сохранялся во-первых.

Во время сохраненного автоматически документа, вновь открывающегося-initForURL:withContentsOfURL:ofType:error: использует новый NSDocumentChangeType:
NSChangeReadOtherContents
Значение для передачи-updateChangeCount: указать, что документ был инициализирован с содержанием файла или пакета файла кроме того, расположение которого будет возвращено-fileURL, и поэтому не может возможно синхронизироваться с его персистентным представлением. Например,-initForURL:withContentsOfURL:ofType:error: использование это, чтобы указать, что вновь открывается сохраненный автоматически документ.


Поддержка NSDocument/NSDocumentController Динамично поддерживающих Типов документов

Несколько интересных приложений Какао реализовали динамично поддерживающие типы документов, в которых поддержка дополнительных типов документов предоставлена плагинами. Поскольку NSDocumentController и объявления типа документа доступа NSDocument в Info.plist непубличным способом, разработчики обратились к доступу к частному NSDocumentController и переменным экземпляра NSDocument непосредственно, которому обескураживают. Для устранения такого обескураженного поведения новые методы, которые можно переопределить, в дополнение к переопределению существующих методов, были добавлены так, можно безопасно реализовать собственную динамично поддерживающую схему ввода документа.


Новые методы NSDocumentController для динамично поддерживающих типов документов

- (NSString *)defaultType;
Возвратите имя типа документа, который должен использоваться при создании новых документов. Если никакой тип Редактора не объявляется, реализация по умолчанию этого метода возвращает первый тип Редактора, объявленный в Info.plist приложения, или возвращает ноль. Можно переопределить его для настройки типа документа, создающегося, когда, например, пользователь выбирает New в меню File.

[NSDocumentController openUntitledDocumentAndDisplay:error:], например, всегда вызывает этот метод. - [NSDocumentController validateUserInterfaceItem:] также вызывает это при решении, действительно ли любой элемент UI, действие которого является newDocument: (Новый элемент в меню File, обычно), должен быть включен.
- (NSString *)typeForContentsOfURL:(NSURL *)inAbsoluteURL error:(NSError **)outError;
Учитывая URL, возвратите имя типа документа, который должен использоваться при открытии документа в том расположении, в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему тип документа не мог быть определен, или факт, что тип документа является просто нераспознанным. Реализация по умолчанию этого метода вызывает-typeFromFileExtension: возможно дважды, передавая строку типа файла HFS для второго вызова. Реализация по умолчанию, конечно, подвержена изменениям как бы то ни было. Можно переопределить это для настройки определения типа для открываемых документов.

[NSDocumentController openDocumentWithContentsOfURL:display:error:] и - [NSDocumentController reopenDocumentForURL:withContentsOfURL:error:], например, всегда вызывают этот метод.
- (NSArray *)documentClassNames;
Возвратите имена подклассов NSDocument, поддерживаемых этим приложением. Реализация по умолчанию этой информации о возвратах метода произошла из Info.plist приложения. Можно переопределить его для возврата имен классов документа, динамично загружающихся из плагинов.


Новый метод NSDocument для динамично поддерживающих типов документов

- (NSArray *)writableTypesForSaveOperation:(NSSaveOperationType)saveOperation;
Возвратите имена типов, к которым этот документ может быть сохранен для детали, отчасти сохраняют работу. Поскольку каждый отчасти сохраняют работу кроме NSSaveToOperation, возвращенный массив должен только включать типы, для которых приложение может играть роль Редактора. Для NSSaveToOperation возвращенный массив может также включать типы, для которых приложение может только играть роль Средства просмотра и еще больше типов, которые может просто экспортировать приложение. Реализация по умолчанию этого метода возвращается [[сам, класс] writableTypes] с, кроме во время NSSaveToOperations, вводит, для которого +isNativeType возвращается НЕ отфильтрованный.

Можно переопределить этот метод для ограничения набора перезаписываемых типов, когда documently в настоящее время содержит данные, которые не являются представимыми во всех перезаписываемых типах. Например, когда документ содержит присоединение и может только быть сохранен должным образом к .rtfd файлам, можно запретить сохранение к .rtf файлам. NSDocument в настоящее время использует этот этот метод во время операций сохранения, что существующие панели сохранения, но это можно вызвать в других случаях в будущих выпусках Mac OS X.

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


Надлежащий вызов существующих методов NSDocument для динамично поддерживающих типов документов

Реализации существующих методов класса NSDocument +readableTypes, +writableTypes, и +isNativeType: не изменились значительно, но они теперь вызываются, когда Вы ожидали бы, что они будут вызваны, так, чтобы было полезно переопределить их. Например, каждый NSDocument разделяют на подклассы, чье имя возвращается - [NSDocumentController documentClassNames], теперь отправляется +readableTypes сообщения для определения списка типов, чем можно открыть. Для другого примера класс сохраняющегося документа отправляется сообщение +writableTypes для определения списка типов, чем можно сохранить. В случае NSSaveOperation или NSSaveAsOperation +isNativeType: отправляется за каждым типом, возвращенным +readableTypes, для отфильтровывания типов только для экспорта.


Новый метод NSDocumentController для управления открытым меню Recents

Новый метод был добавлен к NSDocumentController так, чтобы можно было переопределить его для управления представлением NSDocumentController стандартного меню Open Recents:
- (unsigned int)maximumRecentDocumentCount;
Возвратите максимальное количество элементов, которые могут быть представлены в стандартном меню Open Recent. Значение 0 указывает, что NSDocumentController не попытается добавить меню Open Recent к меню File Вашего приложения, хотя NSDocumentController не попытается удалить любой пункт меню Open Recent, если уже будет тот там. Реализация по умолчанию возвращает значение, которое подвержено изменениям, и можете, или может не быть получен из настройки, установленной пользователем в панели System Preferences.


Изменения в Обработке NSDOCUMENT Команды Сценариев 'Сохранения' (Раздел добавил начиная с WWDC),

Поведение - [NSDocument (NSScripting) handleSaveScriptCommand:], метод, обычно вызывающийся, когда сценарий отправляет команду 'сохранения' в документ, изменяется в Mac OS 10.4. Это теперь реализует поведение, описанное в <http://developer.apple.com/technotes/tn2002/tn2106.html>. Вот сравнение старого и нового поведения:

Когда 'в' параметре предоставлен для уже сохраненного документа
• 10.3: Действовавший как 'Сохраняют Как...', если класс документа не возвратился НЕ для +isNativeType:typeDerivedFromFileExtension, когда действовал как, 'Сохраняют Копию...' (также известный, как 'Сохраняют К...'). Вызванный-writeWithBackupToFile:ofType:saveOperation: непосредственно.
• 10.4: Акты как 'Сохраняют Копию...' Вызывает-saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo:.

Когда 'в' параметре предоставлен для никогда сохраненного документа
• 10.3: Действовавший как 'Сохраняют Как...', если класс документа не возвратился НЕ для + isNativeType:typeDerivedFromFileExtension, когда действовал как, 'Сохраняют Копию...' Вызванный-writeWithBackupToFile:ofType:saveOperation: непосредственно.
• 10.4: Акты как 'Сохраняют Как...' Вызывает-saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo:.

Когда не 'в' параметре предоставлен для уже сохраненного документа
• 10.3: Действовавший как 'Сохранение'. Вызванный-saveDocument:.
• 10.4: Актам нравится, 'Сохраняют'. Вызывает-saveDocumentWithDelegate:didSaveSelector:contextInfo:.

Когда не 'в' параметре предоставлен для никогда сохраненного документа
• 10.3: Действовавший как 'Сохраняют Как...' Вызванный-saveDocumentAs:.
• 10.4: Актам нравится, 'Сохраняют', который в этом случае неотличим от, 'Сохраняют Как...', потому что диалоговое окно сохранения должно быть представлено пользователю. Вызывает-saveDocumentWithDelegate:didSaveSelector:contextInfo:.

TextEdit, который не является находящимся в NSDocument, был обновлен для реализации того же поведения.


Изменения в Обработке NSDOCUMENT Редакторов, Дипломированных через Привязку Какао NSEditorRegistration Неофициальный Протокол (Раздел добавил начиная с WWDC),

В Mac OS 10.3 NSDocument реализовали Привязку Какао NSEditorRegistration неофициальный протокол и скажут значению ключа обязательных редакторов, чтобы фиксировать и отбросить их изменения в определенные времена. В Mac OS была усовершенствована обработка 10.4 NSDOCUMENT значения ключа обязательные редакторы. Эти методы не долго говорят зарегистрированным редакторам фиксировать свои изменения:
- saveDocument:-saveDocumentAs: и-saveDocumentTo: и-printDocument:.
- canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:.
- [NSDocumentController saveAll:].
Вместо этого эти методы NSDocument теперь говорят зарегистрированным редакторам фиксировать свои изменения:
- saveDocumentWithDelegate:didSaveSelector:contextInfo:
- runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:
- saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo: (за исключением NSAutosaveOperations)
- printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:
Конечный результат - то, что любое предупреждение покрывает это, редакторы могут представить, когда спросили фиксировать, теперь всегда представляются в нужное время.

- revertDocumentToSaved: теперь говорит зарегистрированным редакторам отбрасывать после того, как пользователь видел, «Вы хотите вернуться?» панель и выбранный «Revert», вместо, прежде чем панель представлена.

- близко теперь говорит редакторам отбрасывать свои изменения.

- isDocumentEdited теперь возвращает YES каждый раз, когда существует зарегистрированное значение ключа обязательные редакторы.

Для обратной совместимости на уровне двоичных кодов NSDocument отправит-commitEditingWithDelegate:didCommitSelector:contextInfo: сообщения дипломированным редакторам, которые реализуют этот новый метод, но отступят к использованию старого (но не устаревшие (deprecated))-commitEditing сообщение тем, которые не делают.


Исправление ошибки для Instantation Подклассов NSDocumentController (Раздел добавил начиная с WWDC),

Согласно документации, названной, «Создавая Подкласс NSDocumentController»:

«Приложение не попросит его совместно используемый контроллер документа до окончания applicationWillFinishLaunching: сообщение отправляется его делегату. Поэтому можно создать экземпляр подкласса NSDocumentController в applicationWillFinishLaunching делегата приложения: метод и тот экземпляр будут установлены как совместно используемый контроллер документа».

В Mac OS 10.0-10.3 это было не всегда истиной. Код в AppKit вызвал бы + [NSDocumentController sharedDocumentController] во время загрузки основного пера Вашего приложения, если бы это содержало пункт меню Open Recent перед отправкой-applicationWillFinishLaunching: делегату приложения, предотвращая NSDocumentController, который инстанцирует приложение, делегируют от того, чтобы быть возвращенным последующими вызовами +sharedDocumentController. Это было ошибкой и было фиксировано в Mac OS 10.4. (Ошибка не влияла на приложения, не имеющие никакого пункта меню Open Recent в их основном пере и позволяющие NSDocumentController добавить один под первым элементом, имевшим нулевую цель и openDocument: действие, как Редактор Эскиза и Списка свойств.)


Исправление ошибки в - [NSDocument displayName]

В Mac OS 10.3, NSDocuments начал отправлять себе сообщения-displayName в целях определения, был ли документ не назван. Реализация NSDOCUMENT-displayName возвратила бы ноль в этой ситуации. Это вмешалось в переопределения-displayName, вызвавшего [супер displayName] и предположившего, что ненулевое значение будет возвращено (допустимое предположение). Эта ошибка была исправлена. - [NSDocument displayName] больше когда-либо возвращает ноль.


Удаление объявлений устаревшего метода от NSDocument.h и NSDocumentController.h

Четыре метода NSDocument были отмечены как устаревшие из как Mac OS 10.0, будучи замененным методами, поведение которых в присутствии многократных листов заметно лучше:

- canCloseDocument: был заменен-canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:
- fileNameFromRunningSavePanelForSaveOperation: был заменен-saveDocumentWithDelegate:didSaveSelector:contextInfo:
- runModalSavePanel:withAccessoryView: был заменен-runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:
- shouldCloseWindowController: был заменен-shouldCloseWindowController:delegate:shouldCloseSelector:contextInfo:

Два метода NSDocumentController были аналогично отмечены как устаревшие одновременно:

- closeAllDocuments: был заменен-closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
- reviewUnsavedDocumentsWithAlertTitle:cancellable: был заменен-reviewUnsavedDocumentsWithAlertTitle:cancellable:delegate:didReviewAllSelector:contextInfo:

Объявления для этих шести методов были удалены из NSDocument.h и NSDocumentController.h. Необходимо прекратить использовать или переопределять их в приложениях и начать использовать или переопределять их замены. Однако для обратной совместимости на уровне двоичных кодов их реализации остаются в Какао в категориях под названием NSDocument (NSCompatibility) и NSDocumentController (Совместимость). Если Вы не в состоянии мигрировать на более новые методы, можно покончить с любыми предупреждениями компилятора, вызванными изменениями в NSDocument.h и NSDocumentController.h путем добавления следующих объявлений к файлам кода соответствующего источника в проекте:
@interface NSDocument(NSDeprecatedLongAgo)
- (BOOL)canCloseDocument;
- (NSString *)fileNameFromRunningSavePanelForSaveOperation:(NSSaveOperationType)saveOperation;
- (int)runModalSavePanel:(NSSavePanel *)savePanel withAccessoryView:(NSView *)accessoryView;
- (BOOL)shouldCloseWindowController:(NSWindowController *)windowController;
@end
@interface NSDocumentController(NSDeprecatedLongAgo)
- (BOOL)closeAllDocuments;
- (BOOL)reviewUnsavedDocumentsWithAlertTitle:(NSString *)title cancellable:(BOOL)cancellable;
@end

Сводка осуждаемых методов NSDocument

Поиск в вышеупомянутой информации о версии для получения информации о том, почему каждый был осужден, и когда это все еще вызывается.
- (NSData *)dataRepresentationOfType:(NSString *)type;
- (NSDictionary *)fileAttributesToWriteToFile:(NSString *)fullDocumentPath
ofType:(NSString *)documentTypeName saveOperation:(NSSaveOperationType)saveOperationType;
- (NSString *)fileName;
- (NSFileWrapper *)fileWrapperRepresentationOfType:(NSString *)type;
- (id)initWithContentsOfFile:(NSString *)absolutePath ofType:(NSString *)typeName;
- (id)initWithContentsOfURL:(NSURL *)absoluteURL ofType:(NSString *)typeName;
- (BOOL)loadDataRepresentation:(NSData *)data ofType:(NSString *)type;
- (BOOL)loadFileWrapperRepresentation:(NSFileWrapper *)wrapper ofType:(NSString *)type;
- (void)printShowingPrintPanel:(BOOL)flag;
- (BOOL)readFromFile:(NSString *)fileName ofType:(NSString *)type;
- (BOOL)readFromURL:(NSURL *)url ofType:(NSString *)type;
- (BOOL)revertToSavedFromFile:(NSString *)fileName ofType:(NSString *)type;
- (BOOL)revertToSavedFromURL:(NSURL *)url ofType:(NSString *)type;
- (int)runModalPageLayoutWithPrintInfo:(NSPrintInfo *)printInfo;
- (void)saveToFile:(NSString *)fileName saveOperation:(NSSaveOperationType)saveOperation
delegate:(id)delegate didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo;
- (void)setFileName:(NSString *)fileName;
- (BOOL)writeToFile:(NSString *)fileName ofType:(NSString *)type;
- (BOOL)writeToFile:(NSString *)fullDocumentPath ofType:(NSString *)documentTypeName
originalFile:(NSString *)fullOriginalDocumentPath saveOperation:(NSSaveOperationType)saveOperationType;
- (BOOL)writeToURL:(NSURL *)url ofType:(NSString *)type;
- (BOOL)writeWithBackupToFile:(NSString *)fullDocumentPath ofType:(NSString *)documentTypeName
saveOperation:(NSSaveOperationType)saveOperationType;

Сводка осуждаемых методов NSDocumentController

Поиск в вышеупомянутой информации о версии для получения информации о том, почему каждый был осужден, и когда это все еще вызывается.
- (id)documentForFileName:(NSString *)fileName;
- (NSArray *)fileNamesFromRunningOpenPanel;
- (id)makeDocumentWithContentsOfFile:(NSString *)fileName ofType:(NSString *)type;
- (id)makeDocumentWithContentsOfURL:(NSURL *)url ofType:(NSString *)type;
- (id)makeUntitledDocumentOfType:(NSString *)type;
- (id)openDocumentWithContentsOfFile:(NSString *)fileName display:(BOOL)display;
- (id)openDocumentWithContentsOfURL:(NSURL *)url display:(BOOL)display;
- (id)openUntitledDocumentOfType:(NSString*)type display:(BOOL)display;
- (void)setShouldCreateUI:(BOOL)flag;
- (BOOL)shouldCreateUI;

NSPersistentDocument

NSPersistentDocument является подклассом NSDocument, позволяющего легко создать типы документов, сделанные персистентными платформой CoreData. Экземпляры NSPersistentDocument имеют NSManagedObjectContext (и таким образом NSPersistentStoreCoordinator - реализация по умолчанию создает отдельный штабель контекста, координатора и персистентного хранилища для каждого документа, но это может быть реконфигурировано путем переопределения). Координатор создается с [сам модель].

NSPersistentDocument значением по умолчанию хранит данные в XML-файле (персистентное хранилище XML), но это может быть реконфигурировано к SQL или двоичным форматам путем переопределения configurePersistentStoreCoordinatorForURL:ofType:error: метод.

Сводка того, как работают различные операции документа:
- Открытый: Вызывает конфигурировать... метод с файлом URL, добавляет хранилище типа по умолчанию (XML). Объекты будут загружены из персистентного хранилища по требованию через контекст документа.
- Сохраните: На новом документе добавит хранилище типа по умолчанию с выбранным URL пользователя, затем вызывает, сохраните: на контексте. Для уже открытого документа, просто вызывает, сохраните: на контексте.
- Сохраните Как: Для нового документа, отступает к Save:. Для уже открытого документа, перемещает персистентное хранилище на новый URL и вызывает, сохраните: на контексте.
- Сохраните К: Не поддерживаемый в Тайгере.
- Вернитесь: Возвращается или сбрасывает контекст. Объекты будут загружены снова из персистентного хранилища точно так же, как Открытое: случай.

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


Поддержка NSApplication улучшенной печати событие Apple

Новое событие Enhanced Print Apple было определено Mac OS 10.3 (http://developer .apple.com/technotes/tn2002/tn2082.html), но Какао не поддерживало его должным образом. У Тигра механизмы были добавлены для переоснащения поддержки события печати существующим приложениям, но они не работают во всех случаях. Чтобы позволить Вам легко создавать non-NSDocument-based приложения, обрабатывающие события Print Apple надежно, новый делегат NSApplication был добавлен, и один осуждаемый:
- (NSApplicationPrintReply)application:(NSApplication *)application printFiles:(NSArray *)fileNames
withSettings:(NSDictionary *)printSettings showPrintPanels:(BOOL)showPrintPanels;
Учитывая, что приложение попросили распечатать группу файлов, распечатайте их. printSettings является словарем, содержащим NSPrintInfo-совместимые атрибуты задания печати. Ваше приложение должно добавить их к любому NSPrintInfo, используемому для печати файлов, обычно путем вызова [[thePrintInfo словаря] addEntriesFromDictionary:printSettings]. showPrintPanels является флагом, указывающим, должна ли панель печати быть представлена для каждого распечатываемого файла. Если это нет, никакие панели печати не должны быть представлены (но панели прогресса печати должны все еще быть представлены). Посмотрите - [NSPrintOperation setShowsPrintPanel:] ниже. Реализации этого метода должны возвратить одно из следующего:
typedef enum NSApplicationPrintReply {
NSPrintingCancelled = 0,
NSPrintingSuccess = 1,
NSPrintingFailure = 3,
NSPrintingReplyLater = 2
} NSApplicationPrintReply;
Возвратите NSPrintingReplyLater, если результат печати не может быть сразу возвращен, если печать вызовет представление листа, например. Если Ваш метод возвращает NSPrintingReplyLater, это должно всегда вызывать - [NSApplication replyToOpenOrPrint:], когда вся работа печати была завершена, успешно или нет.

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


Поддержка NSPrintInfo улучшенной печати событие Apple

Поддержка соответствия атрибутов полям в событии Enhanced Print Apple «со свойствами» параметр была добавлена к NSPrintInfo:
NSString *NSPrintPagesAcross; // an NSNumber containing the number of logical pages to be placed across a physical sheet
NSString *NSPrintPagesDown; // an NSNumber containing the number of logical pages to be placed down a physical sheet
NSString *NSPrintTime; // an NSDate containing the time at which printing should begin
NSString *NSPrintDetailedErrorReporting; // an NSNumber containing a boolean value
NSString *NSPrintFaxNumber; // an NSString containing a fax number
NSString *NSPrintPrinterName; // an NSString containing the name of a printer
Ошибка: NSPrintTime не имеет никакого эффекта в Mac OS 10.4.


Поддержка NSPrintOperation улучшенной печати событие Apple

Поскольку представление панели печати во время обработки События печати является дополнительным, но панель прогресса печати должна всегда представляться, новые методы были добавлены к NSPrintOperation, чтобы дать Вам отдельный контроль над двумя видами панелей:
- (void)setShowsPrintPanel:(BOOL)flag;
- (BOOL)showsPrintPanel;
- (void)setShowsProgressPanel:(BOOL)flag;
- (BOOL)showsProgressPanel;
Эти методы заменяют-setShowPanels: и теперь осуждающиеся-showPanels. Старые методы функционируют, как они сделали в Mac OS 10.3, но возвращаемое значение-showPanels: неоднозначно (мудрый реализацией, это возвращает то же значение как-showsPrintPanel).


Новые методы NSDocument для улучшенной печати событие Apple

Новое событие Enhanced Print Apple было определено Mac OS 10.3 (<http://developer.apple.com/technotes/tn2002/tn2082.html>), но Какао не поддерживало его должным образом. У Тигра механизмы были добавлены для переоснащения поддержки события печати существующим приложениям, но они не работают во всех случаях. Чтобы позволить Вам легко создавать основанные на документе приложения, обрабатывающие события Print Apple должным образом, два новых метода были добавлены к NSDocument, и методы были осуждены:
- (void)printDocumentWithSettings:(NSDictionary *)printSettings showPrintPanel:(BOOL)showPrintPanel
delegate:(id)delegate didPrintSelector:(SEL)didPrintSelector contextInfo:(void *)contextInfo;
Распечатайте документ. Если показ панели печати указан, представьте его сначала, и печать только если пользователь OKs панель. Атрибуты NSPrintInfo в переданном - в printSettings словаре должны быть добавлены к копии информации печати документа, и получающаяся информация печати должна использоваться для работы. Когда печать будет завершена или будет отменена, отправьте сообщение, выбранное didPrintSelector делегату с contextInfo как последний параметр. Метод, выбранный didPrintSelector, должен иметь ту же подпись как:
- (void)document:(NSDocument *)document didPrint:(BOOL)didPrintSuccessfully contextInfo:(void *)contextInfo;
Реализация по умолчанию этого метода сначала удостоверяется, что любой редактор зарегистрировал Привязку Какао использования NSEditorRegistration, неофициальный протокол фиксировал свои изменения, затем вызывает [сам printOperationWithSettings:printSettings error:&anError]. Если ноль возвращается, он представляет ошибку пользователю в модальной документом панели прежде, чем передать делегата. Иначе это вызывает [thePrintOperation setShowsPrintPanel:showPrintPanel] тогда [сам runModalPrintOperation:thePrintOperation delegate:delegate didRunSelector:didPrintSelector contextInfo:contextInfo]. Ваш будут должны вряд ли переопределить этот метод.

Этот метод заменяет-printShowingPrintPanel: который теперь осуждается. Для обратной совместимости на уровне двоичных кодов все еще вызывается старый метод, когда надлежащий, если это переопределяется. Когда это - сделанное использование Какао частная функциональность, чтобы принять меры 1), чтобы настройки печати вступили в силу несмотря на то, что переопределение-printShowingPrintPanel: не может возможно знать о них и 2) быть уведомленным, когда работа печати была завершена, таким образом, она может передать делегата в корректное время. Корректный обмен сообщениями делегата необходим для корректной обработки события Print Apple.
- (NSPrintOperation *)printOperationWithSettings:(NSDictionary *)printSettings error:(NSError **)outError;
Создайте работу печати, которая может быть выполнена, чтобы распечатать текущее содержание документа и возвратить его в случае успеха. Если не успешный, возвратите ноль после установки *outError к NSError, инкапсулирующему причину, почему не могла быть создана работа печати. Атрибуты NSPrintInfo в переданном - в printSettings словаре должны быть добавлены к копии информации печати документа, и получающаяся информация печати должна использоваться для работы. Реализация по умолчанию этого метода ничего не делает. Необходимо переопределить его, чтобы позволить распечатать в приложении.

- runModalPageLayoutWithPrintInfo: теперь осуждается, потому что это может только представить модальную приложением панель, которая является плохим пользовательским интерфейсом в этом случае. Используйте-runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo: вместо этого.-runModalPageLayoutWithPrintInfo: никогда не вызывается ниоткуда в Какао, как в Mac OS 10.3 и ранее.


Верхний колонтитул страницы NSView / Нижний колонтитул, Распечатывающий API (Раздел добавил начиная с WWDC),

Тайгер добавляет API, упрощающий для приложения Какао включать верхние колонтитулы страницы и нижние колонтитулы в его печатном выводе. Эта опция прочь по умолчанию, но может быть активирована с помощью нового атрибута NSPrintHeaderAndFooter NSPrintInfo:
APPKIT_EXTERN NSString *NSPrintHeaderAndFooter;
AppKit также распознает значение по умолчанию тождественно-именованного-пользователя, таким образом, эта функция может быть легко протестирована с исполнимой программой существующего приложения путем запуска приложения с набором по умолчанию к YES.

Например:
MyApp.app/Contents/MacOS/MyApp-NSPrintHeaderAndFooter YES

Когда эта опция активирована,-drawPageBorderWithSize NSVIEW: метод, ранее ничего не сделавший, распечатывает заголовок и нижний колонтитул на каждой странице. (Таким образом любое переопределение-drawPageBorderWithSize: должен будет вызвать реализацию super, если она захочет наследовать это поведение.) Заголовок и содержание нижнего колонтитула предоставлены двумя новыми методами NSView:
- (NSAttributedString *)pageHeader;
- (NSAttributedString *)pageFooter;
Реализации NSVIEW этих методов обеспечивают заголовок по умолчанию, включающий должность печати (который обычно совпадает с заголовком документа или заголовком окна), и дата и нижний колонтитул по умолчанию, включающий количество страницы и номер страницы. Печатаемый класс представления может переопределить один или оба из этих методов для замены его собственным содержанием вместо этих значений по умолчанию.

Каждый из этих методов вызывается один раз на страницу во время печати, предложения конструкторам шанс обеспечить потенциально специфичное для страницы содержание заголовка/нижнего колонтитула (включая надлежащий номер страницы и возможно предложение различного содержания или выравнивания для даже по сравнению с нечетными страницами, например). Конструкторы будут обычно консультироваться с объектом printInfo NSPrintOperation получить данные интереса включать в текст заголовка/нижнего колонтитула.

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

Это оставляют до клиентского приложения представить эту функцию в ее пользовательском интерфейсе при желании. Простой флажок в представлении аксессуара листа печати или панель Preferences приложения, был бы достаточен. Приложение, предусмотревшее пользовательскую настройку содержание заголовка/нижнего колонтитула, могло решить пойти далее.


Рисование NSView Перенаправления API (Раздел добавил начиная с WWDC),

Тайгер добавляет три новых метода к NSView, позволяющим приложению попросить, чтобы поддерево представления вовлекло указанный NSBitmapImageRep или NSGraphicsContext. Эта функция может быть использована для взятия снимка получения, сделанного представлением и его потомками, или как кэш для в вычислительном отношении дорогого получения представления, или для использования в некоторой последующей графической работе. Это в настоящее время не поддерживает получение представлений, представляющих на аппаратно ускоренные поверхности (т.е. NSOpenGLViews и NS/QTMovieViews), но иначе работает со всем Основанным на кварце получением представления. Представления, которые будут нарисованы, но нуждаются не, может находиться в окне. Клиент может запросить получение всего содержания представления или некоторую прямоугольную подобласть.

Клиенты этого API должны начать путем получения NSBitmapImageRep надлежащих размерностей и глубины цвета для получения желаемого содержания представления. Такой битовый массив может быть получен с помощью нового метода NSView:
- (NSBitmapImageRep *)bitmapImageRepForCachingDisplayInRect:(NSRect)rect;
Клиент, желающий получать только части получателя, не отсекающиеся представлениями наследователя, должен передать «visibleRect» получателя как параметр NSRect. Также возможно создать снимки части представления, в настоящее время отсекающиеся (вследствие включения NSScrollView, например), путем указания прямоугольника, который является вне visibleRect получателя, но все еще в его границах.-bitmapImageRepForCachingDisplayInRect: метод возвращает новый, автовыпущенный экземпляр NSBitmapImageRep, подходящий для кэширования копии указанной области представления.

Как только подходящий целевой битовый массив был получен, клиент должен инициализировать его, как желаемый прежде, чем попросить, чтобы поддерево представления вовлекло его. Для инициализации битового массива к полностью прозрачному, например, можно было использовать следующий код:
    NSGraphicsContext *bitmapGraphicsContext = [NSGraphicsContext graphicsContextWithBitmapImageRep:cacheBitmapImageRep];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:bitmapGraphicsContext];
[[NSColor clearColor] set];
NSRectFill(NSMakeRect(0, 0, [cacheBitmapImageRep size].width, [cacheBitmapImageRep size].height));
[NSGraphicsContext restoreGraphicsState];
Желаемая область поддерева представления может тогда быть вовлечена в битовый массив с помощью нового метода:
- (void)cacheDisplayInRect:(NSRect)rect toBitmapImageRep:(NSBitmapImageRep *)bitmapImageRep;
«Rect» параметр должен иметь тот же размер, как это передало bitmapImageRepForCachingDisplayInRect:. Этот метод создает NSGraphicsContext для того, чтобы вовлечь NSBitmapImageRep, переводит его систему координат для размещения требуемого прямоугольника в источнике, и затем просит, чтобы поддерево представления вовлекло NSGraphicsContext с помощью другого нового метода NSView:
- (void)displayRectIgnoringOpacity:(NSRect)aRect inContext:(NSGraphicsContext *)context;
Клиенты, хотящие установить различное преобразование или другие графические параметры контекста, могут также отправить это сообщение непосредственно вместо cacheDisplayInRect:toBitmapImageRep: но будет иначе обычно считать последний подход более удобным.

NSView.h содержит объявление для дополнительного нового метода:
- (BOOL)lockFocusIfCanDrawInContext:(NSGraphicsContext *)context;
Это еще не используется в Тайгере, но может быть сделано функциональным в будущем.


NSView-registeredDraggedTypes API

Тайгер добавляет средство доступа-registeredDraggedTypes к NSView. Этот метод может использоваться для запросов представления для набора типов перетаскивания, для которых представление было зарегистрировано через-registerForDraggedTypes. Элементы в возвращенном массиве без определенного порядка, но массив, как гарантируют, не будет содержать двойные записи.


NSView-drawPageBorderWithSize: фиксируйте (Раздел, добавленный начиная с WWDC)

На предыдущих версиях Mac OS X, блокируя фокус для рисования в переопределении-drawPageBorderWithSize NSVIEW: метод применяет преобразование, и отсеките, которые являются неподходящими для рисования в области границы страницы. Обходное решение для этой проблемы обсуждено в Какао: Печать: Обеспечение Пользовательской Схемы Разбиения на страницы. На Тигре обходное решение больше не необходимо, но не нанесет ущерба в приложениях, использующих его.


NSView +new изменение поведения

Для приложений, соединенных на или после Тигра, +new NSVIEW эквивалентен [[выделение ViewClass] init], который является более соответствующим обычному значению +new, чем предыдущее поведение вызова [[выделение ViewClass] initWithFrame:...].

Таким образом, если подкласс NSView переопределит-init, то +new вызовет-init реализацию подкласса, тогда как это было бы обойдено в пользу-initWithFrame: прежде.


NSView преобразовывают, фиксирует

-convertRect:fromView NSVIEW: и-convertRect:toView: методы были фиксированы в Тайгере. Ранее, эти методы могли возвратить rect недостаточной ширины или высоты при некоторых трансформациях.


NSApplication

У Тигра мы изменили поведение NSApplication для некоторых модальных панелей. В то время как модальная панель открыта, теперь возможно скрыть приложение. В то время как открытая панель произошла, также возможно выйти из приложения.

Мы теперь показываем строку меню ранее в запуске приложения - прямо после отправки applicationWillFinishLaunching уведомления. Если Ваше приложение хочет скрыть строку меню на запуске, необходимо вызвать + [NSMenu setMenuBarVisible:NO] во время applicationWillFinishLaunching.

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

Следующие проблемы были решены:

- делегат приложения, реализовавший только application:openFiles: (и не application:openFile:) не был бы в состоянии открыть недавние документы.

- NSWorkspaceWillPowerOffNotification был отправлен каждый раз, когда приложение получило 'выход' AppleEvent, ли от loginwindow, прикрепления или AppleScript. За этим уведомлением теперь только посылают выход из системы, перезапуск или завершение работы.

- секции и NSStatusItems могли предотвратить приложение, делегат которого возвратил YES из-applicationShouldTerminateAfterLastWindowClosed: от завершения, когда закрылось последнее окно.


Перетаскивание (Раздел, обновленный начиная с WWDC)

В Тайгере мы решили проблему, куда смещение передало - [NSView dragImage:at:offset:event:pasteboard:source:slideBack:] был проигнорирован при расположении перетащенного изображения на экране, но не проигнорирован при передаче расположения перетаскивания источнику в draggedImage:endedAt:operation:. Это смещение теперь универсально проигнорировано, потому что оно больше не целесообразно с конкретной реализацией. Эта фиксация применяется только к приложениям, основывался на Тайгере или позже по причинам совместимости.

Мы добавили метод к NSDraggingDestination неофициальный протокол, чтобы позволить перетаскивать места назначения, чтобы указать, что они не интересуются периодическими сообщениями-draggingUpdated. На Пантере и предыдущий, код перетаскивания отправляет периодические сообщения-draggingUpdated месту назначения, даже если нет никакого изменения в перетаскивании (мышь не переместилась, и флаги модификатора не изменились), как задокументировано. Мы добавили новый метод, чтобы позволить перетаскивать места назначения для переопределения этого поведения.
@interface NSObject(NSDraggingDestination)
...
- (BOOL)wantsPeriodicDraggingUpdates;
...
@end
- wantsPeriodicDraggingUpdates будет отправлен в целевое представление перетаскивания или окно, если это ответит. Если место назначения ответит и возвратится нет, то-draggingUpdated сообщения будет отправлен только, когда мышь перемещается или флаг модификатора изменения. Иначе, поведение по умолчанию будет состоять в том, чтобы продолжать отправлять, периодическое перетаскивание обновило сообщения, даже если ничто не изменяется.

Мы добавили возможность указать, что обещание HFS перетаскивает, не используя dragPromisedFilesOfTypes:fromRect:source:slideBack:event:. Источник перетаскивания может теперь добавить NSFilesPromisePboardType к области монтажа непосредственно и должен вызвать setPropertyList:forType: записать массив типов файлов как данные для этого типа. Объект передал в исходном параметре dragImage:at:offset:event:pasteboard:source:slideBack: должен реализовать namesOfPromisedFilesDroppedAtDestination: обеспечить имена файлов, когда отбрасывается перетаскивание.

Мы исправили ошибку, где скрытые представления могли быть целью перетаскивания.


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

У Тигра мы добавили константу, NSDeviceIndependentModifierFlagsMask, чтобы использоваться в поразрядном - и с - [NSEvent modifierFlags] для получения только независимых от устройств флагов modifer. Это позволяет приложения маске от зависимого от устройств modifierFlags, включайте информацию об объединении события. Если какие-либо независимые от устройств флаги модификатора присутствуют в использовании theEvent, например, приложение могло обнаружить:
    if (([theEvent modifierFlags] & NSDeviceIndependentMofidierFlagsMask) != 0) ...
Мы исправили давнишнюю ошибку, куда событие передало NSApplication и NSWindow-discardEventsMatchingMask:beforeEvent: был проигнорирован, и все события в очереди, соответствующей маску, были отброшены. Поскольку приложения основывались на Тайгере или позже, мы теперь проверяем, что времена события против события передали в, и отбрасывание только те события, время события которых ранее. Поскольку приложения основывались на Пантере или ранее, мы продолжаем отбрасывать все события в очереди, соответствующей маску.


События NSScrollWheel (Раздел добавил начиная с WWDC),

Для поддержки прокрутки с более прекрасными зернами, требуемой новыми устройствами, событие NSScrollWheel и обработка событий NSScrollWheel в NSScrollView изменились. Для scrollWheel мышей поля дельты могут теперь содержать дробные компоненты. Эти дробные значения сделаны доступными для приложений, основывался на Тайгере или позже. Приложения основывались на Тайгере или позже которые делают их собственная обработка события NSScrollWheel должна быть подготовлена иметь дело с дробными значениями, например путем округления суммы прокрутки, вычисленной от события до интегрального значения перед прокруткой. Приложения основывались на Пантере или ранее получат интегральные значения, совместимые со значениями, полученными на предыдущих выпусках.

Кроме того, новые устройства могут отправлять событие NSScrollWheel намного более часто, в некоторых случаях и с deltaX и с deltaY 0. Эти события прокрутки содержат зависимую от устройств информацию о прокрутке, которые позволяют NSScrollView делать непрерывную прокрутку, так должен быть передан супер, если Ваш подкласс позволяет NSScrollView делать прокрутку. Если Ваш подкласс делает пользовательскую прокрутку, Вы должны быть подготовлены проигнорировать события NSScrollWheel, deltaX которых и deltaY оба 0. Эти приложения влияния изменения основывались на Тайгере и на предыдущих выпусках.


Поддержка мероприятия планшета

У Пантеры драйверы планшета начали генерировать собственные события планшета в дополнение к событиям от нажатия мыши со встроенными данными планшета. У Тигра мы добавили API, чтобы определить типы событий планшета, обеспечить средства доступа для данных о событии планшета от собственных событий планшета и событий от нажатия мыши с данными планшета, и позволить событиям планшета быть отправленными через цепочку респондента.

Драйверы планшета генерируют события планшета двумя способами. В некоторых случаях (события точки планшета двойной шайбы, «современные» события близости), драйвер генерирует чистые события планшета. Они событие были добавлены к NSEvent.h:
typedef enum _NSEventType {        /* various types of events */
...
NSTabletPoint = 23,
NSTabletProximity = 24,
...
} NSEventType;
Вместе с соответствующими масками:
enum {                    /* masks for the types of events */
...
NSTabletPointMask = 1 << NSTabletPoint,
NSTabletProximityMask = 1 << NSTabletProximity,
...
};
В других случаях (события точки планшета единственной шайбы, события близости совместимости), драйвер генерирует mouseDown/Up/Dragged/Moved события с дополнительными данными планшета. Эти события могут быть идентифицированы их подтипом. Мы опубликовали подтипы события от нажатия мыши, таким образом, приложения могут сказать, когда событие имеет информацию о планшете. Эти подтипы объявляются с точки зрения констант, определенных в IOLLEvent.h:
enum {        /* event subtypes for mouse events */
NSMouseEventSubtype = NX_SUBTYPE_DEFAULT,
NSTabletPointEventSubtype = NX_SUBTYPE_TABLET_POINT,
NSTabletProximityEventSubtype = NX_SUBTYPE_TABLET_PROXIMITY
};
Перечисление NSPointerType объявляет возможные значения, возвращенные-pointerType. Эти значения объявляются с точки зрения констант, которые будут определены в IOLLEvent.h:
/* pointer types for NSTabletProximity events or mouse events with subtype NSTabletProximityEventSubtype*/
typedef enum {
NSUnknownPointingDevice = NX_TABLET_POINTER_UNKNOWN,
NSPenPointingDevice = NX_TABLET_POINTER_PEN,
NSCursorPointingDevice = NX_TABLET_POINTER_CURSOR,
    NSEraserPointingDevice = NX_TABLET_POINTER_ERASER
} NSPointingDeviceType;
Следующее перечисление объявляет, что возможные значения включены в поразрядное - или возвращены-buttonMask. Эти значения объявляются с точки зрения констант, определенных в IOLLEvent.h:
/* button masks for NSTabletPoint events or mouse events with subtype NSTabletPointEventSubtype */
enum {
    NSPenTipMask = NX_TABLET_BUTTON_PENTIPMASK,
    NSPenLowerSideMask = NX_TABLET_BUTTON_PENLOWERSIDEMASK,
    NSPenUpperSideMask = NX_TABLET_BUTTON_PENUPPERSIDEMASK
};
- давление и - сообщения подтипа теперь допустимы для новых типов событий, как описано в комментариях:
/* This message is valid for all mouse down/up/drag events */
/* This message is also valid for mouse events with subtype NSTabletPointEventSubtype and
for NSTabletPoint events on 10.4 or later */
- (float)pressure;
/* this message is valid for kit, system, and app-defined events */
/* this message is also valid for mouse down/up/drag/move events on 10.4 or later */
- (short)subtype;
Кроме того, мы добавили средства доступа для полей событий планшета:
/* this message is valid for mouse events with subtype NSTabletPointEventSubtype or
NSTabletProximityEventSubtype, and for NSTabletPoint and NSTabletProximity events */
- (unsigned int)deviceID; // system-assigned unique device ID
/* these messages are valid for mouse events with subtype NSTabletPointEventSubtype, and for NSTabletPoint events */
- (int)absoluteX; // absolute x coordinate in tablet space at full tablet resolution
- (int)absoluteY; // absolute y coordinate in tablet space at full tablet resolution
- (int)absoluteZ; // absolute z coordinate in tablet space at full tablet resolution
- (unsigned int)buttonMask; // mask indicating which buttons are pressed.
- (NSPoint)tilt; // range is -1 to 1 for both axes
- (float)rotation; // device rotation in degrees
- (float)tangentialPressure; // tangential pressure on the device; range is -1 to 1
- (id)vendorDefined;         // NSArray of 3 vendor defined shorts
/* these messages are valid for mouse events with subtype NSTabletProximityEventSubtype, and  for NSTabletProximity events */
- (unsigned int)vendorID; // vendor defined, typically USB vendor ID
- (unsigned int)tabletID; // vendor defined tablet ID
- (unsigned int)pointingDeviceID; // vendor defined ID of pointing device
- (unsigned int)systemTabletID; // system assigned unique tablet ID
- (unsigned int)vendorPointingDeviceType; // vendor defined pointing device type
- (unsigned int)pointingDeviceSerialNumber; // vendor defined serial number of pointing device
- (unsigned long long)uniqueID; // vendor defined unique ID
- (unsigned int)capabilityMask; // mask representing capabilities of device
- (NSPointingDeviceType)pointingDeviceType; // type of pointing device
- (BOOL)isEnteringProximity; // YES - entering; NO - leaving
Наконец, мы добавили методы NSResponder для чистых типов событий планшета:
@interface NSResponder : NSObject <NSCoding>
...
- (void)tabletPoint:(NSEvent *)theEvent;
- (void)tabletProximity:(NSEvent *)theEvent;
...
@end

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

У Тигра ColorSync добавил возможность обновить профиль ColorSync, присоединенный к контексту окна. На Пантере и предыдущий, профиль ColorSync был определен профилем основного дисплея во время инициализации сервера окна (=login время) и кэшировался и использовался для всех новых контекстов окна. Другими словами, окна не могли взять обновленный профиль ColorSync, пока пользователь не вышел из системы, и въехать задним ходом. Даже новые окна, создаваемые после изменения профиля ColorSync, не были затронуты изменением. У Тигра мы поддержим это поведение для окон, не принимающих новый API. Профиль основного дисплея будет продолжать кэшироваться и использоваться для любого нового контекста окна, не указывающего иначе. Поддержание этой совместимости важно для правильности в приложениях, делающих кэшируемое получение, и желательные по причинам производительности в менее сложных приложениях.

Мы представили новую поддержку ColorSync окнам, хотящим принять ее. Когда профиль дисплея изменился, представление функциональности подразумевает обновление профиля дисплея, присоединенного к окну CGContextRef, и уведомлению окна.
@interface NSWindow : NSResponder
...
- (void)setDisplaysWhenScreenProfileChanges:(BOOL)flag;
- (BOOL)displaysWhenScreenProfileChanges;
...
@end
Если окно возвратит YES для-displaysWhenScreenProfileChanges, то AppKit вызовет CGWindowContextUpdateDisplayInfo для контекста окна, тогда говорят окну отображать, при следующих условиях:
- большинство окна переместилось в различный экран, и профиль дисплея для текущего экрана отличается, чем тот из предыдущего экрана
- мы получаем уведомление от цветной синхронизации, которую профиль дисплея изменил для экрана, содержащего большинство окна
- контекст окна сначала создается (несмотря на то, что в этом случае окну не должны были бы говорить восстановить изображение),

Значение по умолчанию НЕТ.

Мы также добавили уведомление о том, когда профиль дисплея изменился, чтобы быть отправленным после того, как AppKit вызвал CGWindowContextUpdateDisplayInfo и прежде чем окну скажут вывести на экран, так, чтобы окно могло обновить любые внеэкранные кэши:
APPKIT_EXTERN NSString *NSWindowDidChangeScreenProfileNotification;
Делегат окна может автоматически зарегистрироваться для этого уведомления путем реализации нового метода делегата:
@interface NSObject(NSWindowNotifications)
...
- (void)windowDidChangeScreenProfile:(NSNotification *)notification;
...
@end
Добавление дочернего окна с помощью-addChildWindow:ordered: если получатель является экранным, теперь заставляет дочернее окно быть упорядоченным на экране в корректном относительном расположении (выше или ниже).

Мы добавили поддержку нового появления окна, где фон от строки заголовка продолжается на панель инструментов, заставляя их казаться объединенным. Существует новый styleMask NSUnifiedTitleAndToolbarWindowMask для указания этого появления окна.

Кнопка на панели инструментов является теперь дополнительной:
- (void)setShowsToolbarButton:(BOOL)show;
- (BOOL)showsToolbarButton;

NSWindow-disableScreenUpdatesUntilFlush API (Раздел добавил начиная с WWDC),

Когда представление, представляющее на аппаратную поверхность (такую как представление OpenGL) помещается в NSScrollView или NSSplitView, может быть значимое мерцание или отстать, когда перемещены позиция прокрутки или позиция разделителя. Это происходит, потому что каждое перемещение аппаратной поверхности сразу вступает в силу, прежде чем остающееся содержание окна имело возможность нарисовать и сбросить.

Чтобы позволить приложениям устранить этот визуальный артефакт, Тигр, AppKit обеспечивает новое сообщение NSWindow,-disableScreenUpdatesUntilFlush. Это сообщение просит, чтобы окно приостановило экранные обновления, пока обновленное содержание окна впоследствии не сбрасывается на экран. Это сообщение может быть отправлено от представления, собирающегося переместить его аппаратную поверхность, обеспечить, чтобы аппаратное перемещение поверхности и окно восстановили изображение, будет визуально синхронизироваться. Окно отвечает путем непосредственного отключения экранных обновлений через вызов к NSDisableScreenUpdates () и установки флага, который заставит его вызывать NSEnableScreenUpdates () позже, когда окно сбросит. Допустимо отправить это сообщение в данное окно несколько раз во время данного цикла обновления окна; окно только приостановит и повторно включит обновления один раз во время того цикла.

Класс представления, представляющий на аппаратную поверхность, может отправить это сообщение от переопределения-renewGState (метод, который является, сразу вызывается, прежде чем поверхность представления перемещена) эффективно задержать составление композита перемещенной поверхности, пока окно не закончило рисовать и сбрасывать его остающееся содержание.
- (void)renewGState {
NSWindow *window = [self window];
if ([window respondsToSelector:@selector(disableScreenUpdatesUntilFlush)]) {
[window disableScreenUpdatesUntilFlush];
}
[super renewGState];
}
В вышеупомянутом примере,-respondsToSelector: проверка использовалась для обеспечения совместимости предыдущими системными выпусками. В системах предтигра, где NSWindow не имеет никакого-disableScreenUpdatesUntilFlush метода, переопределение-renewGState не будет иметь никакого эффекта.


Объединенные Обновления (Раздел добавил начиная с WWDC),

У Тигра «объединенные обновления» функция графической подсистемы улучшают производительность получения и устраняют визуальный разрыв. Однако это также вызывает приложения, сбрасывающие на экран быстрее, чем 60 кадр/с для остановки при рисовании. Для поддержания обратной совместимости, там существуют проверки совместимости, куда приложения предтигра, останавливающиеся вследствие вспышки, вернулись назад Пантере, сбрасывающей поведение.

Для гарантии лучшей производительности приложения должны воздержаться от анимации на уровнях выше 60 кадр/с. И как прежде, это - хорошая идея использовать setNeedsDisplay NSVIEW: и связанные методы, а не непосредственный метод дисплея, когда это возможно, с тех пор setNeedsDisplay: позволяет объединить обновления получения от различных частей окна и сокращает ненужное сбрасывание до экрана.

Кварцевое приложение Отладки обеспечивает средства отладки, которые могут помочь определить, вспыхивает ли приложение.

Мы ожидаем публиковать технические замечания или Вопросы и ответы по этой теме.


Живые NSWindow изменяют размеры оптимизации

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

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

На Тигре сохранение содержания во время живого изменяет размеры, включен по умолчанию. Однако мы предоставляем окнам путь к уклонению этой оптимизации. Если нет никаких представлений, которые могут использовать в своих интересах его, окно оплатило бы ненужные расходы для сохранения старого содержания.
@interface NSWindow : NSResponder
...
-(void)setPreservesContentDuringLiveResize:(BOOL)flag;
flag - YES to indicate that window should preserve content on live resize, NO otherwise.  Default is YES.
- (BOOL)preservesContentDuringLiveResize;
...
@end
Сохранение содержания на уровне представления отключено по умолчанию для совместимости с представлениями, которые должны перерисовать полностью, когда изменено. Представление может принять сохранение содержания путем реализации следующего для возврата YES:
@interface NSView : NSResponder
...
- (BOOL)preservesContentDuringLiveResize;
...
@end
Представление, возвращающее YES для-preservesContentDuringLiveResize, ответственно за лишение законной силы его собственного грязного rects во время живого, изменяют размеры. Некоторые представления могут счесть удобным реализовать setFrameSize: и сделайте их собственное вычисление. Другие представления захотят способ получить информацию о том, что изменилось. Мы добавляем метод, возвращающий rect представление ранее нарисованного содержания и другого метода, возвращающего rects представление минимальной области к грязному в новых границах. Эти методы можно вызвать во время живого, изменяют размеры, любое время после setFrameSize: был вызван на представлении для живого, изменяют размеры работы (т.е. любое время после реализации NSVIEW setFrameSize: был вызван для того представления), и прежде чем начнется рекурсивный дисплей иерархии представления.
@interface NSView : NSResponder
...
/* the rect returned from -rectPreservedDuringLiveResize indicates the rect the view previously occupied,
in the coordinate system of the current bounds. This may be smaller or larger than the current bounds,
depending on whether the view grew or shrunk. The result of this method is an empty rect for a view that
returns NO from -preservesContentDuringLiveResize or a view in a window that returns NO from
-preservesContentDuringLiveResize
*/
-(NSRect)rectPreservedDuringLiveResize;
/* exposedRects - on return from this method, exposedRects contains a list of rects (at most 4)
indicating the parts of the view that are newly exposed. If the view decreased in both height and width,
this list will be empty. If the view increased in both height and width and stayed anchored in the
upper left corner (currently always true but may change in the future), this list will include a
vertical component and a horizontal component indicating the exposed "L".
count - on return, the number of rectangles in the exposedRects list. Can be 0.
The result of this method is the entire view bounds for a view that returns NO from
-preservesContentDuringLiveResize or a view in a window that returns NO from -preservesContentDuringLiveResize
*/
-(void)getRectsExposedDuringLiveResize:(NSRect[4])exposedRects count:(int *)count;
...
@end

NSWindow graphicsContext

Добавляется новый API graphicsContext. Это возвращает экземпляр NSGraphicsContext, связанный с получателем для вызывающего потока.


Новое Поведение в - [Печать NSWindow:]

В 10.0-10.3.x Mac OS - [Печать NSWindow:] сделал копию [NSPrintInfo sharedPrintInfo], устанавливал некоторые параметры печати в копии и использовал копию при создании работы печати. Установленный один из параметров печати был ориентацией, для соответствия ориентации окна. Это было несоответствующим, потому что это переопределило любую ориентацию, которую пользователь уже установил в совместно используемой информации печати с помощью панели установки страницы. Это было фиксировано. - [Печать NSWindow:] больше не устанавливает ориентацию печати кроме, для обратной совместимости на уровне двоичных кодов, в приложениях, соединенных против Mac OS 10.3 или ранее.


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

Мы добавили «Расположение в переднем» альтернативном пункте меню для пункта меню «Bring All to Front» в Меню окна. Приложения не должны трудно кодировать индексы элементов в Меню окна, поскольку добавление альтернативного пункта меню или любые другие изменения Меню окна, изменит индексы других пунктов меню. Мы ограничили это изменение в приложениях, основывался на Тайгере или позже сохранить совместимость на уровне двоичных кодов.


Металлический фон окна

При использовании цвета фона из металлического окна в другом окне он не заархивирует и разархивирует правильно, и разархивированный цвет потеряет свою динамическую возможность масштабирования. Можно избежать этого в металлическом окне при помощи - [NSWindow backgroundColor] или - [NSColor controlColor] для рисования металлического фона в пользовательских элементах управления.


Ключ NSWindow просматривает цикл

Методы были добавлены, чтобы позволить окну автоматически повторно вычислять ключевой цикл представления после того, как были добавлены представления.
- (void)setAutorecalculatesKeyViewLoop:(BOOL)flag;
- (BOOL)autorecalculatesKeyViewLoop;
- (void)recalculateKeyViewLoop;
Если autorecalculatesKeyViewLoop ДА, то каждый раз, когда представление добавляется к окну, ключевой цикл представления является dirtied и повторно вычисленный автоматически, когда - [NSWindow selectKeyViewFollowingView] или - [NSWindow selectKeyViewPrecedingView] вызываются. Если autorecalculatesKeyViewLoop будет нет, то добавление представлений не будет грязный, ключевой цикл представления и цикл не будут повторно вычислены. Можно всегда вызывать явно recalculateKeyViewLoop, чтобы повторно вычислить цикл и очистить грязный ключевой флаг цикла представления. Метод также вызывают, если ключевой цикл представления должен быть вычислен, когда в окне сначала упорядочивают. Если initialFirstResponder не установлен, вычисленный цикл совпадает с по умолчанию. Это основывается на геометрическом порядке представлений в окне.


Перемещение с помощью клавиатуры

Панель инструментов и секции окна являются теперь достижимым использованием клавиатур <вкладка> механизм навигации. Система перемещения с помощью клавиатуры ожидает отдельные циклы клавиатуры на панели инструментов, содержании окна и каждом содержании секции. Например, цикл клавиатуры в contentView окна должен быть полным циклом (после nextKeyView/previousKeyView), который не оставляет ограничения-contentView. Перемещение с помощью клавиатуры в состоянии достигнуть других циклов (например, перемещение от содержания окна до панели инструментов), через-nextValidKeyView/-previousValidKeyView. Когда надлежащий, next/previousValidKeyView будет представления клавиши Return в других ключевых циклах.


NSAlert

У Тигра мы изменили имена переменной экземпляра NSAlert, который будет снабжен префиксом подчеркиваниями, чтобы быть соответствующими соглашениям о присвоении имен AppKit. Это не должно иметь никаких импликаций совместимости на уровне двоичных кодов, но может потребовать, чтобы исходные изменения в любом NSAlert разделили это на подклассы ссылочные переменные экземпляра по имени. (Конечно, так как если не указано иное переменные экземпляра классов Какао являются частными, приложения не должны получать доступ к переменным экземпляра.)


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

+ [Экраны NSScreen] больше не будут возвращать многократные экраны, когда будет включено зеркальное отражение.


Текст

Текстовая строка запоминающего устройства системы (как получено строковыми методами на NSTextView или NSTextStorage) теперь делает лучшую проверку параметра приложения, соединенные на Тайгере.

Оказывается initWithRTF:documentAttributes: initWithDocFormat:documentAttributes: и initWithRTFD:documentAttributes: мог вызвать катастрофический отказ, если бы документу не удалось открыться, и сообщение было отправлено NSTextStorage. Это было фиксировано в Тайгере и в 10.3.3, но в ранее 10.3.x выпускает единственное разумное обходное решение, должен избежать этих сообщений, если могли бы не открыться предоставленные данные. Можно использовать метод чтения или вызвать их на NSAttributedString.


NSTypesetter

Набор API, представленного как часть NSATSTypesetter в Mac OS X 10.3 Пантер, перемещен в NSTypesetter. Приложения могут теперь реализовать конкретный подкласс с механизмом пользовательского макета путем переопределения layoutParagraphAtPoint: метод.

NSSimpleHorizontalTypesetter осуждается, и его объявление интерфейса перемещено в новый заголовок NSSimpleHorizontalTypesetter.h.

В дополнение к интерфейсу, перемещенному от NSATSTypesetter, NSTypesetter имеет дополнительный новый API:

paragraphCharacterRange и paragraphSeparatorCharacterRange возвращают диапазоны в символьном пространстве, соответствующем их дубликатам версии глифа. attributesForExtraLineFragment для доступа к информации о стилях, которая должна использоваться для дополнительного фрагмента строки. actionForControlCharacterAtIndex: используется для определения действий triggerd от управляющего символа в индексе.

Новый API -getLineFragmentRect:usedRect:emainingRect:forStartingGlyphAtIndex:proposedRect:lineSpacing:paragraphSpacingBefore:paragraphSpacingAfter: заменяет-lineFragmentRectForProposedRect:remainingRect: в NSATSTypesetter.


NSATSTypesetter

lineFragmentRectForProposedRect:remainingRect: осуждается. Обратитесь к новому API, предоставленному основным классом NSTypesetter getLineFragmentRect:usedRect:emainingRect:forStartingGlyphAtIndex:proposedRect:lineSpacing:paragraphSpacingBefore:paragraphSpacingAfter:.


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

Понятие выбора в NSTextView было расширено для разрешения выбора многократных несмежных диапазонов сразу. Два новых примитива для выбора
- (void)setSelectedRanges:(NSArray *)ranges affinity:(NSSelectionAffinity)affinity stillSelecting:(BOOL)flag;
- (NSArray *)selectedRanges;
найдите что-либо подобное к существующему setSelectedRange:affinity:stillSelecting и selectedRange методам. Существующие однодиапазонные методы setSelectedRange: setSelectedRange:affinity:stillSelecting, и selectedRange теперь определяются с точки зрения этих новых методов. Сродство и stillSelectingFlag параметры сохраняют их неизменные актуальные значения. Параметр диапазонов требуется, чтобы быть ненолем, непустым массивом объектов, отвечающих на - (NSRange) rangeValue. selectedRanges метод, как гарантируют, возвратит массив, удовлетворяющий те же критерии, и кроме того его элементы будут сортированы, возрастая расположением, и несмежный (т.е. если r1 появится прежде r2 тогда NSMaxRange (r1) <r2.location), и кроме того если будет больше чем один элемент тогда, то никакой элемент не будет иметь нуль длины.

Существует несколько дополнительных новых методов NSTextView:
- (void)setSelectedRanges:(NSArray *)ranges;
- (NSArray *)rangesForUserTextChange;
- (NSArray *)rangesForUserCharacterAttributeChange;
- (NSArray *)rangesForUserParagraphAttributeChange;
- (BOOL)shouldChangeTextInRanges:(NSArray *)affectedRanges replacementStrings:(NSArray *)replacementStrings;
Первым является удобный метод, параллельный существующему setSelectedRange:. Следующие три параллельны существующему rangeForUserTextChange, rangeForUserCharacterAttributeChange, и rangeForUserParagraphAttributeChange методам, повинуясь тем же ограничениям, описанным выше для selectedRanges, за исключением того, что они возвратят ноль в случае, если надлежащее изменение не разрешено в ситуациях, в которых существующие однодиапазонные методы теперь возвращаются (NSNotFound, 0). Последнее подобно существующему shouldChangeTextInRange:replacementString:; массив replacementStrings должен или быть нолем или иначе содержать один элемент для каждого диапазона в affectedRanges.

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

Существует два новых метода делегата NSTextView:
- (NSArray *)textView:(NSTextView *)textView
willChangeSelectionFromCharacterRanges:(NSArray *)oldSelectedCharRanges
toCharacterRanges:(NSArray *)newSelectedCharRanges;
- (BOOL)textView:(NSTextView *)textView
shouldChangeTextInRanges:(NSArray *)affectedRanges
replacementStrings:(NSArray *)replacementStrings;
в котором параметры удовлетворяют критерии как те из возвращаемого значения selectedRanges. В первом возвращаемое значение должно удовлетворить критерии как те для параметра диапазонов setSelectedRanges:affinity:stillSelecting:.

Если делегат реализует старый метод делегата
- (NSRange)textView:(NSTextView *)textView
willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange
toCharacterRange:(NSRange)newSelectedCharRange;
а не новый, тогда множественный выбор будет эффективно запрещен; попытки установить выбранные диапазоны вызовут старый метод делегата с первым поддиапазоном, и впоследствии только единственный выбранный диапазон будет установлен. Если делегат реализует новый метод, то старый будет проигнорирован.

Если делегат реализует старый метод делегата
- (BOOL)textView:(NSTextView *)textView
shouldChangeTextInRange:(NSRange)affectedCharRange
replacementString:(NSString *)replacementString;
тогда это вызовут с надлежащим диапазоном и строкой. Если делегат реализует новый метод, то старый будет проигнорирован.

Существует несколько средних значений, предусмотрел пользователей, чтобы сделать множественный выбор. Во-первых, выбор команды может использоваться в текстовом представлении с обычным значением - это выбирает новые части текста, или уже отменяет выбранную часть. Во-вторых, выбор опции может использоваться в текстовом представлении, чтобы сделать прямоугольный выбор; существует отличительный курсор, предусмотрел этот режим. Значение по умолчанию предоставлено, NSProhibitMultipleTextSelectionByMouse, для управления этим поведением; если значение по умолчанию будет установлено в ДА, то команда - и выбор опции в тексте не будет иметь их новых особых значений, но будет вести себя, как они сделали у Пантеры. Этот механизм позволяет новым средним значениям выбора быть выключенными для приложений, в которых они не могут быть желаемы.

Кроме того, двум новым NSFindPanelActions предоставлены, NSFindPanelSelectAll и NSFindPanelSelectAllInSelection, для разрешения выбора всех экземпляров определенной строки поиска; если клавиша CTRL удерживается, стандартная панель находки использует их. Наконец, панель стилей поддерживает выбор всего текста, имеющего определенный стиль - это могло использоваться, например для выбора всего текста в данном шрифте, тогда впоследствии преобразовать его в различный шрифт, или выбрать весь подчеркнутый текст и впоследствии выделить курсивом его.


Удаление переопределения-attributedSubstringFromRange: в категории NSTextStorage

В Mac OS, 10.0-10.3.x было переопределение - [NSAttributedString attributedSubstringFromRange:] в частной категории NSTextStorage. Переопределение возвратило экземпляр NSSubTextStorage, частный подкласс NSTextStorage (и поэтому NSAttributedString) используемый подсистемой сценариев Какао. Этот объект NSSubTextStorage реагировал на все сообщения NSAttributedString, но его значение изменится со значением «родительского» NSAttributedString, который не был корректен и вызвал несколько трудно диагностируемых ошибок. Это переопределение было удалено. NSTextStorages теперь возвращают невидоизменяющийся NSAttributedStrings, когда отправлено-attributedSubstringFromRange: сообщение.


NSParagraphStyle

Функции NSParagraphStyle новые методы hyphenationFactor и tighteningFactorForTruncation. Соответствующие методы писателя, setHyphenationFactor: и setTighteningFactorForTruncation: добавляются к NSMutableParagraphStyle.


Уровень заголовка NSParagraphStyle

NSParagraphStyle теперь определяет новый атрибут, уровень заголовка, целое число, которое должно или быть 0 или иначе в диапазоне 1-6. Это в настоящее время используется только для импорта/экспорта HTML, определяя, является ли определенный абзац заголовком или не и раз так какой уровень. Соответствующие методы
- (int)headerLevel;
на NSParagraphStyle и
- (void)setHeaderLevel:(int)level;
на NSMutableParagraphStyle.


Направление записи основы

Методы доступа для направления записи основы, baseWritingDirection и setBaseWritingDirection: были добавлены к NSCell, NSControl и классам NSText.

Кроме того, NSTextView и NSMutableAttributedString теперь имеют setBaseWritingDirection:range: API.


NSStringDrawing

Новые методы были добавлены к NSString и категориям NSAttributedString, определенным в NSStringDrawing.h. drawWithRect:options: и boundingRectWithSize:options: предложите более точную строковую функциональность рендеринга/калибровки.


NSFont и NSFontDescriptor

NSFont и классы NSFontDescriptor были реструктурированы. NSFontDescriptor теперь продвинут, чтобы быть основной ссылкой шрифта в AppKit, заменяющем имена Постскриптума. Кроме того, новые функциональности, такие как подстановка шрифтов, замена шрифтов и расположение каскадом шрифта встроены в класс NSFontDescriptor.


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

Класс NSGlyphInfo теперь соответствует протоколу NSCopying.


NSTextView, вводящий метод делегата атрибутов

В дополнение к существующему уведомлению NSTextView теперь имеет новый метод делегата, разрешающий делегату вмешиваться, чтобы позволить, предотвратить, или изменить изменения во вводе атрибутов:
- (NSDictionary *)textView:(NSTextView *)textView
shouldChangeTypingAttributes:(NSDictionary *)oldTypingAttributes
toAttributes:(NSDictionary *)newTypingAttributes;

Объединение отмены NSTextView (Раздел добавил начиная с WWDC),

NSTextView теперь представляет новый метод для управления объединением отмены:
- (void)breakUndoCoalescing;
Это полезно, например, как способ заставить приложение предотвращать последовательные операции ввода прежде и после сохранения из того, чтобы быть объединенным в единственный невыполнимый элемент текстовым представлением.


Новые методы респондента

NSResponder теперь определяет два новых метода действия, реализованные в NSTextView. Первое предназначается для вставки разрыва строки (в отличие от конца абзаца). Реализация NSTextView вводит NSLineSeparatorCharacter. Второе предназначается для вставки контейнерного повреждения (обычно разрыв страницы). Реализация NSTextView вводит NSFormFeedCharacter.
- (void)insertLineBreak:(id)sender;
- (void)insertContainerBreak:(id)sender;

Текстовые таблицы (Раздел, обновленный начиная с WWDC)

Текстовая система Какао теперь поддерживает таблицы. Основной включенный объект является новым классом, NSTextBlock, представляющим блок текста, который должен быть размечен в подобласти текстового контейнера. Самым важным подклассом является NSTextTableBlock, представляющий блок текста, появляющегося как ячейка в таблице. Сама таблица представлена отдельным классом, NSTextTable, на который ссылаются все его NSTextTableBlocks и управляющим их калибровкой и расположением.

Текстовые блоки появляются как атрибуты в абзацах как часть стиля абзаца. NSParagraphStyle теперь может иметь массив текстовых блоков, представляя вложенные блоки, содержащие абзац, в порядке от наиболее удаленного до самого внутреннего. Например, если block1 будет содержать четыре абзаца, средние два из которых находятся также во внутреннем block2, тогда то массив текстовых блоков для первых и четвертых абзацев будет (block1), в то время как массив текстовых блоков для вторых и третьих абзацев будет (block1, block2).

Методы, реализовывая это
- (NSArray *)textBlocks
на NSParagraphStyle, и
- (void)setTextBlocks:(NSArray *)array
на NSMutableParagraphStyle.

Кроме того, существуют удобные методы для NSAttributedString для определения диапазона, покрытого блоком или таблицей (или (NSNotFound, 0), если данное расположение не находится в указанном блоке или таблице):
- (NSRange)rangeOfTextBlock:(NSTextBlock *)block atIndex:(unsigned)location;
- (NSRange)rangeOfTextTable:(NSTextTable *)table atIndex:(unsigned)location;
Во время расположения наборное устройство предлагает большой rect, в котором должен соответствовать определенный блок. Для наиболее удаленного блока это будет определено текстовым контейнером; для внутренних блоков это будет определено содержанием блока. Блочный объект тогда решает, какой subrect этого он должен фактически привести в рабочее состояние. Существует фактически два rects, определяющиеся: во-первых, расположение rect, в котором должен быть размечен текст в блоке; во-вторых, границы rect, который также содержит пространство для дополнения, границ, декоративного обрамления, полей, и т.д. Расположение rect сразу определяется, прежде чем первый глиф в определенном блоке размечается, потому что это необходимо для всего последующего расположения текста в блоке. Это часто будет довольно высоко, потому что в этой точке еще не была определена высота текста, размеченного в блоке. Границы rect сразу определяются после того, как последний глиф в блоке был размечен, и это основывается на фактическом используемом rect для текста в блоке.

Методы на NSTextBlock, которые вызывает наборное устройство,
- (NSRect)rectForLayoutAtPoint:(NSPoint)startingPoint inRect:(NSRect)rect
textContainer:(NSTextContainer *)textContainer characterRange:(NSRange)charRange;
- (NSRect)boundsRectForContentRect:(NSRect)contentRect inRect:(NSRect)rect
textContainer:(NSTextContainer *)textContainer characterRange:(NSRange)charRange;
NSTextTableBlock призовет свой NSTextTable выполнять эти вычисления, с помощью его методов
- (NSRect)rectForBlock:(NSTextTableBlock *)block layoutAtPoint:(NSPoint)startingPoint inRect:(NSRect)rect
textContainer:(NSTextContainer *)textContainer characterRange:(NSRange)charRange;
- (NSRect)boundsRectForBlock:(NSTextTableBlock *)block contentRect:(NSRect)contentRect inRect:(NSRect)rect
textContainer:(NSTextContainer *)textContainer characterRange:(NSRange)charRange;
Наборное устройство хранит результаты этих методов в менеджере по расположению. Новые методы NSLayoutManager:
- (void)setLayoutRect:(NSRect)rect forTextBlock:(NSTextBlock *)block glyphRange:(NSRange)glyphRange;
- (void)setBoundsRect:(NSRect)rect forTextBlock:(NSTextBlock *)block glyphRange:(NSRange)glyphRange;
- (NSRect)layoutRectForTextBlock:(NSTextBlock *)block glyphRange:(NSRange)glyphRange;
- (NSRect)boundsRectForTextBlock:(NSTextBlock *)block glyphRange:(NSRange)glyphRange;
- (NSRect)layoutRectForTextBlock:(NSTextBlock *)block atIndex:(unsigned)glyphIndex effectiveRange:(NSRangePointer)effectiveGlyphRange;
- (NSRect)boundsRectForTextBlock:(NSTextBlock *)block atIndex:(unsigned)glyphIndex effectiveRange:(NSRangePointer)effectiveGlyphRange;
- (NSRect)lineFragmentRectForGlyphAtIndex:(unsigned)glyphIndex effectiveRange:(NSRangePointer)effectiveGlyphRange
withoutAdditionalLayout:(BOOL)flag;
- (NSRect)lineFragmentUsedRectForGlyphAtIndex:(unsigned)glyphIndex effectiveRange:(NSRangePointer)effectiveGlyphRange
withoutAdditionalLayout:(BOOL)flag;
- (NSTextContainer *)textContainerForGlyphAtIndex:(unsigned)glyphIndex effectiveRange:(NSRangePointer)effectiveGlyphRange
withoutAdditionalLayout:(BOOL)flag;
Первые два метода используются наборным устройством, чтобы хранить информацию, полученную из текстовых блоков. Другие используются во время расположения, когда необходимо определить, какое пространство было приведено в рабочее состояние ранее положенными блоками. Последние три являются вариантами существующих методов, имеющих опцию не порождения дополнительного расположения; когда их вызывают во время расположения, их нужно вызвать таким способом как для не принуждения дальнейшего расположения, чтобы избежать бесконечной рекурсии. По той же причине... Методы RectForTextBlock вызывают генерацию глифа, но не расположение; если никакой rect не был установлен, они возвращают NSZeroRect. Расположение rect должно быть сразу установлено, прежде чем первый глиф в блоке размечается; границы rect должны быть сразу установлены после того, как последний глиф в блоке был размечен. При некоторых обстоятельствах границы rect могут быть скорректированы впоследствии, поскольку размечаются дополнительные блоки в той же таблице.

Во время дисплея текст составлен, как обычно, но текстовый блок призван для рисования любого фонового или декоративного обрамления, в то время как фоны глифа рисуются, с помощью следующего метода:
- (void)drawBackgroundWithFrame:(NSRect)frameRect inView:(NSView *)controlView
characterRange:(NSRange)charRange layoutManager:(NSLayoutManager *)layoutManager;
и снова NSTextTableBlocks призывают свой NSTextTable к этому использованию его метода:
- (void)drawBackgroundForBlock:(NSTextTableBlock *)block withFrame:(NSRect)frameRect
inView:(NSView *)controlView characterRange:(NSRange)charRange
layoutManager:(NSLayoutManager *)layoutManager;
Калибровка и расположение модели для текстовых блоков включают много размерностей для каждого блока, каждая из которых может или иметь абсолютное значение в точках или иначе быть выражена как процент содержания блока. Эти размерности включают ширину, высоту, минимальную и максимальную ширину и высоту, и поле, границу и дополнительные ширины для каждой из этих четырех сторон. Значение по умолчанию в каждом случае будет 0, не означая поля/границы/дополнения и естественной ширины и высоты. Определенные части блока будут иметь свои собственные цвета, значение по умолчанию, являющееся нолем ни для какого цвета.
- (void)setValue:(float)val type:(NSTextBlockValueType)type forDimension:(NSTextBlockDimension)dimension;
- (float)valueForDimension:(NSTextBlockDimension)dimension;
- (NSTextBlockValueType)valueTypeForDimension:(NSTextBlockDimension)dimension;
- (void)setWidth:(float)val type:(NSTextBlockValueType)type forLayer:(NSTextBlockLayer)layer edge:(NSRectEdge)edge;
- (void)setWidth:(float)val type:(NSTextBlockValueType)type forLayer:(NSTextBlockLayer)layer; // Convenience method
- (float)widthForLayer:(NSTextBlockLayer)layer edge:(NSRectEdge)edge;
- (NSTextBlockValueType)widthValueTypeForLayer:(NSTextBlockLayer)layer edge:(NSRectEdge)edge;
- (void)setBackgroundColor:(NSColor *)color;
- (NSColor *)backgroundColor;
- (void)setBorderColor:(NSColor *)color forEdge:(NSRectEdge)edge;
- (void)setBorderColor:(NSColor *)color; // Convenience method sets all edges at once
- (NSColor *)borderColorForEdge:(NSRectEdge)edge;
NSTextTableBlock и экземпляры NSTextTable имеют дополнительные методы, определенные для ячеек таблицы и для таблиц. Для NSTextTableBlock:
- (id)initWithTable:(NSTextTable *)table startingRow:(int)row rowSpan:(int)rowSpan
startingColumn:(int)col columnSpan:(int)colSpan; /* Designated initializer */
- (NSTextTable *)table;
- (int)startingRow;
- (int)rowSpan;
- (int)startingColumn;
- (int)columnSpan;
Для NSTextTable:
- (unsigned)numberOfColumns;
- (void)setNumberOfColumns:(unsigned)numCols;
- (NSTextTableLayoutAlgorithm)layoutAlgorithm;
- (void)setLayoutAlgorithm:(NSTextTableLayoutAlgorithm)algorithm;
- (BOOL)collapsesBorders;
- (void)setCollapsesBorders:(BOOL)flag;
- (BOOL)hidesEmptyCells;
- (void)setHidesEmptyCells:(BOOL)flag;

Текстовые списки

Текстовая система Какао теперь поддерживает списки. Основной включенный объект является новым классом, NSTextList, представляющим раздел текста, формирующего единственный список. Видимые элементы списка, включая маркеры списка, все еще появятся в тексте, как они делают для списков, создаваемых вручную сегодня. Объект списка, однако, позволит списку быть распознанным как таковой текстовой системой, так, чтобы маркеры и интервал могли быть автоматически созданы для пользователя, и так, чтобы списки могли быть должным образом отмечены при сохранении в различных форматах RTF.

Текстовые списки появляются как атрибуты в абзацах как часть стиля абзаца. NSParagraphStyle теперь может иметь массив текстовых списков, представляя вложенные списки, содержащие абзац, в порядке от наиболее удаленного до самого внутреннего. Например, если list1 будет содержать четыре абзаца, средние два из которых находятся также во внутреннем list2, тогда то текстовый массив списков для первых и четвертых абзацев будет (list1), в то время как текстовый массив списков для вторых и третьих абзацев будет (list1, list2).

Методы, реализовывая это
- (NSArray *)textLists
на NSParagraphStyle, и
- (void)setTextLists:(NSArray *)array
на NSMutableParagraphStyle.

Кроме того, существуют удобные методы для NSAttributedString для определения диапазона, охваченного списком и порядковой позицией в списке определенного элемента:
- (NSRange)rangeOfTextList:(NSTextList *)list atIndex:(unsigned)location;
- (int)itemNumberInTextList:(NSTextList *)list atIndex:(unsigned)location;
Сам объект NSTextList описывает формат маркеров списков:
- (id)initWithMarkerFormat:(NSString *)format options:(unsigned)mask;
- (NSString *)markerFormat;
- (unsigned)listOptions;
- (NSString *)markerForItemNumber:(int)itemNum;
Здесь «маркер» относится к вычисленному значению для определенной порядковой позиции в списке, и «формат маркера» относится к универсальной строке, используемой для указания формата для всех маркеров в списке. Формат маркера интерпретируется как постоянная строка, за исключением спецификатора нумерации, который примет форму «{<ключевое слово>} «. В настоящее время поддерживаемые значения для <ключевого слова> включают десятичное число, более низкого римлянина, верхнего римлянина, более низкую альфу и верхнюю альфу. Таким образом» ({десятичное число})» был бы формат для списка номер (1), (2), (3)... Единственным значением опции, в настоящее время определяемым, является NSTextListPrependEnclosingMarker, сигнализируя, что вложенный список должен включать маркер для своего суперсписка включения перед его собственным маркером.


Текстовые Панели (Раздел, обновленный начиная с WWDC)

NSTextView теперь определяет несколько методов действия, предназначающихся для переноса на следующий период панелей, чтобы позволить пользователю управлять расстоянием между абзацами, ссылками, списками и таблицами в тексте. TextEdit теперь имеет пункт меню, соответствующий каждому из этих методов действия:
- (void)orderFrontSpacingPanel:(id)sender;
- (void)orderFrontLinkPanel:(id)sender;
- (void)orderFrontListPanel:(id)sender;
- (void)orderFrontTablePanel:(id)sender;
Существует теперь несколько средних значений, предусмотрел пользователей, чтобы добавить и управлять ссылками в тексте. Ссылки могут создаваться, управляться или удалили использование панели ссылки; они могут также быть перетащены или скопированы и вставлены к или из других приложений. Кроме того, если ссылка уже будет присутствовать в тексте, то щелчок управления по ссылке переведет контекстное меню в рабочее состояние с несколькими опциями, связанными со ссылкой.

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

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


Текстовый Импорт/Экспорт (Раздел, обновленный начиная с WWDC)

Текстовая система Какао может теперь импортировать следующие форматы: простой текст, RTF, RTFD, SimpleText, формат документа, WordML, HTML и WebArchive. Это может теперь экспортировать все их за исключением SimpleText. Вместо того, чтобы добавить новые методы для каждого нового формата, NSAttributedString и NSMutableAttributedString теперь имеют методы общего назначения, позволяющие формату быть указанным в качестве параметра. Существующие методы остаются как удобства.

Новые методы на NSAttributedString:
- (id)initWithURL:(NSURL *)url options:(NSDictionary *)options documentAttributes:(NSDictionary **)dict error:(NSError **)error;
- (id)initWithData:(NSData *)data options:(NSDictionary *)options documentAttributes:(NSDictionary **)dict error:(NSError **)error;
- (NSData *)dataFromRange:(NSRange)range documentAttributes:(NSDictionary *)dict error:(NSError **)error;
- (NSFileWrapper *)fileWrapperFromRange:(NSRange)range documentAttributes:(NSDictionary *)dict error:(NSError **)error;
Первые два метода подобны существующим методам, но с добавлением параметра ошибок. Последние два метода аналогично добавляют параметр ошибок, но кроме того они требуют, чтобы тип документа был указан в словаре атрибутов документа. Последний метод возвращает обертку файла каталога в подходящих случаях для типа документа, иначе регулярная обертка файла.

Новые методы на NSMutableAttributedString:
- (BOOL)readFromURL:(NSURL *)url options:(NSDictionary *)opts documentAttributes:(NSDictionary **)dict error:(NSError **)error;
- (BOOL)readFromData:(NSData *)data options:(NSDictionary *)opts documentAttributes:(NSDictionary **)dict error:(NSError **)error;
которые снова подобны существующим методам, но с добавлением параметра ошибок.

Существует много новых констант, используемых в текстовом импорте/экспорте. Существует новый тип документа
NSString *NSWebArchiveTextDocumentType;
для типа WebKit WebArchive; фактический используемый формат является представлением данных WebArchive.

Константы были определены для всех существующих атрибутов документа и ключей опций; значения все еще указаны для существующих ключей для обратной совместимости с предыдущими версиями системы. (Для использования их в системах Пантеры используйте фактическое строковое значение идентификатора, где предоставленный в комментариях.), Кроме того, некоторые новые ключи были добавлены (см. ниже), и у некоторых есть немного отличающиеся использования. NSCharacterEncodingDocumentAttribute теперь используется и для импорта и для экспорта документов простого текста. NSCocoaVersionDocumentAttribute все еще возвращает NSNumber, но теперь он может иметь значение с плавающей точкой; для Тайгера и позже, этим значением будет NSAppKitVersionNumber для версии AppKit, создавшей файл. Предыдущие значения должны быть интерпретированы следующим образом: значения меньше чем 100 - предварительный Mac OS X; 100 Mac OS X 10.0 и 10.1; 102 Mac OS X 10.2 и 10.3.

Различные атрибуты документа (автор, предмет, и т.д.) могут теперь быть считаны и записаны в файлах обогащенного текста. Ключевые слова для этого были определены в AppKit/NSAttributedString.h:
NSString *NSTitleDocumentAttribute;
NSString *NSCompanyDocumentAttribute;
NSString *NSSubjectDocumentAttribute;
NSString *NSAuthorDocumentAttribute;
NSString *NSKeywordsDocumentAttribute;
NSString *NSCommentDocumentAttribute;
NSString *NSEditorDocumentAttribute;
NSString *NSCreationTimeDocumentAttribute;
NSString *NSCopyrightDocumentAttribute;
Панель «Document Properties» TextEdit демонстрирует использование некоторых из этих ключевых слов.


Импорт/Экспорт HTML (Раздел, обновленный начиная с WWDC)

Текстовая система Какао теперь импортирует и экспортирует HTML. Импорт HTML был полностью пересмотрен, чтобы использовать WebKit во всех случаях и использовать новую поддержку текстовой таблицы и списка. Для Тигра опция документа «UseWebKit» больше не будет релевантна, и NSTimeoutDocumentOption, NSWebPreferencesDocumentOption, и NSWebResourceLoadDelegateDocumentOption всегда будет доступен.

Существует теперь дополнительная опция документа,
NSString *NSTextSizeMultiplierDocumentOption;
который указывает масштабный коэффициент для размеров шрифта, соответствуя textSizeMultiplier WebView, то же значение, представленное в Safari через меню «Make Text Bigger/Smaller» и элементы панели инструментов.

NSCharacterEncodingDocumentAttribute теперь доступен для использования в экспорте HTML. Если это не будет указано, то кодировка по умолчанию для экспорта HTML будет UTF-8. Символы, не непосредственно представимые в указанном кодировании, будут представлены символьными ссылками - обычно ссылки цифрового символа, но ссылки символьной сущности могут использоваться в определенных особых случаях. (В настоящее время некоторые кодировки не могут полностью поддерживаться.)

Типом сгенерированного HTML управляет новый атрибут документа,
NSString *NSExcludedElementsDocumentAttribute;
Это должно быть NSArray, содержащим строки (нечувствительные к регистру), которые являются именами элементов HTML плюс несколько дополнительных стоимостей: DOCTYPE (представляющий doctype объявление) и XML (представляющий определение XML), и определенные специфичные для Apple значения, описанные ниже. Элементы, содержавшиеся в этом списке, являются теми, которые не будут использоваться в генерации HTML; текстовая система использует любые другие элементы HTML, как она считает целесообразным. По умолчанию, если никакой список не будет указан, то исключенные элементы будут теми, которые осуждаются в HTML 4 - а именно, APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, и U - плюс XML. Когда XML будет в исключенном списке, HTML-формы будут использоваться, где существует различие; когда это будет удалено из списка, формы XHTML будут использоваться.

Клиенты, указывающие список, будут иметь значительный контроль над сгенерированным HTML, например:

- Удалите U из этого списка, и U будет использоваться для подчеркнутого текста (и doctype больше не будет строг).
- Удалите XML из этого списка, и определение XML будет сгенерировано, и формы XHTML будут использоваться.
- Добавьте STYLE к этому списку, и стили будут встроены, а не помещены в голову.
- Удалите FONT из этого списка, и Теги шрифта будут сгенерированы.
- Добавьте B, меня, SUB и SUPER к этому списку, и CSS будет использоваться для всего моделирования.
- С другой стороны добавьте SPAN к этому списку, и никакой CSS вообще не будет использоваться.
- Добавьте к этому списку, и все ссылки будут подавлены.
- Добавьте IMG и OBJECT к этому списку, и все присоединения будут разделены.
- Добавьте DOCTYPE к этому списку, и никакой doctype не будет сгенерирован.
- Добавьте META к этому списку, и все метатеги будут подавлены.
- Добавьте HEAD к этому списку, и вся главная информация будет подавлена (и стили будут встроены).
- Добавьте BODY к этому списку, и тег основного текста будет опущен (но организация будет все еще сгенерирована).
- Добавьте DOCTYPE, HTML, HEAD и BODY к этому списку, и результатом будет пустой отрывок HTML (со встроенными стилями).
- Добавьте DOCTYPE и каждый HTML-тэг кроме B и меня, и результатом будет пустой отрывок HTML с помощью только B и я.

Сгенерированный doctype зависит от списка элементов. Если XML будет в исключенном списке, то HTML doctype будет использоваться; иначе XHTML будет использоваться. Если какой-либо из осуждаемых элементов HTML 4 не будет в списке, или если P будет в списке, то переходный doctype будет использоваться; иначе строгий doctype будет использоваться. Однако во всех случаях doctype будет использоваться, только если сгенерированный HTML фактически соответствует ему (например, все соответствующие doctypes требуют TITLE).

Существует два специфичных для Apple значения, которые могут быть добавлены к исключенному массиву элементов: преобразованное пространство Apple и Преобразованная вкладка Apple. Если они будут отсутствовать в массиве, то экспорт HTML добавит элементы SPAN с этими именами классов как механизм для сохранения определенных типов пробела (вкладки и многократные пробелы), которые иначе не имеют никакого точного представления в HTML. Если они будут присутствовать в массиве, то сгенерированный HTML не будет содержать эти несколько громоздкие элементы SPAN. Существует также треть распознанное значение, Новая строка обмена Apple, но в настоящее время не включается ее использование. В случае TextEdit присутствием этих значений управляет флажок «Preserve white space» в части HTML открытого, и сохраните предпочтительную область.

Форматом сгенерированного HTML также управляет новый атрибут документа,
NSString *NSPrefixSpacesDocumentAttribute;
Это должно быть NSNumber, содержащим целое число (значение по умолчанию 0) представление числа пробелов на уровень, которым определенные вложенные элементы HTML (особенно элементы, вовлеченные в представление списков и таблиц), должны быть расположены с отступом от запуска строки. Это автоматическое добавление отступа делает получающийся HTML более читаемым.


RTF

Обработка \expnd была фиксирована для обработки параметра как четверти точек, а не полуточек. (Обратите внимание на то, что на практике эта ошибка не оказывала влияния, поскольку мы всегда следуем за \expnd с \expndtw, правильно указывающим значение в twips.)

Файлы RTF могут теперь обработать дополнительные дробные размеры. (Спецификация RTF позволяет только точность полуточки.)

«Никакой кернинг» теперь не сохраняется в файлах RTF; это не выписывалось правильно.


Инструмент командной строки (Раздел добавил начиная с WWDC),

Существует теперь инструмент,/usr/bin/textutil, который предоставляет доступ командной строки к средствам импорта/экспорта текстовой системы Какао. Это может использоваться для проверки свойств файлов для изменения атрибутов, и для преобразования между любым из типов файлов, которые поддерживает текстовая система. Примеры могли бы включать: определение формата и атрибутов метаданных файла; добавление или изменение метаданных, таких как автор или заголовок; преобразование между HTML и RTF; извлечение простого текста из документов обогащенного текста; или преобразование простого текста от одного кодирования до другого. Для получения дополнительной информации см. «человека 1 textutil».


Режимы NSFontPanel

Мы добавили следующие режимы к NSFontPanel, чтобы позволить отключать эффекты шрифта с помощью validModesForFontPanel. Однако, они фактически еще не реализованы:
NSFontPanelUnderlineEffectModeMask      = 1<<8,
NSFontPanelStrikethroughEffectModeMask = 1<<9,
NSFontPanelTextColorEffectModeMask = 1<<10,
NSFontPanelDocumentColorEffectModeMask = 1<<11,
NSFontPanelShadowEffectModeMask = 1<<12,
NSFontPanelAllEffectsModeMask = 0XFFF00

Изменения Цвета Эффектов шрифта (Раздел добавил начиная с WWDC),

У Пантеры часть эффектов шрифта панели шрифта использовала частный механизм для обработки цветных изменений (основной цвет, цвет подчеркивания, перечеркнутый цвет и цвет фона документа). У Тигра это использует стандарт changeAttributes:/convertAttributes: механизм для основного цвета, цвета подчеркивания, и перечеркнутого цвета и стандарта changeDocumentBackgroundColor: метод для цвета фона документа. Это упрощает для пользовательских представлений реагировать на эти цветные изменения. Предыдущий частный механизм будет все еще поддерживаться для тех представлений, которые, возможно, реализовали его на основе реализации Пантеры, но changeAttributes:/convertAttributes: рекомендуется для будущего использования.


Экранные Изменения Шрифта NSLayoutManager (Раздел добавил начиная с WWDC),

У Пантеры менеджер по расположению не использовал бы экранные шрифты, если бы какое-либо текстовое представление, связанное с нею, масштабировалось или поворачивалось, независимо от установки usesScreenFonts. В Тайгере менеджер по расположению будет использовать экранные шрифты, если usesScreenFonts будет установлен, независимо от состояния текстовых представлений, связанных с ним. Предыдущее поведение остается в силе для приложений, соединенных на Пантере или предыдущих. Приложения, соединенные на Тайгере или вне, должны будут вручную вызвать setUsesScreenFonts: на их менеджерах по расположению, если они хотят, чтобы изменилось использование экранных шрифтов.


Генератор глифа NSLayoutManager

NSLayoutManager теперь имеет методы для того, чтобы непосредственно установить и получить его генератор глифа:
- (NSGlyphGenerator *)glyphGenerator;
- (void)setGlyphGenerator:(NSGlyphGenerator *)glyphGenerator;

Параметр Языка NSSpellChecker (Раздел добавил начиная с WWDC),

Документация утвердила что параметр языка
- (NSRange)checkSpellingOfString:(NSString *)stringToCheck startingAt:(int)startingOffset
language:(NSString *)language wrap:(BOOL)wrapFlag inSpellDocumentWithTag:(int)tag wordCount:(int *)wordCount;
должна быть пустая строка, чтобы указать, что должна использоваться в настоящее время выбираемая программа проверки правописания пользователя. Фактически, ноль должен использоваться вместо этого; использование пустой строки дало бы противоречивые результаты на версиях системы предтигра. Для Тигра пустая строка будет обработана как ноль, но все еще предпочтен ноль. То же содержит для похожих методов
- (int)countWordsInString:(NSString *)stringToCount language:(NSString *)language;
- (NSArray *)completionsForPartialWordRange:(NSRange)range inString:(NSString *)string
language:(NSString *)language inSpellDocumentWithTag:(int)tag;

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

- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)atomicFlag updateFilenames:(BOOL)updateFilenamesFlag;
Этот метод был изменен, чтобы быть более эффективным при перезаписи существующих каталогов. Изменение в поведении - то, что оно пытается избежать создавать новые копии любых не изменившихся файлов.


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

Когда панель инструментов находится в метке только режим, NSToolbarItem menuFormRepresentation теперь только проверен. Это - победа производительности, так как эти menuFormRepresentations только используются, когда панель инструментов находится в метке только режим.

Ошибка была обнаружена у Пантеры, влиявшей на расположение гибко размерных элементов «представления» когда в режиме «Icon & Text». В этом случае часть представления элемента панели инструментов была намного меньше, чем пространство, которое было доступно ей. В сущности эти элементы были похожи, что у них было слишком много вакуума на правой и левой стороне. Они выглядели намного более далекими от смежных элементов, чем желаемый (помимо факта, что часть представления была меньшей, чем это должно быть). У Пантеры часть представления никогда не должна иметь избыточного интервала справа и оставленный, если степень элемента панели инструментов и его метки не больше, чем максимальный указанный размер представления элемента.

NSToolbar теперь указывает состояние выбора элементов, даже если они находятся в меню переполнения. До Тигра элементы в меню переполнения не указывали состояние выбора. Выбранные пункты обозначены с помощью галочки стандартного меню.

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

Для понимания, почему старое поведение является проблемой вообразите следующее: у Вас есть предназначенный нолем элемент «сохранения», действие которого является saveContentsOfWindow:. Существует 2 окна "A" и "B", открыты с A, являющимся ключевым окном. Каждое окно реализует saveContentsOfWindow:. До Тигра проверка окна B «сохраняет» элемент, всегда проходил бы через код доступа A. Далее, если Вы cmd-нажатый по B's «сохраняете» элемент (т.е. выполните щелчок, не изменяя ключевое окно), действие было бы выполнено A.

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

menuFormRepresentation NSToolbarItem, который является подменю, можно было теперь связать цель/действие с элементом верхнего уровня. Такие элементы ведут себя как выпадающее меню, высокоуровневый элемент которого активируем по щелчку как кнопка. Если пользовательские мыши перед выпадающим показаны, действие элемента верхнего уровня отправляется. Если пользователь перемещает мышь, выпадающее меню показано после малой задержки, или. Параметром 'отправителя' методов действия будет пункт меню верхнего уровня. Это новое поведение включено для приложений, соединенных на Тайгере и позже..

Поведение изменения размеров элементов NSToolbarFlexibleSpaceItemIdentifier изменилось немного. Цель гибкой распорной детали является двукратной. Сначала это используется пользователями, хотящими выровнять по правому краю определенные элементы. Во-вторых, это - использование для создания визуального разделения. Гибкие элементы распорной детали раньше совместно использовали равную сумму свободного места с другими элементами изменяемого размера. К сожалению, это крадет ценное пространство из элементов с фактическим содержанием. Для обращения этого гибкие распорные детали больше не изменяют размеры с равным взвешиванием.

Расположение NSTOOLBAR элементов изменяемого размера было улучшено. Для приложений, соединенных на Пантере или ранее, существует ошибка в расположении элементов изменяемого размера в режиме метки и значке. Часто элементы, которые должны были быть тем же размером, отличались в размере. В частности если два элемента имеют тот же minSize, когда они оба более широки, чем их метка, еще меньше тогда свой maxSize, они должны быть тем же размером. Эта ошибка была исправлена для приложений, соединенных на или после Тайгера.

До Тайгера, изменяя метку элемента изменяемого размера мог иногда заставлять элемент изменять размеры на экране, когда было ненужным изменить размеры. Эта ошибка была исправлена для приложений, соединенных на или после Тайгера.

До Тайгера, изменяя метку элемента изменяемого размера мог иногда заставлять элемент изменять размеры на экране, когда было ненужным изменить размеры. Эта ошибка была исправлена для приложений, соединенных на или после Тайгера.

Изменения макета - поля NSTOOLBAR изменились немного.

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

Поля в металлических окнах: расположение имеет те же изменения, которые окна воды имеют плюс небольшое вертикальное граничное изменение. Металлические окна теперь вертикально короче с полями, теперь соответствующими Safari и Средство поиска. В результате металлические окна с панелями инструментов будут несколькими пикселями короче для того же размера содержания.

Рисование базового разделителя: Для приложений, хотящих, чтобы их панель инструментов больше походила на Средство поиска и Safari, NSToolbar позволяет Вам скрывать базовую линию, которую это рисует между собой и содержанием главного окна. Разработчики могут также использовать этот API для сокрытия основной линии так, чтобы они могли нарисовать свой собственное выглядящий разделитель. Для превращения базового получения включения - выключения вызовите следующие методы перед присоединением панели инструментов на ее окно:
- (void)setShowsBaselineSeparator:(BOOL)flag;
- (BOOL)showsBaselineSeparator;

NSToolbarItem

Автопроверка

NSToolbar полагается на обновление окна для управления его механизмом автопроверки для включения NSToolbarItems. К сожалению, обновление окна может не произойти в точный момент, разработчик должен обновить их UI. Кроме того, обновление окна происходит очень часто и может вызвать проблемы производительности для блоков проверки допустимости, которые должны выполнить большую работу. Поэтому мы теперь обеспечиваем способ выключить автоматическую проверку по умолчанию на основе на элемент.
/* By default NSToolbar automatically invokes its items validate method on a regular basis.
To be in complete control of when the -validate method is invoked, you can disable automatic validation
on a per-item basis. In particular, if your validation code is slow, you may want to do this for performance reasons.
*/
- (void)setAutovalidates:(BOOL)autovalidates;
- (BOOL)autovalidates;
Предотвращение переполнения

Некоторые приложения хотели бы предположить что определенные элементы панели инструментов всегда быть видимыми, никогда не попадая в меню переполнения. Например, в Safari, поле URL очень важно, и должно обычно всегда быть видимо (а не в меню переполнения). Пользователи могут счесть очень полезным определить этот вид вещи также. Например, В XCode, я мог бы хотеть предположить, что «сборка разрабатывает» раскрывающийся всегда быть видимой. Для выполнения этого мы добавили следующий API.
enum {
// The default visibility priority value. By default, all items have this priority
NSToolbarItemVisibilityPriorityStandard = 0,
    // A good value to use for items which should be first to fall into the overflow menu
NSToolbarItemVisibilityPriorityLow = -1000,
    // A good value to use for items you want to stay visible, allowing users to still have highest priority
NSToolbarItemVisibilityPriorityHigh = 1000,
    // Value assigned to an item the user wants to "keep visible". You should only use values less than this
NSToolbarItemVisibilityPriorityUser = 2000
};
/* When a toolbar does not have enough space to fit all its items, it must push some into the overflow menu.
Items with the highest visibility priority level are chosen last for the overflow menu. The default
visibilityPriority value is NSToolbarItemVisibilityPriorityStandard. To suggest that an item always
remain visible, give it a value greater than NSToolbarItemVisibilityPriorityStandard, but less than
NSToolbarItemVisibilityPriorityUser. In configurable toolbars, users can control the setting of any item,
and the value is rememeber by NSToolbar along with its other autosaved information. You should allow
user setting to have the highest priority.
*/
- (void)setVisibilityPriority:(int)visibilityPriority;
- (int)visibilityPriority;
Предостережение: панель инструментов никогда не предназначается, чтобы быть единственным способом сделать определенную функцию. Этот API не должен использоваться в качестве опоры. Фактически, так как пользователи могут переопределить Ваше предложение того, что должно быть видимо, Вам все еще никогда не гарантируют это, элемент всегда будет видим.


NSStatusItem

Можно теперь получить и установить отдельное действие двойного щелчка с NSStatusItem. Это действие вызывают для любого даже с clickCount больших, чем 1.
- (SEL)doubleAction;
- (void)setDoubleAction:(SEL)aSelector;

NSMenu

Новый метод был добавлен к NSMenu, возвращающему высоту строки меню для главного меню. Этот метод заменяет + [NSMenuView menuBarHeight]. Если меню является текущим главным меню приложения и 0 иначе, метод возвращает высоту строки меню.
- (float)menuBarHeight;

Меню прикрепления

У Тигра мы добавили поддержку альтернативных пунктов меню в меню прикрепления. Если делегат меню установлен, мы также добавили поддержку для вызова методов делегата NSMenu.


NSSegmentedCell/NSSegmentedControl

Новый метод был добавлен к NSSegmentedCell и NSSegmentedControl, выбирающему ячейку, данную тег. Это будет искать элемент с тегом и затем вызывать - [NSSegmentedCell setSelectedSegment]. Функция возвратит YES, если сегмент будет найден, даже если ячейка не можно выбрать, потому что это отключено. Метод управления вызывает метод ячейки.
- (BOOL)selectSegmentWithTag:(int)tag;

NSPopUpButtonCell/NSPopUpButton

Новый метод был добавлен к NSPopUpButtonCell и NSPopUpButton, выбирающему элемент, данный тег. Это будет искать элемент с тегом и затем вызывать - [NSPopUpButtonCell selectItemAtIndex]. Если элемент будет найден, метод возвратит YES. Если элемент не найден, функция возвращается НЕ и ничего не делает. Метод управления вызывает метод ячейки.
- (BOOL)selectItemWithTag:(int)tag;

NSFormCell

Строковые методы заполнителя в NSTextFieldCell также доступны в NSFormCell.
- (void)setPlaceholderString:(NSString *)string;
- (NSString *)placeholderString;
- (void)setPlaceholderAttributedString:(NSAttributedString *)string;
- (NSAttributedString *)placeholderAttributedString;

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

Можно теперь выбрать цвет фона безграничной кнопки. Это не влияет на цвет ограниченных кнопок, таких как кнопки.
- (void)setBackgroundColor:(NSColor *)color;
- (NSColor *)backgroundColor;
Получение фона кнопки, изображения и текста вспыхнулось в 3 отдельных открытых метода, дающие подклассу точку переопределения.
- (void)drawImage:(NSImage *)image withFrame:(NSRect)frame inView:(NSView *)controlView;
- (NSRect)drawTitle:(NSAttributedString *)title withFrame:(NSRect)frame inView:(NSView *)controlView;
- (void)drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView;
Если кнопка имеет надлежащую установку, эти методы вызывают.-drawBezelWithFrame:inView: если кнопка ограничена, вызывается.-drawImage:withFrame:inView: и-drawTitle:withFrame:inView: если кнопка будет иметь изображение и заголовок соответственно, будет вызван.-drawTitle:withFrame:inView: возвратится фактический прямоугольник раньше представлял текст (обычно центрируемый в кадре, переданном в.)

Существует несколько новых доступных стилей внешней панели:
    NSSmallSquareBezelStyle = 10
NSTexturedRoundedBezelStyle = 11
Первой является внешняя панель простого квадрата, появляющаяся в предпочтительной области учетных записей в Установках системы ('+' и '-' кнопки). NSTexturedRoundedBezelStyle используется для создания кнопки, подобной действию Средства поиска (имущество) кнопка. Это подобно по внешности сегментированному управлению единственного элемента.

У обоих есть регулярные, нажатые, и отключенные появления. Установка controlSize не применяется. NSSmallSquareBezelStyle может масштабироваться к любому размеру, и NSTexturedRoundedBezelStyle имеет только единственный размер и фиксированную высоту.
    NSRoundRectBezelStyle = 12
Это - кнопка с полукруглыми заглушками. Это имеет серую штриховку от света до темноты. Это имеет регулярные, нажатые, и отключенные появления. Необходимо установить шрифт, чтобы быть точкой Lucida Grande 12.
    NSRecessedBezelStyle = 13
Это - кнопка с полукруглыми заглушками. Это, кажется, имеет расположенное появление. Это имеет регулярные, нажатые, выбранные, и отключенные появления. Необходимо установить шрифт, чтобы быть точкой Lucida Grande 12. Эта кнопка работает при установке-setShowsBorderOnlyWhileMouseInside в YES.
    NSRoundedDisclosureBezelStyle = 14
Эта кнопка является квадратной кнопкой, совпадающей с кнопкой раскрытия в панели сохранения. Это имеет регулярные и выбранные состояния. Это не должно иметь текста или набора изображения.


NSSearchFieldCell

Флаг доступен, который заставит действие ячейки поля поиска быть отправленным незамедлительно вместо того, чтобы собрать в группу изменения до пользовательского ввода пауз.
- (BOOL)sendsSearchStringImmediately;
- (void)setSendsSearchStringImmediately:(BOOL)flag;

NSCell

Метод-setControlView: теперь доступно в NSCell и его подклассах. Реализация в NSCell ничего не делает. Реализация в NSActionCell сохраняет представление.

Можно теперь установить ячейку (обычно NSTextFieldCell), чтобы позволить или запретить отмену. По умолчанию поле установлено позволить отмену. Когда ячейка начинает редактировать, стек отмены очищен.
- (void)setAllowsUndo:(BOOL)allowsUndo;
- (BOOL)allowsUndo;
Можно установить режим разрыва строки ячейки для текстового получения. Это позволит усечение текста в ячейке, не будучи должен разделить на подклассы. Вызов - [NSCell setWraps:] установит режим в NSLineBreakByWordWrapping и NSLineBreakByClipping для YES и НЕ соответственно. если режимом будет NSLineBreakByWordWrapping или NSLineBreakByCharWrapping,-setWraps возвратит YES.
- (void)setLineBreakMode:(NSLineBreakMode)mode
- (NSLineBreakMode)lineBreakMode

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

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


NSComboBox

Вызов - [NSComboBox setUsesDataSource:] теперь всегда устанавливает indexOfSelectedItem в-1. До Тигра это не делало этого для setUsesDataSource:NO.

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

Всплывающее меню NSComboBox теперь только показывает полосу прокрутки, если это необходимо.

Расположение всплывающего окна NSComboBox изменилось немного. Если раскрывающееся не может соответствовать ниже текстового поля, NSComboBox теперь помещает поле комбинированного списка выше текстового поля, только если существует больше пространства выше поля комбинированного списка, чем существует ниже. В прошлом NSComboBox не обращал внимание, к которому сторона имела больше пространства. Далее, если нет достаточного количества комнаты с обеих сторон, NSComboBox теперь уменьшает окно для адаптации на экране.

NSComboBox исправил ошибку в-indexOfSelectedItems, заставившем индекс быть неправильным, когда используется от действия NSComboBox в определенных ситуациях.

NSComboBoxCell может теперь использоваться в NSMatrix. Для функционирования должным образом матрица должна использовать NSTrackModeMatrix для - режим.


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

Вызов setTitle:ofColumn: во время создания столбца теперь работает. До Тигра, вызывая его не было возможно установить заголовок столбца, создаваемого с помощью этого API от любого из методов «создания» делегата:-browser:numberOfRowsInColumn: или-browser:createRowsForColumn:inMatrix:.

titleFrame передал в drawTitleOfColumn:inRect: теперь на 2 пикселя больше на каждой стороне. В прошлом NSBrowser раньше вставлял значение, возвращенное titleFrameOfColumn: прежде, чем вызвать drawTitleOfColumn:inRect:. Это было неправильным поступком, и также привело к определенным подстрочным элементам (как «g» и «j») отсекаемый в нижней части. Обратите внимание на то, что базовая линия текста не переместится. Новое поведение применяется, если Вы не используете подкласс NSBrowser, соединенного перед Тайгером. Для приложений, соединенных на или после Тайгера, NSBrowserCell теперь значения по умолчанию к использованию NSLineBreakByTruncatingTail для его режима разрыва строки. Набор - [NSCell setLineBreakMode:] для получения дополнительной информации о режимах разрыва строки.


NSMatrix

Когда dirtying содержание ячеек, NSMatrix теперь обращает внимание на ячейки-focusRingType. В прошлом NSMatrix всегда принимал-focusRingType NSFocusRingTypeExterior, заставляя его использовать [сам setKeyboardFocusRingNeedsDisplayInRect:cellFrame] всегда, вместо только для ячеек та поддержка фокусирующие кольца.

NSComboBoxCell может теперь использоваться в NSMatrix. Для функционирования должным образом матрица должна использовать NSTrackModeMatrix для - режим.


NSOutlineView

- (BOOL) isItemExpanded: (ID) элемент; теперь возвраты НЕ, если не найден 'элемент'.

NSOutlineView теперь возвращает допустимые результаты rowForItem: и levelForItem: когда вызвано с дочерними элементами элемента в прогрессе расширения. В то время как определенный дочерний элемент загружается, эти методы возвратят допустимые результаты. Ранее они возвратились-1, в то время как элемент был в процессе того, чтобы быть загруженным родителем (например, во время элемента, расширяются). Нет никакой причины, этот определенный тип информации не должен быть допустимым в течение времени загрузки, таким образом, это теперь доступно.

Загрузка данных NSOutlineView намного более ленива теперь. Данные теперь запрашиваются от источника данных по требованию. В целом источник данных не будет запрошен для данных элементов, если тот элемент не будет видим, или API вызывается, который требует, чтобы присутствовали те данные.

Следующие методы, обозначенные, как осуждается прежде 10.0, были удалены: - (недействительный) setAutoResizesOutlineColumn: (BOOL) изменяют размеры; и - (BOOL) autoResizesOutlineColumn; Если Вы используете эти методы, переключаетесь на использование: - (недействительный) setAutoresizesOutlineColumn: (BOOL) изменяют размеры; и - (BOOL) autoresizesOutlineColumn;

Столбец схемы NSOutlineView теперь уважает minWidth, указанный в IB. В прошлом NSOutlineView вынудил minWidth к значение, достаточно большое всегда показать ячейки расширения, даже если это было меньше, чем minWidth, который Вы указали. Это изменение вступает в силу для приложений, соединенных на или после Тайгера.

Перетаскивание

Поскольку приложения основывались на Тайгере или позже, NSOutlineView теперь позволяет перетаскиванию строки начинаться с щелчка в любом столбце. Ранее, вытаскивание было ограничено столбцом схемы. Приложения основывались на Тайгере и позже, могут сохранить старое поведение путем простого переопределения - (BOOL) canDragRowsWithIndexes: (NSIndexSet *) rowIndexes atPoint: (NSPoint) назначают; возвратить YES только, когда 'aPoint' находится в столбце схемы.

Для большего количества изменений перетаскивания см. информацию о версии NSTableView.

ToolTips

По многим причинам трудно добавить подсказки уровня ячеек к NSOutlineView с помощью существующего API NSView. Для решения этого мы добавляем новый API, который позволит делегату предоставить подсказку для ячейки (пересечение столбца/строки) по требованию. Обратите внимание на то, что нет никаких тегов отслеживания подсказки, связанных с этими подсказками. Для использования в своих интересах этой новой функции необходимо реализовать метод делегата:
/* When the user pauses over a cell, the value returned from this method will be displayed in a tooltip.
'point' represents the current mouse location in view coordinates. If you don't want a tooltip
at that location, return nil. On entry, 'rect' represents the proposed active
area of the tooltip. By default, rect is computed as [cell drawingRectForBounds:cellFrame].
To control the default active area, you can modify the 'rect' parameter.
*/
- (NSString *)outlineView:(NSOutlineView *)ov toolTipForCell:(NSCell *)cell rect:(NSRectPointer)rect
tableColumn:(NSTableColumn *)tc item:(id)item mouseLocation:(NSPoint)mouseLocation;

NSTableView

Misc

Для приложений, соединенных на или после Тигра, NSTableView лишает законной силы таблицу, и заголовок просматривают только, когда изменились тип телосложения или размеры столбца. В прошлом вызовы к - мозаика излишне лишили законной силы всю таблицу и представление заголовка.

Для приложений, соединенных на или после Тигра, NSTableView (и NSOutlineView) ячейка данных по умолчанию теперь значения по умолчанию к использованию NSLineBreakByTruncatingTail для его режима разрыва строки. Набор - [NSCell setLineBreakMode:] для получения дополнительной информации о режимах разрыва строки.

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

Если щелчок был в cellFrame области, двойной щелчок теперь только начинает редактировать. До Тигра, дважды щелкающий где угодно в столбце/строке rect начал редактировать. В частности это имело нечетный эффект в NSOutlineView. Таким образом, теперь, дважды щелкающий по левой стороне кнопки раскрытия схемы больше не запускает редактирование ячейки.

Проверка меню изменилась немного. deselectAll: если нет никакого выбора в таблице, теперь отключен. selectAll: если таблица запрещает множественные выборы, теперь отключен.

Изменение табличного цвета фона и цвета сетки теперь вызывает восстанавливание изображение в случае необходимости.

NSTableView теперь намного более агрессивен о проверке dataCell, и controlView ivar headerCell установлен. Например, у Пантеры и более ранних систем, вызывая [сам controlView] обычно возвращал бы ноль для ячейки в таблице. Для приложений, соединенных на или после Тайгера, это и другие связанные проблемы были фиксированы. В целом NSTableView пытается удостовериться, вызывая-controlView, возвратит ссылку на себя для ячеек, которые он использует.

Для приложений, соединенных на или после того, как, Тайгер, удаляя столбец из NSTableView теперь приводит к tableView ссылке столбца, которая будет установлена в ноль.

Атрибуты ячеек данных столбца таблицы по умолчанию изменились. В его-init методе NSTableColumn теперь создает ячейку данных NSTextFieldCell по умолчанию со следующими измененными атрибутами: setDrawsBackground=YES; font=systemFont с размером systemFontSize (Lucida Grande, 13). До Тигра NSTableColumn раньше устанавливал свойства по умолчанию в setDrawsBackground=NO и шрифт = (Lucida Grande, 12). Различие раньше представляло много проблем. Например, если бы Вы добавили столбцы к своей таблице в коде, то у них были бы различные размеры шрифта, чем те от заархивированного пера. Далее, если бы Вы приняли решение вывести на экран популярные альтернативные цвета строк, то те ячейки данных, setDrawsBackground которых был YES, затенили бы синий на любой строке. Наконец, в большинстве таблиц является ненужным для ячеек нарисовать фон, потому что таблица уже рисует фон. Новые атрибуты только установлены для приложений, соединенных на Тайгере и позже, и только в init методе NSTableColumn. Так, при архивации перьев с неправильным размером шрифта необходимо фиксировать их вручную в IB или в коде.

Кроме того, в IB было возможно создать новые столбцы, имевшие различные свойства, чем столбцы по умолчанию, которые Вы получаете при перетаскивании таблицы от палитры.

Осуждаемый API

Везде, где возможно, NSTableView теперь использует NSIndexSet в своем APIs. Следующие методы были осуждены:
- (NSImage *)dragImageForRows:(NSArray *)dragRows event:(NSEvent *)dragEvent dragImageOffset:(NSPointPointer)dragImageOffset;
- (BOOL)tableView:(NSTableView *)tv writeRows:(NSArray *)rows toPasteboard:(NSPasteboard *)pboard;
... и замененный NSIndexSet базировал версии:
- (NSImage *)dragImageForRowsWithIndexes:(NSIndexSet *)dragRows tableColumns:(NSArray *)tableColumns
event:(NSEvent *)dragEvent offset:(NSPointPointer)dragImageOffset;
- (BOOL)tableView:(NSTableView *)tv writeRowsWithIndexes:(NSIndexSet *)rowIndexes toPasteboard:(NSPasteboard *)pboard;
Доступность фиксирует

При выборе строки таблицы с помощью доступности APIs теперь должным образом консультируется с shouldSelectRow NSTableView: делегат API.

NSTableView теперь устанавливает больше состояния NSCell прежде, чем вызвать accessibilityPerformAction: когда действием является NSAccessibilityPressAction. В частности ячейки controlView установлены в таблицу, и clickedRow и clickedColumn таблицы отражают строку и столбец ячейки, получающей NSAccessibilityPressAction. Наконец, selectedCell таблицы возвратит ячейку, обрабатывающую NSAccessibilityPressAction. Идея состоит в том, что NSAccessibilityPressAction должен быть в состоянии быть обработанным то же, как будто пользователь щелкнул по ячейке с мышью.

Перетаскивание (Раздел, обновленный начиная с WWDC)

NSTableView добавил API, позволяющий Вам управлять, где могут начаться операции перетаскивания строки. По умолчанию NSTableView позволяет, перетаскивает для начала где угодно за немногим исключением: Щелкает, кнопки, кнопки всплывающего меню, ползунки и другие подобные средства управления отследят мышь вместо того, чтобы начаться, строка перетаскивают. Для настройки этого поведения переопределите следующий метод:
/* The return value indicates whether the table can attempt to initiate a row drag at 'mouseDownPoint'.
Return NO to disallow initiating a row drag at the given location.
*/
- (BOOL)canDragRowsWithIndexes:(NSIndexSet *)rowIndexes atPoint:(NSPoint)mouseDownPoint;
NSTable/OutlineViews, которые являются местами назначения перетаскивания теперь, подтверждают, перетаскивает (validateDrop: API), если изменяются модифицирующие клавиши.

Можно теперь настроить NSTableView (и NSOutlineView) реализация-draggingSourceOperationMaskForLocal без разделения на подклассы. NSTableView реализует исходный метод перетаскивания-draggingSourceOperationMaskForLocal: для Вас. По умолчанию это запрещает перетаскивание местам назначения вне его приложения при разрешении любого типа перетаскивания в его приложении. Существует две опции для настройки этого поведения. Когда решения должны быть динамичными, разработчики могут всегда разделять на подклассы и переопределять этот метод. Однако У Тигра, мы добавили более простой способ настроить поведение. Просто используйте следующий новый метод:
/* Configures the default value returned from -draggingSourceOperationMaskForLocal:.
An isLocal value of YES indicates that 'mask' applies when the destination object is in the same application.
An isLocal value of NO indicates that 'mask' applies when the destination object in an application outside
the receiver's application. NSTableView will archive the values you set.
*/
- (void)setDraggingSourceOperationMask:(unsigned int)mask forLocal:(BOOL)isLocal;
Перетаскивание - файл перетаскивание Promise

NSTableView поддерживает обещанный файл, перетаскивает через новый тип области монтажа NSFilesPromisePboardType. К файлу поддержки обещание перетаскивает, клиенты просто добавляют этот тип к области монтажа в tableView:writeRowsWithIndexes:toPasteboard:. Когда место назначения признает, что обещание перетаскивает, оно просит, чтобы NSTableView предоставил файлы через-namesOfPromisedFilesDroppedAtDestination:. NSTableView передает ответственность фактического создания файла к источнику данных, указавшему, что обещание перетаскивает. Это будет отправлено следующий новый метод источника данных:
/* Returns an array of filenames for the created files (filenames only, not full paths).  The URL represents
the drop location. For more information on file promise dragging, see documentation on the
NSDraggingSource protocol and -namesOfPromisedFilesDroppedAtDestination:.
*/
- (NSArray *)tableView:(NSTableView *)tableView namesOfPromisedFilesDroppedAtDestination:(NSURL *)dropDestination
forDraggedRowsWithIndexes:(NSIndexSet *)indexSet;
NSOutlineView имеет свою собственную версию:
- (NSArray *)outlineView:(NSOutlineView *)outlineView
namesOfPromisedFilesDroppedAtDestination:(NSURL *)dropDestination
forDraggedItems:(NSArray *)items;
ToolTips

По многим причинам трудно добавить подсказки уровня ячеек к NSOutlineView с помощью существующего API NSView. Для решения этого мы добавляем новый API, который позволит делегату предоставить подсказку для ячейки (пересечение столбца/строки) по требованию. Обратите внимание на то, что нет никаких тегов отслеживания подсказки, связанных с этими подсказками. Для использования в своих интересах этой новой функции необходимо реализовать метод делегата:
/* When the user pauses over a cell, the value returned from this method will be displayed in a tooltip.
'point' represents the current mouse location in view coordinates. If you don't want a tooltip at that location, return nil.
On entry, 'rect' represents the proposed active area of the tooltip. By default, rect is computed as
[cell drawingRectForBounds:cellFrame]. To control the default active area, you can modify the 'rect' parameter.
*/
- (NSString *)tableView:(NSTableView *)tv toolTipForCell:(NSCell *)cell rect:(NSRectPointer)rect
tableColumn:(NSTableColumn *)tc row:(int)row mouseLocation:(NSPoint)mouseLocation;

Переменные высоты строки

До сих пор каждая строка в табличном представлении была обязана быть той же высотой как любая строка. Это подходяще для подавляющего большинства использования табличного представления. Однако в некоторых случаях это ограничивает. Иногда это может быть выгодно для указания высоты строки на основе данных, которые должна вывести на экран строка. У Тигра мы позволим строкам табличного представления быть указанными на строку при необходимости со следующим API:
/* If the delegate implements -tableView:heightOfRow:, this method immediately re-tiles the table view using row heights it provides.
*/
- (void)noteHeightOfRowsWithIndexesChanged:(NSIndexSet *)indexSet;

@interface NSObject (NSTableViewDelegate)
/* Optional - Variable Row Heights
Implement this method to support a table with varying row heights. The height returned by this method should not include
intercell spacing and must be >0. Performance Considerations: For large tables in particular, you should make sure that this
method is efficient. NSTableView may cache the values this method returns. So if you would like to change a row's height make
sure to invalidate the row height by calling -noteHeightOfRowsWithIndexesChanged:. NSTableView automatically invalidates its
entire row height cache in -reloadData, and -noteNumberOfRowsChanged.
*/
- (float)tableView:(NSTableView *)tableView heightOfRow:(int)row;
@end
@interface NSObject (NSOutlineViewDelegate)
/* Optional - Variable Row Heights
Implement this method to support an outline view with varying row heights. The height returned by this method should not include
intercell spacing and must be >0. Performance Considerations: For large tables in particular, you should make sure that this
method is efficient. NSTableView may cache the values this method returns. So if you would like to change a row's height make
sure to invalidate the row height by calling -noteHeightOfRowsWithIndexesChanged:. NSTableView automatically invalidates its
entire row height cache in -reloadData, and -noteNumberOfRowsChanged.
*/
- (float)outlineView:(NSOutlineView *)outlineView heightOfRowByItem:(id)item;
@end
Некоторые примечания о переменном табличном представлении высоты строки:
- lineScroll представления прокрутки таблицы управляет-rowHeight.
- Высотой строк «заполнителя» управляет-rowHeight. Т.е. расстояние между линиями сетки и альтернативные цвета строк мимо последней строки таблицы.


Изменение размеров Столбца таблицы - Лучший алгоритм / Новый APIs

NSTableView в настоящее время поддерживает режимы автоизменения размеров двух столбцов: «измените размеры, все» и «изменяют размеры в последний раз».

Мы изменяемся, поведение тока «изменяют размеры всего» режима. Его поведение упрощенно и не полезно. В настоящее время, поскольку таблица изменяет размеры, она устанавливает ширину каждого столбца изменяемого размера к (availableWidth / numResizableColumns), contraining к каждой минуте и максимальный, Этот алгоритм распределения не принимает во внимание текущие относительные размеры каждого столбца. Это поведение будет заменено алгоритмом, унифицированно распределяющим пространство при принятии во внимание начальных значений. Ток «изменяет размеры в последний раз», изменяет размеры последнего столбца изменяемого размера, пока это не достигает своей минуты или макс. ширины. Это поведение будет сохранено.

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

Примечание: «автоизменение размеров» относится к изменению размеров столбца в ответ на изменение кадра. Думайте живые, изменяют размеры. «Пользователь, изменяющий размеры», обращается к изменению размеров путем перетаскивания от правого края заголовка столбца.

Также примечание,-sizeToFit NSTableView и-sizeLastColumnToFit поведение были фиксированы как часть этой работы для использования новых стилей и алгоритмов. Во время живой работы изменения размеров эти методы используют определенный стиль изменения размеров, который Вы выбрали через-setColumnAutoresizingStyle:. Когда вызвано вне живого изменяют размеры работы,-sizeToFit изменяет размеры столбцов для адаптации видимому использованию ширины NSTableViewUniformColumnAutoresizingStyle, в то время как-sizeLastColumnToFit изменяет размеры использования столбцов NSTableViewLastColumnOnlyAutoresizingStyle.
/* The column auto resizing style controls resizing in response to a table view frame change.
Compatability Note: This method replaces -setAutoresizesAllColumnsToFit:.
*/
typedef enum {
// Turn of column autoresizing
NSTableViewNoColumnAutoresizing = 0,
    // Autoresize all columns by distributing equal shares of space simultaeously
NSTableViewUniformColumnAutoresizingStyle,
    // Autoresize each table column one at a time.
// Proceed to the next column when the current column can no longer be autoresized (when it reaches maximum/minimum size).
NSTableViewSequentialColumnAutoresizingStyle, // Start with the last autoresizable column, proceed to the first.
NSTableViewReverseSequentialColumnAutoresizingStyle, // Start with the first autoresizable column, proceed to the last.
    // Autoresize only one table column one at a time.
// When that table column can no longer be resized, stop autoresizing.
// Normally you should use one of the Sequential autoresizing modes instead.
NSTableViewLastColumnOnlyAutoresizingStyle,
NSTableViewFirstColumnOnlyAutoresizingStyle
} NSTableViewColumnAutoresizingStyle;
- (void)setColumnAutoresizingStyle:(NSTableViewColumnAutoresizingStyle)style;
- (NSTableViewColumnAutoresizingStyle)columnAutoresizingStyle;

/* Deprecated in Mac OS 10.4.  You should use setColumnAutoresizingStyle: instead.
To preserve compatibility, if flag is YES, This method calls setColumnAutoresizingStyle:NSTableViewUniformColumnAutoresizingStyle.
If flag is NO, this method calls setColumnAutoresizingStyle:NSTableViewLastColumnOnlyAutoresizingStyle.
*/
- (void)setAutoresizesAllColumnsToFit:(BOOL)flag;
- (BOOL)autoresizesAllColumnsToFit;

Характеристики изменения размеров NSTableColumn теперь обеспечивают более прекрасные средства управления. Мы добавили API, позволяющий Вам объявлять, что пользователь может изменить размеры столбца, но что он не должен изменять размеры во время живого, изменяют размеры (автоизменение размеров).
/* The resizing mask controls the resizability of a table column.  Compatability Note: This method replaces setResizable.
*/
- (void)setResizingMask:(unsigned)resizingMask;
- (unsigned)resizingMask;
enum {
NSTableColumnNoResizing = 0, // Disallow any kind of resizing.
NSTableColumnAutoresizingMask = ( 1 << 0 ), // This column can be resized as the table is resized.
NSTableColumnUserResizingMask = ( 1 << 1 ), // The user can resize this column manually.
};
/* Deprecated in Mac OS 10.4.  If flag is YES, calls
setResizingMask:(NSTableColumnUserResizingMask | NSTableColumnAutoresizingMask).
If flag is NO, calls setResizingMask:(NSTableColumnNoResizing).
*/
- (void)setResizable:(BOOL)flag;
- (BOOL)isResizable;


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

Имена всей привязки и опций, используемых в AppKit, теперь объявляются через явные константы в NSKeyValueBinding.h.

Отладить проблемы с кодированием значения ключа и наблюдением значения ключа имело отношение к привязке, можно теперь установить пользовательское значение по умолчанию NSBindingDebugLogLevel для получения более полезных журналов о проблемах (вместо неопределенных ключевых исключений, например). Когда Вы пытаетесь найти неправильно сконфигурированную привязку в большом файле пера со многой привязкой, это может быть полезно. Установите значение по умолчанию в 1 для включения журналирования, и в 0 для выключения его.

Новый метод для возврата информации о текущей привязке объекта был добавлен к NSObject:
- (NSDictionary *)infoForBinding:(NSString *)binding;
Это возвращает словарь с информацией о существующей привязке или ноле, если это не связывается. Дополнительную информацию см. в NSKeyValueBinding.h.

Несколько новой привязки доступны:
- NSTextView теперь имеет attributedString, связывающий (доступный, если многократные шрифты позволяются или не).
- NSView и подклассы теперь имеют привязку подсказки.
- NSWindow теперь имеет displayPatternTitle привязку для указания заголовка окна через строку образца с многократными значениями (и работа тот же путь как displayPatternValue привязка на текстовых полях).
- NSBox теперь имеет заголовок и displayPatternTitle привязку (что работа как привязка на NSWindow).
- NSSearchField теперь имеет привязку предиката (и, если связано представляет дополнительный predicate2, predicate3, и т.д. привязка) - Вы указываете имя дисплея и prediate строку формата через опции привязки и обычно связываете их с filterPreciate контроллера массива.
- NSTableView теперь имеет doubleClickArgument/doubleClickTarget привязку, работающую тот же путь привязкой параметра/цели кнопок - привязка используется для инициирования вызова метода при двойном щелчке в табличном представлении.
- Виджеты выбора (NSPopUpButton/NSPopUpButtonCell и NSMatrix) теперь предлагают contentObjects, связывающий в дополнение к содержанию, и contentValues привязка (привязка contentObjects становится доступной, только если содержание связывается). Это позволяет Вам связывать содержание виджета к массиву (привязка содержания), выведенные на экран значения к зависимому массиву (contentValues связывающий - который должен использовать ключевой путь, который является расширением того привязки содержания), и «представленные» объекты, которые будут обработаны посредством selectedObject/selectedObjects привязки к другому массиву depdendent (contentObjects - который также должен использовать ключевой путь, который является расширением того привязки содержания). Например, если у Вас есть массив со словарями (который может быть связан с контроллером через «selection.dictionaries» ключ), который у каждого есть значения для ключа «displayName» и ключа «representedObject», можно связать содержание кнопки всплывающего меню к «selection.dictionaries», contentValues к «selection.dictionaries.displayName» и contentObjects к «selection.dictionaries.representedObject» - selectedObject будет тогда воздействовать на значения «representedObject», в то время как раскрывающиеся дисплеи «displayName» оценивают в пользовательском интерфейсе. Конечно, если Вы не используете привязку contentObjects, представленные объекты являются все еще значениями в массиве, с которым связывается содержание.

Опция для привязки значения на столбцах таблицы была добавлена:
NSCreatesSortDescriptorBindingOption
Эта опция может использоваться для подавления создания дескрипторов вида на столбце (обязательное) основание.

Опция вынудить привязку обработать ошибки с предупредительными панелями вместо листов была добавлена к varioius привязке:
NSAlwaysPresentsApplicationModalAlertsBindingOption
Множество ошибок было фиксировано, некоторые исправления вызвали небольшое изменение в поведении привязки/контроллеров:
- Для привязки с непосредственной включенной проверкой пользовательский интерфейс теперь правильно отражает значения сразу, когда принуждено в validateValue:forKey: метод.
- Привязка на столбцах таблицы с раскрывающимися ячейками данных и содержанием, contentValues и selectedObject привязка теперь генерируют дескрипторы вида для выбранных объектов на основе ключа дисплея (как определено от contentValues, связывающего).
- Если явно не указано, содержание табличного представления, selectionIndexes и sortDescriptor привязка автоматически сгенерированы, полученные из общих падежей привязки столбцов таблицы. Эта автоматическая привязка табличного представления теперь создается путем вызова общественности-bind:toObject:withKeyPath:options: на табличном представлении, так, чтобы подклассы могли прервать вызовы в случае необходимости.
- В реализации Пантеры, при удалении объектов в фоновом режиме от массива, до которого содержание NSArrayController было связано (не удаляющий через контроллер), индекс за пределы, иногда повышалось исключение. Эта ситуация была фиксирована для Тайгера.
- У Пантеры, копируя arrangedObjects массив NSArrayController скопировал элементы в массиве также. Эта ситуация была фиксирована для Тайгера, теперь объекты содержания больше не копируются.
- У Пантеры, значения набора (NSArrays и NSDictionaries) чтение от NSUserDefaultsController были возвращены как неизменные наборы, лишив возможности добавлять или удалять от них непосредственно. Обходное решение должно было использовать преобразователь значения для создания непостоянных копий наборов на чтении. Для Тигра NSUserDefaultsController теперь возвращает наборы как непостоянные экземпляры, который делает использование специального преобразователя значения устаревшим (но все еще обычно необходимо включать опцию NSHandlesContentAsCompoundValueBindingOption при привязке содержания NSArrayController или NSObjectController к значению, предоставленному через NSUserDefaultsController).
- Взаимодействуйте через интерфейс Разработчик теперь правильно вызывает-exposedBindings для заполнения инспектора Привязки.


NSEditor, ошибочное представление привязки как листы (Раздел добавил начиная с WWDC),

Так, чтобы поддержка привязки в собственных представлениях Какао могла представить ошибочные предупреждения как листы в надлежащих случаях, новый метод был добавлен к NSObject привязки значения ключа (NSEditor) категория:
- (void)commitEditingWithDelegate:(id)delegate didCommitSelector:(SEL)didCommitSelector contextInfo:(void *)contextInfo;
Учитывая, что получатель был зарегистрирован в-objectDidBeginEditing: как редактор некоторого объекта, и еще вычеркнутый из списка последующим вызовом-objectDidEndEditing: попытка фиксировать результат редактирования. Когда фиксация или успешно выполнится или перестанет работать, отправьте выбранное сообщение в указанный объект с информацией контекста как последний параметр. Метод, выбранный didCommitSelector, должен иметь ту же подпись как:
- (void)editor:(id)editor didCommit:(BOOL)didCommit contextInfo:(void *)contextInfo;
Если ошибка происходит при попытке фиксировать, потому что значение ключа, кодирующее сбои проверки, например, реализация этого метода должна обычно отправлять NSView, в котором редактирование делается-presentError:modalForWindow:delegate:didRecoverSelector:contextInfo: сообщение, указывая представление, содержащее окно.

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

Привязка и реализация по умолчанию контроллера методов NSEditor будут использовать новое находящееся в NSResponder ошибочное представление API, так, чтобы обработка ошибок могла быть настроена отдельными приложениями.

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

NSManagedObjectContext CoreData действительно реализует и NSEditor и методы NSEditorRegistration, как NSController делает.


NSObjectController

NSObjectController (и таким образом подклассы NSArrayController и NSTreeController) имеет следующий новый API для указания контекста управляемого объекта и описания для того, как выбрать объекты от него (именем объекта и предикатом выборки). Имя объекта (если указано) также определяет, как новые объекты создаются (вместо того, чтобы использовать имя класса).
- (NSManagedObjectContext *)managedObjectContext;
- (void)setManagedObjectContext:(NSManagedObjectContext *)managedObjectContext;
- (NSString *)entityName;
- (void)setEntityName:(NSString *)entityName;
- (NSPredicate *)fetchPredicate;
- (void)setFetchPredicate:(NSPredicate *)predicate;
- (void)fetch:(id)sender;

NSTreeController

Тигр представляет новый класс контроллера в Какао, NSTreeController, для управления иерархическими структурами данных. Большая часть API этого класса параллели тот из контроллера массива. Этот класс, в сочетании с новым классом NSIndexPath в Основе, позволяет вывести на экран дерево объектов модели в NSOutlineView или NSBrowser.

Большая часть API в этом классе или наследована от NSController и NSObjectController или разработана, чтобы быть подобной API NSArrayController. Многие понятия являются тем же за исключением того, что объекты адресуются NSIndexPath вместо интервала.

Содержание древовидного контроллера может быть установлено в корень дерева объектов модели. Клиенты могут тогда прогрессивно пересекать части дерева по мере необходимости путем получения объектов модели на основе NSIndexPath, представляющего их расположение в глубину в дереве. Это устраняет необходимость нас вытянуть все дерево в память передняя сторона. На вниз стороне, это препятствует тому, чтобы мы предложили selectObject: функциональность, так как мы не хотим платить штраф выполнения поиска в глубину объекта в неупорядоченном дереве.

NSTreeController пересекает свое дерево содержания при помощи кодирования значения ключа для нахождения дочерних элементов объекта модели. Существуют методы для того, чтобы установить ключ для использования для пересечения дерева, а также 2 других ключей, используемых в качестве возможностей повышения производительности. Если объект модели в дереве может сообщить о числе дочерних элементов, это имеет, мы можем использовать countKey для нахождения числа дочерних элементов вместо того, чтобы получить весь дочерний массив только для обмена сообщениями его количество. Аналогично, мы можем прекратить пересекать поддерево, как только мы встречаемся с объектом, говорящим нам, что это - вершина в дереве возвратом YES для набора ключей как leafKey.

Нужно отметить это из-за природы выборов в неупорядоченных деревьях, реализации preservesSelection функции, возможно довольно дорогой для больших, редких выборов, объединенных с широкими деревьями.


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

NSArrayController теперь поддерживает фильтрацию с NSPredicates:
- (void)setFilterPredicate:(NSPredicate *)filterPredicate;
- (NSPredicate *)filterPredicate;
- (void)setClearsFilterPredicateOnInsertion:(BOOL)flag;
- (BOOL)clearsFilterPredicateOnInsertion;
Предикат фильтра может быть связан с (перечислимой) привязкой предиката NSSearchFields (используйте опции NSDisplayNameBindingOption и NSPredicateFormatBindingOption сконфигурировать привязку) автоматически устанавливать просачивание пользовательского интерфейса.

NSArrayController также имеет новый режим для обработки множественных выборов:
- (void)setAlwaysUsesMultipleValuesMarker:(BOOL)flag;
- (BOOL)alwaysUsesMultipleValuesMarker;
По умолчанию, если все выбранные объекты будут иметь то же значение, контроллер массива будет смотреть на значения выбранных объектов на основе ключа ключом и указывать выборы многократных различных значений через NSMultipleValuesMarker, но обеспечивать общую ценность. Если alwaysUsesMultipleValuesMarker будет установлен в то ДА, он будет использовать NSMultipleValuesMarker для всех выборов с двумя или больше объектами (Вы будете обычно также устанавливать опцию NSAllowsEditingMultipleValuesSelectionBindingOption различной привязки значения для средств управления, связанных с выбором контроллера массива к НЕ). Этот новый флаг очень полезен в приложениях с очень большими массивами объектов, не хотящих позволять редактировать многократные выбранные объекты вообще, и также приводит к улучшениям высоких показателей в определенных ситуациях с большими массивами.


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

NSUserDefaultsController имеет новый метод, чтобы указать, существуют ли остающиеся без применения изменения:
- (BOOL)hasUnappliedChanges;
Например, можно связать включенное состояние кнопок к этому методу.


NSGraphicsContext

Класс NSGraphicsContext теперь имеет API для указания составляющей композит установки работы: compositingOperation и setCompositingOperation:. Как с другим графическим состоянием контекста, установка сохраняется/восстанавливается через saveGraphicsState и restoreGraphicsState методы. Установка не имеет никакого эффекта с существующим рендерингом API, берущий составляющую композит работу в качестве параметра такой как - [NSImage compositeToPoint:operation:].

NSGraphicsContextDestinationAttributeName теперь позволяет экземпляр NSBitmapImageRep как его значение. В настоящее время только непланарные экземпляры NSBitmapImageRep поддерживаются. Метод фабрики удобства graphicsContextWithBitmapImageRep: также добавляется.

Как пример использования, следующий код будет передискретизировать битовый массив в srcRep, чтобы быть шириной x высота с результатом, идущим в outputRep:
    NSBitmapImageRep *outputRep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
pixelsWide:width pixelsHigh:height bitsPerSample:8 samplesPerPixel:4
hasAlpha:YES isPlanar:NO colorSpaceName:NSCalibratedRGBColorSpace
bytesPerRow:0 bitsPerPixel:0];
    NSGraphicsContext *ctxt = [NSGraphicsContext graphicsContextWithBitmapImageRep:bitmapImageRep];
    [NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:ctxt];
[[NSGraphicsContext currentContext] setImageInterpolation:NSImageInterpolationHigh];
[srcRep drawInRect:NSMakeRect(0, 0, width, height)];
[NSGraphicsContext restoreGraphicsState];

Метод фабрики graphicsContextWithGraphicsPort:flipped: добавляется. Можно инстанцировать NSGraphicsContext от любого произвольного CGContextRef с помощью этого метода. initialFlippedState параметр определяет начальную букву flippedness установка возвращенного из-isFlipped метода.

Класс теперь имеет зеркально отраженную установку, доступную через isFlipped метод. Рекомендуемый способ определить текущее зеркально отраженное состояние рендеринга системы координат теперь [[NSGraphicsContext currentContext] isFlipped] вместо [[NSView focusView] isFlipped]. Отметьте, поскольку с дубликатом NSVIEW, эта установка не обязательно отражает текущую систему координат.


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

Реализация класса NSAffineTransform переместилась от AppKit до Основы.-transformBezierPath: - набор и-concat методы являются теперь частью категории, реализованной в AppKit.


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

Можно теперь получить и установить пользовательские гамма значения для файлов PNG с помощью свойства NSImageGamma. Если установлено в файле, свойство установлено в репутации растрового изображения при чтении и используется при сохранении битового массива как данных PNG.

NSBitmapImageRep теперь поддерживает альтернативные расположения альфа-значений и форматов. Следующее перечисление и методы были добавлены:
typedef enum {
NSAlphaFirstBitmapFormat = 1 << 0, // 0 means is alpha last (RGBA, CMYKA, etc.)
NSAlphaNonpremultipliedBitmapFormat = 1 << 1, // 0 means is premultiplied
NSFloatingPointSamplesBitmapFormat = 1 << 2    // 0 means integer
} NSBitmapFormat;
- (id)initWithBitmapDataPlanes:(unsigned char **)planes
pixelsWide:(int)width pixelsHigh:(int)height bitsPerSample:(int)bps
samplesPerPixel:(int)spp hasAlpha:(BOOL)alpha isPlanar:(BOOL)isPlanar
colorSpaceName:(NSString *)colorSpaceName
bitmapFormat:(NSBitmapFormat)bitmapFormat bytesPerRow:(int)rBytes bitsPerPixel:(int)pBits;
- (NSBitmapFormat)bitmapFormat;
Возвращает новую репутацию растрового изображения с помощью указанного формата. Недопустимые форматы заставят метод возвращать ноль. Например, установка формата с плавающей точкой требует, чтобы биты/выборка были 32 (хотя мы можем поддерживать двойную или так называемую половину значений с плавающей точкой в будущем.). Растровый формат может также быть установлен в ненулевой при загрузке в изображениях от файлов. Например, файлы PNG теперь загружаются в с форматом NSAlphaNonpremultipliedBitmapFormat.

Возвратитесь изображение формата находится или в от загружающегося файла или через-initWithBitmapDataPlanes:... или-initWithFocusedViewRect... Создается с помощью более старого APIs, не берущего растровый формат, значения по умолчанию формата к 0 (альфа в последний раз, предварительно умноженный, целое число)

По умолчанию новые форматы будут возвращены для случаев, где источник растровых данных находится в новом формате (плавающая точка, non-premutliplied, и т.д.). Скомпилированные приложения предварительного тигра все еще доберутся, старое предварительно умножило формат RGBA. Можно также включить или отключить его explicity путем установки значения по умолчанию NSOldBitmapFormatOnly в YES или НЕТ.-initWithFocusedViewRect: будет продолжать возвращать растровый формат 0 изображений.

Можно теперь указать NSJPEG2000FileType как выходной формат, чтобы записать JPEG 2 000 файлов.

Можно теперь указать прогрессивное сохранение JPEG через растровое свойство NSImageProgressive для вывода прогрессивных изображений JPEG.

При чтении или записи файла JPEG, можно включать NSDictionary как свойство растрового изображения NSImageEXIFData.

Методы теперь доступны, который устанавливал/получал цветную информацию для пикселя в NSBitmapImageRep. Если репутация изображения является частью NSImage, и репутация кэшируется NSImage, тогда изменяющим пиксельные значения, может не обнаружиться при рисовании изображения. Если Вы действительно помещаете репутацию в изображении и намереваетесь изменить ее, используйте [отображают setCacheMode:NSImageCacheNever]. Для-getPixel:atX:y: и-setPixel:atX:y: необходимо предоставить массив для соответствия выборок репутации на пиксель, и диапазон значений основываются на битах репутации на выборку (например, если бит/с равняется 4, то значения возвратились, от 0 до 15). Устанавливающие значения из диапазона не определяются. Если битовый массив имеет выборки с плавающей точкой, фактические значения возвратились, плавания. Точно так же порядок пикселей и умножение в обратном порядке, как предполагается, соответствуют растровый формат репутации.
- (void)setColor:(NSColor *)color atX:(int)x y:(int)y;
- (NSColor *)colorAtX:(int)x y:(int)y;
- (void)getPixel:(unsigned int[]) atX:(int)x y:(int)y;
- (void)setPixel:(unsigned int[]) atX:(int)x y:(int)y;
Если Вы не передаете в явных плоскостях и значениях bytesPerRow при создании NSBitmapImageRep, буферный указатель возвратился, больше может не быть первый байт блока malloc'ed, и bytesPerRow может быть дополнен дополнительными байтами для производительности. Если Вы пересекаете байты, не предполагайте, что bytesPerRow = ширина * bitsPerSample / 8 иначе изображение может казаться скошенным.

При изменении битов NSBitmapImageRep непосредственно можно найти случаи, где изображение не составляет обновленное изображение, потому что мы теперь позволяем Кварцу кэшировать пиксели (возможно в видеопамяти). Если Вы запрашиваете растровый указатель данных через - [NSBitmapImageRep getBitmapDataPlanes:] или - [NSBitmapImageRep bitmapData] тогда кэшируемая информация будет очищена, и последующие получения составят обновленное изображение. Если Ваше приложение просто запрашивает растровый указатель данных один раз и затем постоянно modifys это, изображение может не обновить.


NSImage и NSCachedImageRep, кэширующий поведение

Когда Кварцевое Экстремальное значение включено, поведение NSCachedImageRep изменилось для улучшения производительности. Эти изменения могут влиять на Ваш код. Если репутация изображения создается через - [NSCachedImageRep initWithSize:depth:separate:alpha:] тогда после получения, изображение будет быть скопированным с внеэкранного окна, где это сохранено, и окно может быть выпущено. Не полагайтесь на окно или прямоугольник, чтобы быть допустимыми за пределами вызовов NSImage-lockFocus/unlockFocus. При необходимости в окне вызывая - [Окно NSCachedImageRep] возвратит допустимое новое окно и прямоугольник, который может использоваться до следующего раза - [NSCachedImageRep рисуют], вызов выполняется. Если NSCachedImageRep создается через - [NSCachedImageRep: initWithWindow:rect:] После получения содержание окна будет скопировано и может не отразить текущее содержание окна, когда нарисовано позже. Если Вы захотите, чтобы imageRep отразил текущее содержание окна, вызвав - [То окно NSCachedImageRep] выпустит любую кэшируемую информацию.


NSImageView теперь поддерживает сокращение: копия: вставка: и удалите: (Раздел добавил начиная с WWDC),

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

По умолчанию NSImageView обеспечит, новое поведение для приложений основывалось на Тайгере, в то время как подавление его для совместимости для приложений основывалось на Пантере и ранее. Чтобы позволить приложениям переопределять это решение и отключать или добавлять новую функциональность на основе на экземпляр, мы добавили новый атрибут «allowsCutCopyPaste» и следующее соответствующее средство доступа API, к NSImageView:
@interface NSImageView
- (BOOL)allowsCutCopyPaste;
- (void)setAllowsCutCopyPaste:(BOOL)flag;
@end

Воспроизведение анимации NSImageCell

Иногда, кадры в animaged GIF изображение укажут длительность воспроизведения нуля. На Пантере поддерживающий анимацию NSImageCell воспроизводит такую анимацию без задержки между кадрами (т.е. максимально быстро). На Тигре NSImageCell фиксирует продолжительность кадра к минимуму 1/30 секунды, соответствуя способ, которым Safari и Internet Explorer обрабатывают такой GIFs.


NSImageCell NSScaleToFit и копирование

На Пантере и ранее, набор NSImageCell к режиму NSScaleToFit всегда делал бы копию своего присвоенного изображения, даже когда NSImageCell был измерен таким образом, что изображение будет выведено на экран в точно его первоначальном размере. Когда изображение выводится на экран в некотором размере кроме его точного первоначального размера, на Тигре NSImageCell только делает эту копию.


Установка пользовательского значка NSWorkspace API

NSWorkspace имеет новый-setIcon:forFile:options: метод, создающий значок из данного изображения и присваивающий его как пользовательский значок данного файла или папки:
- (BOOL)setIcon:(NSImage *)image forFile:(NSString *)fullPath options:(unsigned)options;
Параметр «изображения» указывает произвольное изображение, с или без информации о прозрачности (альфа), которая будет автоматически повторно масштабироваться для генерации представлений значка. «полный путь» должен указать существующий файл или папку, к которой у пользователя есть полномочия записи. Параметр «опций» является поразрядной комбинацией следующих флагов, объявленных в NSWorkspace.h (это может быть нуль):
typedef unsigned int NSWorkspaceIconCreationOptions;
enum {
NSExcludeQuickDrawElementsIconCreationOption = 1 << 1,
NSExclude10_4ElementsIconCreationOption = 1 << 2
};
Флаги опции обеспечивают управление видами представлений, которые будет содержать пользовательский значок.

Формат «QuickDraw» допускает представления значка до 128x128 пикселей и поддерживается на Mac OS X 10.0 до 10,4.

Mac OS X 10,4 дополнений это с новым классом представления значка, разработанного для поддержки более высоких разрешений с лучшей эффективностью хранения. Средство поиска на Mac OS X 10.4 еще не использует значки в этом новом формате, но поддерживает для генерации их, предоставлен в-setIcon:forFile:options: API для прямой совместимости. Это новое представление значка безопасно проигнорировано Средством поиска на Mac OS X 10.3, но его присутствие предотвратит дисплей пользовательского значка файла в пред10.3 системах, даже если также будут присутствовать представления в формате «QuickDraw». Вследствие этой проблемы совместимости, и избегать напрасно использовать дополнительное хранение, рекомендуется, что приложения, использующие-setIcon:forFile:options: API подавляет генерацию этого нового представления, ожидая его использование будущим выпуском системы.

NSExclude10_4ElementsIconCreationOption подавляет генерацию представлений в новом сжатом формате с высокой разрешающей способностью. NSExcludeQuickDrawElementsIconCreationOption подавляет генерацию представлений QuickDraw-формата, понимающихся и использующихся Mac OS X 10.0 до 10,4. Когда никакой флаг не указан, поведение будет состоять в том, чтобы генерировать представления в обоих форматах, приводящих к файлу или папке, пользовательский значок которой будет визуализуемым на Mac OS X 10.3 и 10.4.


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

Если метод fullPathForApplication: не удалось найти приложение с помощью стандартной базы данных LaunchServices, это отступило бы к выполнению мирового поиска в стандартных местах где приложения многие быть найденным. На практике, хотя база данных LaunchServices действительно включает те места, таким образом, грубая сила перерывает, они просто делают вызов метода значительно медленнее.

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

Метод selectFile:inFileViewerRootedAtPath: теперь консультируется с пользовательским значением по умолчанию под названием «NSFileViewer», и если настоящее, использование это как пакет ID приложения для использования в качестве средства просмотра файла для выбора файла в. Если это значение по умолчанию не установлено, или нет никакого соответствующего зарегистрированного приложения, то Средство поиска используется в качестве нормального. selectFile:inFileViewerRootedAtPath: приложения метода, должен использовать для, «Показывают в Средстве поиска» функциональность.

С тех пор 10.0, метод getInfoForFile:application:type вел себя по-другому, чем задокументированный. Документация утверждала, что возвращенный тип является фактически не типом файла, но одним из маленького набора предопределенных идентификаторов, указывающих вид файла; оказывается, что этот метод фактически возвратил тип документа. У Тигра мы продолжаем это существующее ранее поведение; документация будет фиксирована. Другое требование документации, что этот метод возвратится НЕ, если файл не будет существовать, является истиной только, когда информацию приложения просят относительно (параметр приложению: не-NULL). Таким образом, этот метод возвратится НЕ, только если относительно информации приложения просят, и или файл не существует, или LaunchServices не имеет ассоциации приложения для документа.

Уведомление NSWorkspaceDidUnmountNotification могло быть отправлено даже за неуспешными попытками размонтирования. Это теперь отправляется, только если фактически размонтирован объем.


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

Калиброванный NSColors (создаваемые с colorWithCalibratedRed:.., colorWithCalibratedHue:.., или colorWithCalibratedWhite:...), теперь используют Кварц универсальные цветовые пространства, а не «дисплей» (иначе «устройство») цветовые пространства. Поскольку цели отладки это поведение, может быть отключен со значением по умолчанию NSUseGenericColorSpaceForCalibrated. Это - значение по умолчанию отладки и будет удалено в будущем обновлении.

В приложениях надлежащий способ получить поведение цветового пространства устройства состоит в том, чтобы создать цвета с colorWithDeviceRed:..., colorWithDeviceWhite:..., и т.д.

Во многих случаях, как надлежащий, основной цвет для NSColors представляющие цвета, используемые в пользовательском интерфейсе (например, методы такой как - [NSColor alternateSelectedControlColor]), был изменен на цветовое пространство устройства.


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

Новый класс, NSColorSpace, вместе с новым API в NSColor, позволяет создать экземпляры NSColor, относящиеся к пробелам пользовательского цвета, включая создаваемых с профилями ColorSync.

Можно создать экземпляры NSColorSpace из экземпляров CMProfileRef или NSDatas, содержащего данные профиля ICC:
- (id)initWithICCProfileData:(NSData *)iccData;
- (id)initWithColorSyncProfile:(void * /* CMProfileRef */)prof;
- (NSData *)ICCProfileData;
- (void * /* CMProfileRef */)colorSyncProfile;
Можно запросить характеристики цветовых пространств с:
- (int)numberOfColorComponents;       // Does not include alpha
- (NSColorSpaceModel)colorSpaceModel;
- (NSString *)localizedName; // Will return nil if no localized name
NSColorSpace предназначается, чтобы быть бесплатным мостом к CGColorSpaceRef. Но это не было реализовано в Тайгере.

Обратите внимание на то, что существующее понятие «цветового пространства», где небольшое количество предопределенных цветовых пространств идентифицируются их именами, не должно быть перепутано с этим новым классом NSColorSpace. Различные типы NSColors традиционно отличило их «цветовое пространство» (представленный colorSpaceName). Это цветовое пространство решает, что примитивные средства доступа для цвета, и в экземплярах генерала Нсколора с различными цветовыми пространствами не выдерживают сравнение равный; если все их атрибуты равны, экземпляры НСКОЛОРА в том же цветовом пространстве выдерживают сравнение равный.

Существующими именами цветового пространства, поддерживаемыми NSColor, является NSCalibratedWhiteColorSpace, NSCalibratedRGBColorSpace, NSDeviceWhiteColorSpace, NSDeviceRGBColorSpace, NSDeviceCMYKColorSpace, NSNamedColorSpace и NSPatternColorSpace. NSColorSpace обеспечивает методы класса возвратить экземпляры, соответствующие применимым предопределенным именам цветового пространства:
+ (NSColorSpace *)genericRGBColorSpace;   // NSColorSpace corresponding to Cocoa colorspace name NSCalibratedRGBColorSpace
+ (NSColorSpace *)genericGrayColorSpace; // NSColorSpace corresponding to Cocoa colorspace name NSCalibratedWhiteColorSpace
+ (NSColorSpace *)genericCMYKColorSpace;
+ (NSColorSpace *)deviceRGBColorSpace; // NSColorSpace corresponding to Cocoa colorspace name NSDeviceRGBColorSpace
+ (NSColorSpace *)deviceGrayColorSpace; // NSColorSpace corresponding to Cocoa colorspace name NSDeviceWhiteColorSpace
+ (NSColorSpace *)deviceCMYKColorSpace; // NSColorSpace corresponding to Cocoa colorspace name NSDeviceCMYKColorSpace
Для поддержки пользовательского NSColorSpaces мы позволяем создать NSColors с «NSCustomColorSpace» имени цветового пространства. Такие цвета создаются с:
/* Create colors with arbitrary color space. The number of components in the provided array should match
the number dictated by the specified color space, plus one for alpha (1.0 for opaque colors);
otherwise an exception will be raised. If the color space is one which cannot be used with NSColors, nil is returned.
*/
+ (NSColor *)colorWithColorSpace:(NSColorSpace *)space components:(const float *)components count:(int)numberOfComponents;
и с атрибутами таких цветов получают доступ:
/* For colors with custom color space; get the color space and individual floating point components, including alpha.
Note that all these methods will work for other NSColors which have floating point components.
They will raise exceptions otherwise, like other existing color space-specific methods.
*/
- (NSColorSpace *)colorSpace;
- (int)numberOfComponents;
- (void)getComponents:(float *)components;
Один дополнительный API, добавленный к NSColor, позволяет преобразовывать цвета между цветовыми пространствами:
/* colorUsingColorSpace: will convert existing color to a new color space and create a new color,
which will likely have different component values but look the same. It will return the same color
if the color space is already the same as the one specified. Will return nil if conversion is not possible.
*/
- (NSColor *)colorUsingColorSpace:(NSColorSpace *)space;
colorUsingColorSpace: и эти три метода выше работы не только на цветах NSCustomColorSpace, но также и на других плавающих компонентно-ориентированных цветах. Обратите внимание на то, что colorUsingColorSpace: не гарантирует, что возвратил цвет NSCustomColorSpace; например, если - [NSColor colorUsingColorSpace: [NSColorSpace genericRGBColorSpace]] отправляется в цвет NSCalibratedRGBColorSpace, тот же цвет мог бы очень хорошо быть возвращен. Конечно, такой цвет ответит NSColorSpace genericRGBColorSpace] для его цветового пространства, таким образом, результат не будет настолько неожидан.

Существующий метод colorUsingColorSpaceName: все еще верный способ получить цвет с определенным colorSpaceName для другого цвета (или ноль, если преобразование не возможно).

Когда цвета с пробелами пользовательского цвета архивируются в старые (невключенные) архивы, предположение - то, что такие архивы все еще должны быть считаны в системах предтигра, таким образом, цвета записаны у предварительного тигра совместимый вид, будучи преобразованным в одно из именованных цветовых пространств, без экземпляра NSColorSpace. возможно переопределить это поведение со значением по умолчанию NSWriteCustomColorSpacesToOldArchives; установка этого к YES означает, что пробелы пользовательского цвета будут записаны в невключенные архивы, делая их несовместимыми с системами предтигра.


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

Удаление NSColorWell из его окна теперь деактивировало цвет хорошо.


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

Недоступные для редактирования списки цветов (идентифицированный isEditable, возвращающимся НЕ) теперь, повышают исключения, когда попытка предпринята для изменения их. Это как документируется.


Изменения доступности

Следующий метод был добавлен:
- (BOOL)accessibilitySetOverrideValue:(id)value forAttribute:(NSString *)attribute;
Это позволяет Вам переопределять значение атрибута или добавлять новый атрибут к определенному Элементу UI – т.е. экземпляр NSObject, соответствующего протокол NSAccessibility. Ранее, единственный способ выполнить это состоял в том, чтобы использовать пользовательское подкласс для того, что Элемент UI и переопределяет надлежащие методы протокола NSAccessibility – например, accessibilityAttributeValue.

• Этот метод только работает над объектами, класс которых уже реализует протокол NSAccessibility.

• Возвращаемое значение указывает, была ли попытка переопределить успешна.

• Если указанный атрибут уже поддерживается объектом, значение, Вы указали победы - т.е. для этого экземпляра, это переопределит значение атрибута, которое было бы возвращено иначе. Это сделано вне протокола NSAccessibility – accessibilityAttributeValue, не будет вызван при определении значения переопределенного атрибута.

• Если указанный атрибут не будет существовать, то он будет создаваться. Это сделано вне протокола NSAccessibility – accessibilityAttributeNames, все еще возвратит старый список, не содержащий новый атрибут.

• Еще раз переопределение приписывает, сделан вне протокола NSAccessibility. Доступ к атрибутам с помощью accessibilityAttributeNames и accessibilityAttributeValue не возвратит атрибуты, создаваемые процессом переопределения, и при этом это не возвратит их переопределенные значения.

• Переопределенные атрибуты не устанавливаемы. Т.е. accessibilitySetValue:forAttribute никогда не будет вызываться для переопределенного атрибута. При переопределении устанавливаемого атрибута, это больше не будет устанавливаемо. Что именуется, вот возможность вспомогательного приложения изменить значение атрибута. Вызов accessibilitySetOverrideValue:forAttribute снова изменит переопределенное значение.

• Метод, accessibilitySetOverrideValue:forAttribute: не должен быть перепутан с accessibilitySetValue:forAttribute:. Последний метод, который является частью протокола NSAccessibility, вызывается, когда вспомогательное приложение хочет изменить значение атрибута - например, изменить установку ползунка.

• Если необходимо отменить эффект использования этого метода, вызовите его снова передающий ноль для значения.

• Необходимо гарантировать, чтобы Вы вызвали этот метод на фактический объект, представляющий Элемент UI. Например, в случае NSButton необходимо было бы использовать базовый NSButtonCell. Сам NSButton проигнорирован доступностью. Если Вы незнакомы с этим понятием, см. документацию для accessibilityIsIgnored метода протокола NSAccessibility.

• Этот метод работает над объектом, представляющим единственный Элемент UI. Когда не будет никакого объекта, лежащего в основе Элемента UI тогда, Вы не будете в состоянии использовать его. Общий падеж, где это - проблема, - когда отдельный объект представляет многократные Элементы UI (например, NSSegmentedCell имеет только отдельный объект, но это обеспечивает Элементы UI для каждого сегмента).
NSString *NSAccessibilityRoleDescription(NSString *role, NSString *subrole);
NSString *NSAccessibilityRoleDescriptionForUIElement(id element);
NSString *NSAccessibilityActionDescription(NSString *action);
Эти функции были добавлены для помощи с реализацией протокола доступности – в частности для возврата описаний стандартных ролей и действий. Например, если Вы реализуете виджет кнопки, не наследовавшийся от NSButton, необходимо использовать NSAccessibilityRoleDescription для возврата локализованного ролевого соответствия описания, что возвращается стандартными кнопками.

• Если нет никакой подроли, необходимо передать ноль NSAccessibilityRoleDescription.
• NSAccessibilityRoleDescriptionForUIElement походит на NSAccessibilityRoleDescription, но это запрашивает элемент для получения роли и подроли. Очевидно, NSAccessibilityRoleDescription более эффективен, но эта функция полезна для того, чтобы дополнить аксессуарами базовые классы так, чтобы они должным образом обработали производные классы – который может переопределить подроль – или даже роль.


Атрибуты формата пикселя NSOpenGL

Четыре новых константы атрибута формата пикселя были добавлены к NSOpenGL.h, для представления новых возможностей кадрового буфера, предоставленных CGL.
NSOpenGLPFAColorFloat         =  58, /* color buffers store floating point pixels    */
NSOpenGLPFAMultisample = 59, /* choose multisampling */
NSOpenGLPFASupersample = 60, /* choose supersampling */
NSOpenGLPFASampleAlpha = 61, /* request alpha filtering */
См. информацию о версии OpenGL для получения информации относительно корректного использования этих функций.


Службы (Раздел добавил начиная с WWDC),

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

У Тигра средство Служб называет коммуникационные порты, которые это использует на основе идентификатора пакета поставщика услуг. (На предыдущих выпусках имя процесса использовалось вместо этого.) Это изменение в соглашении о присвоении имен будет невидимо для большинства поставщиков услуг и клиентов. Однако пакет «.service» может дополнительно объявить услуги, предоставляющиеся исполнимой программой другого пакета вместо содержания ее собственной исполнимой программы. В таких случаях пакет, объявляющий службу, должен указать идентификатор пакета провайдера, поскольку NSPortName службы, чтобы позволить средству Служб найти и (если необходимый) запускают провайдера. Пакет провайдера может быть пакетом «.app» или пакетом «.service», имеющим его собственную исполнимую программу.


Исправление ошибки в Обработке NSURLPboardType (Раздел добавил начиная с WWDC),

Ошибка была представлена в Mac OS 10.3, который иногда препятствовал тому, чтобы данные NSURLPboardType появились на областях монтажа, предоставленных программами Углерода. Например, вызов + [NSURL URLFromPasteboard: когда файл образа был перетащен от Средства поиска и отброшен на одном из DragDropImageViews программы,] в примере CocoaDragAndDrop неправильно возвратил бы ноль. Эта ошибка была исправлена.


Делегация и Уведомление, предупреждающее (Раздел добавил начиная с WWDC),

С классами AppKit, предоставляющими делегации и уведомлению (такому как NSWindow), если Вы явно регистрируетесь для определенных уведомлений, также использующихся для отправки сообщений делегата, и затем Вы прекращаете быть делегатом, Вы не зарегистрированы для тех уведомлений. Не ясно, как это будет адресоваться в будущем, но необходимо знать об этом потенциально неожиданном поведении.


Предупредительная панель в Java

Ошибка, где случаи «%» исчезли бы в предупредительных панелях в JAVA-приложениях Какао, была исправлена для приложений, соединенных на Тайгере или позже. Обходное решение для более ранних приложений должно удвоить каждый «%», происходящий в строке сообщения.





Отмечает определенный для Mac OS X 10.3

Улучшения воды

Пантера взяла с собой набор улучшений Воды, предназначающихся для улучшения вида приложений совместимо, не будучи нужен ни в каких изменениях в приложениях. Изменения в элементах пользовательского интерфейса сохраняют метрики расположения, который помогает поддержать совместимость. Где это необходимо, возвращаемые значения различного APIs (например, NSColors) были изменены для поддержки нового взгляда; приложения с помощью этого APIs получат новые значения автоматически.


Мини-средства управления

Много средств управления теперь поддерживают размер элемента управления NSMiniControlSize, который меньше, чем NSSmallControlSize. Средства управления, рисующие с этим размером: переключатели, флажки, кнопки, ползунки, снабжают вкладками представления, степперы, раскрывающиеся и выпадающие меню и поля комбинированного списка. Округленные текстовые поля и поля поиска могут теперь быть измерены меньшие и будут использовать меньшую округленную внешнюю панель в зависимости от высоты текстового поля. NSStepperCell теперь поддерживает и маленькие и мини-размеры. Минисредства управления разработаны, чтобы использоваться с LucidaGrande 9 ПБ как шрифт текста.


Привязка (иначе уровень контроллера)

Главная новая функция в Какао для Пантеры является возможностью связать объекты пользовательского интерфейса с объектами модели через контроллеры. Эта технология позволяет разработчикам Какао получать намного больше внедрения приложения, сделанного непосредственно в Интерфейсном Разработчике.

Технология уровня контроллера базируется в парадигме проекта Model-View-Controller (MVC). Какао обеспечивает богатый набор представления и классов модели, но до сих пор не было никакой мощной и обобщенной функциональности контроллера. С новым уровнем контроллера у разработчиков Какао наконец есть уровень API и Интерфейсная поддержка уровня Разработчика привязки значений дисплея и характеристик UI приложения к данным, сохраненным в модели данных приложения. Через уровень контроллера значения данных и изменения могут быть распространены живые между элементами UI и хранением данных приложения без разработчиков, имеющих необходимость записать весь код связующего звена, к которому они имели прежде.

В Интерфейсном Разработчике проверьте палитру Controllers для классов NSController, которые могут быть добавлены к новым и существующим перьям. Эти контроллеры добавляют функциональность как отслеживание выбора, распространение редактирований в пользовательском интерфейсе, сортировки и обработки контроля ввода. Логика встроила в NSUserDefaultsController, NSObjectController и NSArrayController, которые предоставлены для Вас по умолчанию, позволяют Вам фокусироваться на разработке модели данных и пользовательского интерфейса, не имея необходимость писать, что чрезмерные суммы связующего звена кодируют для получения до полируемого приложения. Классы контроллера предоставляют связующую логику Вам.

В Интерфейсном Разработчике существует также новый элемент инспектора: Инспектор Привязки. Этот инспектор позволяет Вам связывать элементы пользовательского интерфейса как NSTextField, NSTableView, NSImageView и NSTabView, к экземплярам NSController в Вашем пере (или экземпляры контроллера к другим контроллерам). Таким образом, Вы не должны явно делать соединения розетки к своему NSDocument или владельцу файла NSApplication. Различными свойствами виджетов (таких как источник значения NSTextField, или цвет шрифта и цвет текста текстового поля) можно управлять через контроллер.

Соответствующие заголовочные файлы для этой технологии включают <AppKit/NSKeyValueBinding.h>, <AppKit/NSController.h>, <AppKit/NSArrayController.h>, <AppKit/NSObjectController.h>, и <AppKit/NSUserDefaultsController.h>.

Кодирование значения ключа было также улучшено для поддержки технологии привязки. См. <Foundation/NSKeyValueCoding.h> и <Foundation/NSKeyValueObserving.h> для получения дополнительной информации.

Обратите внимание на то, что файлы пера с помощью нового уровня контроллера (экземпляры подклассов NSController и привязки) могут только загружаться и экономиться «10.2 и позже» формат файла пера. Файлы пера в более старых форматах должны быть преобразованы путем открытия их в Интерфейсном Разработчике и явно сохранения их в новом формате.

Кроме того, файлы пера, создаваемые с предварительными показами Mac OS X 10.3, могут содержать привязку, которая не законна в выпуске GM. Та привязка обычно приводит к исключениям кодирования значения ключа («неопределенный ключ») во время выполнения и обнаруживается в разделе «Parameters» инспектора Привязки в Интерфейсном Разработчике. Необходимо разъединить привязку вручную и заменить их новой привязкой (который обычно очевиден для выбора).

Привязка для пунктов меню и других объектов, автопроверяющих включенное состояние (как элементы панели инструментов) проигнорирована, если автопроверка не выключена (в NSMenu - который может быть сделан в Интерфейсном Разработчике). Например, пункт меню с привязкой значения, но никакой набор цели/действия, будет всегда отключаться, если автопроверка не будет выключена вручную.

NSControllers игнорируют опции, которые могут быть переданы-addObserver:forKeyPath:options:context:context: метод. Таким образом, даже при регистрации наблюдателей в опциях NSKeyValueObservingOptionNew или NSKeyValueObservingOptionOld Вы не получите значения в словаре изменения-observeValueForKeyPath:ofObject:change:context: вызовы. Это обычно - не проблема, но если Вы полагаетесь на получение тех значений, обходное решение может быть должно наблюдать объекты модели непосредственно.



NSAlert

Мы добавили NSAlert как новый общедоступный класс. Этот класс обеспечивает функциональность, ранее доступную только через функции на базе С NSPanel, и создает гибкость к тому же функциональность. Например, теперь возможно указать пользовательский значок и присвоить специализированные ключевые эквиваленты или возвращаемые значения к кнопкам NSAlert. Также возможно использовать больше чем три кнопки, несмотря на то, что это должно быть сделано только при необходимости. Мы также добавили API для включения кнопки справки начеку панель.

Этот API может использоваться и для модальных панелей и для листов.

Обратите внимание на то, что по умолчанию новые возвращаемые значения---NSAlertFirstButtonReturn, и т.д.---проще использовать и более гибкий, но не являются тем же как предыдущим---NSAlertDefaultReturn значений и т.д. Это - важный момент, поскольку Ваши предупредительные обработчики возврата изменят поведение при перемещении кода без уделения внимания этому. Следующий удобный метод может использоваться для простой миграции от использования APIs на базе С, поскольку это устанавливает совместимые возвращаемые значения:
+ (NSAlert *)alertWithMessageText:(NSString *)message
defaultButton:(NSString *)defaultButton
alternateButton:(NSString *)alternateButton
otherButton:(NSString *)otherButton
informativeTextWithFormat:(NSString *)format, ...;
Возвращаемые значения могут быть настроены с setTag: методы, использование которых в предупредительной панели резервируется с этой целью.

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

См. документация для более подробной информации об этом новом классе.


NSSpeechRecognizer / NSSpeechSynthesizer

NSSpeechRecognizer и NSSpeechSynthesizer являются двумя новыми классами AppKit, обеспечивающими доступ к способностям к синтезу речи Mac OS X. Существуют примеры этих классов в использовании в/Developer/Examples/Speech. Кроме того, документация для этих классов доступна в ссылке Набора Приложения.


NSShadow

NSShadow является новым классом AppKit, создаваемым в целях содержания параметров падающей тени, которая будет использоваться при рисовании. Тени всегда рисуются в основном пространстве (также известный как пространство пользователя по умолчанию). Это означает, что вращения, переводы и т.д. текущей матрицы преобразования (CTM) не влияют на получающуюся тень. Другой способ думать об этом состоит в том, что изменения в CTM не перемещают или изменяют источник света.

Существует два позиционных параметра для тени, x-смещения и y-смещения тени, выраженной как единственный NSSize, в модулях пространства пользователя по умолчанию, с положительными произошедшими значениями и вправо. Существует один дополнительный параметр с плавающей точкой, радиус размытия, указывающий, насколько маска изображения объекта размывается, прежде чем это будет составлено на место назначения. Нулевое значение не означает размытости, и большие значения дают соответственно большую размытость, снова в модулях пространства пользователя по умолчанию.

Кроме того, тень может иметь цвет. Если никакой цвет не будет выбран, то тень будет нарисована с помощью черного с альфа-значением 1/3. Если цвет будет выбран, то тень будет нарисована с помощью того цвета. В настоящее время только цвета, конвертируемые к RGBA, поддерживаются.

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


NSNib

NSNib является новым классом AppKit, представляющим файл пера. Когда экземпляр NSNib создается из файла пера, все данные должны были инстанцировать пера (граф объектов, а также изображения и звуки, которые могли бы быть в пакете пера), читаются из диска, однако перо не инстанцируют, пока Вы не вызываете один из методов инстанцирования. Можно использовать NSNib, чтобы быстро повторно инстанцировать файла пера, к которому часто получают доступ, не загружая перо неоднократно из диска.



NSSegmentedControl, NSSegmentedCell

NSSegmentedControl является новым управлением, реализующим многослойную ячейку или представление 'сегмента'. Каждый сегмент может содержать изображение, простую метку, меню, тег и подсказку. Сегменты автоизмерены, если не установлена определенная ширина. Класс обеспечивает три режима отслеживания: подобный Радио (NSSegmentSwitchTrackingSelectOne), переключаясь (NSSegmentSwitchTrackingSelectAny), и кнопка (NSSegmentSwitchTrackingMomentary).

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

См. документация для большего количества информации об этих двух классах.

(Как в стороне, это было управлением, для которого мы попросили именование предложений в течение 2003 WWDC. Большое спасибо за Ваши карты и буквы---мы получили сотни предложений!)


NSSearchField и NSSearchFieldCell

Новые подклассы NSTextField и NSTextFieldCell были добавлены, которые создают стандартный UI для полей поиска как те в Почте, Safari и Адресной книге. Когда пользователь нажимает возврат, это включает кнопку отмены, кнопку поиска с меню и опцией отправить результаты при вводе или. API для NSSearchField минимален и вперед к NSSearchFieldCell. Необходимо поставить цель и действие этого управления или его ячейки к получателю, интересующемуся поисковым запросом. Граница является полем круглого почерка.

См. документация для большего количества информации об этих двух классах.


NSSlider

Новый стиль ползунка вызвал круговой ползунок (т.е. набор) доступно. Можно получить его путем установки типа ползунка. Вы тогда получаете фиксированный размерный ползунок, идущий от minValue до maxValue. minValue, наверху и повышения стоимости, поскольку Вы вращаетесь по часовой стрелке к чуть ниже maxValue (например, если Вы устанавливаете минуту = 0, макс. = 360, можно добраться до 359,999). Можно показать метки и иметь значения, ограниченные просто метками то же как регулярный ползунок. Вы можете только иметь регулярный и маленький. Нет никакой мини-версии.
typedef enum {
NSLinearSlider = 0,
NSCircularSlider
} NSSliderType;
- (void)setSliderType:(NSSliderType)sliderType;
- (NSSliderType)sliderType;

Новый NSOpenPanel / NSSavePanel

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

Вследствие изменений в панели больше не поддерживаются следующие константы (теги представления). Последние три были уже отмечены в NSSavePanel.h, как осуждается:
NSFileHandlingPanelImageButton
NSFileHandlingPanelTitleField
NSFileHandlingPanelBrowser
NSFileHandlingPanelForm
NSFileHandlingPanelHomeButton
NSFileHandlingPanelDiskButton
NSFileHandlingPanelDiskEjectButton
Добавленный следующие методы получателя соответствовать существующие методы установщика:
- (id)delegate;                // - (void)setDelegate:(id)delegate;
- (BOOL)canSelectHiddenExtension;    // - (void)setCanSelectHiddenExtension:(BOOL)flag;
Добавленный следующие методы делегата позволить аксессуар просматривает для хранения в синхронизации с изменениями в состоянии панели:
- (void)panel:(id)sender directoryDidChange:(NSString *)path;
- (void)panelSelectionDidChange:(id)sender;
Два метода были добавлены, чтобы позволить обеспечивать короткое сообщение наверху панели:
- (NSString *)message;
- (void)setMessage:(NSString *)message;
В Ягуаре каталог методов, имя файла и URL были применимы только после того, как панель была отклонена – и задокументирована как так. Это ограничение было снято у Пантеры.

Использование-selectText: осуждается. Этот метод больше ничего не делает.

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


NSSavePanel

Два метода были добавлены к NSSavePanel для поддержки изменения метки рядом с полем редактирования имени файла - который обычно маркируется, «Сохраняют как»::
- (NSString *)nameFieldLabel;
- (void)setNameFieldLabel:(NSString *)label;
В Ягуаре мы поддерживали единственный требуемый тип файла с методами setRequiredFileType и requiredFileType. Мы теперь поддерживаем список типов:
- (NSArray *)allowedFileTypes;
- (void)setAllowedFileTypes:(NSArray *)types;
Старые и новые вызовы взаимодействуют следующим образом. Вызов setRequiredFileType: эквивалентно вызову setAllowedFileTypes: с массивом того одного типа. Вызов requiredFileType возвратит первый элемент списка позволенных типов или ноля, если не будет ни одного. Как имел место с setRequiredFileType: ноль, setAllowedFileTypes:nil средние значения позволяют любой тип файла. Вызов setAllowedFileTypes: с пустым массивом не позволяется.

В Ягуаре, если пользователь попытался использовать имя файла с распознанным расширением, не соответствовавшим требуемый тип, им дали три опции: отмена, замените их расширение требуемым или используйте обоих (например, foo.html.txt). Не было никакой опции использовать указанное расширение. Приложения, которые должны были предоставить эту возможность (например, TextEdit и Safari, таким образом, Вы могли использовать.h или .html как альтернатива .txt) имели специальный код для работы вокруг этого ограничения.

Для обращения этого существует два новых метода:
- (BOOL)allowsOtherFileTypes;
- (void)setAllowsOtherFileTypes:(BOOL)flag;
Как имел место в Ягуаре, если пользователь пытается сохранить имя файла с распознанным расширением, это не находится в списке позволенных типов, им подарят диалоговое окно. Однако, если allowsOtherFileTypes будет ДА, то диалоговое окно представит опцию использования расширения, которое указал пользователь. Настройка по умолчанию для allowsOtherFileTypes нет, иначе существующие приложения начали бы получать расширения, которые они не подготовлены обработать.



NSOpenPanel

Следующий новый метод NSOpenPanel позволяет немодальную работу открытой панели:
- (void)beginForDirectory:(NSString *)path
file:(NSString *)name
types:(NSArray *)fileTypes
modelessDelegate:(id)delegate
didEndSelector:(SEL)didEndSelector
contextInfo:(void *)contextInfo;
Два метода были добавлены, чтобы позволить открытым панелям иметь кнопку «New Folder» - который может быть полезным в открытых панелях, сконфигурированных для разрешения выбора папки:
- (void)setCanCreateDirectories:(BOOL)flag;
- (BOOL)canCreateDirectories;

NSMenu

NSMenuItems, имеющие подменю теперь, могут иметь цель и набор действия, и сам элемент можно выбрать. Вызов - [NSMenuItem setSubmenu:] больше не будет изменять действие, если это не будет NULL или @selector (submenuAction:). Можно выключить его снова путем установки действия элемента или к NULL или к @selector (submenuAction:).

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

NSMenuItem имеет некоторый новый метод set/метода get API для добавления функциональности, найденной в меню Carbon:
- (void)setAlternate:(BOOL)isAlternate;
- (BOOL)isAlternate;
Это отмечает элемент как альтернативу к предыдущему пункту меню. Если элемент будет иметь тот же ключевой эквивалент как предыдущий элемент, но будет иметь различные ключевые эквивалентные модификаторы тогда, то элементы будут свернуты в единственный видимый элемент, и надлежащий элемент покажет при отслеживании меню. У Вас могут быть элементы без ключевых эквивалентных, но различных модификаторов, когда, единственный способ получить доступ к альтернативным элементам через мышь. У Вас может быть много элементов, отмеченных столь же альтернативный, хотя, если их ключевые эквиваленты не соответствуют, они могут закончить как отдельно видимые элементы. При отмечании первого элемента, поскольку альтернатива не имеет никакого эффекта. Этот флаг архивируется.
- (void)setIndentationLevel:(int)indentationLevel;
- (int)indentationLevel;
Это устанавливает уровень отступа пункта меню от 0 до 15. Уровни отступа, больше, чем 15, прикрепляются к максимуму. Значения меньше чем 0 генерируют исключение. Уровень отступа по умолчанию 0. Это значение архивируется.

Можно теперь указать шрифт при отображении контекстного меню с помощью метода класса:
+ (void)popUpContextMenu:(NSMenu *)menu
withEvent:(NSEvent *)event
forView:(NSView *)view
withFont:(NSFont *)font;
Передача в ноле для шрифта использует стандартный шрифт для меню.

Можно передать в пользовательской строке для пункта меню путем установки приписанной строки. Это позволит Вам добавить разработанный текст и встроенное изображение к строке пункта меню. Если цвет текста не будет установлен, то это будет бело на выборе и серо на отключенном. Любой цветной текст останется неизменным, когда выделено. При установке приписанного заголовка регулярный заголовок также установлен с простым строковым значением, но когда Вы очищаете приписанный строковый заголовок, заголовок остается неизменным. Эта строка не архивируется в в старом формате пера.
- (void)setAttributedTitle:(NSAttributedString*)string;
- (NSAttributedString*)attributedTitle;
Можно установить тег справки для пункта меню. Это включает элементы в основную строку меню. Эта строка не архивируется в старом формате пера.
- (void)setToolTip:(NSString*)toolTip;
- (NSString*)toolTip;
Можно теперь зарегистрироваться для уведомления, когда меню, отслеживающее концы, даже если не отправляется никакое действие. Регистр для уведомления:
NSString *NSMenuDidEndTrackingNotification;
Это уведомление отправляется за строкой главного меню ([NSApp mainMenu]) и за главным меню кнопки всплывающего меню.

NSMenu теперь имеет делегата, которого можно использовать для заполнения меню непосредственно перед тем, как это будет нарисованным и проверять на ключевые эквиваленты, не создавая пункт меню. NSMenu имеет два новых метода:
- (void)setDelegate:(id)anObject;
- (id)delegate;
Этот делегат не архивируется в в старом формате пера.

Для заполнения меню делегат должен реализовать также:
- (void)menuNeedsUpdate:(NSMenu*)menu;
Когда меню собирается быть выведенным на экран в начале сеанса отслеживания, который вызывают. Можно изменить меню путем добавления, удаления или изменения пунктов меню. Любые новые элементы должны иметь надлежащее, включают набор состояния.

Также, если население собирается не торопиться, можно реализовать пару методов:
- (int)numberOfItemsInMenu:(NSMenu*)menu;
- (BOOL)menu:(NSMenu*)menu updateItem:(NSMenuItem*)item atIndex:(int)index shouldCancel:(BOOL)shouldCancel;
Первый метод возвращает число элементов в меню. Если значение возвратилось, положительно, меню изменено или удаляющими или добавляющими элементами. При возврате отрицательной величины число элементов оставлено без изменений, и метод обновления не вызывают. Недавно создаваемые элементы являются пробелом. Тогда второй метод неоднократно вызывают для каждого элемента, в котором времени, и т.д. может быть обновлен заголовок меню, изображение. Если во время обновления, пользователь сделает что-то так, чтобы меню больше не выводилось на экран, то shouldCancel paramter будет установлен в YES. Можно проигнорировать флаг или прекратить обновлять и сохранить, где Вы кончили до следующего раза.

Если делегат реализует метод:
- (BOOL)menuHasKeyEquivalent:(NSMenu*)menu forEvent:(NSEvent*)item target:(id*)target action:(SEL*)action;
Этот метод позволяет делегату возвращать цель и действие для ключа вниз событие. Метод должен возвратить YES, если был бы допустимый и включенный элемент для ключевого события и возвратил бы цель и действие (оба из которых могут быть нолем / NULL для вызова цели и действия меню). Если этот метод не будет определен в делегате, то меню будет заполнено, чтобы узнать, имеют ли какие-либо элементы соответствующий ключевой эквивалент. Делегат должен возвратиться НЕ, если бы нет никаких элементов с тем ключевым эквивалентом, или элемент был бы отключен.

Поскольку приложения основывались на Пантере или позже, отслеживание меню теперь выполнит runloop в NSEventTrackingRunLoopMode, а не NSDefaultRunLoopMode. Это является соответствующим отслеживанию в других средствах управления и решает проблему, где приложение могло заставить меню застревать на экране путем прерывания runloop неожиданно, например, путем подъема модальной панели, в то время как пользователь отслеживал в меню. Это изменение означает, что таймеры и другие runloop источники, добавленные только для NSDefaultRunLoopMode, не будут стрелять во время отслеживания меню. Если Вы хотите, чтобы Ваш таймер продолжал стрелять во время отслеживания меню, необходимо также добавить его к runloop для NSEventTrackingRunLoopMode. Один простой способ сделать это должно использовать kCFRunLoopCommonModes, несмотря на то, что это также имеет эффект включения Вашего runloop источника в то время как в NSModalPanelRunLoopMode.



Делегация и уведомление

С классами AppKit, предоставляющими делегации и уведомлению (такому как NSWindow), если Вы явно регистрируетесь для определенных уведомлений, также использующихся для отправки сообщений делегата, и затем Вы прекращаете быть делегатом, Вы не зарегистрированы для тех уведомлений. Не ясно, как это будет адресоваться в будущем, но необходимо знать об этом потенциально неожиданном поведении.


NSColor

Можно определить оттенок управления существующей системой при рендеринге цветов при помощи метода класса NSColor.
+ (NSControlTint)currentControlTint;
Этот метод будет в настоящее время возвращать или NSBlueControlTint или NSGraphiteControlTint.

Метод selectedMenuItemColor теперь возвращает изображение образца на основе текущего появления (синий или графитовый), а не сплошной цвет.

- [Набор NSColor] больше не разделяет прозрачность, когда вывод идет в устройство кроме экрана (например, принтер или файл). Обратите внимание на то, что это изменение было представлено в обновлении программного обеспечения Ягуара 10.2.3; и это активно только для приложений, соединенных на 10,2 или позже. Однако приложение может принять решение вызвать поведение так или иначе путем регистрации NSAllowTransparencyWhenPrinting по умолчанию в YES или НЕТ.

+ [NSColor disabledControlTextColor] теперь возвращает 50%-го белого, а не 53%-го белого.

Теперь возможно установить цвета заливки и цвета обводки независимо с NSColor с setFill и setStroke методами. Метод установки продолжает устанавливать обоих. Продвижение, все три должны быть обработаны как примитивы---т.е. методы, которые должны быть реализованы подклассификаторами. Для совместимости существуют реализации setFill и setColor в NSColor, но они работают путем преобразования цвета в RGB и заполнения или перечеркивания его.

NSColor внедрил новый метод, возвращающий стандартный список чередования цветов, используемых многими приложениями, такими как iTunes. NSTableView добавил прямую поддержку рисования ее фона с помощью этих цветов. Однако те, которые реализуют пользовательскую строку, базировались, средства управления могут использовать этот новый API для рисования переменного фона:
+ (NSArray *)controlAlternatingRowBackgroundColors;

NSColorPanel

Цветная панель может теперь вывести на экран произвольную информацию об авторском праве для списка цветов. Для предоставления информации авторского права просто добавьте, что ключ NSColorListCopyrightInfo к спискам цветов представляет файл в виде строки (например, MyColorList.clr/English.lproj/MyColorList.strings).


NSColorWell

До Пантеры, иногда просто нажав на цвет хорошо заставил бы его действие быть отправленным. Это было фиксировано. NSColorWell теперь только отправляет свое действие, если действительно изменился цвет, который он содержит.

Вызов активируется: программно теперь правильно показывает цветную панель, если это уже не видимо.


NSImage

Проблема, где рендеринг NSImage в другой lockFocus'ed NSImage мог вытереть состояние графики, устранена.

Ограничение на размер NSCachedImageRep и таким образом NSImage, что Вы-lockFocus на были повышены от 10 000 до 32 767. Обратите внимание на то, что Вы отображаете ниже этого размера, может все еще перестать работать из-за ограничений памяти.


NSImageRep

NSImageRepRegistryDidChangeNotification теперь содержит фактический класс NSImageRep, добавленный или удаленный вместо получателя сообщения, которое обычно было основным классом NSImageRep.


NSBitmapImageRep

Можно теперь считать и записать 5 каналам изображения CMYKA.

Если анимированное изображение GIF содержит информацию, указывающую число раз для игры GIF, новое свойство доступно как значение только для чтения.
NSString* NSImageLoopCount;
Если установлено, расширение имело явное указанное значение. Значение количества цикла будет между 0 и 65,535 со значением 0 циклов значения навсегда. Если свойство не присутствует, оно не было указано в файле, и это будет до приложения для решения, сколько раз циклично выполниться

Файлы PNG теперь имеют корректный размер и набор DPI, базируемый в блоке 'физики' в файле. Это только применяется к приложениям, скомпилированным после Ягуара (10.2.x).


NSImageView


Экземпляры NSImageView могут теперь автоматически воспроизвести анимированные изображения GIF. Этой функциональностью управляет новое средство доступа API:
- (void)setAnimates:(BOOL)flag;
- (BOOL)animates;
NSImageView, чей «анимирует» свойство, установлен в YES, будет автоматически играть любое изображение с анимацией, присваивающееся ему с характеристиками синхронизации и цикличного выполнения, указанными данными изображения. То, когда «анимирует», установлено в нет, NSImageView выводит на экран первый кадр анимации (соответствующий поведению на Ягуаре и ранее). Значением по умолчанию является YES для недавно создаваемых экземпляров NSImageView, НЕТ для ранее создаваемых объектов NSImageView, загруженных из .nib файлов.

Эта установка не влияет на дисплей обычных неподвижных изображений.

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


NSView

На Ягуаре и ранее, области представления, отмеченные грязное использование-setNeedsDisplayInRect: объединяются (через операцию NSUnionRect()) в единственный «dirtyRect», который поддерживает представление. Когда лишенные законной силы области распространены по мере необходимости наследователям и потомкам каждого представления и-drawRect, получение, таким образом запланированное, сделано позже в конце цикла цикла выполнения: вызывается для каждого представления, которое должно привлечь некоторых или все его содержание.

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

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

- drawRect: остается переопределяемые «рисуют сам» обратный вызов для классов представления. Однако конструктор-drawRect: может теперь перезвонить к сам, чтобы запросить более подробное описание области быть составленным, чем единственный параметр NSRect к-drawRect: обеспечивает. В частности можно запросить список прямоугольников, более близко приближающий область, которой нужно получение через новый метод:
- (void)getRectsBeingDrawn:(const NSRect **)rects count:(int *)count;
По возврату из этого метода *rects содержит указатель на список значений NSRect, и *, количество является числом прямоугольников в списке. В зависимости от его стратегии получения,-drawRect: реализация может проверить этот список непосредственно для определения, что нарисовать, или это может использовать удобный метод:
- (BOOL)needsToDrawRect:(NSRect)aRect;
протестировать отдельные объекты, которые будут нарисованы по одному против списка.-needsToDrawRect: возвраты YES, если настороженный пересекают любой из прямоугольников в списке, НЕТ иначе. Использование этого удобного метода было бы подходящим для представления, определяющего, что нарисовать путем простой итерации по списку или иерархии drawable объектов. Представление, которое может эффективно определить, какой из его элементов должен быть нарисован как функция данного прямоугольника (такого как представление, выводящее на экран изображение или изображения или регулярную сетку объектов) может лучше подходить для проверки списка rect непосредственно. Обратите внимание на то, что параметр NSRect, что-drawRect: получает остается потенциально полезным как полный ограничительный прямоугольник, окружающий область, которая будет нарисована. Тесты на пересечение против этого прямоугольника могут быть выполнены как быстрое «тривиальное отклонение» тест, идентифицировав объекты, которые являются ясно вне области, которая будет нарисована.-needsToDrawRect: использование эта стратегия в ее реализации.

Для гарантии совместимого поведения получения для существующих классов представления AppKit по умолчанию осуществляет отсечение к области, которой нужно получение. На Ягуаре и ранее, отсечение было осуществлено более свободно к параметру NSRect-drawRect:.

Представление, не хотящее значение по умолчанию, AppKit-предоставленное отсечение (также, потому что его-drawRect: реализация очень старается нарисовать только в требуемой области, или потому что это устанавливает свое собственное отсечение), может отказаться от отсечения значения по умолчанию путем переопределения нового метода-wantsDefaultClipping для возврата НЕТ:
- (BOOL)wantsDefaultClipping;
Реализация по умолчанию, предоставленная NSView, возвращает YES. Любое представление, возвращающееся НЕ для этого метода, ответственно за установку его собственного отсечения, или так как иначе обеспечение, чтобы это не рисовало вне требуемой области. Представление наследуется только независимо от того, что отсечение предоставлено его самым близким наследователем, самостоятельно не предшествующим AppKit-предоставленному отсечению по умолчанию.


NSView имеет новый API, допускающий сокрытие отдельных представлений или всех поддеревьев представления. Скрытое представление остается в списке его суперпредставления подпредставлений и участвует в автоизменении размеров, но не выведено на экран и не получает входные события. Это упрощает замену старого метода удаления представления от его суперпредставления для «скрытия» его при предотвращении потери автоизменения размеров функциональности, от которой всегда страдал тот подход.

Сокрытием представлений управляют следующие новые методы NSView:
- (void)setHidden:(BOOL)flag;
- (BOOL)isHidden;
- (BOOL)isHiddenOrHasHiddenAncestor;
Для сокрытия представления Вы отправляете ему сообщение-setHidden:YES. AppKit отметит область, которую представление занимает в его суперпредставлении как нуждающийся в дисплее, и так как представление теперь скрыто, это не будет нарисовано, когда следующая передача получения произойдет, таким образом, исчезнет представление. Любой курсор rects, подсказка rects, или отслеживающий rects, которым владеет представление, будет отключен в течение времени, представление скрыто.

Если представление, имеющее подпредставления, будет скрыто, то его подпредставления и их потомки будут эффективно скрыты также с теми же последствиями, применяющимися к их курсору/подсказке/отслеживанию rects и возможности получить входные события. Отметьте, однако, что-isHidden только возвращает YES для представления, которое самостоятельно было явно скрыто через-setHidden: API. Для задавания более широкого вопроса того, стало ли представление эффективно скрытым, ли явно скрытый само или в результате наличия наследователя, который теперь скрыт, отправляют представлению сообщение-isHiddenOrHasHiddenAncestor.

Если сообщение-setHidden:YES вызывает представление, которое является текущим firstResponder окна для становления эффективно скрытым, nextValidKeyView сделан новым первым респондентом. Скрытое представление остается в nextKeyView цепочке, это было ранее частью, но проигнорировано в целях перемещения с помощью клавиатуры.

Для восстановления скрытого представления отправьте ему сообщение-setHidden:NO. Если представление не останется эффективно скрытым вследствие наличия скрытого представления наследователя, AppKit заставит его снова быть показанным и восстановит любой курсор rects, подсказка rects, и отслеживающий rects, что этому принадлежит.


На MacOS X версий до Пантеры, если границы NSVIEW изменяются (через один из-setBounds...: методы), возможность представления получения автоизменить размеры подпредставлений пожизненно нетрудоспособна. Пример этого поведения может быть замечен в TextEdit на Ягуаре. Если Вы включаете «Формат-> Обертка К Странице» и затем устанавливаете увеличение во что-нибудь (даже 100%), границы NSClipView установлены. Если Вы тогда преобразовываете назад в режим «Wrap to Window», NSClipView больше автоматически изменяет размеры своих подпредставлений - протяжение окна покажет, что автоматически не изменен NSTextView.

Когда границы установлены на NSView, он создает матрицу преобразования для корректировки получения представления. Так как эта матрица преобразования может привести к повернутому представлению, правила для знания, как автоизменить размеры подпредставления, неизвестны, таким образом NSView просто выключает то поведение.

Для приложений, соединенных на Пантере, было скорректировано это поведение так, чтобы, если матрица преобразования эффективно возвращается к матрице «идентификационных данных» (никакое деформирование) автоизменили размеры поведения подпредставлений, становится включенным снова.


Можно спросить представление, если это должно стать ключевым представлением на основе текущего режима UI клавиатуры (только все средства управления/текстовое поле). Вы не должны переопределять этот метод. Используйте - [NSView acceptsFirstResponder] для того случая.
- (BOOL)canBecomeKeyView;

NSView / NSCell - Фокусирующее кольцо, Получающее API

NSView и NSCell представили API, позволяющий разработчикам управлять получением фокусирующего кольца. В частности можно отключить получение фокусирующего кольца представления путем переопределения-focusRingType или вызова-setFocusRingType: с NSFocusRingTypeNone. Необходимо только отключить представление из рисования его фокусирующего кольца в ограниченных ситуациях. Обычно Вы могли бы сделать так, потому что Вы хотите нарисовать свое собственное фокусирующее кольцо, или потому что нет достаточного пространства для отображения фокусирующего кольца в расположении по умолчанию. Эта установка архивируется в перьях старого и нового стиля.


NSCell

Если Вы установите объектное значение ячейки с классом, реагирующим на селекторный-attributedStringValue, то ячейка будет использовать тот метод для выборки строки для рисования вместо того, чтобы использовать-stringValue.

Числа оттенка управления для синего (NSBlueControlTint) и графита (NSGraphiteControlTint) оттенки были добавлены к перечислению NSControlTint. Можно использовать их в сочетании с + [NSColor currentControlTint] для определения цвета для рендеринга пользовательских элементов управления.

NSMiniControlSize, новый размер управления, которое меньше, чем NSSmallControlSize, были добавлены к перечислению NSControlSize. NSCell и его подклассы и NSProgressIndicator, NSScroller и NSTabView примут этот новый размер.


NSButtonCell

Вызов - [NSButtonCell setImageDimsWhenDisabled:] был бы проигнорирован, и изображение будет всегда представлять, потускнел. Если флаг установлен в НЕТ, это теперь проверяет флаг и не потускнеет изображение.

Были добавлены несколько новых стилей внешней панели кнопки:

NSTexturedSquareBezelStyle заставит Вас стиль внешней панели использовать, который является подходящим для текстурированных (металлических) окон.

NSDisclosureBezelStyle поддерживает треугольник раскрытия как тот в NSOutlineView. Можно создать треугольник раскрытия путем установки стиля внешней панели кнопки в NSDisclosureBezelStyle и типа кнопки к NSOnOffButton.

NSHelpButtonBezelStyle был добавлен для обеспечения стандартного вида кнопки справки.


NSTextFieldCell

Новый API для NSTextFieldCell позволяет Вам указывать строку, чтобы нарисовать, если строковое значение ячейки текстового поля пусто, и ячейка текстового поля не редактирует. Если фактическое строковое значение является нолем или «», эта строка никогда не появляется как строковое значение ячейки, но используется на этапах получения. Строка обычного текста будет нарисована в сером. Эта строка не архивируется в старом формате пера. Установка приписанной строки убирает строку обычного текста и наоборот.
@interface NSTextFieldCell
- (void)setPlaceholderString:(NSString*)string;
- (NSString*)placeholderString;
- (void)setPlaceholderAttributedString:(NSAttributedString*)string;
- (NSAttributedString*)placeholderAttributedString;
@end

NSScrollView

Начиная с Пантеры, NSScrollView можно попросить автоматически скрыть его скроллеры, когда они не необходимы. Прочь по умолчанию, этим поведением можно управлять через следующий новый API:
- (BOOL)autohidesScrollers;
- (void)setAutohidesScrollers:(BOOL)flag;
Поскольку показ и сокрытие его скроллеров вызывают NSScrollView к перемозаике, использование этой функции в контекстах, где другой механизм конкурирует за управление размера представления документа, не рекомендуется. В частности когда включение представления документа, NSScrollView установлен автоматически скрыть свои скроллеры, представление документа, не должно быть установлено автоизменить размеры. AppKit избежит потенциальных рекурсий, которые могли бы возникнуть в результате, но это может препятствовать тому, чтобы скроллер автоскрылся работать должным образом на такие представления.

Предыдущая пустая реализация-toggleRuler: был удален из NSScrollView. Тупиковая реализация, предназначенная, чтобы помочь гарантировать совместимость для приложений перед Mac OS X, использовавших осуждаемый класс представления линейки, была удалена, чтобы препятствовать тому, чтобы он блокировал цепочку респондента для приложений, хотевших обработать это сообщение.

При использовании NSClipView в NSScrollView (обычная конфигурация для использования NSClipView), разработчики должны выпустить сообщения что фон управления, получающий состояние к NSScrollView, вместо того, чтобы передать NSClipView непосредственно. Эта рекомендация применяется к следующим сообщениям:
- (void)setBackgroundColor:(NSColor *)color;
- (NSColor *)backgroundColor;
- (void)setDrawsBackground:(BOOL)flag;
- (BOOL)drawsBackground;
Несмотря на то, что NSClipView обеспечивает тот же набор методов, они предназначаются прежде всего для того, когда NSClipView используется независимо от содержания NSScrollView. В обычном случае NSScrollView нужно разрешить управлять рисующими фон свойствами его связанного NSClipView.

Предыдущая документация не ясно давала понять это, но отмечала, что существует только один набор рисующего фон состояния на пару NSScrollView/NSClipView. Два объекта не поддерживают независимый и отличный drawsBackground и backgroundColor свойства; скорее средства доступа NSScrollView для этих свойств в основном подчиняются связанному NSClipView и позволяют NSClipView поддерживать состояние. В Ягуаре и более ранних версиях системы, возможно, казалось, что NSScrollView и его NSClipView действительно поддерживали отдельное состояние для drawsBackground свойства, так как NSScrollView поддержал кэш последнего состояния, которое это установило для его NSClipView, который мог стать из синхронизации, если бы NSClipView был отправлен setDrawsBackground: обменивайтесь сообщениями непосредственно. Это кэширование состояния было удалено у Пантеры. Однако остается важным отметить что отправка setDrawsBackground: сообщение с параметром НЕ к NSScrollView, а не непосредственно к его вложенному NSClipView, имеет добавленный эффект отправки NSClipView setCopiesOnScroll: сообщение с параметром НЕ (как задокументировано). Побочный эффект исключения этого шага является появлением «следов» (остатки предыдущего получения) в представлении документа, когда это прокручивается.

Таким образом общая рекомендация состоит в том, чтобы отправить запросы, имеющие отношение к фоновому состоянию рисования к включению NSClipView NSScrollView (когда существующий), и позвольте NSScrollView управлять состоянием NSClipView.


NSMovie

Если Вы явно создаете NSMovie использование-initWithMovie: когда NSMovie будет освобожден, метод, DisposeMovie больше не будут вызывать на фильме. Фильмы, создаваемые через URL или область монтажа, будут все еще расположены. Это изменение будет только влиять на приложения, скомпилированные у Пантеры или позже.


NSStatusItem

Для стандартных элементов строки состояния можно теперь установить дополнительное изображение, выведенное на экран, когда элемент выделяется на отслеживании мыши.
- (void)setAlternateImage:(NSImage*)image;
- (NSImage*)alternateImage;
Для пользовательских элементов строки состояния представления существует два новых метода, чтобы помочь эмулировать стандартные товары. Первый метод нарисует фоновый образец меню в элементе состояния пользовательское представление в регулярном или выделит образец.
- (void)drawStatusBarBackgroundInRect:(NSRect)rect withHighlight:(BOOL)highlight;
Это выведет на экран меню под пользовательским элементом состояния.
- (void)popUpStatusItemMenu:(NSMenu*)menu;

NSOpenGLContext, NSOpenGLPixelFormat

NSOpenGLContext и NSOpenGLPixelFormat имеют новые средства доступа, которые можно вызвать для получения базовых объектов CGL. Можно тогда использовать API CGL для работы с этими объектами непосредственно.

NSOpenGLContext обеспечивает:
- (void *)CGLContextObj;        /* cast the return value to a CGLContextObj */
Точно так же NSOpenGLPixelFormat добавляет средство доступа:
- (void *)CGLPixelFormatObj;    /* cast the return value to a CGLPixelFormatObj */

NSWorkspace

NSWorkspace теперь имеет API для вводных файлов и запускающихся приложений с большим количеством опций запуска LS. Следующий API был добавлен:
- (BOOL)launchAppWithBundleIdentifier:(NSString *)bundleIdentifier
options:(NSWorkspaceLaunchOptions)options
additionalEventParamDescriptor:(NSAppleEventDescriptor *)descriptor
launchIdentifier:(NSNumber **)identifier;
- (BOOL)openURLs:(NSArray *)urls
withAppBundleIdentifier:(NSString *)bundleIdentifier
options:(NSWorkspaceLaunchOptions)options
additionalEventParamDescriptor:(NSAppleEventDescriptor *)descriptor
launchIdentifiers:(NSArray **)identifiers;
NSWorkspaceLaunchOptions может быть найден в NSWorkspace.h. Кроме того, NSWorkspace теперь имеет API для получения абсолютного пути от идентификатора пакета:
- (NSString *)absolutePathForAppBundleWithIdentifier:(NSString *)bundleIdentifer;
В NSWorkspaceDidLaunchApplicationNotification был добавлен новый постоянный NSApplicationBundleIdentifier.

NSWorkspace теперь обеспечивает уведомления сна. NSWorkspaceWillSleepNotification и NSWorkspaceDidWakeNotification будут отправлены передо снами машины и после следов машины, соответственно. Наблюдатель NSWorkspaceWillSleepNotification может задержать сон в течение максимум 30 секунд в обработке уведомления.

Мы добавили уведомления NSWorkspaceSessionDidBecomeActiveNotification и NSWorkspaceSessionDidResignActiveNotification NSWorkspace для приложений, которые должны знать, что сеанс переключается (иначе «быстрое переключение между пользователями»). Например, приложение может решить отключить некоторую обработку, когда ее сеанс пользователя выключается, и повторно включите, когда тот сеанс вкладывает переключенный назад. Такое приложение должно зарегистрироваться для этих уведомлений.

Кроме того, если приложение запускается в неактивном сеансе и регистрах для этих уведомлений, NSWorkspace отправляет NSWorkspaceSessionDidResignActiveNotification после отправки NSApplicationWillFinishLaunching и прежде, чем отправить NSApplicationDidFinishLaunching.



NSProgressIndicator

Мы добавили новый индикатор хода выполнения вращения большего размера, соответствующий NSRegularControlSize. Исходный индикатор меньшего размера теперь соответствует NSSmallControlSize. Если Ваше приложение будет соединено против чего-нибудь перед Пантерой, то мы будем всегда возвращать меньший размер для обеспечения совместимости на уровне двоичных кодов.


NSPasteboard

NSPasteboard автоматически сделал «простые доступные данные» типа области монтажа ASCII NeXT, когда приложения Углерода поместили 'TEXT' на область монтажа, несмотря на то, что использование этого типа публично не поддерживалось перед Mac OS 10.0. NSPasteboard больше не гарантирует, что этот тип доступен на областях монтажа. Используйте NSStringPboardType вместо этого.

Когда элементы NSRTFPboardType были помещены на область монтажа, в Mac OS 10.2, NSPasteboard начал автоматически обеспечивать Углерод kScrapFlavorTypeUnicode ('utxt') и kScrapFlavorTypeUnicodeStyle ('ustl') данные. 'utxt', что NSPasteboard, предоставленный всегда, начинался с метки порядка байтов (BOM) Unicode, которая допустима. К сожалению, много приложений Углерода не смогли должным образом обработать BOM. Начиная с 10.2.3, 'utxt', который NSPasteboard автоматически не обеспечивает больше, начинается с BOM. Однако, потому что обеспечение BOM является в конечном счете правильным решением, мы действительно намереваемся возвратить его в будущем выпуске.


NSPrintInfo

В Mac OS 10.2, - [NSPrintInfo setPaperSize:] начал тихо игнорировать любой формат бумаги, не соответствовавший ни одного из форматов бумаги, поддерживаемых текущим выбранным принтером. Эта ошибка была исправлена 10.2.3.

В Mac OS 10.2, - [NSPrintInfo setPaperSize:] начал тихо игнорировать любой формат бумаги, который был повернутым вариантом формата бумаги, поддерживаемого текущим выбранным принтером. Эта ошибка была исправлена 10.2.3.

Строка, возвращенная - [NSPrintInfo paperName], обычно не подходит для представления пользователю. Например, когда пользователь указал «Букву» в NSPageLayout, «na-буква» очень часто возвращается. Поскольку для некоторых приложений нужно к именам данной работы к пользователю, новый метод был добавлен к NSPrintInfo:
- (NSString *)localizedPaperName;

NSDocument

- [NSDocument lastComponentOfFileName] теперь возвращает то же самое значение, что-displayName был бы. Допустимое значение для свойства «имени» документа теперь всегда возвращается к сценариям.

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

- [NSDocumentController openDocumentWithContentsOfFile:display:] теперь вызывается с дисплеем: параметр YES вместо НЕ, когда обрабатывается событие Print Documents Apple. Для документов, представляющих панель печати, поскольку лист (документ модально) там должен быть видимым окном документа, к которому может быть присоединен лист. Для документов, представляющих панель печати как диалоговое окно (приложение модально), окно документа обеспечивает индикацию относительно того, что будет распечатано, когда пользователь нажмет кнопку OK в панели печати.

В предыдущих версиях Какао не было никакого простого общедоступного способа управлять, какое окно документа мультиокна должно использоваться в качестве родительского окна листов, представленных тем документом. Поскольку существует общая потребность в этом, новый метод был добавлен к NSDocument:
- (NSWindow *)windowForSheet;
В предыдущих версиях Какао нумерация документов без названия была сделана таким способом, которым излишне большим количествам было свойственно появиться на имена дисплея документов без названия, например, «Неназванные 78». NSDocument теперь называет документы без названия таким способом, которым каждому новому документу без названия дают число, которое является одним большим, чем наибольшее число, используемое в ком-либо в настоящее время, открывается, неназванный, документ.

В предыдущих версиях Какао - [NSDocument writeWithBackupToFile:ofType:saveOperation:] привел бы к сбою, когда передано строку пути документа, содержавшую двоеточия. Поскольку двоеточия по путям стиля POSIX являются условно результатом пользователя, вводящего наклонную черту в пользовательском интерфейсе (или то из самого приложения или Средство поиска), эта ошибка появилась бы пользователю как отказ сохранить документы, имена которых содержали наклонные черты. Это было фиксировано.



NSWindow

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

Мы представили задержку перетаскивания от кнопки значка документа. Если Вы перетащите на кнопке значка документа без приостановки, то окно переместится. Если Вы щелкнете и пауза в течение 1/8 секунды, то кнопка значка документа станет источником перетаскивания. Когда задержка перетаскивания будет удовлетворена, кнопка значка документа будет выделена для указания. Кроме того, shift-drags предотвращения ограничения от кнопки значка документа был снят. Модификатор сдвига теперь проигнорирован для кнопки значка документа, перетаскивает.

Функциональность-setMiniWindowImage: был повторно включен для приложений, соединенных на Пантере или позже. Ранее, по причинам совместимости, специальное значение по умолчанию было необходимо для включения этого.

У нас теперь есть метод, чтобы позволить делегату окна указывать пользовательское расположение листа. Большая часть настройки включает просто вертикальное смещение, но некоторые приложения также хотят управлять горизонтальным расположением в окне. Некоторые приложения могли бы хотеть управлять шириной запуска эффекта листа также. Например, это могло бы быть целесообразно заставлять лист появиться, как будто это происходило из кнопки или другого виджета. Обратите внимание на то, что это обычно - свойство родительского окна, но может также зависеть от типа представляемого листа.
@interface NSObject(NSWindowDelegate)
- (NSRect)window:(NSWindow *)window willPositionSheet:(NSWindow *)sheet usingRect:(NSRect)rect;
...
@end
Этот метод будет отправлен делегату окна прежде сначала анимировать лист, а также любое окно времени изменено, в то время как присоединяется лист. Возвращенный NSRect указывает строку, в которой главный край листа должен быть присоединен к окну с источником в координатах окна и rect.size.width указание ширины начальной анимации. Если rect.size.width будет более широким, чем лист, то лист выскользнет. Если rect.size.width будет более узким, чем лист, то лист будет джин из данного rect. Вершина листа будет центрироваться в данном rect. Обратите внимание на то, что rect.size.height не будет в настоящее время влиять на тот размер анимации, но будет использоваться для определения центра rect.

NSWindow теперь имеет методы, действительно измеряющие вычисления с точки зрения содержания, а не структурирующие метрики. Это позволяет спецификацию размера содержания окна, который особенно полезен в окнах, которые могут иметь видимую панель инструментов.
- (NSRect)frameRectForContentRect:(NSRect)contentRect
- (NSRect)contentRectForFrameRect:(NSRect)frameRect
Следующие методы предпочтены по основанным на кадре методам, но основанные на кадре методы будут продолжать работать, если не будут использоваться основанные на содержании методы:
- (void)setContentMaxSize:(NSSize)aSize
Вышеупомянутый метод устанавливает максимальный размер, к которому кадр contentView получателя может быть измерен к судебному разбирательству. Максимальное ограничение размера осуществляется для изменения размеров пользователем, а также для setFrame... методы кроме setFrame:display:. Имеет приоритет по setMaxSize:.
- (NSSize)contentMaxSize
Возвращает максимальный размер кадра contentView получателя.
- (void)setContentMinSize:(NSSize)aSize
Устанавливает минимальный размер, к которому кадр contentView получателя может быть измерен к судебному разбирательству. Минимальное ограничение размера осуществляется для изменения размеров пользователем, а также для setFrame... методы кроме setFrame:display:. Имеет приоритет по setMinSize:.
- (NSSize)contentMinSize
Возвращает минимальный размер кадра contentView получателя.
- (void)setContentAspectRatio:(NSSize )ratio
Устанавливает форматное соотношение размера содержания получателя в отношение, ограничивая размер его прямоугольника содержания к интегральной сети магазинов этого размера, когда пользователь изменяет размеры его. Можно установить размер NSWINDOW в любое отношение программно. Имеет приоритет по-setAspectRatio:.
- (NSSize)contentAspectRatio
Возвращает форматное соотношение размера содержания получателя.
- (void)setContentResizeIncrements:(NSSize)increments
Наборы, которые получатель изменяет размеры инкрементов к инкрементам, ограничивая ширину и высоту прямоугольника содержания изменять интегральной сетью магазинов increments.width и increments.height, когда пользователь изменяет размеры его. Можно установить размер NSWINDOW в любую ширину и высоту программно. Имеет приоритет по-setResizeIncrements:.
- (NSSize)contentResizeIncrements
Вышеупомянутый метод возвращается, содержание получателя изменяют размеры инкрементов.

Время по умолчанию для листа и окна изменяет размеры анимации, был сокращен, таким образом, эффекты произойдут более быстро. Если необходимо настроить эту анимацию, чтобы быть медленнее (или быстрее) в подклассе окна, можно переопределить-animationResizeTime: и настройте значение, полученное из супер.

Мы фиксировали-setIgnoresMouseEvents: так, чтобы это работало более надежно на непрозрачные окна, хотящие быть очевидными для событий от нажатия мыши, и также работает на прозрачные окна, хотящие получить события от нажатия мыши. В Ягуаре этот API только несколько работал на игнорирование событий и не работал вообще для получения событий от нажатия мыши в прозрачных окнах. Эта фиксация применяется только к приложениям, основывался на Пантере или позже.

Мы больше не игнорируем NSMiniaturizableWindowMask для неактивации служебных окон. Если этот styleMask установлен на окне утилиты неактивации в приложении, основывался на Пантере или позже, то окно получит кнопку свертывания окна. Мы будем продолжать запрещать кнопку свертывания окна на других типах служебных окон.

На Ягуаре и предыдущих системах, - [NSPanel orderFront:] вел бы себя как-orderFrontRegardless: означая, что NSPanel был бы выявлен его уровня окна, было ли его приложение владения активно. У Пантеры мы удалили это различие для немодального NSPanels. NSPanel и NSWindow теперь ведут себя то же в который orderFront: если активное окно будет принадлежать другому приложению, упорядочит панель или окно позади активного окна. Для совместимости это изменение применяется только к приложениям, основывался на Пантере или позже.


NSEvent

Методы экземпляра NSEvent теперь проверяют, что методы экземпляра отправляются в допустимые типы событий, поскольку приложения основывались на Пантере или позже. Это как документируется, но не было ранее осуществлено. Метод, отправленный в неправильный тип события, заставит исключение быть повышенным.

Правило поставки для событий NSScrollWheel было изменено так, чтобы события NSScrollWheel были отправлены в представление под мышью в ключевом или служебном окне. Если мышь не по ключевому или служебному окну, события NSScrollWheel отбрасываются. От событий NSScrollWheel можно все еще отказаться цепочка респондента от представления получения. Когда объединение события отключено, в 10,2, сервер окна начал устанавливать дополнительный зависящий от устройств флаг модификатора в событиях ввода данных пользователем для указания. Приложения, проверяющие на modifierFlags использование равенства, не маскируя от зависящего от устройств modifierFlags сначала, могут получить неожиданное поведение вследствие этого изменения. Для поддержания совместимости для приложений, основывался на Ягуаре и более ранних системах, NSEvent полосами по умолчанию этот зависящий от устройств флаг модификатора при создании события из windowServer события. Поскольку приложения основывались на Пантере или более поздних системах, это больше не будет поведением по умолчанию. Для переопределения поведения NSEVENT по умолчанию приложение может указать значение для пользовательского значения по умолчанию NSDeviceDependentModifierFlags. Если это значение по умолчанию будет установлено в то нет, зависящие от устройств флаги модификатора будут разделены.

NSApplication

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

Новые методы делегата были добавлены для открытия или печати многократных файлов сразу:
@interface NSObject(NSApplicationDelegate)
...
-(void)application:(NSApplication *)app openFiles:(NSArray *)fileList
-(void)application:(NSApplication *)app printFiles:(NSArray *)fileList
...
@end
Если делегат приложения реализует application:openFiles: этот метод вызовут вместо application:openFile:. Точно так же application:printFiles: будет вызван вместо application:printFile:.

Обратите внимание на то, что делегат, возможно, должен представить один или несколько листов при обработке этих методов. Также могут быть состояния ошибки. Это - ответственность делегата уведомить пользователя через ошибочную панель или другие средние значения в подходящих случаях. Делегат также будет ответственен за указание отказа или пользовательской отмены к отправителю AppleEvent, заставившего один из этих методов быть отправленным. Для создания ответа на AppleEvent простым, мы обеспечили обертку в NSApplication:
typedef enum NSApplicationDelegateReply {
NSApplicationDelegateReplySuccess = 0,
NSApplicationDelegateReplyCancel = 1,
NSApplicationDelegateReplyFailure = 2
} NSApplicationDelegateReply;
- (недействительный) replyToOpenOrPrint: (NSApplicationDelegateReply) ответ

Делегат должен вызвать этот метод, чтобы заставить набор управлять сообщением об ошибке в ответе AppleEvent. Если этот метод вызовут с NSApplicationDelegateReplyCancel, то userCanceledErr будет установлен в ответе AppleEvent. Если этот метод вызывают с NSApplicationDelegateReplyFailure, errAEEventFailed установлен в ответе AppleEvent. Делегат может также вызвать этот метод для сообщения об успехе, несмотря на то, что текущая реализация ничего не делает в ответ на это. Делегаты, хотящие управлять Событием Apple, отвечают себе, должен сделать настолько использующий NSAppleEventManager API и не должен вызывать этот метод.

В 10,3, если Вы передаете ноль-setApplicationIconImage: мы теперь установим значок панелей в изображение по умолчанию для приложения. Ранее это поведение было не определено.

Если будет приложение модальная открытая панель, обработчик AppleEvent для события 'выхода' теперь возвратит userCanceledErr.-applicationShouldTerminate не будет вызван на делегата приложения в этом случае. Одно последствие этого изменения - то, что о приложении с модальной открытой панелью теперь сообщат как отменяющий выход из системы. На предыдущих версиях системы такое приложение блокировало бы выход из системы, пока не была отклонена модальная панель.

Установки системы позволяют пользователям добавлять приложения на список Элементов Запуска и запускать те скрытые приложения. У Пантеры, и начиная с семени WWDC, NSApplication теперь осуществляет скрытую на запуске установку путем добавления окон, упорядоченных на экране во время запуска приложения к скрытому списку. Это включает любые немодальные окна, упорядоченные на экране до и включая время когда-applicationDidFinishLaunching: отправляется. Windows упорядочил на экране после того, как это время заставит приложение быть выведенным на экран. Для поддержания совместимости на уровне двоичных кодов с приложениями, которые могут не ожидать это поведение, скрытая на запуске установка только осуществляется для приложений, основывался на Пантере или позже. Приложения основывались на более ранних системах, будет, вероятно, видеть старое поведение, где окно, показанное во время запуска, временно высветится на экране, затем быть скрытым с приложением.

Новый API - [NSApplication orderFrontCharacterPalette:] добавляется.

AppKit теперь добавляет пункт меню «Special Characters...» к меню «Edit» если элемент с-orderFrontCharacterPalette: действие не найдено в меню. Для предотвращения поведения можно установить предпочтительную установку NSDisabledCharacterPaletteMenuItem в YES.



NSBox

Мы больше не архивируем или разархивировали contentView для NSBoxSeparator для включенного кодирования. contentView не имеет никакой цели для NSBoxSeparator.

В 10,3 мы задерживаем калибровку NSBox после разархивирования, пока это сначала не нарисовано. Это означает, что подпросматривает, которые изменяют размеры на основе размера поля, может быть изменен позже, чем они сделали на Ягуаре и предыдущих системах.

10.3 обеспечивает новое появление для NSBox. Типы поля NSBoxPrimary и NSBoxSecondary оба нарисуют со взглядом с отступом, улучшенным, но подобным до некоторой степени тому, как поля NSBoxSecondary привлекли Ягуар. Если для Вашего приложения нужен простой взгляд схемы, необходимо использовать NSBoxType NSBoxOldStyle и NSBorderType NSLineBorder. Рекомендуется использовать это только для полей без заголовков.


Перетаскивание

Локальный пул автовыпуска теперь установлен и выпущен вокруг вызовов метода NSDraggingDestination, поскольку приложения основывались на Пантере или позже. Это позволяет автовыпущенным объектам быть выпущенными во время перетаскивания, улучшающего использование памяти, но также и изменяющего время жизни некоторых объектов. Это изменение ограничивается приложениями, основывался на Пантере или позже по причинам совместимости.

Ошибка в генерации изображения перетаскивания привела бы к зеркально отраженному изображению (isFlipped: набор) попытка казаться незеркально отраженным, если источник кэшировался (т.е. не битовый массив). Изображение теперь появится в корректной ориентации. Это изменение будет только влиять на приложения, скомпилированные у Пантеры или позже.


NSCursor

Приложения основывались на Пантере или позже могут теперь использовать изображения курсора размеров кроме 16x16. Размер курсора будет определен размером изображения, переданного-initWithImage:hotSpot: или-initWithImage:foregroundColorHint:backgroundColorHint:hotSpot:. Приложения могут проверить на NSAppKitVersionNumber, больше, чем, или равняться NSAppKitVersionNumberWithCursorSizeSupport, чтобы определить, доступна ли эта поддержка.

NSCursor теперь обеспечивает новые курсоры для псевдонима, и копия перетаскивает, а также немного измененные курсоры для вертикального и горизонтального изменяют размеры. Мы также добавили дополнительные общедоступные курсоры:
+ (NSCursor *)pointingHandCursor;
+ (NSCursor *)closedHandCursor;
+ (NSCursor *)openHandCursor;
+ (NSCursor *)resizeLeftCursor;
+ (NSCursor *)resizeRightCursor;
+ (NSCursor *)resizeLeftRightCursor;
+ (NSCursor *)resizeUpCursor;
+ (NSCursor *)resizeDownCursor;
+ (NSCursor *)resizeUpDownCursor;
+ (NSCursor *)crosshairCursor;
+ (NSCursor *)disappearingItemCursor;

NSGraphics

Следующие функции были добавлены, чтобы отключить и повторно включить все получение на экран контекстом вызова:
void NSDisableScreenUpdates(void);
Предотвращает получение для всех окон, принадлежащих обработке вызовов от того, чтобы быть сброшенным до экрана. Эта функция разрешает операциям на многократных окнах казаться атомарными пользователю и особенно полезна для родительских и дочерних окон. Обратите внимание на то, что эта функция должна использоваться с заботой о коротких операциях только, поскольку система только позволит обновлениям быть отключенными в течение короткого времени (в настоящее время одна секунда) перед автоматическим перевключением обновлений.
void NSEnableScreenUpdates(void);
Повторно позволяет рисовать для всех окон, принадлежащих обработке вызовов. Вызовы к NSDisableScreenUpdates должны быть соответствующими вызовам к NSEnableScreenUpdates. Штабель множественных вызовов.



NSHelpManager

У нас теперь есть методы для поддержки поиска справки кроме из Меню справки. Когда кнопка Help нажимается, например, следующие методы поддерживают навигацию к определенному расположению в книге справки или запросы книги справки для строки.
- (void)openHelpAnchor:(NSString *)anchor inBook:(NSString *)book
Найдите и выведите на экран текст в данном расположении привязки в данной книге. Если ноль, все установленные книги справки ищутся, параметром должно быть локализованное название книги справки или ноль---. Это - обертка для AHRegisterHelpBook (который вызывают только один раз для регистрации книги справки, указанной в основном пакете приложения), и AHLookupAnchor.
- (void)findString:(NSString *)query inBook:(NSString *)book
Ищите данный запрос в данной книге. Если ноль, все установленные книги справки ищутся, параметром должно быть локализованное название книги справки или ноль---. Это - обертка для AHRegisterHelpBook (который вызывают только один раз для регистрации книги справки, указанной в основном пакете приложения), и AHSearch.


Доступность

Атрибут AXWindows приложения Элемент UI теперь возвращает список окна в z-порядке, грудь-спина.

AXWindows теперь поддерживают действие повышения, моделирующее перенос на следующий период окна путем щелчка по его строке заголовка.
NSAccessibilityRaiseAction
AXWindows теперь поддерживают подроли для различения различных типов окон.
NSAccessibilityStandardWindowSubrole
NSAccessibilityDialogSubrole
NSAccessibilitySystemDialogSubrole
NSAccessibilityUnknownSubrole
NSAccessibilityFloatingWindowSubrole
NSAccessibilitySystemFloatingWindowSubrole
Атрибут заголовка AXWINDOW раньше включал путь для окон с представленными файлами (согласно [заголовок NSWindow]). Это было теперь фиксировано так, они только возвращают выведенный на экран заголовок. Необходимо получить доступ к представленному файлу с атрибутом AXDocument.

AXWindows теперь поддерживают атрибуты для идентификации их значения по умолчанию и кнопок отмены.
NSAccessibilityDefaultButtonAttribute
NSAccessibilityCancelButtonAttribute
Когда AXDrawers и AXSheets создаются, Windows теперь испускает уведомления.
NSAccessibilityDrawerCreatedNotification
NSAccessibilitySheetCreatedNotification
AXScrollBars теперь представляют свои стрелки и страницу области up/down как AXButtons с подролями.
NSAccessibilityIncrementArrowSubrole
NSAccessibilityDecrementArrowSubrole
NSAccessibilityIncrementPageSubrole
NSAccessibilityDecrementPageSubrole

10.3 обеспечивает более мощные текстовые функции доступности. Много новых атрибутов были добавлены для AXTextAreas и AXTextFields для возврата более подробной информации о тексте в. Эти дополнения документируются в Доступность APIs.


Два новых метода были добавлены к протоколу доступности Какао для поддержки параметризованных атрибутов – один для возврата списка их и один для возврата их значений.
- (NSArray *)accessibilityParameterizedAttributeNames;
- (id)accessibilityAttributeValue:(NSString *)attribute forParameter:(id)parameter;
Новая функция была добавлена так, можно повысить ошибку, если параметр является неправильным типом или имеет недопустимое значение. Если попытка предпринята для установки значения атрибута с неправильным типом или недопустимого значения, эта функция может также использоваться для повышения ошибки.
void NSAccessibilityRaiseBadArgumentException(id element, NSString *attribute, id value);
Следующие константы были удалены:
NSAccessibilityWindowTitleRole
NSAccessibilityWindowProxyRole
NSAccessibilityRelevanceIndicatorRole
Следующие константы были добавлены:
NSAccessibilityCancelAction


NSSound

NSSound использует CoreAudio для игры большинства файлов в 10,3, но использует QuickTime для игры некоторых звуковых форматов, как звуки Музыкального магазина iTunes и общий URLs. В 10,2, NSSound прежде всего использовал QuickTime для игры звуков.

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

Так как QuickTime требует, чтобы цикл выполнения был выполнен для звука (или фильмы), чтобы продолжать играть, NSSound требует этого также. «Выполненным циклом», то, что предназначается, является циклом выполнения на потоке, запускающем звуковую игру. Для приложений Какао это не грандиозное предприятие для звуков, играемых на основном потоке, поскольку приложения Какао обычно позволяют AppKit обработать выполнение цикла выполнения на основном потоке. Кроме того, так как QuickTime не особенно ориентирован на многопотоковое исполнение, не рекомендуется играть звуки (или фильмы) на многократных потоках.

Делегат-sound:didFinishPlaying: также отправляется на основном потоке, когда он автоматически инициирован звуковым окончанием. Однако, когда - остановку вызывают, она сразу отправляется на том вызове потока - остановка. Таким образом, если каждый действительно все не звучит как игра и остановка на основном потоке, нельзя предположить, что метод делегата вызывают на основном потоке.

Выполнение всей звуковой игры на основном потоке также изолирует Вас лучше от будущих изменений в многопоточном поведении NSSound и базовых платформ.


Игра NSSound несколько раз одновременно

Приведенный пример NSSound может только играть, или нет. Если звук играет, и - игру вызывают, ничто не произойдет. Это было истиной в 10,2, и все еще верно в 10,3 и будет истиной в будущем. Однако различный экземпляр NSSound может играть тот же звуковой файл. Таким образом, если Вы хотите тот же звук, потенциально играл наложение, сделайте копию NSSound и играйте копию:
[[[mySound copy] autorelease] play];

NSBrowser

NSBrowser прокрутка теперь обеспечивает непосредственную и непрерывную обратную связь. Это, конечно, обеспечивает намного лучший пользовательский опыт, но также и потребовало некоторых существенных изменений. В частности внутренняя иерархия представления должна была измениться. Так, если у Вас есть подклассы NSBrowser или NSBrowserCell, зависящих от внутренней иерархии представления, необходимо быть на взгляде для несовместимостей. У Пантеры непрерывная прокрутка идет по умолчанию для всех приложений. Однако при необходимости, можно вернуться к старой реализации путем установки значения по умолчанию NSBrowserSupportsContinuousScrolling в НЕТ. Старая, ненепрерывная реализация прокрутки остается для совместимости и будет удалена в следующем выпуске.

Реализация непрерывной прокрутки имеет следующие импликации:

Внутренняя иерархия представления изменилась. Однако общедоступный API, торгующий геометрией браузера все еще, возвращает значения в координатах браузера. Например,-titleFrameOfColumn: и-frameOfColumn: возвратите прямоугольники относительно NSBrowser.

Переопределение-drawRect NSBROWSER: метод больше не очень полезен (вследствие новой иерархии представления).

-drawTitleOfColumn:inRect: 'inRect' параметр метода находится в координатах представления, составляющего заголовки. Вы не должны делать никакого преобразования для рисования.

Размер столбцов браузера может теперь варьироваться на один пиксель. Когда свободное место для обработки почвы столбца не может быть равномерно разделено на число видимых столбцов, это происходит.

Использование методов делегата-browserWillScroll: и-browserDidScroll: потребуйте некоторого объяснения. Ненепрерывная реализация отправила эти, делегат обменивается сообщениями каждый раз, когда новый столбец стал видимым. Однако с непрерывной прокруткой, частичные столбцы могут теперь быть видимы во время прокрутки. Непрерывная реализация прокрутки использует эти методы прежде и после того, как завершилась прокрутка. Так, эти методы больше не являются уведомлениями видимости.

Использование-scrollViaScroller: осуждается. Этот метод больше ничего не делает при использовании непрерывной реализации прокрутки

Использование-updateScroller осуждается. Этот метод больше ничего не делает при использовании непрерывной реализации прокрутки.

Отметьте, можно проверить на поддержку непрерывной прокрутки путем сравнения appkit номера версии с NSAppKitVersionNumberWithContinuousScrollingBrowser.


NSBrowser теперь обеспечивает три различных режима изменения размеров столбца: NSBrowserNoColumnResizing, NSBrowserAutoColumnResizing и NSBrowserUserColumnResizing. Для многих приложений автоматическое изменение размеров будет достаточно. В автоматическом изменении размеров каждому столбцу дают ту же ширину, вычисляющуюся с помощью combinination минимальной ширины столбца и макс. установки видимых столбцов. Некоторый applicaitons может решить, что они знают, как измерить столбцы лучше, чем NSBrowser или пользователь, и примут решение не использовать изменение размеров столбца. В режиме NSBrowserNoColumnResizing разработчик явно определит ширину каждого столбца, и ни пользователь, ни NSBrowser изменит присвоенную ширину. Наконец, NSBrowser позволяет режим изменения размеров столбца, позволяющий разработчикам выбирать начальную ширину столбца при разрешении пользователям опции изменить размеры столбцов во многом как, они могут в Средстве поиска.

Пользовательский режим изменения размеров столбца NSBrowsers (NSBrowserUserColumnResizing) и никакой режим изменения размеров столбца (NSBrowserNoColumnResizing) заслуживают немного дальнейшего объяснения, так как они являются новыми. Чрезвычайно автоматическое изменение размеров столбца совпадает со старым поведением браузера. Много новых методов и методов делегата были представлены для поддержки двух новых режимов. В первую очередь, существует новый API для указания типа изменения размеров столбца:
typedef enum _NSBrowserColumnResizingType {
NSBrowserNoColumnResizing = 0, /* Column sizes are fixed and set by developer. */
NSBrowserAutoColumnResizing = 1, /* No user resizing. Columns grow as window grows. */
NSBrowserUserColumnResizing = 2 /* Columns fixed as window grows. User can resize. */
} NSBrowserColumnResizingType;
- (void)setColumnResizingType:(NSBrowserColumnResizingType)columnResizingType;
- (NSBrowserColumnResizingType)columnResizingType;
- (void)setPrefersAllColumnUserResizing:(BOOL)prefersAllColumnResizing;
- (BOOL)prefersAllColumnUserResizing;
Затем, существует новый API и методы делегата, позволяющие Вам объявлять начальный размер для недавно посещаемого столбца браузера. Существует также API, позволяющий Вам непосредственно устанавливать ширину столбца:
- (void)setWidth:(float)columnWidth ofColumn:(int)columnIndex;
- (float)widthOfColumn:(int)column;
@interface NSObject (NSBrowserDelegate)
- (float)browser:(NSBrowser *)browser
shouldSizeColumn:(int)columnIndex
forUserResize:(BOOL)forUserResize
toWidth:(float)suggestedWidth;
- (float)browser:(NSBrowser *)browser
sizeToFitWidthOfColumn:(int)columnIndex;
@end
Наконец, существует новый API, чтобы сделать простую персистентность ширины столбца и новые уведомления, позволяющие Вам делать, более сложный путь базировал персистентность ширины столбца:
- (void)setColumnsAutosaveName:(NSString *)name;
- (NSString *)columnsAutosaveName;
+ (void)removeSavedColumnsWithAutosaveName:(NSString *)name;
APPKIT_EXTERN NSString * NSBrowserColumnConfigurationDidChangeNotification AVAILABLE_MAC_OS_X_VERSION_10_3_AND_LATER;
// Object : browser - the browser whose column sizes need to be persisted.
// UserInfo : No user info.
@interface NSObject (NSBrowserDelegate)
- (void)browserColumnConfigurationDidChange:(NSNotification *)notification;
@end

NSBrowser больше не теряет фокус во время reloadColumn: или loadColumnZero.

Выполнение selectAll: на матрице в браузере теперь работает. В прошлом только «загруженные» ячейки были бы частью выбора по окончании. Это было фиксировано. Так, как часть выбора все, ячейки загружаются при необходимости.

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

Существующий-maxVisibleColumn/setMaxVisibleColumns: проигнорированы и не применимые для использования браузера NSBrowserNoColumnResizing или типы NSBrowserUserColumnResizing.

Использование-displayColumn: осуждается. Используйте setNeedsDisplayInRect: с надлежащим прямоугольником вместо этого.

Использование displayAllColumns осуждается. Используйте setNeedsDisplay или setNeedsDisplayInRect: с надлежащим прямоугольником вместо этого.




NSBrowserCell

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

Для приложений, соединенных на или после Пантеры,-cellSize вычисление NSBrowserCell будет теперь включать ширину, требуемую для ее изображения и стрелки при необходимости. Приложения, соединенные в более ранних системах, будут все еще иметь старое ошибочное поведение. Старое поведение возвратило значение, которое было слишком маленьким, потому что изображение, стрелка и интервал не были изображены в размер нужной ячейки.


NSComboBox

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

NSComboBox может теперь быть выведен на экран без «границы» вокруг ее кнопки. Часто полезно в NSTableView, например, не вывести на экран границу кнопки. Для конфигурирования этой установки используйте новый API:
- (void)setButtonBordered:(BOOL)flag;
- (BOOL)isButtonBordered;

NSOutlineVIew

Треугольник раскрытия NSOutlineView теперь анимирует.

- (недействительный) collapseItem: (ID) элемент collapseChildren: флаг (BOOL) теперь фактически разрушится дочерние элементы, если спросили сделать так
- (ID) outlineView: (NSOutlineView *) olv itemForPersistentObject: если нулевое значение возвращается, объект (ID) больше не повышает исключение.

Сортировка UI - видит, что NSTableView «Сортирует UI» информация.



NSTabView

Для приложений, соединенных против Пантеры и позже,-tabViewItems теперь возвращает неизменный массив. Это, как всегда объявляли, возвратило неизменный массив, но до сих пор всегда возвращало непостоянный массив.

Когда NSTabViewItem будет удален из представления вкладки, его состояние будет теперь всегда устанавливаться в NSBackgroundTab.


NSTableView

NSTableView теперь реализует протокол NSUserInterfaceValidations, и в частности проверяет selectAll: цель/метод действия.

Если существует достаточно комнаты для отображения той, NSTableView и NSOutlineView рисуют индикацию клавиатурного фокуса. Индикация фокуса нарисована или вокруг представления прокрутки включения, или вокруг таблицы и заголовка (если не включенный в представление прокрутки). Если существует недостаточно комнаты для отображения большей части фокусирующего кольца, то ни один не показан.

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

Для приложений, соединенных против Пантеры или позже, NSTableView теперь возвращает YES из-needsPanelToBecomeKey. Это означает, что пользователи могут перейти к таблице с помощью ключа <tab>. Ранее, если Вы не разделили NSTableView на подклассы и переопределили этот метод, пользователь должен будет быть в «Любых Средствах управления» режимом перемещения с помощью клавиатуры, чтобы быть в состоянии <снабдить вкладками> к таблице. Если таблица находится в панели, возвращающей YES из becomesKeyOnlyIfNeeded, то этот needsPanelToBecomeKey для становления ключевыми возвратами YES, только если панель является в настоящее время ключевой. Путем выполнения этого щелчки в таких панелях не вынудят панель стать ключевой. Обратите внимание на то, что двойной щелчок в текстовой ячейке, чтобы начать редактировать вынудит панель стать ключевой.

NSTableHeaderView теперь ожидает до мыши, чтобы выбрать или отменить выбор столбца. Если пользователь щелкнул в ранее отменявшем заголовке, заголовок будет нарисован в нажатом (NSOnState), но не выбрал состояние до пользовательских мышей в ячейке заголовка. Среди прочего это означает, что столбец не должен быть выбран, чтобы быть перемещенным пользователем.

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

NSTableHeaderCell исправил ошибку с расположением ее изображения индикатора. До Пантеры индикатор отображает-setIndicatorImage:inTableColumn NSTableView использования набора: приведший к изображению, нарисованному слишком низко, такому, что только верхняя часть изображения была видима. NSTableHeaderCell теперь должным образом центрирует изображение. Изображению также позволили быть слишком близким к тексту заголовка. Это было фиксировано путем уменьшения ширины, доступной тексту заголовка. Оба фиксирует, применяются к приложениям, соединенным на Пантере и позже только.

Последний столбец таблицы NSTableView теперь рисует свое выделение столбца полностью до конца. Все другие столбцы оставляют маленький разрыв между выделениями столбца (если существует интервал межъячейки) путем окончания их выделения столбца за исключением фактического конца столбца.

NSTableView теперь кэширует результаты numberOfRowsInTableView: если это возможно. В прошлом NSTableView передал источник данных для этого значения беспорядочная сумма времен.


NSTableView теперь поддерживает рисование его фона с помощью стандартных переменных цветов, используемых многими приложениями, такими как iTunes. Новые флаги сохраняются во включенном archiver старого и нового стиля. Эта функция может быть принята во время проектирования IB, или во время выполнения с помощью следующего нового API:
- (void)setUsesAlternatingRowBackgroundColors:(BOOL)useAlternatingRowColors;
- (BOOL)usesAlternatingRowBackgroundColors;
NSTableView теперь представляет точку переопределения для разрешения полной фоновой настройки окраски. Для настройки фонового получения переопределите следующий новый API:
- (void)drawBackgroundInClipRect:(NSRect)clipRect;

NSTableView теперь обеспечивает, индекс установил базируемый выбор API, с помощью нового класса NSIndexSet:
- (void)selectColumnIndexes:(NSIndexSet *)indexes byExtendingSelection:(BOOL)extend;
- (void)selectRowIndexes:(NSIndexSet *)indexes byExtendingSelection:(BOOL)extend;
- (NSIndexSet *)selectedColumnIndexes;
- (NSIndexSet *)selectedRowIndexes;

Следующий неиндекс установил, базировался, APIs был осужден:
- (void)selectColumn:(int)column byExtendingSelection:(BOOL)extend;
- (void)selectRow:(int)row byExtendingSelection:(BOOL)extend;
- (NSEnumerator *)selectedColumnEnumerator;
- (NSEnumerator *)selectedRowEnumerator;

NSTableView теперь обеспечивает общую сортировку API на NSTableView, который сделает сортировку реализацией UI проще. API состоит из методов, которые позволят NSTableView автоматически управлять сортировкой UI и создавать дескрипторы вида, которые будут использоваться по условию источник, когда пользователь щелкнет по табличному заголовку. Данные не будут автоматически сортированы, но источник данных будет сказан, когда это должно будет обратиться свои данные.

Столбец таблицы считают поддающимся сортировке, если это он имеет sortDescriptorPrototype. Дескриптор вида содержит три данные: ключ, селектор и направление вида. Когда используется в качестве прототипа столбца, дескриптор вида определяет несколько интересных вещей. Во-первых, присутствие прототипа дескриптора вида указывает, что столбец является поддающимся сортировке. Затем направление вида прототипа определяет начальное направление сортировки. Наконец, ключевое и селекторное определение обеспечивают удобное расположение, чтобы хранить информацию, в которой источник данных будет нужен при сортировке. Обратите внимание на то, что не требуется, что ключ соответствует идентификатор столбцов таблицы, однако ключ должен быть уникальным от ключа, используемого другими столбцами.
// NSTableColumn.h
- (void)setSortDescriptorPrototype:(NSSortDescriptor *)sortDescriptor;
- (NSSortDescriptor *)sortDescriptorPrototype;
Учитывая таблицу с поддающимися сортировке столбцами, NSTableView будет автоматически управлять сортировкой UI. NSTableView автоматически выводит на экран индикатор вида для основного столбца вида. Для выполнения этого NSTableView ведет список дескрипторов вида. Первый дескриптор вида в списке определяет основной ключ сортировки, селектор и направление. Массив дескрипторов вида архивируется. Кроме того, массив дескрипторов вида сохранится вместе с другой информацией о столбце, если будет определено имя автосохранения.
// NSTableView.h
- (void)setSortDescriptors:(NSArray *)array;
- (NSArray *)sortDescriptors;
@end
Теперь, так как NSTableView не управляет данными, он не может сортировать если для Вас. Когда к данным нужно обратиться, Однако это действительно говорит Вам.
@interface NSObject (NSTableDataSource)
- (void)tableView:(NSTableView *)tableView sortDescriptorsDidChange:(NSArray *)oldDescriptors;
@end
@interface NSObject (NSOutlineDataSource)
- (void)outlineView:(NSOutlineView *)outlineView sortDescriptorsDidChange:(NSArray *)oldDescriptors;
@end
NSTableHeaderCell обеспечивает точки переопределения для настройки сортировки взгляд UI.-drawSortIndicatorWithFrame:inView:ascending:priority: вызывается для каждого столбца, участвующего в сортировке. Однако по умолчанию NSTableHeaderCell только рисует индикатор, если приоритет 0, т.е. если столбец является основным столбцом вида.
@interface NSTableHeaderCell
- (void)drawSortIndicatorWithFrame:(NSRect)cellFrame inView:(NSView *)controlView ascending:(BOOL)ascending priority:(int)priority;
- (NSRect)sortIndicatorRectForBounds:(NSRect)theRect;
@end

Сетка NSTableView, рисующая теперь, работает должным образом. Однако много перьев были бессознательно сохранены с, «рисует сетку» флаг, зарегистрировался в IB. Для предотвращения перекомпилировавший приложения, случайно показывающие сетки, старый флаг полностью проигнорирован. Это не грандиозное предприятие, так как флаг никогда не использовался так или иначе. Надлежащая архивация флага рисования сетки только поддерживается включенным archiver.

NSTableView теперь уважает альфу в цветах сетки.

NSTableView теперь позволяет намного более прекрасное управление рисованием сетки. В дополнение к рисованию полной сетки можно теперь принять решение провести линии сетки по вертикали или сетки по горизонтали только с помощью-setGridStyleMask: (интервал без знака) gridStyleMask API. Только перья, сохраненные с включенным archiver, сохранят эту информацию. Обратите внимание на то, что, с добавлением этого API, старая сетка, получающая API, становится избыточной, и была поэтому осуждена.

Эти методы были осуждены:
- (void)setDrawsGrid:(BOOL)drawGrid;
- (BOOL)drawsGrid;

NSTableColumn

Несмотря на то, что NSTableColumn соответствовал NSCoding в течение длительного времени, это теперь наконец объявляет это соответствие в своем заголовке.


NSToolbar

Элементы панели инструментов, имеющие NSBox как их представление, раньше вынуждали поле использовать NSNoBorder на панели инструментов и NSLineBorder в палитре настройки. NSToolbarItem больше не делает это.


NSToolbar теперь поддерживает отображение выбранного элемента панели инструментов на панелях инструментов, использующихся в качестве переключателей режима (например, инспекторы, цветная панель, и т.д...). Делегат панели инструментов должен реализовать-toolbarSelectableItemIdentifiers для указания, какой тип элементов панели инструментов может использоваться для указания режима. Обратите внимание на то, что, так как панели инструментов являются очень динамичными в своем содержании, выбор элемента сохраняется «идентификатором элемента», не элементом. NSToolbar поддерживает выбор автоматически для элементов типа изображения. Однако, идентификатор выбранного пункта может быть явно установлен во что-либо путем вызова-setSelectedItemIdentifier:.


Анимация «Гомосексуала»

Новая функция, NSShowAnimationEffect () был добавлен, чтобы позволить разработчикам использовать ту же анимацию удаления элемента, используемую средствами управления, такими как панель инструментов и прикрепление. Несмотря на то, что API разработан как общий механизм для системных эффектов анимации, в настоящее время только одна анимация существует. Для выполнения анимации Вы указываете тип анимации, которую Вы хотите, размер и расположение анимации и дополнительная информация об обратном вызове. Эффект NSAnimationEffectDisappearingItemDefault предназначается для указания удаления из списка, фактически не уничтожая базовый элемент. Например, удаление из прикрепления не удаляет файл. NSAnimationEffectPoof просто показывает исчезающее облако, эффект гомосексуала. В настоящее время NSAnimationEffectDisappearingItemDefault и NSAnimationEffectPoof являются тем же эффектом, но они, как гарантируют, не будут тем же в будущем.


ToolTips

Подсказки, которые являются слишком большими теперь автоматически, переносятся. Это может быть отключено путем установки NSToolTipAutoWrappingDisabled по умолчанию в YES.

До Пантеры, если бы пользователь активировал окно путем щелчка в области с подсказками, не были бы выведены на экран никакие подсказки, пока пользователь не переместил мышь из области подсказки и затем назад в той области. Эта ошибка была исправлена.


До Mac OS X 10.3, подсказки только выведены на экран в ключевом окне активного приложения. В Mac OS X 10.3, подсказки теперь всегда выводят на экран в активном приложении. Если Ваше приложение неактивно (или в фоновом режиме), Однако для подсказок причин производительности не активны. Это по причинам производительности. Если подсказки будут включены, то перемещение мыши по окну фонового приложения заставит приложение выполнять работу, которая может ухудшить производительность системы. Чтобы позволить Вашему приложению использовать подсказки, даже когда это - фоновое приложение, используйте следующий новый API:


@interface NSWindow (NSToolTip)
- (void)setAllowsToolTipsWhenApplicationIsInactive:(BOOL)allowWhenInactive;
- (BOOL)allowsToolTipsWhenApplicationIsInactive;
@end

NSBezierPath

Ошибка, вызывающая-appendBezierPathWithGlyphs:count:inFont: и-appendBezierPathWithPackedGlyphs: mehods для не усовершенствования после каждого глифа был фиксирован. Кроме того,-appendBezierPathWithGlyphs:count:inFont: больше не изменяет текущий графический контекст (он не вызывает - [Набор NSFont]). Это означает, что это - ответственность вызывающей стороны использовать шрифты с матрицей для зеркального отражения, когда зеркально отражается целевое представление.

Наконец, эти методы теперь перемещают текущую точку к базовой позиции последнего глифа. Другими словами, последовательные вызовы к этим методам правильно выравнивает глифы на базовой линии.



NSGraphicsContext

+saveGraphicsState и-saveGraphicsState больше не сохраняют текущий путь.


NSFormatter

Частичные методы проверки NSFORMATTER теперь правильно вызываются в конце отмеченного текстового сеанса. Если средство форматирования возвращается НЕ в этой ситуации и следовательно - [NSTextView shouldChangeTextInRange:replacementString:] возвраты нет, полевой редактор все еще удаляет диапазон текста в текущем отмеченном сеансе.



Чтение/Запись текстового документа

Метод был добавлен к NSMutableAttributedString:
- (BOOL)readFromData:(NSData *)data
options:(NSDictionary *)options
documentAttributes:(NSDictionary **)dict;
который параллелен существующему readFromURL:options:documentAttributes: но воздействует на содержание файла как данные вместо того, чтобы требовать, чтобы существовал файл. readFromURL:options:documentAttributes: метод обычно предпочтителен, если файл уже существует, так как это может использовать атрибуты файловой системы, такие как расширение и тип, чтобы помочь определить тип файла, но новый метод более удобен, если файл уже не существует, или если по некоторым причинам каждый не хочет, чтобы были учтены атрибуты файловой системы. В Java конструктор для NSAttributedString и NSMutableAttributedString, берущего два параметра, NSData и NSMutableDictionary, будет теперь использовать этот метод для построения приписанной строки из данных любого формата, который может считать текстовая система.

Новый тип текстового документа теперь поддерживается,
NSString *NSDocFormatTextDocumentType;
соответствие документам Microsoft Word. Эти документы могут быть считаны с помощью любого из существующих методов NSAttributedString/NSMutableAttributedString для чтения текстовых документов. Они могут быть также быть считанными и записанными с помощью новых методов NSAttributedString
- (id)initWithDocFormat:(NSData *)data documentAttributes:(NSDictionary **)dict;
- (NSData *)docFormatFromRange:(NSRange)range documentAttributes:(NSDictionary *)dict;
В настоящее время две новых главных версии формата поддерживаются для чтения (соответствующий примерно к Word 6 и позже), но только новая главная версия поддерживается для записи. Обратите внимание на то, что это не подразумевает поддержку всех функций, выразимых в таком документе, больше, чем существующее чтение RTF подразумевает поддержку всех функций, потенциально выразимых в RTF. Фактически, поддержка функции Какао чтения формата документа и записи очень почти эквивалентна ее поддержке RTF чтение и запись. Эта поддержка была, однако, улучшена для включения функций, описанных в разделы по дополнительным текстовым атрибутам и дополнительным функциям стиля абзаца.

«Преобразованному» ключу в словаре свойств документа дали иное толкование в пути, который является соответствующим его предыдущему определению. Ранее положительные значения указали, что документ был преобразован в формат, указанный службой фильтра, и все другие значения указали, что файл был первоначально в указанном формате. Это все еще имеет место, но теперь существует различие между отрицательными величинами и 0 (или не существующее). Теперь отрицательные величины подразумевают, что файл был первоначально в указанном формате, но что преобразование из формата, указанного к NSAttributedString, возможно, было с потерями. Кроме того, существует два новых ключа свойства документа: «DefaultTabInterval», указывающий интервал вкладки по умолчанию всего документа для документа. и «BackgroundColor», указывающий цвет фона всего документа для страниц.


Существует новый метод импорта NSAttributedString HTML,
- (id)initWithHTML:(NSData *)data options:(NSDictionary *)options documentAttributes:(NSDictionary **)dict;
это берет словарь опций как используемые другими подобными текстовыми методами импорта AppKit. В дополнение к соответствующим существующим ключам опций (BaseURL и CharacterEncoding) существуют некоторые новые ключи опций, предназначенные в частности для импорта HTML, который может использоваться с этим методом и с другими методами, берущими словарь опций:

«UseWebKit» (NSNumber, содержащий интервал; если существующий и положительный, используется основанный на WebKit импорт HTML сил; поведение, если это включено, может отличаться от того из импорта HTML в Mac OS X 10.2 и прежде, особенно для таблиц),
«TextEncodingName» (NSString, содержащий имя, IANA или иначе, текстового кодирования, которое будет использоваться, если кодирование не может быть определено из документа; взаимоисключающий с CharacterEncoding)
«Тайм-аут» (NSNumber, содержащий плавание; время в секундах для ожидания документа, чтобы закончить загружаться; если не существующий или не положительный, тайм-аут по умолчанию будет использоваться),
«WebPreferences» (WebPreferences; если основанный на WebKit импорт HTML используется, указывает объект WebPreferences; если не существующий, набор по умолчанию предпочтений будет использоваться),
«WebResourceLoadDelegate» (NSObject; если основанный на WebKit импорт HTML используется, указывает объект служить WebResourceLoadDelegate; если не существующий, делегат по умолчанию будет использоваться, который разрешит загрузку вспомогательных ресурсов, но не будет реагировать на запросы аутентификации),


Изображения в файлах SimpleText теперь центрируются, как они были в SimpleText. Кроме того, изображения в японских файлах SimpleText теперь выведены на экран.

Методы для загрузки файлов в NSAttributedString теперь попытаются распознать XML-файлы и использовать кодировку символов, определенную в заголовке XML, если они могут. Это - просто эвристика, не всегда применимая; если вызывающая сторона обеспечит явное кодирование, это не будет использоваться.

Ссылки (как представлено NSLinkAttributeName и сохраненный как NSString, или более предпочтительно как NSURL) в тексте теперь считаны из и записаны в файлы RTF. Используемый формат совместим с одним используемым Word.



Текстовые атрибуты

Следующие атрибуты были добавлены к текстовой системе:
NSString *NSStrokeWidthAttributeName; /* float, in % of font size, default 0: no stroke; pos for stroke alone; neg for stroke+fill */
NSString *NSStrokeColorAttributeName; /* NSColor, default nil: same as foreground color */
NSString *NSShadowAttributeName; /* NSShadow, default nil: no shadow */
NSString *NSObliquenessAttributeName; /* float; shear to be applied to glyphs, default 0 (no shear) */
NSString *NSExpansionAttributeName; /* float; log of expansion factor to be applied to glyphs, default 0 (no expansion) */
NSString *NSCursorAttributeName; /* NSCursor, default IBeamCursor */
NSString *NSToolTipAttributeName; /* NSString, default nil: no tooltip */
NSString *NSUnderlineColorAttributeName; /* NSColor, default nil: same as foreground color */
NSString *NSStrikethroughStyleAttributeName; /* int, default 0: no strikethrough */
NSString *NSStrikethroughColorAttributeName; /* NSColor, default nil: same as foreground color */
Кварц позволяет тексту быть составленным как основы (штрих) или твердые частицы (заливка) или оба, потенциально в различных цветах. Ранее текстовое получение Какао всегда использовало получение заливки. Новая штриховая ширина и атрибуты цвета обводки позволяют штрих, рисующий также. Фактическая штриховая используемая ширина является абсолютным значением атрибута; одно только штриховое получение обозначено положительным значением, штрихом и заливкой отрицательной величиной и одной только заливкой нулевым значением или отсутствием атрибута. Значение дано как процент размера точки шрифта так, чтобы единственное значение могло иметь непротиворечивое значение через многократные шрифты. Основной цвет продолжает использоваться в качестве цвета заливки. Если отдельный цвет обводки будет указан, то он будет использоваться в качестве цвета обводки; иначе основной цвет используется и для штриха и для заливки.

Предыдущие значения для NSUnderlineStyle, NSNoUnderlineStyle = 0 или NSSingleUnderlineStyle = 1, or'ed с NSUnderlineByWordMask для подчеркивания словом и/или NSUnderlineStrikethroughMask для перечеркиваний, теперь осуждаются (за исключением NSUnderlineByWordMask), несмотря на то, что они все еще определяются и поддерживаются для совместимости. Новые значения для NSUnderlineStyle
enum {
NSUnderlineStyleNone = 0x00,
NSUnderlineStyleSingle = 0x01,
NSUnderlineStyleThick = 0x02,
NSUnderlineStyleDouble = 0x09
};
or'ed с одним из следующего:
enum {
NSUnderlinePatternSolid = 0x0000,
NSUnderlinePatternDot = 0x0100,
NSUnderlinePatternDash = 0x0200,
NSUnderlinePatternDashDot = 0x0300,
NSUnderlinePatternDashDotDot = 0x0400
};
и с NSUnderlineByWordMask, если подчеркивание должно быть словом. Цвет подчеркивания указан NSUnderlineColorAttributeName; если никакой цвет не указан, основной цвет используется.

Вместо NSUnderlineStrikethroughMask в стиле подчеркивания, существует теперь отдельный атрибут NSStrikethroughStyleAttributeName с тем же набором значений как NSUnderlineStyleAttributeName. Существует также NSStrikethroughColorAttributeName для управления перечеркнутым цветом; если никакой цвет не указан, основной цвет используется. Соответственно, существует теперь два дополнительных метода NSLayoutManager для рисования перечеркиваний, параллельных двум существующим методам подчеркивания:
- (void)drawStrikethroughForGlyphRange:(NSRange)glyphRange
strikethroughType:(int)underlineVal
baselineOffset:(float)baselineOffset
lineFragmentRect:(NSRect)lineRect
lineFragmentGlyphRange:(NSRange)lineGlyphRange
containerOrigin:(NSPoint)containerOrigin;
- (void)strikethroughGlyphRange:(NSRange)glyphRange
strikethroughType:(int)underlineVal
lineFragmentRect:(NSRect)lineRect
lineFragmentGlyphRange:(NSRange)lineGlyphRange
containerOrigin:(NSPoint)containerOrigin;
Существует три подгруппы с одним параметром аффинной группы, которые ясно полезны, поскольку обеспечивают трансформации текста, размеченного на базовых линиях, таких как текстовая система Какао. Расширение всегда было доступно в форме размера точки шрифта. Две остающихся подгруппы являются (a) одномерным расширением, соответствуя сжатию или расширению текста вдоль оси X; и (b) трансформация сдвига, в частности та, оставляющая базовую линию текста неизменной, но делающая остаток от текста более или менее наклонным. Они выражены атрибутами NSExpansionAttributeName и NSObliquenessAttributeName соответственно. Значения выбраны так, чтобы оба появились как аддитивные группы, в частности так, чтобы 0 представлял идентификационные данные.

Новые атрибуты NSCursorAttributeName и NSToolTipAttributeName поддерживают возможность изменить курсор и вывести на экран подсказки по частям текста в текстовом представлении. Как NSLinkAttributeName, эти атрибуты обычно будут устанавливаться программно, а не пользовательским действием. Кроме того, NSTextView теперь имеет метод делегата,
- (NSString *)textView:(NSTextView *)textView
willDisplayToolTip:(NSString *)tooltip
forCharacterAtIndex:(unsigned)charIndex;
который вызовут, если атрибут NSToolTipAttributeName будет фактически установлен на символах, над которыми мышь нависает, и который позволяет делегату изменять (путем возврата различной строки) или подавлять (путем возврата ноля) дисплей подсказки во время дисплея.

Обратите внимание на то, что курсоры и подсказки активны, только если текстовое представление можно выбрать. Невыбираемые текстовые представления не обрабатывают событий от нажатия мыши. Если по некоторым причинам необходимо запретить пользовательское изменение выбора в текстовом представлении, что события от нажатия мыши дескрипторов, это может быть достигнуто, заставив текст просмотреть можно выбрать, но реализовав метод делегата textView:willChangeSelectionFromCharacterRange:toCharacterRange: запрещать изменения выбора.


Атрибуты временного и текста ссылки

Некоторая текстовая генерация глифа влияния атрибутов и/или расположение, и некоторые не делают. Последние включают атрибуты цвета всех типов, подчеркиваний и перечеркиваний, курсоров и подсказок. Только последние являются кандидатами на временные атрибуты на менеджере по расположению, или для выбранного или отмеченного текстового атрибута на текстовом представлении. Другие атрибуты будут проигнорированы, если они будут использоваться в качестве временных, выберут или отметят текстовые атрибуты. Кроме того, существует новый набор атрибутов на текстовом представлении, атрибутов текста ссылки. Они будут применены - т.е. чтобы быть добавленными, переопределяя только существующие значения тех же атрибутов - к тексту ссылки при рисовании на экран, как выбранные и отмеченные текстовые атрибуты применяются к выбранному и отмеченному тексту. Следующие методы были добавлены к NSTextView:
- (void)setLinkTextAttributes:(NSDictionary *)attributeDictionary;
- (NSDictionary *)linkTextAttributes;
В то время как для Связанных приложений пантеры значение по умолчанию является синим текстом с подчеркиванием и надлежащим курсором, для приложений перед пантерой значение по умолчанию является пустым словарем. Обратите внимание на то, что linkTextAttributes предназначается для тех, кто хочет, чтобы все ссылки получили определенные атрибуты; приложения, желающие украсить различные ссылки по-другому, могут использовать временные атрибуты с этой целью, которые будут иметь приоритет по соответствующим атрибутам текста ссылки.


Дополнительный текст UI

Текстовый аксессуар линейки изменился значительно, и несколько дополнительных панелей были добавлены, чтобы дать пользователям дополнительный контроль над символом и атрибутами абзацев. В поддержку этого метод был добавлен к NSTextView:
- (void)changeAttributes:(id)sender;
несколько параллельный существующему changeFont:. Когда changeAttributes: вызывается, это вызывает новый метод
- (NSDictionary *)convertAttributes:(NSDictionary *)attributes;
на отправителе changeAttributes: последовательно с каждым набором атрибутов, используемых в текущем выбранном диапазоне (или в атрибутах ввода). Отправитель тогда вносит любые изменения атрибута, которых он желает, и возвратите преобразованный словарь. Отправитель, как ожидают, оставит нетронутые атрибуты, которыми он не интересуется. Это может также использоваться для пользовательских элементов управления, которые могли бы быть предоставлены для различных текстовых атрибутов. Кроме того, NSTextView теперь обеспечивает уведомление и соответствующий метод делегата при вводе изменения атрибутов, изменился ли текст в результате - например, когда «Полужирный» выбран, но существует выбор нулевой длины. Это может использоваться для отслеживания все изменения в текстовых атрибутах:
NSString *NSTextViewDidChangeTypingAttributesNotification;
- (void)textViewDidChangeTypingAttributes:(NSNotification *)notification;
На NSFontManager существует также два новых метода:
- (void)orderFrontStylesPanel:(id)sender;
- (void)setSelectedAttributes:(NSDictionary *)attributes isMultiple:(BOOL)flag;
Когда атрибуты изменяются, последний используется NSTextView для уведомления новых панелей. Прежний - метод действия основная панель, которая будет выведена на экран, предназначена для использования с пунктами меню.


NSTextStorage

NSTextStorage не удавалось не зарегистрировать его делегата к уведомлениям, будучи освобожденным. Это теперь устанавливает своего делегата в ноле в dealloc, вычеркивающем из списка делегата как наблюдателя.


NSTextView

Несколько разных дополнительных методов были также добавлены к NSTextView. Для поддержки пункта меню шрифта «Схемы» метод действия был добавлен:
- (void)outline:(id)sender;
Как подчеркивание: это добавит соответствующий атрибут, если отсутствующий, или удалять его если нет. Также как подчеркивание: это использует значение по умолчанию для соответствующего атрибута - в этом случае, атрибутом является NSStrokeWidthAttributeName, и значение по умолчанию 3.0.

Для поддержки изменения основной направленности абзаца - например, для иврита или арабского языка - метод действия был добавлен:
- (void)toggleBaseWritingDirection:(id)sender;
Был добавлен дополнительный метод действия
- (void)changeDocumentBackgroundColor:(id)sender;
поддерживать пользовательские изменения цвета фона текстового представления (и все его одноуровневые текстовые представления). Термин «документ» добавляется к имени для различения этого цвета фона от цвета фона текста, как указано NSBackgroundColorAttributeName, применяющимся только к определенным диапазонам текста а не к документу в целом. Этот цвет фона является backgroundColor представления, и это - цвет фона, который, как ожидали бы, будет использоваться в связи со свойством документа «BackgroundColor», описанным выше. С тех пор не все текстовые представления будут хотеть позволить пользователям изменять цвет фона документа, существует флаг (значение по умолчанию НЕ), который определяет, позволяется ли это, и методы, чтобы установить и получить его значение:
- (void)setAllowsDocumentBackgroundColorChange:(BOOL)flag;
- (BOOL)allowsDocumentBackgroundColorChange;
Новый метод рисования был добавлен,
- (void)drawViewBackgroundInRect:(NSRect)rect;
который вызывают, когда текстовое представление намеревается нарисовать свой фон, и который подклассы могут переопределить для выполнения дополнительного получения позади текста NSTextView.

NSTextView теперь имеет стиль абзаца по умолчанию, который клиенты могут установить, и который он будет использовать, когда никакой стиль абзаца не будет явно указан, и который пользователь будет в состоянии вернуться к использованию линейки. Если никакой клиент не установит это, то [NSParagraphStyle defaultParagraphStyle] будет использоваться.
- (NSParagraphStyle *)defaultParagraphStyle;
- (void)setDefaultParagraphStyle:(NSParagraphStyle *)paragraphStyle;
В сочетании с новым defaultTabStop свойством NSParagraphStyle это обеспечивает простой способ обеспечить позиции табуляции по умолчанию всюду по документу - например, в документе простого текста.


У нас теперь есть стандартная панель находки, применимая NSTextView. Следующие два метода в NSTextView позволяют позволять/запрещать стандартную панель находки:
- (void)setUsesFindPanel:(BOOL)flag;
- (BOOL)usesFindPanel;
По умолчанию недавно создаваемые NSTextViews в IB имеют этот набор атрибута, но по причинам совместимости, программно создаваемым или уже, заархивированные экземпляры не делают.

Следующий метод является универсальным методом действия для панели находки, и найдите меню:
- (void)performFindPanelAction:(id)sender;
Это добавляется к NSTextView и может быть переопределено представлениями, хотящими обеспечить их собственную панель находки. Фактическая работа определяется значениями тега, такими как NSFindPanelActionNext и т.д.; посмотрите перечислимый NSFindPanelAction.

В 10,3 панель находки предназначается для использования NSTextView только, поскольку нет никаких методов для обеспечения степени возможности многократного использования, которая была бы необходима для других клиентов для сцепления до него.

При загрузке пользовательских специфичных для пользователя словарей привязки клавиш из ~/Library/KeyBindings, текстовая система больше не ищет файл DefaultKeyBinding.plist, просто DefaultKeyBinding.dict. Прежний не упоминается в документации, но некоторые более старые пользовательские установки могли бы иметь тот файл вместо предпочтительного DefaultKeyBinding.dict.


Текстовое завершение

NSTextView теперь имеет реализацию по умолчанию первого завершенного метода респондента: который связывается по умолчанию с Escape опции и также F5. Намерение полных: должен предоставить пользователям выбор завершений для слова, в настоящее время вводимого. По умолчанию текстовая система не вызовет завершенный: автоматически, а скорее только если пользователь нажимает клавишу, с которой это связывается; однако, клиенты текстовой системы могут получить автозавершение путем вызова завершенный: программно, когда желаемый. NSTextView предоставит список по умолчанию завершений, взятых от множества источников, но клиенты могут заменить или изменить этот список через методы подклассов или методы делегата.

Реализация NSTextView
- (void)complete:(id)sender;
поочередно вызовет методы NSTextView (переопределяемый подклассами)
- (NSRange)rangeForUserCompletion;
- (NSArray *)completionsForPartialWordRange:(NSRange)charRange indexOfSelectedItem:(int *)index;
заставить диапазон частичного слова быть завершенным, список потенциальных завершений, и дополнительно индекс в том списке элемента, который будет первоначально выбран. Этот последний метод поочередно вызовет метод делегата NSTextView (если реализовано)
- (NSArray *)textView:(NSTextView *)text
completions:(NSArray *)words
forPartialWordRange:(NSRange)charRange
indexOfSelectedItem:(int *)index;
который позволит делегату изменять, переопределять или подавлять список завершений. Для текстовых полей и других средств управления, мы определим метод делегата NSControl
- (NSArray *)control:(NSControl *)control
textView:(NSTextView *)
completions:(NSArray *)words
forPartialWordRange:(NSRange)charRange
indexOfSelectedItem:(int *)index;
позволить делегату управления ту же свободу управлять списком завершений, используемых полевым редактором. Фактические средние значения представления потенциальных завершений будут определены завершенным NSTextView: метод; те, кто хочет изменить его, должны будут переопределить complete:.

Массив, используемый во всех этих случаях, является массивом строк в порядке, в котором они должны быть представлены, представляя полные слова, которые пользователь мог бы пытаться ввести при запуске путем ввода частичного слова в данном диапазоне. Результатами являются полные слова, а не просто остаток от слова, в случае, если завершение требует некоторой небольшой модификации того, что пользователь уже ввел - например, добавление диакритического знака или изменение в капитализации. Разработчики могли бы также использовать это для поддержки сокращений, которые завершатся в слова, не обязательно запускавшиеся с символов сокращения. Индексный параметр позволяет делегатам или подклассам возвращать ссылкой индекс, указывающий, какое из завершений должно быть выбрано первоначально (значение по умолчанию 0, и-1 среднее значение никакой начальный выбор).

Когда пользователь перемещается через список завершений, следующий метод NSTextView вызовут с в настоящее время выбираемым завершением:
- (void)insertCompletion:(NSString *)word
forPartialWordRange:(NSRange)charRange
movement:(int)movement
isFinal:(BOOL)final;
для которого реализация по умолчанию вставит предложенное завершение в текст в надлежащем месте. Заключительный флаг будет НЕ, пока завершение является все еще предварительным, и YES, когда пользователь в конечном счете выбирает одно завершение окончательно. Параметр перемещения опишет меры, которые пользователь принял для изменения текущего выбранного завершения; это примет свои значения от перечисления NSTextMovement, определенного в NSText.h, уже использующемся в подобной цели в описании перемещений через таблицы, матрицы и формы. Дополнительное значение NSCancelTextMovement было добавлено, для покрытия случая, в котором пользователь отменяет завершение, и исходное частичное слово восстанавливается. Кроме того, значению перемещения 0 дали дополнительное имя NSOtherTextMovement, более ясно отражающий и его предыдущее и текущее использование - а именно, для покрытия любого случая, не покрытого другими значениями в этом перечислении. Подклассы будут в состоянии переопределить insertCompletion:forPartialWordRange:movement:isFinal: или чтобы изменить поведение по умолчанию метода или иначе выполнить некоторое дополнительное действие, возможно в зависимости от ли и тем, какие средние значения пользователь вышли из процесса завершения.

Один потенциальный источник завершений является программой проверки правописания. В поддержку этого дополнительный метод был добавлен к NSSpellChecker:
- (NSArray *)completionsForPartialWordRange:(NSRange)range
inString:(NSString *)string
language:(NSString *)language
inSpellDocumentWithTag:(int)tag;
и соответствующий метод делегата NSSpellServer, который будет реализован в самой программе проверки правописания:
- (NSArray *)spellServer:(NSSpellServer *)sender
suggestCompletionsForPartialWordRange:(NSRange)range
inString:(NSString *)string
language:(NSString *)language;

Перед Пантерой текстовые операции отмены/восстановления не заставляли NSTextView отправлять свой textView:shouldChangeTextInRange:replacementString: метод делегата и его уведомление NSTextDidChange. На Пантере тот метод делегата и уведомление будут, посылают за текстовой отменой и восстановлением. Однако по причинам совместимости, это произойдет только для исполнимых программ, соединенных на Пантере или более поздних версиях системы.


Двунаправлено-опытное перемещение

Методы NSResponder, содержащие «вперед» и «назад» на их имена, не являются самым надлежащим выбором для перемещения клавиши со стрелкой в двунаправленном тексте. У Пантеры существуют некоторые дополнительные методы, описанные «правом», и «уехали», которые используются для привязки перемещения клавиши со стрелкой и того перемещения в надлежащем визуальном направлении, является ли это фактически вперед или назад в логическом порядке текста.
- (void)moveWordRight:(id)sender;
- (void)moveWordLeft:(id)sender;
- (void)moveRightAndModifySelection:(id)sender;
- (void)moveLeftAndModifySelection:(id)sender;
- (void)moveWordRightAndModifySelection:(id)sender;
- (void)moveWordLeftAndModifySelection:(id)sender;


Диапазон абзаца

Мы теперь ясно делаем различие между разделителями строки и разделителями абзацев. Соответственно, Основа имеет новые методы на NSString для нахождения границ абзаца:
- (void)getParagraphStart:(unsigned *)startPtr
end:(unsigned *)parEndPtr
contentsEnd:(unsigned *)contentsEndPtr
forRange:(NSRange)range;
- (NSRange)paragraphRangeForRange:(NSRange)range;
которые параллельны существующим эквивалентам диапазона строки, но которые принимают во внимание только разделители абзацев и не все разделители строки. В использованиях, связанных с текстовой системой Какао, нужно решить, являются ли диапазон строки или диапазон абзаца надлежащим количеством, и выберите из этих методов соответственно. Диапазон атрибута NSParagraphStyle, например, всегда будет диапазоном абзаца; аналогично, тройной щелчок выберет диапазон абзаца.


NSGlyphGenerator

Новый общедоступный класс NSGlyphGenerator был добавлен к текстовой Системе Какао. Класс выполняет начальную номинальную фазу генерации глифа в процессе создания макета. Класс связывается через протокол NSGlyphStorage. Экземпляром классов, соответствующих протоколу, является NSLayoutManager.

NSGlyphGenerator теперь генерирует NSControlGlyph для всех символов в Unicode Общая Категория C* и U200B (ZERO WIDTH SPACE).


NSATSTypesetter

Новый общедоступный подкласс бетона NSTypesetter, NSATSTypesetter, добавляется в текстовой Системе Какао. Класс выполняет фактически расположение (определяет позиции глифа), фаза в процессе создания макета.

API NSATSTypesetter категоризирован в 3 группы.

Первая группа интерфейсов, объявленных в основе @interface сам раздел, разделена на 2 раздела---примитивы расположения и интерфейс NSLayoutManager.

Примитивы расположения обычно вызываются методами интерфейса NSLayoutManager внутренне. Тем временем примитивы могут вызвать сторонние механизмы расположения непосредственно для выполнения набора, не используя NSLayoutManager.

Вторая группа API объявляется в категории NSLayoutPhaseInterface. Это перечисляет все точки переопределения для подклассов для тонкой настройки различных аспектов наборного поведения.

Третий набор объявляется в категории NSGlyphStorageInterface. Методы являются примитивами для взаимодействия через интерфейс с хранением глифа, такими как NSLayoutManager.

Можно переопределить все методы, перечисленные в здесь для взаимодействия через интерфейс с пользовательским хранением глифа. Затем вызов-layoutParagraphAtPoint: диски каждый абзац наборный сеанс.

Поведение для U00AD (SOFT HYPHEN) теперь соответствует спецификации версии 4.0 Unicode.


NSParagraphStyle

Следующие методы были добавлены к NSParagraphStyle:
- (float)lineHeightMultiple;
- (void)setLineHeightMultiple:(float)aFloat;
- (float)paragraphSpacingBefore;
- (void)setParagraphSpacingBefore:(float)aFloat;
- (float)defaultTabInterval;
- (void)setDefaultTabInterval:(float)aFloat;
Значения по умолчанию для lineHeightMultiple, paragraphSpacingBefore, и defaultTabInterval все будут 0.0, который даст предыдущее поведение. Если lineHeightMultiple будет положителен, то естественная высота строки будет умножена на lineHeightMultiple, но все еще ограничена minimumLineHeight и maximumLineHeight, как обычно. Это означает, что lineHeightMultiple 2,0 даст двойной интервал. Пространство между абзацами теперь будет paragraphSpacing предыдущего абзаца плюс paragraphSpacingBefore следующего параграфа. Если defaultTabInterval будет положителен, то вкладки после последней явно указанной позиции табуляции дадут эффективно оставленные вкладки в интегральной сети магазинов defaultTabInterval от левого края страницы.

Оставление тремя настройками NSLineBreakMode, NSLineBreakByTruncatingHead, NSLineBreakByTruncatingTail, и NSLineBreakByTruncatingMiddle, реализовано в NSATSTypesetter (NSTypesetterBehavior> NSTypesetterOriginalBehavior). Можно использовать их для рисования усеченных строк и текста более эффективно, который обычный многоступенчатый процесс (вычисляют размер, усеченный, затем составляет).

removeTabStop: используемый для удаления всего isEqual: экземпляры позиции табуляции, вопреки документации. У Пантеры, для приложений соединился против Пантеры или позже, это только удаляет первый isEqual: экземпляр.


NSTextTab

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


NSResponder

Два новых метода привязки клавиш определяются в NSResponder.-deleteBackwardByDecomposingPreviousCharacter: обязан управлять - удаляют по умолчанию.-cancelOperation: обязан Выйти. Кроме того, как описано выше, мы теперь добавили Escape опции как основную привязку значения по умолчанию для complete:.

NSFontDescriptor

NSFontDescriptor класса был добавлен, который обеспечивает механизм для описания шрифта, который может позже быть превращен в объект NSFont. Основная часть дескриптора шрифта является словарем атрибутов. Все атрибуты являются дополнительными. Можно в настоящее время создавать дескриптор шрифта с помощью следующих методов.
- (id)initWithFontAttributes:(NSDictionary *)attributes;
+ (NSFontDescriptor *)fontDescriptorWithFontAttributes:(NSDictionary *)attributes;
+ fontDescriptorWithName:(NSString *)fontName size:(float)size;
Текущие атрибуты, которые могут быть определены,
NSFontFamilyAttribute
NSFontNameAttribute
NSFontFaceAttribute
NSFontSizeAttribute
NSFontVisibleNameAttribute
NSFontColorAttribute

NSFont

Новый API + [NSFont systemFontSizeForControlSize:] добавляется.

Список резервного шрифта теперь уважает список приоритета языка пользователя.

NSFont теперь всегда зеркально отражает текстовую матрицу regerdless ее собственной матрицы преобразования, когда установлено для фокусируемого представления, зеркально отразившего систему координат. Это раньше делало так только, когда матрица преобразования шрифта была идентификационными данными. Для восстановления старого поведения можно установить предпочтительное значение NSOnlyFlipFontsWithIdentityMatrix в YES.

-screenFont метод теперь последовательно возвращает экранный шрифт независимо от размера получателя. Логика для инстанцирования экранных шрифтов по их дубликатам шрифта принтера перемещена в - [NSLayoutManager substituteFontForFont:]. Новая логика в NSLayoutManager теперь всегда выбирает шрифты принтера для шрифтов неединичной матрицы.

Размер по умолчанию для шрифта палитры изменяется с 10,0 до 11,0 для следования за спецификацией Воды.

Шрифт строки меню может отличаться от шрифта, используемого для пунктов меню. Этот метод возвращает шрифт. Передача в 0 для fontSize возвращает шрифт строки меню по умолчанию.
+ (NSFont *)menuBarFontOfSize:(float)fontSize;
Можно получить дескриптор шрифта от NSFont использование следующего метода:
- (NSFontDescriptor *)fontDescriptor;

NSFontManager

Следующие методы были добавлены к NSFontManager для поддержки управления набором шрифта. Можно создать и удалить наборы с помощью следующих двух методов:
- (BOOL)addCollection:(NSString *)collectionName options:(int)collectionOptions;
- (BOOL)removeCollection:(NSString *)collectionName;
В настоящее время единственная опция, доступная для наборов шрифта,
NSFontCollectionApplicationOnlyMask
Можно получить массив текущего использования имен набора
- (NSArray *)collectionNames;
и можно получить массив дескрипторов в данном использовании набора
- (NSArray *)fontDescriptorsInCollection:(NSString *)collectionNames;
Чтобы добавить и удалить дескрипторы шрифта из набора, используйте следующие методы.
- (void)addFontDescriptors:(NSArray *)descriptors  toCollection:(NSString *)collectionName;
- (void)removeFontDescriptor:(NSFontDescriptor *)descriptor fromCollection:(NSString *)collection;
Можно получить массив объектов NSFont, соответствующих определенный дескриптор шрифта с помощью следующего метода. Текущая реализация только распознает NSFontFamilyAttribute, NSFontNameAttribute и NSFontFaceAttribute. Все другие атрибуты проигнорированы.
-(NSArray *) availableFontNamesMatchingFontDescriptor: (NSFontDescriptor *) descriptor;

NSFontPanel

Наборы шрифта мигрировали на формат, использующий класс NSFontDescriptor. Наборы теперь живут в ~/Library/FontCollections с .collection расширением. Изменения, внесенные в наборы с помощью предыдущих версий AppKit, будут влиять на .fcache файлы и не будут синхронизироваться с новыми наборами. Если Вы хотите повторно синхронизировать их, необходимо будет удалить все .collection файлы в папке наборов шрифта и повторно запустить панель шрифта.

Панель шрифта теперь имеет возможность скрыть элементы, которые не применимы при наличии цели, реагируют на метод, проверяющий режимы панели шрифта. Следующие маски режима определяются:
enum {
NSFontPanelFaceModeMask = 1 << 0,
NSFontPanelSizeModeMask = 1 << 1,
NSFontPanelCollectionModeMask = 1 << 2,
...
NSFontPanelStandardModesMask = 0xFFFF, // standard modes, including those added in the future but expected to work by default
NSFontPanelAllModesMask = 0xFFFFFFFF // all modes, including some added in the future but are not enabled by default
};
Если цель хочет что-нибудь кроме маски стандартного режима, она должна реагировать на этот метод.
- (unsigned int)validModesForFontPanel:(NSFontPanel *)fontPanel;

Обработка параметра «сохранения» приложения выхода событие Apple

В предыдущих версиях Какао обработка AppKit по умолчанию стандартного события Quit Application Apple (и команды Quit пишущего сценарий Стандартного Комплекта) проигнорировала параметр «сохранения», ведя себя, как будто его значение было, всегда «спрашивают». Новое поведение было представлено так, чтобы было правильно интерпретировано значение параметра «сохранения».

В приложениях, имеющих NSDocumentController:

Если значение параметра «сохранения» - «да», каждый открывается, измененный, документ будет отправлен-saveDocumentWithDelegate:didSaveSelector:contextInfo: сообщение. Если документ будет сохранен успешно, то NSDocument будет тогда отправлен - сообщение о закрытии и следующее открытое, изменили, документ будет обработан. Если какой-либо документ не может быть сохранен из-за ошибки или пользовательской отмены, приложение не будет завершено.

Для «нет» заявление будет послано - оконечный: сообщение. Приложение не отправит его делегату-applicationShouldTerminate: сообщение все же.

Для «спрашивают», NSDocumentController будет отправлен-reviewUnsavedDocumentsWithAlertTitle:cancellable:delegate:didReviewAllSelector:contextInfo: сообщение, как в предыдущих версиях Какао.

В приложениях, не имеющих никакого NSDocumentController:

Если значение параметра «сохранения», «спрашивают» или «да», делегат будет отправлен-applicationShouldTerminate: как в предыдущих версиях Какао. Делегаты, которые должны знать точное значение параметра «сохранения», могут использовать новое - [NSAppleEventManager currentAppleEvent] метод.

Для «нет» заявление будет послано - оконечный: сообщение. Приложение не отправит его делегату-applicationShouldTerminate: сообщение все же.


Передача команд сценариев завершения и печати, отправленных в Windows

В предыдущих версиях Сценариев Какао, близко и команд печати, отправленных в окна, были не справлены. Теперь, - [NSWindow (NSScripting) handleCloseScriptCommand:] направит близкую команду к соответствующему документу, если будет соответствующий документ, и окно является главным окном документа. Иначе, окно отправит себе сообщение-performClose, если оно будет иметь рамку для закрытия.

Аналогично, [NSWindow (NSScripting) handlePrintScriptCommand:] теперь вперед команда печати к соответствующему документу, если это - главное окно того документа. Иначе, окно отправит себя - сообщение печати.


Устаревшие символы

NSAlphaEqualToData и NSAlphaAlwaysOne (со значениями 1 и 2, соответственно) были удалены из NSGraphics.h, поскольку они не использовались прежде 10.0.





Отмечает определенный для Mac OS X 10.2.5

Обновление Ягуара 10.2.5 содержит новый AppKit, адресующий несколько ошибок, включая незваных гостей с файлами PNG, содержащими данные ColorSync, поврежденные файлы GIF и редкую освобожденную ошибку памяти в целевых приложениях при использовании доступности APIs. Кроме того, ошибка 3163914, заставляя модернизированные перья с пользовательскими подклассами вызвать проблемы во время выполнения, была также исправлена.

Номер версии для AppKit в 10.2.5 663.10. Предупреждение, хотя, в очень маловероятном случае необходимо отличить 10.2.5 версии AppKit---, если обработано как число с плавающей точкой, 663.10, заканчивает тем, что было меньше чем 663,6.


Отмечает определенный для Mac OS X 10.2.3

Новый AppKit присутствует в 10.2.3. Некоторые изменения в 10.2.3 AppKit упоминаются ниже.

В случае, если необходимо дифференцировать две версии AppKit во время выполнения: номер версии для 10.2.3 AppKit 663.6. Номер версии для 10.2 AppKit был 663. Нет никакого API или изменений заголовочного файла в AppKit между 10.2 и 10.2.3.


NSBezierPath

10,2 ошибок с appendBezierPathWithGlyphs:count:inFont: помещение всех глифов друг на друге было фиксировано в 10.2.3.


NSColor

NSColor теперь сохраняет прозрачность при печати.


NSColorPanel

Цветная панель может теперь вывести на экран произвольную информацию об авторском праве для списка цветов. Для предоставления информации авторского права просто добавьте, что ключ NSColorListCopyrightInfo к спискам цветов представляет файл в виде строки (например, MyColorList.clr/English.lproj/MyColorList.strings).

Палитра цветов списка была обновлена с несколькими новыми пользовательскими функциями, включая поле поиска.


NSImage

Исключение, вызывая несуществующий метод clearAvailableData во время инкрементной загрузки изображения было фиксировано.

JPEG 6 файлов, сохраненных с Графическим Преобразователем, мог подвесить или разрушить приложения; эта ошибка была исправлена.

Анимированные изображения GIF теперь работают лучше.


NSOutlineView

Возможный катастрофический отказ в вызове reloadItem:reloadChildren: во время редактирования фиксируется в 10.2.3.


NSTableView

Ошибка была представлена в 10,2, где вызов abortEditing, в то время как ячейка редактировалась, мог вызвать катастрофический отказ. 10.2.3 решает эту проблему.

Проблема производительности с выбором многократных элементов в tableview использование клавиатуры решена в 10.2.3.


NSToolbar

Регрессия пунктов меню исчезновения в элементах панели инструментов с menuFormRepresentations была фиксирована в 10.2.3.


NSWindow

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


Печать

10,2 регрессий с программно установкой пользовательского формата бумаги были фиксированы.


Текст

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

Мы временно выключили включение символа Unicode BOM (0xFEFF) в типе области монтажа Углерода для текста Unicode ('utxt'), поскольку это вызывало проблемы в нескольких приложениях, которым не удалось иметь дело с этим должным образом. Это - наше намерение повторно включить это в будущем выпуске.

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

Катастрофический отказ в сохранении как текстовые документы RTF, содержащие глифы без соответствующих символов Unicode, был фиксирован в 10.2.3. Такие глифы обычно вводятся с помощью палитры символов.




Отмечает определенный для Mac OS X 10.2

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

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

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


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

Новый APIs в заголовках отмечен с конструкцией:
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_2
...
#endif
Основные определения для них прибывают из AvailabilityMacros.h, нового стандартного системного заголовка. Это включено от Cocoa.h, AppKit.h и импорта Foundation.h.

Если Вы ничего не делаете, MAC_OS_X_VERSION_MAX_ALLOWED, как предполагается, является MAC_OS_X_VERSION_10_2. Однако для наблюдения, на который пост10.1 символов приложение ссылаются (например), можно создать указание флага компилятора:
-DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_1
и наблюдайте за предупреждениями.


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

Существует несколько способов проверить на новые функции, предоставленные платформами Какао во время выполнения. Нужно искать данный новый класс или метод динамично, и не использовать его если не там. Другой должен использовать глобальную переменную NSAppKitVersionNumber (или, в Основе, NSFoundationVersionNumber):
APPKIT_EXTERN double NSAppKitVersionNumber;
#define NSAppKitVersionNumber10_0 577
#define NSAppKitVersionNumber10_1 620
Одно типичное использование этого должно поставить в тупик () значение и проверку по сравнению со значениями, предоставленными в NSApplication.h:
if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_0) {
    /* On a 10.0.x or earlier system */
} else if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_1) {
    /* On a 10.1 - 10.1.x system */
} else {
    /* 10.2 or later system */
}
Особые случаи или ситуации для проверки версии также обсуждены в информации о версии как надлежащие. Например, некоторые отдельные заголовки могут также объявить числа версий для NSAppKitVersionNumber, где некоторое исправление ошибки или функциональность доступны в данном обновлении, например:
#define NSAppKitVersionWithSuchAndSuchBadBugFix 582.1

Доступность

Стандартные элементы пользовательского интерфейса какао (например, NSButton, NSView...) поддерживают недавно добавленную Доступность APIs, позволяющий вспомогательные приложения, например, программу экранного доступа, чтобы исследовать и взаимодействовать с пользовательскими интерфейсами других приложений.

Если Ваше приложение будет иметь элементы настроенного пользовательского интерфейса, то необходимо будет реализовать протокол NSAccessibility в порядке от них работать с Доступностью APIs. Документация для этого протокола может быть найдена в/Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/Accessibility.


Какао в углероде

Теперь возможно показать окна Cocoa в приложениях Углерода. Когда Какао загружается в приложение Углерода, NSApplicationLoad () нужно вызвать для инициализации среды Какао должным образом. Дальнейшая документация для этого будет доступна на сайте Документации Разработчика Apple.

Панель Font и цветная панель также доступны приложениям Углерода с помощью Углерода APIs. Какао будет загружено динамично в приложение Углерода при необходимости.


Включенная архивация

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

Некоторые опции, которые Вы имеете:

- Если Ваше приложение пишет объектные архивы, и Вам нужны те архивы, чтобы быть читаемыми на 10,1, придерживаться старого формата; иначе лучше переключиться на новый формат.
- Если Ваша архивация реализации объектов, и Вы хотите, чтобы они использовали в своих интересах функции гибкости и совместимости, предоставленные включенной архивацией, увеличили Ваш initWithCoder: и encodeWithCoder: методы для реализации включенной архивации. Обратите внимание на то, что объекты, не реализующие включенную архивацию, могут все еще быть записаны во включенные архивы, но они не используют в своих интересах новые функции.
- Сохранив файлы пера в Интерфейсном Разработчике, можно принять решение использовать 10,1 форматов, 10,2 форматов или обоих. Эти 10,1 форматов совместимы с пред10.2 системами, однако, вследствие проблем совместимости, 10,1 архивов не способны к хранению многих новых опций, добавленных в 10,2 и будущее. Сохранение файлов пера с помощью «оба» форматы позволяет Вам помещать и новые и старые архивы в ту же .nib обертку, выбирая и открывая надлежащую во время выполнения. При редактировании такого файла пера оба архива редактируются и сохраняются одновременно.



Локализованное представление файловой системы

10,2 поддержек локализовали представление файловой системы, позволяющей пользователям видеть имена элементов файловой системы (приложения, пакеты, пакеты документов и папки) на их основном языке, принимающие локализации были предоставлены. Это выполняется, фактически не локализуя имена файловой системы. Эта функция обсуждена далее в Системном документе Обзора (около конца раздела «How the File System Is Organized»).

В приложении Какао существует несколько вещей знать:

- Пути, используемые для доступа к файловой системе, никогда не локализуются; таким образом, локализованные версии имен объекта файловой системы должны только привыкнуть, будучи выведенным на экран к пользователю. Например, не используйте локализованное имя дисплея при сохранении путей в предпочтениях или в другом месте.

- Используйте - [NSFileManager displayNameAtPath:] или новое - [NSFileManager componentsToDisplayForPath:] методы для получения человекочитаемых имен для объектов файловой системы, если Вы выводите на экран кого-либо.

- Если Вы хотите, чтобы Ваше имя приложения было локализуемо, добавьте CFBundleDisplayName к своему Info.plist. Значение этого должно совпасть с именем файловой системы (без расширения файла). Это может тогда быть локализовано через InfoPlist.strings. Если Ваше имя приложения не будет локализованным, по причинам производительности лучше не включать этот ключ в Info.plist. Обратите внимание на то, что существующий ключ CFBundleName (и локализация) все еще используется для локализованного «короткого» имени приложения, выведенного на экран в строке меню и о поле.

- Если Вы хотите создать папку, локализовавшую имена: (1) Предоставляют Вашей папке расширение файла «.localized» и отмечают расширение, как скрытый; (2) создают плоский пакет, названный «.localized» в папке (плоские пакеты являются в основном папками без подпапок Contents или Resources); (3) предоставление представляет файлы в виде строки с именами, такими как en.strings, содержа «NonlocalizedName» = «Локализованное имя». Пример:
Release Notes For My App.localized/
    .localized/
        en.strings (contains "Release Notes For My App" = "Localized name"; )
        ja.strings

Текст

Текстовые документы, имеющие тип Mac OS 'TEXT' и не имеющие никакой 'styl' информации о ветви ресурсов, будут возвращены, поскольку «простой текст» от различного AppKit приписал строковые методы, открывающие текстовые файлы. Они раньше идентифицировались как обогащенный текст. Даже если целый диапазон текста покрыт отдельным стилем, Обратите внимание на то, что файлы 'TEXT' с 'styl' информацией считают обогащенным текстом.

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

С новой поддержкой расстояния между абзацами мы обнаружили некоторые файлы RTF, которым установили значения расстояния между абзацами, но конечно никогда не выводимый на экран до сих пор. Это также оказывается вследствие Почтовой ошибки, которую некоторый текст копирует/вставляет с Почты, мог иметь поддельные значения расстояния между абзацами. Для фиксации их значения расстояния между абзацами в файлах RTF, сгенерированных Какао до 10,2, будут проигнорированы читателем RTF. Однако можно использовать значение по умолчанию NSIgnoreRTFParagraphSpacing для принуждения поведения так или иначе (никогда не игнорируют, всегда игнорируют). Обратите внимание на то, что как часть этой фиксации, значение атрибута документа CocoaRTFVersion было увеличено от 100 до 102.

Мы теперь чтение-запись - [NSParagraphStyle lineSpacing] (пространство между строками в абзаце, иначе ведя) в файлах RTF.

Главные текстовые системные объекты (NSTextView, NSTextContainer, NSLayoutManager и NSTextStorage) теперь поддерживают архивацию с помощью новой включенной архивации. Это позволяет произвольным конфигурациям текстовой системы быть заархивированными.

Пункты меню со вставкой действия: теперь автоматически отключите себя, когда первым респондентом является NSTextView и нет ничего в области монтажа в настоящее время, которая может быть вставлена в NSTextView.


NSParagraphStyle

NSParagraphStyle теперь имеет методы для основы, пишущий установку направления в реверсивном тексте. - [NSParagraphStyle baseWritingDirection] и - [NSMutableParagraphStyle setBaseWritingDirection:] методы доступа для атрибута. Можно использовать + [NSParagraphStyle defaultWritingDirectionForLanguage:] для запросов направления записи значения по умолчанию для данного имени локализации. Передающий ноль подразумевает настройку по умолчанию пользователя.

Позиции табуляции кроме левого (право, центрируемое, и десятичное число), теперь реализованы.


NSAttributedString

Методы разрыва текста NSAttributedString: - [NSAttributedString lineBreakBeforeIndex:withinRange:], - [NSAttributedString doubleClickAtIndex:], и - [NSAttributedString nextWordFromIndex:forward:], теперь имейте Unicode совместимые реализации.

Для обратной совместимости,-lineBreakBeforeIndex:withinRange: все еще возвращается, индекс передал в первом параметре, когда индекс равняется длине строки.


NSGlyphInfo

У нас теперь есть новый класс, NSGlyphInfo. Экземпляры этого класса используются для представления глифов в приписанных строках, разрешение Вам переопределить шрифт указало Unicode-> глиф отображение ID. Например, если шрифт содержит многократные изменения для символа с этим API, можно указать различный глиф для символа. Или можно указать определенный глиф лигатуры, не имеющий отображения Unicode. Следующий пример присваивает маленькую прописную букву глиф, часто находимый в шрифтах OpenType.
NSMutableAttributedString *attrString; // Pre-initialized attributed string
NSRange rangeOfStringToBeOverriden;
NSString *baseString = [[attrString string] substringWithRange:rangeOfStringToBeOverriden];
NSFont *font = [attrString attribute:NSFontAttributeName
atIndex:rangeOfStringToBeOverriden.location
effectiveRange:NULL];
NSGlyphInfo *smallCapitalAGlyph = [NSGlyphInfo glyphInfoWithGlyphName:@"Asmall"
forFont:font
baseString:baseString];
[attrString addAttribute:NSGlyphInfoAttributeName
value:smallCapitalAGlyph
range:rangeOfStringToBeOverriden];

Протокол NSTextInput

Служба ввода текста InkWell может попросить, чтобы Вы возвратили содержание своего клиента ввода текста, расширяющегося на Ваш диапазон документа; так реализация для метода NSTextInputProtocol,-attributedSubstringFromRange: должен быть подготовлен выйти из диапазона. В этом случае необходимо возвратить пересечение диапазона документа и диапазона, указанного в параметре. Если расположение диапазона имеет полностью за пределы Ваш диапазон документа, можно возвратить ноль.


NSTypesetter

У нас теперь есть новый, в настоящее время частный, подкласс NSTypesetter, включенный как системное наборное устройство по умолчанию. Это использует Службу Типа Apple для Функциональности обработки изображений Unicode экстенсивно, предоставляя приложениям усовершенствованные функции книгопечатания, такие как умное заключение в кавычки и контекстно-зависимый плеск, и расширяя поддержку языков в платформе AppKit.

Для обеспечения надежной текстовой совместимости расположения между выпусками Mac OS X для приложений текстовая подсистема AppKit имеет новый APIs для управления различными аспектами текстового управления расположением в платформе.

NSLayoutManager теперь имеет новые методы:
- (NSTypesetterBehavior)typesetterBehavior;
- (void)setTypesetterBehavior:(NSTypesetterBehavior)behavior;
NSTypesetterBehavior определяется как:
typedef enum {
NSTypesetterLatestBehavior = -1,
NSTypesetterOriginalBehavior = 0,
NSTypesetterBehavior_10_2_WithCompatibility = 1,
NSTypesetterBehavior_10_2 = 2,
} NSTypesetterBehavior;
Установка значения NSTypesetterLatestBehavior заставляет менеджера по расположению использовать последнее (наиболее усовершенствованное) наборное устройство, доступное в системе. Это - значение по умолчанию и подходяще для большинства использований. На 10,2, это соответствует NSTypesetterBehavior_10_2. Это активирует все новые опции в новом наборном устройстве и исправляет ошибки в реализации NSSimpleHorizontalTypesetter:

- Это не добавляет дополнительный один пиксель к надстрочному элементу по умолчанию, вызванному погрешностью округления с плавающей точкой, найденной в предыдущей реализации наборного устройства
- Значения возвратились из - [NSParagraphStyle firstLineHeadIndent], и - [NSParagraphStyle headIndent] интерпретируются как ожидалось со всеми режимами выравнивания текста
- Значение, возвращенное из - [NSParagraphStyle paragraphSpacing], используется наборным устройством
- Это не добавляет дополнительные 20%, приводящих к надстрочному элементу больше кроме с Helvetica, Времена, Курьер, которые уже обычно используются в пользовательском интерфейсе.
- Даже если атрибут установлен в целый абзац, это интерпретирует значение в NSBaselineOffsetAttributeName.

NSTypesetterBehavior_10_2_WithCompatibility ведет себя так же, как NSTypesetterBehavior_10_2 кроме упомянутых выше ошибок сохраняются для приложений, хотящих использовать новое наборное устройство и полагающихся на поведение в реализации NSSimpleHorizontalTypesetter.

NSTypesetterOriginalBehavior обеспечивает 100%-ю совместимость при помощи NSSimpleHorizontalTypesetter. Вы не получите новые функции.

Существует 2 настройки по умолчанию для управления поведением наборного устройства по умолчанию: «NSTypesetterBehavior» принимает целочисленные значения от 0 до 2 соответствий перечисляемым значениям в типе NSTypesetterBehavior. Другие значения интерпретируются как NSTypesetterLatestBehavior. Значение по умолчанию для приложений основывалось 10.2, NSTypesetterBehavior_10_2, и значение по умолчанию для приложений основывалось на предыдущих версиях, NSTypesetterOriginalBehavior. Значение доступно через новый метод класса NSTypesetter +defaultTypesetterBehavior.

«NSStringDrawingTypesetterBehavior» принимает целочисленные значения от 0 до 2 соответствий перечисляемым значениям в типе NSTypesetterBehavior. Другие значения интерпретируются как NSTypesetterLatestBehavior. Это - значение, используемое строковыми методами рисования и подклассами NSCell. Когда этот ключ не присутствует в базе данных по умолчанию, он использует значение для NSTypesetterBehavior, принимая значение явно набор и меньше, чем значение по умолчанию для NSStringDrawingTypesetterBehavior. Значение по умолчанию для NSStringDrawingTypesetterBehavior для приложений основывалось 10.2, NSTypesetterBehavior_10_2_WithCompatibility, и значение по умолчанию для приложений основывалось на предыдущих версиях, NSTypesetterOriginalBehavior.

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

В NSTypesetterBehavior_10_2 и NSTypesetterBehavior_10_2_WithCompatibility, новом Unicode используется сверхпораженный алгоритм надписи глифа на основе 3.2. Это покрывает все комбинированные символы, определенные в символьном стандарте, кроме тех в Devanagari, бенгальском языке, Gurmukhi, Gujarati, языке ория, тамильском, языке телугу, каннаде, Малайяламе, Sinhara, тайском языке и Мьянме (U0900 - U0E7F и U1000 - U109F). Комбинированные символы в этих сценариях требуют шрифтов с Apple Усовершенствованное Книгопечатание capabiliity. Новое наборное устройство пытается предварительно сочинить перед отступанием к присоединяемому алгоритму размещения на основе объединяющегося класса, приводящего к лучшей замене глифа со шрифтами, испытывающей недостаток в таблицах Apple Advanced Typography. Существует теперь порог для числа последовательных сверхпораженных глифов. Последовательность символов, имеющая больше комбинированных символов, чем этот порог, не предварительно составлена. Значение по умолчанию является 10 глифами. Установка может быть переопределена через значение по умолчанию «NSMaxNonBaseInscriptionGlyphs».

Известные проблемы с NSTypesetterBehavior_10_2 и NSTypesetterBehavior_10_2_WithCompatibility:

- Значения NSGlyphInscription кроме NSGlyphInscribeBase и NSGlyphInscribeOverstrike проигнорированы
- Две опции Apple Advanced Typography, выравнивание контекста-senstive и уехавшие/исправленные кронштейны, явно отключены в этом выпуске.


NSInputManager

По умолчанию NSInputManager больше не ищет/Network/Library/InputManagers менеджеров по вводу. Можно переопределить это поведение путем установки пользовательской настройки NSSearchNetworkForInputManagers в YES для загрузки менеджеров по вводу по сети.


NSFont

Новый API,-coveredCharacterSet, добавляется к NSFont. Это возвращает NSCharacterSet, содержащий все номинальные символы, renderable получателем. Другими словами, это возвращает все записи, отображенные в 'cmap' таблице шрифта. Обратите внимание на то, что число глифов, поддерживаемых данным шрифтом, часто больше, чем число символов, содержавшихся в наборе символов, возвращенном этим методом. Например, шрифт может иметь 'tt' глиф лигатуры, но это не будет в наборе символов, так как глиф не имеет соответствующего Значения Unicode.


NSFontPanel

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


NSColorPanel

Панель стандартного цвета теперь имеет режим «мелка», предлагающий пользователю ряд предопределенных цветов для выбора из. Цвета мелка также доступны в средстве выбора «списка» путем выбора «Crayons» в кнопке всплывающего меню «Палитры». Две новых константы были добавлены к NSColorPanel.h для размещения этого нового режима выбора цвета:
    NSCrayonModeColorPanel        = 7
NSColorPanelCrayonModeMask    = 0x00000080

Кнопка «Apply» была удалена из цветной панели. NSColorPanel раньше вызывал метод респондента 'changeColor': каждый раз, когда была нажата эта кнопка. Так как кнопка больше не там, 'changeColor': будет сразу отправлен первому респонденту на цветном изменении. Этот метод респондента будет отправляться постоянно, только если цветная панель установлена быть непрерывной.


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


В прошлом цветная панель использовала матрицу кнопок для представления как матрица кнопок. Цветная панель теперь использует маленький значок только панель инструментов. Так, необходимо удостовериться, что значок выглядит хорошим как маленькая панель инструментов значки (см. NSToolbarItem relnotes для получения дополнительной информации). Обратите внимание на то, что в прошлом изображение кнопки и подсказка могли быть предоставлены путем переопределения-provideNewButtonImage и/или-insertNewButtonImage:in:. Это все еще имеет место.


NSProgressIndicator

10.2 приносит поддержку вращающегося стиля в дополнение к текущему стилю панели. Следующий API был добавлен для поддержки этого нового стиля.
typedef enum {
NSProgressIndicatorBarStyle = 0,
NSProgressIndicatorSpinningStyle = 1
} NSProgressIndicatorStyle;
- (void) setStyle:(NSProgressIndicatorStyle)style;
- (NSProgressIndicatorStyle)style;
// For the spinning style, it will size the spinning arrows to their default size.
// For the bar style, the height will be set to the recommended height.
- (void) sizeToFit;
// True by default; for spinning style, might make sense to choose
// to have it not displayed when stopped.
- (BOOL) isDisplayedWhenStopped;
- (void) setDisplayedWhenStopped:(BOOL)isDisplayed;

NSDocumentController

Если существует тот, NSDocumentController пытается создать новый документ во время запуска приложения с помощью первого подходящего типа документа, объявленного в файле приложения Info.plist. В предыдущих выпусках Mac OS X тип документа считали подходящим, если его словарь Info.plist содержал запись CFBundleTypeRole, значение которой было «Редактором» или «Средством просмотра». Вследствие широко распространенного беспорядка это вызвало среди разработчиков, использовавших архитектуру документа Какао для записи приложений только для средства просмотра, это поведение было изменено. Теперь, NSDocumentConroller попытается создать новый документ во время запуска с помощью первого типа, чья запись CFBundleTypeRole словаря Info.plist является «Редактором», если существует тот. Типы документов, для которых приложение может только принять роль «Средства просмотра», не рассмотрят.

Для назад совместимости на уровне двоичных кодов NSDocumentController покажет то же поведение в этом отношении, как это сделало в Mac OS 10.1 при выполнении в программах, соединенных против 10.1 или более ранних версий платформ AppKit или Какао.


В предыдущих выпусках Mac OS X, - [NSDocumentController typeFromFileExtension] выдержал сравнение, передал - в расширениях файла к расширениям, объявленным в Info.plist приложения чувствительным к регистру способом. В результате находящиеся в NSDocument приложения были часто неспособны открыться, документы с расширениями файла случились способом, непредвиденным разработчиками приложений. Например, документы с расширением файла «PDF» не могли быть открыты приложением, Info.plist которого содержал массив CFBundleTypeExtensions, содержавший только запись «PDF». Эта ошибка была исправлена. Некоторые разработчики работали вокруг этого путем избыточного перечисления расширений файла в Info.plist их приложения с избыточными записями, варьирующимися только регистром символов. Такое обходное решение больше не необходимо для приложений, не требующихся, чтобы работать на выпусках Mac OS X, более старого, чем 10,2.


NSPrinter

Были осуждены некоторые методы NSPrinter. Они:
- (NSRect)imageRectForPaper:(NSString *)paperName;
+ (NSPrinter *)printerWithName:(NSString *)name domain:(NSString *)domain includeUnavailable:(BOOL)flag;
- (NSString *)domain;
- (NSString *)host;
- (NSString *)note;
- (BOOL)acceptsBinary;
- (BOOL)isColor;
- (BOOL)isFontAvailable:(NSString *)faceName;
- (BOOL)isOutputStackInReverseOrder;
См. комментарии в заголовочном файле <AppKit/NSPrinter.h> больше более определенной информации.


В предыдущих выпусках Mac OS X, - [NSPrinter printerNames] возвратил имена всех NetInfo-зарегистрированных принтеров, независимо от того, были ли принтеры добавлены к Списку Принтера Центра Печати. Это поведение было изменено. - [NSPrinter printerNames] теперь возвращает имена тех же принтеров, появляющихся в списке принтера.

В предыдущих выпусках Mac OS X, - [NSPrinter printerTypes] всегда возвращал массив, содержавший точно одну строку («Xrn4525p»). Это теперь возвращает строки, содержащие делать и модели принтеров, появляющихся в списке принтера.


NSPrintInfo

Важно во многих приложениях быть в состоянии надежно определить максимальную область изображения печатной страницы. Новый метод был добавлен к NSPrintInfo:
- (NSRect)imageablePageBounds;
Возвращает область изображения листка бумаги, указанного этим объектом, принимая во внимание текущий принтер, формат бумаги, и настройки ориентации, но не масштабирование. «Область изображения» является максимальной областью, которая может возможно быть отмечена на аппаратными средствами принтера, не областью, определенной текущими установками поля. Прямоугольник находится в координатном пространстве, измеренном точками, с (0, 0) быть нижним левым углом ориентированного листа и (paperWidth, paperHeight) быть верхним правым углом ориентированного листа. Вызывающие мысленный образ границы могут расшириться мимо краев листа, когда, например, драйвер принтера указывает его так, чтобы безграничная печать могла быть сделана надежно.


Были осуждены некоторые методы NSPrintInfo. Они:
+ (void)setDefaultPrinter:(NSPrinter *)printer;
+ (NSPrinter *)defaultPrinter;
+ (NSSize)sizeForPaperName:(NSString *)name;
Кроме того, были осуждены некоторые атрибуты NSPrintInfo. Они:
NSPrintFormName
NSPrintJobFeatures
NSPrintManualFeed
NSPrintPagesPerSheet
NSPrintPaperFeed
См. комментарии в заголовочном файле <AppKit/NSPrintInfo.h> больше более определенной информации.


Печать предварительных установок

Новый начиная с обновления WWDC 10,2, Mac OS X теперь имеет поддержку «печати предварительных установок». С этой функцией драйвера принтера могут указать имена для обычно используемых наборов печати значений параметров, таким образом, пользователи могут выбрать такие наборы легко. Например, когда эта опция активирована, и когда принтер, поддерживающий эту функцию, выбран, пользователь мог бы видеть элементы как «фотография на Простой бумаге» в меню Presets панелей печати. Для активации этой опции приложения должны обеспечить подсказку о том, какое задание печати выводится. Новые методы были добавлены к Какао для этого.

Прямо сейчас только один стиль задания печати поддерживается. Это идентифицируется постоянной строкой, добавленной к NSPrintPanel.h. Это - объявление, похож на это:
NSString *NSPrintPhotoJobStyleHint;
Это в настоящее время - единственное допустимое значение для идентификации подсказки стиля задания.

Два новых метода были добавлены к NSPrintPanel.h:
- (void)setJobStyleHint:(NSString *)hint;
- (NSString *)jobStyleHint;
Наборы или получают строку, обеспечивающую подсказку о типе задания печати, в котором используется панель печати. Это управляет набором элементов, появляющихся в меню Presets. В настоящее время строкой должен быть NSPrintPhotoJobStyleHint или ноль для обеспечения подсказки.

Методы сопоставления были добавлены к NSPrintOperation.h:
- (void)setJobStyleHint:(NSString *)hint;
- (NSString *)jobStyleHint;
Наборы или получают строку, обеспечивающую подсказку о типе задания печати. Это управляет набором элементов, появляющихся в меню Presets панели печати, представленной этой работой, если это представляет тот. В настоящее время строкой должен быть NSPrintPhotoJobStyleHint или ноль для обеспечения подсказки.


NSWindow

- [NSWindow setBackgroundColor:] теперь вступит в силу независимо от окна styleMask. В 10,1, - [NSWindow setBackgroundColor:] только изменил цвет фона для безграничных окон (т.е. окон с styleMask, равным NSBorderlessWindowMask).

Существует теперь styleMask, чтобы указать, что окно имеет текстурированный фон, NSTexturedBackgroundWindowMask. Windows с этим styleMask получает текстурированный металлом фон, подобный фону в iApp окнах. Окно с этим styleMask может быть перемещено путем перетаскивания где угодно в фоне окна, в противоположность окну без этого styleMask, который может только быть перемещен путем перетаскивания в строке заголовка. Ограниченное окно с этим styleMask также получит округленные нижние углы. Безграничному окну можно также дать этот styleMask, чтобы указать, что это должно иметь текстурированный металлом фон и быть подвижно фоном окна.

Существует теперь метод, чтобы указать, что пользовательское окно должно быть подвижным своим фоном и методом для запросов этой установки. Окно, styleMask которого включает NSTexturedBackgroundWindowMask, получает эту установку по умолчанию, за исключением того, что это не позволяется для листов и секций.
- (void)setMovableByWindowBackground:(BOOL)flag;
- (BOOL)isMovableByWindowBackground;
Также посмотрите обсуждение - [NSView mouseDownCanMoveWindow] далее ниже.


Включенная архивация для NSWindow является недопустимой работой. Попытка заархивировать или разархивировать NSWindow использование включенного кодера повысит NSInvalidArgumentException.


Следующие изменения NSWindow являются новыми начиная с выпуска WWDC 10,2.

-windowRef метод был изменен для создания Углерода WindowRef, если Вы уже не существуете для окна. Этот метод ранее возвратился, WindowRef только для NSWindow, создаваемого с помощью-initwithwindowref:.-windowRef, может теперь использоваться для создания WindowRef для окна, содержащего управление Углеродом. Последующие вызовы к методу возвратят существующий WindowRef.


Существует новый API, чтобы создать и получить доступ к кнопкам в строке заголовка окна:
typedef enum {
    NSWindowCloseButton,
    NSWindowMinimizeButton,
    NSWindowZoomButton,
    NSWindowToolbarButton,
    NSWindowDocumentIconButton
} NSWindowButton;
Следующий метод возвращает автовыпущенный новый экземпляр данной стандартной кнопки, измеренной соответственно для styleMask. Вызывающая сторона ответственна за добавление кнопки к иерархии представления и для того, чтобы поставить цель, чтобы быть окном:
+ (NSButton *)standardWindowButton:(NSWindowButton)b forStyleMask:(unsigned int)styleMask
Следующие возвраты данная стандартная кнопка, если это находится в иерархии представления окна:
- (NSButton *)standardWindowButton:(NSWindowButton)b

Существует новый API для присоединения одного окна к другому в целях переместить и упорядочить. childWin будет упорядочиваться или выше (NSWindowAbove) или ниже (NSWindowBelow) получатель и сохраняться в той относительной позиции для последующих операций упорядочивания, включающих любое окно. В то время как это присоединение активно, перемещение childWin не заставит получатель перемещаться (как в задвижение секции или), но перемещение получателя заставит childWin перемещаться:
- (BOOL)addChildWindow:(NSWindow *)childWin ordered:(NSWindowOrderingMode)place
Запрашивать массив присоединенных дочерних окон:
- (NSArray *)childWindows
Отсоединять childWin от получателя:
- (void)removeChildWindow:(NSWindow *)childWin
Получить родительское окно, к которому получатель присоединяется как дочерний элемент:
- (NSWindow *)parentWindow
Узкое место для установки parentWindow ivar в получателе. Может быть переопределен подклассами; должен вызвать супер:
- (void)setParentWindow:(NSWindow *)window
Обратите внимание на то, что упорядочивание операций на дочернем элементе также произведет родителя, таким образом, дочернее окно должно будет обычно быть удалено из его родителя, прежде чем childWindow прикажут уйти.


Существует теперь API для создания окна очевидным для событий от нажатия мыши, позволяя окна наложения. Установить, очевидно ли окно для щелчков мышью и других событий от нажатия мыши, позволяя окна наложения:
- (void)setIgnoresMouseEvents:(BOOL)flag;
Возвратитесь, очевидно ли окно для событий от нажатия мыши:
- (BOOL)ignoresMouseEvents;
Если окно пользовательской формы имеет тень, тень должна быть обновлена, когда окно изменяет форму. Следующий метод лишит законной силы тень окна так, чтобы это было повторно вычислено на основе текущей формы окна:
- (void)invalidateShadow;

NSPanel

10.2 приносит понятие панели неактивации. Панель неактивации может получить ввод с клавиатуры, не активируя его приложение владения. Для поддержки этого styleMask был добавлен к NSPanel.h:
enum {
    ...
NSNonactivatingPanelMask = 1 << 7
};
Этот styleMask может быть передан определяемому инициализатору NSPANEL:
- (id)initWithContentRect:(NSRect)contentRect styleMask:(unsigned int)aStyle backing:(NSBackingStoreType)bufferingType defer:(BOOL)flag;
Обратите внимание на то, что как NSUtilityWindowMask, NSNonactivatingPanelMask только допустим для NSPanel или подкласса, это не допустимо для NSWindow.

Этот тип панели наследовал метод NSPANEL для указания, должна ли панель стать ключевой, когда активировано, или только если необходимый:
- (BOOL)setBecomesKeyOnlyIfNeeded:(BOOL)flag;
Если с этим методом вызывают ДА, то панель неактивации становится ключевой, только если представление хита возвращает YES для-needsPanelToBecomeKey. Таким образом панель неактивации может управлять, крадет ли она клавиатурный фокус или нет. Внутренне, мы позволим событиям клавиатуры быть направленными к панели, не требуя, чтобы приложение владения было активно. Панели неактивации с клавиатурным фокусом свяжут появление с ключевыми окнами, включая фокусирующие кольца, курсор rects и мерцающий курсор в подходящих случаях. Даже если ее приложение владения не активно, панель неактивации может быть сделана ключевой.


NSView

Автокалибровка NSVIEW машинного оборудования больше не корректирует y источник к 0, когда это становится отрицательным. В предшествующих выпусках NSView раньше корректировал y источник к 0, когда это становится отрицательным, часто приводя к недоступным представлениям, продвинутым за окном. Когда вертикальным autoresizingMask является NSViewMinYMargin, поведение корректировки удалено.

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


Новый начиная с обновления WWDC 10,2, NSView теперь имеет новый метод, позволяющий представлению указывать, должно ли это быть обработано как блокирование окна, перемещающегося для mouseDown в его границах. Это только применяется к представлениям в окнах, возвращающих YES для-isMovableByWindowBackground. Если представление не непрозрачно и НЕ иначе, реализация по умолчанию возвращает YES. NSControl и другие стандартные представления, реализующие mouseDown: возвратитесь НЕ для этого метода. Пользовательское представление должно реализовать этот метод для возврата НЕ, если это хочет отключить окно, перемещающееся для mouseDown: в границах представления. Это - дополнение к NSView.h:
- (BOOL)mouseDownCanMoveWindow;

NSResponder

Метод был добавлен к NSResponder для различения, когда перо вниз должно начать обводить чернилами по сравнению с тем, когда это должно быть обработано как мышь вниз событие. Это необходимо для поддержки модели записи где угодно для основанного на пере ввода.
- (BOOL)shouldBeTreatedAsInkEvent:(NSEvent *)event;
Параметром события является мышь вниз с данными планшета. Этот метод возвращает YES, если событие должно быть обработано как событие чернил, НЕТ если это должно быть обработано как событие от нажатия мыши.

Перо вниз заставляет этот метод быть отправленным в NSApplication. Реализация по умолчанию в NSApplication отправляет метод в NSWindow под пером. Если окно неактивно,-shouldBeTreatedAsInkEvent: возвраты ДА, если перо вниз не находится в окне, перетаскивают область.

Если окно активно,-shouldBeTreatedAsInkEvent: будет отправлен в NSView под пером. Реализация по умолчанию в возвратах NSView и NSControl переопределяют для возврата НЕТ. Это позволяет запись где угодно по большей части NSViews, но также и позволяет перу использоваться, чтобы отследить в средствах управления и переместить окна.

Пользовательское представление должно переопределить этот метод в случае необходимости для получения корректного поведения для пера вниз в представлении.


Обещания HFS

Какао теперь поддерживает перетаскивание Обещаний HFS и для источника перетаскивания и для места назначения перетаскивания. Это было добавлено начиная с выпуска WWDC 10,2.

NSView, действующий как источник перетаскивания для обещаний HFS, должен вызвать - [NSView dragPromisedFilesOfTypes:fromRect:source:slideBack:event:]. Когда перетаскивание будет отброшено, этот метод запишет новый тип области монтажа, NSFilePromisePboardType, с данными, состоящими из массива типов файлов, и также запишет частный тип, необходимый, чтобы позволить месту назначения просить имена файлов. Это - дополнение к NSView.h:
- (BOOL)dragPromisedFilesOfTypes:(NSArray *)fileTypes fromRect:(NSRect)aRect source:(id)sourceObject slideBack:(BOOL)slideBack event:(NSEvent *)theEvent
типы файлов - массив расширений типа файла, например, [NSArray arrayWithObject:@ «txt»], чтобы обещать одному файлу с .txt расширением, или [NSArray arrayWithObjects:@ «PDF», «PDF», ноль] обещать два файла с расширением pdf. Это также быть возможным обещать типы HFS, с помощью NSFileTypeForHFSTypeCode.
настороженный - описывает позицию перетащенного изображения, представляющего обещание файла
sourceObject - контроллер работы перетаскивания, которая должна соответствовать протоколу NSDraggingSource
slideBack - если перетаскивание отклоняется, должно ли перетащенное изображение slideback
theEvent - объект события mouseDown, от которого можно инициировать работу перетаскивания

    Если работа перетаскивания успешно инициируется, НЕТ иначе, этот метод возвращает YES.

Когда перетаскивание отбрасывается на месте назначения, принимающем обещания HFS,-namesOfPromisedFilesDroppedAtDestination: будет вызван на sourceObject. Это - дополнение к NSDraggingSource неофициальный протокол:
 -(NSArray *)namesOfPromisedFilesDroppedAtDestination:(NSURL *)dropDestination
dropDestination - URL, представляющий расположение отбрасывания

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

Источник перетаскивания будет использовать - [NSView dragPromisedFilesOfTypes:fromRect:source:slideBack:event:] для обещания одного или более файлов для перетаскивания, но задержит создание этих файлов, пока перетаскивание не было отброшено, так, чтобы обещанные файлы могли быть созданы в их конечном месте назначения. Фактическое содержание файлов не должно быть записано, пока перетаскивание не было выпущено, если файлы большие, для предотвращения блокирования места назначения во время длинной работы файла. Кроме того, источник может обещать каталог верхнего уровня, затем заполнить содержание каталога после того, как было выпущено перетаскивание.

Местом назначения может быть или Углерод или Какао. Если местом назначения является Какао,-performDragOperation: когда перетаскивание отбрасывается, вызывается на месте назначения. В этой точке место назначения должно вызвать новый метод на NSDraggingInfo для получения имен для обещанных файлов, передав место назначения отбрасывания. Это - дополнение к протоколу NSDraggingInfo:
 -(NSArray *)namesOfPromisedFilesDroppedAtDestination:(NSURL *)dropDestination
dropDestination - URL, представляющий расположение отбрасывания

Возвращается массив имен файлов для создаваемых файлов - отмечают, что это - имена файлов только, не полные пути

Это вызовет IPC к источнику, который вызовет-namesOfPromisedFilesDroppedAtDestination: на источнике перетаскивания, если источник является Какао или попросит данные обещания HFS, если источником перетаскивания является Углерод.


NSPasteboard

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

- declareTypes:owner: теперь должным образом возвращает количество изменения области монтажа. Это выравнивается с задокументированным поведением. Это раньше возвращалось 0.

- addTypes:owner: теперь должным образом возвращает количество изменения pastebaord. Это выравнивается с задокументированным поведением. Это раньше возвращалось-1 или 0.

-dataForType: метод теперь ожидает в течение более длительного времени обещаний, которые будут выполнены, или целочисленные секунды, данные значением по умолчанию NSPasteboardPromiseTimeout, или 120 секунд, если не существует значение по умолчанию.


AppKit добавил новую константу, NSVCardPboardType, для представления VCards на области монтажа. AppKit ничего не делает с данными этого типа, это просто экспортирует тип для клиентов.


Тайм-ауты поиска сервера области монтажа

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

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

        Значение по умолчанию NSPBSServerLookupTimeout: 10 секунд
            Значение по умолчанию NSPBSServerSendTimeout: 20 секунд
            Значение по умолчанию NSPBSServerReplyTimeout: 60 секунд


NSSound

NSSound теперь использует QuickTime для игры большинства звуковых ФАЙЛОВ/URLS, включая потоковую передачу нефайла URLs из Интернета. Так как QuickTime требует, чтобы цикл выполнения был выполнен для звука (или фильмы), чтобы продолжать играть, NSSound теперь требует этого также. Делегат-sound:didFinishPlaying: не будет также вызван, если не выполняется цикл выполнения. «Выполненным циклом», то, что предназначается, является циклом выполнения на потоке, запускающем звуковую игру. Для приложений Какао это не грандиозное предприятие для звуков, играемых основным потоком, поскольку приложения Какао обычно позволяют AppKit обработать выполнение цикла выполнения на основном потоке. Но в других ситуациях необходимо будет знать об этом требовании.


NSEvent

Когда объединение события отключено, в 10,2, и начиная с семени WWDC, сервер окна начал устанавливать дополнительный зависящий от устройств флаг модификатора в событиях ввода данных пользователем для указания. Приложения, проверяющие на modifierFlags использование равенства, не маскируя от зависящего от устройств modifierFlags сначала, могут получить неожиданное поведение вследствие этого изменения. Для поддержания совместимости для приложений, основывался 10.2 и более ранние системы, NSEvent значениями по умолчанию разделяет этот зависящий от устройств флаг модификатора при создании события из windowServer события. Поскольку приложения основывались на системах позже, чем 10,2, это больше не будет поведением по умолчанию. Для переопределения поведения NSEVENT по умолчанию приложение может указать значение для пользовательского значения по умолчанию NSDeviceDependentModifierFlags. Если это значение по умолчанию будет установлено в то ДА, зависящие от устройств флаги модификатора не будут разделены.


NSWorkspace

NSWorkspace теперь содержит два дополнительных метода для контакта со списком запущенных приложений. В целях этих методов приложение указано путем возврата словаря со столькими следующими ключами, сколько доступны:

NSApplicationPath (полный путь к приложению, как строка)
NSApplicationName (имя приложения, как строка)
NSApplicationProcessIdentifier (ID процесса приложения, как NSNumber)
NSApplicationProcessSerialNumberHigh (верхний уровень долго PSN, как NSNumber)
NSApplicationProcessSerialNumberLow (нижний уровень долго PSN, как NSNumber)

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

Новые методы:
- (NSArray *)launchedApplications;
- (NSDictionary *)activeApplication;
Первый из этих возвратов массив этих словарей для всех запущенных приложений (те, за которыми уведомление запуска желания было бы отправлено), в то время как вторые возвраты словарь для текущего frontmost приложения.


NSSavePanel

Если-setTreatsFilePackagesAtDirectories: был отправлен в панель сохранения, в то время как это было на экране, браузер войдет в недопустимое состояние и не обновит должным образом к новому состоянию панели. Пользователь должен был «щелкнуть вокруг» в браузере для обновления его. Это было фиксировано. Это позволяет-setTreatsFilePackagesAtDirectories: быть вызванным, например, как результат пользователя, переключающего переключатель во вспомогательном представление панели.


Представления аксессуара являются теперь частью цикла клавиатуры (NSColorPanel, NSSavePanel, NSOpenPanel, проверяя правописание панели)

Много системных панелей позволяют разработчикам указывать пользовательское вспомогательное представление, которое будет выведено на экран как часть панели. В предыдущей версии Mac OS X те представления аксессуара не становились частью цикла клавиатуры панелей. Это было фиксировано для нескольких системных панелей, включая: NSSavePanel, NSOpenPanel, NSColorPanel и совместно используемая панель проверки правописания. Можно указать собственный цикл клавиатуры во вспомогательном представление. Эти системные панели обрабатывают вспомогательное 'nextKeyView' представления во многом как initialFirstResponder NSWindow (см. примечания в NSWindow на автоматически сгенерированных циклах клавиатуры). Если nextKeyView представления не будет установлен, то будет предполагаться, что Вы не указали свой собственный цикл клавиатуры, и каждый будет вычислен для Вас. Если 'nextKeyView' будет установлен, то Ваш цикл будет использоваться. Обычно автоматически вычисленный цикл клавиатуры сделает то, что Вы хотите.


NSTabView

NSTabView теперь имеет поддержку направленных вкладок - NSLeftTabsBezelBorder, NSBottomTabsBezelBorder, и типы представления вкладки NSRightTabsBezelBorder теперь реализованы. Эти стили могут быть выбраны в InterfaceBuilder, или вызовами к-setTabViewType:. Можно проверить на поддержку этой новой функции путем сравнения с константой:
    #define NSAppKitVersionNumberWithDirectionalTabs 631.0
Никакой новый API не был представлен для поддержки направленных вкладок. Однако существуют проблемы с некоторым существующим API, требующим объяснения.

Во-первых, определите нормальную ось, чтобы быть одним данным направлением вкладки. Так, для вкладок NSRightTabsBezelBorder нормальная ось указывает на восток, или слева направо через экран. Затем, определите ось метки для перпендикуляра нормальной оси. Ширина метки всегда измеряется вдоль оси метки и высоты вдоль нормальной оси. Учитывая эти определения, мы разъясняем эффект на существующий APIs:
    NSTabViewItem:
    - (void)drawLabel:(BOOL)shouldTruncateLabel inRect:(NSRect)labelRect;
    // This method draws the tab label in labelRect.
    // 'labelRect' is the area in between the curved end caps.
    // 'shouldTruncateLabel' is a hint that the label should be truncated.
    - (NSSize)sizeOfLabel:(BOOL)computeMin;
    // This method returns the minimum or nominal size of the tab label.
    // 'computeMin' indicates whether you should return the minimum or
    // nominal label size. The returned value is used to
    // compute the range of legal sizes for the tab label.
- drawLabel:inRect: предполагает, что метка и нормальная ось приезжают ось x и y соответственно. Этот метод вызывает NSTabView после преобразования системы координат для достижения этого эффекта. Так, разработчиками по умолчанию может нарисовать все вкладки, как будто они были севером, бывшим обращенным (к NSTopTabsBezelBorder).

- sizeOfLabel: также возвращает ширину и высоту метки элементов. Ширина метки измеряется вдоль оси метки, и высота измеряется вдоль нормальной оси.


NSBrowser

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

Браузеры больше не включают свои заголовки в прямоугольнике фокусирующего кольца. Фокусирующее кольцо будет всегда включать просто столбцы (и горизонтальный скроллер если настоящее).


NSTableColumn

Ошибка была обнаружена в 10,1, который не мог быть фиксирован в 10,2. Столбцы таблицы, создаваемые в IB, имеют ячейки данных с различными свойствами, чем создаваемые с alloc/init. NSTableColumns, происходящие из IB (Или прямо от палитры, или сделанный через вставку копии), будут содержать NSTextFieldCell, drawsBackground свойство которого нет, и чей шрифт составляет 13 ПБ. Lucida Grande. Когда NSTableColumn будет создан с помощью [[выделение NSTableColumn] initWithIdentifier:@ «foo»], это будет содержать NSTextFieldCell, drawsBackground свойство которого ДА, и чей шрифт составляет 12 ПБ. Lucida Grande. Пока это не фиксируется, может быть необходимо проверить / фиксируют высоты шрифта Ваших таблиц в коде.


NSColor

isEqual: на образце цвета теперь должным образом возвратятся НЕ с параметрами, которые не являются цветами. Это раньше повышало исключение.


colorWithPatternImage: используемый для возврата неавтовыпущенных цветов. Поскольку приложения соединились пост10.1, это правильно автовыпустит возвращаемое значение. Если Вы не сохраняли возвращаемое значение, Ваше приложение откажет, как только это соединяется в пост10.1 системах. Фиксация должна сохранить цвет. Если необходимо динамично проверить эту фиксацию, искать версию AppKit> = NSAppKitVersionNumberWithPatternColorLeakFix (или если использование цветов образца является маленьким---, выделенные---всего нескольких экземпляров позволяют 10,1 утечкам версии).


NSColor теперь имеет следующие дополнительные стандартные цвета. Они параллельны существующему selectedControlColor и selectedControlTextColor:
+ (NSColor *)alternateSelectedControlColor;
+ (NSColor *)alternateSelectedControlTextColor;
Эти цвета предназначаются, чтобы использоваться в таблицах и списках, где желаемы Почта или iTunes как выделение. Для неактивных элементов в этих ситуациях используйте существующие методы secondarySelectedControlColor и selectedControlTextColor. Обратите внимание на то, что в этом неактивном контексте не означает отключенный; это означает неключ (иначе вторичный).

Посмотрите ниже («Альтернативные цвета выделения») для обсуждения использования их, раскрашивает AppKit.


Альтернативные цвета выделения

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

Когда таблица/схема или браузер активно фокусируются (управление, получающее события клавиатуры, т.е. это - первый респондент и в ключевом окне), они покажут выборы с помощью нового альтернативного цвета подсветки, + [NSColor alternateSelectedControlColor]. Для браузеров только последний столбец будет использовать + [NSColor alternateSelectedControlColor]. В 10,1, использовался +selectedControlColor.

Если таблица/схема или браузер активно не фокусируются тогда, это использует + [NSColor secondarySelectedControlColor]. Для браузеров этот цвет используется для каждого столбца кроме последнего выбранного столбца. Этот процесс совпадает с ним, был в 10,1; однако, значение цвета изменилось. Это раньше было более легкой версией + [NSColor selectedControlColor], теперь это - просто светло-серый. (И ясно это могло изменить в будущем, поэтому, предположениях.)

Если строка будет выделена с помощью + [NSColor alternateSelectedControlColor], то NSCell будет автоматически использовать + [NSColor alternateSelectedControlTextColor] вместо + [NSColor controlTextColor] при рисовании. Автоматическое использование цвета дополнительного текста только произойдет, если цвет текста Вашей ячейки будет установлен в + [NSColor controlTextColor], или значения RGB Вашего цвета текста совпадают с + [NSColor controlTextColor]. Кроме того, NSCell не изменит сохраненный цвет текста Вашей ячейки. Это просто решит нарисовать с различным цветом в подходящих случаях.

Принятие новой схемы выделения:
- Большинство ничего не должно будет делать для этого для работы.
- Если Вы рисуете часть своей собственной таблицы/схемы, браузера или выделений ячейки, необходимо проверить, что они все еще выглядят хорошо. Если они не делают, это, вероятно, потому что Вы - жесткое кодирование Ваше использование цветов. При рисовании выделений рекомендуется спросить NSCell что цвет использовать путем вызова-highlightColorWithFrame:inView:.
- Если Вы делаете свое собственное текстовое получение (использующий строковые подпрограммы рисования) или устанавливаете Ваши собственные цвета текста, удостоверьтесь, что корректные цвета используются в качестве надлежащих. Так как распространено разделить NSCells на подклассы, и сделать это, ниже является примером того, как сделать текстовое выделение.

Если Вы не можете использовать альтернативные цвета по некоторым причинам, можно установить значение по умолчанию NSAlternateListHighlightCompatibility_10_1 в YES.
    - (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView *)controlView {
NSColor *highlightColor = [self highlightColorWithFrame:cellFrame inView:controlView];
BOOL highlighted = [self isHighlighted];
        if (highlighted) {
    [highlightColor set];
NSRectFill(cellFrame);
}
        // Draw the icon
        if (myImage) {
            .....
        }
        // Draw the text (myTitle is an NSAttributedString)
        if (myTitle) {
            // If we are highlighted AND are drawing with the alternate color, then we want to draw our text with the alternate text color.
// For any other case, we should draw using our normal text color.
            if (highlighted && [highlightColor isEqual:[NSColor alternateSelectedControlColor]]) {
                // Make a copy of our title so that we can ....
NSMutableAttributedString *myTitleCopy = [[myTitle mutableCopy] autorelease];
                // ... add the alternate text color attribute...
[myTitleCopy addAttribute:NSForegroundColorAttributeName
                    value:[NSColor alternateSelectedControlTextColor]
range:NSMakeRange(0,[myTitle length])];
myTitle = myTitleCopy;
            }
            // Draw the text
            [myTitle drawInRect: .....];
        }
    }


NSTableView

Любой API, изменяющий выбор в табличном представлении, теперь закончит редактирование, если это будет надлежащим. Например, deselectAll: будет всегда заканчивать редактирование. В целом, если вызов API заставляет отредактированную строку больше не выбираться, редактирование будет закончено. Далее, если вызов API заставляет многократные строки быть выбранными, редактирование будет закончено. Во всех случаях редактирование заканчивается корректно, означая, что значение будет применено, если это будет допустимо.

Изображение передало setIndicatorImage: теперь сохранен и выпущен табличным представлением как надлежащий.

Индикаторы порядка сортировки по умолчанию теперь доступны, как названо NSImages. К этим изображениям можно получить доступ с [NSImage imageNamed:] использование имен NSAscendingSortIndicator («^» значок), и NSDescendingSortIndicator («v» значок).

encodeWithCoder NSTableView: метод теперь архивирует autosaveName, но только если Вы используете включенную архивацию. initWithCoder NSTableView: метод читает autosaveName и затем устанавливает его столбцы в найденных в пользовательских значениях по умолчанию.

В 10,1, rowsInRect: метод возвратил диапазон {0,0} каждый раз, когда inRect параметр содержал отрицательный y компонент, даже если высота была достаточно высока для пересечения с некоторыми строками в таблице. Это было фиксировано.

Следующие методы теперь отражаются в Java API для NSTableView:
void setIndicatorImage(NSImage indicatorImage, NSTableColumn tableColumn);
NSImage indicatorImage(NSTableColumn tableColumn);
void setHighlightedTableColumn(NSTableColumn tableColumn);
NSTableColumn highlightedTableColumn();

Если пользователь изменил выбор с клавиатурой (ключи стрелки вверх и вниз), в 10,2 и предыдущие выпуски, NSTableView не отправлял свое действие в его цель. Эта проблема может быть легко обработана путем ловли NSTableViewSelectionDidChangeNotification NSTableView.


Следующее является списком ошибок в NSTableView, которые, как обнаруживали, слишком поздно были фиксированы.

Перетаскивает запуск с NSTableView, больше автоматически поддерживают мусор как место назначения. Это применяется к 10.2 и более поздние приложения. Если необходимо перетащить к мусору, можно сделать это путем разделения на подклассы NSTableView и включая NSDragOperationDelete в возвращаемом значении от draggingSourceOperationMaskForLocal:. Чтобы определить если перетаскивание, законченное в мусоре, переопределите draggedImage:endedAt:operation:. Мы надеемся сделать этот процесс проще в будущем.


Флаг «Show Grid» в IB проигнорирован. Если Вы не установили флаг в IB, можно включить получение сетки в коде как ожидалось. Однако при установке этого флага в IB необходимо будет сделать следующее в коде, чтобы заставить сетку рисовать:
    [tableView setDrawsGrid:NO];
[tableView setDrawsGrid:YES];

NSTableView возвращается НЕ из needsPanelToBecomeKey. Это означает по умолчанию пользователя, перешедшего, использование клавиши Tab перескочит через таблицы и обрисует в общих чертах представления. К обходному решению это можно разделить NSTableView на подклассы и возвратить YES из needsPanelToBecomeKey.


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


Следующий сценарий может быть проблематичным для таблиц, сохраняющих их столбцы таблицы автоматически. Автоматическое сохранение столбцов таблицы может быть включено в IB путем установки «атрибута» Имени Автосохранения, или в коде при помощи setAutosaveTableColumns:/setAutosaveName:. Если Вы хотите позволить пользователям настраивать список столбцов или их порядка, это полезно.

Рассмотрите таблицу, сохраняющую столбцы автоматически, который указан в IB со столбцами (идентификатором столбца): «Кола», «ColB». Когда пользователь запустит Ваше приложение, существующие идентификаторы столбца таблицы будут выписанный к пользовательским значениям по умолчанию. Когда пользователь повторно выполнит программу, NSTableView найдет список идентификаторов столбцов в пользовательских значениях по умолчанию, представляя столбцы, которые будут использоваться в той таблице. NSTableView тогда ищет себя существующие столбцы, данные те идентификаторы, сохраняя столбцы, которые он находит в таблице и эффективно удалении других. Если Вы удалили или переименовали (идентификатор) столбец в IB, можно столкнуться с проблемами, потому что, NSTableView остановится, это ищет каждый раз, когда это поражает больше не существующий столбец. Это может заставить его появляться, что исчезли все столбцы таблицы после недостающего столбца. Хуже, если столбец, исчезнувший, является первым идентификатором столбца, найденным в пользовательских значениях по умолчанию, тогда Ваша таблица будет иметь столбцы NO (который заставит NSTableView повышать в более позднее время).

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


NSOutlineView

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

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

Посмотрите, что раздел NSTableView касается выборов для дополнительного поведения, которое наследовал NSOutlineView.

Внутреннее представление индексов в NSOutlineView было фиксировано так, чтобы число дочерних элементов больше не было ограничено 32K.

Значительная утечка была фиксирована в NSOutlineView. Расширяемые элементы (возвращенные из источника данных API) иногда сохранялись бы, но никогда не выпускались бы NSOutlineView, приводящим к утечкам. Ваше приложение получит эту фиксацию, только если это соединяется против 10,2 или позже. Приложения, соединенные против любой предыдущей версии, поддержат старое поведение для совместимости.


NSComboBox

В 10,1, отключенные поля комбинированного списка возвратили YES из acceptsFirstResponder. Когда пользователи щелкнули по отключенному полю комбинированного списка, это заставит фокус волшебно смещаться к ключевому представлению после поля комбинированного списка. NSComboBox теперь возвращается НЕ из acceptsFirstResponder, если это отключено.


NSToolbarItem

Если изображение содержит многократные представления, NSToolbarItem теперь выбирает наиболее соответственно размерное представление при отображении. Например, если изображение будет содержать представление, которое является тем же размером как изображение пункта меню, то то представление будет использоваться в представлении формы меню. Далее, если Вы находите, что Ваш значок не масштабируется хорошо в маленьком режиме значков NSTOOLBAR, можно добавить собственное маленькое представление изображения изображению, и это будет использоваться вместо масштабирования.


NSToolbar

Панели инструментов теперь позволяют пользователям конфигурировать выведенный на экран размер. Панели инструментов, сохраняющие их конфигурацию к пользовательским значениям по умолчанию, также запишут пользователей выбранный размер. Следующий API был добавлен для поддержки конфигурируемых размеров панели инструментов:
    typedef enum {
        NSToolbarSizeModeDefault,
        NSToolbarSizeModeRegular,
        NSToolbarSizeModeSmall
    } NSToolbarSizeMode;
    - (void)setSizeMode:(NSToolbarSizeMode)sizeMode;
    - (NSToolbarSizeMode)sizeMode;
Элементы изображения автоматически выведут на экран постоянного клиента (32x32) или маленький измеренный (24x24) изображение как соответствующего. Если Ваше изображение будет содержать представление изображения точного размера текущего режима, то то изображение будет использоваться. Иначе, самое надлежащее представление будет масштабироваться к текущему размеру режимов. Обычно необходимо просто предоставить регулярный размерный значок и позволить масштабированию использования панели инструментов при отображении небольшой версии. Когда NSToolbar создаст масштабированную версию, он добавит масштабированное представление Вашему исходному изображению так, чтобы он не должен был создавать его снова, поскольку пользователи переключаются между режимами или открывают многократные окна.

Элементы представления могут потребовать, чтобы пользовательский код скорректировал их появление на основе режима размера. Если представление Вашего элемента реализует setControlSize: представление будет сконфигурировано путем отправки ему того метода. Если Ваше представление не реализует setControlSize: NSToolbar проверит, чтобы видеть, просматриваете ли Вы, действительно управление, ячейка которого реализует setControlSize:. В этом случае Ваша ячейка получит метод. Заметьте, что это означает, что большинство стандартных средств управления будет автоматически сконфигурировано для Вас. Например, если Вы представление элемента являетесь NSPopUpButton, NSButton, NSTextField, и т.д... у Вас не будет работы, чтобы сделать. Если необходимо настроить или выполнить собственную конфигурацию, просто предоставьте Вам элемент с целью, реализующий setControlSize:.


Любой набор свойств на панели инструментов, прежде чем это будет вручено ее окну, считается «начальным» свойством панели инструментов. Т.е. если никакие значения для панели инструментов не будут найдены в предпочтениях пользователя, то начальное значение будет использоваться. В 10.1 setVisible: НЕТ был в основном проигнорирован. Это было фиксировано. Теперь, если Вы делаете setVisible:NO, и никакие значения не найдены в пользовательских значениях по умолчанию (это - первый раз, когда пользователь видит панель инструментов), панель инструментов действительно обнаружится первоначально скрытый.


В Mac OS X 10.1, вызывая setConfigurationFromDictionary: только измененный состояние переданная панель инструментов. Теперь, панель инструментов должным образом обновляет другие панели инструментов с этим, имеют тот же идентификатор как переданная панель инструментов.


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


setConfigurationDictionary: теперь обращает внимание на показанный / скрытый флаг и покажет / скрывают панель инструментов, если флаг отличается от текущей конфигурации.


NSCell

В 10,1 использованиях-setStringValue:/-stringValue NSCELL мог вызвать катастрофический отказ, если используется во вложенных пулах автовыпуска. Эта ошибка обычно замечена в Java Какао из-за использования пулов автовыпуска в мосте Java. Эта ошибка была исправлена теперь. Необходимо знать, однако, что приложение, работающее в 10,2, может быть восприимчиво к этому незваному гостю в 10,1.


Если Вы редактируете ячейку (например, NSTextFieldCell) и просите stringValue ячейки, в то время как пользователь вводит, можно прервать мультиключевой ввод символов. Необходимо проверить поле редактирования, чтобы видеть, находится ли в настоящее время в этом состоянии через следующее:

[[управляйте currentEditor] hasMarkedText];

... и не выбирайте строковое значение, если это возвращает YES. Это не проблема при использовании NSFormatter. В то время как в этом неполном символе утверждают, метод NSFormatter isPartialStringValid:... не вызовут.


NSMovieView

Вызов к - [NSMovieView setMovie:] теперь вызовет QuickTime PrePrerollMovie, и PrerollMovie функционирует асинхронно. При указании потоковой передачи URL это будет инициировать соединение, но не фактически начинать играть, когда предварительный рулон завершится, если Вы уже не вызвали - [NSMovieView запускаются:].

NSMovieView был изменен для использования NSUndoManager для всех операций отмены. Это включает многократную отмену/восстановление. Обратите внимание на то, что отмена: метод в NSMovieView был удален, так как это теперь обрабатывается NSUndoManager.


NSImage

Изменение было внесено в - [NSImage initByReferencingFile:]. Если изображение может кэшироваться, потому что кэшируемый размер меньше, чем фактический расширенный размер, т.е. изображение, которое составляет больше чем 72 точки на дюйм, то исходные данные сбрасываются, и кэшируемое изображение используется. При изменении размеров изображения, или больше или меньше чем на 50% данные будут загруженный в снова из файла. Если Вы ожидаете, что файл изменится или будет удален, необходимо использовать - [NSImage initWithContentsOfFile:] вместо этого. Это поведение только применяется к приложениям, основывался 10.2 или позже.


Можно теперь установить ли кэши изображений его представление при рисовании изображения впервые.
typedef enum {
NSImageCacheDefault,
NSImageCacheAlways,
NSImageCacheBySize,
NSImageCacheNever
} NSImageCacheMode;
-(void)setCacheMode:(NSImageCacheMode)mode;
-(NSImageCacheMode)cacheMode;
NSImageCacheDefault является текущим поведением с битовым массивом и PICT, кэшируемым размером и PDF, кэшируемым при рисовании на экран. NSImageCacheAlways будет всегда кэшироваться, NSImageCacheBySize будет кэшироваться, если кэшируемый размер будет меньшим, чем размер данных. Используйте это, когда у Вас есть setDataRetained:YESto, избавляются от хранения изображения. NSImageCacheNeverwill пробуют к никогда кэшу.

Обратите внимание на то, что в зависимости от типа NSImageRep и работы составного объекта получения и альфы (часть), изображение может все еще кэшироваться. Например, данные PDF могут только быть представлены с помощью NSCompositeSourceOver с полной альфой, таким образом, NSImage должен будет все еще кэшировать изображение для рендеринга с другими составными операциями.

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


NSBitmapImageRep

Поддержка была добавлена для чтения 1, 2, и палитра на 4 бита/выборки базировала файлы TIFF. Эти изображения преобразовываются для направления RGB на 8 битов/выборки или изображений RGBA при чтении. Палитра базировалась, файлы TIFF с альфой, возможно, были ранее нарисованы неправильно.

Поддержка была добавлена, чтобы считать и записать изображения JPEG CMYK. Кроме того, полутоновое изображение JPEG теперь сохранено как единственная выборка вместо того, чтобы преобразовать в RGB.

Поддержка была добавлена, чтобы считать и записать изображения TIFF на 16 битов/выборки.

Проверка файлов образа без информации типа для того, являются ли они TIFF, теперь немного более строга. В теории это должно быть безопасно; но, если предыдущее, более свободное поведение желаемо, предпочтение, NSLooseTIFFChecking может быть установлен со значением YES.

- [NSBitmapImageRep setProperty:withValue:] теперь принимает значение ноля, что означает, что можно убрать свойства, такие как данные ColorSync.


Анимированный GIFs

Поддержка была добавлена к NSBitmapImageRep для анимированного GIFs. Если NSBitmapImageRep будет создаваться из анимированного файла или данных сверхкадра GIF, то репутация изображения будет иметь 3 дополнительных свойства:
  NSImageFrameCount
NSImageCurrentFrame
NSImageCurrentFrameDuration
Вы проверяете на анимированный GIF путем наблюдения, существует ли свойство NSImageFrameCount. Если это сделает, то это будет целочисленный NSNumber, содержащий число кадров. NSImageCurrentFrame возвращает целочисленный NSNumber, содержащий текущий кадр начиная с кадра 0, и NSImageCurrentFrameDuration возвращает продолжительность того кадра как NSNumber с плавающей точкой в секундах. Для изменения на различный кадр установите свойство NSImageCurrentFrame в то, которое Вы хотите и затем проверяете свойство NSImageCurrentFrameDuration на продолжительность нового кадра.

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

Вот, некоторые методы на NSImage, можно добавить, что это может упростить доступ:
@implementation NSImage(AnimatedImageExtension)
- (int)frameCount {
NSBitmapImageRep* imageRep = [[self representations] objectAtIndex:0];
id property = [imageRep valueForProperty:NSImageFrameCount];
return property != nil ? [property intValue] : 0;
}
- (int)currentFrame {
NSBitmapImageRep* imageRep = [[self representations] objectAtIndex:0];
id property = [imageRep valueForProperty:NSImageCurrentFrame];
return property != nil ? [property intValue] : 0;
}
- (void)setCurrentFrame:(int)frame {
NSBitmapImageRep* imageRep = [[self representations] objectAtIndex:0];
[imageRep setProperty:NSImageCurrentFrame withValue: [NSNumber numberWithInt:frame]];
}
- (float)frameDuration {
NSBitmapImageRep* imageRep = [[self representations] objectAtIndex:0];
id property = [imageRep valueForProperty:NSImageCurrentFrameDuration];
return property != nil ? [property floatValue] : 0.0;
}
@end

Инкрементная загрузка Изображения

API был добавлен для поддержки инкрементной загрузки изображения. В настоящее время только изображения JPEG могут быть загружены этот путь, но GIF и PNG будут добавлены в будущем. API находится в двух частях. API NSImage предназначается для клиентов, что или не имейте их собственного источника данных или движения, может через NSURLHandle. Прямой API используется для клиентов, которые могут предоставить их собственные данные непосредственно. В то время как более простой, NSBitmapImageRep API синхронен.

Следующее является рядом методов делегата для NSImage, которые вызывают, поскольку загружается изображение. Используемого при первом рисовании NSImages создал через initByReferencingFile: и новый метод initByReferencingURL:.
typedef enum {
NSImageLoadStatusCompleted,
NSImageLoadStatusCancelled,
NSImageLoadStatusInvalidData,
NSImageLoadStatusUnexpectedEOF,
NSImageLoadStatusReadError
} NSImageLoadStatus;
@interface NSObject(NSImageDelegate)
- (void)image:(NSImage*)image willLoadRepresentation:(NSImageRep*)rep;
- (void)image:(NSImage*)image didLoadRepresentationHeader:(NSImageRep*)rep;
- (void)image:(NSImage*)image didLoadPartOfRepresentation:(NSImageRep*)rep withValidRows:(int)rows;
- (void)image:(NSImage*)image didLoadRepresentation:(NSImageRep*)rep withStatus:(NSImageLoadStatus)status;
@end
Требование для загрузки прогрессивного изображения - то, что там быть делегатом и делегатом реализуют последний метод image:didLoadRepresentation:withStatus: когда изображение полностью доступно, таким образом, это может получить уведомление. Все другие методы делегата являются дополнительными.

Если пользователь отменяет загрузку или существует ошибка, image:didLoadRepresentation:withStatus: будет все еще вызван и изображение будет содержать любую часть данных, допустимо. Если чтение заголовка перестало работать, NSBitmapImageRep останется измеренным нулем.

При рисовании изображения, в то время как оно загружается, только допустимые строки нарисованы. Остаток заполнен белым. Можно использовать - [NSImage drawInRect:fromRect:operation:fraction] для обрезки изображения с помощью значения validRows.

То, когда Вы сначала создадите NSImage использование URL, это будет содержать нуль, измерило NSBitmapImageRep. Когда Вы сначала рисуете изображение или иначе требуете растровых данных, image:willLoadRepresentation: вызывается и загрузка образа начинается. Когда достаточно данных было считано для определения размера изображения, image:didLoadRepresentationHeader: вызывается. В этой точке NSBitmapImageRep допустим и имеет хранение для битового массива, но битовый массив заполнен цветом фона изображения. Как загрузки образа, image:didLoadPartOfRepresentation:withValidRows делегата: метод будут вызывать неоднократно, чтобы сообщить делегату, что больше изображения доступно. Тогда, когда изображение было полностью распаковано, метод image:didLoadRepresentation: вызывается.

Существует два новых метода NSImage. Один для зеркального отражения initByReferencingFile:. Используя это заархивирует просто URL а не данные изображения.
- (id)initByReferencingURL:(NSURL*)url;
Этот метод и initByReferencingFile: позвольте фоновую загрузку. initWithContentsOfFile: и initWithContentsOfURL: оба сделает синхронные загрузки хотя initWithContentsOfURL: теперь поддержки больше, чем просто файл URLs

Другой метод позволяет непосредственную отмену при загрузке изображения. Если изображение не загружается, этот вызов не имеет никакого эффекта.
- (void)cancelIncrementalLoad;
Следующий API позволяет клиенту подавать данные NSBitmapImageRep из источника потоковой передачи и иметь данные быть распакованным. API предназначается, чтобы быть минимальным, так как только усовершенствованные клиенты должны будут, вероятно, использовать его.
typedef enum {
NSImageRepLoadStatusUnknownType = -1, // not enough data to determine image format. please feed me more data
NSImageRepLoadStatusReadingHeader = -2, // image format known, reading header. not yet valid. more data needed
NSImageRepLoadStatusWillNeedAllData = -3, // can't read incrementally. will wait for complete data to become avail.
NSImageRepLoadStatusInvalidData = -4, // image decompression encountered error.
NSImageRepLoadStatusUnexpectedEOF = -5, // ran out of data before full image was decompressed.
NSImageRepLoadStatusCompleted = -6 // all is well, the full pixelsHigh image is valid.
} NSImageRepLoadStatus;
- (id)initForIncrementalLoad;
- (int)incrementalLoadFromData:(NSData*)data complete:(BOOL)complete;
Во-первых, NSBitmapImageRep создается с помощью-initForIncrementalLoad. Это создает 0 размерных, пустых, в основном недопустимых NSBitmapImageRep без буфера. Тогда клиент будет неоднократно вызывать-incrementalLoadFromData:complete: со все большим количеством данных, наконец передающих в YES для полного: когда последний блок данных стал доступным. Данные должны быть полными данными, не только новыми данными, так как декомпрессор, возможно, должен отследить в обратном порядке. Этот вызов синхронен и распакует как можно больше изображения на основе длины данных. Репутация изображения не сохраняет данные, но указатель данных не должен изменяться в то время как в методе.

Если недостаточно данных было отправлено для определения формата, NSImageRepLoadStatusUnknownType возвращается. Клиент должен продолжать вызывать с большим количеством данных.

Как только достаточно данных было считано, NSImageRepLoadStatusReadingHeader может быть возвращен, указав, что, в то время как тип известен, недостаточно данных было считано для определения размера, глубины, и т.д. изображения. Клиент должен продолжать вызывать с большим количеством данных. Если окажется, что формат не поддерживает инкрементную загрузку, то NSImageRepLoadStatusWillNeedAllData будет возвращен. Пока Вы не вызываете-incrementalLoadFromData:complete: с ДА, будет возвращено это состояние, хотя можно продолжать вызывать его, но никакая распаковка не будет иметь место. Как только Вы действительно вызываете его с ДА, тогда изображение будет распаковано, и одно из заключительных трех сообщений о состоянии будет возвращено.

Если формат действительно поддерживает инкрементную загрузку, то, как только достаточно данных было считано, изображение распаковывается от вершины вниз строка за один раз. Информация репутации изображения будет допустима включая pixelsHigh, pixelsWide, размер, bitsPerSample, и т.д. включая растровые данные. В это время,-incrementalLoadFromData:complete: возвратит число строк, распакованных от вершины изображения. Можно использовать эту информацию для рисования части изображения, которое допустимо. Остальная часть изображения будет заполнена непрозрачным белым. Обратите внимание на то, что, если изображение является прогрессивным, можно быстро получить полное значение pixelsHigh, но изображение будет все еще загружаться, так не используйте это в качестве индикации относительно того, сколько из изображения остается быть распакованным.

Если ошибка произошла при распаковке, NSImageRepLoadStatusInvalidData возвращается. Если завершенный: YES, но недостаточно данных было доступно для распаковки, NSImageRepLoadStatusUnexpectedEOF возвращается. Если достаточно данных было предоставлено (независимо от полного: флаг), тогда NSImageRepLoadStatusCompleted возвращается. Когда любой из этих трех результатов состояния будет возвращен, NSBitmapImageRep будет скорректирован так, чтобы pixelsHigh и размер, а также растровые данные только содержали допустимые пиксели.

Для отмены распаковки просто передайте в существующих данных или ноле и YES для complete:. Если данные не будут нолем, то такое количество остающихся данных будет распаковано. Если Вы передаете в ноле, то распаковка сразу останавливается, размер изображения корректируется, и Вы возвращаете состояние NSImageRepLoadStatusUnexpectedEOF.

Вызов-incrementalLoadFromData:complete: после того, как любой из трех результатов или на изображении, инициализированном от любого другого вызова init, приведет к результату NSImageRepLoadStatusCompleted.


Удалены частные изображения

Следующие частные изображения были удалены из открытого пера панели. Если какое-либо приложение использовало их из платформы AppKit, эти изображения больше не будут находиться:
NSSimpleSaveUpArrow.tiff
NSSimpleSaveDownArrow.tiff
NXSmallFloppyEjectIcon.tiff
NXSmallHomeIcon.tiff
NXSmallFloppyIcon.tiff


NSStatusBar

Удаление элемента через - [NSStatusBar removeItem:] теперь сразу удаляет элемент из строки меню. Это изменение не должно влиять на существующие приложения.

Была решена проблема с приложением, которые поднимают элемент строки состояния и затем становятся активными при щелчке по элементу строки состояния.


NSStepper

Была решена проблема, заставившая значения степпера не изменяться, если степпер был установлен не автоматически повториться.


Клавиатура UI

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


Всплывающие меню

Меню кнопки всплывающего меню и их подменю теперь соответствуют размер шрифта кнопки и размер шрифта.


NSPopUpButtonCell

В 10.1.x текст в безграничной кнопке всплывающего меню расположен 3 пикселя слишком высоко. Это было фиксировано для приложений, соединяющихся против 10,2 или позже.

Это - примечание для указания на потенциальную ошибку, не исправленную в 10,2. Если Ваше приложение пропускает какие-либо экземпляры NSPopUpButtonCell, использование командных клавиш позже могло бы заставить Ваше приложение отказывать в - [NSApplication sendEvent:]. Этот катастрофический отказ фактически произойдет с любым NSPopUpButtonCell, имеющим недопустимое (освобожденный или иначе) controlView (NSPopUpButton).


NSMenu

Новые методы класса были добавлены к NSMenu, чтобы показать и скрыть строку меню и узнать, в настоящее время видимо ли это.
+ (void)setMenuBarVisible:(BOOL)visible;
+ (BOOL)menuBarVisible;

Ключевые эквиваленты Пункта меню

Некоторые ключевые эквиваленты пункта меню резервируются системой для захватов выбора и экрана. Можно установить эти ключевые эквиваленты в Интерфейсном Разработчике, но они не будут показаны при выполнении. В настоящее время зарезервированные ключевые эквиваленты являются Command-Shift-3 (иначе Command-#), Command-Shift-4 (иначе Команда - $) и Сдвиг Управления Команды 3 и Сдвиг Управления Команды 4.

Были изменены рекомендуемые эквиваленты командной клавиши для Скопировать/вставить линейки и шрифта (стиль) команды. Они раньше были cmd-1, cmd-2, cmd-3, и cmd-4 соответственно; потому что мы хотим оставить эти командные клавиши приложениям, новые рекомендуемые инструкции для этих команд:

cmd-opt-c копируют стиль
cmd-ctrl-c копируют линейку

cmd-opt-v вставляют стиль
cmd-ctrl-v вставляют линейку

TextEdit и Почта следуют этим инструкциям, а также записям меню в палитре Interface Builder. Однако не все приложения в системе были преобразованы.

cmd-opt-H является теперь рекомендуемой командной клавишей, эквивалентной для, «Скрывают Других».


Делегация и уведомление

С классами AppKit, предоставляющими делегации и уведомлению (такому как NSWindow), если Вы явно регистрируетесь для определенных уведомлений, также использующихся для отправки сообщений делегата, и затем когда Вы прекращаете быть делегатом, Вы не зарегистрированы для тех уведомлений. Не ясно, как это будет адресоваться в будущем, но необходимо знать об этом потенциально неожиданном поведении.


NSTextField и устаревшие методы NSMatrix

Следующие 4 метода от NSTextView и NSMatrix являются устаревшими и были удалены из заголовков. Они будут продолжать работать, но испустят сообщение журнала, когда используется. Используйте методы NSView setNextKeyView: nextKeyView, и previousKeyView вместо этого.
- (void)setPreviousText:(id)anObject;
- (void)setNextText:(id)anObject;
- (id)nextText;
- (id)previousText;

NSTextField, NSTextFieldCell

Можно теперь изменить внешнюю панель текстового поля, чтобы быть округленным стилем. Текстовое поле должно уже иметь набор setBezeled:YES.
typedef enum {
NSTextFieldSquareBezel,
NSTextFieldRoundedBezel
} NSTextFieldBezelStyle;
@interface NSTextField
-(void)setBezelStyle:(NSTextFieldBezelStyle)bezelStyle;
-(NSTextFieldBezelStyle)bezelStyle;
@end
@interface NSTextFieldCell
-(void)setBezelStyle:(NSTextFieldBezelStyle)bezelStyle;
-(NSTextFieldBezelStyle)bezelStyle;
@end

Если бы его управление редактировалось, в Mac OS X 10.1, NSTextFieldCell в управлении нарисовал бы свое фокусирующее кольцо. Для сложных средств управления с многократными текстовыми полями это заставило фокусирующее кольцо быть нарисованным много раз, приведя к темному фокусирующему кольцу без желаемых мягких краев. Это было фиксировано. NSTextFieldCell теперь проверяет свой атрибут 'showsFirstResponder', чтобы определить, должен ли он нарисовать фокусирующее кольцо, когда редактируется управление. Если Вы замечаете, что Ваши фокусирующие кольца не обнаруживаются больше, можно вызвать setShowsFirstResponder ячейки: со значением YES.


Меню прикрепления

В 10,2, действие, отправленное от пользовательского меню прикрепления, имеет NSMenuItem как своего отправителя. В 10,1, отправителем всегда был NSApp.


NSApplication

Существует теперь лучшее различие, сделанное между модальными документом сеансами и модальными приложением сеансами. Это решает проблемы, где лист на модальном приложением окне повредил бы модальность приложения. Один результат этого изменения состоит в том, что - [NSApplication modalWindow] больше не будет возвращать окно листа. При необходимости в доступе к окну листа можно быть в состоянии использовать - [NSWindow attachedSheet].

При необходимости в совместимости с 10,1, потому что Вы полагаетесь - [NSApplication modalWindow] для возврата листа, или потому что Вы вызываете - [NSApplication endSheet:returnCode:] для завершения модальных приложением сеансов можно установить пользовательское значение по умолчанию NSModalCompatibilityWithMacOS10.1 в YES.

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


Параметры SEL

Основа была противоречива в своей обработке параметров NULL SEL в прошлом. В 10,2, для приложений, соединенных на 10,2 или позже, Основа повышает исключения во всех функциях и методах (таких как NSObjects-respondsToSelector:), которые берут параметры SEL, если параметром SEL является NULL.


NSOpenGL

Четыре новых константы были добавлены к NSOpenGLPixelFormat:
NSOpenGLPFASampleBuffers      =  55
NSOpenGLPFASamples = 56
NSOpenGLPFAAuxDepthStencil = 57
NSOpenGLPFAVirtualScreenCount = 128
Две новых константы были добавлены к NSOpenGLContextParameter:
NSOpenGLCPSurfaceOrder        = 235
NSOpenGLCPSurfaceOpacity = 236
Следующие методы позволяют контексту быть смещенным между виртуальными экранами.
- (void)setCurrentVirtualScreen:(int)screen;
- (int)currentVirtualScreen;
Этот новый метод позволяет Вам создавать новую текстуру с целью идентификатора от содержания NSView, связанного с NSOpenGLContext.
- (void)createTexture:(unsigned long/*GLenum*/)target fromView:(NSView*)view internalFormat:(unsigned long/*GLenum*/)format;

NSBezierPath

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

Если Вы замечаете проблемы производительности с NSBezierPaths, имеющими много сегментов, и Вы не заботитесь слишком много об абсолютной правильности рендеринга пересечений, Вы могли бы хотеть использовать меньшие сегменты.


Функция NSGraphics

Объявление функции NSCopyBitmapFromGState удалено из NSGraphics.h. Реализация функции была удалена на ранней стадии разработки Mac OS X.





Отмечает определенный для Mac OS X 10.1

Управление версиями

NSApplication.h теперь объявляет NSAppKitVersionNumber, который может использоваться для обнаружения различных версий платформы AppKit (к гранулярности на сборку; существует много сборок между общедоступными выпусками). Существует также символьное значение для Mac OS X 10,0 версий AppKit:
/* The version of the AppKit framework */
APPKIT_EXTERN double NSAppKitVersionNumber;
#define NSAppKitVersionNumber10_0 577
Клиенты могут выдержать сравнение с этим, чтобы определить, работают ли они 10.0 или на более новой версии. Обратите внимание на то, что некоторые отдельные заголовки для других объектов и компонентов могут также объявить числа версий для NSAppKitVersionNumber, где некоторое исправление ошибки или функциональность доступны в данном обновлении, например:
#define NSAppKitVersionWithSuchAndSuchBadBugFix 582.1
Несмотря на то, что NSAppKitVersionNumber не был объявлен в заголовочных файлах в 10,0, это все еще доступно и может быть получено доступ приложениями во время выполнения. Если Вы компилируете на 10,0, можно объявить эту переменную сами.

В целом необходимо выдержать сравнение с номером версии, который Вы знаете, решает проблему, которую Вы проверяете на, а не точная версия последнего внешнего выпуска. Как пример, несмотря на то, что 10.0 до 10.0.4 у всех есть версия 577 AppKit, 577.1 могли бы быть выпущены для исправления некоторой ошибки в будущем 10.0.x. Это - просто пример, но это произошло с другими платформами, обновленными в различном 10.0.x обновления программного обеспечения.


Клавиатура UI

10.1 приводит функцию перемещения с помощью клавиатуры в чувство Какао. Пользователи могут теперь использовать вкладку, shift-tab и различные клавиши CTRL (устанавливаемый пользователь; посмотрите Предпочтения) перейти между элементами пользовательского интерфейса. Например, с помощью настроек по умолчанию, ctrl-F2 берет фокус к строке меню, и ctrl-F5 берет фокус на панель инструментов. Обратите внимание на то, что по умолчанию полное перемещение с помощью клавиатуры отключено, и пользователи могут только снабдить вкладками между текстовыми элементами и списками. Удар ctrl-F1 включает полную навигацию.

Как имел место прежде, для окон, имеющих набор initialFirstResponder, набор предполагает, что существует допустимый цикл перемещения с помощью клавиатуры и использует существующий цикл. Если у Вас есть окна с initialFirstResponder, в котором Вы добавили или удалили элементы UI, навигация могла бы быть испорчена.

В окнах без initialFirstResponder набор создаст клавиатуру цикл UI для Вас.

Мы поддерживаем способ, которым пользовательские элементы управления могут добавить кольцо клавиатурного фокуса вокруг текста, графики и изображений. Например, посмотрите клавиатурный фокус на панелях инструментов. Эта функция устанавливает 'стиль' в текущем графическом контексте в текущем заблокированном представлении фокуса, влияющем на весь рендеринг, пока не восстанавливается состояние графики.
typedef enum {
NSFocusRingOnly = 0,
NSFocusRingBelow = 1,
NSFocusRingAbove = 2
} NSFocusRingPlacement;
void NSSetFocusRingStyle(NSFocusRingPlacement placement);
Размещение указывает, как будет нарисовано фокусирующее кольцо. Используйте NSFocusRingAbove, чтобы дистиллировать изображение, использовать NSFocusRingBelow, чтобы нарисовать фокусирующее кольцо в соответствии с текстом и использовать NSFocusRingOnly, если у Вас нет изображения или текста. Для случая NSFocusRingOnly заполните форму для добавления фокусирующего кольца вокруг формы.

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

Поскольку фокусирующее кольцо может быть нарисовано вне представления, используйте следующий метод NSView для лишения законной силы области вокруг фокусирующего кольца.
-(void)setKeyboardFocusRingNeedsDisplayInRect:(NSRect)rect;
Передача в прямоугольнике управления или ячейка и это будут расширены и лишены законной силы.


NSDocument

В 10,1, NSDocument добавляет следующие опции конечного пользователя: расширения Скрытого файла, возможность отследить документы, папки и объемы, переименованные, и возможность сохранить документы в пути, сохраняющем псевдонимы к документам и дополнительной информации документа (таким как местоположения значка). recents меню также поддерживает отслеживание документов. Эти функции и изменения обсуждены ниже. Обратите внимание на то, что большинство этих функций может поддерживаться в базируемых приложениях non-NSDocument также с различными степенями работы. TextEdit, который не является базируемым NSDocument, имеет некоторых (но не все) этих функций; можно найти его источники в/Developer/Examples/AppKit/TextEdit.


NSDocument теперь предоставляет поддержку для понятия расширений имени скрытого файла, представленного в версии 10.1 Mac OS X. Эта функция позволяет расширениям файла быть скрытыми на основе на файл, обеспечивающей межплатформенную и веб-совместимость файлов при освобождении пользователей от необходимости иметь дело с и видеть расширения. Например, по умолчанию, видимое пользователем имя дисплея файлов RTF, сохраненных TextEdit, не имеет «.rtf» расширения.

Существует дополнительный API в NSSavePanel, NSFileManager и NSDocument, чтобы поддерживать эту функцию. Изменения NSSavePanel описаны далее ниже; изменения NSFileManager описаны в информации о версии Основы.

В NSDocument два новых метода были добавлены, чтобы поддерживать эту функцию:
- (BOOL)fileNameExtensionWasHiddenInLastRunSavePanel;
YES возвратов, если панель сохранения была представлена этим документом и пользователем, приняли решение скрыть расширение имени файла, выбранного в той панели сохранения. Возвраты НЕ иначе.
- (NSDictionary *)fileAttributesToWriteToFile:(NSString *)fullDocumentPath
ofType:(NSString *)documentTypeName
saveOperation:(NSSaveOperationType)saveOperationType;
Возвращает атрибуты файла, которые должны быть записаны в именованный файл документа указанного типа документа как часть определенного типа работы сохранения. Набор атрибутов правильного файла является подмножеством понятых под классом NSFileManager. Invokers этого метода должен тихо проигнорировать недопустимые атрибуты. Особенно интересный атрибут NSFileExtensionHidden, документирующийся в информацию о версии Основы.

Кроме того, поведение одного метода NSDocument изменилось на расширения скрытого файла поддержки: - [NSDocument displayName] теперь возвращает визуализуемое название документа, принимающее во внимание, должно ли быть скрыто расширение имени файла документа.

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

Переопределение-writeWithBackupToFile:ofType:saveOperation: метод должен вызвать этот метод и установить возвращенные атрибуты на записанном файле документа, возможно с помощью - [NSFileManager changeFileAttributes:atPath:] метод.

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


NSDocument теперь реализует сохранение документа в пути, сохраняющем, если это возможно, различные атрибуты каждого документа, включая:
• Дата создания.
• Полномочия/полномочия.
• Расположение значка документа в окне Icon View Finder его родительской папки.
• Значение Настройки внутреннего абонента Шоу документа.

Заботу также соблюдают для сохранения документов в пути, не повреждающем создаваемых пользователями псевдонимов, которые могут указать на документы.

В результате некоторые методы в любом подклассе NSDocument могут теперь быть вызваны с параметрами, отличающимися от того, что использовалось бы в прошлом. Например, теперь более важно чем когда-либо что переопределения-writeToFile:ofType:originalFile:saveOperation: и-writeToFile:ofType: не сделайте предположения о путях к файлам, передающихся как параметры, включая:
• Расположение, в которое пишется файл. Вероятно, как не файл пишется в скрытый временный каталог.
• Имя записанного файла. Возможно, что имя файла не будет иметь никакого очевидного отношения к названию документа.
• Отношение любого передаваемого пути к файлу, включая originalFile, к возвращаемому значению [сам имя файла].

Для назад совместимости на уровне двоичных кодов NSDocument покажет почти то же самое поведение, как это сделало в Mac OS 10.0 при выполнении в программах, соединенных против Mac OS 10,0 версий платформы AppKit или Какао.


Открытые документы теперь имеют возможность отследить файлы, от которых они были открыты (или к которому они были последний раз сохранены) так, чтобы они противостояли виду перемещения и переименования документов, папок и объемов, которые пользователь может сделать со Средством поиска. Эта функция проявляется в пользовательском интерфейсе двумя способами:
• Если пользователь будет использовать Средство поиска, чтобы переместить или переименовать открытый документ, содержание папки или объема, то меню расположения заголовка и документа окна документа (как замечено, когда Вы щелчок команды по заголовку окна) будет обновлено автоматически, когда будет повторно активировано приложение.
• Когда пользователи пытаются сохранить документ после того, как любая из вышеупомянутых операций была выполнена, надлежащая предупредительная панель может быть представлена, чтобы позволить пользователю выбрать соответствующие меры.

В результате этого дополнения экземпляры NSDocument будут отправлены несколько сообщений,-setFileName: в частности более часто, чем они были в прошлом.


-fileAttributesToWriteToFile:ofType:saveOperation: упомянутый выше метод может быть переопределен, чтобы указать, что код создателя и/или код типа файла должны быть записаны в файл, поскольку это сохраняется. См. информацию о версии Основы для описаний новых атрибутов файла NSFileHFSCreatorCode и NSFileHFSTypeCode. Реализация NSDOCUMENT-fileAttributesToWriteToFile:ofType:saveOperation: возвраты обнуленный создатель и коды типа файла, эффективно, исключая код создателя и тип файла кодируют от сохранения атрибута, описанного выше.

- [NSDocument runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:] теперь представит приложение модально панели макета страницы, если не будет никакого окна документа, которому это может быть представленный документ модально.


Была ошибка, в которой значение originalFile параметра было неправильным во время вызовов-writeToFile:ofType:originalFile:saveOperation: это имело место во время операций Save As. Это всегда был или ноль или путь к перезаписываемому файлу. Если документ никогда не сохранялся прежде, теперь это - путь к текущему расположению документа на диске или ноль.


NSDocumentController

Во время выпуска Mac OS X, версии 10.0, Какао Mac OS X Информация о версии AppKit утверждала что:

«-fileExtensionsFromType NSDocumentController: теперь возвращает массив строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла.-runModalOpenPanel:forTypes: и-typeFromFileExtension: ведите себя, как они всегда имеют, но теперь примут строки типа файла, содержащие закодированные типы файлов HFS, а также расширения файла.-openDocumentWithContentsOfFile:display: и-openDocumentWithContentsOfURL:display: теперь примите тип файла HFS во внимание файлов при решении того, какой подкласс NSDocument нужно инстанцировать».

Это не было истиной, но это - истина теперь. (Остальная часть информации о версии, имеющей дело с типами файлов HFS, была точна.) Ни один из методов NSDocumentController, названных в той информации о версии, за исключением-runModalOpenPanel:forTypes: обработанные типы файлов HFS правильно. Теперь,-fileExtensionsFromType:-runModalOpenPanel:forTypes:-typeFromFileExtension:-openDocumentWithContentsOfFile:display: и-openDocumentWithContentsOfURL:display: весь дескриптор типы файлов HFS правильно.


Реализация NSDocumentController меню Open Recent теперь пытается противостоять виду перемещения и переименования документов, папок и объемов, которые пользователь может сделать со Средством поиска. Если пользователь делает какую-либо такую работу, включающую документ, выбор соответствующего пункта меню Open Recents все еще приводит к открытию документа.

Документы, которые не могут быть расположены больше, появляются в меню Open Recent вообще.

Расширения имени файлов, показанных в меню Open Recent, также будут скрыты или показаны как надлежащие.


- [NSDocumentController reviewUnsavedDocumentsWithAlertTitle:cancellable:delegate:didReviewAllSelector:contextInfo:] теперь полностью игнорирует переданный - в предупредительной строке заголовка.


NSWindowController

Была ошибка в NSWindowController, в котором название документа, возвращенное переопределением - [NSDocument displayName], не будет использоваться для заголовков окна документа. Та ошибка была исправлена.


NSSavePanel

Чтобы поддерживать функцию расширения скрытого файла, обсужденную выше, флажок был добавлен к панели сохранения, позволяющей пользователю скрывать или показывать расширение. Существующий non-NSDocument базировался, приложения должны будут быть изменены для установки флага; по умолчанию флажок не видим. (В большинстве случаев эта функция автоматически поддерживается для базируемых приложений NSDocument.)

Новый API состоит из 3 методов в NSSavePanel.h:
- (void)setCanSelectHiddenExtension:(BOOL)flag;
- (BOOL)isExtensionHidden;
- (void)setExtensionHidden:(BOOL)flag;
setCanSelectHiddenExtension: показывает флажок в панели сохранения. Это нужно вызвать прежде runModal: и т.д.

setExtensionHidden: позволяет приложению устанавливать флажок. если будет редко использоваться, так как на состоянии экономят на основание приложения.

если флажок видим и проверен, isExtensionHidden возвращает YES. Этот флаг может использоваться для установки скрытого дополнительного бита в сохраненных файлах через NSFileManager API.


NSProgressIndicator

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


NSPDFImageRep

- [NSImage рисуют...] методы, когда вызвал на изображение PDF во время печати, очень часто не создавал вывода. Это было ошибкой и было фиксировано.


NSPrintOperation

Расположения задания NSPrintPreviewJob и NSPrintSaveJob не поддерживались в Mac OS 10.0.x. Они находятся в Mac OS 10.1.

Атрибут, к которому получают доступ с помощью-setShowPanels: и-showPanels теперь управляет, представлена ли панель прогресса печати-runOperation или-runOperationModalForWindow:delegate:didRunSelector:contextInfo:.


Сценарии

Значение по умолчанию атрибута сценариев «версии» NSAPPLICATION является теперь записью CFBundleShortVersionString в Информационном списке свойств приложения вместо нуля числа. Это значение может все еще быть переопределено делегатом приложения объект.


NSButton

- [NSButton setKeyEquivalentModifierMask] теперь поддерживает NSCommandKeyMask как параметр. Когда commandKey модификатор присутствует в keyDown событии, NSApplication теперь ищет командную клавишу, эквивалентную в ключевом окне прежде, чем отправить событие в меню. Командная клавиша, эквивалентная в ключевом окне, будет поэтому иметь приоритет по той же командной клавише эквивалентным в меню. Предпочтительно избежать таких коллизий, как бы то ни было.


Эквивалентный ключ команды-d

NSRunAlertPanel и NSBeginAlertSheet теперь обеспечивают ключ команды-d, эквивалентный для кнопки «Do not save» в панели, если Вы найдены. Заголовки кнопки ищутся локализованное значение для, «Не сохраняют». Если соответствие найдено, та кнопка присваивается эквивалентный ключ команды-d, если это уже не кнопка по умолчанию. (Это не работает для присвоения и команды-d и возврата как ключевые эквиваленты для той же кнопки, таким образом, возврат берет приоритет).

Если Вы создаете модальное использование панели - [NSApplication runModalForWindow:] или - [NSApplication beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:], можно присвоить ключевой эквивалент сами, с помощью - [NSButton setKeyEquivalent] и - [NSButton setKeyEquivalentModifierMask:].


NSWindow

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

- когда окно является «листом» или документом модальная панель, isSheet был добавлен для указания. Существует также метод для выяснения лист, присоединенный к окну,-attachedSheet. Если такой лист существует, это указывает, что окно находится в документе модальное состояние. Если окно не имеет присоединенного листа, этого ноля возвратов метода.

Уведомление отправляется, прежде чем лист представлен на окне, NSWindowWillBeginSheetNotification, и после того, как это отклонено, NSWindowDidEndSheetNotification.
- (BOOL)isSheet;
- (NSWindow *)attachedSheet;
Делегат окна должен реализовать следующий для получения уведомлений листа:
- (void)windowWillBeginSheet:(NSNotification *)notification;
- (void)windowDidEndSheet:(NSNotification *)notification;
Была ошибка в 10,0 где вызов setAspectRatio: на окне вызвал бы, оно для изменения размеров к нулю структурирует момент, Вы попытались изменить размеры его. С Puma5G21-setAspectRatio: теперь осуществляет форматное соотношение правильно для, изменяют размеры операций.

В 10,1, строка передала в - [NSWindow setTitle:] будет скопирован, а не сохранен окном. Это обеспечивает корректное поведение для набора заголовков с помощью непостоянных строк. Однако, если Вы будете зависеть от NSWindow для сохранения этой строки для приложения для позже изменения его, то необходимо будет сохранить строку сами. Также обратите внимание на то, что модификации, сделанные после строки, передаются в setTitle: не будет отражен в заголовке окна.

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

Существует также меньше типичной проблемы, где, разрушаясь панель сохранения может заставить окно документа перемещаться в неожиданное расположение. Это - проблема, вызывающаяся отказом инициализировать положение окна должным образом в некоторых случаях. Вы можете обходное решение эта проблема в Вашем приложении путем расположения окна документа с - [NSWindow setFrame:display:] вместо того, чтобы передать расположенный кадр в - [NSWindow initWithContentRect:styleMask:backing:defer:].


NSScreen

У нас теперь есть поддержка динамического экранного реконфигурирования. Это позволит определенным моделям PowerBooks обнаруживать дисплеи, добавленные или удаленные при пробуждении изо сна. Когда дисплей будет добавлен или демонтирован, содержание + [экраны NSScreen] изменятся, таким образом, приложения не должны кэшировать экранный массив.


NSEvent

Типы событий были добавлены для «других» событий от нажатия мыши. Эти события могут быть сгенерированы устройством ввода данных больше чем с двумя кнопками:
NSOtherMouseDown      = 25,
NSOtherMouseUp = 26,
NSOtherMouseDragged = 27
Соответствующие маски события также определяются:
NSOtherMouseDownMask      = 1 << NSOtherMouseDown,
NSOtherMouseUpMask = 1 << NSOtherMouseUp,
NSOtherMouseDraggedMask = 1 << NSOtherMouseDragged
Метод был добавлен для получения buttonNumber для кнопки мыши, генерировавшей событие OtherMouse.-buttonNumber метод предназначается для использования с событиями OtherMouse, но возвратит постоянные значения для событий LeftMouse и RightMouse также:
- (int)buttonNumber;
Методы NSResponder были добавлены для обработки этих событий. Подкласс NSResponder может реализовать эти методы, которые вызовут, когда получено событие OtherMouse:
- (void)otherMouseDown:(NSEvent *)theEvent;
- (void)otherMouseUp:(NSEvent *)theEvent;
- (void)otherMouseDragged:(NSEvent *)theEvent;
- [NSEvent deltaX] и - [NSEvent deltaY] теперь возвращает дельту мыши для перемещения мыши, и мышь перетащила события.


- [NSEvent locationInWindow] может теперь возвратить NSPoints с неинтегральными координатами для представления субпиксельной точности, сгенерированной некоторыми устройствами ввода данных, например планшеты. - [NSDraggingInfo draggingLocation] и - [NSDraggingInfo draggedImageLocation] может также возвратить неинтегральные расположения. Приложения не должны предполагать, что эти расположения будут на границах пикселей.


NSApplication

Если Ваше приложение использует NSStatusItems и реализации - (BOOL) applicationShouldHandleReopen: (NSApplication *) theApplication hasVisibleWindows: флаг (BOOL), существует известная проблема, где флагом hasVisibleWindows всегда будет YES, даже если не будет никаких видимых окон кроме NSStatusItems.

Если Ваше приложение использует NSStatusItems и должно точно различить наличие видимых окон и не, необходимо добавить собственную регистрацию-applicationShouldHandleReopen:hasVisibleWindows:. Например, это могло бы быть целесообразно спрашивать, ли - [NSApp mainWindow] ноль как способ проверить на видимые окна документа.


Взаимодействие прикрепления NSApplication

NSApplication добавил поддержку приложений для указания содержания меню прикрепления приложения. Это позволяет приложению добавлять пункты меню ниже списка окон в меню прикрепления.

Приложение может или указать NSMenu в пере или возвратить NSMenu из метода делегата.

Для указания NSMenu в пере добавьте имя пера к info.plist, с помощью ключа AppleDockMenu. Имя пера должно быть указано без расширения. Будет выход IB от NSApplication, названного dockMenu, который должен быть подключен к NSMenu в пере. Это меню должно быть в его собственном файле пера так, чтобы оно могло быть загружено лениво, когда dockMenu требуют, а не во время запуска.

Существует также метод делегата приложения позволить делегату указывать меню динамично. Если делегат возвращает неноль для этого меню, он имеет приоритет по dockMenu в пере. Поскольку этот метод вызывается каждый раз, когда dockMenu должен быть показан, эффективность важна. Когда этот метод вызывается, делегат должен сохранить его собственное внутреннее представление меню прикрепления актуальным вместо того, чтобы обновить.
- (NSMenu *)applicationDockMenu:(NSApplication *)sender;
Цель и действие для каждого пункта меню передаются прикреплению. На выборе пункта меню прикрепление передает приложение, вызывающее [NSApp sendAction:selector to:target from:nil].

Текущая реализация еще не поддерживает добавление изображения к пункту меню или изменению заголовка меню на основе модифицирующих клавиш, которые являются оба функциями, желаемыми в dockMenu.


У нас теперь есть поддержка «Уведомлений Прикрепления», в основном пользовательских уведомлений для разрешения приложения, которое не является frontmost для запроса пользовательского внимания. Прикрепление предоставляет новый вид анимации мозаики приложения для указания этого уведомления.

Для запуска уведомления приложение вызвало бы:
- (int)requestUserAttention:(NSRequestUserAttentionType)requestType
requestType является или NSInformationalRequest или NSCriticalRequest. Мы возвращаем значок панелей в течение одной секунды (обычно один возврат) для информационного запроса, и пока приложение не становится активным для критического запроса. Активация приложения отменяет пользовательский запрос уведомления. Совершение этого звонка в приложении, которое уже активно, не имеет никакого эффекта.

Возвращаемое значение является тегом запроса, который может быть передан:
- (void)cancelUserAttentionRequest:(int)request
cancelUserAttentionRequest: позволяет приложению отменять предыдущий запрос. запрос является возвращаемым значением от предыдущего вызова до requestUserAttention:. В общем падеже запрос будет отменен автоматически пользовательской активацией приложения. Этот метод предоставляет менее часто необходимое средство для отмены запроса без явной активации.

Дополнения к NSApplication.h:
enum {
NSInformationalRequest = 0,
NSCriticalRequest = 1
} NSRequestUserAttentionType;
- (int)requestUserAttention:(NSRequestUserAttentionType)requestType
- (void)cancelUserAttentionRequest:(int)request
Если неактивное приложение представляет модальную панель, мы вызываем - [NSApp requestUserAttention:NSCriticalRequest] автоматически для приложения. Модальная панель больше не выявляется (использование NSModalPanelWindowLevel) для неактивного приложения.


Стандарт о панели

Стандарт о панели теперь поддерживает ссылки в области Credits; щелчок по ссылке вызывает, он, чтобы быть открытым в приложении по умолчанию подготовил обрабатывать ссылку. Можно указать ссылки в приписанной строке, которую Вы обеспечиваете (поскольку значение «Кредитов» вводит словарь), или в файле Credits.html, который будет разыскиваться перед Credits.rtf. Обратите внимание на то, что Credits.html не разыскивается в 10,0, поэтому если Вы действительно обеспечиваете один, Вы могли бы также хотеть обеспечить файл Credits.rtf. Существует также поддержка теперь Credits.rtfd.


Предупреждения

В 10,1 предупредительная панель, представленная NSRunCriticalAlertPanel и листом, представленным NSBeginCriticalAlertSheet, будет значок значок приложения со значком предупреждения. Эти функции должны использоваться только, как указано Инструкциями по Интерфейсу пользователя.


NSFileWrapper

Исправления ошибок
- Улучшенная обработка ошибок. При некоторых обстоятельствах ошибки игнорировались во время инициализации (вместо того, чтобы возвратить ноль), и получающаяся обертка файла могла вызвать segfault, когда это использовалось.
- Поврежденный, абсолютные ссылки теперь копируются в обертку файла вместо того, чтобы быть обработанными как ошибка.

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


NSWorkspace

Ошибка была исправлена, в котором NSWorkspace не поставлял свой NSWorkspaceDidUnmountNotification, если объем был насильственно и сразу сделан недоступным, например путем простого отключения диска firewire. В этом случае NSWorkspaceDidUnmountNotification будет теперь поставлен, но NSWorkspaceWillUnmountNotification все еще не будет, потому что нет никакого шанса поставить его, прежде чем будет размонтирован объем.


Текст

Методы NSAttributedString
- (id)initWithPath:(NSString *)path documentAttributes:(NSDictionary **)dict;
- (id)initWithURL:(NSURL *)url documentAttributes:(NSDictionary **)dict;
и метод NSMutableAttributedString
- (BOOL)readFromURL:(NSURL *)url options:(NSDictionary *)options documentAttributes:(NSDictionary **)dict;
может теперь использовать службы фильтра для преобразования указанного файла в формат, распознанный текстовой системой Какао (простой текст, rtf, rtfd, или HTML). В дополнение к существующим типам области монтажа для простого текста, rtf, и rtfd, существует теперь NSHTMLPasteboardType, который может использоваться с этой целью, и может также быть считан (но не записан) NSTextView. В дополнение к этим типам области монтажа текстовые службы фильтра могут также преобразовать во введенные типы области монтажа имен файлов (снова, типов txt, rtf, rtfd, или HTML). Для поддержки использования служб фильтра ключ «Converted» предоставляется в возвращенных атрибутах документа, чтобы указать, был ли файл преобразован службой фильтра или не (если бы это было, затем текстовый редактор, например, вероятно не хотел бы записывать файл обратно в том же расположении). Кроме того, следующие методы
+ (NSArray *)textUnfilteredFileTypes;
+ (NSArray *)textUnfilteredPasteboardTypes;
+ (NSArray *)textFileTypes;
+ (NSArray *)textPasteboardTypes;
доступны для определения, какие типы могут быть загружены как текст.


TextView теперь попытается открыть ссылки, если не будет никакого делегата, или метод делегата для обработки ссылок возвращается НЕТ. Обратите внимание на то, что textview не мог бы быть в состоянии открыть некоторые ссылки, поскольку он не имеет надлежащего базового URL во многих случаях.


Мы теперь обрабатываем следующий новый ключ в documentAttributes словаре при чтении/записи файлов:

«Только для чтения»: NSNumber, содержащий интервал; 0 или меньше: доступный для редактирования, 1 или больше: только для чтения. Если не существующий, подразумевает значение 0, т.е. доступный для редактирования. Обратите внимание на то, что состояние только для чтения не имеет никакого отношения к защите файловой системы; это просто указывает, как документ должен быть представлен пользователю. TextEdit имеет новый пункт меню для использования в своих интересах этой установки.


Существуют теперь первые методы действия респондента для разговора пользовательского видимого текста в Какао,
- (void)startSpeaking:(id)sender;
- (void)stopSpeaking:(id)sender;
реализованный на NSTextView, и который может быть реализован как надлежащий на других респондентах. Контекстное меню значения по умолчанию NSTextView содержит элементы для вызова этих методов.


Метод NSTextView
- (BOOL)shouldChangeTextInRange:(NSRange)affectedCharRange
replacementString:(NSString *)replacementString;
если textview не будет доступен для редактирования, теперь автоматически возвратится НЕ. Это предотвращает некоторые экземпляры, в которых textview мог быть изменен пользовательскими действиями даже при том, что он был установлен быть недоступным для редактирования. Общее правило, соблюденное здесь, состоит в том, что NSTextView, как уровень представления в текстовой структуре системы контроллера представления модели, осуществляет любые ограничения на взаимодействие с пользователем и соответственно используется для действий, непосредственно причиняющихся пользовательскими действиями. Программируемые изменения в тексте, для которого не должны быть нужными те ограничения, должны быть внесены на уровне модели, т.е. в NSTextStorage.

Одна вещь иметь в виду в этом соединении состоит в том, что действия, зарегистрированные на стеке отмены текстовой системой, имеют место на уровне модели. Поэтому, если textview в какой-либо точке изменится от того, чтобы быть доступным для редактирования к тому, чтобы не быть доступным для редактирования, то любые действия, связанные с ним все еще на стеке отмены, все еще будут в состоянии быть отмененными. Если изменение в editability предназначается, чтобы быть необратимым (например, если это соответствует изменению, посвящающему себя безвозвратно базе данных), тогда продвигается, должен быть взят для удаления любых таких действий отмены во время изменения. С другой стороны, если изменение в editability обратимо, то то изменение должно самостоятельно делаться невыполнимым, так, чтобы это было бы отменено в процессе передачи стека отмены прежде, чем достигнуть любых элементов, которые изменят текст.


NSLayoutManager теперь обеспечивает порог для текстового сглаживания. Это смотрит на значение по умолчанию, установленное Предпочтениями. Если размер шрифта меньше, чем или равен этому пороговому размеру, текст представляется искаженный NSLayoutManager. Можно изменить пороговое значение от области General приложения Установок системы.


NSDrawer

Несколько проблем в NSDrawer были теперь решены. Во-первых, была проблема, заставившая секции с максимальным размером содержания не быть в состоянии быть вручную измененной к тому максимальному размеру. Это было фиксировано. Во-вторых, была проблема с setContentSize: который не интерпретировал его параметр правильно. Это было фиксировано, но приложения, соединившиеся против предыдущих версий Какао или AppKit, будут продолжать использовать старое поведение. В-третьих, метод делегата drawerWillResizeContents:toSize: не отправлялся; теперь это. Для сравнения с NSAppKitVersionNumber номер версии, в котором произошли эти изменения, был 592.


NSColorPanel

NSColorPanel может теперь переключиться между видимым / скрытый.

Любой пункт меню, соответствующий пункт меню «Show Colors» по умолчанию в IB, покажет новое поведение. Вместо того, чтобы просто показать цветную панель, пункт меню теперь переключит видимость цветной панели. Если цветная панель уже будет скрыта, то она упорядочит его передняя сторона. Если цветной панели уже упорядочат, то передняя сторона, выбирая пункт меню скроет цветную панель.

Ваш пункт меню «Show Colors» только покажет это новое поведение, если это будет цель, FirstResponder, и это - действие, orderFrontColorPanel:. Далее, если заголовок Вашего пункта меню будет соответствовать значение по умолчанию в IB (локализованное сравнение), «Покажите Цвета», то тогда проверка меню будет заголовок Ваше меню соответственно, чтобы указать, скроет ли выбор пункта меню или покажет цветную панель. Если Ваш заголовок не переключается соответственно, это или потому что заголовок пунктов меню не соответствует значение по умолчанию от IB, или у Вас есть пользовательский подкласс NSApplication, переопределяющего validateMenuItem: и не вызывает [супер validateMenuItem:].


NSFontPanel

NSFontPanel может теперь переключиться между видимым / скрытый.

Любой пункт меню, соответствующий пункт меню «Show Fonts» по умолчанию в IB, покажет новое поведение. Вместо того, чтобы просто показать панель шрифта, пункт меню теперь переключит видимость панели шрифта. Если панель шрифта уже будет скрыта, то она упорядочит его передняя сторона. Если панели шрифта уже упорядочат, то передняя сторона, выбирая пункт меню скроет панель шрифта.

Ваш пункт меню «Show Fonts» только покажет это новое поведение, если это будет цель, совместно используемый объект NSFontManager (или значок «Font Manager» в Вашем документе IB), и это - действие, orderFrontFontPanel:. Далее, если заголовок Вашего пункта меню будет соответствовать значение по умолчанию в IB (локализованное сравнение), «Покажите Шрифты», то тогда проверка меню будет заголовок Ваше меню соответственно, чтобы указать, скроет ли выбор пункта меню или покажет панель шрифта. Если Ваш заголовок не переключается соответственно, это, вероятно, потому что заголовок пунктов меню не соответствует значение по умолчанию от IB.


NSTabView

controlSize метод NSTabView был неправильно объявлен как: - (NSControlTint) controlSize. Это теперь правильно объявляется как: - (NSControlSize) controlSize. Это изменение не повредит compatability как NSControlTint, и NSControlSize являются оба тем же размером.


Пользователи могут теперь переместиться по представлению вкладки, и это - элементы с помощью клавиатуры. Используя клавишу Tab, пользователи могут поместить клавиатурный фокус в NSTabView и переключиться между элементами вкладки путем нажатия клавиш со стрелками. С вниманием на само представление вкладки, поражая вкладку возьмет пользователя к initialFirstResponder выбранного пункта. Продолжение снабдить вкладками возьмет пользователей через keyloop, который Вы определили, в конечном счете ведя пользователя из NSTabView (обычно представление, соединенное как nextKeyView представления вкладки в IB).

Существует несколько подробных данных, которые должны быть упомянуты:

- Первоначально предоставленный nextKeyView NSTabView помнят как «исходное следующее ключевое представление».

- Каждый NSTabViewItem должен обеспечить initialFirstResponder и допустимый цикл клавиатуры. Если Вы не делаете prvide один, предполагается, что Вы фактически не обеспечили цикла клавиатуры. Поэтому цикл клавиатуры будет автоматически создаваться.

- Последнее ключевое представление в цикле NSTabViewItem будет высказано «исходное следующее ключевое мнение» как его следующее ключевое представление. Если будет никакое исходное следующее ключевое представление, то последнее ключевое представление будет соединено проводом к самому представлению вкладки.

- Цикл клавиатуры, который Вы обеспечиваете, не должен содержать циклы. Если найдено, цикл может быть поврежден, так, чтобы переключение вкладок мимо последнего ключевого представления вынуло пользователей из представления вкладки. Расположение цикл повреждается, будут считать последним ключевым представлением элемента.

- Цикл клавиатуры, который Вы определяете, не должен вести за пределами представления NSTabViewItems. Если это обнаруживается, ссылка, заставляющая клавиатурный фокус оставить представление, может быть повреждена. Это расположение будут считать последним ключевым представлением элемента.

Сводка: Каждый NSTabView должен иметь исходное следующее ключевое представление (обычно предоставленный в IB). Каждому NSTabView элементы нужно дать initialFirstResponder и допустимый цикл клавиатуры. Обычно использование клавиши Tab возьмет пользователя к вкладке через цикл клавиатуры выбранных пунктов, и затем другую сторону.


NSCell

NSCell имеет поддержку рисования надлежащего цвета подсветки в неключевых окнах. Этот возврат метода цвет для использования при рисовании подсветки выделения:
- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView:(NSView *)controlView;
В прошлых разработчиках обычно предполагал, что цветное использование было [NSColor selectedControlColor]. Однако теперь некоторые средства управления хотят нарисовать с различными цветами подсветки выделения в зависимости от вещей, таких как ключевое состояние controlView, в котором выведена на экран ячейка. Чтобы быть уверенными, что Вы используете корректный цвет подсветки выделения, необходимо искать существующий код места, принимающие использование [NSColor selectedControlColor].


NSBrowser

setPath: содержит исправление ошибки, вызывающее небольшое, все же желательное изменение в поведении. Метод, и теперь делает, должен возвратить YES каждый раз, когда путь допустим, и НЕ иначе (ранее, это возвращается НЕ, если лист был соответствующим).

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


NSTableView

Табличные представления и представления схемы теперь позволяют Вам перетаскивать записи без приложения, являющегося активным. Это изменение только влияет на клиенты, использующие строку/элемент, базируемую, перетаскивая APIs. Перетаскивание от такой таблицы теперь действует больше как реализация NSTextViews перетаскивания. Если от таблицы, приложение не активно, и пользователи можно теперь перетащить, если они просто щелкнут, то выбор не будет затронут. В этой ситуации Вы приложение станет активным, но не изменится выбор.

Для упрощения этой функции NSTableView теперь реализует:
- (void)shouldDelayWindowOrderingForEvent:(NSEvent *)theEvent;
- (BOOL)acceptsFirstMouse:(NSEvent *)theEvent;

NSPDFImageRep

Размер репутации изображения теперь установлен от поля обрезки PDF's вместо поля носителей. Если они не соответствовали, можно найти, что изображение кажется больше.


NSMovie

- [NSMovie initWithURL:byReference:] будет теперь принимать и играть, сеть базировала URLs (http: rtsp: и т.д.). Начиная проигрывать фильм, NSMovieView не будет не изменяться. Необходимо будет зарегистрироваться в movieController для получения обратного вызова, когда размер изменится динамично, и обновите NSMovieView для соответствия.


NSView

NSView теперь имеет живое изменение размеров API:
- (void)viewWillStartLiveResize
- (void)viewDidEndLiveResize
Эти методы будут отправлены в представление, прежде чем живой изменят размеры, запускается, и после того, как оно заканчивается. В простом случае представление будет отправлено viewWillStartLiveResize, прежде чем первые изменят размеры работы на содержании окна и viewDidEndLiveResize после того, как последние изменяют размеры работы. Представление, неоднократно добавляющееся и удаляющееся из окна во время живого, изменяет размеры, получит только одно сообщение viewDidStartLiveResize (на первом разе, когда это добавляется к окну), и одно сообщение viewDidEndLiveResize (когда окно завершилось, живые изменяют размеры работы). Это позволяет суперпредставлению, такому как NSBrowser добавлять и удалять свои подпредставления NSMatrix во время живого, изменяют размеры без NSMatrix, получающего множественные вызовы этих методов.

Представление могло бы выделить структуры данных информации о рисовании кэша в viewWillStartLiveResize и должно очистить эти структуры данных в viewDidEndLiveResize. Кроме того, представление, делающее оптимизированное получение во время живого, изменяет размеры, мог бы хотеть сделать полное получение после viewDidEndLiveResize, несмотря на то, что представление не должно предполагать, что имеет контекст получения в viewDidEndLiveResize (так как это, возможно, было удалено из окна во время живого, изменяют размеры). Представление, хотящее перерисовать себя после живой, изменяет размеры, должен вызвать [сам setNeedsDisplay:YES] в viewDidEndLiveResize.

Подкласс представления должен вызвать супер от этих методов.
- (BOOL)inLiveResize
Это - удобный метод, который, как ожидают, будет вызван от-drawRect: принять решения относительно оптимизированного получения.

Если метод вызывается на неправильное представление, unlockFocus метод NSVIEW теперь повышает исключение NSInvalidArgumentException.

Также посмотрите в другом месте в этом документе для обсуждения нового метода setKeyboardFocusRingNeedsDisplayInRect:.


NSOpenGLPixelFormat

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

Обратите внимание на то, что методы NSOpenGLPixelFormat-initWithData:-setAttribute: и - атрибуты осуждаются и будут удалены в будущем выпуске. Также не рекомендуется заархивировать NSOpenGLPixelFormat.

Существует два новых значения перечисления NSOpenGLPixelFormatAttribute, не перечисленные в заголовках, но доступные в Mac OS X 10.1:
NSOpenGLPFASampleBuffers = 55
NSOpenGLPFASamples = 56
Это для поддержки GL_ARB_multisample.


NSFont

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

- [Подстрочный элемент NSFont] метод раньше возвращал значение с разрывом строки (продвижение), добавленное для японского семейства шрифтов Хирагино в 10,0. В 10,1 метод возвращает корректное значение подстрочного элемента, указанное в шрифте. Для получения высоты строки по умолчанию, которая должна включать надстрочный элемент, подстрочный элемент, и продвижение, использовать - [NSFont defaultLineHeightForFont] метод.


NSColor

NSColor теперь имеет secondarySelectedControlColor метод, обеспечивание несколько приглушенного цвета раньше выводило на экран выборы в tableview, браузере, и т.д., когда неактивный. Кроме того, disabledControlTextColor метод NSCOLOR теперь правильно архивирует себя. Эти цвета могут быть разархивированы во всех системах, назад к 10,0.


NSStatusBar

NSStatusBar позволяет Вам помещать персистентные элементы UI в строку меню. Существует несколько важных вещей отметить.

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

2. Пространство в строке меню является драгоценным товаром. В зависимости от размера меню активного приложения и размера дисплея пользователя, Ваши элементы строки состояния могли бы быть отсечены и не выводиться на экран. Кроме того, другие факторы могли бы заставить элементы строки состояния прекращать отображать постоянно в будущем выпуске. Из-за этих причин не рассчитывайте на элемент строки состояния как на единственный способ сообщить пользователю состояния. Это разумно, рассматривая № 1 выше.

3. Расположение и размер элементов строки состояния могли бы измениться в будущем выпуске. Не делайте слишком много предположений о расположении и размере этих элементов.



NSScroller

Перечисление NSScrollArrowPosition было изменено для размещения дополнительного стиля, представленного в 10,1 (стрелки вместе). Обратите внимание на то, что NSScrollerArrowsMaxEnd и значения NSScrollerArrowsMinEnd теперь осуждаются. Можно только получить доступ к NSScrollerArrowsNone или NSScrollerArrowsDefaultSetting. NSScrollerArrowsDefaultSetting получает конфигурацию от предпочтений пользователя.


NSSplitView

NSSplitView теперь размещает рядом свои подпредставления и разделители правильно. - [NSSplitView drawDividerInRect:] раньше получал высоту, которая на 2 пикселя выше, чем значение возвратилось из-dividerThickness.


Строковое получение

В выпусках до 10,1, были случаи в который - [NSString drawAtPoint:withAttributes:] и - [NSAttributedString drawAtPoint:] сместил бы точку, в которой была нарисована строка, или отсеките строку неправильно, если точка была указана, чтобы поместить строку частично или полностью за пределами границ текущего фокусируемого представления. Это было фиксировано в 10,1.

Одно предостережение состоит в том что поведение стилей абзаца NSRightTextAlignment и NSCenterTextAlignment с drawAtPoint: вызовы не четко определены. Если Вы хотите использовать эти стили выравнивания со строковым получением, мы строго рекомендуем использование drawInRect: строковые вызовы рисования, а не drawAtPoint: варианты. Для обратной совместимости, строковой реализации рисования в 10,1 попытках подражать поведению предыдущих выпусков, когда правильное или центральное выравнивание используется с drawAtPoint: вызовы, но это поведение не гарантируется и может измениться от выпуска до выпуска.



Отмечает определенный для Mac OS X 10.0


NSToolbar

NSToolbar и NSToolbarItem являются новыми классами, обеспечивающими механизм для создания стандартных панелей инструментов, которые можно присоединить к названным окнам.

Для создания NSToolbar, необходимо будет предоставить делегату, который может предоставить NSToolbarItems по требованию и ответить на многие важные вопросы. Во-первых, делегат панели инструментов обеспечивает, идентификатором, списком элементов панели инструментов по умолчанию. Этот список используется при возвращении для установки по умолчанию и построении начальной панели инструментов. Затем, делегат обеспечивает список позволенных идентификаторов элемента. Если панель инструментов настраиваема, позволенный список элемента используется для построения палитры настройки. Наконец, делегат должен реализовать метод, возвращающий NSToolbarItems для данного идентификатора элемента.

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

Большинство панелей инструментов будет содержать простые активируемые по щелчку элементы. Самый простой NSToolbarItem определяется его значком, меткой, метка палитры (используемый в настроить листе), цель, действие, подсказка и другие атрибуты. Большинство панелей инструментов может достаточно быть представлено с помощью этих простых подобных кнопке элементов. Однако при необходимости в чем-то пользовательском на панели инструментов это возможно. Пользовательские представления предоставлены путем вызова setView: на NSToolbarItem. Например, если Вы хотите, чтобы Ваше средство разработки имело популярность для выбора стилей сборки, можно предоставить элементу панели инструментов NSPopupButton.

Существует несколько идентификаторов стандартного товара, о которых знает NSToolbar. NSToolbarSeparatorItemIdentifier является идентификатором для стандартного вертикального разделителя строки. NSToolbarSpaceItemIdentifier представляет фиксированное пространство ширины, которое может быть перетащено на панель инструментов. NSFlexibleSeparatorItemIdentifier представляет пространство переменной ширины. Существует также NSToolbarShowColorsItemIdentifier, NSToolbarShowFontsItemIdentifier, NSToolbarPrintItemIdentifier и NSToolbarCustomizeToolbarItemIdentifier. Эти элементы только доступны идентификатором.

Если необходимо изменить действие, отправленное стандартным товаром, можно сделать это в toolbarWillAddItem:.

Несколько методов были добавлены к NSWindow для помогания поддержать NSToolbar. NSWindow теперь позволяет Вам добавить панель инструментов, показать/скрыть текущую панель инструментов и выполнить палитру настройки. Если Вы добавляете пункты меню в своем приложении и сцепляете их до toggleToolbarShown: и runToolbarCustomizationPalette: NSWindow будет заботиться о проверке. В частности пункт меню с toggleToolbarShown: поскольку его действие будет должным образом заголовок пункт меню, зависящий от текущего состояния панели инструментов.
/* Set and Get a window's toolbar. */
- (void)setToolbar:(NSToolbar*)toolbar;
- (NSToolbar *)toolbar;
/* Targets / action methods. */
- (void)toggleToolbarShown:(id)sender;
- (void)runToolbarCustomizationPalette:(id)sender;
NSWindow показывает панель инструментов путем роста размера окна, таким образом хранения предметной области тем же размером. Если окно будет тем же размером как экран со скрытой панелью инструментов, то показ заставит содержание уменьшаться. Тем путем изменять размеры поле не убегает экран.

Пункты меню "Hide/Show Toolbar" и "Customize Toolbar..." приложения (в том порядке) должны быть помещены в то же меню. В почти всех ситуациях пункты меню имеют большую часть смысла в соответствии с меню «Window». См. Инструкции по Интерфейсу Воды для получения дополнительной информации о том, куда поместить эти пункты меню.

Известные ошибки и Ограничения:

- Перетаскивание на панель инструментов когда-то заставит отсеченные элементы «скользить» в представление временно.
- Если содержание окна не изменяемого размера, показывая, что панель инструментов может иногда выполнять нижнюю часть окна от экрана.
- В настоящее время нет никакой поддержки объявления элементов как несъемные (?). Все элементы являются съемными.
- На элементах панели инструментов нет никакого перетаскивания поддержки, за исключением того, что можно предоставить собственные представления, чтобы сделать это.
- В настоящее время нет никакого способа указать определенное расположение листа настройки, например Вы не можете установить размер листа
- В настоящее время нет никакого состояния, у которого потребовали, для элементов когда в текстовом режиме Only.
- Элементы панели инструментов выглядят неактивными во время, показывают/скрывают анимацию.
- Если делегат возвращает ноль для определенного элемента, панель инструментов показывает странный мусор вместо того, чтобы просто отбросить элемент от панели инструментов.


NSStepper, NSStepperCell

Это - новый подкласс управления, реализующий то, что в Углероде вызывают 'небольшими стрелками'. Это - два управления частью, постепенно увеличивающее и постепенно уменьшающее значение. Это - общий контроль для записи даты и времени. NSStepper является подклассом NSControl, NSStepperCell является подклассом NSActionCell. Они оба реализуют следующий дополнительный API:
- (double)minValue;
- (void)setMinValue:(double)minValue;
- (double)maxValue;
- (void)setMaxValue:(double)maxValue;
- (double)increment;
- (void)setIncrement:(double)increment;
- (BOOL)valueWraps;
- (void)setValueWraps:(BOOL)valueWraps;
- (BOOL)autorepeat;
- (void)setAutorepeat:(BOOL)autorepeat;
Можно установить и получить минимум, максимум, и постепенно увеличить значения. Если valueWraps будет установлен в ДА, то при постепенном увеличении или постепенном уменьшении, значение перенесет минимум или максимум. Если это не перенесется, то это будет прикреплено. Если автоповтор будет ДА, то первая мышь вниз сделает один инкремент и после задержки 0,5 секунд, это постепенно увеличится по курсу 10 раз в секунду. Если автоповтор будет нет, то он сделает один инкремент на мыши в управлении. Значения по умолчанию для значения, минута, макс., и инкремент 0, 0, 59, и 1. И valueWraps и автоповтор установлены в YES.


NSWindow

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

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

Прямоугольник передал - [NSWindow cacheImageInRect:] теперь сделан интегралом прежде, чем кэшировать изображение, избежать сглаживать артефакты.

Следующий новый APIs представляет возможности CGS на уровне NSWindow:
// allow for transparent parts in the window - default is opaque = YES
- (void)setOpaque:(BOOL)isOpaque
- (BOOL)isOpaque;
// this call applies an alpha value to the entire window
- (void)setAlphaValue:(float)windowAlpha;
- (float)alphaValue;
setHasShadow NSWINDOW: если установка тени изменяется, теперь лишает законной силы тень окна. Это заставляет тень окна быть повторно вычисленной. Приложения, рисующие пользовательские формы окна, могут хотеть использовать этот метод, чтобы повторно вычислить тень окна каждый раз, когда изменяется форма окна. Рекомендуемый способ сделать это на данный момент должно соединить вызовы к этому методу:
-(void)customDrawingRoutine {
<draw window shape>
[window setHasShadow:NO];
[window setHasShadow:YES];
}
Следующее позволяет дополнительное управление свойствами окна:
// resize window to saved frame.  If flag is YES, resize even if window is non-resizable
- (BOOL)setFrameUsingName:(NSString *)name force:(BOOL)flag;
// indicate whether a window can be hidden during -[NSApplication hide:].  Default is YES
- (void)setCanHide:(BOOL)flag;
- (BOOL)canHide;
// show/hide resize corner (does not effect resizable property)
- (void)setShowsResizeIndicator:(BOOL)show;
- (BOOL)showsResizeIndicator;
Следующий новый API поддерживает анимацию окна, измените размеры:
- (void)setFrame:(NSRect)frameRect display:(BOOL)displayFlag animate:(BOOL)animateFlag;
Если animateFlag ДА, таймер создается для анимации перехода от текущего кадра до нового кадра. Если animateFlag нет, этот вызов совпадает с-setFrame:display:. Иерархия представления рекурсивно выведена на экран на каждом, изменяют размеры инкремента, если displayFlag является YES.

Время для изменять размеры анимации может быть указано подклассом путем переопределения:
- (NSTimeInterval)animationResizeTime
Реализация по умолчанию использует значение для пользовательского значения по умолчанию NSWindowResizeTime как время в секундах для изменения размеров на 150 пикселей. Если неуказанный, NSWindowResizeTime составляет.33 секунд.

Уровни окна в NSWindow.h теперь определяются с точки зрения функции в <CoreGraphics/CGWindowLevel.h>. Это означает, что уровни окна больше не являются константами, таким образом, они не могут использоваться в статических инициализаторах. Кроме того, значения некоторых уровней окна изменились; например, NSModalPanelWindowLevel является теперь меньше, чем NSMainMenuWindowLevel, так, чтобы модальные панели не появлялись выше меню. Приложения, использующие явные уровни окна, должны восстановить.

Реализация oneShot окон изменилась. CGSWindowID для oneShot окна теперь сохраняется, когда окно закрывается, но освобождено запоминающее устройство. Задержанные oneShot окна больше не поддерживаются, и hide-deactivate окнам явно препятствуют быть oneShot окнами из-за ограничения, где мы не можем гарантировать своевременную перерисовку для hide-deactivate окна.

Следующий новый API позволяет Вам создавать NSWindow, данный Углерод WindowRef:
@interface NSWindow(NSCarbonExtensions)
// create an NSWindow for a Carbon window - windowRef must be a Carbon WindowRef
- (NSWindow *)initWithWindowRef:(void *)windowRef;
// return the Carbon WindowRef passed into initWithWindowRef:
- (void *)windowRef;
@end
См. <HIToolbox/MacWindows.h> для WindowRef API.


Строки типа файла HFS

Для поддержки среды, в которой тип файла может быть обозначен или расширением файла или типом файла HFS новая форма строки типа файла была представлена. Строки типа файла (традиционно расширения файла), которые приняты или возвращены многими методами Какао, могут теперь содержать закодированный тип файла HFS.

Строки типа файла, содержащие расширение файла, все еще приемлемы в каждой ситуации, в которой они были приемлемы прежде.

Несколько новых функций, объявленных в <Foundation/NSHFSFileTypes.h>, были добавлены, чтобы помочь управлять этими новыми строками типа файла:
NSString *NSFileTypeForHFSTypeCode(OSType hfsFileTypeCode);
Учитывая код типа файла HFS, эта функция возвращает автовыпущенную строку, кодирующую тип файла, как описано выше.
OSType NSHFSTypeCodeFromFileType(NSString *fileTypeString);
Учитывая строку вида, закодированного NSFileTypeForHFSTypeCode (), эта функция возвращает соответствующий код типа файла HFS. Это возвращает нуль иначе.
NSString *NSHFSTypeOfFile(NSString *fullFilePath);
Учитывая имя файла, эта функция возвращает автовыпущенную строку, кодирующую тип файла файла HFS, как описано выше, или ноль, если работа не была успешна.

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

Следующие изменения были внесены в различных классах для использования в своих интересах строк типа HFS:

-fileExtensionsFromType NSDocumentController: теперь возвращает массив строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла.-runModalOpenPanel:forTypes: и-typeFromFileExtension: ведите себя, как они всегда имеют, но теперь примут строки типа файла, содержащие закодированные типы файлов HFS, а также расширения файла.-openDocumentWithContentsOfFile:display: и-openDocumentWithContentsOfURL:display: теперь примите тип файла HFS во внимание файлов при решении того, какой подкласс NSDocument нужно инстанцировать.

+imageFileTypes и +imageUnfilteredFileTypes NSIMAGE теперь возвращаемые массивы строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла.-initByReferencingFile:-initWithContentsOfFile: и-initWithContentsOfURL: теперь примите тип файла HFS во внимание файлов при решении того, какой подкласс NSImageRep нужно инстанцировать для представления изображений в файле.

+imageFileTypes и +imageUnfilteredFileTypes NSImageRep теперь возвращаемые массивы строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла. +imageRepClassForFileType: ведет себя, как это всегда имеет, но теперь примет строки типа файла, содержащие закодированные типы файлов HFS, а также расширения файла. +imageRepWithContentsOfFile: +imageRepWithContentsOfURL: +imageRepsWithContentsOfFile: и +imageRepsWithContentsOfURL: теперь примите тип файла HFS во внимание файлов при решении того, какой подкласс NSImageRep нужно инстанцировать.

+movieUnfilteredFileTypes NSMOVIE теперь возвращает массив строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла.

-beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo NSOpenPanel:-runModalForDirectory:file:types:-runModalForTypes: и-runModalForDirectory:file:types:relativeToWindow: ведите себя, как они всегда имеют, но теперь примут строки типа файла, содержащие закодированные типы файлов HFS, а также расширения файла.

В NSSavePanel строки типа файла, содержащие закодированные типы файлов HFS, не являются допустимыми значениями для атрибута, к которому получает доступ-setRequiredFileType: и-requiredFileType.

+soundUnfilteredFileTypes NSSOUND теперь возвращает массив строк типа файла, которые могут содержать закодированные типы файлов HFS, а также расширения файла.

+iconForFileType NSWORKSPACE: теперь принимает строки типа файла, содержащие закодированные типы файлов HFS, а также расширения файла.


Сценарии

Начиная с Беты Общественности Mac OS X платформы Сценариев и AppKitScripting были объединены в платформы Основы и AppKit, соответственно.

В результате этого 4 новых заголовочных файла были добавлены к AppKit.framework/Headers:

- NSApplicationScripting.h
- NSDocumentScripting.h
- NSTextStorageScripting.h
- NSWindowScripting.h

Там все еще Пишут сценарий и платформы AppKitScripting в Mac OS X, но это простые тупики, библиотеки которых импортируют библиотеки Foundation и AppKit и чьи заголовочные файлы импортируют заголовочные файлы Основы и AppKit. Они не должны использоваться для новой разработки.

Больше информации об изменениях сценариев может быть найдено в информации о версии Основы.


NSPageLayout

NSPageLayouts являются теперь визуализуемыми как модальные документом листы. Был добавлен новый метод:
- (void)beginSheetWithPrintInfo:(NSPrintInfo *)printInfo modalForWindow:(NSWindow *)docWindow delegate:(id)delegate didEndSelector:(SEL)didEndSelector contextInfo:(void *)contextInfo;
Этот метод представляет лист макета страницы для printInfo, модального документом относительно docWindow. Когда модальный сеанс закончился, если ни делегат, ни didEndSelector не были нолем, метод, указанный didEndSelector, будет вызван на делегата, передавая contextInfo как параметр, среди других. Метод, указанный didEndSelector, должен иметь ту же подпись как:
- (void)pageLayoutDidEnd:(NSPageLayout *)pageLayout returnCode:(int)returnCode contextInfo:(void *)contextInfo;
Значением кода возврата будет NSCancelButton или NSOKButton.

NSPageLayout больше не является подклассом NSPanel. Это - прямой подкласс NSObject. Это больше не действительно для отправки - [NSView viewWithTag:] к NSPageLayout.

Меры, которые принимает метод, изменились: + [NSPageLayout pageLayout] теперь возвратит новый экземпляр NSPageLayout каждый раз, когда это вызывается. Существует не совместно использованный NSPageLayout.

Были осуждены некоторые методы:

- [NSPageLayout convertOldFactor:newFactor:] будет всегда устанавливать оба из его параметров тому же значению.
- pickedButton: никогда не будет отправляться NSPageLayout из AppKit.
- pickedOrientation: никогда не будет отправляться NSPageLayout из AppKit.
- pickedPaperSize: никогда не будет отправляться NSPageLayout из AppKit.
- pickedUnits: никогда не будет отправляться NSPageLayout из AppKit.


NSPrintOperation

Панели, что работа печати дисплеи является теперь визуализуемой как модальные документом листы. Был добавлен новый метод:
- (void)runOperationModalForWindow:(NSWindow *)docWindow delegate:(id)delegate didRunSelector:(SEL)didRunSelector contextInfo:(void *)contextInfo;
Предполагая, что работа для печати (и не EPS или PDF, копирующий), этот метод заставляет следующие действия выполняться объектом операции печати, хотя не обязательно прежде или после того, как это возвратилось:
- Если значение атрибута, установленного-setShowPanels, не нет, NSPrintPanel представлен как лист, который модален документом к docWindow.
- Если пользователь не отменил работу с помощью NSPrintPanel, открыта панель прогресса, которая или модальна документом к docWindow или модальна приложением, в зависимости от атрибута, установленного-setCanSpawnSeparateThread (см. ниже). Эта панель включает, среди прочего, Кнопку отмены.
- Представление работы распечатано до отмены или завершения. Выполняется ли печать в ее собственном выделенном потоке печати, зависит от атрибута, установленного-setCanSpawnSeparateThread.
- Панель прогресса закрывается.
На отмену или завершение, если ни делегат, ни didRunSelector не были нолем, метод, указанный didRunSelector, будет вызван на делегата, передавая contextInfo как параметр, среди других. Метод, указанный didRunSelector, должен иметь ту же подпись как:
- (void)printOperationDidRun:(NSPrintOperation *)printOperation success:(BOOL)success contextInfo:(void *)contextInfo;
Если работа печати работала к завершению без отмены или ошибки, НЕТ иначе, значением успеха будет YES.

Фактическое представление, распечатывающее, который делает работа печати, может быть сделано иметь место в специализированном потоке печати. Пара новых методов была добавлена:
- (void)setCanSpawnSeparateThread:(BOOL)canSpawnSeparateThread;
- (BOOL)canSpawnSeparateThread;
Атрибут, к которому получают доступ с помощью этих двух методов, влияет на поведение-runOperationModalForWindow:delegate:didRunSelector:contextInfo: если работа не для копирования PDF или EPS. Если это ДА, панель прогресса, показанная во время печати, показана как модальный документом лист, и печать выполняется в ее собственном выделенном потоке печати, автоматически создающемся и уничтожающемся NSPrintOperation. Если Это нет, панель прогресса, показанная во время печати, показана как модальное приложением окно, и печать выполняется в основном потоке приложения.

Значения некоторых методов заслуживают разъяснения:
Атрибут, к которому получают доступ с помощью-setShowPanels: и-showPanels не влияет, представлена ли панель прогресса-runOperation или-runOperationModalForWindow:delegate:didRunSelector:contextInfo: только действительно ли представлен NSPrintPanel.

Ни один из методов класса NSPrintOperation-создания не делает созданный объект текущей работой для потока больше. Вместо этого работа печати становится текущей только когда необходимый:
- В-runOperation случае работа печати сделана текущей, прежде чем любой NSPrintPanel мог бы быть представлен и держится в курсе, пока работа печати не завершилась или была отменена.
- В-runOperationModalForWindow:delegate:didRunSelector:contextInfo: случай, работа печати сделана текущей в потоке, в котором фактическая печать представления должна произойти, сразу прежде чем печать представления начинается и держится в курсе, пока печать представления не завершилась или была отменена.

NSPrintPanel

NSPrintPanels являются теперь визуализуемыми как модальные документом листы. Был добавлен новый метод:
- (void)beginSheetWithPrintInfo:(NSPrintInfo *)printInfo modalForWindow:(NSWindow *)docWindow delegate:(id)delegate didEndSelector:(SEL)didEndSelector contextInfo:(void *)contextInfo;
Этот метод представляет лист панели печати для printInfo, модального документом относительно docWindow. Когда модальный сеанс закончился, если ни делегат, ни didEndSelector не были нолем, метод, указанный didEndSelector, будет вызван на делегата, передавая contextInfo как параметр, среди других. Метод, указанный didEndSelector, должен иметь ту же подпись как:
- (void)printPanelDidEnd:(NSPrintPanel *)printPanel returnCode:(int)returnCode contextInfo:(void *)contextInfo;
Значением кода возврата будет NSCancelButton или NSOKButton. Даже если пользователь нажал кнопку Preview, NSOKButton будет возвращен.

NSPrintPanel больше не является подклассом NSPanel. Это - прямой подкласс NSObject. Это больше не действительно для отправки - [NSView viewWithTag:] к NSPrintPanel.

Меры, которые принимает метод, изменились: + [NSPrintPanel printPanel] теперь возвратит новый экземпляр NSPrintPanel каждый раз, когда это отправляется. Существует не совместно использованный NSPrintPanel.

Были осуждены некоторые методы:
- pickedAllPages: никогда не будет отправляться NSPrintPanel из AppKit.
- pickedButton: никогда не будет отправляться NSPrintPanel из AppKit.
- pickedLayoutList: никогда не будет отправляться NSPrintPanel из AppKit.

NSDocument

NSPageLayouts являются теперь визуализуемыми NSDocuments как модальные документом листы. Был добавлен новый метод:
- (void)runModalPageLayoutWithPrintInfo:(NSPrintInfo *)printInfo delegate:(id)delegate didRunSelector:(SEL)didRunSelector contextInfo:(void *)contextInfo;
Этот метод представляет лист макета страницы для printInfo, документа модально относительно принципиального окна документа. Когда модальный сеанс закончился, если ни делегат, ни didRunSelector не были нолем, метод, указанный didRunSelector, будет вызван на делегата, передавая contextInfo как параметр, среди других. Метод, указанный didRunSelector, должен иметь ту же подпись как:
- (void)documentDidRunModalPageLayout:(NSDocument *)document accepted:(BOOL)accepted contextInfo:(void *)contextInfo;
если пользователь использовал кнопку OK или клавишу Return для отклонения панели макета страницы, НЕТ иначе, принятый будет YES.

Подклассификаторам NSDocument теперь дают возможность подготовить любую панель NSPageLayout, прежде чем это будет представлено пользователю. Был добавлен новый метод:
- (BOOL)preparePageLayout:(NSPageLayout *)pageLayout;
Этот метод вызывается-runModalPageLayoutWithPrintInfo: и-runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo: сделать любую настройку pageLayout панели. Если панель была успешно подготовлена, и НЕ иначе, это возвращает YES. Реализация по умолчанию пуста и возвращает YES.

Панели, что работа печати дисплеи является теперь визуализуемой NSDocuments как модальные документом листы. Был добавлен новый метод:
- (void)runModalPrintOperation:(NSPrintOperation *)printOperation delegate:(id)delegate didRunSelector:(SEL)didRunSelector contextInfo:(void *)contextInfo;
Этот метод выполняет printOperation, документ модально относительно принципиального окна документа. Когда работа закончила работать, если ни делегат, ни didRunSelector не были нолем, метод, указанный didRunSelector, будет вызван на делегата, передавая contextInfo как параметр, среди других. Метод, указанный didRunSelector, должен иметь ту же подпись как:
- (void)documentDidRunModalPrintOperation:(NSDocument *)document success:(BOOL)success contextInfo:(void *)contextInfo;
Если работа печати работала к завершению без отмены или ошибки, НЕТ иначе, значением успеха будет YES.

- [NSDocument runPageLayout:] теперь, вместо того, чтобы вызвать-runModalPageLayoutWithPrintInfo: вызывает-runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo: с частными значениями для делегата, didRunSelector, и contextInfo параметрами.


NSView

- drawSheetBorderWithSize: никогда не будет отправляться в NSView из AppKit.

Существует два новых метода, добавленные к NSView:-viewDidMoveToWindow и-viewDidMoveToSuperview. Реализация по умолчанию ничего не делает. Подклассы NSView могут переопределить эти методы, чтобы сделать дополнительные инициализации в новом окне/суперпредставлении.


NSFont

NSFont теперь может теперь возвратить число глифов в шрифте:
- (unsigned)numberOfGlyphs;
Два метода изменили свое поведение:
+ (void)setUserFixedPitchFont:(NSFont *)aFont;
+ (void)setUserFont:(NSFont *)aFont;
Эти методы воздействуют на текущий домен приложения для ключей "NSFixedPitchFont" и "NSFont" соответственно. Раньше, не было никаких программируемых средних значений удаления значений по умолчанию для домена приложения. Эти методы были изменены, чтобы позволить «нолю» быть указанным как параметр шрифта. В этом случае значения по умолчанию удалены из домена приложения.

Следующий новый метод возвращает шрифт «метки», определяющийся в Инструкциях по Интерфейсу пользователя Воды:
+ (NSFont *)labelFontOfSize:(float)fontSize;
Эти методы возвращают соответствующие размеры шрифта, определенные в Инструкциях по Интерфейсу пользователя Воды:
+ (float)systemFontSize;
+ (float)smallSystemFontSize;
+ (float)labelFontSize;
С комбинацией этих методов можно запросить все изменения шрифта Воды:
Системный шрифт [NSFont systemFontOfSize: [NSFont systemFontSize]]
Системный шрифт (подчеркнутый) [NSFont boldSystemFontOfSize: [NSFont systemFontSize]]
Маленький Системный шрифт [NSFont systemFontOfSize: [NSFont smallSystemFontSize]]
Маленький Системный шрифт (подчеркнутый) [NSFont boldSystemFontOfSize: [NSFont smallSystemFontSize]]
Шрифт приложения [NSFont userFontOfSize:-1.0]
Шрифт Фиксированной Подачи приложения [NSFont userFixedPitchFontOfSize:-1.0]
Шрифт метки [NSFont labelFontOfSize: [NSFont labelFontSize]]


NSFontPanel

Размер экземпляра NSFontPanel изменился начиная с Общедоступной Беты. Это означает любое разделение на подклассы приложений NSFontPanel и добавление, что должны быть перекомпилированы новые переменные экземпляра.


NSSplitView

Существуют ситуации, в которых необходимо знать, разрушено ли подпредставление NSSplitView. Был добавлен новый метод:
- (BOOL)isSubviewCollapsed:(NSView *)subview;
Если подпредставление NSSplitView находится в разрушенном состоянии, НЕТ иначе, этот метод возвращает YES.


Преобразование типов области монтажа

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

- PDF: какао NSPDFPasteboardType <-> углерод 'PDF'
- RTF: какао NSRTFPboardType <-> углерод 'RTF'
- Различный файл, URL и типы текстов


Справка

Приложения могут обеспечить свои собственные книги справки путем добавления plist записей для CFBundleHelpBookFolder и CFBundleHelpBookName. Папка, указанная CFBundleHelpBookFolder, должна содержать локализованную версию книги справки приложения. Если эта книга справки будет указана, то она будет открыта в HelpViewer, когда будет выбран элемент меню справки.

Для получения дополнительной информации посмотрите раздел «Registering a Help Book» в http://developer .apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/AppleHelp/Apple_Help/index.html

Привязка клавиш

В общедоступной Бете функциональные клавиши F1-F4 были отображены на отмене: сокращение: копия: и paste:. Мы отключили это отображение и планируем позволить пользовательскую настройку в будущем выпуске. Однако эта привязка может быть восстановлена через механизм привязки клавиш Какао. F5 является все еще привязкой клавиш по умолчанию для «полного».


События

RightMouseDown в окне неактивного приложения не будет поставлен - [NSWindow sendEvent:]. Событие будет поставлено - [NSApplication sendEvent:], но windowNumber будет 0.


Перетаскивание

- draggingSequenceNumber и-draggedImageLocation теперь работают.-draggedImage допустим для локальных перетаскиваний.

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

Мы добавили следующий новый API:
typedef unsigned int NSDragOperation
NSDragOperationMove, NSDragOperationDelete и NSDragOperationEvery были добавлены к списку перечисляемых значений для NSDragOperation. NSDragOperationAll осуждается.

Источник перетаскивания теперь сказан о перемещении draggedImage, очень поскольку место назначения перетаскивания отправляется draggingUpdated: сообщения:
- (void)draggedImage:(NSImage *)image movedTo:(NSPoint)screenPoint;
Этот после метода осуждает draggedImage:endedAt:deposited: и включает индикацию относительно работы, выполняемой местом назначения, а не принятием указания булевской переменной.
- (void)draggedImage:(NSImage *)image endedAt:(NSPoint)screenPoint operation:(NSDragOperation)operation;
Перетаскивающий целевой протокол имеет один новый метод, который место назначения может реализовать, чтобы быть уведомленным, когда работа перетаскивания заканчивается в некотором другом месте назначения. Это могло бы использоваться местом назначения, делающим авторасширение для разрушений, любой авторасширяется. Этот метод еще не реализован:
- (void)draggingEnded:(id <NSDraggingInfo>)sender

Листы

Модальность документа листов теперь лучше осуществляется. В то время как документ находится в модальном состоянии (т.е. представление листа), пункты меню, имеющие отношение к документу и близкой кнопке документа, отключены.

modalDelegate больше не сохраняется ни одним модальным документом API. Удостоверьтесь, что Вы не рассчитываете на сдерживающее поведение существующего документа модальный APIs.


NSApplication

С добавлением модального документом состояния, подразумеваемого листами, для делегатов приложения стало трудным ответить YES или НЕ к-applicationShouldTerminate:. Часто, когда спросили завершиться, приложение хочет представить модальные документом предупреждения (листы) для грязных документов, давая пользователю возможность сохранить документы, выйти без сохранения или отменить завершение.

Чтобы позволить приложениям делать это, не будучи должен ввести некоторый внешний модальный цикл, applicationShouldTerminate: был переопределен. Этот метод теперь возвращает перечислимый тип, а не BOOL. Возможные значения: NSTerminateNow, чтобы позволить завершению продолжаться, NSTerminateCancel для отмены завершения или NSTerminateLater для отсрочки решения. Если делегат возвратит NSTerminateLater, то NSApplication введет модальный цикл, ожидающий вызова к-replyToApplicationShouldTerminate. Делегат должен вызвать-replyToApplicationShouldTerminate с YES или НЕ как только решено, может ли завершиться приложение. NSApplication выполнит runloop в NSModalPanelRunLoopMode при ожидании делегата для совершения этого вызова.

К сожалению, эта реализация не позволяет - [Оконечный NSApplication:], чтобы быть вызванным от вторичного потока. Если Ваше приложение сделает это, то Вы заставите консольное сообщение об ошибке и вызов завершаться: не будет иметь никакого эффекта. Вы можете обходное решение это ограничение путем обмена сообщениями основного потока приложения для выполнения вызова к terminate:.

Для совместимости на уровне двоичных кодов возвращаемое значение НЕ распознано как NSTerminateCancel и возвращаемое значение YES как NSTerminateNow.
// return values for -applicationShouldTerminate:
enum {
NSTerminateNow,
NSTerminateCancel,
NSTerminateLater
} NSApplicationTerminateReply;
@interface NSObject(NSApplicationDelegate)
(NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender;
...
@end
- (void)replyToApplicationShouldTerminate:(BOOL)shouldTerminate;
скройтесь: и выведите на экран: теперь реализованы для приложений UIElement. Если приложение UIElement вызывает - [NSApp скрываются:], его окна будут скрыты, и следующее приложение в строке будет активировано. Из-за функции строки меню, где это не показывает приложение UIElement как активное приложение, это позволяет желаемое поведение, где приложение, выглядящее активным в строке меню фактически, становится активным приложением после того, как скрывается приложение UIElement. - [NSApp выводят на экран:] активирует и покажет окна приложения UIElement.


Текстовое перетаскивание

NSTextView теперь поддерживает перетаскивание текста. Текстовый выбор будет перетащен, только если пользователь щелкает и держится он на определенный период времени.

Существует два новых метода NSTextView для поддержки перетаскивания текста. Это прежде всего для подклассификаторов.

Следующий метод заставляет textview начинать перетаскивать текущий выбранный диапазон, возвращая YES, если это преуспевает в том, чтобы инициировать перетаскивание:
- (BOOL)dragSelectionWithEvent:(NSEvent *)event offset:(NSSize)mouseOffset slideBack:(BOOL)slideBack;
Следующее используется dragSelectionWithEvent:offset:slideBack: получить надлежащее изображение. Возвращается нижняя левая точка изображения в поле зрения координирует как источник. Может быть вызван другими, которые нуждаются в таком изображении или могут быть переопределены подклассификаторами для возврата различного изображения (если оно возвратит ноль, то значок по умолчанию будет использоваться):
- (NSImage *)dragImageForSelectionWithEvent:(NSEvent *)event origin:(NSPointPointer)origin;
Чтобы позволить делегатам лучше управляют по перетаскиванию или вырезают и вставляют присоединений, два новых метода делегата были добавлены. Как альтернатива существующему:
- (void)textView:(NSTextView *)view draggedCell:(id <NSTextAttachmentCell>)cell inRect:(NSRect)rect event:(NSEvent *)event atIndex:(unsigned)charIndex;
мы теперь имеем:
- (NSArray *)textView:(NSTextView *)view writablePasteboardTypesForCell:(id <NSTextAttachmentCell>)cell atIndex:(unsigned)charIndex;
Если существующий метод не используется, этот метод и следующее позволяют textview заботиться о присоединяемом перетаскивании и вставке с делегатом, ответственным только за запись присоединения к области монтажа. В этом методе делегат должен возвратить массив типов, которые он может записать в область монтажа для данного присоединения. Следующий метод позволяет делегату писать данное присоединение в область монтажа с данным типом и возвращать успешность или неуспешность:
- (BOOL)textView:(NSTextView *)view writeCell:(id <NSTextAttachmentCell>)cell atIndex:(unsigned)charIndex toPasteboard:(NSPasteboard *)pboard type:(NSString *)type ;

NSLayoutManager

Следующие два метода были добавлены к NSLayoutManager:
- (void)setDefaultAttachmentScaling:(NSImageScaling)scaling;
- (NSImageScaling)defaultAttachmentScaling;
Они используются, чтобы указать, что поведение по умолчанию желало, если присоединяемое изображение является слишком большим для помещений в текстовый контейнер. Обратите внимание на то, что присоединяемые ячейки управляют своим собственным размером и получением, таким образом, эта установка может только быть консультацией для них, но предоставленные набор присоединяемые ячейки будут уважать его. Если значение не будет установлено, то NSScaleNone будет использоваться.


NSWorkspace

Большая часть функциональности NSWorkspace была теперь повторно включена. Однако определенные зависимые от операционной системы части функциональности NSWorkspace не релевантны или не в настоящее время реализовываемые на Mac OS X. Например, checkForRemovableMedia и noteUserDefaultsChanged не имеют никакого эффекта, и fileSystemChanged и userDefaultsChanged неинформативны; mountNewRemovableMedia эквивалентен mountedRemovableMedia. Кроме того, extendPowerOffBy: в настоящее время не реализуется, и NSWorkspaceWillPowerOffNotification в настоящее время недоступен. Операции NSWorkspaceCompressOperation файла, NSWorkspaceDecompressOperation, NSWorkspaceEncryptOperation и NSWorkspaceDecryptOperation также в настоящее время недоступны.

Были добавлены три новых метода:
- (BOOL)openURL:(NSURL *)url;
Если NSWorkspace не может найти такие средние значения, это будет использовать системно-зависимые средние значения отображения данного URL пользователю или возвращаться НЕ.
- (BOOL)isFilePackageAtPath:(NSString *)fullPath;
Это определит, является ли данный каталог фактически пакетом файла. Это также возвратится НЕ, если данный путь не будет существовать или будет указывать на что-то, что не является каталогом.
- (NSArray *)mountedLocalVolumePaths
Это возвращает массив, содержащий точки монтирования всех локальных томов, не только съемные, возвращенные mountedRemovableMedia.


NSDrawer

Закрытая секция, если сказали для открытия без определенного указываемого края, теперь попытается выбрать край, на котором можно открыться на основе пространства, доступного для отображения секции на экране. Если необходимо гарантировать, что секция открывается на определенном краю, используйте openOnEdge:.


AppleLanguages

Предпочтительный порядок пользователя на локализации сохранен в пользовательском значении по умолчанию AppleLanguages. Значение для этого должно быть массивом строк. В прошлом строки в этом массиве обычно были именами языка («английский», «французский язык», и т.д.). Однако предпочтительные формы для строк в этом массиве и формы, в которых они, вероятно, появятся в будущем, любой как сокращения языка («en», «франк», и т.д.) или как сокращения локали («en_US», «fr_CA», и т.д.). Любой использующий значение этого значения по умолчанию непосредственно должен быть подготовлен принять любую из этих форм. Прямому использованию значения по умолчанию обескураживают; в большинстве случаев NSBundle или APIs CFBundle должны быть достаточными. Дополнительную информацию см. в документации CFBundle относительно языков, локалей и локализаций.


Службы

Службы будут теперь распознаны за приложения в подкаталогах обычных каталогов приложений, до 5 уровней глубоко. Существует теперь значение по умолчанию, NSServicesFromNetworkApplications, управляющий, будут ли службы распознаны за приложения в каталоге сетевых приложений и его подкаталогах; значение по умолчанию НЕТ. Необходимо установить это значение по умолчанию в NSGlobalDomain и выйти из системы, и журнал въезжают задним ходом для него для вступления в силу.

Записи сервисного меню и эквиваленты командной клавиши могут быть локализованы двумя дополнительными способами. Путь, описанный в документации Служб, состоит в том, чтобы сделать имена языка, вводит записи NSMenuItem и NSKeyEquivalent в части NSServices Info.plist. Это имеет недостаток размещения локализованной информации за пределами .lproj каталогов. Для предотвращения этого недостатка первая альтернатива должна поместить локализованные значения вместо этого в файл ServicesMenu.strings в надлежащих .lproj каталогах. Ключи должны быть точно значением записей «по умолчанию» для NSMenuItem и NSKeyEquivalent, и значения должны быть локализованными эквивалентами. Это - механизм, используемый предоставленными Apple приложениями, такими как TextEdit, который может быть взят в качестве примера этого метода. Вторая альтернатива должна скопировать часть NSServices Info.plist в InfoPlist.strings. Это менее удобно для локализации, но более гибко, потому что она позволяет любой части NSServices быть измененной для локализации.


NSColor, NSColorList

Цветная панель теперь выведет на экран локализованное имя списка цветов и списка цветов, если Вы будете доступны. В частности цвета каталога возвращают свои локализованные имена через эти два метода:
- (NSString *)localizedCatalogNameComponent;
- (NSString *)localizedColorNameComponent;
Локализованные имена для цветов и списка сохранены в строковом ресурсе файла locaized. Например, предположите, что тот хотел локализовать/System/Library/Colors/System.clr/французскому языку. Для этого строковый файл: French.lproj/System.strings должен был бы быть добавлен к каталогу System.clr/. Строковый файл содержал бы запись для каждого цветного имени и для самого имени списка цветов.

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


NSTableView

Движение, используемое для запуска перетаскивания с табличного представления, может теперь быть сконфигурировано. По умолчанию новое табличное представление начнется, перетаскивает, когда встречаются с или горизонтальным или вертикальным движением мыши. Можно управлять, обрабатывается ли вертикальное движение как изменение перетаскивания или выбора путем вызова setVerticalMotionCanBeginDrag. Значение НИКАКИХ средних значений, что вертикальное движение не запустит перетаскивание.

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

Наконец, значение по умолчанию обработки вертикального движения как перетаскивание является изменением в поведении, которое будет применено к новым табличным представлениям только. Таким образом, значением по умолчанию для verticalMotionCanBeginDrag является YES для новых табличных представлений, и НЕ для существующих.
- (void)setVerticalMotionCanBeginDrag:(BOOL)flag;
- (BOOL)verticalMotionCanBeginDrag;
validateDrop методы в NSTableView и NSOutlineView были обновлены, чтобы использовать новый тип NSDragOperation для перетаскивания, и теперь появиться как:
- (NSDragOperation)tableView:(NSTableView *)tv validateDrop:(id <NSDraggingInfo>)info proposedRow:(int)row proposedDropOperation:(NSTableViewDropOperation)op;
- (NSDragOperation)outlineView:(NSOutlineView *)olv validateDrop:(id <NSDraggingInfo>)info proposedItem:(id)item proposedChildIndex:(int)index;

NSOutlineView

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


NSBrowserCell

Выбранные ячейки в последнем столбце браузера рисуют с немного более темным цветом, чем остальная часть столбцов браузеров. Так как это может быть проблематично для ячеек для знания то, что окрашивает, их выделение должно быть, новый метод был, представляют в NSBrowserCell, чтобы помочь определить цвет подсветки, который должен использоваться. controlView параметр метода обычно будет переданным параметром того же имени от методов как drawInteriorWithFrame:inView:
- (NSColor *)highlightColorInView:(NSView *)controlView;

NSOpenGLView

Можно теперь установить NSOpenGLContext, используемый представлением, чтобы позволить совместно использовать тот же контекст на на основание представления. Это заменит существующий контекст, если Вы уже будете созданы представлением. Обратите внимание на то, что этот метод не вызывает - [NSOpenGLContext setView:]. Необходимо будет вызвать тот метод явно для синхронизирования контекста и представления.
- (void)setOpenGLContext:(NSOpenGLContext*)context;
Существует два новых метода, которые можно переопределить:
- (void)reshape;
- (void)update;
. Когда видимый прямоугольник или границы изменения представления Вы будете уведомлены через изменять метод, (для прокрутки или изменяют размеры), реализация по умолчанию ничего не делает. Можно использовать для этого, корректируют область просмотра и выводят на экран frustrum.

Если контекст должен быть обновлен, потому что окно перемещается, перемещения представления или изменено, метод обновления вызывают. Это просто вызывает - [Обновление NSOpenGLContext] метод (см. ниже), Вы не должны должны быть переопределять его, если Вы не должны добавлять блокировки для многопоточного доступа к контексту. При переопределении его вызовите вышестоящий метод.


NSOpenGLContext

Когда NSOpenGLView изменяет свое местоположение или размер перед вызовом к - [NSOpenGLView изменяются] существует вызов к новому методу в NSOpenGLContext:

- (недействительное) обновление;

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


Соединение NSOpenGL

AppKit теперь динамично соединяется в OpenGL в первый раз, когда это необходимо. Если Ваш проект предположил, что это было доступно неявно, необходимо будет теперь импортировать OpenGL.framework явно.


Маленькие средства управления

Для средств управления, которые не могут быть изменены в одном направлении, мы теперь обеспечиваем маленький вариант управления, который можно использовать для инспекторов и палитр. Этот вариант применяется к кнопкам, переключателям, флажкам, ползункам, полосам прокрутки, кнопкам всплывающего меню, вкладкам и индикаторам хода выполнения. Необходимо использовать маленький системный шрифт при установке его для использования маленького управления. Допустимые значения NSControlSize определяются в NSCell.h:
typedef enum _NSControlSize {
NSRegularControlSize,
NSSmallControlSize
} NSControlSize;
NSCell классов, NSTabView, NSScroller и NSProgressIndicator определяют общий метод, который можно использовать, чтобы установить и получить размер элемента управления. Эта установка архивируется.
- (void)setControlSize:(NSControlSize)size;
- (NSControlSize)controlSize;

NSScroller

NSScroller теперь содержит метод класса, возвращающий ширину скроллера для размера элемента управления. - [NSScroller scrollerWidth] продолжает возвращать ширину для нормальной размерной полосы прокрутки.
+ (float)scrollerWidthForControlSize:(NSControlSize)controlSize;

NSProgressIndicator

NSProgressIndicator теперь содержит методы, чтобы установить и получить оттенок управления. Это ведет себя то же как в NSCell и т.д.
- (NSControlTint)controlTint;
- (void)setControlTint:(NSControlTint)tint;

NSScrollView

- [NSScrollView setDrawsBackground:] теперь автоматически отключает копию на прокрутке (setCopiesOnScroll:NO) без параметра.


NSImage

Для совместимости с более старыми приложениями, существующие методы рисования NSImage, такие как compositeToPoint: alway рисуют с только источником преобразованного изображения. Само изображение нарисовано, игнорируя масштаб, и вращение преобразовывает с источником в нижнем левом. В то время как было возможно нарисовать с текущим преобразованием путем получения одного из представления изображения и вызова его метода получения, два новых метода были добавлены к NSImage, делающим это для Вас.
- (void)drawAtPoint:(NSPoint)point fromRect:(NSRect)fromRect operation:(NSCompositingOperation)op fraction:(float)delta;
- (void)drawInRect:(NSRect)rect fromRect:(NSRect)fromRect operation:(NSCompositingOperation)op fraction:(float)delta;
Если Вы передаете в NSZeroRect для fromRect: параметр, тогда целое изображение используется. Для drawInRect: изображение будет масштабироваться для помещений в целевой прямоугольник, а также преобразовываться с текущим преобразованием контекста. Обратите внимание на то, что при использовании этих подпрограмм в зеркально отраженном представлении необходимо будет 'отменить' отрицательный y масштабный коэффициент и скорректировать источник.

Одно изменение в NSImage начиная с Сервера Mac OS X - то, что NSImage теперь избегает кэшировать битовые массивы в окнах каждый раз, когда это может. С точки зрения API это главным образом очевидно для разработчиков; NSImage просто составляет исходное растровое изображение вместо кэшированной версии и избегает создавать относительно дорогие кэши сервера окна. Однако это могло изменить объем памяти Ваше использование приложения. Например, изображение на 300 точек на дюйм закончит тем, что брало намного больше памяти, чем кэшированная версия на 72 точки на дюйм. Это - особенно истина при калибровке изображения, чтобы быть меньшими; если исходное растровое изображение будет все еще вокруг, то оно будет представлять намного больше памяти. Или, изображение, которое сложно для рендеринга (говорят один с профилем ICC) могло закончить тем, что было медленнее, чтобы перерисовать если beng, живо измененный или прокрученный.

Чтобы заставить NSImage кэшировать битовый массив в окне, просто отправьте lockFocus/unlockFocus в него. Если исходные данные прибудут из файла при большинстве обстоятельств, то более высокая версия разрешения будет автоматически использоваться при изменении размеров или печати изображения.


NSMovieView

NSMovieView теперь работает снова. API почти абсолютно неизменен за исключением следующего: во-первых, подпрограммы для загрузки изображений через URLs или пути к файлам были перемещены в NSMovie. В его месте можно установить и получить NSMovie, связанный с представлением. Этот NSMovie архивируется с представлением. Обратите внимание на то, что как OpenGL, QuickTime динамично загружается в первый раз, когда представление должно вывести на экран фильм. При доверии вызовам QuickTime, прежде чем фильм был выведен на экран, необходимо будет явно соединиться в QuickTime и вызвать EnterMovies перед использованием любых вызовов функции QuickTime.
- (void)setMovie:(NSMovie *)movie;
- (NSMovie *)movie;
Можно теперь получить ссылку на фактический контроллер фильма. Используйте это для активации опций, которые не являются частью основного NSMovieView API.
- (void*)movieController;
Это - точка переопределения это возвратами по умолчанию [сам границы]. Можно возвратить меньший прямоугольник для размещения фильма и его контроллера в части представления.
- (NSRect)movieRect;

NSMovie

NSMovie является простой оберткой вокруг ссылки фильма в формате QuickTime. Когда экземпляр NSMovie освобожден, DisposeMovie вызывают. Можно создать собственный Фильм или загрузить фильм через URL (в настоящее время, только файл базировался, фильмы поддерживаются), или через область монтажа. Если Вы передаете в YES для initWithURL:byReference: тогда URL архивируется. Иначе, ссылка Фильма архивируется (не включение фактических данных носителей).
- (id)initWithMovie:(void *)movie;
- (id)initWithURL:(NSURL *)url byReference:(BOOL)byRef;
- (id)initWithPasteboard:(NSPasteboard *)pasteboard;
Это получит ссылку на фильм в формате QuickTime. Не избавляйтесь от него непосредственно.
- (void *)QTMovie;
Если NSMovie создавался с URL, это возвратит его.
- (NSURL *)URL;
Они возвращают информацию о типах файла ролика и типах области монтажа и содержит ли область монтажа фильм. Расширение типа файла по умолчанию является '.mov'
+ (NSArray *)movieUnfilteredFileTypes;
+ (NSArray *)movieUnfilteredPasteboardTypes;
+ (BOOL)canInitWithPasteboard:(NSPasteboard *)pasteboard;

NSBitmapImageRep

NSBitmapImageRep теперь использует, любой связал данные ColorSync (иначе профили ICC) при рендеринге. Это также считает и запишет данные для JPEG и PNG, а также TIFF. Можно установить и получить данные через свойство NSImageColorSyncProfileData.

Тарга и Макпэйнт, импортирующий через NSData, временно недоступны. Импорт через Средства импорта Графики QuickTime все еще работает на другие перечисленные типы.


NSButtonCell

Существует два новых типа внешней панели кнопки, определенной в NSButtonCell.h:
NSShadowlessSquareBezelStyle = 6
'Квадратная внешняя панель без тени' s подобный NSRegularSquareBezelStyle, но не имеет никакой тени, таким образом, можно примкнуть к ячейкам, не имея перекрывающихся теней. Они могли бы использоваться для палитры инструментов.
NSCircularBezelStyle = 7
Это - круглая кнопка с комнатой для маленького значка или отдельного символа. Это имеет регулярные и маленькие варианты. Обратите внимание на то, что большой вариант только входит серый в это время.


NSGraphicsContext

Существуют новые методы, чтобы получить и установить сглаживание и интерполяцию (сглаживание изображения) атрибуты в контексте. Обратите внимание на то, что эти значения не являются частью состояние графики и таким образом, Вы не можете использовать restoreGraphicsState для сброса состояния после установки. NSImageInterpolationDefault зависит от типа контекста.
typedef enum NSImageInterpolation {
NSImageInterpolationDefault,
NSImageInterpolationNone,
NSImageInterpolationLow,
NSImageInterpolationHigh
} NSImageInterpolation;
- (void)setShouldAntialias:(BOOL)antialias;
- (BOOL)shouldAntialias;
- (void)setImageInterpolation:(NSImageInterpolation)interpolation;
- (NSImageInterpolation)imageInterpolation;

NSGraphics

Новая прямоугольная функция кадра была добавлена, который позволяет Вам указать составляющую композит работу, а также ширину. Это ведет себя точно так же, как NSFrameRectWithWidth, но не ограничивается использовать NSCompositeCopy.
void NSFrameRectWithWidthUsingOperation(NSRect rect, float width, NSCompositingOperation op);

NSSavePanel, NSOpenPanel

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

NSSavePanel теперь обеспечивает метод делегата, дающий делегату возможность проверить имя файла, вводимое пользователем:
- (NSString *)panel:(id)sender userEnteredFilename:(NSString *)filename confirmed:(BOOL)okFlag;
Когда пользователь подтверждает их выбор имени файла путем удара OK или <Возврата>, этот метод вызывают с их именем файла. Делегат может или оставить имя файла в покое, или возвратить новое имя файла или возвратить ноль для отмены сохранения (и оставить панель сохранения, как, подобен panel:isValidFilename:).

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

Обратите внимание на то, что в будущем этот метод можно вызвать многократно во время сеанса, поскольку пользователь вводит. В тех случаях okFlag будет НЕ, пока пользователь фактически не подтвердит их выбор, когда okFlag будет YES. Если делегат делает дорогую проверку или поднимает предупреждения, она должна сделать так только в этом последнем случае.


Псевдонимы

В отличие от символьных ссылок, псевдонимы Mac OS в настоящее время не обрабатываются автоматически AppKit или базовыми библиотеками Foundation и POSIX. Это может означать, что файлы, возвращенные NSOpenPanel, могут указать на псевдонимы и должны будут быть разрешены для нахождения исходного элемента. Вот функция, которую можно использовать для проверки пути, у Вас есть точки к реальному файлу и не псевдониму. Функция возвращает исходную строку, если это не указывало на псевдоним. Это означает идти от пути до URL к FSRef, разрешению и возвращению снова.
#import <Carbon/Aliases.h>
NSString* ResolveAliasPath(NSString* path)
{
CFStringRef resolvedPath = nil;
CFURLRef url = CFURLCreateWithFileSystemPath(NULL /*allocator*/, (CFStringRef)path, kCFURLPOSIXPathStyle, NO /*isDirectory*/);
if (url != NULL) {
FSRef fsRef;
if (CFURLGetFSRef(url, &fsRef)) {
Boolean targetIsFolder, wasAliased;
if (FSResolveAliasFile (&fsRef, true /*resolveAliasChains*/, &targetIsFolder, &wasAliased) == noErr && wasAliased) {
CFURLRef resolvedurl = CFURLCreateFromFSRef(NULL /*allocator*/, &fsRef);
if (resolvedurl != NULL) {
resolvedPath = CFURLCopyFileSystemPath(resolvedurl, kCFURLPOSIXPathStyle);
CFRelease(resolvedurl);
}
}
}
CFRelease(url);
}
return resolvedPath != nil ? [(NSString*)resolvedPath autorelease] : path;
}
Обратите внимание на то, что одно место, где псевдонимы автоматически разрешены, - когда по документам дважды щелкают в Средстве поиска или перетаскивают к Вашему значку приложения.


Подменю Find

«Входят, Выбор» элемент в стандартном подменю «Find» был изменен для «Использования Выбора для Находки». Новый шаблон приложений был обновлен, но существующие приложения должны также изменить это явно.


Подчеркивание по сравнению с возвращается к сохраненному

Инструкции по Интерфейсу воды утверждают, что cmd-u ярлык должен использоваться для «Подчеркивания», а не «Возвращаются к Сохраненному». Мы изменили шаблон меню для новых приложений; однако, существующие приложения должны сделать это изменение вручную. Больше нет рекомендуемого ярлыка для, «Возвращаются к Сохраненному».


NSMenu

NSMenu теперь использует менеджера по Меню Углерода по ключевой эквивалентной обработке для достижения полной совместимости в поведении командной клавиши с Углеродом. В частности класс теперь использует IsMenuKeyEvent () функция для определения NSMenuItem, который событие, как предполагается, активирует.


NSBezierPath

Все операции защищены gsave/grestore, таким образом, приложения не должны заботиться об установке графики (предельный угол стыка, ширина строки, и т.д.).


Файлы TIFF с альфой (прозрачность)

При загрузке файлов TIFF в приложения Какао Вы могли бы иногда видеть соблюдающее предупреждение в консоли: «Предупреждение: изображение TIFF с неизвестными дополнительными выборками, которые, как предполагают, имели несвязанную альфу. Значения RGB были предварительно умножены».

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

Некоторые приложения краски не делают умножения в обратном порядке, и кроме того, они не совсем ясны в утверждении, что они делают относительно альфы. В тех случаях Вы получите вышеупомянутое предупреждение.

Можно фиксировать такие файлы путем загрузки и сохранения их один раз в приложении Какао. «Tiffutil» утилита командной строки может использоваться, чтобы сделать это. В Окне терминала можно сделать:
tiffutil -cat orig.tiff -out new.tiff
Это считает orig.tiff и выпишет его как new.tiff. При выполнении tiffutil без каких-либо параметров он скажет Вам другие параметры, которые он принимает.


Файлы RTF

Мы теперь обрабатываем следующие новые ключи в documentAttributes словаре при чтении/записи файлов RTF:

«ViewSize»: размер Представления для документа, NSValue, содержащий NSSize
«ViewZoom»: значение Изменения масштаба, NSValue, содержащий плавание; 100 == 100%-е изменение масштаба
«ViewMode»: режим Представления документа, NSValue, содержащий интервал; 0 = ни один (обычно обертка к окну или контейнерный режим); 1 = макет страницы (используют значение «PaperSize»),

TextEdit раньше хранил размер представления в «PaperSize». Это больше не делает это, однако, это попытается правильно поднять размер представления из более старых документов, сделавших это.

Поскольку поддержка RTF не делает должным образом таблиц описателей, скопировать/вставить таблиц из приложений, таких как Excel мог бы не вывести на экран таблицу должным образом в документе обогащенного текста (включая богатый, составляют окна в Почте.) В тех случаях одно простое обходное решение должно вставить в документ простого текста, заставляющий альтернативу простого текста для данных использоваться. Тогда таблица простого текста может быть, копируют/вставляют в документ обогащенного текста.


NSTextStorage

Новый атрибут, NSCharacterShapeAttributeName, теперь поддерживается текстовой системой. Атрибут управляет изменением формы глифа, поддерживаемым японскими шрифтами Хирагино. Значение является целочисленным соответствием значению селектора функции Apple Type Services kCharacterShapeType. Значение 0 интерпретируется для отключения опции, и другое значение является соответствующим селекторным значением плюс 1. См. SFNTLayoutTypes.h в ATS.framework.


NSTextView

Новый метод,-toggleTraditionalCharacterShape: добавляется к NSTextView. Этот метод переключает атрибут NSCharacterShapeAttributeName по текущему выбору. Это добавляет/удаляет NSCharacterShapeAttributeName с целочисленным значением 1 (kTraditionalCharactersSelector + 1).


NSSound

Существует новый init метод для экземпляров NSSound,-initWithData: который берет NSData, содержащий звуковые данные. Магическое число (ла) в звуковом заголовке в данных используется для определения формата выборок.


Info.plist

См. информация о версии Info.plist для изменений, имеющих отношение к пути пакет и информация о типе документа, объявляется в приложениях.



Отмечает определенный для Беты Общественности Mac OS X

Графит

Этот выпуск представляет «Графитовый» цветной вариант для Воды. Этот вариант является выбираемым пользователем через Предпочтительное приложение; однако, это не можно выбрать программно на основе на управление. Это означает, что нет никакого явного значения NSControlTint для Графита; вместо этого, соответствие оттенка изменениям NSDefaultControlTint.

Когда пользователь изменяет эти настройки, приложения сразу уведомляются; все стандартные средства управления реагируют на это путем восстановления изображения себя. Приложения могут зарегистрироваться для NSControlTintDidChangeNotification, чтобы сделать дальнейшую очистку; это полезно, если они имеют пользовательские элементы управления или имеют кэши изображений, которые, возможно, должны были бы быть воссозданы, например. Приложения могут узнать значение цвета текущей установки оттенка по умолчанию путем вызова [NSColor colorForControlTint:NSDefaultControlTint].


NSBezierPath

В бета-версии NSBezierPath добавил следующие методы:
- (float)miterLimit;
- (void)setMiterLimit:(float)miterLimit;
- (float)flatness;
- (void)setFlatness:(float)flatness;
- (void)getLineDash:(float *)pattern count:(int *)count phase:(float *)phase;
- (void)setLineDash:(const float *)pattern count:(int)count phase:(float)phase;
Они позволяют Вам устанавливать и получать предельный угол стыка, плоскость или пунктирный узор строки на определенном пути.


NSOpenPanel / NSSavePanel

Семантика setPrompt: метод в открытом и сохраняет панели, изменился. С Водой UI «подсказка» перед текстовым полем всегда устанавливается «Перейти в»: и не может быть изменен. Метод setPrompt: был отключен в предыдущих выпусках Воды. Это было теперь перенастроено для влияния на кнопку по умолчанию (который не мог раньше быть установлен через API). Текст по умолчанию на кнопке по умолчанию теперь «Открыт» для открытой панели, и «Сохраните» для панели сохранения, но может быть изменен программно. Так как этот API раньше влиял на текстовое поле, любое двоеточие на конце строки удалено прежде чем быть используемым на кнопке.

setTitle: методы в открытом и сохраняют панели, были повторно включены также и влияют на текст заголовка панелей.

Это предназначается, что программисты будут использовать короткие слова или фразы, такой как «Открытые», «Сохранять», «Набор», или «Выбирать» на кнопке. В это время кнопка не изменена для адаптации тексту, когда установлено; это - ошибка, которая должна скоро адресоваться.


Каталоги шрифта

Новая реализация была добавлена для возвращения понятия различных каталогов шрифта для Пользователя, Системы и Сети. Когда пользователь входит в систему, эта функциональность обычно обрабатывается автоматически путем выполнения «fcache» от процесса «PBS». Во время начальной загрузки системы «fcache» программа выполняется для каталогов Системного и Локального шрифта. Когда пользователь входит в систему, это выполняется для корневого каталога пользователя. Программа может также быть выполнена вручную в определенных доменах, и для простоты нового набора параметров командной строки предоставлены: - система, - пользователь, - локальный, и - сеть.


Печать

Заключительный выпуск Mac OS X будет включать существенные изменения в связанные с печатью классы; некоторые из этих изменений обрисованы в общих чертах ниже.

NSPageLayout:

NSPageLayouts будет визуализуемым как модальные документом листы. Новые методы добавляются для создания этого возможным.

NSPageLayout больше не будет подклассом NSPanel. Это будет прямой подкласс NSObject. Не будет возможно отправить - [NSView viewWithTag:] к NSPageLayout.

Осуждаются некоторые методы:

- convertOldFactor:newFactor:will всегда набор оба из его параметров тому же значению.
- pickedButton:will никогда не быть отправленным из AppKit.
- pickedOrientation:will никогда не быть отправленным из AppKit.
- pickedPaperSize:will никогда не быть отправленным из AppKit.
- pickedUnits:will никогда не быть отправленным из AppKit.

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

NSPrintOperation:

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

Значения некоторых методов переоцениваются:

+currentOperation и +setCurrentOperation: подразумевайте, что существует один и только один текущий NSPrintOperation. В будущем будет больше чем один текущий NSPrintOperation.

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

NSPrinter:

Цель класса NSPrinter и каждый из его методов переоцениваются.

NSPrintInfo:

Осуждаются некоторые настройки атрибута, которые были сохранены как записи в словаре assocated с NSPrintInfo. Такие записи будут проигнорированы - [NSPrintInfo initWithDictionary:], и не будет присутствовать ни в каком словаре, возвращенном - [Словарь NSPrintInfo]. Они:

NSPrintFaxCoverSheetName
NSPrintFaxModem
NSPrintFaxHighResolution
NSPrintFaxReceiverNames
NSPrintFaxReceiverNumbers
NSPrintFaxReturnReceipt
NSPrintFaxSendTime
NSPrintFaxTrimPageEnds
NSPrintFaxUseCoverSheet

Расположение задания осуждается:

- setJobDisposition:will treatNSPrintFaxJobas, если это был синонимичный withNSPrintSpoolJob.
- jobDispositionwill никогда returnNSPrintFaxJob.

Метод может быть осужден. Раз так:

+sizeForPaperName:will всегда returnNSZeroSize, независимо от бумажного имени.

Значения некоторых настроек атрибута переоцениваются. Они:

NSPrintFormName
NSPrintJobFeatures
NSPrintPaperFeed
NSPrintPrinter

NSPrintPanel:

NSPrintPanels будет визуализуемым как модальные документом листы. Новые методы добавляются для создания этого возможным.

NSPrintPanel больше не будет подклассом NSPanel. Это будет прямой подкласс NSObject.

Осуждаются некоторые методы:

- pickedAllPages:will никогда не быть отправленным из AppKit.
- pickedButton:will никогда не быть отправленным из AppKit.
- pickedLayoutList:will никогда не быть отправленным из AppKit.

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

NSDocument:

NSPageLayouts будет визуализуемым NSDocuments как модальные документом листы. Новые методы добавляются, и значения измененных других, для создания этого простым.

NSWindow:

Поведение - метод печати может измениться чтобы на панели как модальные документом листы.


NSWindow

Сокрытие приложения теперь выпускает запоминающее устройство для любых oneShot окон. Минимизация oneShot окна также выпускает запоминающее устройство. Любые представления, делающие пользовательское получение (за пределами стандартного механизма дисплея), который может попытаться нарисовать, в то время как приложение скрыто или окно, минимизируются, должен использовать - [NSView lockFocusIfCanDraw], а не - [NSView lockFocus].

Существует пользовательское значение по умолчанию, AppleDockIconEnabled, чтобы позволить установить изображение в минимизируемой мозаике окна с - [NSWindow setMiniwindowImage:]. Изображение будет масштабироваться по мере необходимости для адаптации мозаике. Это поведение прочь по умолчанию, таким образом, необходимо установить AppleDockIconEnabled в YES, если Вы хотите включить это поведение. Наше намерение состоит в том, чтобы включить это поведение в следующем выпуске; однако, в большинстве случаев приложения не могли бы хотеть устанавливать значок миниокна явно.

Единственный режим окна был отключен в общедоступной Бете.


NSApplication

Изображение в мозаике приложения прикрепления может быть установлено с - [NSApplication setApplicationIconImage:]. Изображение будет масштабироваться по мере необходимости для адаптации мозаике.

Можно вызвать-postEvent:atStart: и-discardEventsMatchingMask:beforeEvent: методы от подпотоков. События, отправленные в пузыре подпотоков в основной очереди событий потока.


NSWorkspace

Значки, возвращенные методами NSWorkspace теперь, включают представления миниатюры (128x128) при наличии. Они также создаются как изображения размера 32x32, а не изображения неопределенного размера. Ранее их фактические выведенные на экран размеры оставили зависеть от доступных представлений.


Документ модальный API

Документ модальный API, представленный в DP4, теперь реализован в NSDocument, NSDocumentController и NSOpenPanel. Документ DP3 модальный API осуждается и вызывает к этим устаревшим методам, приведет к предупреждениям консоли. Мы выключили эти предупреждения для приложений, найденных в соответствии с Приложениями / или/Developer/Applications. Мы призываем разработчиков тестировать свои приложения на эти предупреждения прежде, чем установить их приложение в Приложениях / или/Developer/Applications.

Каждый метод берет modalDelegate, обратный вызов и дополнительный contextInfo параметр. Когда модальный документом сеанс заканчивается, modalDelegate вызывается с методом обратного вызова, получающим объект sheetWindow, результат выполнения листа - или булевская переменная или код возврата и contextInfo параметр. contextInfo является способом для Вас передать информацию от запуска модального сеанса до конца и может быть простым значением, структурой или объектом.

Обратный вызов вызывается прежде, чем отклонить лист, чтобы дать Вам возможность отклонить лист и родительское окно документа одновременно. Например, Вы могли бы хотеть сделать это, когда отклонение «делает Вы хотите сохранить» предупреждение прежде, чем закрыть окно. Если пользователь выбирает «do not save», Вы хотите закрыть и окно документа и лист без эффекта листа. Это может быть выполнено путем вызова [docWindow близко] от обратного вызова. Можно также отклонить просто лист в этом методе путем вызова [sheetWindow orderOut:]. Если Вы не отклоните лист, то он будет сделан для Вас по возврату из Вашего обратного вызова, но можно быть в ситуации, где Вы хотите сразу представить другой лист, и это, вероятно, лучше всего сделано от Вашего обратного вызова после dimissing первый.

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

NSDocument:
- (IBAction)saveDocument:(id)sender
- (IBAction)saveDocumentAs:(id)sender
- (IBAction)saveDocumentTo:(id)sender
Эти методы теперь вызывают новый документ модальный API ниже.

saveDocument: вызовы-saveDocumentWithDelegate:didSaveSelector:contextInfo:.
saveDocumentAs: и saveDocumentTo: вызовите-saveToFile:saveOperation:delegate:didSaveSelector:contextInfo:.

Это означает, что эти вызовы являются теперь асинхронными - они могут возвратиться, прежде чем работа сохранения завершилась (и лист сохранения может все еще присутствовать на документе).
- (void)shouldCloseWindowController:(NSWindowController *)windowController delegate:(id)delegate shouldCloseSelector:(SEL)callback contextInfo:(void *)contextInfo
Этот метод заменяет shouldCloseWindowController:. Этот метод вызовет обратный вызов с результатом canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:. Если закрывающийся контроллер окна последним или отмечен как порождение документа завершению, является иначе это вызывает обратный вызов с YES. Это вызывает автоматически NSWindow для любого окна, имеющего контроллер окна и документ, связанный с ним. NSWindow вызывает это до выяснения у его делегата-windowShouldClose:.

shouldCloseSelector должен иметь следующую подпись:
- (void)document:(NSDocument *)document shouldClose:(BOOL)shouldClose contextInfo:(void *)contextInfo
- (void)canCloseDocumentWithDelegate:(id)delegate shouldCloseSelector:(SEL)shouldCloseSelector contextInfo:(void *)contextInfo
Этот метод заменяет canCloseDocument. Если документ не будет грязен, то этот метод сразу вызовет обратный вызов с YES. Если документ будет грязен, то предупреждение будет представлено, давая пользователю шанс сохранить, не сохранить или отмена. Если пользователь примет решение сохранить, то этот метод сохранит документ. Если сохранение завершится успешно, то этот метод вызовет обратный вызов с YES. Если сохранение будет отменено или иначе неуспешное, то этот метод вызовет обратный вызов без. Этот метод вызывает shouldCloseWindowController: иногда. Это также вызывает-closeAllDocuments NSDocumentController. Если Вы закрываете документ и хотите дать пользователю случайное сохранение какие-либо редактирования, необходимо вызвать его перед вызовом - близко.

shouldCloseSelector должен иметь следующую подпись:
- (void)document:(NSDocument *)doc shouldClose:(BOOL)shouldClose contextInfo:(void *)contextInfo
- (void)saveDocumentWithDelegate:(id)delegate didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo
Этот метод частично заменяет fileNameFromRunningSavePanelForSaveOperation:. Этот метод выполняет панель сохранения и вызывает saveToFile:saveOperation:delegate:didSaveSelector:contextInfo: с результатом. Это вызывают от-saveDocument: метод действия, и от canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo: если пользователь принимает решение сохранить.

didSaveSelector должен иметь следующую подпись:
- (void)document:(NSDocument *)doc didSave:(BOOL)didSave contextInfo:(void *)contextInfo
- (void)saveToFile:(NSString *)fileName saveOperation:(NSSaveOperationType)saveOperation delegate:(id)delegate didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo
Этот метод частично заменяет fileNameFromRunningSavePanelForSaveOperation:. Этот метод вызывают после того, как пользователю дали возможность выбрать место назначения через модальную панель сохранения, представленную runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:. Если имя файла является ненолем, этот метод пишет документ имени файла, устанавливает расположение файла документа и тип документа (если собственный тип), и очищает отредактированное состояние документа. если документ сохраняется успешно и НЕ иначе, didSaveSelector вызывают с YES.

didSaveSelector должен иметь следующую подпись:
- (void)document:(NSDocument *)doc didSave:(BOOL)didSave contextInfo:(void *)contextInfo
- (void)runModalSavePanelForSaveOperation:(NSSaveOperationType)saveOperation delegate:(id)delegate didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo
Этот метод replacesrunModalSavePanel:withAccessoryView:. Этот метод подготавливает и выполняет модальную панель сохранения. Это вызывается fromsaveDocumentWithDelegate:didSaveSelector:contextInfo: и действие methodssaveDocumentAs: andsaveDocumentTo:. Этот метод будет callprepareSavePanel:to позволять дальнейшую настройку savePanel.

didSaveSelector должен иметь следующую подпись:
- (void)document:(NSDocument *)doc didSave:(BOOL)didSave contextInfo:(void *)contextInfo
- (BOOL)prepareSavePanel:(NSSavePanel *)savePanel
Этот метод вызывается, byrunModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:to делают любую настройку панели сохранения. Это возвращает YES, если успешно подготовлено, и НЕ иначе. Реализация по умолчанию пуста и возвращает YES.

NSDocumentController:
- (void)closeAllDocumentsWithDelegate:(id)delegate didCloseAllSelector:(SEL)didAllCloseSelector contextInfo:(void *)contextInfo
Этот метод replacescloseAllDocuments. Этот метод проходит через все открытые документы и пытается закрыть их один за другим. Каждый NSDocument отправляется-canCloseDocument:didCloseSelector:contextInfowhich, если это грязно, дает ему шанс отказаться закрывать или сохранять себя сначала и может поднять UI, чтобы спросить, сохранить ли или выполнять сохранение.

если все документы закрываются, и НЕ иначе, didCloseAllSelector вызывается с YES. Это должно иметь следующую подпись:
- (void)documentController:(NSDocumentController *)docController didCloseAll:(BOOL)didCloseAll contextInfo:(void *)contextInfo
- (void)reviewUnsavedDocumentsWithAlertTitle:(NSString *)title cancellable:(BOOL)cancellable delegate:(id)delegate didReviewAllSelector:(SEL)didReviewAllSelector contextInfo:(void *)contextInfo
Этот метод заменяет reviewUnsavedDocumentsWithAlertTitle:cancellable:. Это выводит на экран предупредительное выяснение панели пользователи, если они хотят рассмотреть несохраненные документы, выйти независимо от несохраненных документов, или (если флагом является YES), если они хотят отменить нависшую работу сохранения. Этот метод вызывает didReviewAllSelector с YES, если завершенный без сохранения, выбран или при отсутствии грязных документов, и НЕ иначе. Если пользователь выбирает опцию Review Unsaved, closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo: вызывается. Этот метод вызывается, когда пользователи выбирают команду меню Quit и когда производительность компьютера выключается (когда, флаг НЕ).

didReviewAllSelector должен иметь следующую подпись:
- (void)documentController:(NSDocumentController *)docController didReviewAll:(BOOL)didReviewAll contextInfo:(void *)contextInfo
NSOpenPanel:
- (void)beginSheetForDirectory:(NSString *)path file:(NSString *)name types:(NSArray *)fileTypes modalForWindow:(NSWindow *)docWindow modalDelegate:(id)delegate didEndSelector:(SEL)didEndSelector contextInfo:(void *)contextInfo
Этот метод заменяет runModalForDirectory:file:types:relativeToWindow:. Этот метод представляет открытый лист панели на docWindow. Когда модальный сеанс будет закончен, didEndSelector будет вызван.

didEndSelector метод должен иметь следующую подпись:
- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(int)returnCode contextInfo:(void *)contextInfo

Перетаскивание

Перетаскивание имеет некоторые известные проблемы. Вы не можете перетащить многократные элементы между приложениями Рабочего стола и Какао; можно только перетащить единственные элементы правильно между приложениями.

- (NSImage *), draggedImage всегда возвращает ноль, и - (интервал) draggingSequenceNumber возвращается 0.


Методы NSTextAttachmentCell

Протокол NSTextAttachmentCell имеет следующие дополнительные методы, объединяющие конформеры, может реализовать для более точного управления отслеживания мыши и рисованию:
- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView characterIndex:(unsigned)charIndex layoutManager:(NSLayoutManager *)layoutManager;
- (BOOL)wantsToTrackMouseForEvent:(NSEvent *)theEvent inRect:(NSRect)cellFrame ofView:(NSView *)controlView atCharacterIndex:(unsigned)charIndex;
wantsToTrackMouse метод позволяет присоединению указывать, хочет ли он когда-нибудь отследить мышь; если это возвращается ДА, то новый wantsToTrackMouseForEvent:inRect:ofView:atCharacterIndex: позволяет присоединению решать, хочет ли оно сделать так для определенных событий.


Поддержка перетаскивания в NSTableView и NSOutlineView

TableView и OutlineView теперь поддерживают, перетаскивают и отбрасывают. Для использования этого все, что необходимо, должно принять дополнительный API, найденный в NSTableViewDataSource и NSOutlineViewDataSource. Для изменения изображения перетаскивания по умолчанию можно переопределить новый метод, найденный в NSTableView.

Перетаскивание связанных протоколов DataSource:

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

Чтобы быть местом назначения перетаскивания, источник данных должен реализовать надлежащий validateDrop: и acceptDrop: методы. Поскольку перетаскивание продолжается, представление должно постоянно определять, где отбрасывание должно закончиться, если бы была выпущена мышь. На основе расположения мыши представление согласует, где потенциальное отбрасывание произошло бы так, чтобы это могло выделить расположение отбрасывания для визуальной обратной связи. Расположение отбрасывания согласовывается с validateDrop: метод.

С тех пор существует поддержка и между и на типах отбрасывания строк, согласование для расположения отбрасывания требует короткого объяснения. Примите табличное представление строки, пронумерованные от 0 до N-1 начиная с самой верхней строки. Теперь, предположите, что мышь по строке R табличного представления. Если мышь фактически ближе к строке R+1, чем середина строки R табличное представление сначала попытается согласовать отбрасывание между строкой R и R+1. Если источник данных отклонит то предложение, то табличное представление предложит отбросить на строке R самой. Наконец, когда мышь выпущена, источник данных будет отправлен acceptDrop: так, чтобы это могло включить отброшенные данные в ранее согласованном расположении.
typedef enum { NSTableViewDropOn, NSTableViewDropAbove } NSTableViewDropOperation;
В одежде представителя противоположного пола и отбрасывание, это перечисление используется для указания dropOperation. Например, учитывая таблицу со строками N (пронумерованный со строкой 0 наверху визуально), строка N-1 и работа NSTableViewDropOn указали бы отбрасывание на последней строке. Для указания отбрасывания ниже последней строки можно было бы использовать строку N и NSTableViewDropAbove для работы.
@interface NSObject (NSTableViewDataSource)
- (BOOL)tableView:(NSTableView *)tv writeRows:(NSArray*)rows toPasteboard:(NSPasteboard*)pboard;
Это выше метода вызывают после того, как было определено, что перетаскивание должно начаться, но прежде чем было запущено перетаскивание. Для отказа от перетаскивания возвратитесь НЕТ. Для запуска перетаскивания возвратите YES и поместите данные перетаскивания на область монтажа (данные, владелец, и т.д...). Изображение перетаскивания и другая соответствующая информация перетаскивания будут установлены и предоставлены табличным представлением, как только этот вызов возвращается с YES. Массив строк является списком номеров строк, которые будут участвовать в перетаскивании.
- (unsigned int)tableView:(NSTableView*)tv validateDrop:(id <NSDraggingInfo>)info proposedRow:(int)row proposedDropOperation:(NSTableViewDropOperation)op;
Этот метод используется NSTableView для определения допустимой цели отбрасывания. На основе положения мыши табличное представление предложит предложенное расположение отбрасывания. Этот метод должен возвратить значение, указывающее, который, перетаскивая работу выполнит источник данных. Источник данных может «перенастроить» отбрасывание при желании путем вызова setDropRow:dropOperation: и возврат чего-то другого, чем NSDragOperationNone. Можно принять решение перенастроить по различным причинам (например, по лучшей визуальной обратной связи при вставке в сортированную позицию).
- (BOOL)tableView:(NSTableView*)tv acceptDrop:(id <NSDraggingInfo>)info row:(int)row dropOperation:(NSTableViewDropOperation)op;
Этот метод вызывают, когда мышь выпущена по представлению схемы, ранее решившему позволить отбрасывание через validateDrop метод. Источник данных должен включить данные от области монтажа перетаскивания в это время.
@end
Следующее значение может использоваться в качестве допустимого childIndex целевого элемента отбрасывания. В этом случае отбрасывание произойдет непосредственно на целевом элементе.
enum { NSOutlineViewDropOnItemIndex = -1 };
@interface NSObject (NSOutlineViewDataSource)
- (BOOL)outlineView:(NSOutlineView *)olv writeItems:(NSArray*)items toPasteboard:(NSPasteboard*)pboard;
Этот метод вызывают после того, как было определено, что перетаскивание должно начаться, но прежде чем было запущено перетаскивание. Для отказа от перетаскивания возвратитесь НЕТ. Для запуска перетаскивания возвратите YES и поместите данные перетаскивания на область монтажа (данные, владелец, и т.д...). Изображение перетаскивания и другая соответствующая информация перетаскивания будут установлены и предоставлены представлением схемы, как только этот вызов возвращается с YES. Массив элементов является списком элементов, которые будут участвовать в перетаскивании.
- (unsigned int)outlineView:(NSOutlineView*)olv validateDrop:(id <NSDraggingInfo>)info proposedItem:(id)item proposedChildIndex:(int)index;
Вышеупомянутый метод используется NSOutlineView для определения допустимой цели отбрасывания. На основе положения мыши представление схемы предложит предложенное расположение отбрасывания. Этот метод должен возвратить значение, указывающее, который, перетаскивая работу выполнит источник данных. Источник данных может «перенастроить» отбрасывание при желании путем вызова setDropItem:dropChildIndex: и возврат чего-то другого, чем NSDragOperationNone. Можно принять решение перенастроить по различным причинам (например, по лучшей визуальной обратной связи при вставке в сортированную позицию).
- (BOOL)outlineView:(NSOutlineView*)olv acceptDrop:(id <NSDraggingInfo>)info item:(id)item childIndex:(int)index;
Этот метод вызывают, когда мышь выпущена по представлению схемы, ранее решившему позволить отбрасывание через validateDrop метод. Источник данных должен включить данные от области монтажа перетаскивания в это время.
@end
Примечания:

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

Перенастройка отбрасывания расположение Target:

Когда источник данных получает validateDrop: это должно возвратить значение, указывающее, может ли быть принято предложенное отбрасывание. В это время источник данных может перенастроить расположение отбрасывания, например, чтобы показать, что перетащенный.h файл закончится в группе h файлов. Для поддержки перенастройки предложенного расположения мы добавили один новый метод к NSTableView и NSOutlineView соответственно.
@interface NSTableView ...
- (void)setDropRow:(int)row dropOperation:(NSTableViewDropOperation)op;
Использоваться от validateDrop: если Вы хотите «перенастроить» предложенное отбрасывание. Для указания отбрасывания на второй строке можно было бы указать row=2 и op=NSTableViewDropOn. Для указания отбрасывания ниже последней строки можно было бы указать строку = [ТВ numberOfRows], и op=NSTableViewDropAbove.
@end
@interface NSOutlineView ...
- (void)setDropItem:(id)item dropChildIndex:(int)index;
Использоваться от validateDrop: для «перенастраивания» предложенного отбрасывания. Для указания отбрасывания на элементе I можно было бы указать item=I и index=NSOutlineViewDropOnItemIndex. Указать отбрасывание между дочерним элементом 2 и 3 из элемента I, на указало бы item=I, и index=3 (дочерние элементы являются индексированной нулевой основой). Для указания отбрасывания на нерасширяемом элементе I можно было бы указать item=I и index=NSOutlineViewDropOnItemIndex.
@end
Влияние на поведение перетаскивания значения по умолчанию:

По умолчанию, когда пользователь перетаскивает из таблицы или представления схемы, появится, как будто они перетаскивают копию ячеек (обычно текстовые ячейки). В то время как представления схемы только выведут на экран столбец схемы каждой строки, табличные представления выведут на экран всю строку. Для использования пользовательского изображения перетаскивания вместо этого, переопределите dragImageForRows:event:dragImageOffset:.
@interface NSTableView ...
- (NSImage*)dragImageForRows:(NSArray*)dragRows event:(NSEvent*)dragEvent dragImageOffset:(NSPointPointer)dragImageOffset;
Этот метод вычисляет и возвращает изображение для использования для перетаскивания. Переопределите это для возврата пользовательского изображения. 'dragRows' представляет строки, участвующие в перетаскивании. 'dragEvent' является ссылкой на мышь вниз событие, начавшее перетаскивание. 'dragImageOffset' в / параметре. Этот метод вызовут с набором dragImageOffset к NSZeroPoint, но это может быть изменено, чтобы изменить местоположение возвращенного изображения. dragImageOffset NSZeroPoint заставит изображение центрироваться под мышью.
@end
Распространенные ошибки:

Важно иметь в виду несколько вещей при реализации источника данных. Во-первых, Вы будете всегда отправляться допустимые предложения. Если Вы принимаете решение перенастроить отбрасывание, необходимо удостовериться, что цель отбрасывания допустима. Во-вторых, NSTableView и NSOutlineView поддерживают «на» и «между» видом отбрасываний. Это означает, что Вы будете потенциально отправлены два, обмениваются сообщениями, когда представление пытается определить, где предназначаться для отбрасывания. Например, если Вы будете очень близко к вершине строки, то реализация сначала предложит отбрасывание между той строкой и той выше ее. Однако при возврате NSDragOperationNone (возможно, Вы только хотите «на» отбрасываниях типа), реализация предложит отбрасывание «на» самой строке. И конечно, если Вы ближе к середине строки, что край, «на» отбрасывании попробуют перед «между» видом отбрасывания.

Так, предположите, что Вы только хотите принять «на» отбрасываниях типа. Частая ошибка может быть замечена в следующем сегменте кода:
- (unsigned int)tableView:(NSTableView*)tv validateDrop:(id <NSDraggingInfo>)info proposedRow:(int)row proposedDropOperation:(NSTableViewDropOperation)op {
...
// Decide if we want to accept the data in info...
...
if (weWantThisData) {
[tv setDropRow: row dropOperation: NSTableViewDropOn];
return NSDragOperationAll;
} else {
return NSDragOperationNone;
}
}
Лицо, осуществляющее внедрение забыло, что строка N (где таблица имеет строки 0 через N-1) и работа типа NSTableViewDropAbove допустима. Это означает, что законно для NSTableView предложить N и NSTableViewDropAbove как цель отбрасывания (т.е. предложить отбрасывание «ниже» последней строки). К сожалению, в этой ситуации, вышеупомянутый сегмент закончит тем, что перенастроил отбрасывание, чтобы быть «на» строке N, который не целесообразно! Вышеупомянутый сегмент кода должен был быть:
- (unsigned int)tableView:(NSTableView*)tv validateDrop:(id <NSDraggingInfo>)info proposedRow:(int)row proposedDropOperation:(NSTableViewDropOperation)op {
if (op==NSTableViewDropOn) {
...
// Decide if we want to accept the data in info...
...
if (weWantThisData) {
return NSDragOperationAll;
} else {
return NSDragOperationNone;
}
} else {
return NSDragOperationNone;
}
}
Автоматическая поддержка расширения в NSOutlineView:

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

Когда перетаскивание закончилось, представление схемы может решить автоматически разрушиться, эти элементы (после того, как маленькая задержка) для возврата схемы просматривают назад к ее исходному состоянию. По умолчанию, если отбрасывание успешно (как обозначено возвращаемым значением fromacceptDrop:), элементы останутся открытыми. Если отбрасывание перестанет работать, то элементы разрушатся и возвратятся к их исходному состоянию. Для изменения этого поведения нужно переопределить следующий метод в NSOutlineView:
@interface NSOutlineView ...
- (BOOL)shouldCollapseAutoExpandedItemsForDeposited:(BOOL)deposited;
Этот метод возвращает YES, чтобы указать, что автоматические расширенные элементы должны возвратиться к разрушенному состоянию их оригинала. Переопределите этот метод для обеспечения пользовательского поведения. 'депонированный' говорит, завершилось ли отбрасывание вследствие успешного отбрасывания (как обозначено возвращаемым значением от acceptDrop:). Обратите внимание на то, что выход из представления будет обработан то же как неработающее отбрасывание.
@end
Известные ошибки:

NSOutlineView в настоящее время имеет ошибку, заставляющую его отправлять theoutlineView:validateDrop:proposedItem:proposedChildIndex:in situatuations, где это не необходимо. В частности если мышь переместилась немного, и представление схемы определяет цель, которую это предложит, совпадает с прежде, метод не должен быть отправлен. В настоящее время, в этой ситуации, сообщение будет отправлено, и клиенты не должны рассчитывать на это остающееся поведение.


NSImage

Два новых метода были добавлены, которые позволяют изображению быть представленным с любой работой составления композита и с любым альфа-значением одновременно.
- (void)compositeToPoint:(NSPoint)point operation:(NSCompositingOperation)op fraction:(float)delta;
- (void)compositeToPoint:(NSPoint)point fromRect:(NSRect)rect operation:(NSCompositingOperation)op fraction:(float)delta;
Ранее, изображение могло быть составлено с любой работой, но только в альфе 1,0 (-[NSImage compositeToPoint:operation:]) или просто sourceOver с переменной альфой (-[NSImage dissolveToPoint:fraction:]). Обратите внимание на то, что могут быть определенные комбинации работы и альфы, которая не может быть распечатана правильно.


NSBitmapImageRep

NSImage через NSBitmapImageRep теперь использует QuickTime GraphicsImporter для чтения дополнительных типов растрового изображения. Дополнительные типы и расширения, которые в настоящее время поддерживает QuickTime:

FlashPix: .fpix, .fpx
Макпэйнт: .pntg, .pnt, .mac
Photoshop: .psd
SGI: .sgi, .rgb
Тарга: .targa, .tga
Формат изображения QuickTime: .qtif, .qti


NSOpenGLView

NSOpenGLView был изменен, чтобы заархивировать информацию и позволить динамическое изменение и контекста и его связанного формата пикселя. Новое поведение состоит в том, что контекст не создается, до или - [NSOpenGLView openGLContext] или - [NSOpenGLView openGLContext] вызываются. Это позволяет Вам изменить формат пикселя после создания представления. Новые методы:
+ (NSOpenGLPixelFormat *)defaultPixelFormat;
Этот метод класса вызывают, когда контекст создается, но не был указан никакой формат пикселя. По умолчанию это возвращает формат, упакованный в ящики с пустым списком атрибутов. Можно переопределить его в пользовательском классе, если Вы хотите передать в различном наборе атрибутов, когда создается представление.
- (void)clearGLContext;
Это избавится от контекста, связанного с представлением. Можно использовать это для изменения формата и затем calllockFocusagain для создания нового контекста.
- (void)setPixelFormat:(NSOpenGLPixelFormat *)pixelFormat;
- (NSOpenGLPixelFormat *)pixelFormat;
Они устанавливают и связали формат пикселя с контекстом. При установке формата после того, как был создан контекст, не имеет никакого эффекта на текущий контекст представления. Эта информация архивируется.


NSOpenGLPixelFormat

NSOpenGLPixelFormat теперь следует протоколу NSCoding. Поскольку список атрибутов является произвольным списком целых чисел, необходимо указать список через объект NSData, если атрибуты к заархивированному. Если Вы создаете формат с помощью initWithAttributes: тогда никакие данные не архивируются и когда это восстанавливается, значение по умолчанию к старому списку. Новые методы:
- (id)initWithData:(NSData *)attribs;
Это сохранит атрибуты, переданные в NSData.
- (NSData *)attributes;
- (void)setAttributes:(NSData *)attribs;
Это позволит Вам устанавливать и получать список атрибутов для объекта формата.


NSColor

Новый метод класса был добавлен, который возвращает единственный цвет, отражающий оттенок средств управления.
+ (NSColor *)colorForControlTint:(NSControlTint)controlTint;

Клавиатурный фокус

Из-за незаконченных изменений в появлении и поведении пользовательского интерфейса клавиатурного фокуса, кнопки, ползунки и вкладки были временно выключены для Общедоступной Бета-версии. Это означает - [NSButtonCell acceptsFirstResponder], - [NSSliderCell acceptsFirstResponder], и - [NSTabView acceptsFirstResponder] теперь возвращаются НЕТ. Мы намереваемся фиксировать это для следующего выпуска.


Стандарт о панели

Поддержка осуждаемого NSBuildVersion, NSAppVersion, и NSHumanReadableShortName и внутреннего AuxiliaryInformation и BackgroundImage вводит словарь опций, был удален.


Сценарии

Зависимости пишущей сценарий платформы от EOControl были удалены путем копирования кодирования ключа/значения в Основу, и путем разделения на подклассы NSScriptClassDescription прочь NSClassDescription в Основе (вместо EOClassDescription).

После Общедоступной Беты мы намереваемся свернуть Сценарии и AppKitScripting в Основу и AppKit, соответственно. Для защиты приложения от этого изменения было бы лучше соединиться против Cocoa.framework вместо AppKit.framework и AppKitScripting.framework.


NSRect по сравнению с CGRect

Мы намереваемся свернуть эти два типа в один. Однако это не произошло для Общедоступной Беты. Для ситуаций, куда необходимо передать их назад и вперед, мы рекомендуем использовать макро-или подставляемую функцию, в основном делающую что-то как:
*(CGRect *)&nsRect
*(NSRect *)&cgRect

Предупредительная панель

Инструкции по интерфейсу пользователя для предупреждений теперь утверждают, что сообщение предупреждения появляется в вершине (где заголовок), и больше дополнительной вторичной информации появляется ниже этого в шрифте меньшего размера. Так, вместо
Close
Do you want to save this document before closing?
<Don't Save> <Cancel> <OK>
необходимо вместо этого использовать что-то как:
Do you want to save this document before closing?
The contents of this document will be lost if it is not saved.
<Don't Save> <Cancel> <OK>
API для контакта с предупреждениями и способ, которым мы обрабатываем параметры, не были изменены (параметр «заголовка» появляется как полужирный элемент, параметр «сообщения» как вторичная информация, и дополнительные аргументы применяются только к сообщению); кроме того, много стандартных панелей в AppKit и стандартных приложений не было также обновлено. Разработчики могли бы хотеть изменить параметры в своих предупредительных вызовах панели для больше соответствования этим новым инструкциям. На данный момент нет никакого удобного способа параметризовать первый параметр (с % - замены), но можно просто использовать [NSString stringWithFormat:] для обхождения этого.


Java

Пакеты Java для платформ Какао были переименованы от com.apple.yellow.* к com.apple.cocoa.*. Инструменты преобразования и инструкции могут быть найдены в/Developer/Java/Conversion/YellowToCocoa.


NSEvent

- символы и методы-charactersIgnoringModifiers теперь возвращаемые значения обрабатываются менеджером Carbon Text Services. TSM отображает коды клавиши с помощью текущего сценария клавиатуры (т.е. Вы получаете 'w' для 'z' позиции, если Ваш текущий сценарий клавиатуры является французским). Отображения происходят лениво так, чтобы NSEvent вызвал и создал NSString только, когда это необходимо. Это изменение класса NSEvent завершает менеджера Carbon Text Services интеграция в наборе.

scrollWheel событие теперь отправляется в представление под мышью, а не первым респондентом. Это означает по умолчанию, что представление под указателем мыши прокручивается, когда используется scrollwheel.


NSGlyphGenerator

Текстовая система теперь использует основанную на ATS генерацию глифа. Это означает, что мы используем тот же алгоритм для генерации глифов, как ATSUI делает. Все функции по умолчанию в 'morf' или 'morx' таблице применяются автоматически включая лигатуру, пропорциональную замену Hiragana/Katakana и предварительный состав Unicode. Среди функций только kLigaturesType в настоящее время отображается на атрибуте NSAttributedString NSLigatureAttributeName. NSLigatureAttributeName оценивают 0, применяет kRequiredLigaturesOnSelector селектор, оцените 1, действительно все принимает значение по умолчанию селекторы и оценивает 2, делает весь селектор, поддерживаемый шрифтом. Если шрифт имеет соответствующий свод правил, генератор глифа все еще использует основанную на своде правил генерацию глифа. В настоящее время можно вынудить набор использовать основанную на CG генерацию глифа путем установки _NSForceRulebookGlyphGeneration в YES.

AppKit отключает kDiacriticsType, kFractionsType, и kTypographicExtrasType/kSmartQuotesOffSelector, даже если это включено в шрифте.


NSPICTImageRep

При рендеринге NSPICTImageRep через его методы получения он будет нарисован с помощью QuickDraw. Поскольку f это, это не будет отсечено или преобразовано на основе текущих границ NSView и может закончить тем, что рисовало вне представления.

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


Службы

В общедоступной Бете нет никакого «make_services»; вместо этого открытие службы сделано PBS во время входа в систему. Таким образом, чтобы заставить новые службы, которые будут распознаны, необходимо будет выйти из системы, и журнал въезжают задним ходом.

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



Отмечает определенный для Предварительного просмотра Разработчика Mac OS X 4

Вода

Метрики проекта воды изменились начиная с DP3. По большей части элементы UI являются теперь тем же размером как свои дубликаты в Платине (Mac OS 9 взглядов). Текст в пользовательском интерфейсе все еще использует Lucida Grande, но размер в большинстве ситуаций - теперь 13 ПБ.

Используйте Интерфейсного Разработчика, «Применяют функциональность» Инструкций по Расположению для согласовывания перьев.


NSTableView

В этом выпуске несколько новых методов были добавлены к NSTableView.

Два метода поддерживают «изображения индикатора» для использования в заголовках столбца таблицы. Произвольное (маленькое) изображение может быть установлено быть представленным на правой стороне заголовка столбца. (Это используется, например, в Почте для указания направления сортировки в настоящее время сортируемого столбца в почтовом ящике.)
- (void)setIndicatorImage:(NSImage *)anImage inTableColumn:(NSTableColumn *)tc;
- (NSImage *)indicatorImageInTableColumn:(NSTableColumn *)tc;
Поддержка была также добавлена для highlightable заголовка столбца, который может использоваться в сочетании с выбором строки для выделения определенного столбца таблицы. (Например, как используется в Почте указать в настоящее время сортируемый столбец.)
- (void)setHighlightedTableColumn:(NSTableColumn *)tc;
- (NSTableColumn *)highlightedTableColumn;
Три новых метода делегата были добавлены для помогания поддержать новых изображений индикатора и выделенных заголовков столбцов. Первый метод отправляется делегату каждый раз, когда мышью щелкают вниз в заголовке столбца. Второй метод отправляется в то время, когда мышь впоследствии восстанавливает работоспособность, и по столбцу «щелкнули», не будучи перетащенным никуда. Третий метод отправляется во время мыши, когда столбец был перетащен в течение времени, мышь снизилась.
- (void)tableView:(NSTableView *)tableView mouseDownInHeaderOfTableColumn:(NSTableColumn *)tableColumn;
- (void)tableView:(NSTableView *)tableView didClickTableColumn:(NSTableColumn *)tableColumn;
- (void)tableView:(NSTableView *)tableView didDragTableColumn:(NSTableColumn *)tableColumn;

NSApplication

AppKit теперь обрабатывает, «вновь открывают» (rapp) AppleEvents. Эти события отправляются каждый раз, когда Средство поиска повторно активирует уже запущенное приложение, потому что кто-то дважды щелкнул по нему снова или использовал прикрепление для активации его. По умолчанию AppKit обработает это событие путем проверки, существуют ли какие-либо видимые NSWindows (не NSPanels) и, если нет ни одного, это проходит через стандартное создание документа без названия (то же, как это делает, если приложение запускается без любого документа для открытия). Для большинства основанных на документе приложений это означает, что будет создаваться документ без названия. Делегат приложения также получит шанс реагировать на нормальные делегации документа без названия.

Существует также новый метод делегата NSApplication, который могут использовать приложения, если они хотят иметь определенное поведение для, вновь открываются, который отличается от поведения по умолчанию, описанного выше:
- (BOOL)applicationShouldHandleReopen:(NSApplication *)sender hasVisibleWindows:(BOOL)flag;
При реализации этого метода в делегате приложения его вызовут, прежде чем любое поведение по умолчанию происходит. Если Вы возвратитесь ДА, то NSApplication продолжит делать свою нормальную вещь. Если Вы возвратитесь нет, то NSApplication ничего не сделает. Так, можно или реализовать это, ничего не сделать и возвратиться НЕ, если Вы не хотите, чтобы что-нибудь произошло вообще (не рекомендуемый), или можно реализовать это, обработать событие сами некоторым пользовательским способом и возвратиться НЕТ. Параметр «флага» указывает, нашел ли NSApplication какой-либо видимый NSWindows в Вашем приложении. Этот флаг может использоваться в качестве индикации относительно того, сделал ли бы NSApplication что-нибудь при возврате YES.

Обратите внимание на то, что то, что происходит с минимизируемыми окнами, еще не определяется, но намерение состоит в том, что флаг == НЕ указывает, создаст ли AppKit новое окно для удовлетворения вновь открыть события.


NSApplication теперь реализует методы действия скрыть все приложения (кроме вызывающей стороны) и вывести на экран все приложения (включая вызывающую сторону).
- (void)hideOtherApplications:(id)sender;
- (void)unhideAllApplications:(id)sender;
В DP4 unhideAllApplications заставит каждое приложение упорядочивать свои окна к передней стороне, которая могла затенить в настоящее время активное окно в активном приложении.

Документ модальный API

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

DP4 представляет новый API, возвращающийся сразу с начала модального сеанса, затем вызывающий обратный вызов, когда отклонен модальный сеанс. Текущий документ модальный API будет осуждаться, но будет все еще работать через DP4.

Запустить документ модальный сеанс, NSApplication.h:
- (void)beginSheet:(NSWindow *)sheet modalForWindow:(NSWindow *)docWindow modalDelegate:(id)modalDelegate didEndSelector:(SEL)didEndSelector contextInfo:(void *)contextInfo;
didEndSelector метод является дополнительным. Если это реализовано modalDelegate, этот метод вызывается после того, как модальный сеанс закончил и передал код, и вызывающая сторона указала contextInfo. didEndSelector должен иметь следующую подпись:
- (void)didEndSheet:(NSWindow *)sheet returnCode:(int)returnCode contextInfo:(void *)contextInfo;
Для окончания документа модальный сеанс окно листа должно быть указано:
- (void)endSheet:(NSWindow *)sheet;
- (void)endSheet:(NSWindow *)sheet returnCode:(int)code;
В NSPanel.h:
void NSBeginAlertSheet(NSString *title, NSString *defaultButton, NSString *alternateButton, NSString *otherButton, NSWindow *docWindow, id modalDelegate, SEL willEndSelector, SEL didEndSelector, void *contextInfo, NSString *msg, ...);
void NSBeginInformationalAlertSheet(NSString *title, NSString *defaultButton, NSString *alternateButton, NSString *otherButton, NSWindow *docWindow, id modalDelegate, SEL willEndSelector, SEL didEndSelector, void *contextInfo, NSString *msg, ...);
void NSBeginCriticalAlertSheet(NSString *title, NSString *defaultButton, NSString *alternateButton, NSString *otherButton, NSWindow *docWindow, id modalDelegate, SEL willEndSelector, SEL didEndSelector, void *contextInfo, NSString *msg, ...);
Обратите внимание на то, что параметры упорядочиваются по-другому, чем NSRunAlertPanel () вызовы, чтобы гарантировать, что они сгруппированы лучше и обеспечивают лучшую проверку типа параметров.

Реализация willEndSelector и didEndSelector метода является дополнительной. Если willEndSelector реализован modalDelegate, этот метод вызывается после того, как модальный сеанс закончился, но прежде, чем отклонить лист. didEndSelector вызывается после отклонения листа. willEndSelector и didEndSelector методы должны иметь следующие подписи:
- (void)willEndSheet:(NSWindow *)sheet returnCode:(int)code contextInfo:(void *)contextInfo;
- (void)didEndSheet:(NSWindow *)sheet returnCode:(int)code contextInfo:(void *)contextInfo;
В NSSavePanel.h:
- (void)beginSheetForDirectory:(NSString *)path file:(NSString *)name modalForWindow:(NSWindow *)docWindow modalDelegate:(id)delegate didEndSelector:(SEL)didEndSelector contextInfo:(void *)contextInfo;
Реализация didEndSelector является дополнительной. Если didEndSelector реализован modalDelegate, этот метод вызывается после того, как модальный сеанс закончился, но прежде, чем отклонить лист панели сохранения. didEndSelector метод может отклонить саму панель сохранения; это будет отклонено по возврату из метода иначе.
- (void)didEndSavePanel:(NSSavePanel *)savePanel returnCode:(int)code contextInfo:(void *)contextInfo;
Для следующего выпуска мы предназначаем при помещении документа модальную поддержку листа в NSDocument.

NSEvent

Метод класса был добавлен к NSEvent.h для экспорта текущего положения мыши в координатах экрана:
+ (NSPoint)mouseLocation;
Тип события, NSScrollWheel, был добавлен к NSEvent.h для поддержки событий колесика прокрутки. Кроме того, следующий метод был добавлен к NSResponder.h:
- (void)scrollWheel:(NSEvent *)theEvent;
Если NSScrollView будет firstResponder, то событие NSScrollWheel будет обработано то же как щелчок по стрелке скроллера.

NSEvent.h также определяет методы для получения дельты вдоль каждой оси для события колесика прокрутки:
- (float)deltaX;
- (float)deltaY;
- (float)deltaZ;

Поддержка динамических экранных изменений

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

Уведомление приложения и метод делегата были добавлены:
NSString *NSApplicationDidChangeScreenParametersNotification;
- (void)applicationDidChangeScreenParameters:(NSNotification *)notification;

NSDrawer

NSDrawers может теперь иметь делегатов, со следующим делегатом и делегировать методы уведомления:
@interface NSObject(NSDrawerNotifications)
- (void)drawerWillOpen:(NSNotification *)notification;
- (void)drawerDidOpen:(NSNotification *)notification;
- (void)drawerWillClose:(NSNotification *)notification;
- (void)drawerDidClose:(NSNotification *)notification;
@end
@interface NSObject(NSDrawerDelegate)
- (BOOL)drawerShouldOpen:(NSDrawer *)sender;
- (BOOL)drawerShouldClose:(NSDrawer *)sender;
- (NSSize)drawerWillResizeContents:(NSDrawer *)sender toSize:(NSSize)contentSize;
@end
Вызовы к методу drawerWillResizeContents:toSize: еще не реализованы. Дополнительные методы для самого NSDrawer:
- (void)setDelegate:(id)anObject;
- (id)delegate;
- (void)open:(id)sender;
- (void)close:(id)sender;

NSTabView

NSTabView улучшил свою поддержку усечения его текстовой метки. Когда будет недостаточно пространства для отображения всех меток NSTabViewItem, усечение будет выполняться, начинаясь сначала с более длинных меток. Обратите внимание на то, что были тонкие изменения в методах, которые подклассы NSTabViewItem переопределяют для отображения их владеть маркой. Хотя сигнатура метода остается тем же, использование изменилось.
- (void)drawLabel:(BOOL)shouldTruncateLabel inRect:(NSRect)labelRect;
Этот метод рисует метку вкладки в labelRect, который является областью, промежуточной кривые заглушки. shouldTruncateLabel является подсказкой, что метка должна быть усеченной; если shouldTruncateLabel ДА, то labelRect <перекрывают ([... sizeOfLabel:YES])
- (NSSize)sizeOfLabel:(BOOL)flag;
Этот метод возвращает минимальный или номинальный размер метки вкладки. Флаг указывает, необходимо ли возвратить минимальный или номинальный размер метки. Возвращенное значение используется для вычислений диапазона юридических размеров для метки вкладки.


Загрузка NEXTSTEP 3.x .nib файлы

Отображения разархивирования от старых классов NEXTSTEP (как NXBrowser) к классам OPENSTEP (как NSBrowser) теперь отключены по умолчанию. Значение по умолчанию временного пользователя NSEnableNEXTSTEPArchiverMappings со значением YES может использоваться, чтобы повторно включить установку этих отображений.

Обратите внимание на то, что NXStringTable, NXBundle, StreamTable и Классы памяти были удалены со времени выполнения ObjC, поэтому если перо будет содержать экземпляры этих классов, то это также не загрузится, и нет никакого способа исправить это. На данный момент классы Списка и HashTable и функции NXHashTable, остаются, но необходимо ожидать эти вещи, удаляемые со времени выполнения в будущем.

objc_getClasses

objc_getClasses () функция в objc/objc-runtime.h является устаревшим. Необходимо использовать новый objc_getClassList () функция вместо этого, как описано в комментарии в заголовке.

NSPDFImageRep

Поддержка была добавлена к NSPDFImageRep для выбора который страница многостраничного документа рендерингу. Ранее, только первая страница была нарисована.
- (void)setCurrentPage:(int)page;
- (int)currentPage;
- (int)pageCount;
Первые два набора методов и заставляют текущую страницу отображать. Индекс страницы является базируемым нулем. pageCount возвращает число страниц в документе. После вызова setCurrentPage: прямоугольник, возвращенный - [Границы NSPDFImageRep], для новой страницы.

NSColor

Новый метод был добавлен к списку системных цветов:
+ (NSColor*)windowBackgroundColor;
Под Водой это теперь возвращает NSPatternColor, который проведет управляемые линии для фона окна.

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

Много системных цветов, в то время как все еще допустимый, больше не значимы под Водой. Они включают любого из тех с 'управлением' на их имя. Они возвращают старые Платиновые цвета появления, которые обычно являются оттенком серого.

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

NSWorkspace

Новый метод был добавлен, который позволяет Вам уведомлять Средство поиска, когда был добавлен новый файл.
- (void)noteFileSystemChanged:(NSString*)path;
NSDocument и NSSavePanel, как изменено использовать этот метод, сохранив файл. При создании файла непосредственно необходимо вызвать этот метод так, чтобы Средство поиска могло обновить папку, если это открыто.

NSSavePanel

Новый метод делегата был добавлен к NSSavePanel, уведомляющему делегата, когда панель сохранения собирается расшириться или разрушиться. Можно получить вызов к этому в первый раз, когда панель показана, поскольку она разрушается или расширяется на основе последнего состояния, это было в.
- (void)panel:(id)sender willExpand:(BOOL)expanding;
Новая функция, соглашающаяся с новым методом делегата, возвращает текущее состояние панели сохранения. Обратите внимание на то, что для открытой панели, это в настоящее время всегда возвращает YES:
(BOOL)isExpanded;

NSOpenGLContext, NSOpenGLView

Поддержка была добавлена для рендеринга OpenGL в представление в AppKit. Можно получить прямой доступ к системе OpenGL через NSOpenGLContext и его класс assocated NSOpenGLPixelFormat, или можно просто создать экземпляр NSOpenGLView и когда Вы lockFocus на представлении, текущий контекст OpenGL будет установлен в представление. Вы не можете составить использующее регулярное 2D получение в представлении, так как это полностью покрыто 3D контекстом.

NSOpenGLView имеет 2 открытых метода. Каждый - init метод, куда можно передать в пользовательском формате пикселя для выбора определенного набора функций рендеринга. Если Вы просто притягиваете NSOpenGLView в InterfaceBuilder, это эквивалентно передаче в ноле для формата, когда, система выберет лучший формат, это может на основе возможностей оборудования.
- (id)initWithFrame:(NSRect)frameRect pixelFormat:(NSOpenGLPixelFormat*)format;
- (NSOpenGLContext*)openGLContext;
Если Вы хотите нарисовать к представлению за пределами вызова lockFocus, можно просто установить текущий контекст непосредственно через [[glView openGLContext] makeCurrentContext];.

Для полного экрана или внеэкранного получения, необходимо будет создать собственный NSOpenGLContext. Хотя NSOpenGLContext действительно позволяет Вам связывать любое представление с контекстом, необходимо будет обработать любые изменения кадра представления сами. Рекомендуется использовать NSOpenGLView в этих случаях.

Значения по умолчанию

Набор больше не регистрирует несколько устаревших значений по умолчанию, включая NSHost и несколько для NSPrinter.

genstrings

genstrings теперь всегда выписывает файлы Unicode. Они могут быть отредактированы в TextEdit или других текстовых редакторах, способных к контакту с Unicode.

Для локализуемых строк без указанной таблицы genstrings просто записал бы вывод в stdout. Это теперь вместо этого запишет вывод Локэлизэбле.стрингсу, который является таблицей по умолчанию, с которой консультируется код NSBundle/CFBundle, когда не указана никакая таблица.

Стандарт о панели

Ключи ProjectVersion и SystemVersionName больше не разыскиваются в о словаре опций панели. Эти ключи не были задокументированы публично. Корректным ключом для использования является ApplicationVersion, который должен иметь значение для указания имени версии продукта, например «Mac OS X» (для системных приложений), «веб-Объекты 4.5», «FooSimulator 2000», и т.д. Если не указанный в словаре опций, будет взят ключ CFBundleShortVersionString от информации пакета plist; если это не будет там, старая форма, то NSAppVersion будет использоваться. (Обратите внимание на то, что в DP4 существует ошибка, предотвращающая автоматическое взятие строки CFBundleShortVersionString от Info.plist.)

Для внутренних приложений с помощью внутреннего о функции панели это поле автоматически заполняется с именем версии продукта, «Mac OS X».

Ключ Version, если не указанный, теперь поднят с CFBundleVersion, вводят информацию пакета plist. Если это не будет там, старая форма, то NSBuildVersion будет также разыскиваться.

Информация о версии InfoPlist.html была обновлена с другими изменениями в ключах Info.plist.

Текст

Документы Macintosh, создаваемые с SimpleText (MacOS вводит TEXT, sEXT, ttro), могут теперь быть загружены в приписанные строки при использовании initWithPath:documentAttributes: и initWithURL:documentAttributes:.

Встроенная графика поддерживается (такие файлы не непосредственно creatable с самим SimpleText, но сохраненные как ресурсы PICT). Обратите внимание на то, что нет никаких планов относительно поддержки сохранения документов в формате SimpleText.

Во всех методах, берущих documentAttributes: параметр, если не NULL, по возврату это может теперь также содержать следующие дополнительные ключи:

«DocumentType»: указание NSString, как толкнулся документ; см. NSAttributedString.h для возможных значений
«CharacterEncoding»: Для файлов простого текста только; NSNumber, содержащий интервал без знака, указывающий NSStringEncoding раньше, интерпретировал файл

Следующий метод был добавлен к NSMutableAttributedString как общая точка трубы для всей загрузки документа:
- (BOOL)readFromURL:(NSURL *)url options:(NSDictionary *)options documentAttributes:(NSDictionary **)dict;
Этот метод походит на initWithURL:documentAttributes:; кроме него может быть снова использован для перезагрузки файла в существующую приписанную строку, и поведение может быть настроено со словарем опций. Если не NULL, этот словарь может содержать следующие значения:

«CharacterEncoding»: Для документов простого текста; NSNumber, содержащий международный NSStringEncoding без знака, который будет использоваться, если не может быть определено кодирование
«BaseURL»: Для документов HTML; NSURL, содержащий базовый URL
«DefaultAttributes»: NSDictionary, содержащий атрибуты, которые будут применены к простым файлам

NSLayoutManager

NSLayoutManager теперь включают поддержку временных атрибутов. Эти атрибуты используются только для экранного получения и не персистентные всегда. Когда непрерывная проверка правописания включена, NSTextView использует их для окраски слов с ошибками. В настоящее время единственные временные атрибуты, которые будут распознаны, являются связанными с цветами и подчеркиваниями. Следующий временный атрибут имел отношение, методы доступны для NSLayoutManager:
- (NSDictionary *)temporaryAttributesAtCharacterIndex:(unsigned)charIndex effectiveRange:(NSRangePointer)effectiveCharRange;
- (void)setTemporaryAttributes:(NSDictionary *)attrs forCharacterRange:(NSRange)charRange;
- (void)addTemporaryAttributes:(NSDictionary *)attrs forCharacterRange:(NSRange)charRange;
- (void)removeTemporaryAttribute:(NSString *)name forCharacterRange:(NSRange)charRange;

Соединение Carbon.framework

AppKit.framework больше не соединяется против Carbon.framework, но против подплатформ в там. Это все еще вводит большинство платформ, покрытых платформой зонтика; исключенные включают NavigationServices и CommonPanels. Если Ваше приложение вытягивает в символах Углерода явно от них (и другой не включенные платформы), необходимо, вероятно, запросить вытянуть в Carbon.framework явно.

NSImage

[NSImage imageNamed:@ «foo»] теперь найдет foo.tiff в локализованном каталоге ресурсов (для основного языка), прежде чем это найдет некоторый другой тип foo в нелокализованном каталоге. Это поведение изменяется в этом, прежде чем нелокализованный «foo» (с распознанным расширением файла образа) был бы найден перед локализованным «foo». Это изменение было сделано для размолвки только по причинам производительности.

NSPanel

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

Неактивация условий:
1) Это - служебное окно
2) Это - плавающая панель
3) becomesKeyOnlyIfNeeded == YES
4) Событие mouseDown происходит в представлении, не принимающем первое состояние респондента

NSCell

Осуждаемое перечисление оценивает NSStateMixed, НССТЭТЕОФФ, и NSStateOn были удалены из NSCell.h. Используйте NSMixedState, NSOffState и NSOnState вместо этого.

NSMenu

+(void)popUpContextMenu:(NSMenu*)menu withEvent:(NSEvent*)event forView:(NSView*)view;
Этот метод выведет на экран NSMenu как контекстное меню в представлении. Используйте это, если поддержка контекстного меню в NSView не удовлетворяет Вашим потребностям. Меню раскроется расположенное рядом с курсором.

NSMatrix, NSTextField

Следующие методы были сделаны устаревшими и удаленными из общедоступных заголовков. Они осуждаются, и NSFormatter должен использоваться вместо этого для обработки плохо ввода.
- (SEL)errorAction;
- (void)setErrorAction:(SEL)aSelector;

NSMovieView

NSMovieView, все еще функциональный в Выпуске Developer 4.

NSMenu

Изображения в раскрываются, и меню все еще не работают; это - ошибка.

NSScreen

Следующие методы являются частными и не должны быть перечислены в NSScreen.h вообще. Они будут удалены из заголовков post-DP4:
- (NSRect)_savedVisibleFrame;
- (void)_saveVisibleFrame

Многократные мониторы

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

NSWindow

Проблемы повторной входимости DP3 с методами NSWindow - [NSWindow setMiniwindowTitle:] и - [NSWindow setTitle:] были фиксированы в DP4. Они были вследствие взаимодействия прикрепления, которое могло заставить runloop быть повторно введенным.



Отмечает определенный для Предварительного просмотра Разработчика Mac OS X 3

Вода

Большим изменением в Предварительном просмотре Разработчика 3 является Вода, новый пользовательский интерфейс. Вода вносит с ним много визуальных изменений, новых функций и многих дополнений к APIs.

Несмотря на то, что Вы получаете новый взгляд для Воды автоматически в Ваших приложениях, некоторые новые функции, такие как документ, модальные панели доступны через новый APIs и автоматически не взяты.

По большей части метрики Воды больше, чем используемые ранее (в виде «платины» Сервера Mac OS X). Это означает, что, когда файлы пера перед водой открыты под Водой, будут отсечены определенные средства управления. Кроме того, Вода представляет новое расположение для строки меню. Посмотрите ниже для подробных данных о том, как преобразовать перья в инструкции по Воде.


Специфичные для платформы модификаторы ресурса

Для разрешения предварительной воды, и Вода взаимодействует через интерфейс для сосуществования, у нас есть отдельные модификаторы ресурса для платинового появления (используемый на Сервере Mac OS X) и Вода. Используйте макинтош для вида Сервера Mac OS X и macos для Воды. Вы делаете это путем добавления «-macos» или «-макинтош» к базовому имени любого ресурса, полученного (прямо или косвенно) через NSBundle или CFBundle.

Для тех из Вас преобразовывающий ресурсы для поддержки Воду, но также и бывший должный поддерживать вид Сервера Mac OS X мы предлагаем переименовать старые ресурсы для имения идентификатора платформы макинтоша, и сохранить Вы - ресурсы Воды без идентификатора платформы. Это, вероятно, столь же просто как:
cp -r foo.nib foo-macintosh.nib
теперь отредактируйте foo.nib к для Воды

(Вещи станут немного более хитрыми, если у Вас будут другие специфичные для платформы ресурсы.)

Если Вы не должны поддерживать Сервер Mac OS X, то у Вас может просто быть один набор перьев без специальных идентификаторов ресурсов.


Преобразование UI к воде

Интерфейсный Разработчик обеспечивает удобство для обновления перьев для приспосабливания инструкциям по Воде. Откройте свои файлы пера в IB и используйте команду меню «Apply UI Guidelines» для согласовывания окон и меню.

«Применяйтесь, Инструкции UI» применяется только к в настоящее время выбираемому окну редактирования; таким образом, если у Вас будут многократные окна в Вашем пере, то необходимо будет выбрать каждое окно вручную и выполнить эту команду. Кроме того, для согласовывания расположения меню щелкните по редактору меню (экранное представление меню, не изображение «MainMenu» в окне документа IB) и выполните эту команду.

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

В старых файлах пера средства управления не могли бы использовать шрифт «сообщения», но вместо этого зашитый шрифт, такой как Helvetica. Они автоматически не преобразовываются для использования Lucida в 14 точках, которые являются новым стандартным шрифтом для большинства средств управления. В тех случаях лучше устанавливать шрифт, привыкший теми средствами управления к сообщению «Пользователя Шрифт», в 14 ПБ, можно выбрать через панель шрифта в Интерфейсном Разработчике.


Секция

Секции являются новым дополнением к AppKit. Для примера секции посмотрите секцию почтовых ящиков в Почте. С точки зрения API NSDrawer является коллегой NSWindow; как окно, секция используется, чтобы содержать и вывести на экран представления. Секция, однако, может появиться на экране только, когда связано с окном, которое вызывают его родителем. Секция не может быть перемещена или упорядочена независимо, но вместо этого присоединена к одному из краев его родителя и перемещается вместе с ним. Секции могут быть изменены, но секция никогда не может быть больше, чем ее родитель. Данное окно может иметь любое число секций; это - ответственность разработчика удостовериться, что многократные секции не открыты сразу наложение друг друга на том же краю.

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

Точное появление секции и ее реализация, могут быть зависимыми от платформы. Когда секция находится на экране, его представления должны обязательно быть помещены в некотором NSWindow так, чтобы они могли быть выведены на экран, но этот объект является частным, и его точный класс, вероятно, будет зависим от платформы. API NSDrawer концентрируется на предметной области секции, а не на ее границе или кадре.

Методы доступны, чтобы создать секцию, предоставить ее довольное представление и предпочтительный край, и связать ее с родителем:
- (id)initWithContentSize:(NSSize)contentSize preferredEdge:(NSRectEdge)edge;
- (void)setParentWindow:(NSWindow *)parent;
- (NSWindow *)parentWindow;
- (void)setContentView:(NSView *)aView;
- (NSView *)contentView;
- (void)setPreferredEdge:(NSRectEdge)edge;
- (NSRectEdge)preferredEdge;
Обратите внимание на то, что родительское окно сохранит секцию, и не наоборот. Секция может быть разъединена с любым родителем путем установки его родительского окна в ноль, но в этом случае секция должна была бы быть явно сохранена, если это все еще необходимо. Кроме того, секция без родителя не может быть открыта. Если setParentWindow: отправляется в секцию, не закрывающуюся, изменение вступит в силу только, когда будет затем закрыта секция.

Методы также предоставлены, чтобы открыть или закрыть секцию и установить ее состояние:
- (void)open;
- (void)openOnEdge:(NSRectEdge)edge;
- (void)close;
- (NSDrawerState)state;
- (NSRectEdge)edge;
Методы предоставлены, чтобы установить размер секции или установить минимальные и максимальные размеры для него, но они не переопределяют правило, что секция не может быть больше, чем ее родитель.
- (void)setContentSize:(NSSize)size;
- (NSSize)contentSize;
- (void)setMinContentSize:(NSSize)size;
- (NSSize)minContentSize;
- (void)setMaxContentSize:(NSSize)size;
- (NSSize)maxContentSize;
Открытая секция присоединяется точно к надлежащему краю ее родительского окна, но ее позицией и размером вдоль того края можно управлять, относительно предметной области его родителя, с продвижением и запаздывающим смещением. Если эти параметры не будут установлены, то значения по умолчанию будут предоставлены, которые подходящие для текущего стиля интерфейса. Эти смещения могут не быть отрицательными.
- (void)setLeadingOffset:(float)offset;
- (float)leadingOffset;
- (void)setTrailingOffset:(float)offset;
- (float)trailingOffset;

Панель шрифта

Пользовательский интерфейс Панели Шрифта был значительно улучшен в этом выпуске. Панель теперь имеет три области (Шрифты, Избранное, Наборы Редактирования).

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

Представление Edit Collections позволяет пользователю выбирать набор, просматривать его элементы, и добавлять или удалять элементы с <кнопки <and>>. Пользователи могут также создать новые наборы или удалить существующие наборы.

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

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

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


Приложение

В немного отличающееся время теперь отправляется NSApplicationDidFinishLaunchingNotification. Обработка открытия или печати файлов или открытия документа без названия во время запуска приложения раньше обрабатывалась до основного цикла событий запуск. Поскольку AppleEvents для 'oapp', 'odoc', и 'pdoc' получены через основной цикл событий как первое событие, когда приложение начинает работать, если мы отправим NSApplicationDidFinishLaunchingNotification прямо прежде, чем ввести основной цикл событий, то то уведомление произойдет, прежде чем документы открыты. Для предотвращения этого уведомление теперь сразу отправляется после обработки 'oapp', 'odoc', или 'pdoc' событие во время первого проходит через цикл.

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


Документ модальные панели

Mac OS X представляет понятие документа модальные панели («листы»). Модальная панель документа вызывает документ, к которому она относится для ввода модального состояния, не помещая целое приложение в модальное состояние. Документ модальная панель упоминается как лист и имеет специальное появление и ведет себя, как будто это было присоединено к окну документа. API был добавлен для поддержки создания документа модальные панели.

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


SavePanel

Существует новый метод, позволяющий панели сохранения быть представленной как лист.

Обратите внимание на то, что, если Ваша предварительная вода может быть проблема с начальным расположением некоторых элементов в панели, размер панели сохранения по умолчанию был очень маленьким. Можно удалить старый сохраненный размер по умолчанию путем ввода следующего в Терминале для сброса к начальному размеру по умолчанию:
defaults delete NSGlobalDomain "NSWindow Frame NXSavePanel"

Меню

Реализация меню изменилась решительно; NSMenuView и NSMenuItemCell больше не используются, - [NSMenu menuRepresentation] теперь возвращает ноль, и оторвите меню, больше не доступны. Для Предварительного просмотра Разработчика 3, нет никакой поддержки изображений пункта меню. Если не будет никакого текста в пункте меню, то текст заполнителя, состоящий из» <изображения>» или» <названия картинки>», будет вставлен вместо этого. Изображения состояния пункта меню не поддерживаются или и в их месте стандартный флажок или тире для на и смешались, состояния используются.


Миниатюризация прикрепления

На Mac OS X, миниатюризируя окно заставляет миниатюру окна появляться в прикреплении. При вызове - [NSWindow миниатюризируют:] заставит целевое окно анимировать (джин) в миниатюру, и - [NSWindow deminiaturize:] повторно развернет окно. Заголовок миниатюры должен быть кратким, и установлен путем вызова - [NSWindow setMiniwindowTitle:]. Если миниатюру не назвали через setMiniwindowTitle: сокращение заголовка окна будет использоваться.

В DP3 операции, включающие прикрепление, могут заставить runloop быть повторно введенным способами, которыми не ожидает Ваше приложение (например, таймеры могли бы стрелять). Эти операции включают - [NSWindow setMiniwindowTitle:], - [NSWindow setTitle:] (если Вы явно не вызываете setMiniwindowTitle:), - [NSWindow миниатюризируют:], и - [NSWindow deminiaturize:]. Мы будем смотреть на способы предотвратить эту повторную входимость в будущем, но на данный момент Вы, возможно, должны охранять против него.


Непрерывные проверки правописания

В NSTextView.h существует три новых метода:
- (void)setContinuousSpellCheckingEnabled:(BOOL)flag;
- (BOOL)isContinuousSpellCheckingEnabled;
- (void)toggleContinuousSpellChecking:(id)sender;
Они включают и выключают непрерывную проверку правописания (поскольку Вы вводите). Кроме того, контекстное меню NSTextView позволит Вам исправлять выбранное слово с ошибками. В NSSpellChecker.h существует также новый метод:
- (NSArray *)guessesForWord:(NSString *)word;
Это предоставляет программируемый доступ к списку предложенных исправлений для пообещанного.


Поле

Существует новый NSBoxType, переопределяющий существующие типы границы.
typedef enum {
NSBoxPrimary= 0,// default
NSBoxSecondary = 1,
NSBoxSeparator = 2,
NSBoxOldStyle = 3 // use border type
} NSBoxType;
По умолчанию новый NSBox имеет тип поля NSBoxPrimary. Если типом поля является NSBoxSeparator, то линия разделителя проведена центрируемая в поле, параллельном самой длинной стороне. Если стилем поля является NSBoxOldStyle, то тип границы используется вместо этого. Во всех случаях, если типом границы является NSNoBorder, не нарисовано никакое поле.
- (void)setBoxType:(NSBoxType)boxType;
- (NSBoxType)boxType;

Окно

Существует новый API для включения и выключения теней на на основание окна:
- (void)setHasShadow:(BOOL)hasShadow;
- (BOOL)hasShadow;
Изменение теневого состояния сразу влияет на окно. Можно также переопределить hasShadow. Значение по умолчанию - то, что все окна кроме безграничных имеют тень.


Цвет образца

NSColor теперь содержит поддержку шаблонных цветов, сделанных из NSImages:
+ (NSColor *)colorWithPatternImage:(NSImage*)image;
- (NSImage *)patternImage;
NSImage сохраняется цветом образца.

Существует также новое цветовое пространство, NSPatternColorSpace, для соглашений с этой функцией.

Образец всегда выровненный к нижней части окна. Используйте вызов CoreGraphics CGSetHalftonePhase () для изменения фазы образца.

Система NSColors еще не поддерживает образцы, используемые Водой. Однако новая функция была добавлена для рисования образца фона окна Воды. Можно использовать это для пользовательских элементов управления так, чтобы управление не должно было быть прозрачным:

недействительный NSDrawWindowBackground (NSRect aRect);

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


Оттенки управления

Можно указать, имеют ли NSCell, NSTabView и NSScroller крашеное или ясное появление, когда окно активно. В настоящее время допустимые оттенки, определенные в NSCell.h:
typedef enum _NSControlTint {
NSDefaultControlTint = 0,// system 'default'
NSClearControlTint = 7
} NSControlTint;
Новые методы в этих трех классах:
- (void) setControlTint:(NSControlTint)controlTint;
- (NSControlTint)controlTint;

Автопрокрутите при перетаскивании

NSClipView теперь реализует автопрокрутку при перетаскивании. Когда курсор сохранен в 5 пикселях от краев в течение 0,3 секунд, автопрокрутка запускается.


SplitView

Появление NSSplitView изменилось; горизонтальные разделения нарисованы прозрачные со средством захвата с двумя строками в центре. Вертикальные разделения в настоящее время рисуются абсолютно прозрачные; это, как ожидают, изменится перед заключительным выпуском MacOS X. Кроме того, существует новый API на NSSplitView для изменения горизонтального появления представления разделения от прозрачной версии, замеченной в Панели Шрифта к пузырившемуся, непрозрачному один замеченный в Почте. Новые методы являются-setIsPaneSplitter: и-isPaneSplitter; пузырившееся, непрозрачное появление является появлением разделителя области (т.е. представление разделения, используемое Почтовыми возвратами YES от isPaneSplitter).

Интерфейсный Разработчик позволяет, Вы для выбора между двумя типами разделителя через разделение просматриваете инспектора.

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


NSUserInterfaceValidation

Этот новый протокол определяет универсальный и стандартный механизм проверки пользовательского интерфейса. В настоящее время NSMenuItem является единственным клиентом этого протокола. См. комментарии в NSUserInterfaceValidation.h для подробных данных.


Документ

Новый метод, названный noteNewRecentDocument: был добавлен к NSDocumentController. Этот метод подобен noteNewRecentDocumentURL: за исключением того, что экземпляр NSDocument передается ему. Реализация по умолчанию получает URL из документа и вызывает noteNewRecentDocumentURL:. Этот новый метод всегда вызывается NSDocument вместо noteNewRecentDocumentURL: и это было добавлено для обеспечения, лучшая точка переопределения для NSDocument базировала приложения, хотящие иметь возможность упустить некоторые документы из списка recents. Принятие этого решения на основе экземпляра NSDocument часто более удобно, чем необходимость базировать его на URL.

Не находящиеся в NSDocument приложения могут и должны все еще вызвать noteNewRecentDocumentURL: получить недавнюю функцию документов их приложений.


BezierPath

Методы NSBezierPath appendBezierPathWithPackedGlyphs: и drawPackedGlyphs:atPoint: теперь реализованы.


Строковое получение

NSParagraphStyleAttributeName теперь делает корректную вещь независимо от flippedness фокусируемого представления.


StatusBar

Из-за изменений UI элементы строки состояния больше не рисуются на экране в Предварительном просмотре Разработчика 3 даже при том, что не изменился API. Замена будет сделана доступной в последующей версии.


TableView

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



Отмечает определенный для Предварительного просмотра Разработчика Mac OS X 2

Платформа какао

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

Одна из этих платформ зонтика является Cocoa.framework, в настоящее время включающим AppKit, и Основа, но в будущем будет расширена для включения платформ сценариев.

Другими платформами зонтика является Углерод, ApplicationServices (общие службы уровня UI), CoreServices (CoreFoundation, CarbonCore и другое общее обслуживание без UI), и Система (Posix, BSD и Мах APIs).


Упаковка приложения

Новая структура пакета приложений обрисована в общих чертах в информации о версии CFBundle/CFPlugIn. Старая структура будет продолжать работать, но рекомендуется преобразовать приложение в новую структуру, поскольку это - формат, на который сначала проверяет NSBundle при поиске ресурсов.

В DP2, на «делают установку», make-файлы Разработчика Проекта все еще создадут пакет старого стиля. Однако можно добавить следующий к Makefile.preamble, чтобы заставить модернизированный пакет быть созданным:
BUNDLE_STYLE = MACOSX
Это заставит сценарий/System/Developer/Makefiles/pb_makefiles/convertBundle быть выполненным в конце, «делают установку» для преобразования пакета приложения приложения в новый стиль. Обратите внимание на то, что, если Вы работаете, «делают установку» как сами и не как корень, этот сценарий мог бы перестать работать.

Если Ваш пакет приложений должен работать над X-сервером MacOS, или у Вас есть некоторый код, роющийся в обертке приложения, не проходя через NSBundle или APIs CFBundle, Вы не могли бы быть в состоянии переключиться на новый формат сразу.


Приложение и значки документа

В DP2 Средство поиска ожидает приложение и значки документа в формате ICNS. TIFF не работает. Следующее описывает шаги, должен был создать версии ICNS Ваших значков и получить их включенный в Ваш проект.

Обратите внимание на то, что необходимо сделать это только для значков, выведенных на экран Средством поиска. Большинство изображений TIFF в Вашем приложении не должно быть преобразовано.

Можно использовать инструмент,/usr/bin/tiff2icns для преобразования значков TIFF в формат ICNS. ICNS, как TIFF, поддерживает многократные форматы в одном файле, и преобразование должно сохранить все изображения в TIFF, в дополнение к созданию 1-разрядной маски хита, которой требует Средство поиска.

Если TIFF не будет иметь 32 x 32 форматами, инструмент сократит 48 x 48 изображений в TIFF к 32 x 32. Если TIFF имеет 16 x 16 изображений, и это более глубоко, чем 48 x 48, инструмент мог бы принять решение развернуть тот вместо этого. Если Вы замечаете, что 32 x, 32 изображения в ICNS являются расплывчатыми (который будет иметь место, если это масштабировалось от 16 x 16), Вы могли бы хотеть извлечь 48 x 48 значков в его собственный файл TIFF и затем сделать преобразование. Можно использовать «tiffutil - информация» для перечисления изображений в TIFF и «tiffutil - выдержка» для извлечения корректной.

Как только у Вас есть свои файлы ICNS, добавьте их к своему проекту приложения как нелокализуемых (или локализуемый, если они должны быть локализованы), ресурсы. Затем в инспекторе ProjectBuilder проекта перейдите к панели «Project Attributes». Удалите все расширение / пары имени значка, поскольку они не используются больше. Не удаляйте запись для «значка приложения»; это изображение все еще используется [NSImage imageNamed:@ «NSApplicationIcon»] в качестве значка для Вашего приложения в Вашем приложении.

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

Для Вашего значка приложения просто включайте запись для CFBundleIconFile. Для каждого типа документа поддержки приложений включайте запись в массив CFBundleDocumentTypes. Если Ваши поддержки приложений никакие документы, помещенные пустой массив здесь.

Можно смотреть на файл TextEdit CustomInfo.plist (/System/Developer/Examples/AppKit/TextEdit/CustomInfo.plist) как выборка. TextEdit объявляет четыре типов документов; 3 из которых это может отредактировать, один из которых (HTML) это может просто просмотреть.

Информация о версии InfoPlist имеет больше подробных данных о различных ключах и их значениях.


InterfaceBuilder

IB теперь поддерживает NSTableView и NSOutlineView. См. информация о версии InterfaceBuilder для большего количества информации.


Документ / DocumentController

Теперь проще разделить NSDocumentController на подклассы путем инстанцирования подкласса в основном пере. У интерфейсного Разработчика есть определенные проблемы в тестовом режиме интерфейса, если Вы используете такой подкласс, но они являются косметическими.

-readFromFile NSDOCUMENT: теперь символьные ссылки решений в имени файла.

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

NSWindowController является теперь подклассом NSResponder. Это - двоичный файл и источник совместимое изменение и для Objective C и для Java. Кроме того, и NSWindowController автоматически устанавливает себя как-nextResponder его окна. То, что это означает, - то, что подкласс NSWindowController может реализовать методы респондента как keyDown: и получите их, как любой респондент в цепочке обычно был бы.


Недавние документы

Поддержка меню «Open Recent» была добавлена. NSDocument базировался, приложения получат это новое меню автоматически. Приложения Non-NSDocument должны будут добавить это меню и вызвать noteNewRecentDocumentURL NSDocumentController: метод, чтобы заставить элементы появляться в нем.


QuickDrawView

Новое зеркально отраженное, ненепрозрачное представление было добавлено к Какао, которое позволит Вам рисовать Углерод использования QuickDraw. Каждый раз, когда lockFocus обращается к представлению, сделан (такой как как раз перед - [NSQuickDrawView drawRect:]), QuickDraw CGrafPort будет создан и установлен. Кадр порта отражает видимые границы представления и может измениться между вызовами. Можно получить CGrafPtr представления путем вызова - [NSQuickDrawView qdPort], хотя это только допустимо когда в lockFocus/unlockFocus. Также обратите внимание на то, что это создает CGrafPort для каждого представления.


ToolTips

NSView теперь способен к более сложному управлению подсказкой, начатому со следующих трех методов:
- (NSToolTipTag)addToolTipRect:(NSRect)aRect owner:(id)anObject userData:(void *)data;
- (void)removeToolTip:(NSToolTipTag)tag;
- (void)removeAllToolTips;
Если NSView обнаруживает, что прямоугольник подсказки был активирован, это отправляет владельцу следующий метод для получения строки для отображения:
- (NSString *)view:(NSView *)view
stringForToolTip:(NSToolTipTag)tag
point:(NSPoint)point
userData:(void *)data;
Кроме того, NSMatrix теперь поддерживает подсказки на ячейку:
- (void)setToolTip:(NSString *)str forCell:(NSCell *)cell;
- (NSString *)toolTipForCell:(NSCell *)cell;

TableView

Новый метод, dataCellForRow: был добавлен к NSTableColumn для управления, ячейка раньше рисовала фактические значения в табличном представлении. NSTableView теперь всегда вызывает dataCellForRow: который, значением по умолчанию просто вызывает метод dataCell. Подклассификаторы могут переопределить это, если они должны потенциально использовать различные ячейки для различных строк. Подклассификаторы должны быть подготовлены обработать строку ==-1 в случаях, где никакая фактическая строка не включается, но табличное представление должно получить некоторую универсальную информацию ячейки.


Углерод

Все приложения Какао теперь вводят библиотеки Carbon, что означает, что общедоступные символы в этих библиотеках появляются в том же пространстве имен как приложение. Большинство общедоступных символов в Углероде не использует префиксы, который позволяет там быть конфликтами символа. Решение этого состоит в том, чтобы избежать конфликтов путем переименования символов.


Производительность

Из-за больших базовых изменений в системе начиная с X-сервера MacOS возможно, что некоторые проблемы производительности были введены в Ваше приложение. Большинство из них находится в базовых библиотеках и системе, и будет адресоваться для заключительного выпуска. (Примеры этого включают чрезмерное выделение памяти и инициализацию библиотек и ресурсов во время запуска.). Однако способ, которым Ваше приложение делает вещи (ищут ресурсы, пересеките файловую систему, и т.д.) мог бы также вызывать некоторые дополнительные проблемы, которые могло бы быть просто точно определить и исправить. Можно использовать Сэмплер, MallocDebug или другие инструменты для проверки на проблемы.


Службы

Теперь работают службы, главным образом поврежденные в DP1.


GraphicsContext

NSGraphicsContext теперь имеет методы для сохранения текущего состояния графики на основе на поток.


ClipView и ScrollView

NSClipView и NSScrollView оба поддерживают возможность обеспечить прозрачный фон (как в стандарте о поле) через новый setDrawsBackground: метод.


Область монтажа

Формат для списков свойств на области монтажа изменился снова; это могло бы повредить код, делающий предположения об этом формате. Например, код, читающий NSString из области монтажа с помощью dataForType: и попытки десериализовать его вручную теперь повреждаются. См. примечания DP1 (ниже) для большего количества подробных данных.


Упорядочивание окна и активация

NSWindow больше не активирует главное окно, когда ключевое окно закрывается, если главное окно не наверху z-порядка окна приложения. Следующее окно в z-порядке, который готов быть ключевым, активируется. Большинство людей не должно замечать различие.

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

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


StatusBar

Элементы строки состояния с меню, имеющими подменю теперь, работают правильно (т.е. подменю появятся и отследят должным образом).


Звук

В DP2 может теперь играть NSSound, распаковал звуковые файлы AIFF, а также распаковал звуки в форматах WAV и NeXT/AU.

В Сервере Mac OS X NSSound раньше был в состоянии играть сжатые звуковые файлы СТИЛЯ NEXT; они больше не поддерживаются.


Текст

NSTextView кэшировал атрибуты ввода от предыдущего запоминающего устройства, когда это было сцеплено до нового запоминающего устройства. Это было фиксировано.

NSTextStorage теперь имеет возможность фиксировать атрибуты лениво; три новых метода были добавлены, чтобы поддерживать эту функцию.

Метод fixesAttributesLazily должен быть переопределен в конкретных подклассах, которые могут сделать это для возврата YES. В абстрактном суперклассе NSTextStorage этот метод возвращается НЕТ; но конкретный подкласс NSTextStorage по умолчанию возвращает YES.

processEditing теперь вызывает invalidateAttributesInRange:. Если текстовое хранение не лениво, это просто вызывает fixAttributesInRange: вызывая вещи произойти как прежде. Если текстовое хранение лениво, это вместо этого просто записывает фиксацию необходимости диапазона.

ensureAttributesAreFixedInRange: должен быть вызван в текстовом хранении, которое лениво, чтобы гарантировать, что атрибуты фиксируются в определенном диапазоне. Подклассы NSTextStorage, хотящие поддерживать лень, должны вызвать ее от всех средств доступа атрибута, которые они реализуют. Конкретный подкласс по умолчанию NSTextStorage вызывает это от своих средств доступа, чтобы гарантировать, чтобы клиенты всегда видели непротиворечивое представление атрибутов.


RTF

Читатель RTF теперь поддерживает значения кодирования MacOS для \fcharsetN. Это может теперь считать любое кодирование, поддерживаемое в RTF1.5. Протестированный против AppleWorks, Word97 на NT, Word98 на MacOS, WordPad на NT, X-сервере MacOS и OPENSTEP 4.2 генерировали файлы RTF, содержащие Latin1 и японские символы. Кроме того, читатель RTF теперь поддерживает строковые директивы RTF1.5 Unicode \uN и \ucN.

Писатель RTF теперь использует очень подобную схему кодирования для Word9x. Это кодирует в кодировании шрифта, предоставляющем максимальной совместимости других читателей RTF. Как результат, это кодирует latin1 символы в Макосромене на MacOS и WindowsLatin1 на Windows.

Это изменение делает файлы RTF сгенерированными на MacOS несовместимый с OPENSTEP 4.x, где символы неASCII включаются, так как не было никакого декодера Макосромена на OS. Можно вынудить читателя генерировать в кодировках Microsoft значением по умолчанию установки NSRTFWriteOpenStepCompatibleEncodings к YES.

С NSRTFWriteOpenStepCompatibleEncodings == НИКАКОЙ (значение по умолчанию), сгенерированные файлы с латинским 1 символом были успешно загружены в Работы Apple, Word97 на NT, Word98 на MacOS и TextEdit на X-сервере MacOS. К сожалению, файлы RTF с японским языком не загружаются правильно в TextEdit на X-сервере MacOS, не распознававшем японский индикатор набора символов.

С NSRTFWriteOpenStepCompatibleEncodings == ДА, сгенерированные файлы были успешно считаны TextEdit на X-сервере MacOS, WordPad на NT и TextEdit на OPENSTEP 4.2, в дополнение к вышеупомянутому.


Перетаскивание

Какао, Углерод и Классика все двигают общий уровень для перетаскивания, и в DP2, перетаскивающем единственный файл между работами Какао и Углерода. Однако существуют все еще некоторые ошибки.

Перетаскивание к и от локальной области монтажа не работает. Метод протокола NSDraggingInfo-draggingPasteboard будет всегда возвращать область монтажа под названием NSDragPboard, таким образом, место назначения не сочтет альтернативную область монтажа используемой источником.

Метод протокола NSDraggingInfo draggedImageLocation отразит смещение изображения от текущего расположения мыши, только если источник и место назначения перетаскивания являются тем же приложением. Если перетаскивание будет от одного приложения до другого, то draggedImageLocation возвратит текущее расположение мыши, игнорируя любое смещение образа.


Прерывание модального сеанса

Для остановки модального сеанса от NSTimer или задержанного исполнителя, необходимо вызвать - [NSApplication abortModal]. - [NSApplication abortModal] теперь отправляет событие NSAppKitDefined в приложение вместо того, чтобы повысить NSException, и это возвратится к вызывающей стороне.


MovieView

NSMovieView не работает в DP2.


ScrollView

Удержание/вниз кнопки на скроллере заставляют скорость прокрутки увеличиваться в течение долгого времени путем увеличения числа строк, прокручивающихся за один раз. Это не должно вызывать несовместимости.

Скроллером по умолчанию кнопки являются теперь отдельными; если Вы хотите свои стрелки вместе, можно установить значение по умолчанию NSScrollerHasSeparateArrows в НЕ.


Printing & View Print API

Печать поддержки в AppKit прошла через крупные изменения. Машинное оборудование печати теперь сцепляется в диспетчер печати Тиога; NSPrintPanel и NSPageLayout используют реализации Углерода, предоставленные Тиога; и печать NSVIEW имела отношение, API упрощен, потому что это оригинальный проект стремилось поддерживать Соглашение Структурирования документов Adobe.

NSView теперь имеет возможность генерации PDF через следующие методы, работающие их дубликатами EPS:
- (void)writePDFInsideRect:(NSRect)rect toPasteboard:(NSPasteboard *)pb;
- (NSData *)dataWithPDFInsideRect:(NSRect)rect;
Вместо многократных точек входа, потребовавшихся, чтобы поддерживать Adobe DSC, NSView теперь получает только следующие пять сообщений во время работы печати:
- (NSString *)printJobTitle;
- (void)beginDocument;
- (void)endDocument;
- (void)beginPageInRect:(NSRect)r atPlacement:(NSPoint)loc;
- (void)endPage;
Поскольку NSPrintPanel и панели Carbon использования NSPageLayout, все переменные экземпляра, объявленные для классов, никогда не инициализируются, и приложения не должны получать доступ ни к одной из переменных.


StringDrawing

drawInRect: варианты NSStringDrawing API теперь правильно обеспечивают отсечение, и получение появляется в правильном месте независимо от зеркально отраженного мыса фокусируемого представления.


Поле, ScrollView и ClipView

Отправляя removeFromSuperview сообщение в представление содержания/документа NSBox, NSScrollView и NSClipView правильно очистят их соответствующий ivars.
NSBox *myBox;
NSBox *srcBox1;
NSBox *srcBox2;
[myBox setContentView:myViewIsInBox1 ? [srcBox1 contentView] : [srcBox2 contentView]];
Вышеупомянутый пример работал, так как srcBox1 и srcBox2 всегда имел указатель на их представления содержания, нетронутые методом-removeFromSuperview, вызванным вызовом-setContentView: с myBox. Теперь,-contentView ноль возвратов метода во второй раз вышеупомянутый код выполнялся, так как указатели представления содержания в обоих srcBox очищены setContentView:.


Меню

После Предварительного выпуска 2 реализация NSMenu и NSMenuItem изменится для нахождения поверх менеджера по Меню Углерода, подобного реализации Windows меню Cocoa. Это означает, что Вы не должны предполагать, что существует NSMenuView или NSMenuItemCell позади NSMenu или NSMenuItem соответственно. Использование набора изображений - [NSMenuItem setOnStateImage], - [NSMenuItem setOffStateImage], и - [NSMenuItem setMixedStateImage] будет все еще поддерживаться, как будет, устанавливая шрифт для кнопок всплывающего меню.


Шрифты

Какао и Углерод в настоящее время не используют тот же набор шрифтов как CoreGraphics, и QuickDraw еще не пользуются той же базовой библиотекой для текстового рендеринга. Это будет скоро исправлено.

См. DP1 отмечает Шрифтом (ниже), чтобы заставить новые шрифты появляться в приложениях Какао для тестирования.


Удаленные значения по умолчанию

Некоторые значения по умолчанию, которые больше не необходимы, были удалены, вместе с поддержкой регистрации их в домене по умолчанию:

- Факс связал значения по умолчанию
- NSCachedColorConversion (раньше был YES; теперь это всегда происходит),
- NSDrawUsingGradients (раньше был НЕ),
- NSObjectLinkUpdateMode (раньше был 2),
- NSMiniaturizeAnimationRate (раньше был пробелом),
- NSPSName (раньше был пробелом),
- NSMenuX, NSMenuY (0.0, 1000000.0)



Отмечает определенный для Предварительного просмотра Разработчика Mac OS X 1

AppKit включает следующие новые функции и изменения начиная с X-сервера MacOS. В некоторых случаях примечания ниже могли бы быть лишены законной силы изменениями в MacOS X Предварительных просмотров Разработчика 2, упомянуты выше. Также обратите внимание на то, что для примечаний, имеющих отношение к DP1 и ранее, мы используем термин «Желтое Поле» для обращения к Какао.


Графика

MacOS X не включает PostScript Дисплея; вместо этого, графическая функциональность для Желтых приложений предоставлена через новую платформу клиентской стороны под названием CoreGraphics.

Одна импликация этого - то, что PostScript функционирует, и код генерировал использование pswrap, больше не будет работать. В Предварительном выпуске Разработчика некоторый PSxxx () функции все еще поддерживаются для совместимости на уровне двоичных кодов, но их использованию в новом коде высоко обескураживают, так как их функциональность не может быть точно эмулирована поверх CoreGraphics, и они будут удалены в будущем выпуске. Вместо этого используйте NSBezierPath или различные другие классы получения в AppKit или функции, объявленные в NSGraphics.h или CoreGraphics API непосредственно.

Следующие функции были добавлены к NSGraphics.h. Они должны использоваться вместо PScompositerect ():
void NSRectFillUsingOperation(NSRect aRect, NSCompositingOperation op);
void NSRectFillListUsingOperation(const NSRect *rects, int count, NSCompositingOperation op);
void NSRectFillListWithColorsUsingOperation(const NSRect *rects, NSColor **colors, int num, NSCompositingOperation op);
Они эквивалентны non-NSCompositingOperation версиям за исключением того, что они устанавливают составляющую композит работу прежде, чем заполнить прямоугольники. Все режимы составления композита кроме NSCompositeHighlight поддерживаются.

Следующие функции в настоящее время без операций в секунду:

NSDottedFrameRect

Следующие функции больше не должны использоваться и могут возвратить фиктивные значения:

NSHighlightRect, NSCopyBitmapFromGState, NSGetWindowServerMemory

Составляющий композит режим NSCompositeHighlight больше не поддерживается ни для какой функции. Используя его для операции рисования приведет к использованию NSCompositeSourceOver вместо этого.

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

Текст также сглаживается выше размера определенного момента (в настоящее время 16 ПБ). В Предварительном выпуске Разработчика это значение можно настроить с пользовательским значением по умолчанию (см. обсуждение Шрифта ниже).

Строки нулевой ширины в настоящее время ничего не рисуют. В PostScript это раньше проводило самую тонкую линию для устройства.

Наконец, «-NSHost» параметр командной строки больше не поддерживается.


DPSContext

Перед MacOS X, был объект NSDPSContext, обернувший дескриптор DPSContext который, в свою очередь, представленный и соединение приложения с WindowServer и графический контекст. Объект NSDPSContext инстанцировала платформа автоматически во время запуска приложения, и только необходимо было иметь дело с экземпляром кроме определенных ситуаций (т.е. приложение было многопоточно, или явно контакт с работой печати). «Текущий» NSDPSContext был довольно предсказуем начиная с экземпляра, создававшегося во время запуска, было всегда текущим и активным, если Ваше приложение не было посреди печати. Это не истина в MacOS X, с одной стороны, NSDPSContext был удален. (К сожалению, заголовочные файлы все еще оставили в выпуске, но они не должны быть импортированы. Они не импортируются автоматически AppKit.h больше.)

AppKit теперь только представляет абстрактный суперкласс NSGraphicsContext, который автоматически инстанцируют для каждого NSWindow. Кроме того, NSWindow инстанцирует дополнительных объектов NSGraphicsContext для каждого рисующего вторичного устройства потоки по мере необходимости. lockFocus метод NSVIEW устанавливает графический текущий контекст своего окна, в дополнение к установке текущей системы координат и отсечению состояния.

Большинство операций на NSDPSContext теперь или не необходимо или должно быть выполнено на NSGraphicsContext.

По большей части, принцип реализации drawRect: метод является все еще тем же. К тому времени, когда Ваш пользовательский класс NSView получает drawRect: платформа уже установила контекст получения для Вас. Только необходимо вызвать функции получения в методе, и платформа удостоверяется, что получение появляется в желаемом представлении. Можно или использовать собственное получение AppKit API (NSBezierPath, NSImage и методы рисования NSSTRING) или вызвать функции CoreGraphics непосредственно. Можно запросить дескриптор CGSContextRef для текущего графического контекста [[NSGraphicsContext currentContext] graphicsPort]. Ваш drawRect: метод хотел бы:
- (void)drawRect:(NSRect)rect {
CGSContextRef cgContext = [[NSGraphicsContext currentContext] graphicsPort];
// Construct path (line from 10.0/10.0 to 100.0/100.0
CGMoveTo(cgContext, 10.0, 10.0);
CGLineTo(cgContext, 100.0, 100.0);
// Set stroke color to white
CGSetGrayStrokeColor (cgContext, 1.0, 1.0);
// Stroke
CGStroke (cgContext);
}
Как Вы видели до сих пор, основной принцип получения остается тем же. lockFocus/unlockFocus пара метода устанавливает среду получения, и Вы вызываете функции получения. Но, базовое значение текущего графического контекста изменяется. Различие полностью содержится в lockFocus методе. lockFocus метод теперь выполняет следующие операции:

1) Вызовы + [NSGraphicsContext setCurrentContext:] с контекстом для окна представления. Это создает новый контекст для подпотоков, если у них еще нет того.

2) Сохраняет текущее состояние графики путем вызова - [NSGraphicsContext saveGraphicsState]. Обратите внимание на то, что PSgstate раньше сохранял текущее устройство окна, но saveGraphicsState метод не делает, так как каждый объект NSGraphicsContext не знает о контекстах для других окон.

3) Устанавливает систему координат и отсекающий состояние путем вызывания функций CoreGraphics.

Обратите внимание на то, что, в то время как это раньше работало, обычно, вызывало currentContext или saveGraphicsState за пределами фокусируемой ситуации, это обязательно больше не имеет место.


Изображение

Были исправлены несколько ошибок с GIF и обработкой JPEG.

8-разрядный индексируемый TIFFs не работает в этом выпуске; необходимо будет преобразовать их в RGB перед использованием их.


Шрифт

Шрифты PostScript не поддерживаются в Предварительном просмотре Разработчика, и API, определенный для них, больше не доступен (подробные данные ниже). Единственный формат файла шрифтов, в настоящее время поддерживаемый, является «.TTF» файлом.

Раньше, шрифты были найдены в/System/Library/Fonts и других расположениях. Эти расположения не ищутся в этом выпуске. Информация о семье и поверхности, относящаяся к NSFontPanel, все еще сохранена в/System/Library/Fonts/.default.fcache, но каталог иначе пуст.

Шрифты конечного пользователя и установленные шрифты приложения не поддерживаются в этом выпуске. Платформа CoreGraphics ищет шрифты TrueType только в одном расположении,/System/Library/Frameworks/CoreGraphics.frameworks/Resources.

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

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

Система NSText использует ограничительный прямоугольник шрифтов для определения высоты строки по умолчанию. В будущем это, вероятно, изменится. Один эффект использования ограничительного прямоугольника состоит в том, что в этом выпуске, все высоты строки потенциально изменились от того, чем они были, когда представлено со шрифтами PostScript. Это влияет на некоторые файлы NIB, использующие поля многострочного текста фиксированной высоты: строки около нижней части поля могут быть частично отсечены. Высоты строки в текущем наборе системных шрифтов иногда немного более высоки, чем в шрифтах PostScript с теми же именами вследствие отличающихся дополнений глифа шрифтов. Различие особенно примечательно с семьей Helvetica. Разработчики могут хотеть проверить свои файлы NIB на поля многострочного текста фиксированной высоты и изменить размеры их с новыми шрифтами в подходящих случаях.

Метод afmDictionary делается устаревшим. В этом выпуске это возвращает ноль.

Метод afmFileContents является устаревшим и больше реализован.

Устаревший метод ширин больше не реализуется. Раньше, этот метод возвратил массив 256 плаваний и был только полезен с «основными» шрифтами. Это осуждалось в течение нескольких лет.

Метод fontWithName:matrix: в то время как все еще поддерживается, не работает точно тем же способом в прошлом. Использование шрифта и текстовых матриц в CoreGraphics немного отличается от того, чем это было с PostScript. В частности этих двух координат перемещения в матрице NSFont только Y является фактически эффективным. Разработчики должны избегать использования этого метода, и вместо этого использовать fontWithName:size: если это возможно. В этом выпуске существует также недавно обнаруженная ошибка, вызывающая все шрифты, создаваемые через fontWithName:matrix: иметь неправильный размер. (Размер ошибочно умножается отдельно внутренне во время инициализации; это может работаться вокруг путем предоставления меньшего размера и предназначается, чтобы быть фиксированным в последующих версиях.)

Метод isBaseFont всегда возвращает YES для шрифтов TrueType.

capHeight и xHeight шрифта эвристическим образом определяются в текущей реализации, так как эти значения не универсально предоставлены шрифтами TrueType.

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

Метод NSFont glyphWithName: в настоящее время не реализуется в CoreGraphics и не возвратит корректные результаты.

Метод boundingRectForGlyph: имеет ошибку, где она откажет.

Использующие кернинг таблицы в настоящее время не поддерживаются CoreGraphics; следовательно использующая кернинг информация не доступна через методы NSFont в этом выпуске. (Т.е. все шрифты, кажется, не имеют никакого кернинга.)

Единственным глифом, упаковывающим фактически поддерживаемый в системе, является NSNativeShortGlyphPacking. Все шрифты, как предполагают, имеют векторы кодирования, представимые как интервал короткого целого без знака, система NSText только использует NSNativeShortGlyphPacking. Функция преобразования NSConvertGlyphsToPackedGlyphs () может все еще использоваться для получения других упаковок; но они больше не полезны ни с какими текстовыми системными компонентами.

Более старые понятия PostScript изменчивости кодирования шрифта и конфигурируемости постепенно сокращаются. Разработчики должны избегать использования методов mostCompatibleStringEncoding и encodingScheme. Вместо этого когда необходимо определить, доступен ли данный глиф, разработчики могут использовать метод glyphIsEncoded:. В дополнение к оказанию лучшей международной поддержки для сложного рендеринга сценария это предназначается в будущем, чтобы сделать «Unicode CMAP» доступный через API NSFont и использовать глиф каждого шрифта IDs непосредственно.

Метод widthOfString: осуждается и не должен использоваться; это предоставлено для обратной совместимости только. Этот метод только применим в случае, где все символы в строке, как известно, renderable со шрифтом получения во взаимно-однозначном соответствии между символами и глифами. Во всех других случаях это, как почти гарантируют, не отразит то, что фактически произойдет, когда строка будет представлена через текстовую систему. Кроме того, символы строки, которая не может быть представлена, как определено, когда этот метод вызывают, проигнорированы в вычислении ширины.

Использование ограничительного прямоугольника шрифта для определения высоты строки по умолчанию постепенно сокращается в пользу более типографским способом корректных понятий с помощью подъема шрифта, спуска, и «разрыва строки». Разработчики должны использовать новый метод defaultLineHeightForFont, когда они должны знать, как высокий они должны установить строки. В текущей реализации текстовой системы это не может последовательно применяться.

Программы buildafmdir и cacheAFMData являются устаревшими и больше поставлены. Они раньше использовались для создания форматов кэша шрифта, используемых более старыми системами NextStep до Версии 4.0 OpenStep. Они не использовались в недавних системах, но были сохранены для совместимости в сетях, комбинирующих машины со старыми и новыми операционными системами. Их файлы продукта, .fontdirectory и .fontlist, (в каждом каталоге библиотеки шрифтов) являются аналогично устаревшими. Эти файлы только используются машинами, выполняющими более ранние операционные системы, чем Версия 4.0 OpenStep.

Заменяющая программа является fcache для кэширования данных, используемых панелью шрифта. На этом выпуске fcache является только эффективным, когда выполняется администратором (корень) и только хранит информацию для шрифтов в расположении, описанном выше.

Предварительная сборка программ и screenafm являются аналогично устаревшими. Нет никаких замен. (Эти программы раньше использовались для обработки настроенных на руку битовых массивов в шрифтах PostScript.)

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

Как упомянуто выше, платформа CoreGraphics делает сглаженное получение. Поскольку сглаженные шрифты имеют тенденцию иметь меньше четких краев и могут вызвать проблемы с экранной удобочитаемостью в небольших размерах, реализация AppKit NSFont по умолчанию будет использовать сглаженные шрифты только в 16points и больше. В этом выпуске тем размером можно управлять через пользовательское значение по умолчанию NSMaxScreenFontSize. Для глобального уменьшения размера, в котором сглаженные шрифты являются используемым шрифтом выше 12 точек, например, пользователь может выполнить следующую командную строку:
defaults write NSGlobalDomain NSMaxScreenFontSize 12.0
Это говорит NSFont использовать сглаженные шрифты выше 12,0 точек глобально и использовать экранные шрифты до и включая 12,0 точек. Как с любым другим значением по умолчанию, это может быть ограничено определенным приложением путем замены доменом приложения, и приложения могут установить или зарегистрировать значение внутренне через NSUserDefaults.


FontPanel

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

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


BezierPath

Следующие функции рендеринга глифа в NSBezierPath не функциональны в Предварительном выпуске Разработчика:
- (void)appendBezierPathWithGlyph:(NSGlyph)glyph inFont:(NSFont *)font;
- (void)appendBezierPathWithGlyphs:(NSGlyph *)glyphs count:(int)count inFont:(NSFont *)font;
- (void)appendBezierPathWithPackedGlyphs:(const char *)packedGlyphs;

CStringText

NSCStringText, который был obsoleted в выпусках Developer X-сервера MacOS, был удален из системы. Необходимо использовать NSTextView вместо этого.

Если Вы разархивируете файлы пера, содержащие экземпляры NSCStringText, то Вы получите предупреждение, и экземпляр будет преобразован в NSTextView, сохраняя атрибуты, которые устанавливаемы через инспектора Интерфейсного Разработчика. Обратите внимание на то, что могли бы все еще быть проблемы с помощью того файла пера, если Вы отправляете этому методы экземпляра, только NSCStringText понимает. Необходимо заменить NSCStringText NSTextView в Интерфейсном Разработчике.


Звук

Воспроизведение звука в объектах NSSound было отключено для этого выпуска.


Предпочтения

Пользовательские значения по умолчанию (как сохранено NSUserDefaults и CFPreferences) теперь сохранены в каталоге Library/Preferences в домашней папке пользователя в XML-файлах. Один побочный эффект этого изменения состоит в том, что предпочтения X-сервера MacOS отличны от MacOS X предпочтений. В первый раз, когда Вы входите в систему MacOS X, MacOS, X предпочтений будут создаваться автоматически для Вас от Ваших предпочтений X-сервера MacOS. (Это могло бы занять до минуты.)


Удаленный запуск

Вы не можете запустить приложение AppKit от сеанса удаленного входа в систему, потому что это не соединится с Сервером Области монтажа вследствие ограничений безопасности. Обходное решение: от сеанса удаленного входа в систему можно сначала запустить удаленный экземпляр Сервера Области монтажа в фоновом режиме с:
  /System/Library/CoreServices/pbs -a &
Приложения, впоследствии запущенные от этого сеанса, соединятся с этим Сервером Области монтажа. Отметьте, однако, что не будет возможно скопировать и вставить или перетащить между приложениями, запустил этот путь и другие приложения, запущенные локально в целевой системе.


Сценарии

Поддержка AppleScript не функциональна в этом выпуске.


Документ

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

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

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

Существует новый initWithNibPath:owner: метод на NSWIndowController, позволяющем Вам указывать полный путь к файлу пера вместо просто имени. Это полезно, когда перо находится в нестандартном расположении (т.е. в том же пакете как класс, загружающий его).

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


Текст

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

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

Разбивка на страницы в недоступном для редактирования текстовом представлении больше не будет разбивать на страницы вниз.

Один новый метод был добавлен к классу NSSimpleHorizontalTypesetter для удобства подклассификаторов:
- (void)willSetLineFragmentRect:(NSRect *)aRect
forGlyphRange:(NSRange)aRange
usedRect:(NSRect *)bRect
Если реализовано подклассами, это вызывают в методе layoutGlyphsInHorizontalLineFragment:baseline: после разметки каждого фрагмента строки, и сразу прежде, чем вызвать setLineFragmentRect:forGlyphRange:usedRect: в NSLayoutManager для записи используемых прямоугольников фрагмента строки. Это предназначается для подклассов, чтобы быть в состоянии влиять, например, linespacing глобально. «Используемый» rect, как ожидают, будет меньшим, чем или равным «aRect».


PopUp, меню

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

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

Раскрывается теперь рисуют пунктирный ключевой индикатор представления, когда они - первый респондент на Windows.


Область монтажа

Формат сериализации, используемый для помещения списков свойств на области монтажа теперь, использует XML. Клиенты NSPasteboard, использовавшего setStringForType: и setPropertyListForType: незатронуты этим изменением. Клиенты, принявшие формат данных, были то, что используемый NSSerializer и использовал setDataForType: должен преобразовать в вышеупомянутые методы везде, где строки или списки свойств являются содержанием области монтажа. Формат сериализации, используемый областью монтажа, подвергается дальнейшему изменению. Чтобы быть изолированными от будущих изменений, используйте-setStringForType: и setPropertyListForType: везде, где строки или списки свойств являются содержанием области монтажа.

Копия и вставка между всеми приложениями (Желтое Поле, Углерод и Синее Поле), как ожидают, будут работать с помощью существующего NSPasteboard и Фрагмента и интерфейсов. Это не работает в этом выпуске. Преобразование типов между традиционным OpenStep и типами MacOS, как ожидают, будет присутствовать в будущем выпуске.


Перетаскивание

Нет никакой видимой пользователем обратной связи (изменение курсора) следующий из установки работы перетаскивания в ответ на методы протокола NSDragging, отправленные месту назначения перетаскивания. Перетаскивание между Углеродом и Желтыми приложениями также не работает в этом выпуске.


Службы

Службы для большинства приложений не доступны в меню служб в этом обновлении, поскольку make_services не удается посмотреть в каталогах, где живут приложения. Обходное решение должно выполнить make_services вручную; в окне оболочки сделайте:
make_services /System/Applications /System/Demos /System/Developer/Applications

MovieView

NSMovieView еще не функционален, поскольку QuickTime не доступен в Предварительном выпуске Разработчика.


Манипулирование окном

Вследствие изменений в подсистемах графического и управления окнами некоторые ошибки были представлены в манипуляциях окном:

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

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



Отмечает определенный для Сервера Mac OS X

AppKit включает следующие новые функции и изменения между Выпуском Developer 2 и X-сервером 1.0 MacOS. Обратите внимание на то, что в некоторых случаях примечания ниже могли бы быть лишены законной силы изменениями в MacOS X Предварительных просмотров Разработчика 1 и 2, упомянуты выше.


Сценарии

Сервер Mac OS X представляет поддержку scriptable Желтых приложений. Поддержку все еще считают бета качеством и предоставляют для разработчиков, чтобы начать подавать их scriptable заявки. См. информацию о версии сценариев и документацию для большего количества подробных данных. TextEdit и и Java и версия Objective C сценариев поддержки Эскиза и может использоваться в качестве примеров того, как реализовать сценарии в Желтом приложении.


ActiveX (только Windows)

Желтые платформы теперь имеют поддержку ActiveX при работе Windows. Дополнительную информацию см. в информации о версии ActiveX. Пример WebBrowser показывает, как использовать встраивание ActiveX.


Звук

Новый класс, NSSound, был добавлен к AppKit. Этот класс предлагает простые межплатформенные играющие звук возможности приложениям. Редактирование и запись звуков не поддерживаются, ни являются манипулированием звуковыми параметрами (объем, уехавший/исправленный относительно усиления, и т.д.). Понятые звуковые форматы являются законом, u-законом, 8-и 16-разрядными линейными кодировками без знака и со знаком Microsoft WAV и NeXT/Sun SND (AU) форматы. Эти форматы поняты на любой платформе.

NSButton и классы NSButtonCell имеют setSound: методы, которые могут использоваться для соединения звука с кнопкой.


MovieView

AppKit теперь включает NSMovieView, который может использоваться для игры фильмов в формате QuickTime. Это содержит достаточную функциональность для создавания приложения, такого как MoviePlayer, но не предоставляет полный доступ ко всему QuickTime APIs для создания содержания. Фильм всегда изменяется для заполнения целого представления, и представление может быть встроено в другое представление с надлежащим отсечением. Обратите внимание на то, что загрузка представления фильма занимает несколько секунд, сначала начиная загружать библиотеки QuickTime. Существует выдающаяся ошибка, заставляющая приложение отказывать, если представление изменено к нулевой ширине или высоте.


Совместимость на уровне двоичных кодов на Windows

Вследствие исправления ошибки во время выполнения Objective C, двоичные файлы от DR2 и ранее не будет работать на Желтом Поле для Windows 1.0. Эти приложения должны быть полностью перекомпилированы.


ColorSync поддерживают в NSBitmapImageRep

Словарь свойства в NSBitmapImageRep имеет ключ, объявленный в NSBitmapImageRep.h как NSImageColorSyncProfileData. Значение для этого ключа является профилем ICC.

В 1,0, исправление ColorSync изображений во время дисплея поддерживается на всей архитектуре. До 1,0 это только поддерживалось на PPC.

Кроме того, когда репутация растрового изображения превращена в представление TIFF, профиль ICC записан в представление размолвки. До 1,0, профили, встроенные в представления размолвки, только поддерживались во время чтения.

Если NSImage заменяет NSBitmapImageRep NSCachedImageRep, цветной синхронизирующий профиль используется и больше часть словаря свойства. Значения пикселей в кэшируемой репутации изображения являются исправленными ColorSync.


Элементы Меню Apple

Можно хотеть, чтобы установка приложения привела к дополнительным элементам, появляющимся в Меню Apple каждого пользователя. Чтобы сделать это, необходимо установить пакет в пути поиска библиотеки. Например, если бы Ваше приложение устанавливалось в/Local/Applications, то Вы добавили бы пакет к/Local/Library/AppleMenu.

Пакет должен иметь расширение .appleMenuItems. В пакете должен быть файл AppleMenuItems.plist. Если бы пакет локализуется, был бы файл, AppleMenuItems.strings, в каждом .lproj, для которого это локализуется. Только видимый пользователем заголовок элемента должен быть локализован.

Формат для plist явно не документируется. Существует, однако, существенный пример в AppKit в/System/Library/Frameworks/AppKit.framework/Resources/English.lproj/AppleMenuItems.plist и/System/Library/Frameworks/AppKit.framework/Resources/English.lproj/AppleMenuItems.strings.

В настоящее время все элементы Меню Apple, найденные через эти пути поиска, собраны и локализованы один раз на вход в систему. Элементы становятся фоном, на котором пользователи делают свои отдельные настройки. Пользователь без настроек видит все элементы.


Протокол TextAttachmentCell

Чтобы дать присоединениям больше информации о среде, которую их просят подойти к концу, протокол NSTextAttachmentCell был расширен. Следующие методы были добавлены к протоколу:
- (void)drawWithFrame:(NSRect)cellFrame
inView:(NSView *)controlView
characterIndex:(unsigned)charIndex;
- (BOOL)trackMouse:(NSEvent *)theEvent
inRect:(NSRect)cellFrame
ofView:(NSView *)controlView
atCharacterIndex:(unsigned)charIndex
untilMouseUp:(BOOL)flag;
- (NSRect)cellFrameForTextContainer:(NSTextContainer *)textContainer
proposedLineFragment:(NSRect)lineFrag
glyphPosition:(NSPoint)position
characterIndex:(unsigned)charIndex;
Существующие приложения и объектные файлы совместимы с двоичным файлом и не требуют перекомпиляции. Однако при определенных обстоятельствах, необходимо будет внести исходные изменения для перекомпиляции существующих конформеров к протоколу NSTextAttachmentCell. Подклассы класса NSTextAttachmentCell не должны быть изменены; тот класс реализует новые методы путем вызова более старого-cellSize,-cellBaselineOffset,-drawWithFrame:inView: и-trackMouse:inRect:ofView:untilMouseUp: методы. Однако другие классы, соответствующие этому протоколу, должны будут быть изменены для перекомпиляции. Самое простое изменение должно просто удалить протокол из класса (т.е. удалить» <NSTextAttachmentCell>» из @interface строки для Вашего класса); это произведет предупреждения, когда Вы перекомпилируете, но получающееся приложение или платформа будут работать как ожидалось. Более полная фиксация должна реализовать новые методы для вызова старых, точно как класс, который делает NSTextAttachmentCell. Самая прямая реализация появляется ниже:
- (NSRect)cellFrameForTextContainer:(NSTextContainer *)textContainer
proposedLineFragment:(NSRect)lineFrag
glyphPosition:(NSPoint)position
characterIndex:(unsigned)charIndex {
NSRect result;
result.origin = [self cellBaselineOffset];
result.size = [self cellSize];
return result;
}
- (BOOL)trackMouse:(NSEvent *)theEvent
inRect:(NSRect)cellFrame
ofView:(NSView *)controlView
atCharacterIndex:(unsigned)charIndex
untilMouseUp:(BOOL)flag {
return [self trackMouse:theEvent inRect:cellFrame ofView:controlView untilMouseUp:flag];
}
- (void)drawWithFrame:(NSRect)cellFrame
inView:(NSView *)controlView
characterIndex:(unsigned)charIndex {
[self drawWithFrame:cellFrame inView:controlView];
}
При записи нового класса, соответствующего протоколу NSTextAttachmentCell, сначала решите, нужна ли Вам добавленная информация в новых, более богатых методах. В противном случае просто реализуйте эти методы для вызова более старых, более простых методов, как показано выше. Если Вы хотите использовать в своих интересах более богатые методы, однако, необходимо реализовать более богатые методы, то переопределить более старые методы для вызова более богатых, передающих фиктивных параметров. Например, если Вы хотите использовать текстовый контейнер и информацию о фрагменте строки при калибровке присоединения реализуйте-cellFrameForTextContainer:proposedLineFragment:glyphPosition:characterIndex: должным образом вычислить размер и расположение Вашей ячейки. Тогда реализуйте более старые методы-cellSize и-cellBaselineOffset для вызова этого метода, передающие фиктивные параметры (-cellFrameForTextContainer:...., метод должен быть терпим к этому случаю и отступить к некоторому простому алгоритму калибровки). Это дает Вам:
- (NSRect)cellFrameForTextContainer:(NSTextContainer *)textContainer
proposedLineFragment:(NSRect)lineFrag
glyphPosition:(NSPoint)position
characterIndex:(unsigned)charIndex {
NSRect result;
if (!textContainer) {
// Do some simple size calculation here
...
} else {
// Do your full size calculation here
...
}
return result;
}
- (NSPoint)cellBaselineOffset {
return [self cellFrameForTextContainer:nil proposedLineFragment:NSZeroRect
glyphPosition:NSZeroPoint characterIndex:NSNotFound].origin;
}
- (NSSize)cellSize {
return [self cellFrameForTextContainer:nil proposedLineFragment:NSZeroRect
glyphPosition:NSZeroPoint characterIndex:NSNotFound].size;
}
Текстовая система AppKit никогда не будет вызывать более старые методы; однако, другие классы, проверяющие на протокол, могли бы, таким образом, необходимо удостовериться, что реализовали полный набор.

В дополнение к вышеупомянутым изменениям следующие методы были добавлены к NSLayoutManager, чтобы позволить этому работать:
- (void)setAttachmentSize:(NSSize)attachmentSize forGlyphRange:(NSRange)glyphRange;
- (NSSize)attachmentSizeForGlyphAtIndex:(unsigned)glyphIndex;
- (void)showAttachmentCell:(NSCell *)cell inRect:(NSRect)rect
characterIndex:(unsigned)attachmentIndex;
Последний осуждает следующий метод, который будет продолжать работать в 1,0:
- (void)showAttachmentCell:(NSCell *)cell atPoint:(NSPoint)point;

Используя NSURL для загрузки ресурсов

API NSURL был обогащен, чтобы позволить загрузить ресурсы из сети и сети, или на переднем плане или на фоне. Для загрузки URL на переднем плане вызовите resourceDataUsingCache:passing YES или нет, в зависимости от того, хотите ли Вы использовать кэш. При использовании кэша NSURL будет видеть, было ли это или эквивалентный URL уже загружено и сохранено в кэше. Если так, это возвратит кэшируемые данные ресурсов. В противном случае это запустит новую загрузку URL, возвращаясь только после того, как будут полностью загружены данные URL's. Если Вы не будете использовать кэш, то новая загрузка будет запущена независимо. Для загрузки URL в фоновом режиме вызовите loadResourceDataNotifyingClient:usingCache:. Этот метод запустит фоновую загрузку, затем сразу возвратиться. Поскольку ресурс загружается, клиент получит сообщения от неофициального протокола NSURLClient (если клиент реализует их):
@interface NSObject(NSURLClient)
- (void)URL:(NSURL *)sender resourceDataDidBecomeAvailable:(NSData *)newBytes;
- (void)URLResourceDidFinishLoading:(NSURL *)sender;
- (void)URLResourceDidCancelLoading:(NSURL *)sender;
- (void)URL:(NSURL *)sender resourceDidFailLoadingWithReason:(NSString *)reason;
@end
Клиент получит некоторое число (возможно нуль) URL:resourceDataDidBecomeAvailable: сообщения, сопровождаемые точно одним из URLResourceDidFinishLoading: URLResourceDidCancelLoading: или URL:resourceDidFailLoadingWithReason:. Клиент должен только реализовать те методы, что это интересуется получением.

NSURLHandle и его подклассы:

NSURL загружает свой ресурс при помощи объекта помощника класса NSURLHandle. Сам NSURLHandle является абстрактным суперклассом, определяющим путь, которым URLs связывается с их дескрипторами. Подклассы регистра NSURLHandle для определенной схемы (http, ftp, файл, и т.д.), затем реализуют фактический механизм загрузки для той схемы. В настоящее время Основа только обеспечивает подклассы для файла и http схем.

Каждый подкласс NSURLHandle также определяет много свойств для ИТ-услуг схемы. Например, полномочия, тип и размер файла являются всеми свойствами файла URLs (URLs формы file:///some-path). Можно попросить у URL одного из его свойств путем отправки ему propertyForKey: сообщение, передавая ключ для свойства Вы хотите. HTTP URLs предоставляет их данные HTTP-заголовка как свойства; используйте имя поля заголовка, которым Вы интересуетесь как ключ. Файл URLs обеспечивает их атрибуты файла как свойства; используйте строки атрибута файла, определенные в NSFileManager.h.

Несмотря на то, что существует много удобных методов, доступных на NSURL для загрузки ресурсов и запросов свойств, некоторые приложения найдут, что функциональность, экспортируемая NSURL, не достаточна для его потребностей. Для более обширного управления необходимо получить NSURLHandle от NSURL, затем передать дескриптор непосредственно. Можно сделать это путем отправки NSURL URLHandleUsingCache: сообщение. Для получения дополнительной информации о NSURLHandle, смотрите на заголовочный файл, NSURLHandle.h.

Запись собственного подкласса NSURLHandle:

Одна вещь, которую платформа или приложение могут хотеть сделать, добавляет возможность обработать новую схему. Например, можно хотеть добавить обработку ftp, или возможно собственную схему. Можно сделать это путем разделения на подклассы NSURLHandle. Ваш подкласс должен будет переопределить и реализовать следующие методы:
+ (BOOL)canInitWithURL:(NSURL *)anURL;
+ (NSURLHandle *)cachedHandleForURL:(NSURL *)anURL
- initWithURL:(NSURL *)anURL cached:(BOOL)willCache;
- (id)propertyForKey:(NSString *)propertyKey;
- (id)propertyForKeyIfAvailable:(NSString *)propertyKey;
- (BOOL)writeProperty:(id)propertyValue forKey:(NSString *)propertyKey;
- (BOOL)writeData:(NSData *)data;
- (NSData *)loadInForeground;
- (void)beginLoadInBackground;
- (void)endLoadInBackground;
Ваш подкласс должен реализовать canInitWithURL: возвратить YES, если это может обслужить данный URL, и НЕ иначе. cachedHandleForURL: должен выглядеть в кэше (сохраняемым Вашим подклассом) для существующего дескриптора, обслуживающего URL, идентичный переданному тому. Если так, кэшируемый дескриптор должен быть возвращен. В противном случае новый дескриптор должен быть создан для URL, сохранил в кэше, затем возвратился. initWithURL:cached: определяемый инициализатор для NSURLHandle; второй параметр указывает, будет ли дескриптор помещен в кэш.

propertyForKey: должен выбрать значение для любых свойств, которые определяет Ваш подкласс, и возвратите ноль для любых нераспознанных свойств. propertyForKeyIfAvailable: должен возвратить ноль, если свойство не уже легко доступно.

Если Ваш подкласс позволяет выписывать свойства или данные, необходимо реализовать writeProperty:forKey: и writeData: чтобы попытаться выписать их параметры, затем возвратите YES, если запись успешно выполнилась, и НЕ иначе. Иначе, необходимо реализовать их для простого возврата НЕТ.

Последние три метода, loadInForeground, beginLoadInBackground, и endLoadInBackground выполняют мясистую работу Вашего подкласса. Их вызывают от resourceData, loadInBackground, и cancelLoadInBackground соответственно, после проверки состояния дескриптора. (Например, resourceData не вызовет loadInForeground, если был уже загружен дескриптор; это просто возвратит существующие данные.) loadInForeground должен синхронно выбрать и возвратить данные ресурсов URL's. beginLoadInBackground должен запустить фоновую загрузку данных, затем возвратиться. В то время как фоновая загрузка развивается, Ваш подкласс должен передать себя с didLoadBytes:loadComplete: передавая байты, полученные, и закончилась ли загрузка. Если сбои загрузки в какой-либо точке, Ваш подкласс должен вызвать backgroundLoadDidFailWithReason: передавая человекочитаемую строку, приводящую причину для отказа. NSURLHandle реализует эти методы для информирования его клиентов (включая URL сам) нового состояния. Наконец, Ваш подкласс должен переопределить cancelLoadInBackground для остановки фоновой происходящей загрузки. Как только дескриптор получил сообщение cancelLoadInBackground, он не должен отправлять дальше didLoadBytes:loadComplete: или backgroundLoadDidFailWithReason: сообщения.

Теперь все, что остается, должно сообщить NSURLHandle Вашего нового подкласса; Вы делаете это путем отправки классу NSURLHandle registerURLHandleClass: сообщение, передавая Ваш подкласс как параметр. Как только это сообщение было отправлено, поскольку NSURLHandle просят создать дескрипторы для данного URL, это поочередно спросит Ваш подкласс, если это захочет обработать URL. Если Ваш подкласс ответит то ДА, NSURLHandle инстанцирует Вашего подкласса для URL.


Используя NSUndoManager от Java

Поскольку основанный на вызове регистрационный механизм отмены недоступен в Java, Java, API NSUndoManager был обогащен. Следующий метод был добавлен к NSUndoManager:
public native void registerUndoWithTargetAndArguments(
java.lang.Object target,
com.apple.cocoa.foundation.NSSelector selector,
java.lang.Object arguments[]);
Это позволяет вызывающей стороне помещать произвольный вызов метода на стек отмены. Первым параметром является намеченный получатель для метода, второй параметр указывает метод, и третьим параметром является массив параметров, которые будут переданы.

Обратите внимание на то, что массив arguments является массивом Объектов. Когда Ваш метод берет скалярные типы, необходимо использовать эквивалентные классы обертки Java в массиве arguments. Например, метод, берущий интервал, должен создать java.lang. Целочисленный экземпляр, содержащий тот интервал для помещения в массив arguments. Менеджер по отмене разрешит все это к тому времени, когда это должно создать вызов для отправки. Посмотрите версию Java исходного кода приложения Эскиза для примера использования этого нового метода.

Существует известная ошибка, предотвращающая аргументы с плавающей запятой (зарегистрированный как java.lang. Объекты плавающие) от того, чтобы быть должным образом зарегистрированным; Методы, берущие плавания, не будут в состоянии быть отмененными должным образом в это время. Параметром всегда будет нуль к тому времени, когда Ваш метод вызывается от менеджера по отмене. Эскиз имеет эту проблему с setStrokeLineWidth () метод в Графическом классе. Можно работать вокруг этого при наличии метода, берут java.lang. Плавание вместо этого. Эта ошибка должна адресоваться в предстоящем выпуске.


Используя отмену с текстовой системой

Недостаток дизайна был обнаружен при использовании отмены с текстовой системой AppKit. Если Вы будете иметь текстовое представление и включите отмену с нею путем вызова [myTextView setAllowsUndo:YES], то стек отмены, которым управляет текстовое представление, станет поврежденным, если текстовым хранением будут управлять непосредственно. Ряд методов на NSTextView (методы, наследованные от NSText формы-replaceCharactersInRange:....), также повредит стек отмены. После того, как поврежденный, вызовы, чтобы отменить и восстановить будут иметь неожиданные результаты, возможно разрушая приложение. Для предотвращения этого мы рекомендуем, чтобы Вы или управляли текстом только через безопасные методы NSTextView, управляли стеком отмены сами или отключили отмену. Эта ошибка будет разрешена в предстоящем выпуске.


TableView

Идентификаторы столбцов, используемые с «autosaveTableColumns» функцией NSTableView, должны соответствовать протоколу NSCoding. NSTableView повысит исключение, если пользователь попытается выполнить автосохранение (в Пользовательские Значения по умолчанию) на идентификаторе столбца таблицы, который не является archivable объектом. В DR2 представление позволило бы делать попытку этого, и программа откажет загадочно во время Пользовательской записи Значений по умолчанию.

Когда существует набор имени автосохранения, опция автосохранения только фактически активирована. код должен вызвать setAutosaveName: прежде, чем вызвать setAutosaveTableColumns:YES. В предыдущих выпусках это сохранило бы любой неназванный tableview автоматически с тем же ключом, «Столбцы NSTableView *ноль*».

Корректный способ использовать эту функцию для экземпляров NSTableView в файлах NIB состоит в том, чтобы определить имя и включить его после того, как файл NIB загружается и прежде чем произойдет дисплей. «AwakeFromNib» метод в классе контроллера является хорошим местом, чтобы сделать это.

Из-за этой функции автосохранения приостановлены уведомления об изменении ширины столбца, в то время как NSTableView размещает себя рядом или иначе выкладывает себя пользовательским столбцом - изменяют размеры работы. Столбцы сохраняются после завершения работы расположения. Были уведомления, не приостановленные, setWidth:calls во время расположения заставит уведомления быть отправленными и настройки столбца, которые будут сохранены. Это изменение предотвращает автосохранение во время операций расположения и изменения размеров.

Примечание: Разработчики могут найти, что программы, использовавшие функцию автосохранения в DR2, могут разрушить или повысить исключение при попытке считать старые значения по умолчанию под новым режимом. (Исключение обычно происходило бы в методах, вызванных через закрытый метод _readPersistentTableColumns; и сообщение NSLog утвердит, что NSInlineUnicodeString не реагирует на метод байтов.) Катастрофический отказ может быть исправлен первым удалением старых значений по умолчанию автосохранения для того приложения. (Используйте «значения по умолчанию, удаляют TheApp TheKey», или когда в сомнении, «значения по умолчанию удаляют TheApp» для удаления всех значений по умолчанию для незаконного приложения.

Столбцы сохраняются идентификатором столбца. В выпуске DR2 идентификатор столбца, как ожидали, всегда будет NSString, хотя это - должным образом тип «ID». В этом выпуске идентификатор столбца может быть любым объектом, реагирующим на протокол NSCoding (хотя обычно NSNumber NSString).

Некоторые примечания по редактированию ячейки и перезагрузке данных: Когда reloadData метод вызовут, любая ячейка, которая является посреди того, чтобы быть отредактированным, потеряет в настоящее время происходящие изменения редактирования. (Т.е. ячейка, имеющая мерцающий курсор во время перезагрузки, потеряет то, что изменилось.) Это может быть исправлено путем явного окончания сеанса редактирования перед перезагрузкой, которая сохранит данные в ячейке. Прежде, чем отправить reloadData в Табличное представление, отправьте endEditingFor: к окну, в котором это живет. Например:
    [[myTabView window] endEditingFor:self];
[myTabView reloadData];

OutlineView

Метод делегата outlineView:willDisplayOutlineCell:forTableColumn:item: никогда не отправлялся. Это было фиксировано так, чтобы это вызвали (если делегат реагирует на него) непосредственно перед тем, как нарисована ячейка.

Метод removeTableColumn: не должен использоваться для «столбца таблицы схемы», и если попытка будет предпринята, чтобы сделать это (который привел бы к противоречивому состоянию), то метод зарегистрирует ошибку, и никакое изменение не будет иметь место. Используйте setOutlineTableColumn: метод для надлежащей замены столбца таблицы схемы при необходимости. Во-первых, добавьте новый столбец, если Вы должны, затем используйте setOutlineTableColumn: для переключения на новый столбец таблицы затем удалите старый столбец при желании.


Примечания по поддержке «европейского» валютного знака

Большинство шрифтов, поставленных с этим выпуском, не было изменено для включения нового «Европейского» валютного знака европейского Валютного союза. Темно-серый шрифт, однако, был изменен для включения этого глифа в должность кодирования, раньше сохраненную для Международного Валютного Знака, редко используемого символа. Ожидается, что в будущем, если бы другие шрифты изменяются, они аналогично включали бы Европейский знак в эту позицию. Кодировка символов за Евро входит в систему, стандарт Unicode является U+20AC, как задокументировано в Технический отчет № 8 Unicode. (Международный Валютный Знак кодируется в U+00A4.)

Для упрощения использования Евро подписываются без системных модификаций, если новые шрифты, содержащие его, добавляются пользователями, или другие поставщики, и символ для Европейского знака и для Международного Валютного Знака представляются с глифом, закодированным в 0x00A8 в кодировании шрифта «NextStep».

Другими словами: в Темно-сером шрифте глиф для Международного Валютного Знака недоступен, будучи замененным глифом для Европейского знака. В других шрифтах глиф для Европейского знака недоступен. Однако все NextStep-закодированные шрифты отвечают, как будто глиф для Европейского знака был закодирован в 0x00A8.

Для отображения надлежащего глифа за Евро входят в систему простой текст, можно использовать Темно-серый шрифт. Вывести на экран надлежащий глиф в RTF или другом знатоке отформатировало документы, можно ввести символ U+20AC, выбрать его и изменить шрифт того одного символа к Древесному углю.


Примечания по поддержке клавиатуры для «европейского» валютного знака

Большинству раскладок клавиатуры, поставленных с Сервером Mac OS X теперь, присоединили Европейский знак к сочетанию клавиш Alt-Shift-4. Если раскладка клавиатуры, которую Вы выбрали, не сконфигурирована этот путь, или если Вы хотите изменить сочетание клавиш для генерации Евро, можно использовать Keyboard.app, который может быть найден в/System/Demos.

Поскольку контурные карты в настоящее время не поддерживают присвоение фактических символов Unicode, thetechnique для присвоения Европейского знака к ключу не очевидно. Для присвоения Евро ключу необходимо использовать слот кодирования 0xa0 набора символов Символа. Этот слот кодирования не использован в кодировании стандартного символа.

Для присвоения этого ключу откройте файл отображения клавиатуры в Keyboard.app, выберите ключ, который Вы хотите на изображении клавиатуры и удостоверяетесь, что проверяются флажки для любых модификаторов, которые Вы хотите. Например, для присвоения его Alt-Shift-4 выберите четыре ключа и проверьте флажки Shift и Alternate. Затем с помощью Палитры Кода символа (доступный из меню Tools), выберите кодирование Символа из раскрывающегося у основания окна и перетащите микросхему для 0xa0 на клавиатуру и отбросьте его на ключе, который Вы хотите присвоить. Слот 0xa0 является 1-м столбцом 11-й строки Палитры Кода символа. При присвоении Европейского знака ключу, Вы хотите, сохраняете клавиатуру, отображающуюся в Ваш ~/Library/Keyboards каталог (создающий каталог Keyboards если необходимый), и используйте Preferences.app для выбора нового отображения клавиатуры.


Наборное устройство

NSTypesetter был сделан общедоступным классом в этом выпуске. Класс сам NSTypesetter абстрактен. Одним конкретным подклассом является NSSimpleHorizontalTypesetter, который является классом, используемым в качестве значения по умолчанию по всей системе. Некоторые переменные экземпляра реального класса доступны для использования подклассификаторами.

Следующие методы NSLayoutManager были представлены для поддержки использования пользовательских подклассов NSTypesetter:
- (NSTypesetter *)typesetter;
- (void)setTypesetter:(NSTypesetter *)typesetter;
- (unsigned)getGlyphsInRange:(NSRange)glyphsRange
glyphs:(NSGlyph *)glyphBuffer
characterIndexes:(unsigned *)charIndexBuffer
glyphInscriptions:(NSGlyphInscription *)inscribeBuffer
elasticBits:(BOOL *)elasticBuffer

Браузер

Некоторые методы делегата NSBrowser (особенно browser:columnOfTitle:) зависят от настроек опции и состояния экземпляра браузера в это время setDelegate: метод вызывают, но документация не ясна по этому вопросу. Лучше заботиться обо всех настройках опции экземпляра браузера (таких как setTitled: и setTakesTitlesFromPreviousColumn:) прежде, чем установить делегата через setDelegate:.


Окно

NSWindow теперь имеет-isZoomed API, чтобы позволить Вам спросить, масштабируется ли в настоящее время окно. Ответом будет YES при ударе поля изменения масштаба или вызове изменения масштаба: метод заставил бы окно восстанавливать последнее пользовательское состояние. Если удар поля изменения масштаба заставил бы окно масштабировать, это будет НЕ.


DocumentController

Подписи Java для следующих методов изменились, чтобы быть более определенными. Это изменение потребует перекомпилировать JAVA-приложений, использующих архитектуру документа.
public static native NSDocumentController sharedDocumentController();
public native NSDocument makeUntitledDocumentOfType(java.lang.String);
public native NSDocument makeDocumentWithContentsOfFile(java.lang.String, java.lang.String);
public native NSDocument makeDocumentWithContentsOfURL(java.net.URL, java.lang.String);
public native NSDocument openUntitledDocumentOfType(java.lang.String, boolean);
public native NSDocument openDocumentWithContentsOfFile(java.lang.String, boolean);
public native NSDocument openDocumentWithContentsOfURL(java.net.URL, boolean);
public native NSDocument currentDocument();
public native NSDocument documentForWindow(com.apple.cocoa.application.NSWindow);
public native NSDocument documentForFileName(java.lang.String);
Эти методы все раньше возвращали java.lang. Объект в DR2.


WindowController

Подписи Java для следующего метода NSWindowController изменились, чтобы быть более определенными. Это изменение потребует перекомпилировать JAVA-приложений, использующих архитектуру документа.
public native NSDocument document();
Этот метод раньше возвращал java.lang. Объект в DR2.


Приложение

activateIgnoringOtherApps: если флагом будет YES, теперь выведет на экран и активирует скрытое приложение. В DR2 и предыдущих выпусках, этот метод не имел никакого эффекта на скрытое приложение.

NXOpen, NXOpenTemp и NXPrint больше не распознаются как параметры командной строки. Любое использование этих ключевых слов должно быть заменено NSOpen, NSOpenTemp и NSPrint, соответственно.


Поточная обработка

Теперь возможно создать окно на вторичном потоке.

Теперь возможно вызвать [NSApplication postEvent:atStart:] от вторичного потока. Это приведет к поставке события к очереди событий на основном потоке.

В DR2 многопоточные приложения могли поразить состояние состязания, где шрифт, определенный на одном потоке, не был доступен на другом. Это было фиксировано для рисования шрифтов. Фиксация не применяется к печати шрифтов, но это не должно быть проблемой, поскольку не ожидается, что приложение будет распечатывать от двух потоков сразу.

Для получения дополнительной информации о версии при поточной обработке поддержки см. ThreadSupport.html.


Используя NSFileHandle с сокетами на Windows

Поскольку считанный () и запись () не работают над сокетами на Windows, дескриптор файла, создаваемый с [[выделение NSFileHandle] initWithNativeHandle: (HANDLE) someSocketHandle] не был применим.

Если считано () и запись () сбой, реализация дескриптора файла теперь пробует recv (), и отправьте (), соответственно, и дескриптор файла создал этот путь, теперь применимо.

Можно счесть особенно удобным пройти через NSFileHandle API в случаях, где Вы не знаете, является ли дескриптор сокетом или дескриптором к регулярному файлу файловой системы. Например, дочерний процесс, родитель которого установил его, чтобы читать или записать из сокета с помощью stdin и stdout, может успешно считать из stdin и stdout использование дескриптора файла API, тогда как stdio вызовы библиотеки, такие как getchar () и putchar () перестанут работать.


Тянущийся Windows

Вследствие неправильного соответствия между сообщениями, отправленными OLE, перетаскивают менеджера и NSDraggingDestination неофициальный протокол, draggingEntered: неоднократно отправлялся и draggingUpdated: не был отправлен. Разработчики, работавшие вокруг этих долгосрочных проблем, должны удалить свои обходные решения с этого выпуска.


Непрерывное завершение в NSComboBox и NSComboBoxCell

Новый метод setCompletes: был представлен. Если завершается, ДА, после каждого изменения в тексте ячейки поля комбинированного списка, completedString: вызывается. Если строка, возвращенная completedString: более длинно, чем существующий текст, текст заменяется, и дополнительный материал выбран. Если пользователь удаляет текст, или выбор (или точка вставки) не в конце текста, завершение не опробовано.

Реализация completedString: предоставлен. Если поле комбинированного списка (или ячейка поля комбинированного списка) использует источник данных, и источник данных отвечает на comboBox:completedString: (или comboBoxCell:completedString: в случае ячейки поля комбинированного списка), возвращаемое значение этого метода используется. Иначе, эта реализация просто идет линейно через элементы, пока она не находит элемент, подходящий как завершенная строка. Подклассификаторы completedString: не должны вызывать супер. Нормально возвращать ноль (когда никакое завершение не происходит). completedString: обычно не вызывается непосредственно.


ButtonCell

Константы NSMomentaryPushButton и NSMomentaryLight, где инвертировано. Если Вы вызвали [NSButtonCell setButtonType:] с этими константами, они сделали бы неправильную вещь. Для compatability были сохранены эти постоянные имена, но были представлены новые с корректным именованием: NSMomentaryLightButton и NSMomentaryPushInButton.


StatusItem

Предел на ширине элементов строки состояния был увеличен (до 10 000, в основном неограниченный).


MenuItem

Реализация Windows NSMenuItem теперь поддерживает черные и белые изображения для использования в качестве меток для указания на, прочь, или смешанные состояния. Если пользовательские изображения не установлены, то галочка используется для на состоянии, тире используется для смешанного состояния, и никакое изображение не используется для от состояния. Изображение будет центрироваться в границах значка пункта меню.


ToolTips

В DR2 и ранее, подсказки не работали в модальных окнах. Они теперь делают.


Стандарт о панели

Следующие два метода были добавлены к NSApplication, чтобы позволить поднимать стандартную панель About. Первый позволяет Вам указывать различные поля. Значения по умолчанию (как описано ниже) используются для неуказанных полей. Второй метод, предназначенный для использования цели/действия, просто использует все значения по умолчанию:
- (void)orderFrontStandardAboutPanelWithOptions:(NSDictionary *)optionsDictionary;
- (void)orderFrontStandardAboutPanel:(id)sender;
Следующее является ключами, которые могут произойти в optionsDictionary:

«Кредиты»: NSAttributedString выведен на экран в информационной области панели. Если не указанный, содержание получено из «Credits.rtf» в [NSBundle mainBundle]; если не доступный, пробел.

«ApplicationName»: NSString выведен на экран вместо имени приложения по умолчанию. Если не указанный, использует значение NSHumanReadableShortName в локализованной версии Info.plist. Если это не доступно, использование [[NSProcessInfo processInfo] processName].

«ApplicationIcon»: NSImage выведен на экран вместо NSApplicationIcon. Если не указанный, используйте [NSImage imageNamed:@ «NSApplicationIcon»]; если не доступный, универсальный значок.

«Версия»: NSString, содержащий число версии сборки приложения («58.4»); выведенный на экран как» (v58.4)». Если не указанный, получите из ключа NSBuildVersion infoDictionary; если не указанный, оставьте незаполненный (» (v)», не выведен на экран).

«Авторское право»: NSString, содержащий строку авторского права. Если не указанный, получите из значения NSHumanReadableCopyright в локализованной версии InfoDictionary; если не доступный, оставьте незаполненный.

«ApplicationVersion»: NSString, выведенный на экран как версия приложения («X-сервер MacOS», «WebObjects 3.5», «ClarisWorks 5»...). Если не указанный, получите из ключа NSAppVersion в Info.plist. Если не доступный, оставьте незаполненный; тогда версия сборки, если предоставленный, выведена на экран как «Версия 58.4».


Приписанные строки в FoundationJava

Обратите внимание на то, что несмотря на то, что конструкторы NSAttributedString от AppKit перечислены в FoundationJava в Желтом / Java APIs, они все еще реализованы в AppKit и требуют, чтобы AppKit был соединен в быть применимыми.


Текст

Текстовый объект теперь поддерживает более сложное подчеркивание; можно подчеркнуть словами, и перечеркиванием. Вы можете «или» вместе NSUnderlineByWordMask и NSUnderlineStrikethroughMask с основным стилем подчеркивания (NSNoUnderlineStyle или NSSingleUnderlineStyle) для получения желаемого эффекта.

В DR2 и ранее, расстановка переносов могла (особенно с высокими факторами расстановки переносов, выше 0.8) незначительные сбои дисплея причины (перезаписанные строки, например) при некоторых редких обстоятельствах. Это теперь фиксируется.

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


SplitView

Следующий метод делегата:
- (void)splitView:(NSSplitView *)sender
constrainMinCoordinate:(float *)min
maxCoordinate:(float *)max
ofSubviewAt:(int)offset;
осуждался в пользу:
- (float)splitView:(NSSplitView *)sender
constrainMinCoordinate:(float)proposedCoord
ofSubviewAt:(int)offset;
- (float)splitView:(NSSplitView *)sender
constrainMaxCoordinate:(float)proposedCoord
ofSubviewAt:(int)offset;
В 1,0, вызовут старый, если он будет все еще реализован.


Представление

Новый метод lockFocusIfCanDraw был внедрен. Любой поток, рисующий непосредственно (например, за пределами стандартного механизма дисплея), должен использовать этот метод для проверки законности получения, прежде чем это начнет рисовать.


FileWrapper

Строковое кодирование для сериализированной обертки каталога изменяется от NSNEXTSTEPStringEncoding до NSUTF8StringEncoding. Это означает, что символы неASCII в сериализированных данных RTFD теряют обратную совместимость.


Java

Альфа-версии Java APIs к Желтому Полю были удалены. Им были предоставлены в DR2 для совместимости только.



Отмечает определенный для выпуска Developer 2

Набор Приложения включает эти новые классы, функции, и изменяется начиная с первого Выпуска Developer. Многие новые функции были задокументированы, так см. документация для большего количества подробности.


Java

Java APIs к Желтому Полю, распределенный в их альфа-форме в первом Выпуске Developer, претерпел некоторые изменения и теперь значительно более устойчив и завершен. Посмотрите Java информация о версии APIs для подробных данных.


Основанная на документе архитектура приложения

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

Экземпляры NSDocument представляют документы. NSDocument абстрактен; Вы разделяете его на подклассы для добавления хранения для документа и способов поведения, таких как чтение и запись. NSDocument появляется в цепочке респондента прямо после делегата ее окна, и NSDocument устанавливается, чтобы быть целью первого респондента для различных действий тех, которые сохраняют, возвращаются, и печать. Кроме того, NSDocument управляет отредактированным состоянием своего окна и реализует большую часть поведения, требуемого для операций восстановления и отмены.

Каждое приложение имеет один экземпляр NSDocumentController, управляющего списком документов и реализующего поведение всего приложения.

NSWindowController обеспечивает основной файл пера и управление окнами. Для простых ситуаций (один документ, одно окно), у Вас обычно будет один экземпляр NSWindowController на документ. NSWindowController может также использоваться для управления окнами в не, документ базировал приложения. Разделение на подклассы является дополнительным.

Новый тип проекта, «Документ Основанное Приложение», упрощает начальная настройка, требуемая создавать приложение на основе этих новых классов.


Типы данных

Для лучше поддержки нового объекта документа и Средства поиска (в предстоящих выпусках) некоторые изменения были внесены в содержании Info.plist и файлов CustomInfo.plist, найденных в обертках приложения и пакетах. См. информацию о версии на информационном Формате Списка свойств для подробных данных.


Поддержка отмены

Платформа Объекта предприятия EOUndoManager была изменена и сделана новым Фундаментальным классом, NSUndoManager. Этот класс упрощает для приложений поддерживать операции восстановления и отмена. Клиенты регистрируют обратные вызовы, которые вызывает менеджер по отмене, когда пользователи запрашивают отмену или восстанавливают работу. Группировка поддержек NSUndoManager и многократные уровни отмены.

NSResponder теперь обеспечивает метод, названный undoManager; клиенты должны использовать этот метод для получения доступа к NSUndoManager. Поведение по умолчанию в NSResponder состоит в том, чтобы вызвать следующего респондента; это обычно заканчивается в NSWindow, который находится в цепочке респондента. Поведение по умолчанию NSWindow немного более сложно; если окно имеет контроллер окна с документом, NSWindow реализует этот метод первым, надеющимся видеть, имеет ли его документ менеджера по отмене и возврат его, если это так. Иначе, NSWindow вызывает новый метод делегата undoManagerForWindow:If, делегат не реализует этот метод, NSWindow создает и возвращает свой собственный NSUndoManager.

Текстовая система теперь также поддерживает операции восстановления и отмена.


Сценарии

Несмотря на то, что DR2 не содержит функций сценариев, информация о версии была предоставлена для предоставления информации, чтобы помочь Вам разработать свое приложение так, чтобы это было scriptable, когда Желтое Поле действительно обеспечит scriptability. Эта информация о версии также обсуждает архитектуру документа и функции отмены в некоторой подробности.


ActiveX (Windows Only)

Платформа ActiveX (ActiveX.framework) объединяет первые части Желтой интеграции Поля/ActiveX, позволяя Вам использовать Объекты автоматизации ActiveX в Objective C. Обратите внимание на то, что эта функциональность в настоящее время является предварительной альфой, означая упаковку, и APIs самостоятельно подвержен изменениям в следующем выпуске.

NSDispatchProxy является конкретным подклассом NSProxy, определяющего прокси для Объектов автоматизации ActiveX. Когда NSDispatchProxy получает сообщение, в большинстве случаев он передает сообщение через DCOM (Объектная модель распределенных компонентов) к реальному Объекту автоматизации ActiveX, предоставляя возвращаемое значение к отправителю сообщения, если Вы являетесь предстоящими, и распространяющий какое-либо исключение назад к invoker метода, повысившего его. См. документацию, предоставленную в платформе для получения дополнительной информации.


Функции мультипотока

Набор Приложения и Основа теперь обеспечивают больше мультипотокобезопасности, достаточно чтобы поддерживать многопоточные требования получения AWT и позволить разработчикам делать множество задач с помощью многократных потоков. Рисование от многократных потоков поддерживается, пока каждый поток использует свое собственное соединение с сервером окна; это легко выполняется при помощи метода фабрики NSApplication detachDrawingThread:toTarget:withObject:.


Строка состояния

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

Тот же API доступен и на Macintosh и на Windows. На Macintosh элементы появляются на правой стороне строки меню. Под Windows элементы состояния появляются как часть области уведомлений панели задач (обычно правая сторона панели задач). Пользовательская функция представления не поддерживается под Windows.


Меню и раскрывающийся

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

Набор Приложения «взлом» изменения первого меню верхнего уровня к Меню Apple, если его заголовком является «Информация» все еще, работает в этом выпуске; однако, необходимо переключить меню для использования реального Меню Apple.

Любое меню, которое является частью главного меню приложения, может быть оторвано. Для отрыва меню начинают отслеживать в нем, как будто Вы собирались выбрать элемент и перетащить от нижней части меню немного расстояния. Кнопка мыши должна быть до, отрывают меню. Меню, которые Вы отрываете в приложении, помнят и восстанавливают, поскольку Вы выходите и повторно запускаете приложение.

Меню теперь поддерживают клавиатуру UI: В то время как меню отслеживает Вас, может теперь использовать клавиши со стрелками для навигации. С тех пор в настоящее время нет никакого способа начать отслеживать главное меню через клавиатуру, это еще не очень полезно для нормальных меню, но это означает, что можно использовать клавиатуру для выбора элементов в раскрывающемся или выпадающем меню. Когда фокус находится на NSPopUpButton, нажимание клавиши «Пробел» раскрывается меню. Тогда можно использовать клавиши со стрелками для перемещения между элементами; нажмите клавишу «Пробел» снова для выбора элемента.

Если представление имеет тот, щелчок управления теперь показывает контекстное меню для представления. Щелчок управления не замечен (как mouseDown:) представлениями, имеющими контекстные меню. Представления, не имеющие контекстных меню все еще, получают mouseDown:for Щелчки управления. Даже если у Вас нет контекстных меню, Однако с помощью Управления, поскольку модификатору мыши обескураживают. В течение долгого времени Желтые приложения Поля, предоставленные Apple, мигрируют далеко от использования Щелчка управления для чего-либо кроме контекстных меню.

Пользователь ключевые эквивалентные переопределения: Эта опция реализована, но UI для установки их не находится в этом выпуске.

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


ScrollView

Можно теперь независимо установить горизонтальную и вертикальную строку и суммы прокрутки страницы.


SplitView

NSSplitView имеет дополнительные методы делегата позволить Вам ограничивать изменение размеров и разрушение представления.


TabView

Новый удобный метод selectTabViewItemWithIdentifier:allows Вы для выбора элемента вкладки его идентификатором. Если идентификатор недопустим, как с другими методами в NSTabView, этот метод повышает исключение.


Рабочая область

В Выпуске Developer 1 на платформах MacOS, делегаты приложения не получали applicationShouldTerminate:on выключение питания или события выхода из системы в дополнение к нормальному завершению приложения. Это теперь работает должным образом. Если делегат приложения реализует этот метод и возвраты нет, то выход из системы или выключение питания отменяются.

Приложения, которые должны отличить между завершением, связанным с концом сеанса входа в систему и завершением посредством Выхода (или Выход) команду, могли сделать это путем регистрации для NSWorkspaceWillPowerOffNotification. Это уведомление отправляется до вызова applicationShouldTerminate:.

Дополнительные соответствующие события, происходящие позже в последовательности завершения, являются регистрацией NSApplicationWillTerminateNotificationand соответствующее сообщение делегату приложения applicationWillTerminate: если это реализует метод.

Для документов, которыми управляет NSDocumentController, не необходимо для делегата приложения оказаться замешанным в процесс отмены или сохранение.


Кнопка

Кнопки включают новую функцию, делает границу кнопки видимой только, когда кнопка включена, и мышь по кнопке. Можно включить или отключить эту опцию путем вызова метода setShowsBorderOnlyWhileMouseInside:; текущая установка этого атрибута возвращается методом showsBorderOnlyWhileMouseInside. Эти два метод доступен и в NSButton и в NSButtonCell и этой установке, архивируются и восстанавливаются. Когда Вы будете иметь дело с матрицами, вызовите методы ячейки непосредственно.

Можно переопределить mouseEntered:and mouseExited:methods, добавленный к NSButtonCell для внесения дополнительных изменений появления. Эти методы вызываются, когда ячейка кнопки включена, showsBorderOnlyWhileMouseInsideflag установлен в ДА, и мышь вводит или выходит из кнопки.


BitmapImageRep

Новый метод colorizeByMappingGray:toColor:blackMapping:whiteMapping:supports колоризация изображений. Этот метод прежде всего отображает полутоновые изображения компонента пользовательского интерфейса на различные цветовые схемы.

В этом выпуске NSBitmapImageRep имеет некоторую предварительную поддержку профилей ColorSync в файлах TIFF. Профиль загружается и используется, если это возможно. Это не сохраняется на сохранении. Кроме того, это работает только над архитектурой PowerPC.

Как упомянуто в Выпуске Developer 1 примечание, NSBitmapImageRep теперь поддерживает JPEG, GIF, и чтение PNG и запись. Эта поддержка не завершена и вероятно изменится для первого Выпуска Клиента для включения дополнительных форматов с помощью кодеков QuickTime.

Поскольку различные форматы изображения содержат дополнительную информацию, эта информация хранится как свойства NSBitmapImageRep. Можно установить эти свойства в изображении при помощи setProperty:withValue:method и получить свойства с valueForProperty: или можно добавить или переопределить свойства при создании представления с помощью representationOfImageRepsInArray:usingType:properties:and representationUsingType:properties:methods. Свойства сохранены в NSDictionary использование NSString для ключа. Следующие пары ключ/значение в настоящее время определяются:

- NSImageCompressionMethod: - метод сжатия TIFF для файлов TIFF. Перечисляемое значение сохранено в NSNumber.
- NSImageCompressionFactor: - TIFF и фактор сжатия JPEG. Значение плавающее сохранено в NSNumber.
- NSImageDitherTransparency: - Используемый для вывода GIF только. Это - булево значение, сохраненное в NSNumber. Если это правда, прозрачность размывается для получения эффекта альфа-канала.
- NSImageRGBColorTable: - Для ввода и вывода GIF. Это состоит из 768-байтового объекта NSData, содержащего упакованную таблицу RGB с каждым компонентом, являющимся 8 битами.
- Вывод NSImageInterlaced: - For PNG; это значение указывает, что должно быть чередовано выходное изображение. Это - булево значение, сохраненное в NSNumber.]


Цвет

Несколько новых методов фабрики поддерживают дополнительные системные цвета:

- keyboardFocusIndicatorColor: - Цвет для использования для рисования клавиатурного фокуса звонит вокруг текстовых полей и кнопок.
- headerColor: - Цвет фона для ячеек заголовка в Table/OutlineView.
- headerTextColor: - цвет текста для ячеек заголовка в Table/OutlineView

X-сервер MacOS теперь поддерживает динамическое обновление цветовых схем; если пользователь изменяется, любая система раскрашивает Предпочтительное приложение, приложения будут обновлены динамично. Если Вы создаете или кэш какие-либо пользовательские цвета на основе системных цветов, Вы, возможно, должны были бы слушать NSSystemColorsDidChangeNotificationand, принимают соответствующие меры, когда обновляется цветовая схема.

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


Новые типы C

NSPointArray определений типов, NSSizeArray, NSRectArray и NSRangeArrayare добавили к Основе и AppKit для указания методов и функций, берущих C-массивы NSPoint, NSSize, NSRect и NSRange.

Точно так же NSPointPointer определений типов, NSSizePointer, NSRectPointer и NSRangePointerare добавили для указания методов и функций, возвращающих NSPoints, NSSizes, NSRects и NSRanges ссылкой.

Эти определения типов действительно не изменяют API, но они действительно разъясняют намерения нескольких методов, берущих указатели на структуры, позволяющие мосту Java преобразовать их правильно.


FontManager

Методы availableFontFamilies, availableMembersOfFontFamily: и localizedNameForFamily:face:are добавил для предоставления большей информации о семействах шрифтов.


Окно

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

Набор Приложения теперь поддерживает утилиту, ищут панели. Это обычно используется для маленьких немодальных панелей, плавающих и скрывающихся, когда приложение деактивировано, такие как палитра инструментов. Служебное окно является плавающей панелью по умолчанию, но можно отключить это поведение путем вызова setFloatingPanel:with параметра НЕТ.

Можно создать служебные окна программно с NSUtilityWindowMaskstyle (который должен быть указан в сочетании с NSTitledWindowMask), или в Интерфейсном Разработчике, путем включения «служебного окна» опция в инспекторе Атрибута Панели.

«Минимизировать» атрибут, измененный на windowshade окна в Выпуске Developer 1, теперь или минимизирующий или windowshades в зависимости от пользовательской настройки.

Известной проблемой в этом выпуске является поведение окон, отмеченных как «Видимое в запуске» в Интерфейсном Разработчике. Когда приложение запускается, они становятся видимыми, но они не становятся ключевыми даже при том, что приложение активно. Для окна для становления ключевым, makeKeyAndOrderFront:must быть явно вызванным.


URL

Класс NSURL был добавлен к платформе Основы. В этом выпуске класс только поддерживает файл URLs.

Различные классы в Основе и Средах разработки приложения имеют новый APIs, берущий URLs в дополнение к именам файлов. Например, initWithContentsOfFile:now NSDATA имеет параллель initWithContentsOfURL:. Можно теперь возвратить массив URLs от открытой панели вместо массива имен файлов. Если Ваше приложение начнет использовать этот новый APIs, то оно наследует более богатое поведение (такое как доступ к файлам и ресурсам по сети), когда класс NSURL будет расширен в будущих выпусках.


HTML

initWithHTML:documentAttributes:method NSAttributedString был осужден в пользу initWithHTML:baseURL:documentAttributes: который обеспечивает способ предоставить надлежащий базовый URL.

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


Изображение

Вызов NSImage's imageNamed:method с не существующими изображениями может быть дорогостоящим, вызвав поиск основного пакета приложения и Среды разработки приложения. Если Вы хотите обнаружить такие вызовы к этому методу, запустить Ваше приложение с набором NSLogMissingNamedImagesdefault к YES (как со всеми значениями по умолчанию, это может также быть указано через командную строку).


Ползунок

Метод setKnobThickness:currently не имеет никакого эффекта.


Распределенные уведомления

Платформа Основы теперь содержит NSDistributedNotificationCenter, класс для отправки уведомлений между процессами на единственной машине. В дополнение к основным характеристикам в NSNotificationCenter этот класс обеспечивает способ установить поведение приостановки на уведомлениях: можно заставить их быть сразу поставленными всем приложениям или задержанными, пока не приостановлены приложения. Набор Приложения гарантирует, чтобы приложения стали приостановленными, когда они деактивированы.

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


BezierPath

Еще существуют не документирующиеся существенные изменения в NSBezierPath APIs. См. заголовочный файл для нового API.

Совместимость не сохранялась между старым и новым APIs, поэтому более ранний код, использовавший NSBezierPath, должен быть перекомпилирован.


Менеджер по вводу

Этот выпуск представляет некоторый дополнительный метод ввода API. В ядре взаимодействия insertText:and setMarkedText:selectedRange:can получает экземпляр NSAttributedString как их параметры, где они были ограничены NSString в предыдущих выпусках. Входные серверы, как ожидают, запросят допустимые атрибуты с validAttributesForMarkedTextmethod. В настоящее время следующие атрибуты поддерживаются NSTextView для отмеченного текста: основной цвет (NSForegroundColorAttributeName), цвет фона (NSBackgroundColorAttributeName) и подчеркивание (NSUnderlineAttributeName).

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

Когда Выпуск Developer 2 поставки, веб-сайт Поддержки разработчиков Apple сделает доступным исходный код для демонстрационного метода ввода, использующего новый APIs для реализации шестнадцатеричного метода ввода (разрешающий Вам ввести шестнадцатеричное число для указания любого символа Unicode).


OutlineView и TableView

Путем вызова setAutosaveTableColumns:you может получить конфигурацию столбца (такую как упорядочивание и размеры) таблицы или обрисовать в общих чертах представление, которое будет сохранено, на пользователя, под ключом, указанным через setAutosaveName:. Это работает во многом как функция сохранения кадра в NSWindow. Представление схемы также обеспечивает дополнительный метод, setAutosaveExpandedItems: чтобы позволить приложениям сохранить состояние расширения просматриваемых данных. Для включения этого необходимо будет также реагировать на новые методы источника данных, позволяющие представлению схемы архивировать элементы.

Дополнительные методы делегата и уведомления в NSOutlineView позволяют экземплярам передавать расширение и разрушение элементов.


Представление

Метод печати knowsPagesFirst:last:has осуждаемый в пользу knowsPageRange: который проще отобразить на Java. Старый метод продолжит работать, но больше не будет документироваться.


Текст

Вызовите setAllowsUndo:with параметр YES для включения отмены в текстовой системе.


Коннекторы IB

Если Вы пишете Вашему собственному инспектору соединения для IB, можно хотеть использовать NSNibControlConnector, NSNibOutletConnector и классы NSNibConnector. NSNibControlConnector обеспечивает соединение цели/действия между объектами в файле пера. NSNibOutletConnector обеспечивает соединение розетки между объектами в файле пера. NSNibConnector является общим базовым классом; можно хотеть разделить его на подклассы для собственных коннекторов между объектами.


DataLinks

DataLinks, сделанные устаревшими между NextStep и выпусками OPENSTEP, были удалены из платформы.


ComboBox

NSComboBoxCell теперь обеспечивает автоматическое завершение ввода.


Клавиатура UI

Путем клавиатура, UI запускается на X-сервере MacOS, была изменена. В окнах без доступных для редактирования текстовых полей, поражая Вкладку введет Вас в режим UI клавиатуры; до того времени клавиатурный фокус не будет ни на каком объекте пользовательского интерфейса. В окнах с доступными для редактирования текстовыми полями, если начальный первый респондент не был указан, текстовое поле будет иметь фокус, когда окно будет переведено в рабочее состояние. На Windows ситуация состоит в том, как это было; т.е. это работает как Windows, делает.

На X-сервере MacOS Стрелка вверх команды и Стрелка вниз команды раньше изменяли упорядочивание окон (не делая их ключевыми). Это больше не имеет место.

Клавиша выхода (Esc) теперь больше не выходит из завершения по умолчанию; вместо этого, это отменяет текущее действие (обычно отклоняющий панели). Для возврата Escape к завершению создайте или отредактируйте файл DefaultKeyBinding.dict в ~/Library/KeyBindings так, чтобы это содержало эту строку:
{
"\033" = "complete";
}

CStringText

Рассмотрите NSCStringText, и все связали API (все в obsoleteNSCStringText.h), чтобы быть осужденными. Несмотря на то, что этот код продолжит работать некоторое время, он настоятельно рекомендован это, Вы переключаетесь на новую текстовую систему, обеспечивающую намного больше функциональности намного более чистым способом. Если существуют какие-либо причины, препятствующие тому, чтобы Вы переместились в новую текстовую систему, сообщите нам посредством Поддержки разработчиков.



Отмечает определенный для выпуска Developer 1

В DR1 Набор Приложения включает эти новые классы, функции, и изменяется начиная с OpenStep 4.2:


NSPICTImageRep

Класс для объектов, представляющих изображения PICT. Для Выпуска Developer, только растровая работа PICTs.


NSProgressIndicator

Класс для объектов, реализующих определенный или неопределенный индикатор хода выполнения. Неопределенный индикатор хода выполнения может быть анимирован в отдельном потоке, позволив его использование даже в коде вычисления, не использующем цикл выполнения.


NSTabView и NSTabViewItem

Классы для отображения многократных вкладок использования представлений.

NSOutlineView

Подкласс NSTableView, реализующего представление схемы иерархических данных. Как NSTableView и объекты NSBrowser, объекты NSOutlineView используют источник данных (отдельный от делегата) для отображения данных лениво.


NSColor

Новые методы фабрики создают объекты, представляющие дополнительные цвета пользовательского интерфейса.


NSColorPanel

Как делает панель Font, панель Color теперь имеет кнопку Set. Когда щелкнувшийся, это отправляет changeColor:message вниз цепочку респондента. См. документацию NSColorPanel для подробных данных.


NSFont

systemFontOfSize:and boldSystemFontOfSize:methods был осужден в пользу других методов фабрики, возвратив выбранные пользователями шрифты. Функциональный NSConvertGlyphsToPackedGlyphs () был добавлен, чтобы позволить Вам преобразовывать массив NSGlyphs к «упакованным» глифам, подходящим для передачи PostScript.


NSImage и NSBitmapImageRep

NSImage и NSBitmapImageRep могут теперь считать GIF, JPEG и изображения PNG непосредственно (т.е. без средства служб фильтра). Запись JPEG и PNG также поддерживается; запись GIF планируется будущий выпуск. Некоторый APIs был добавлен к NSBitmapImageRep для оказания поддержки для функций, найденных в этих типах файла изображения.


NSBezierPath и NSAffineTransform

Эти два класса помогают обеспечить более полную абстракцию в уровне платформы Набора Приложения для графических операций. NSBezierPath включает стандартные операции со строками, определяемыми пользователем путями и массивами глифов, такими как перечеркивание, заполнение и отсечение. Это также обеспечивает простые методы обнаружения вычисления и хита границ. NSAffineTransform обеспечивает абстракцию для графической матрицы преобразования.


NSGraphicsContext

Абстрактный суперкласс для NSDPSContext, этот класс обеспечивает методы, чтобы сохранить и восстановить состояние графики и изменить текущий графический контекст.


NSGraphics (Java)

NSGraphics имеет три метода класса, не работающие правильно в DR2 (вызывающий их, не имеет никакого эффекта):
fillRectList(NSRect[])
fillRectListWithColors(NSRect[], NSColor[])
clipRectList(NSRect[])
Вместо этих методов, используйте соответствующие «inRange» методы:
fillRectList(rects) ==>
fillRectListInRange(rects, new NSRange(0, rects.length))
fillRectListWithColors(rects, color) ==>
fillRectListWithColorsInRange(rects, colors, new NSRange(0, rects.length))
clipRectList(rects) ==>
clipRectListInRange(rects, new NSRange(0, rects.length))

NSSplitView

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


NSScreen

Новый метод visibleFramesupplies применимая область (без строки меню или областей панели задач) данного экрана.


Кнопка меню и классы кнопки всплывающего меню

Меню и кнопки всплывающего меню изменились значительно начиная с OpenStep 4.2. В 4,2, NSMenu и NSMenuItem утверждали, что они были подклассами NSObject, но они были фактически подклассами NSPanel и NSButtonCell. Несмотря на то, что компилятор предупредил бы о панели или сообщениях ячейки, отправляемых в эти объекты, они выполнят как требуется во время выполнения. В новой реализации NSMenu и NSMenuItem являются истинными подклассами NSObject. Если Ваш код отправляет, сообщения к этим objects&emdashwhich принимают наследование от NSPanel, и NSButtonCell&emdashit больше не будет работать.

NSMenu и NSMenuItem включают новый APIs и функциональность. NSMenuItems может теперь иметь заголовки, ключевые эквиваленты, изображения, и утвердить изображения. NSMenus имеют специфичное для платформы представление меню, отвечающее за представление меню пользователю и разрешению пользователю взаимодействовать с ним. На Махе представлением меню является NSMenuView. NSMenuView позволяет много запаса времени в способе, которым меню работает и смотрит. NSMenuView использует NSMenuItemCells для рисования его элементов. На Windows класс представления меню является в настоящее время частным (menuRepresentationmethod NSMENU возвратит ноль).

Протокол NSMenuItem был осужден в пользу класса NSMenuItem. Используйте класс вместо протокола, который будет отброшен от Набора Приложения в будущем выпуске. Существует теперь общедоступный класс NSPopUpButtonCell. См. справочную документацию Набора Приложения для подробных данных нового APIs.

Некоторые запланированные опции еще не реализованы, такие как слеза offs и ключевые эквивалентные переопределения. Вам не придется сделать ничего специального для подготовки приложения к этим ближайшим функциям. Контекстные меню поддерживаются в Выпуске Developer, но только для систем с мышами с двумя кнопками. Поддержка будет добавлена в более поздней поддержке выпуска контекстных меню Щелчка управления. Вашему коду не придется измениться, но необходимо знать, что использование клавиши CTRL для собственных специальных функций мыши является, вероятно, не хорошей идеей, так как та модифицирующая клавиша будет скоро иметь другое значение.



NSSlider

Ползунки теперь поддерживают метки, идентифицирующие определенные значения на континууме ползунка. Щелчок по этим меткам возвращает представленное значение.


NSTextView

Объекты NSTextView могут теперь считать файлы HTML. Метод делегата предоставлен для пройти по ссылкам HTML.

Методы делегата для щелчка по ячейкам были увеличены с параметром для указания индекса символа щелчка; например, textView:clickedOnCell:inRect:atIndex:instead textView:clickedOnCell:inRect:. Старые методы делегата будут продолжать работать, но необходимо запланировать заменить их новыми.

Текстовая система теперь обрабатывает управление-L («перевод формата») как контейнерный символ разрыва. Управление-L вынуждает расположение продолжаться на следующий контейнер. Однако текстовая система также пытается распознать бесконечно растущий контейнерный случай (который является обычной ситуацией в приложениях, таких как TextEdit и Разработчик Проекта), и игнорирует управление-L в этих случаях.


NSApplication

Когда последнее окно закрывается, на платформах не-Windows приложение может теперь принять решение выйти. Если делегат приложения отвечает на возврат applicationShouldTerminateAfterLastWindowClosed:by ДА, заявление послано terminate:message, когда закрывается последнее окно.

В системах Windows не было никакого изменения. Если последнее окно приложения закрывается, и если окно содержало меню приложения, заявление послано terminate:message по умолчанию. Делегат может предотвратить это путем ответа НЕ на applicationShouldTerminateAfterLastWindowClosed:.


NSWindow

Вместо миниатюризации, окна теперь используют функцию под названием WindowShading: когда пользователь щелкает по надлежащему управлению окном, представление содержания окна исчезает, и просто строка заголовка остается (это может быть переключено назад к исходному состоянию). Windows также имеет кнопку изменения масштаба, переключающую окно между стандартом (размер к адаптации) размер и пользовательским размером. Стандартный размер может быть установлен вызовами в делегата.

Значок документа в строке заголовка предоставляет доступ к документу, представленному окном; пользователи могут перетащить документ непосредственно (это заменяет, «Перетаскивают альтернатива от миниатюризировать кнопки» модель OPENSTEP 4.2).


NSView

Два новых метода в NSView, didAddSubview:and willRemoveSubview: обеспечьте способы обнаружить изменения списка подпредставления.


NSCell и NSButtonCell

Эти классы теперь поддерживают ячейки смешанные состояния. Можно активировать эту опцию с thesetAllowsMixedState:method, позволяющим ячейке быть в режиме NSMixedState в дополнение к NSOnState и NSOffState. Кроме того, различные стили внешней панели были добавлены для поддержки диапазона стилей кнопки, доступных на Mac:

- NSRoundedBezelStyle
- NSRegularSquareBezelStyle
- NSThickSquareBezelStyle
- NSThickerSquareBezelStyle

(Несмотря на то, что заголовочный файл относится к NSNeXTBezelStyle, NSPushButtonBezelStyle, NSSmallIconButtonBezelStyle, NSMediumIconButtonBezelStyle и NSLargeIconButtonBezelStyle, эти стили являются устаревшими и не должны использоваться.)


Java

Выпуск Developer содержит альфа-версию Java APIs для Желтого Поля. При помощи этого APIs можно получить доступ фактически ко всем классам и протоколам платформ Набора и Основы Приложения. Однако, так как это - альфа-версия, этот APIs еще не завершен и наиболее вероятно изменится перед следующим выпуском.


Стиль интерфейса

Постоянный NSMacintoshInterfaceStyle был добавлен для представления пользовательского интерфейса MacOS. NSNextStepInterfaceStyle был удален.

При создании ресурсов используйте суффиксы «-макинтош» и «-окна» для указания любых ресурсов, которые являются определенными для определенного стиля интерфейса. Основной ресурс должен быть доступным (например, foo.nib); все другие стиль интерфейса определенные (такие как foo-windows.nib) являются дополнительными. Это - функция NSBundle и будет работать с любым ресурсом, не просто перьями.



Сводка изменений между NextStep 3.3 и OpenStep 4.2

Этот раздел предоставлен как краткое руководство по по разработчикам, преобразовывающим приложения от NextStep 3.x до Желтого Поля. OpenStep 4.2 был последним выпуском, поставленным NeXT перед закупкой Apple.

Изменения между NextStep 3.3 и OpenStep 4.0

OpenStep: Выпуск 4.0 вносит многочисленные изменения API в AppKit относительно Выпуска 3.3. Инструменты и сценарии, предоставленные для преобразования 3.x приложение к OpenStep, включены с 4.x выпуски в/NextLibrary/Documentation/NextDev/Conversion/ConversionGuide....

Новая текстовая Система: Выпуск 4.0 включает новую текстовую систему, составленную из нескольких различных классов: NSTextView (фронтэнд UI), NSTextStorage и NSAttributedString (текстовое хранение бэкэнда), NSLayoutManager (управление текстовым процессом создания макета и информацией), и NSTextContainer (описание текстовых областей потока). Эти классы обеспечивают открытый, мощный интерфейс и позволяют редактирование текста на нескольких языках, с помощью стандарта Unicode.

FileWrapper: NSFileWrapper, новый класс, предоставляет поддержку для понятия обертки документа (как .rtfd или.... перо). Это обрабатывает чтение и запись пакетов файла в файловой системе, а также сериализации их для использования с Областью монтажа.

TableView: класс табличного представления DBKIT был полностью переписан и перемещен в AppKit как NSTableView. Все четыре класса, составляющие новый TableView, являются общедоступными и полностью подподдающимися классификации.

Клавиатура UI: доступ Клавиатуры теперь предоставлен для большинства средств управления в AppKit.

Форматирование и Проверка: Ячейки могут теперь быть присвоенными значениями произвольного объекта, преобразовывающимися в строки представления связанными объектами средства форматирования. Это позволяет разработчику непосредственно устанавливать NSDate, например, как значение ячейки. Связанное средство форматирования даты ячейки представит представление локализованной строки даты пользователю. Объекты средства форматирования, вместе с делегатами управления, могут также выполнить проверку на вводимых пользователями данных, таким образом ограничив записи в допустимые диапазоны или количества.

Обогащенный текст в Ячейках: NSCell и подклассы могут теперь вывести на экран и отредактировать обогащенный текст. Обогащенный текст указан через экземпляры NSAttributedString. Новое форматирование/проверка API также включает поддержку приписанных строк.

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

Системные Цвета: Новый API был добавлен для доступа к определенным с помощью системы цветам, таким как цвет кнопок, средств управления, текста и текстовых цветов выделения. На Windows, где пользователь может изменить системные цвета в любой точке, эти цвета изменятся во время выполнения для соответствия выбора пользователя.

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

NSApplicationMain: AppKit теперь предоставляет функциональному NSApplicationMain (), чтобы заботиться об инициализации и запуске Вашего приложения. Эта функция объявляется в NSApplication.h.

ObjectLinks: ObjectLinks были удалены из спецификации OpenStep, и в целом функция не поддерживается в OpenStep для Маха или Windows.

Система справочной информации: Справка AppKit API изменилась значительно. NSHelpPanel был obsoleted в пользу нового класса, NSHelpManager, обеспечивающего более независимый от платформы подход к представлению и контекстно-зависимая и всесторонняя справка.

Изменения между OpenStep 4.0 и OpenStep 4.1

ComboBox: класс NSComboBox был добавлен к Набору Приложения. Это предлагает функциональность, которая подобна управлению Полем комбинированного списка, используемому в интерфейсе пользователя Microsoft Windows.

Экран-заставка: OpenStep для Windows теперь предоставляет поддержку для экрана «всплеска» в приложениях; это - в основном панель, придумывающая статическое изображение, поскольку запускается приложение. Для использования этой функции просто обеспечьте 8-разрядный несжатый битовый массив (.bmp) изображение по имени Splash.bmpas ресурс в приложении. Можно сделать его локализуемым, если Вы желаете (таким образом, изображение может быть любой в appname.app/Resources/or appname.app/Resources/language.lproj/),

NSApplication: По умолчанию, на OpenStep для Windows, только единственная копия приложения будет запущена. Если Вы хотите выполнить многократные копии, необходимо использовать, указывают значение НЕ к-NSUseRunningCopycommand опции строки. Кроме того, все параметры командной строки, которые не являются опциями значений по умолчанию (значение пары параметров, где первый запускается с «-») теперь обрабатываются как имена файлов, которые будут открыты, как будто они были снабжены префиксом-NSOpen. В результате этих двух изменений можно теперь связать документы с приложениями OpenStep на Windows просто путем указания расположения приложения. Если существует тот, командная строка по умолчанию, предоставленная Проводником, достаточна, чтобы открыть документы и также соединиться с рабочей копией приложения.

Окно отредактировало состояние: В OpenStep для Windows звездочка в строке заголовка окна указывает, что был отредактирован ассоциированный документ.

Отслеживание прямоугольников: Отслеживающие прямоугольники теперь реализованы на Windows.

NSWindow структурируют по сравнению с содержанием rect: На Windows frameRect и contentRect NSWindow в настоящее время являются тем же размером. Таким образом frameRect NSWindow не включает строку заголовка, строку меню, изменяет размеры границы, и т.д. (но делает на Махе). Кроме того, contentView, в то время как окно миниатюризировано, является NSImageView, не исходный contentView. Когда окно является deminiaturized, contentView восстанавливается.

NSTextView: На Windows, чтобы позволить вводить символ без надлежащей клавиатуры, можно теперь использовать Alternatekey в сочетании с ключами цифры от клавиатуры. При удержании клавиши Alternate введите индекс требуемого символа в кодировании текущего шрифта (в большинстве случаев, это будет NEXTSTEP, кодирующим). Когда клавиша Alternate будет отпущена, надлежащий символ будет вставлен в текст.

Изменения между OpenStep 4.1 и OpenStep 4.2

SplitView: NSSplitView теперь поддерживает горизонталь также вертикальные разделения.

ToolTips: теперь возможно добавить «подсказки» (короткие сообщения справки, раскрывающиеся, поскольку пользователь содержит курсор мыши по элементу) к представлениям. Можно сделать это программно или при помощи панели Help Интерфейсного Разработчика.

Текстовая Расстановка переносов и Выравнивание: текстовый объект теперь поддерживает полное выравнивание и расстановку переносов с довольно основным API.

Ячейка ComboBox: существует теперь общедоступный класс NSComboBoxCell. Эта функция позволяет Вам использовать поля комбинированного списка в табличных представлениях среди других мест.

Сокрытие приложений на Windows: Поддержка «скрывается, приложение» команда было добавлено на OpenStep для Windows. Пункт меню по умолчанию для этого, Минимизируют Все в меню Windows (с Управлением-h как ключевой эквивалент). Кит Приложения добавляет этот элемент автоматически, если это не находится в меню.

Проблема архивации CMYK: ошибка в decodeNXColorthat вызвала цвета CMYK от 3.x были фиксированы, архивы, которые будут считаны неправильно в 4,0 и 4.1. (Цвета были путем от основы; вместо C, использовались M, Y, K, значения 1-C, 1-M, 1-Y, и 1-K.)