Меню

Формат файла desktop linux

Desktop entries

The XDG Desktop Entry specification defines a standard for applications to integrate into application menus of desktop environments implementing the XDG Desktop Menu specification.

Contents

Basics

Each desktop entry must have a Type and a Name key and can optionally define its appearance in the application menu.

The three available types are:

Application Defines how to launch an application and what MIME types it supports (used by XDG MIME Applications). With XDG Autostart Application entries can be started automatically by placing them in specific directories. Application entries use the .desktop file extension. See #Application entry. Link Defines a shortcut to a URL . Link entries use the .desktop file extension. Directory Defines the appearance of a submenu in the application menu. Directory entries use the .directory file extension.

The following sections will roughly explain how these are created and validated.

Application entry

Desktop entries for applications, or .desktop files, are generally a combination of meta information resources and a shortcut of an application. These files usually reside in /usr/share/applications/ or /usr/local/share/applications/ for applications installed system-wide, or

/.local/share/applications/ for user-specific applications. User entries take precedence over system entries.

File example

Following is an example of its structure with additional comments. The example is only meant to give a quick impression, and does not show how to utilize all possible entry keys. The complete list of keys can be found in the freedesktop specification.

Key definition

All recognized entries can be found on the freedesktop site. For example, the Type key defines three types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3).

  • Version key does not stand for the version of the application, but for the version of the desktop entry specification to which this file complies.
  • Name , GenericName and Comment often contain redundant values in the form of combinations of them, like:

This should be avoided, as it will only be confusing to users. The Name key should only contain the name, or maybe an abbreviation/acronym if available.

  • GenericName should state what you would generally call an application that does what this specific application offers (i.e. Firefox is a «Web Browser»).
  • Comment is intended to contain any useful additional information.

Validation

As some keys have become deprecated over time, you may want to validate your desktop entries using desktop-file-validate(1) which is part of the desktop-file-utils package. To validate, run:

This will give you very verbose and useful warnings and error messages.

Installation

Use desktop-file-install(1) to install desktop file into target directory. For example:

Update database of desktop entries

To make desktop entries defined in

/.local/share/applications work, run the following command:

Icons

Common image formats

Here is a short overview of image formats commonly used for icons.

Support for image formats for icons as specified by the freedesktop.org standard.

Extension Full Name and/or Description Graphics Type Container Format Supported
.png Portable Network Graphics Raster No Yes
.svg(z) Scalable Vector Graphics Vector No Yes (optional)
.xpm X PixMap Raster No Yes (deprecated)
.gif Graphics Interchange Format Raster No No
.ico MS Windows Icon Format Raster Yes No
.icns Apple Icon Image Raster Yes No

Converting icons

This article or section is a candidate for merging with ImageMagick#Usage.

If you stumble across an icon which is in a format that is not supported by the freedesktop.org standard (like gif or ico ), you can use the convert tool (which is part of the imagemagick package) to convert it to a supported/recommended format, e.g.:

If you convert from a container format like ico , you will get all images that were encapsulated in the ico file in the form — .png . If you want to know the size of the image, or the number of images in a container file like ico you can use the identify tool (also part of the imagemagick package):

As you can see, the example ico file, although its name might suggest a single image of size 48×48, contains no less than 6 different sizes, of which one is even greater than 48×48, namely 128×128.

Alternatively, you can use icotool (from icoutils ) to extract png images from ico container:

For extracting images from .icns container, you can use icns2png (provided by libicns ):

Obtaining icons

Although packages that already ship with a .desktop file most certainly contain an icon or a set of icons, there is sometimes the case when a developer has not created a .desktop file, but may ship icons, nonetheless. So a good start is to look for icons in the source package. You can i.e. first filter for the extension with find and then use grep to filter further for certain buzzwords like the package name, «icon», «logo», etc, if there are quite a lot of images in the source package.

If the developers of an application do not include icons in their source packages, the next step would be to search on their web sites. Some projects, like i.e. tvbrowser AUR have an artwork/logo page where additional icons may be found. If a project is multi-platform, there may be the case that even if the linux/unix package does not come with an icon, the Windows package might provide one. If the project uses a Version control system like CVS/SVN/etc. and you have some experience with it, you also might consider browsing it for icons. If everything fails, the project might simply have no icon/logo yet.

Читайте также:  Air print mac os x lion

Icon path

The freedesktop.org standard specifies in which order and directories programs should look for icons:

  1. $HOME/.icons (for backwards compatibility)
  2. $XDG_DATA_DIRS/icons
  3. /usr/share/pixmaps

Tools

gendesk

gendesk started as an Arch Linux-specific tool for generating .desktop files by fetching the needed information directly from PKGBUILD files. Now it is a general tool that takes command-line arguments.

Icons can be automatically downloaded from openiconlibrary, if available. (The source for icons is configurable).

How to use

  • Add gendesk to makedepends
  • Start the prepare() function with:
  • Alternatively, if an icon is already provided ($pkgname.png, for instance). The -n flag is for not downloading an icon or using the default icon. Example:
  • $srcdir/$pkgname.desktop will be created and can be installed in the package() function with:
  • The icon can be installed with:
  • Use —name=’Program Name’ for choosing a name for the menu entry.
  • Use —exec=’/opt/some_app/elf —some-arg —other-arg’ for setting the exec field.
  • See the gendesk project for more information.

lsdesktopf

lsdesktopf AUR can list available .desktop files or search their contents.

It can also perform MIME-type-related searches. See XDG MIME Applications#lsdesktopf.

fbrokendesktop

The fbrokendesktop AUR Bash script detects broken Exec values pointing to non-existent paths. Without any arguments it uses preset directories in the DskPath array. It shows only broken .desktop with full path and filename that is missing.

Tips and tricks

Run a desktop file from a terminal

If gtk3 is installed, run gtk-launch application.desktop .

Or install the dex package and run dex /path/to/application.desktop .

Hide desktop entries

Firstly, copy the desktop entry file in question to

/.local/share/applications to avoid your changes being overwritten.

Then, to hide the entry in all environments, open the desktop entry file in a text editor and add the following line: NoDisplay=true .

To hide the entry in a specific desktop, add the following line to the desktop entry file: NotShowIn=desktop-name

where desktop-name can be option such as GNOME, Xfce, KDE etc. A desktop entry can be hidden in more than desktop at once — simply separate the desktop names with a semi-colon.

Modify environment variables

To set environment variables, copy the .desktop file from /usr/share/applications/ to $XDG_DATA_HOME/ (

/.local/share/applications/ ) and edit the Exec= command line by prepending env. For example:

Источник

Программа для создания desktop-файлов

В дистрибутивах GNU/Linux значки приложений в меню описываются специальными текстовыми файлами. Эти файлы имеют расширение .desktop и при установке приложения создаются автоматически. Но иногда бывают ситуации когда нужно самому создать такой файл. Это может быть когда у вас на руках имеется только исполняемый файл приложения, то есть когда приложение не упаковано должным образом. В некоторых дистрибутивах из коробки имеются программы для создания значков запуска, а в некоторых их нет и нужно искать такие приложения в репозиториях. Я создал свой вариант такой программы и в этом посте расскажу, что она из себя представляет.

Немного о desktop-файлах

Вот пример desktop-файла для консольной игры nsnake:

Тут и так все понятно, но я все-таки прокомментировал пару позиций. Самое главное, что нужно прописать это название приложения (Name), путь до исполняемого файла (Exec) и путь до иконки (Icon). Если иконки нет и нет желания ее искать или создавать, то некоторые окружения рабочего стола установят иконку по умолчанию.

Краткое описание

Исходники приложения находятся здесь. Программа довольно простая. Выглядит она вот так:

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

В хидербаре находится кнопка, при нажатии на которую в файловом менеджере откроется папка, находящаяся по пути /.local/share/applications. Именно там программа сохраняет созданные файлы.

Как работает

Приложение написано на языке Vala с помощью среды разработки GNOME Builder. Устанавливал самую свежую версию среды (40.0) из репозитория Flathub. Оказалось, что визуальный дизайнер в этой версии еще багованнее, чем в предыдущей, поэтому интерфейс делал в Glade.

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

При нажатии на кнопку CREATE вызывается метод on_create_file:

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

Чтобы просмотреть готовые файлы существует метод on_open_directory. Он срабатывает при нажатии на кнопку в хидербаре.

Для выбора исполняемого файла используется следующий код:

А для выбора иконки код сложнее, так как данный диалог, помимо фильтра, содержит функционал предварительного просмотра изображения:

Метод для вывода сообщений пользователю:

Чтобы проверить введено ли какое-либо значение в текстовое поле используется такой метод:

На этом все! Надеюсь, что пост был для Вас полезен.

Дополнительная ссылка на SourceForge. До встречи в следующих постах!

Читайте также:  Драйвер для ssd kingston диска windows 10

Источник

Русские Блоги

Углубленный анализ файла Linux Desktop Entry (файл * .desktop)

Почему 80% фермеров кода не могут быть архитекторами? >>>

Linux Desktop Entry — углубленный анализ файла

Краткое описание:Файлы Desktop Entry — это файлы, используемые для описания информации о конфигурации запуска программы в настольной системе Linux. Файлы Desktop Entry реализуют функциональность, аналогичную ярлыкам в операционной системе Windows. В этой статье подробно описаны определение, программирование и использование файла Linux Desktop Entry. Читатель может дополнительно углубить применение файлов Desktop Entry с помощью примеров операций в конце статьи.

На платформе Windows пользователи могут легко открыть целевое приложение, нажав на ярлык, расположенный на рабочем столе или в меню. Эта функция также доступна в современных настольных системах Linux. В настоящее время как настольные системы Linux KDE, так и Linux GNOME используют стандарт файла Desktop Entry для описания информации о конфигурации запуска программы. Стандарт файла Desktop Entry был разработан FreeDesktop.org (http://freedesktop.org/wiki/), и его последней версией является «Desktop Entry Specification 1.0» [1].

Рисунок 1. Браузер приложения Linux GNOME

Файлы рабочего стола имеют расширение «.desktop». В качестве примера рассмотрим настольную систему Linux GNOME. После открытия браузера приложений (см. Рис. 1) пользователи увидят множество ярлыков приложений. Фактически каждый ярлык приложения соответствует файлу Desktop Entry. Эти файлы рабочего стола обычно хранятся в / usr / share / apps / / opt / gnome / share / Applications / и т. Д. Введите эти каталоги в файловом браузере и щелкните соответствующий файл Desktop Entry, чтобы запустить соответствующее приложение.

Предположим, что в текущем каталоге «/ usr / share / Applications /» есть файл «cbt.desktop». Открытие «cbt.desktop» с помощью любого программного обеспечения для редактирования файлов (например, vi или gedit) приведет к следующему содержимому:

Эта статья будет посвящена файловой структуре Desktop Entry в следующем разделе в сочетании с указанным выше содержимым файла «cbt.desktop». Читатели могут понять конкретные значения приведенных выше предложений.

Файлы рабочего стола обычно начинаются со строки «[Desktop Entry]». Как видно из листинга 1, содержимое файла Desktop Entry состоит из нескольких парных записей. Например, «Версия» является ключевым словом, а значение ключевого слова «Версия» равно «1.0». Стандарт файла Desktop Entry определяет ряд стандартных ключевых слов. Стандартные ключевые слова являются обязательными и необязательными: обязательные стандартные ключевые слова должны быть определены в файле .desktop, необязательные ключевые слова — нет. Ниже приводится анализ ключевых слов.

  • Ключевое слово «Версия»: [необязательно] Это значение указывает стандартную версию файла Desktop Entry, которой следует текущий файл Desktop Entry.
  • Ключевое слово «Кодировка»: [устарело в версии 1.0] Это значение указывает кодировку, используемую для конкретной строки в текущем файле Desktop Entry. Хотя это ключевое слово больше не рекомендуется для Desktop Entry File Standard 1.0, оно все еще широко используется в существующих файлах Desktop Entry по историческим причинам.
  • Ключевое слово «Имя»: [Обязательно]
    Это значение указывает название рассматриваемой заявки. Например, значением ключевого слова «Name» в листинге 1 является «Quick Start Tour». Откройте браузер файлов, войдите в каталог «/ usr / share / apps», и вы увидите стиль отображения ярлыка, определенного файлом «cbt.desktop», как показано на рисунке 2. Отображаемое имя ярлыка определяется значением ключевого слова «Имя», а значок, используемый ярлыком, определяется значением ключевого слова «Значок», которое будет описано позже. Конечно, эти определения также применяются в браузере приложения, пожалуйста, обратитесь к рисунку 3.

Рисунок 2 «cbt.desktop» стиль отображения файла в файловом браузере

Ключевое слово «GenericName»: [необязательно]
Это значение указывает общее имя рассматриваемой заявки. Например, значение ключевого слова «GenericName» в листинге 1 — «Учебник пользователя». Откройте браузер приложения, вы увидите строку «User Tutorial», отображаемую справа от значка, как показано на рисунке 3:

Рисунок 3 «cbt.desktop» стиль отображения файла в браузере приложения

  • Ключевое слово «Комментарий»: [необязательно]
    Это значение является кратким описанием текущей записи рабочего стола.
  • Ключевое слово «Тип»: [Обязательно]
    Ключевое слово «Тип» определяет тип файла Desktop Entry. Общими значениями «Тип» являются «Приложение» и «Ссылка». «Type = Application» указывает, что текущий файл Desktop Entry указывает на приложение, а «Type = Link» указывает, что текущий файл Desktop Entry указывает на URL (Uniform Resource Locator).
  • Ключевое слово «Exec»: [необязательно]
    Ключевое слово «Exec» имеет смысл только в том случае, если типом «Тип» является «Приложение». Значение «Exec» определяет команду, которая будет выполнена для запуска указанного приложения. Команда может принимать параметры. В этом примере значением ключевого слова «Exec» является строка «gnome-open /usr/share/doc/manual/sled-gnome-cbt_en/index.html». Ввод этой строки в оболочке и нажатие клавиши Enter также запустит указанное приложение.
  • Ключевое слово «URL»: [необязательно]
    Ключевое слово «URL» имеет смысл только в том случае, если типом «Тип» является «Ссылка». Значение «URL» определяет URL, на который указывает этот файл Desktop Entry. Например:

    Перечисление 2 «Type = Link» Пример рабочего стола

    Двойной щелчок по файлу Desktop Entry, содержащему вышеуказанное, запустит веб-браузер и откроет указанную веб-страницуhttp://www.ibm.com/developerworks«Пожалуйста, обратитесь к рисунку 4 для получения результата выполнения.

  • Ключевое слово «Icon»: [необязательно]
    Это значение определяет значок, отображаемый текущим файлом Desktop Entry в браузере приложений или файловом браузере. Если значение ключевого слова «Icon» задано в формате абсолютного пути, будет использоваться файл значков, указанный в значении, в противном случае система Linux будет использовать «Icon Theme Specification» [2], чтобы найти значок в указанном системой каталоге значков. Файл значка, который будет использоваться. Например, в этом примере значение ключевого слова «Icon» равно «cbt», что фактически соответствует файлу изображения «cbt.png» в каталоге значков, заданном системой. , Эффект отображения изображения в виде значка показан на фиг.2 и фиг.3.
  • Ключевое слово «StartupNotify»: [необязательно]
    Значение ключевого слова «StartupNotify» является логическим значением (true или false). Это ключевое слово имеет смысл только в том случае, если типом «Тип» является «Приложение». Значение его значения определяется спецификацией «Спецификации протокола уведомления при запуске» [3], которая не будет подробно описана здесь.
  • Ключевое слово «Терминал»: [необязательно]
    Как и «StartupNotify», значение ключевого слова «StartupNotify» также является логическим значением, и это ключевое слово имеет смысл только в том случае, если типом «Тип» является «Приложение». Его значение указывает, нужно ли запускать соответствующее приложение (т.е. значение ключевого слова «Exec») в окне терминала. Конкретное использование ключевого слова «Терминал» приведено в следующем разделе.
  • Ключевое слово «Категории»: [необязательно]
    Ключевое слово «Категории» имеет смысл только в том случае, если тип «Тип» — «Приложение». Значение «Категории» указывает категории, которые связанные приложения отображают в меню. Конкретная классификация меню специально определяется спецификацией «Меню спецификации рабочего стола» [4].
  • Ключевые слова «OnlyShowIn» и «NotShowIn»: [необязательно]
    Эти два ключевых слова определяют, будет ли текущая запись рабочего стола отображаться (определяется «OnlyShowIn») или не отображаться (определяется «NotShowIn») в определенной настольной системе Linux (например: Linux GNOME или Linux KDE). Конкретные определения приведены в «Меню спецификаций рабочего стола» [4].
  • Ключевое слово «X-SuSE-translate»: [SUSE для Linux]
    Ключевое слово «X-SuSE-translate» — SUSE Linux (http://www.novell.com/linux/) Удельная. «X-SuSE-translate» соответствует стилю пакета SUSE RPM. Значение «X-SuSE-translate» указывает, следует ли переводить ключевые слова «Name» и «GenericName». Для получения более подробной информации, пожалуйста, обратитесь к «Соглашениям SUSE Package» [5].
  • Локализованное ключевое слово «[LOCALE]»
    Согласно спецификации «Desktop Entry Specification» [1], вы можете добавить строку «[LOCALE]» к ключевому слову, чтобы определить конкретную локализацию ключевого слова. Допустимые значения для «LOCALE»:

    Здесь поля «_COUNTRY», «.ENCODING» и «@MODIFIER» можно игнорировать. Когда указанный файл Desktop Entry анализируется, синтаксический анализатор должен правильно получить значения локализованного ключевого слова на основе текущей локали POSIX. Например, в листинге 1 определены разные значения для ключевых слов «Name», «Comment» и «GenericName» в локалях «cs» и «hu» соответственно.

  • Остальные ключевые слова
    В дополнение к ключевым словам, показанным в листинге 1, «Спецификация записи рабочего стола» также определяет необязательные ключевые слова, такие как «Скрытый», «TryExec», «MimeType» и т. Д. Пользователи могут выбирать в соответствии с их потребностями.
  • Файл Desktop Entry является распространенным форматом файлов Linux. Многие программы Linux должны обеспечивать поддержку этого файла. Здесь эта статья дает основные идеи компиляции для анализа и запуска файлов Desktop Entry.

    Первым шагом в работе с файлом Desktop Entry является получение содержимого файла. Предположим, что существует файл Desktop Entry, информация о пути которого хранится в переменной pPath:

    const char* pPath;

    Следующий код будет считывать содержимое файла в память «буфера».

    Получив содержимое файла Desktop Entry, вы можете дополнительно проанализировать содержимое файла. Здесь в центре внимания анализа находится получение значений ключевых слов «Тип», «Exec» / «URL» и «Терминал». Сначала определите структуру DestopEntryType:

    Следующая программа извлечет значения ключевых слов «Тип», «Exec» / «URL» и «Терминал» и сохранит эти значения в переменных «тип», «uri» и «bTerminal» соответственно.

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

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

    В этом разделе эта статья даст два конкретных примера создания файла Desktop Entry. Цель этих двух примеров — создать ярлык для автоматического доступа к веб-сайту IBM DeveloperWorks. Конкретные результаты показаны на рисунке 4. Эти два примера будут использовать разные методы для достижения этой цели. Первый экземпляр создаст файл записи рабочего стола «VisitDeveloperWorks-Application.desktop» из «Приложения», второй экземпляр создаст файл записи рабочего стола «VisitDeveloperWorks-Link.desktop» из «Link».

    Рисунок 4. Результаты выполнения «VisitDeveloperWorks-Application.desktop» / «VisitDeveloperWorks-Link.desktop»

    Предположим, что файл изображения «gaim.png» хранится в указанной системной директории значков , Отредактируйте файл «VisitDeveloperWorks-Application.desktop», как показано на рисунке 5, и сохраните результат в каталоге «/ usr / share / Applications /».

    Рисунок 5. Содержимое файла «VisitDeveloperWorks-Application.desktop»

    Основное содержание этого файла — установить значок приложения в файл «gaim.png», тип файла Desktop Entry — «приложение», а команду, которая должна быть выполнена приложением, — «firefox http://www.ibm». .com / developerworks «. После редактирования вы можете увидеть стиль отображения этого экземпляра в браузере файлов и браузере приложений (как показано на рисунке 6).

    Рисунок 6 Стиль отображения файла «VisitDeveloperWorks-Application.desktop» в браузере приложения

    Измените вышеуказанный файл «VisitDeveloperWorks-Application.desktop», как показано на рисунке 7, и переименуйте файл «VisitDeveloperWorks-Link.desktop» и сохраните его в каталоге «/ usr / share / Applications /».

    Рисунок 7. Содержимое файла «VisitDeveloperWorks-Link.desktop»

    Основное содержание этого файла — установить тип файла Desktop Entry на «Link», а URL-адрес, указанный в файле Desktop Entry, на «http://www.ibm.com/developerworks». После редактирования в браузере файлов (как показано на рисунке 8) вы можете увидеть стиль отображения этого примера. Стоит отметить, что, поскольку этот экземпляр не является приложением, соответствующие ярлыки не отображаются в браузере приложений.

    Рисунок 8 Стиль отображения файла «VisitDeveloperWorks-Link.desktop» в браузере файлов

    Файл Desktop Entry — это стандартный метод описания конфигурации запуска программы в настольных системах Linux KDE и Linux GNOME. В этой статье определение и применение этого формата файла обсуждаются подробно. Для получения более подробной информации об использовании и программировании, пожалуйста, найдите соответствующие ссылки.

    Ипинг Гонг, инженер-программист, отдел WPLC, Центр разработки программного обеспечения IBM в Китае. Он в основном занимается исследованиями и разработками продуктов Notes Linux. Его исследовательские интересы включают кроссплатформенное портирование приложений Windows, разработку GDI, разработку сетевых устройств и исследование алгоритмов планирования. Контактное лицо: [email protected] .

    Источник

    Adblock
    detector