100字范文,内容丰富有趣,生活中的好帮手!
100字范文 > 桌面条目文件规范

桌面条目文件规范

时间:2023-02-10 00:01:32

相关推荐

桌面条目文件规范

原文链接

介绍

KDE和GNOME桌面环境都采用了类似的”桌面条目”格式,或描述特定程序如何启动的配置文件,它在菜单中的显示方式等。统一标准对更大的社区有利。 所有各方都同意这样做,即两个环境之间的互操作,以及实现规范的任何其他环境变得更加简单。

文件命名

桌面条目文件应具有.desktop扩展名,但类型目录的文件除外,该文件应具有.directory扩展名。基于扩展确定文件类型使得确定文件类型非常容易和快速。当没有文件扩展名时,桌面系统应通过“魔术检测”来后备识别。

对于应用程序,.desktop扩展名之前的桌面文件名称部分应该是有效的D-Bus知名名称。这意味着它是由点(U+002E FULL STOP)分隔的非空元素序列,其中没有一个以数字开头,并且每个元素仅包含来自集合的字符[A-Za-z0-9- _]:ASCII字母,数字,短划线(U+002D HYPHEN-MINUS)和下划线(U+002D HYPHEN-MINUS)。

桌面条目的名称应遵循“反向DNS”约定:它应以应用程序作者控制的反向DNS域名开头,小写。域名后面应该跟应用程序的名称,通常用合并的单词和首字母大写字母(CamelCase)编写。例如,如果exam​​的所有者编写“Foo Viewer”,他们可能会选择名称org.example.FooViewer,结果是名为org.example.FooViewer.desktop的文件。

允许使用包含短划线的已知名称,但不建议这样做,因为在反向DNS名称的某些相关用途中不允许使用短划线,例如D-Bus对象路径和接口名称以及Flatpak应用程序ID。如果作者的域名包含短划线,建议将其替换为下划线:这不会导致歧义,因为DNS域名中不允许使用下划线。

如果作者的域名包含以数字开头的元素(在D-Bus知名名称中不允许),建议在桌面条目名称的该元素前加下划线。例如,7-可能会发布名为org._7_zip.Archiver的应用程序。

桌面文件 ID

表示应用程序的每个桌面条目由其桌面文件ID标识,该文件ID基于其文件名。

要确定桌面文件的ID,请相对于安装桌面文件的$XDG_DATA_DIRS组件创建其完整路径,删除“applications/”前缀,然后将“/”变为“-”。例如/usr/share/applications/foo/bar.desktop具有桌面文件ID foo-bar.desktop。

如果多个文件具有相同的桌面文件ID,则使用$XDG_DATA_DIRS优先顺序中的第一个。例如,如果$ XDG_DATA_DIRS包含默认路径/usr/local/share:/usr/share,那么/usr/local/share/applications/org.foo.bar.desktop/usr/share/applications/org.foo.bar.desktop都具有相同的桌面文件ID org.foo.bar.desktop,但只会使用第一个。如果foo-bar.desktop和foo/bar.desktop都存在,则选择未定义。

如果桌面文件未安装在$XDG_DATA_DIRS组件之一的applications子目录中,则它没有ID。

文件的基本格式

桌面条目文件以UTF-8编码。 文件被解释为由换行符分隔的一系列行。 文件中字母大小写是有意义的。

兼容的实现绝不能从文件中删除任何字段,即使它们不支持它们。 这些字段必须保存在某个列表中,如果文件被“重写”,它们将被包含在内。 这可确保即使其他系统访问和更改文件,也会保留任何特定于桌面的扩展。

注释

以#开头的行被视为注释,将被忽略,但是应该在桌面条目文件的读写期间保留它们。

注释行不被解析,可能包含任何字符(LF除外)。 但是,鼓励将UTF-8用于包含非ASCII字符的注释行。

组头部

名称为groupname的组头部是以下格式的行:

[groupname]

组名可以包含除[]和控制字符以外的所有ASCII字符。

多个组可能没有相同的名称。

在组头部之后的所有{key,value}对,直到新的组头部属于该组。

桌面条目文件的基本格式要求有一个名为Desktop Entry的组头部。 文件中可能存在其他组,但这是明确需要支持的最重要的组。 该组还应该用作自动MIME类型检测的“魔术键”。 桌面条目文件中此组之前应该没有任何内容,但可能有一行或多行注释。

条目

文件中的条目是{key,value}对,格式如下:

Key=Value

等号之前和之后的空格应该被忽略; =符号是实际的分隔符。

在键名中只能使用字符A-Za-z0-9-。

由于大小写是有意义的,键 Name 和 NAME 是不同的。

同一组中的多个键可能不具有相同的名称。不同组中的键可能具有相同的名称。

可能的值类型

识别的值类型是string,localestring,boolean和numeric。

string类型的值可以包含除控制字符之外的所有ASCII字符。

localestring类型的值是可向用户显示的,并以UTF-8编码。

boolean类型的值必须是字符串true或false。

numeric类型的值必须是有效的浮点数,由C语言环境中scanf的%f说明符识别。

转义序列\s,\n,\t,\r和\支持string和localestring类型的值,分别表示ASCII空格,换行符,制表符,回车符和反斜杠。

某些键可以有多个值。在这种情况下,键的值被指定为复数:例如,多个字符串。多个值应该用分号分隔,键的值可以选择用分号结束。尾随空字符串必须始终以分号结束。这些值中的分号需要使用;进行转义。

键的本地化值

类型为localestring的键可以由[LOCALE]后缀,其中LOCALE是条目的语言环境类型。 LOCALE的格式必须为lang_COUNTRY.ENCODING@MODIFIER,其中可省略_COUNTRY,.ENCODING和@MODIFIER。如果出现加后缀的键,则必须同时存在不加后缀的相同的键。

在桌面条目文件中读取时,通过将LC_MESSAGES类别的当前POSIX语言环境与键的所有LOCALE后缀相匹配来选择键的值。

匹配如下进行。如果LC_MESSAGES的格式为lang_COUNTRY.ENCODING@MODIFIER,则它将匹配lang_COUNTRY@MODIFIER格式的键。如果这样的键不存在,它将尝试匹配lang_COUNTRY,然后是lang@MODIFIER。然后,将尝试与lang本身进行匹配。最后,如果未找到匹配的密钥,则使用未指定区域设置的所需键。匹配时忽略LC_MESSAGES值的编码。

如果LC_MESSAGES没有MODIFIER字段,则不会匹配带修饰符的键。同样,如果LC_MESSAGES没有COUNTRY字段,则不会匹配指定国家/地区的键。如果LC_MESSAGES只有一个lang字段,那么它将与具有相似值的键进行直接匹配。下表按照匹配顺序列出了各种LC_MESSAGES值的可能匹配项。请注意,未显示ENCODING字段。

表1. 区域设置匹配

例如,如果LC_MESSAGES类别的当前值是sr_YU@Latn,并且桌面文件包括:

Name=FooName[sr_YU]=...Name[sr@Latn]=...Name[sr]=...

则 Name 的值用[sr_YU]后缀的。

识别的桌面条目键

键是可选的或必需的。 如果键是可选的,则它可能存在也可能不存在于文件中。 但是,如果不是,标准的实现不应该崩溃,它必须提供一些理智的默认值。

某些键仅在上下文中另一个特定键也存在并设置为特定值才有效。 如果特定键不存在或未设置为特定值,则不应使用这些键。 例如,只有在Type键的值为Application时才能使用Terminal键。

如果必需键仅在另一个设置为特定值的键的上下文中有效,则只有在另一个键设置为特定值时才必须存在。 例如,当且仅当Type键的值为Link时,必须存在URL键。

一些示例键:Name[C]Comment[it]

Exec 键

Exec键必须包含命令行。 命令行由可执行程序组成,可选地后跟一个或多个参数。 可执行程序可以使用其完整路径指定,也可以仅使用可执行文件的名称指定。 如果未提供完整路径,则在桌面环境使用的$PATH环境变量中查找可执行文件。 可执行程序的名称或路径可能不包含等号(“=”)。 参数由空格分隔。

参数可以全部引起来(后称为引用)。 如果参数包含保留字符,则必须引用该参数。 引用参数的规则也适用于提供的可执行程序的可执行文件名或路径。

引用必须通过在双引号之间包含参数并转义双引号字符(“"”),反引号字符(“`”),美元符号(“$”)和反斜杠字符(“\”),并在其前面添加一个反斜杠字符来完成。 实现必须在扩展字段代码之前和将参数传递给可执行程序之前解开引用。 保留字符为空格(“ ”),制表符,换行符,双引号(“"”),单引号(“'”),反斜杠字符(“\”),大于号(“>”),小于号(“<” ),波浪号(“~”),竖条(“|”),and符号(“&”),分号(“;”),美元符号(“$”),星号(“*”),问号(“?“),哈希标记(”#“),括号(”(“)和(”)“)和反引号字符(”`“)。

请注意,string类型值的常规转义规则表明反斜杠字符也可以转义为(“\”),并且在引用规则之前应用此转义规则。 因此,要明确表示桌面条目文件中带引号的参数中的文字反斜杠字符,需要使用四个连续的反斜杠字符(“\\”)。 同样,桌面条目文件中带引号的参数中的文字美元符号用(“\$”)明确表示。

已经定义了许多特殊的字段代码,当在命令行中遇到时,它们将由文件管理器或程序启动器扩展。 字段代码由百分比字符(“%”)后跟字母字符组成。 必须将文字百分比字符转义为%%。 应从命令行中删除不推荐使用的字段代码并将其忽略。 字段代码仅扩展一次,不应检查用于替换字段代码的字符串的字段代码本身。

包含未在此规范中列出的字段代码的命令行无效且不得处理,特别是实现可能不会引入对本规范中未列出的字段代码的支持。 如果有的话,应该通过新键引入扩展。

除非本规范明确指示,否则实现必须注意不要将字段代码扩展为多个参数。 这意味着可以包含空格的名称字段,文件名和其他替换项必须在扩展后作为单个参数传递给可执行程序。

尽管Exec键被定义为具有string类型的值(仅限于ASCII字符),但字段代码扩展可能会在参数中引入非ASCII字符。 实现必须注意传递给可执行程序的参数中的所有字符都根据适用的语言环境设置进行了正确编码。

识别的字段代码如下:

命令行最多可包含一个%f,%u,%F或%U字段代码。 如果应用程序不应打开任何文件,则必须从命令行中删除%f,%u,%F和%U字段代码并将其忽略。

不能在带引号的参数内使用字段代码,引用参数内的字段代码扩展的结果是未定义的。 %F和%U字段代码只能单独用作参数。

D-Bus 激活

支持由D-Bus启动的应用程序必须实现以下接口(以D-Bus内省XML格式给出):

<interface name='org.freedesktop.Application'><method name='Activate'><arg type='a{sv}' name='platform_data' direction='in'/></method><method name='Open'><arg type='as' name='uris' direction='in'/><arg type='a{sv}' name='platform_data' direction='in'/></method><method name='ActivateAction'><arg type='s' name='action_name' direction='in'/><arg type='av' name='parameter' direction='in'/><arg type='a{sv}' name='platform_data' direction='in'/></method></interface>

应用程序必须根据介绍部分中的命名建议命名其桌面文件(例如,文件名必须类似于org.example.FooViewer.desktop)。 应用程序必须具有可以使用已知名称激活的D-Bus服务,该名称与删除了.desktop部分的桌面文件名相同(对于我们的示例,org.example.FooViewer)。 上述接口必须在如下确定的对象路径上实现:从应用程序的众所周知的D-Bus名称开始,将所有点更改为斜杠并添加前缀斜杠。 如果找到破折号('-'),将其转换为下划线('_')。 对于我们的示例,是/org/example/FooViewer。

当启动应用程序时不打开任何文件将调用Activate方法。

当启动应用程序时带有文件,将调用Open方法。字符串数组是一个URI数组,采用UTF-8编码。

激活桌面操作时会调用ActivateAction方法。 action-name参数是操作的名称。

所有方法都接收platform-data参数,该参数的使用方式与环境变量的使用方式类似。 目前,规范只定义了一个字段:desktop-startup-id。 这应该是与存储在DESKTOP_STARTUP_ID环境变量中的值相同的字符串,如启动通知协议规范所指定的。

接口

Implements键可用于声明桌面文件实现的一个或多个接口。

每个接口名称必须遵循用于D-Bus接口名称的规则,但除此之外,它们没有特别的含义。 例如,在此列出接口并不一定意味着该应用程序实现了D-Bus接口,甚至不存在这样的D-Bus接口。 完全由定义特定接口的实体来定义实现它的意义。

虽然完全取决于接口的设计者来决定给定的接口名称的含义,但这里有一些推荐的“最佳实践”:

接口应该要求应用程序是可以DBusActivatable的,包括使用D-Bus“反向DNS”约定命名应用程序的桌面文件的要求接口名称应对应于应用程序在导出org.freedesktop.Application接口时在同一对象路径上导出的D-Bus接口如果接口希望允许有关实现的详细信息,则应通过指定实现者在其桌面文件中添加与接口同名的组来实现(例如:[org.freedesktop.ImageAcquire]

尽管建议,接口可以指定几乎任何可以想象的要求,包括这样(荒谬)的事情,“当通过Exec行启动时,应用程序应该呈现一个设置了_FOO_IDENTIFIER属性的窗口,此时将发送一个X客户端消息到那个窗口“。 另一个例子是“此接口的所有实现都应该标记为NoDisplay,并且在启动时,不会显示任何窗口,并且将在不确认的情况下删除所有用户的文件”。

接口定义者在设计接口时应注意保持向后和向前兼容性问题。

注册MIME类型

MimeType键用于指示应用程序知道如何处理的MIME类型。 对于某些应用程序,预计此列表可能会变长。 期望应用程序能够使用Exec键中列出的命令合理地打开这些类型的文件。

此字段中的MIME类型或桌面文件中的任何形式的优先级都不应该具有优先级。 应用程序的优先级在.desktop文件之外处理。

附加应用程序操作

Application类型的桌面条目可以包括一个或多个操作。 操作表示调用应用程序的其他方法。 应用程序启动器应该在应用程序的上下文中将它们公开给用户(例如,作为子菜单)。 这用于构建所谓的“快速列表”或“跳转列表”。

操作标识符

每个操作都由一个字符串标识,其格式与键名相同(请参阅“条目”一节)。 每个标识符都与必须存在于.desktop文件中的操作组相关联。操作组是名为Desktop Action %s的组,其中%s是操作标识符。

Actions键中未提及的操作标识符的操作组无效。实现者必须忽略这样的操作组。

操作的键

每个操作组中都支持以下键。 如果操作组中不存在必需键,则实现者应忽略此操作。

表3.特定于操作的键

实施说明

应用程序操作应该由实现者支持。 但是,如果不支持它们,实现者可以简单地忽略Actions键和关联的Desktop Action操作组,并继续使用Desktop Entry组:描述和调用应用程序的主要方法是通过Desktop Entry组的NameIconExec键。

预计显示应用程序列表的其他桌面组件(例如软件安装程序)不会为这些操作提供任何用户界面。 因此,应用程序必须仅包含作为通用发·射器有意义的操作。

扩展格式

如果要使用适用于所有支持方的新{key,value}对修改标准,则将进行小组讨论。 这是引入更改的首选方法。 如果一个特定的一方希望添加一个供个人使用的字段,他们应该在密钥前面添加字符串X-PRODUCT,例如: X-NewDesktop-Foo,遵循其他IETF和RFC标准设定的先例。

或者,可以将字段放在它们自己的组中,然后它们可以具有任意键名。 如果是这种情况,该组应遵循上述方案,即[X-PRODUCT GROUPNAME]或类似的东西。 这些步骤将避免不同但相似的环境之间的命名空间冲突。

示例桌面条目文件

[Desktop Entry]Version=1.0Type=ApplicationName=Foo ViewerComment=The best viewer for Foo objects available!TryExec=fooviewExec=fooview %FIcon=fooviewMimeType=image/x-foo;Actions=Gallery;Create;[Desktop Action Gallery]Exec=fooview --galleryName=Browse Gallery[Desktop Action Create]Exec=fooview --create-newName=Create a new Foo!Icon=fooview-new

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。