Desktop Entry Files and Xdg-Open

Does this article help you to understand Desktop-files better than before you viewed this article?

  • Yes

    Votes: 0 0.0%
  • No

    Votes: 0 0.0%

  • Total voters
    0
D

DevynCJohnson

Guest
Many Linux users have probably seen the *.desktop files. If any of you have viewed the contents, then you may be curious as to how it all works and why the file is needed. Thankfully, these desktop files are easy to understand. In addition, once you know how it works and what it can do, you may want to make some files yourself.

These *.desktop files are a special kind of file for the GUI. The file itself is just a regular text file. However, most file-managers view this file differently. In other words, this is only a special file in regards to the file-manager. The file acts as a shortcut (soft-link) to the desired executable. Such an executable may be a script or a compiled binary. These *.desktop files contain information such as the icon to use, the executable's location, parameters for the application, version, etc. When clicking on such a file, the linked program is executed. Users can use *.desktop files exactly the same way that Windows users use shortcuts to their programs.

desktop-file1.png


You may have wanted to change the icons, locations, etc. of your applications in your desktop-environment's app list/menu. For example, if you are using Mate, Cinnamon, Gnome, KDE, or any other desktop-interface, you may want a particular application to appear in the "Development" menu rather than "Other". Alternately, you may want to add an icon to an application that is missing an icon. All this can be accomplished with the *.desktop files. The global desktop files are stored under /usr/share/applications/. Users have their own customizable desktop files in ~/.local/share/applications/. To edit the global collection, you must use Root privileges.

Typically, the *.desktop extension is hidden, so users will only see the name. However, some file-managers do not hide the extension or some allow the user to choose. If the file-manager has the capabilities of recognizing the desktop files, then it commonly processes the *.desktop extension differently than other files. This means the *.desktop extension may be hidden even though the user configured the file-manager to show file-extensions.

These desktop files are actually scripts, but they are not shell scripts. You may notice that these scripts use a hashpling that looks like this - "#!/usr/bin/env xdg-open". This hashpling calls "xdg-open" which is a program that controls, configures, and determines default programs for opening files or performing some task. Also, this program reads the desktop files and is independent of the desktop environment. Xdg-open passes its input to the active/current file-opener. Each desktop environment uses a different file-opener. Gnome uses gvfs-open, KDE Plasma Desktops uses kde-open, and Xfce uses exo-open. Other file-openers exist for other environments. Xdg-open acts as a standard interface for each of the different file-openers. For desktop environments that lack a file-opener, xdg-open will become the system's primary (or only) file-opener.

desktop-file2.png


All xdg-open scripts (formerly mentioned as *.desktop files) begin with a hashpling. The following line is "[Desktop Entry]". After that, most of the other lines are optional. The sample script below is a basic xdg-open script with commonly used lines. The "Version" field refers to the script's specification version. Thus, the value of this field must always be "1.0", unless a different standard is supported. "Type" indicates whether the link goes to an application, a web-site (web-link), or a folder. The standard type values include "Application", "Link", and "Directory", respectively. "Terminal" accepts a boolean to know whether the executable runs in a terminal or not. A value of "true" would indicate that the program runs in the terminal. "Name" is the application's name and "Comment" is the tooltip's text. "Exec" and "Icon" call the executable or icon, respectively. To use the system's global icons, just use a name and not a path. If "Type" is "Link", then use "URL" in-place of "Exec" and specify a web-link.

NOTE: Of all of the fields, only "Type", "Name", and "Exec" are required.

Code:
#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Exec=COMMAND
Name=VISABLE-NAME
Comment=SOME-COMMENT
Icon=/ICON/PATH/ICON-FILE

Other fields exist and have useful properties. One such field includes "Categories" which indicates the menu that will list the program. For example, a line like this "Categories=Education;Languages;Java;" would make the specified application in the menu be listed under "Education", "Languages", and "Java". However, not all systems will create or support all of the categories.

If the value in "Exec" fails, then the value in "TryExec" will be tried.

"GenericName" is used to indicate a vague name. For instance, LibreOffice could have a GenericName of "Office Suite". Such names are used to indicate the program's purpose. However, it is recommended that the user creating the file only use "Name" and not “Generic Name”.

Like other scripts, the pound-sign/octothorpe (#) is used for comments and the script permits blank lines. The xdg-open scripts are case-sensitive and uses UTF-8. However, the "Encoding" field allows users to specify an alternate file encoding.

"NoDisplay" accepts a boolean to indicate if the application is visible in the menus. Making a xdg-open script invisible in the application-menu is helpful if the script is only intended to indicate the MIME types recognized by the application. "Hidden" makes the application appear to have been deleted, if the value is "true".

"OnlyShowIn" is used to list the desktop environments that are permitted to use this xdg-open script. "NotShowIn" is the opposite of "OnlyShowIn" where listed desktop-environments are not allowed to use the information.

"Path" is the application's current working directory during execution.

"DBusActivatable" accepts a boolean to specify if the program can be activated with D-Bus. Otherwise, the "Exec" line will be used if the system does not support D-Bus.

To make application-searching more efficient (like in Unity), use "Keywords" to list words that the search will view when the user types in the search box. When using the desktop environment to search for an application, all fields in the file will be read. However, the "Keywords" field allows users to include words that are not in the other lines.

"StartupNotify" is used to indicate whether the application supports startup-notification. A value of "true" activates the check. "StartupWMClass" accepts text that is used to specify a WM Class. In general, you will probably not need to know exactly the purpose of the fields mentioned in this paragraph. Explaining these two fields is a subject of its own. If you need to know them for some reason, try this link - http://standards.freedesktop.org/startup-notification-spec/startup-notification-0.1.txt

After "MimeType", list the MIME types that the program is expected to recognize.

To make a script, create a file with the "desktop" extension and name the file after the target application, if desired. Type the fields and values (entries) you wish to use. To edit a file, open it with a plain text editor and make the desired changes.

After making a xdg-open script, run "desktop-file-validate FILE.desktop", but use the name of your script instead of "FILE". Running this command validates the script. Then, you may safely install it by using one of three methods. For global usage, move the file to /usr/share/applications/. Otherwise, for local use in a single user account, place in ~/.local/share/applications/. The third choice is to place it elsewhere if you wish, like the desktop (~/Desktop/). Either way, remember to make the script executable (chmod +x /usr/share/applications/FILE.desktop).

NOTE: Sometimes after executing “desktop-file-validate”, an extra “.desktop” file-extension is appended to the filename.

Example:
Code:
desktop-file-validate FILE.desktop

mv FILE.desktop /usr/share/applications/FILE.desktop && chmod +x /usr/share/applications/FILE.desktop

mv FILE.desktop ~/.local/share/applications/FILE.desktop && chmod +x ~/.local/share/applications/FILE.desktop

xdg-open script for Audacious:
Code:
#!/usr/bin/env xdg-open
[Desktop Entry]

Version=1.0
Type=Application
Name=Audacious
GenericName=Music Player
Comment=Listen to music
Icon=audacious
Categories=AudioVideo;Audio;Player;GTK;
Exec=audacious %U
TryExec=audacious
Terminal=false
MimeType=application/ogg;application/x-cue;application/x-ogg;application/xspf+xml;audio/midi;audio/mp3;audio/mpeg;audio/mpegurl;audio/ogg;audio/prs.sid;audio/x-flac;audio/x-it;audio/x-mod;audio/x-mp3;audio/x-mpeg;audio/x-mpegurl;audio/x-ms-wma;audio/x-musepack;audio/x-s3m;audio/x-scpls;audio/x-stm;audio/x-vorbis+ogg;audio/x-wav;audio/x-xm;x-content/audio-cdda;

Actions=PlayPause;Next;Previous

[Desktop Action PlayPause]
Name=Play-Pause
Exec=audacious -t
OnlyShowIn=Unity;

[Desktop Action Next]
Name=Next
Exec=audacious -f
OnlyShowIn=Unity;

[Desktop Action Previous]
Name=Previous
Exec=audacious -r
OnlyShowIn=Unity;

Notice the "Actions" field and the last three headers. These enable the use of pause, play, next, and previous buttons when right-clicking the Audacious launcher in Unity.

For more information on the Desktop Entry Specification, view this link - http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html


Understanding the desktop files (xdg-open scripts) allows users to manually edit their application menus without needing special software. After gaining an understanding of these files also allows people to make their own xdg-open scripts.
 

Attachments

  • slide.jpg
    slide.jpg
    78.6 KB · Views: 267,460
Last edited:



Members online


Top