3

Trying to recover a bunch of .desktop files from Ubuntu 14.04 copied to 16.04, but they don't appear in the Launcher.

Did the following (/14.04 is mounted to the old Ubuntu disk / FS)

cd ~/.local/share/applications
cp -pr /14.04/home/ring0/.local/share/applications/[bunch-of].desktop .

but they do no appear after logging back to 16.04. (same user / uid on both versions)

Had a look at /usr/share/applications, but the files are in the .local dir.

Looking at the structure of the .desktop files on both versions, they look similar.

Anything else to check / setup?

Thanks

Déjà vu
  • 969
  • Do you mean they don't appear in the launcher or n Dash? – Jacob Vlijm Jan 03 '17 at 18:41
  • In the launcher – Déjà vu Jan 04 '17 at 02:01
  • @ringø just a question: Did you try dragging them to the launcher, or did you just put them into ~/.local/shared/applications/ ? Also, are you using Unity desktop ? Or something else ? – Sergiy Kolodyazhnyy Jan 05 '17 at 11:08
  • @Serg No I didn't try to drag them yet - will probably do that stuff during the coming week end. – Déjà vu Jan 05 '17 at 12:14
  • @ringø Well there's your problem. Just because you drop .desktop files into folder they won't appear on the launcher. Drag them, they will appear on the launcher. Also consider using one of the methods in my other answer that i linked in point 3 of my answer – Sergiy Kolodyazhnyy Jan 05 '17 at 12:20

4 Answers4

8

You need to manually add it to Unity Launcher, it's not enough to just put it in the folder.

  1. browse to your .local/share/applications folder in Nautilus (the folder might be hidden, so you might need to press Ctrl+H)

  2. drag .desktop files from Nautilus to Unity Launcher, it should then appear instantly

Amias
  • 5,246
  • most logical & straightforward answer of the current bunch. – doug Jan 03 '17 at 22:09
  • +1 This has been tested working in Ubuntu 16.04 and the added .desktop file a.k.a. shortcut in Unity Launcher persists after reboot. –  Jan 04 '17 at 15:26
3

You have to add them to launcher favorites list. To read current list:

~$ dconf read /com/canonical/unity/launcher/favorites
['application://nautilus.desktop', 'application://firefox.desktop', 'application://libreoffice-writer.desktop', 'application://unity-control-center.desktop', 'application://gnome-terminal.desktop', 'unity://running-apps', 'unity://expo-icon', 'unity://devices']

To write new list

dconf write /com/canonical/unity/launcher/favorites "['application://nautilus.desktop', 'application://firefox.desktop', 'application://libreoffice-writer.desktop', 'application://unity-control-center.desktop', 'application://gnome-terminal.desktop', 'unity://running-apps', 'unity://expo-icon', 'unity://devices']"

Not sure if possible to read dconf db of 14.04 using chroot, If your 14.04 still boot-able, boot it then use dconf read ... to get the list. Otherwise, write the list manually from ls ~/.local/share/applications.

user.dz
  • 48,105
0

Have you checked whether the *.desktop files have execution permission? I copied once (with -p option) on 16.04 from /usr/share/applications/ to ~/.local/share/applications/. The files lost execution permission. I guess this is a similar situation.

lilysirius
  • 111
  • Reading the question more closely, you'll see that the copy is from /14.04/home/ring0/.local/share/applications/[bunch-of].desktop to ~/.local/share/applications (where ~ is ring0). Anyway checked the ACL to be sure, and they're correct. – Déjà vu Sep 30 '16 at 16:44
  • For the launcher, being executable is irrellevant. – Jacob Vlijm Jan 03 '17 at 18:39
  • @JacobVlijm Nope. If .desktop files are located anywhere in user's folder , which is also ~/.local/share/applications/ , they do need executable permissions to both run AND be placed onto launcher. This adheres to Ubuntu's security policy. I've tested it also. Launcher with no exec permissions cannot be placed onto launcher – Sergiy Kolodyazhnyy Jan 05 '17 at 08:51
  • @Serg, really, but no. None of my launchers in ~/.local/share/applications is executable. Has never been different. What are you running? – Jacob Vlijm Jan 05 '17 at 08:55
  • @JacobVlijm Ubuntu 16.04 LTS. Please read https://wiki.ubuntu.com/SecurityTeam/Policies I don't know what's wrong with your Ubuntu, but that's how all Ubuntu versions work. If you want , I can provide quotes from other AU answers. Only items placed in /usr/share/application don't require executable bit set. User's folder's do require that bit set – Sergiy Kolodyazhnyy Jan 05 '17 at 08:57
  • @Serg please see this: https://dl.dropboxusercontent.com/u/1155139/noexec.png I believe my eyes rather than what I read. Has never been differently since I wrote the Quicklist Editor for 11.04. – Jacob Vlijm Jan 05 '17 at 09:00
  • @Serg only when used as double-click launcher it needs to be executable. – Jacob Vlijm Jan 05 '17 at 09:04
  • @JacobVlijm you didn't show Permissions tab, which is where actual execution is set. See: http://imgur.com/a/1IRY6 To be placed on the launcher and allow user to run that application, it needs to be executable. Otherwise, Unity flags application as untrusted. It has nothing to do with double clicking, but with letting .desktop run, of which double click is only one way. Sorry, but i have no time for this discussion – Sergiy Kolodyazhnyy Jan 05 '17 at 09:06
  • @Serg The Unity Quicklist Editor https://launchpad.net/~vlijm/+archive/ubuntu/qle is based on those launchers not being executables (simply copied from ~/usr/share/applications). I believe something like 15.000 downloads without a single bug file on that. You should conclude from the generic icon that the launcher is not executable, but for the record, look again into the link to my dropbox. You must have done something adventurous if it works differently on your system. – Jacob Vlijm Jan 05 '17 at 09:10
  • @JacobVlijm Well, I'm not familiar with The Quicklist Editor, so I cannot point out what might be the cause. Besides, we're dealing with .desktop files themselves. Your application is non-standard. As for executable bit, it is something Ubuntu's official security policy requires and there are hundreds of questions relating to "Why does my .desktop file not running?" , and to all of them the solution is the same. – Sergiy Kolodyazhnyy Jan 05 '17 at 09:13
  • Again, that is for double-click. " Sorry, but i have no time for this discussion"?? You started it. The fact that the application is non-standard is totally irrelevant. Not a single bug on this subject is relevant. – Jacob Vlijm Jan 05 '17 at 09:15
  • @JacobVlijm Double click is just but one method of running .desktop file. – Sergiy Kolodyazhnyy Jan 05 '17 at 09:18
  • @Serg Please pick any non-executable launcher in /usr/share/applications does it call the application? No. There is an essential difference in how the .desktop file is used, in the launcher or on double-click. – Jacob Vlijm Jan 05 '17 at 09:22
  • @JacobVlijm "Does it call the application?" It does. And please enlighten me on the difference between launcher and double click. Aside from having right click options, their purpose is the same. Plus again, in all my experience , from 13.10 to 16.04 all Ubuntu versions work exactly same, and require x bit on .desktop files. – Sergiy Kolodyazhnyy Jan 05 '17 at 09:29
  • @Serg, let's not make it a quarrel, let's say you are absolutely sure they do need to be executable to run from the launcher, I am absolutely sure they don't. Only when used as double-click launcher from e.g. your Desktop. – Jacob Vlijm Jan 05 '17 at 09:31
0

Current answers provide bits and pieces of the proper approach. In this answer, I would like to provide more coherent overview of what needs to be done to port the .desktop files.

  1. Actual applications will have to be installed on the new system. .desktop files are merely shortcuts for those applications. If the actual application is not installed, it is pointless to copy .desktop files.

  2. As per Ubuntu's security policy, (link https://wiki.ubuntu.com/SecurityTeam/Policies) , the .desktop files residing in user's home folder have to have executable bit set in order to run (also discussed on another Ask Ubuntu question here). Quick test confirms that they do not stick to launcher, unless executable bit is set. Without executable bit set, they will not run and Unity will deem such application launcher as untrusted. (Note that if the .desktop is cached in memory, it can still appear on the launcher when you remove executable permission - don't be fooled by that). Use chmod +x file.desktop in terminal or right-clicking on application and under Permissions tab check "Allow executing as program" option.

    Another potential issue is ownership and read permissions. If the file belongs to different user and groups, without read permissions you cannot access .desktop file, thus it won't launch and won't still to Unity Launcher. The solution here is to either sudo chmod +r name.desktop or chown $USER:$USER name.desktop.

    NOTE: I've put strikethrough over parts that turned out to be incorrect. For a very peculiar reason, Unity launcher deviates from the security policy.

  3. Placing .desktop files into ~/.local/share/applications (as has been revealed in the comments) doesn't make them appear on Unity launcher. That folder is for storing your own, custom .desktop files. Adding items to Unity launcher can be done by hand, or via command line with gsetting or dconf command. There are alternative approaches, however. Please see this post on multiple ways of adding .desktop files to the Launcher: https://askubuntu.com/a/829228/295286

Community
  • 1
Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • #2 is pretty much completely incorrect (- except for ownership part though again the x is not needed in ~/.local/share/applications – doug Jan 08 '17 at 12:35
  • @doug I've put strikethough incorrect parts. The fact that you need executable bit set for double-clicking is true - there's literally tons of questions on askubuntu about "why does my .desktop file not running?" and 90% of the time it's the executable bit. Check the links I've provided – Sergiy Kolodyazhnyy Jan 08 '17 at 12:48
  • D. clicking, yes, but the question was about use via the (unity) launcher. Also, on 2nd thought ownership probably is also irrelevant in ~/.local/share/applications – doug Jan 08 '17 at 12:57
  • @doug my original assumption was that security policy also extends to Unity launcher, which it turned out to be false. In my tests , I've had a few launchers which just wouldn't stick, which I still can't have explanation. As for ownership,well, try it out for yourself: chmod root:root one of the .desktop files and see if if sticks to the Unity Launcher. I test my answers, so i know ownership affects it. – Sergiy Kolodyazhnyy Jan 08 '17 at 13:06
  • @doug let me add correction to that: if file belongs to a different user:group , and you (or your group) don't have read permissions over that file, then it won't work. If file is -rwxr-xr-x 1 root root (so , read permission granted to all) , then it can stick to the launcher – Sergiy Kolodyazhnyy Jan 08 '17 at 13:16