ahkok
commented
5 years ago Those MimeType messages are just warnings. The program will still indicate a successful execution with $? being 0.
Closed lebensterben closed 5 years ago
ahkok
commented
5 years ago Those MimeType messages are just warnings. The program will still indicate a successful execution with $? being 0.
lebensterben
commented
5 years ago Those MimeType messages are just warnings. The program will still indicate a successful execution with
$?being0.
I'm still wondering why I cannot add desktop-files successfully...
phmccarty
commented
5 years ago Just to confirm, all mentions of update-desktop-applications in the report should be update-desktop-database, correct?
phmccarty
commented
5 years ago @lebensterben The system-wide mimeinfo cache is located at /var/cache/applications/mimeinfo.cache, and it is updated with an update trigger service, mime-update.service.
When I modify my XDG_DATA_DIRS variable to have $HOME/.local/share prepended, update-desktop-database successfully creates $HOME/.local/share/applications/mimeinfo.cache. Note that I tested the command without sudo, since I just wanted to confirm correct behavior for the non-root case with the modified XDG_DATA_DIRS.
Can you check that scenario again?
I need to think through the overall picture here. Probably, setting an appropriate default value for XDG_DATA_DIRS is a good first step, and the flatpak-specific locations can be added to that default value.
lebensterben
commented
5 years ago @phmccarty
When I run update-desktop-database without sudo there are permission errors:
Search path is now: [/home/lucius/.local/share/applications, /home/lucius/.local/share/flatpak/exports/share/applications, /var/lib/flatpak/exports/share/applications, /usr/local/share/applications, /var/cache/applications, /usr/share/applications]
.....
Could not create cache file in "/var/lib/flatpak/exports/share/applications": Error opening directory ?/var/lib/flatpak/exports/share/applications?: No such file or directory
Could not create cache file in "/usr/local/share/applications": Permission denied
Could not create cache file in "/var/cache/applications": Permission denied
......
Could not create cache file in "/usr/share/applications": Permission deniedExcept for /var/lib/flatpak/exports/share/applications that doesn't exists, all other directories needs root permission, which is as expected.
There's no other error other than complaints about lacking MIME types, but still the desktop files are not updated. Because the newly added desktop files do not show up in /var/cache/applications/mimeinfo.cache.
P.S. I found that mime-update.service was not active, so I manually restarted it before executing any commands.
thiagomacieira
commented
5 years ago Adding $HOME/.local/share to XDG_DATA_DIRS is not recommended. That is already the default XDG_DATA_HOME. See the spec: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
thiagomacieira
commented
5 years ago Ok, looks like we have a case like the MIME cache: the cache is present in the /usr/ dir, which Clear does not support. The cache should be placed in /var/cache instead. Recommendation: install /usr/share/applications/mimeinfo.cache as a symlink to ../../../var/cache/mimeinfo.cache so it can be generated after bundle additions, removals and updates.
lebensterben
commented
5 years ago Adding $HOME/.local/share to XDG_DATA_DIRS is not recommended. That is already the default XDG_DATA_HOME. See the spec: specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
If if didn't append $HOME/.local/share to XDG_DATA_DIRS, and then update-desktop-database -v would show the following:
Search path is now: [/home/lucius/.local/share/flatpak/exports/share/applications, /var/lib/flatpak/exports/share/applications, /usr/local/share/applications, /var/cache/applications, /usr/share/applications]And actually for some reason XDG_DATA_DIRS is not correctly set,
> echo $XDG_DATA_DIRS
/home/lucius/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/var/cache/:/usr/share/Ok, looks like we have a case like the MIME cache: the cache is present in the /usr/ dir, which Clear does not support. The cache should be placed in /var/cache instead. Recommendation: install /usr/share/applications/mimeinfo.cache as a symlink to ../../../var/cache/mimeinfo.cache so it can be generated after bundle additions, removals and updates.
First, I found that at this point, these two /usr/share/applications/mimeinfo.cache and /var/cache/applications/mimeinfo.cache are identical.
But interestingly, /usr/share/applications/mimeinfo.cache is newer and sudo update-desktop-database would change it's modified time. Meanwhile, the modified time of ~/.local/share/applications/mimeinfo.cache is determined by the last time I execute update-desktop-database ~/.local/share/applications. (Note that I unset the environment variable $XDG_DATA_HOME and this directory is not processed by update-desktop-databse.)
And the modified time of /var/cache/applications/mimeinfo.cache, 20:42:48:433418517, is not the same as either of the other two. More interestingly, I've the following findings:
zsh and it's history shows the timestamps of commands I executed, around the time when this file was modified, I haven't done anything in shell.journalctl and I find that, at 20:37, swupd automatically updated from 29289 to 29310, and at 20:42, swupd called post-update helper scripts.
icon-cache-update.sh[23514]: gtk-update-icon-cache: Cache file created successfully.gnome-software[2035]: failed to rescan: Failed to parse /var/cache/applications/mimeinfo.cache file: cannot process file of type text/plainPreviously I've built R-studio myself and have it installed under /usr/lib and this afternoon I removed it and installed the new R-rstudio bundle, which is under /usr/lib64/R. I can open it right after the installation without problem. So my guess is, only /var/cache/applications/mimeinfo.cache seems to be working now, which is updated by some post-update scripts.
If I create a soft link as you suggested, then both swupd and update-desktop-database would correctly update it, for both clear bundles and custom desktop entries.
lebensterben
commented
5 years ago Just an update on a more interesting finding related to the problem:
I've a custom desktop file for PyCharm and a while ago I put it in ~/.local/share/applications and it doesn't work. So I put it in /usr/share/applications, and it worked. (So I've two duplicated ones.)
I updated PyCharm today and moved it to a new directory, and modified the the desktop file in ~/.local/share/applications, and left the other untouched.
update-desktop-database, I can start the PyCharm, which has been moved to another directory./usr/share/applications/pycharm.desktop, it doesn't matter, given that ~/.local/share/applications/pycharm.desktop has correct specifications.P.S. The problem reported before is still bothering me, I'd appreciate it if anyone could offer some help.
lebensterben
commented
5 years ago I've found a mysterious way which would let the desktop files show up correctly.
$HOME/.local/share/applications, /usr/share/applications, and /usr/local/share/applications, and I've tried update-desktop-database but it never workedxdg-open <path-to-a-desktop-file>, then on my system gedit will pop up with the desktop file opened. Close the gedit app, and the desktop entry just mysteriously show up in gnome!!!Furthermore,
/usr/local/share/applications won't show up but those under the other two directories will show up correctlylebensterben
commented
5 years ago This is not a bug by update-desktop-database itself, but caused by not setting environment variables correctly. More details in #742
bam80
commented
3 years ago @lebensterben could you describe solution that worked for you? Still can't get it to update my .desktop file, I'm on bash.
lebensterben
commented
3 years ago @bam80 post your desktop file here
bam80
commented
3 years ago [bam@host ~]$ cat ~/.local/share/applications/charmtimetracker.desktop
[Desktop Entry]
Name=Charm
GenericName=Time Tracker
#Exec=env QT_QPA_PLATFORM=xcb toolbox run charmtimetracker --hide-at-start
Exec=toolbox -c fedora-toolbox-32 run charmtimetracker --hide-at-start
Icon=Charm
Type=Application
Categories=Qt;KDE;Utility;
X-KDE-StartupNotify=true
StartupWMClass=com.kdab.charmtimetrackerI fixed Exec command and from console it works, but Gnome seem doesn't see the change. I didn't relogin but wanted to solve problem without..
lebensterben
commented
3 years ago @bam80 Very likely it's because gnome cannot find the icon. It should be located in some sub directory of ~/.local/share/icons
lebensterben
commented
3 years ago Notice that the icon should be named Charm.png for example
bam80
commented
3 years ago The icon is there and displayed. Just old Exec command executed for some reason.. Interesting, if I start searching for a program in menu and launch via found item - it runs fine. Just default menu item doesn't work. Looks like a Gnome bug. Interesting if it can be reproduced somewhere else.. Then we should report it I think. Thanks.
lebensterben
commented
3 years ago The icon is there and displayed. Just old Exec command executed for some reason.. ...
@bam80 can you try to supply the full path to the icon? And also the full path to the binary
iamarkadyt
commented
3 years ago @lebensterben I read through #742 you seem to mention zshell everywhere. I'm on bash, could you please elaborate more on which environment variables exactly get misconfigured that are causing this issue?
lebensterben
commented
3 years ago @iamarkadyt then it's simply irrelevant.
iamarkadyt
commented
3 years ago Did some digging around. I figured out why my desktop files were not showing up in my app grid:
- Value in the "Name" field should match the name in the desktop file.
So that <app-name>.desktop is the same value as in Name=<app-name>.
- Value in the "Exec" field has to be absolute.
Example: /home/me/Software/my-binaryHere is the final desktop file example. File name: 'MyApp.desktop'.
[Desktop Entry]
Type=Application
Name=MyApp
Comment=My application description
Icon=/home/me/Software/myapp/icons/default128.png
Exec=/home/me/Software/myapp/app-binaryPosting here since this comes up 1st in search results. Hopefully it will help someone. Re-run "update-desktop-files ~/.local/share/applications" after you make these changes.
lebensterben
commented
3 years ago Both are false!
Name is a localization-specific string, it can have multiple values. It certainly doesn't require Name to match the basename of desktop file.
Exec doesn't need to be absolute path:
The executable program can either be specified with its full path or with the name of the executable only.
lebensterben
commented
3 years ago What needs to be absolute is Icon. And if the icon file doesn't exist, this desktop entry will not show up.
dzintars
commented
3 years ago As an addition to this issue it is useful to use desktop-file-validate ~/.local/share/applications/Application.desktop to get at least some hints if there is an syntax error.
There is an example of output:
» desktop-file-validate .local/share/applications/Obsidian.desktop
.local/share/applications/Obsidian.desktop: error: (will be fatal in the future): value "Obsidian.png" for key
"Icon" in group "Desktop Entry" is an icon name with an extension, but there should be no extension as
described in the Icon Theme Specification if the value is not an absolute path
Description
After adding a desktop entries to
$XDG_DATA_DIRS/applicationsand executeupdate-desktop-applications, one would expect the entries to show up in gnome, given that the desktop file is valid. But nothing shows up, even after a reboot.More Details
/usr/share/applications, then after a relogin the application would appear, but not after runningupdate-desktop-applications.update-desktop-applicationswould process all desktop files under$XDG_DATA_DIRS/applications.echo $XDG_DATA_DIRSoutputs the following:/home/lucius/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/var/cache/:/usr/share/$HOME/.local/share/applications, thus I added the$HOME/.local/shareintoXDG_DATA_DIRSenvironment variable and executeupdate-desktop-applicationsagain. But it still doesn't workupdate-desktop-applications, it doesn't work either.sudo update-desktop-applications -vas its verbose mode, below is the output:We can see a lot of waning about lacking MimeType key. If I execute
update-desktop-database ~/.local/share/applications -v, which directly specify the directory where I store the desktop files, similar errors appears.So my question is, does those missing MimeType keys prevented the
update-desktop-databasecommand to correctly process desktop files and thus caused the problem?