Как портативные приложения вызываются системой при необходимости (например, сопоставление файлов)? - PullRequest
2 голосов
/ 10 января 2011

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

Поскольку Windows «устанавливает» приложения, размещая файлы повсюду и изменяя параметры в реестре, ассоциации файлов можно легко выполнить. Но, скажем, я только что скачал MPlayer для Mac OS X (или чего-то еще). Я хочу, чтобы все мои фильмы открывались в MPlayer. Затем я решаю переместить пакет приложений MPlayer (эй, он переносной, верно?). Разрушится ли ассоциация? Или это не так, как это делается на OS X?

Как реализовать переносимые приложения в Linux? Должно ли это быть похоже на модель OS X? Я знаю, что это очень открытый вопрос, но любые предложения приветствуются.

Ответы [ 2 ]

2 голосов
/ 10 января 2011

База данных служб запуска OS X отслеживает привязки документов несколькими способами - как правило, изо всех сил старается сопоставить приложение, даже если вы его переместили.

Вы можете запустить lsregister -dump (lsregister is /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister), чтобы увидеть, что говорит база данных Launch Services о привязке. Например, если я связываю текстовые файлы для открытия с помощью TextWrangler, я вижу:

handler id:            3124
    content type:  public.plain-text
    options:       
    all roles:     com.barebones.textwrangler (0x3ea30180)

public.plain-text - это Унифицированный идентификатор типа (который соответствует одному или нескольким расширениям файлов, типам MIME и т. Д. И может иметь подтипы), представляющий простой текст, а com.barebones.textwrangler - идентификатор пакета TextWrangler.

Я не знаю ни одного стандарта Linux, столь же надежного, как этот, для привязки документов - для того, чтобы сделать что-то вроде Mac, во-первых, должен быть стандартный метод идентификации приложений независимо от их местоположения или имени (например, Java). метод «пакетный / обратный DNS» на Mac), затем реестр для сопоставления типов и привязок, за которым последовало достаточное количество рабочих сред, чтобы быть полезным, и некоторый способ регистрации приложений по мере их установки.

Вам не обязательно нужны отдельные файлы, такие как Info.plist в пакетах приложений Mac, для хранения этой информации; даже в Mac OS X вы можете встраивать информацию в двоичный раздел, который прекрасно запускает индексы Launch Services (обратите внимание, что это не отдельный «ответвление» или расширенный атрибут; это похоже на встраивание отладочной информации в исполняемый файл). Так что, возможно, некоторые производные файлов .desktop могут быть встроены. С другой стороны, вам нужен способ распознавания контента. В идеале вы могли бы даже анализировать содержимое, например, команду file(1), чтобы определить тип документа; Классическая Mac OS сделала это с помощью диспетчера переводов (который позволял регистрировать конвертеры из одного формата в другой, а также снифферы).

ИМП и диспетчер переводов обрабатывают (d) буфер обмена и перетаскивают содержимое, а также файлы на диск; объединение этих форматных представлений очень полезно, пока вы на нем.

2 голосов
/ 10 января 2011

Каждый файловый браузер (например, Nautilus, Konqueror) должен быть настроен на использование своих собственных файловых ассоциаций. К счастью, проект Free Desktop работал над стандартизацией файловых ассоциаций (среди многих других вещей). Согласно описанию общей базы данных MIME , формальная спецификация еще не написана, но формат в значительной степени стандартизирован.

Проект Free Desktop также использует .desktop файлы для обеспечения «переносимости» (возможно, вам следует использовать другое слово для этого ... возможно, «подвижный»?). Если вы переместите исполняемый файл за пределы PATH, вы можете обновить .desktop, указав правильное местоположение.

По сути, в сообществе Linux ведется большая работа, направленная на более удобные для пользователя и удобные для разработчика (то есть стандартизированные) способы достижения этих целей. Но дела еще не сделаны.

...