财商书苑
全民财商训练提升,认真负责我们的每句话

Debian 7 wheezy 应用程序添加快捷方式

Debian 下安装完eclipse需要添加快捷方式,方法如下:

1.进入 /usr/share/applications目录

2.新建文件 vi AndroidDeveloperTools.desktop,并键入以下内容。(为什么后缀为desktop?

快捷方式文件为什么要这么写第一行怎么写,以及文件格式是什么样的怎么知道所有的选项? )

–>若链接失效,请翻到文章底部查看原文。

注意:将上述的路径替换为自己安装路径!!!

3.保存文件推出即可。

P.S. wheezy的截图功能很强大,可惜不能截图Activity上的快捷方式。

====================================================================================

原文

====================================================================================

A, 后缀为什么为desktop?

For the desktop

The Internet Media Types (IMT) defined as part of the Multipurpose Internet Mail Extensions (MIME) have been reused by freedesktop.org (formerly known as the X Develepment Group, XDG) to associate applications and files in desktop environments.

Association between a file suffix and/or content and file type is done through XML files following the Shared MIME-info Database specification. The Debian package shared-mime-info contains the specification and the program update-mime-database that is used to populate the /usr/share/mime with relevant entries, using the XML file as a source. Again, dpkg triggers will update the database each time a package is installed or removed.

Programs are indirectly associated to file suffixes through the association with a file type. This is done through their .desktop file, with the MimeType entry.

B, 第一行怎么写,以及文件格式是什么样的?

Basic format of the file

Desktop entry files should have the .desktop extension, except for files of Type Directory which should have the .directory extension. Determining file type on basis of extension makes determining the file type very easy and quick. When no file extension is present, the desktop system should fall back to recognition via “magic detection”.

Desktop entry files are encoded in UTF-8. A file is interpreted as a series of lines that are separated by linefeed characters. Case is significant everywhere in the file.

Compliant implementations MUST not remove any fields from the file, even if they don’t support them. Such fields must be maintained in a list somewhere, and if the file is “rewritten”, they will be included. This ensures that any desktop-specific extensions will be preserved even if another system accesses and changes the file.

Comments

Lines beginning with a # and blank lines are considered comments and will be ignored, however they should be preserved across reads and writes of the desktop entry file.

Comment lines are uninterpreted and may contain any character (except for LF). However, using UTF-8 for comment lines that contain characters not in ASCII is encouraged.

Group headers

A group header with name groupname is a line in the format:

Group names may contain all ASCII characters except for [ and ] and control characters.

Multiple groups may not have the same name.

All {key,value} pairs following a group header until a new group header belong to the group.

The basic format of the desktop entry file requires that there be a group header named Desktop Entry. There may be other groups present in the file, but this is the most important group which explicitly needs to be supported. This group should also be used as the “magic key” for automatic MIME type detection. There should be nothing preceding this group in the desktop entry file but possibly one or more comments.

Entries

Entries in the file are {key,value} pairs in the format:

Space before and after the equals sign should be ignored; the = sign is the actual delimiter.

Only the characters A-Za-z0-9- may be used in key names.

As the case is significant, the keys Name and NAME are not equivalent.

Multiple keys in the same group may not have the same name. Keys in different groups may have the same name.

C, 文件所有选项

Recognized desktop entry keys

Keys are either OPTIONAL or REQUIRED. If a key is OPTIONAL it may or may not be present in the file. However, if it isn’t, the implementation of the standard should not blow up, it must provide some sane defaults.

Some keys only make sense in the context when another particular key is also present and set to a specific value. Those keys should not be used if the particular key is not present or not set to the specific value. For example, the Terminal key can only be used when the value of the Type key is Application.

If a REQUIRED key is only valid in the context of another key set to a specific value, then it has to be present only if the other key is set to the specific value. For example, the URL key has to be present when and only when when the value of the Type key is Link.

Some example keys: Name[C], Comment[it].

Table 2. Standard Keys

Key Description Value Type REQ? Type
Type This specification defines 3 types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3). To allow the addition of new types in the future, implementations should ignore desktop entries with an unknown type. string YES
Version Version of the Desktop Entry Specification that the desktop entry conforms with. Entries that confirm with this version of the specification should use 1.0. Note that the version field is not required to be present. string NO 1-3
Name Specific name of the application, for example “Mozilla”. localestring YES 1-3
GenericName Generic name of the application, for example “Web Browser”. localestring NO 1-3
NoDisplay NoDisplay means “this application exists, but don’t display it in the menus”. This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff). boolean NO 1-3
Comment Tooltip for the entry, for example “View sites on the Internet”. The value should not be redundant with the values of Name and GenericName. localestring NO 1-3
Icon Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be used. If the name is not an absolute path, the algorithm described in the Icon Theme Specification will be used to locate the icon. localestring NO 1-3
Hidden Hidden should have been called Deleted. It means the user deleted (at his level) something that was present (at an upper level, e.g. in the system dirs). It’s strictly equivalent to the .desktop file not existing at all, as far as that user is concerned. This can also be used to “uninstall” existing files (e.g. due to a renaming) – by letting make install install a file with Hidden=true in it. boolean NO 1-3
OnlyShowIn, NotShowIn A list of strings identifying the environments that should display/not display a given desktop entry. Only one of these keys, either OnlyShowIn or NotShowIn, may appear in a group (for possible values see the Desktop Menu Specification). string(s) NO 1-3
TryExec Path to an executable file on disk used to determine if the program is actually installed. If the path is not an absolute path, the file is looked up in the $PATH environment variable. If the file is not present or if it is not executable, the entry may be ignored (not be used in menus, for example). string NO 1
Exec Program to execute, possibly with arguments. See the Exec key for details on how this key works. string YES 1
Path If entry is of type Application, the working directory to run the program in. string NO 1
Terminal Whether the program runs in a terminal window. boolean NO 1
Actions Identifiers for application actions. This can be used to tell the application to make a specific action, different from the default behavior. The Application actions section describes how actions work. string(s) NO 1
MimeType The MIME type(s) supported by this application. string(s) NO 1
Categories Categories in which the entry should be shown in a menu (for possible values see the Desktop Menu Specification). string(s) NO 1
Keywords A list of strings which may be used in addition to other metadata to describe this entry. This can be useful e.g. to facilitate searching through entries. The values are not meant for display, and should not be redundant with the values of Name or GenericName. localestring(s) NO 1
StartupNotify If true, it is KNOWN that the application will send a “remove” message when started with the DESKTOP_STARTUP_ID environment variable set. If false, it is KNOWN that the application does not work with startup notification at all (does not shown any window, breaks even when using StartupWMClass, etc.). If absent, a reasonable handling is up to implementations (assuming false, using StartupWMClass, etc.). (See the Startup Notification Protocol Specification for more details). boolean NO 1
StartupWMClass If specified, it is known that the application will map at least one window with the given string as its WM class or WM name hint (see the Startup Notification Protocol Specification for more details). string NO 1
URL If entry is Link type, the URL to access. string YES 2
赞(0)
未经允许不得转载:财商书苑-全民财商训练提升 » Debian 7 wheezy 应用程序添加快捷方式

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址