Add an application to the KDE system menu

Whether you are compiling an application yourself, or you are just using a binary tarball archive, having a method to notify the Desktop Environment about the installed software to have a shortcut in the system menu or just register it to handle a certain MIME type, it is for sure a comfortable adding. If that method is also widely adopted among several, if not the major part, of Desktop Environment available, then it becomes a must!

In a previous article I showed how to create a shortcut on the contextual KDE menu, also known as KDE service menu, using desktop files, this time we are going to use them for a different purpose.

Desktop files again

The use of desktop files to describe an application is also a Freedesktop standard, and desktop environments as Gnome and KDE take advantage of the encoded info to build their application menu, looking for them among the keys while we use the search bar (activated with the <Alt+F2> keys), and more. That’s why almost any package we install contains one or more of these files.

Also my past application FluxboxAppsMenu make use of them to build the application menu for the Fluxbox system menu.

To getting started with it we need to know where to place or inspect the list of desktop files installed, the kf5-config command comes in help again:

$ kf5-config --path xdgdata-apps

Applications path discovery

Applications path discovery

A list of paths separated by the colon char : will show all the locations evaluated by KDE, the first one is under our home folder and will be used in that article, the other path is populated by the applications installed through the package manager (rpm, Yast, or zypper).

SQLitestudio as example

In that article, I will focus on SQLiteStudio, but all the considerations made can be easily applied to any other application.

SQLiteStudio is a multiplatform GUI application useful to manage SQLite database files, it can query, handle tables and populate them using an easy to use interface.

After downloading the tar archive provided at the Github repository it has to be deflated in some folder, the FHS standard suggests /opt as destination:

$ sudo tar -xvf sqlitestudio-3.2.1.tar.xz -C /opt

To start it from the command line also the PATH variable needs to be updated in the .bashrc file:

export PATH="$PATH:/opt/SQLiteStudio"

And the same file reloaded to work properly from the same terminal:

source ~/.bashrc

Once verified that sqlitestudio starts correctly and no libraries are missing, we can proceed with the desktop file.

SQLiteStudio starting correctly

SQLiteStudio starting correctly

The basic desktop application file

As said in the previous article, a desktop file contains a set of information structured as Ini file.

So let’s create a file under the proper path and edit it with our favorite editor:

$ touch ~/.local/share/applications/sqlitestudio.desktop
$ vi ~/.local/share/applications/sqlitestudio.desktop

Under the Desktop Entry section the Type key must be set to Application:

[Desktop Entry]

The other mandatory keys are:



It’s the name of the application, it may contain spaces
Contains the full path to the binary application or the entry point script
The full path of the icon that will appear to the KDE menu, usually it is provided by the application itself, otherwise any other icon from the installed theme at /usr/share/icons is ok
This includes the main category and one or more additional categories

The list of valid main categories, additional categories and reserved categories belong to the specifications.

One of the main categories has to be present otherwise the application won’t be associated in the correct subfolder in the system menu:

  • AudioVideo
  • Audio
  • Video
  • Development
  • Education
  • Game
  • Graphics
  • Network
  • Office
  • Science
  • Settings
  • System
  • Utility

Optional keys

Other optional but still useful keys are:

Comment=SQLite database management
GenericName=Database Manager


The list of MIME types supported by the application, this is the key which allows associating a particular file to our application every time it is selected inside a file manager
The application working path, usually referred to the root folder containing our application
It can be used as a hint from some menu application, or also to search the application when using the search box.

Here the complete desktop file:

[Desktop Entry]
Comment=SQLite database management
GenericName=Database Manager

In the images below can see how that desktop file affects also the MIME type associated and the search bar results:

Advanced uses

There is a last set of keys that worths a mention:

This is for applications that don’t want to be shown in the system menu, but just notify their MIME type association or provide the info to the application lookup window
If a particular application has to be shown or hide only within a certain context, like a particular Desktop Environment, these are the keys involved, to achieve that the environment variable $XDG_CURRENT_DESKTOP is involved.
Set to true when the application runs in the terminal
When the type is Link this key contains the URL to open

Although we can add all the options using any text editor, after creating the basic skeleton we might take advantage of the Graphical Interface provided by KDE to edit and update it, it will introduce also some other key used internally, especially those providing localization of the strings.

Final thoughts

The key listed are enough to build the most part of desktop files, nonetheless, the Freedesktop standard includes other keys for particular situations, they are covered at the specifications page.

Once again the Linux ecosystem allows us to improve our environment with ease being all the options well documented, and looking also at the installed desktop files is also a great source of inspiration.


Creative Commons License This work is licensed under a Creative Commons Attribution-NoCommercial-ShareAlike 4.0 International License

Share to