Oh you opened this?! Feeling brave eh?! Ha ha!
So as a bit of background for an example of a script that might require a .desktop file - I have a script called
buildbl
in my personal bin directory, which scours my home directory for ebooks and creates a sorted list of all books. So whenever I buy and download a new set of ebooks from Humblebundle.com - I will always run this script to update my list of ebooks.
I have another script, imaginatively called 'book', which allows me to search my library/book-list for a particular book. So if I want to see what ebooks I have related to python, I'll run the command
book python
and I'll see a list of books which have python in the path/file-name. And if I want to filter the list further, I'll use grep.
So if I want to find Python books that are related to robotics, I would use the following
Bash:
book python | grep -i robot
I'm too lazy to type robotics - robot will do! Ha ha.
And once I've found a book I want to read, I'll run another script, called
rd
- which takes the path to an ebook as a parameter and then opens it in Okular. Why do I have a script for that? Because typing
rd /path/to/book
is much faster than typing
okular /path/to/book/ &> /dev/null &
or typing
xdg-open /path/to/book
each time I want to open it up from the terminal.
Now, I'm a bit of an odd-bod. Normally, I live in the terminal - so I'll always run my personal scripts in the terminal. And I don't use a normal desktop either, I use dwm (a tiling window manager). So no GUI application menus/launchers or anything. I don't use the GUI a lot. So most of my scripts are pretty useless from the GUI too.
My
book
and
rd
scripts are really only useful in the terminal, they wouldn't be helpful to launch from the desktop. However my
buildbl
script could potentially be useful from the desktop.
So IF I was a typical desktop user, logged into Gnome (yuk), or KDE, or some other desktop, and I'd bought some new ebooks, and I wanted to update my list from the GUI - then I would need to create a .desktop file for my script, and add it to
~/.local/share/applications
.
Any modern, freedesktop.org standards compliant desktop will look in this location for local application .desktop launchers and will add a icon for them to the application menus. So if you add a .desktop for one of your own scripts, or executable programs here - it should appear as an icon in your systems menu/launcher system.
So let's take a look at a typical .desktop file.
For the sake of an example, I'll create a .desktop file for my 'buildbl' (build book list) script. You can use the file as a template, and modify it for use with your own scripts/programs.
So this particular .desktop file would be called
buildbl.desktop
- obviously, you call yours whatever you like. And I would create it in
~/.local/share/applications/
(you should create yours here too!). And it would look something like this:
Code:
#!/usr/bin/env xdg-open
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=buildbl
GenericName=build book list
Comment="Searches home directory for ebooks and creates a sorted list of books"
Type=Application
Icon=utilities-terminal
Categories=Utility;
#Exec=/home/jason/bin/buildbl
Exec=xterm -e '/home/jason/bin/buildbl;read -p "press any key to continue..." -n1 -s'
Terminal=true
The first thing in the .desktop file is a shebang.
#!/usr/bin/env xdg-open
This tells the shell which interpreter should be used to interpret the file when it is opened.
In this case, we're using xdg-open, which is used by X to open/launch files based on their mime-type and their default application.
The next line
[Desktop Entry]
tells xdg-open that this is a desktop application launcher.
Then we have some information about the file encoding and the application version.
They speak for themselves.
Then we have the Name, Generic name and a Comment (which typically pops-up as a tool-tip when you hover your mouse over the desktop entry). Again, all pretty self explanatory. The Name is the short name for the application. The Generic name is a more long-winded name. And as mentioned - the comment is like a tool-tip.
Obviously, I've made these relevant to my script. If you are adding a .desktop for one of your scripts, or applications - then alter those fields to reflect the name and function of your script/application.
The Type field is set to Application, again - pretty self-explanatory. Our script is an application.
The
Icon=
field is an interesting one. This is used to set the icon for the entry. I've just used a default icon for it, called 'utilities-terminal', so the icon for my application will appear to be a terminal application - which makes sense, because it is a terminal application.
But you could look through /usr/share/icons and find another existing icon that you want to use for your application.
Or you could create your own fancy icon and then specify an explicit path to it in this field. So for example, I could create an icon of my own and set the Icon field to:
Code:
Icon=/home/jason/bin/buildbl-icon.png
And it would use the icon I created. But I'm too lazy for that! I just used a default icon! Icons are mostly in .tiff, .xpm, .png, or .svg format.
Next we have this entry:
That tells the system that my application should be listed under the "Utility", or "Accessories" section in the menu.
There is a list of freedesktop.org application categories here:
If you have a script/program that belongs in a different category in the menu, you can see which categories are available in the above link.
Then we get to the
Exec
section of the .desktop.
This is where we specify what to run.
I've got two exec lines in there. The first one is commented out. The second is not.
The commented out one would run my buildbl script.But it would run my application in a hidden terminal, that wouldn't even show up. So I wouldn't see my application, or see if it completed successfully. Personally - I'd be OK with that - I know my
buildbl
script works. However, you probably might want to see your script running in a terminal so you could see its output.
So the second, uncommented
Exec=
line shows you how I'd go about starting my script in a new terminal window, so I could see what it was doing:
Code:
Exec=xterm -e '/home/jason/bin/buildbl;read -p "press any key to continue..." -n1 -s'
That tells the system to run the xterm terminal emulator and to run my script and then afterwards there is a read command with a prompt "press any key to continue...".
So what that does is, it runs my script in a new instance of xterm. So an xterm window will pop up. My script will run in xterm, eventually the script will tell me how many books are in the new booklist and then I'll be prompted to "press any key to continue..." - I can then press any key and the terminal window will close.
And the final line in the .desktop file is:
Which tells the system that this is a terminal-based application and not a GUI application. If you'd created a windowed, GUI application using C++ with QT, or wxWidgets, then you'd set that to false.
So that's how you'd create a simple .desktop file for a script!
Obviously, I've made it relevant to one of my own scripts - you may need to make some changes to fit whatever scripts you want to run.
Your script might be in your personal bin directory, or it might be something that you have installed system-wide in /usr/local/bin - so it can be used by other users on your system.
In which case, you would add the .desktop file to
/usr/share/applications
instead, which is where the .desktop launchers for system wide applications are stored.
Also
/usr/share/applications
is a great place to look if you want to see some examples of other .desktop launcher files and see what other fields you can use in your own .desktop launchers.
Also, my .desktop file is only in English. If you take a look at the .desktop launchers for some system-wide applications - you will see that the 'Name', 'Generic Name' and 'Comment' fields all have translations for multiple languages.
The field translations use this kind of syntax:
Code:
FieldName[Language-code]="Translated Value"
Where FieldName is either 'Name', 'Generic Name', or 'Comment'
'[Language-code]=' is a language code - e.g.
[cy]= for Welsh or [de]= for German etc. etc.
And "Translated Value" is the translated string for that language.
So in German, the GenericName entry for my application might look something like this:
Code:
GenericName[de]="Bücherliste erstellen"
So for any non-native, English speakers in the community here - who may well have their systems set up to use their own native language, or who perhaps might use a multi-lingual setup, where they regularly switch between their native language and any other languages they know. You could add some translations to your .desktop files too. That will make the .desktop files a little bigger, but the file-size is not really a problem. Most system-wide applications support a huge number of languages.
So some of you might also want to include translations for the name, generic name and comment fields in the .desktop file too!