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

Improve this question
5
  • Do you mean they don't appear in the launcher or n Dash? – Jacob Vlijm Jan 3 '17 at 18:41
  • In the launcher – Breaking not so bad Jan 4 '17 at 2: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 5 '17 at 11:08
  • @Serg No I didn't try to drag them yet - will probably do that stuff during the coming week end. – Breaking not so bad Jan 5 '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 5 '17 at 12:20
8
+100

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

Improve this answer
2
  • most logical & straightforward answer of the current bunch. – doug Jan 3 '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. – user37165 Jan 4 '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.

Improve this answer
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.

Improve this answer
15
  • 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. – Breaking not so bad Sep 30 '16 at 16:44
  • For the launcher, being executable is irrellevant. – Jacob Vlijm Jan 3 '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 5 '17 at 8: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 5 '17 at 8:55
  • @JacobVlijm Ubuntu 16.04 LTS. Please read 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 5 '17 at 8:57
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

Improve this answer
5
  • #2 is pretty much completely incorrect (- except for ownership part though again the x is not needed in ~/.local/share/applications – doug Jan 8 '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 8 '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 8 '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 8 '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 8 '17 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.