Hello !
I have a problem with my installation of Manjaro. When i’m launching a shortcut (from the menu or from the desktop), it launches a white page in the taskbar for a second, then closes.
I checked the executable behind the shortcut (the exec setting in the .desktop file) by launching the command manually on konsole and it worked just fine.
I’ve searched for quite a while online for a fix, but i didn’t find someone that had the same problem as me.
All launchers or just some?
Are these .desktop files you created or are they from the system?
If they are your own please include a sample.
Enhancement:- Please also tell us which application is concerned, and where it was installed from (eg: default repo’s, AUR; flatpak; etc).
Not all the launchers fail to launch. I noticed that all the launchers that launched a bash script failed.
Here’s an example of a shortcut that doesn’t work:
[Desktop Entry]
Name=Word
Exec=/home/aurel/.local/bin/winapps word-o365 %F
Terminal=false
Type=Application
Icon=/home/aurel/.local/share/winapps/apps/word-o365/icon.svg
StartupWMClass=Microsoft Word
Comment=Microsoft Word
Categories=WinApps;Office
MimeType=application/msword;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/vnd.openxmlformats-officedocument.wordprocessingml.template;application/vnd.ms-word.document.macroEnabled.12;application/vnd.ms-word.template.macroEnabled.12;
It’s from a tool called winapps that basically opens a RDP session on a windows KVM with a windows app in it. I know the tool works because when i launch the command in the exec setting manually on a cli, it works.
I’m unfamiliar with winapps, sorry.
Have you made the .desktop files executable?
No problem, yes, they are:
ls -al .local/share/applications/word-o365.desktop
-rwxr-xr-x 1 aurel aurel 520 7 oct 09:49 .local/share/applications/word-o365.desktop
I dont know what winapps looks like, but you said it is a bash script
>>
Exec=/usr/bin/bash "/home/aurel/.local/bin/winapps word-o365 %F"
2 Likes
I missed that completely. Yes, that should probably help. 
.desktop files don’t need execute permission. 
No, not if popups are something you enjoy!
None of my .desktop files have execute permission, and yet I don’t get any of those popups.
Besides, those popups have nothing to do with the actual on-disk permissions. They are for setting the default action on an executable file, which itself is called upon by its .desktop file.
Yes, and by clicking the ‘Execute’ button, ergo, it’s… executable.
When a .desktop file is launched from it’s usual location, that popup is probably never seen, however, from a .desktop created in the menu, or on the desktop proper, it can be.
Doesn’t have anything to do with the filesystem permissions. A .desktop file is just a plain text file that is parsed by any XDG-capable desktop environment for determining what to do with the target it points at.
True. However, from an esoteric standpoint an ‘execute’ button still makes the thing launch, if “is executable” is not already selected it the .desktop file’s Permissions tab.
Yes, but OP stated the following… 
… which is why I wrote…
But…
That permissions tab sets the filesystem permissions on the file. This is a completely different thing.
I think I ignored that; for all the obvious reasons.
Unfortunately, some of the packagers don’t really understand this whole permissions issue and install packages with 755 permissions on their .desktop files under /usr/share/applications — I’ve already had to correct this several times.
I guess that’s what you can expect when you get packagers — even over at Arch, which is Manjaro’s upstream — who grew up on Microsoft Windows and Android, and who’ve ever even seen a UNIX system from up close (if they even know what it is). 
Anyway, returning to the topic, I think @cscs nailed it in post #7. The OP should get back to us on that. 
I’ve seen it: install -Dm755 ... whereas Dm644 is probably more appropriate, unless memory fails me.
1 Like
Well, I don’t know enough about packaging to parse what -Dm stands for. If it stands for a directory — the D? — then 755 is usually appropriate. Not always, but usually. But even then they still get it wrong from time to time. 
I’m likely in the same boat; most of what I’ve learned was borne out of necessity, for example, when a provided PKGBUILD was incomplete, or totally borked. My understanding is that the -DmXXX signifies directory permissions; the XXX the permission attribute itself, being dependent on where the file should be installed to; for example:
install -Dm644 "${srcdir}/${pkgname}.desktop" --> `${pkgdir}/usr/share/applications`
install -Dm755 "${srcdir}/${pkgname}.sh" --> `${pkgdir}/usr/bin`
… or similar. Note, this is pseudo-code – do not try this at home!
I haven’t needed to delve too deep thus far. @dmt might have something to add though.
1 Like