С сосуществующими унаследованными и современными приложениями Mac невозможно связать глобально связанные документы с современным приложением (Launch Services?)
Обновлено 4-9-2013 Это полный репост моего предыдущего вопроса. Поскольку я узнал намного больше о Launch Services, UTIs и устаревших кодах создателей, я чувствую, что могу лучше задать вопрос с нуля.
Описание проблемы:
У нас есть приложение, разработанное для Legacy Mac 9.xx, которое все еще работает на Snow Leopard(с Rosetta). Приложение использует связанные файлы. Мы разработали наше новое приложение для Snow Leopard и не только. Проблема в том, что Launch Services неправильно связывает новое приложение на основе конфигурации plist, которую мы используем в настоящее время, и мне нужно знать, что я делаю неправильно.
Если я щелкну правой кнопкой мыши по документу в комплекте и выберу GetInfo, я могу связать файл в комплекте с устаревшим приложением или новым приложением, и оно будет работать так, как я ожидаю. Я полагаю, что это потому, что снежный барс все еще использовал технологию Creator Code для этого типа ассоциации. Если я скажу файлу связать себя со старым унаследованным приложением и нажму "Изменить все", Launch Services корректно свяжет все файлы этого типа и будет работать как положено. Если я скажу файлу присоединиться к новому приложению и выберу "Изменить все", приложение откроется, а файлы - нет. Из того, что я могу сказать, Launch services назначает приложению динамический UTI, и при щелчке файла ОС не знает, какое приложение использовать.
Я нашел пару постов, которые, кажется, предполагают, что Apple, возможно, допустила некоторые ошибки проектирования в новой методологии UTI. В одном посте показано, как добавить массив строковых расширений файлов в словарь ExportedUTIs новых приложений pList. Это заставляет приложение функционировать правильно, но это не решит проблему; Если мы позволим нашим пользователям называть свои файлы как угодно, мы не сможем предсказать в массиве, каким будет их расширение. Нам нужны службы запуска для корректной работы строго с кодом UTI, или как-то, как заставить работать код OSType.
Как только новое приложение решит, что оно не может открыть связанный с ним файл, мне нужно открыть LanchServices.plist, удалить запись и перезапустить базу данных lsregister. Затем я могу снова открыть файл с новым приложением (связав его, не нажимая "Изменить все").
Я прикрепляю некоторые изображения к спискам приложений, списку документов в комплекте и записи Launch Services:
Любая помощь и наше руководство высоко ценится.
Майк
Обновлено: 16.04.2013
Ссылка на пост о UTI, который я предоставил, также содержит ссылку на приложение с открытым исходным кодом, которое называется RCDefault. Это приложение будет связывать ваше приложение с данным файлом на основе вашего выбора UTI, расширений файлов, кодов OSType и типов файлов. Странно, но это приложение может связать файл с приложением на основе структуры UTI, представленной в наших списках.
Возможно ли, что это всего лишь ошибка в Launch Services for Snow Leopard для этого конкретного сценария, и Apple решила просто игнорировать ее в данный момент (учитывая, что они больше не поддерживают Snow)?
2 ответа
Вы пропускаете ваши CFBundleTypeExtensions. Создайте CFBundleTypeExtensions типа Array, и Item 0 должен быть вашим расширением файла.
Вам также не хватает вашего CFBundleTypeName, типа псевдонима, который будет использовать файл. Делает это красиво и красиво.:)
Ссылка (CFBundleDocumentTypes): https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
Прошло некоторое время с тех пор, как я первоначально разместил это, но на случай, если это кому-нибудь еще интересно, я сделал несколько дополнительных открытий:
Эта проблема не имеет ничего общего с попыткой совместимости с устаревшим приложением и приложением OSX. В комплекте файл содержит код создателя и код OSType. Пока эти два элемента существуют в списке старых приложений, он будет открываться, когда бы его ни попросили, глобально или индивидуально.
Похоже, проблема заключается в попытке включить код ostype в новый список приложений в качестве эквивалентного типа в UTI экспортированного типа.
Единственное решение, которое, кажется, работает, это добавить массив расширений имен файлов в качестве эквивалентного типа, как @Derek, упомянутый для начала.
Это единственное решение, которое решает эту проблему. По иронии судьбы это нарушает руководящие принципы интерфейса пользователя apple, которые в некоторой степени гласят, что пользователь не должен подвергаться ограничениям расширений файлов.
Похоже, что UTI работает только с не связанными документами (файлами), что также поддерживается несколькими публикациями, в которых говорится, что Apple действительно облажалась. Какой смысл беспокоиться о UTI, если в конце концов вам все равно нужен массив расширений?