My Apps are Not Appearing in the Start Menu ZorinOS 16 Pro

General Help
#1

I have just upgraded from ZorinOS 15.3 Premium to 16 Pro. With 15.3, I created .desktop files for apps I developed. I placed them in ~/.local/share/applications. They then appeared under 'Other' in the start menu and worked as desired. I also placed them on the taskbar. With ZorinOS 16 they are not appearing, although the .desktop files are still there. As a test, I copied one of them to /usr/share/applications. It made no difference. Following are the contents of one of the previously working files. Note that my apps appeared under 'Other' in 15.3 rather than under 'Jim' as I specified (apparently incorrectly).
[Desktop Entry]
Name=Foci
Exec=/usr/bin/foci/foci.py
Terminal=false
Type=Application
Icon=/usr/bin/foci/foci64x64.png
StartupNotify=true
Categories=Jim

Name[en_US]=foci.desktop

System tray icons invisible
Rhythmbox not showing on panel
#2

The best I can suggest is retrace all your steps. Check the actual executable files.
You might use Menulibre or Alacarte to double check that the Menu will show the entries.
That is, they may be present, but unchecked in Alarcarte.

#3

I hope someone can suggest something. The items do not show up in alacarte, but menulibre lists them as having unknown errors. I have spent hours trying this and that. I can create new entries in the App Menu using alacarte, but they don't work. Selecting them has no apparent effect. These desktop files were restored by Deja-dup after I upgraded to ZorinOS 16, but no longer work. The apps are written in python3. I've read articles and watched videos on this topic, but I'm already doing what they say to do.

#4

Can you clarify this statement?
This may be the Clue to the trouble.

Deja-dup may have saved the configuration and desktop files saved in the Home Directory, but not that actual Installed Programs in Root.
If you install each of the misbehaving entries, that may solve the problem.

#5

I placed the desktop files in my home directory tree: ~/.local/share/applications/foci.desktop, for example. They worked there in 15.3. I made a deja-dup backup of the /home tree, wiped the SSD, partitioned the disk, installed ZorinOS 16 and restored /home using deja-dup. Everything appears ok except that the desktop files do not work. The ownership is jim:jim. I tried changing it to root:root with no luck. I changed it back and executed chmod u+x on it. Nothing changed. Note that the correct foci.desktop icon appears in menulibre if I place it into /usr/share/applications, but not in the App Menu.

#6

The desktop files are entries that direct to the program, not the programs themselves. I believe this is sorted: The programs in question are not installed.

Choose one of your non-working programs and then attempt to install it; this will be an effective test of my hypothesis. If it works... then, one down... the rest to go.

#7

I'm actually using the programs right now by starting them all in terminal. They are not installed. They are just python scripts in /usr/bin/foci, for example. I run them from terminal as:
$sudo python3 /usr/bin/foci/foci.py. Now that the pyperclip issue is resolved, they all run correctly. I just want them in the App Menu where they used to be under Other.

1 Like
#8

Apologies. Here I thought we were on the right track... I think I need not explain what I was thinking.

Well hmmm...

  • Transferring the desktop files should be fine.
  • It is logical that if they worked on 15.3, they should work on 16. We are not aware of any significant change in how desktop entries are handled between 18.04 and 20.04. Looking at the entry in the O.P., I see nothing that would make it not work.
  • It launches from terminal.

No wonder you are stumped.

Does Menulibre detail the errors?

#9

Menulibre says, in somewhat strange English:
/home/jim/.local/share/applications/foci.desktop
Unknown error. Desktop file appears to be are valid.

1 Like
#10

I did a search on that error anyway, just is case the results is valid.

I came upon this thread that has some very interesting suggestions. It has some length to it:
https://askubuntu.com/questions/1237042/desktop-files-not-launching-from-desktop-in-ubuntu-20-04-ltshttps://askubuntu.com/questions/1237042/desktop-files-not-launching-from-desktop-in-ubuntu-20-04-lts

The consensus though, is that others have experienced the same you have in transferring from pre-19.04 to over 19.04
Very strange. For many, simply moving the file back and forth did the trick.
Another installed the file using the terminal and that did the trick.
But the takeaway is that it is probably not an error within your desktop entries.

#11

This may be an important clue as to what is happening. foci.desktop specifies:
exec=/usr/bin/foci/foci.py
When opened in menulibre, the exec= line is blank.
So, using menulibre, I added a different exec line, thus:
exec=python3 /usr/bin/foci/foci.desktop
If I exit menulibre and reenter it, it remembers what I entered, but the foci.desktop file was not changed. It still has the old exec= line. menulibre is storing the exec= line somewhere else.

#12

Is the menulibre exec command effective?
Menulibre should only store changes in the two known locations. /usr/share/applications or ~/.local/share/applications

What if you re-make your desktop files fresh and new? For all the wild goosechase this issue has led you on, it certainly wouldn't be extraneous work. But I wonder if the transferred files themselves have a corruption. Not necessarily within themselves, but within the markers. A new desktop file on the new system may not have that problem.

#13

I made a fresh and squeaky clean foci.desktop file, but, alas, now it no longer shows up in menulibre, either. I also tried most of the things in the endless suggestions of the link you shared.
I also tried sudo desktop-file-install foci.desktop. I'm running on empty.

#14

No one can blame you. This is a real stumper.

I have tried some additional searching and all I am finding are complaints:

In ubuntu 20.04 you need to make the file executable first, then you'll find the "allow launching" option, anyway I can't add it to the launcher, there's simply no way to do it.
[Desktop Entry]
Version=1.0
Name=blender
Type=Application
Exec=/home/ego/blender-2.93.0-9b87d3f02962-linux64/blender
TryExec=/home/ego/blender-2.93.0-9b87d3f02962-linux64/blender
Terminal=false
StartupNotify=true
It's ridiculous that there's no easy way to do this. You need to search google and become crazy simply to add one icon. One icon. Great OS.

This is a common trend I am reading the more I dig- that something after Ubuntu 19.04 broke how desktop files are handled - but only if these are desktop files created by the user.
If I was given to conspiracy claims, I might wonder if Canonical was pinching off user control. It just seems so specific. I'd prefer to not take that road, just yet...
Will keep searching...

#15

5 posts were split to a new topic: Minimized App icons not showing in Panel

#16

I just edited the firefox.desktop file. I changed the 3 instances of Exec= as follows:
Exec=/usr/bin/python3 /usr/bin/foci/foci.py %u
Exec=/usr/bin/python3 /usr/bin/foci/foci.py
Exec=/usr/bin/python3 /usr/bin/foci/foci.py
To my surprise, the app menu icon for Firefox still invokes Firefox. Since this dumbfounded me, I restarted the system. It still invokes Firefox. I obviously do not understand the purpose of Exec=. I did not know the purpose of the %u that appears at the end of one of the Exec= lines, so I left it there. CORRECTION: It didn't start the Firefox main window. Rather, it opened Firefox bookmarks.

#17

It may not help, but I need to correct some things that I said. The foci icon is showing up in the app menu after all. Instead of placing it in the Other category, as specified, it is creating a second 'Other' entry clear at the end of all of the categories and placing the icon there. When I click on it, a terminal window appears for a split second, then closes. I have terminal set to false in the desktop file. By repeatedly clicking the icon from the taskbar, I was able to make out the word Terminal in the frame that briefly appears, then shrinks to nothing.

#18

Baffling. Ok, so we at least have some clues here: The entries are affecting the app menu. That is good, at least. We can work with that.
But I agree that Terminal should be set to false.

What happens if you run the launch command directly from the terminal? If it launches, what do you get if you launch it with verbosity?

#19

I'm not certain of what you are asking. Do you mean to run '/usr/bin/python3 /usr/bin/foci/foci.py' from the command line? If so, that works. If you mean use a command named 'launch', one isn't found. If there is a launch app, maybe you mean to use it with a -v option for verbose. I'm afraid my unix years were too long ago - 1991.

#20

Yes. "Launch" refers only to you entering any command that launches any application.

Yes. Running with verbosity = running in verbose mode.