Bug 321152

Summary:	Desktop file not usable outside KDE due to empty incompatible field: Path[$e]=
Product:	[Applications] kmenuedit	Reporter:	Ben Armstrong <synrg>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	REPORTED ---
Severity:	normal	CC:	adaptee, cfeck, debian, dev, nyanpasu64, pasthelod
Priority:	NOR
Version:	0.8
Target Milestone:	---
Platform:	Debian unstable
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Ben Armstrong 2013-06-14 16:35:41 UTC

At a time when alacarte was temporarily broken in Debian unstable, I wanted to find a drop-in replacement for it to help another user find a workaround to this breakage. I assumed kmenuedit, which describes itself as an "XDG menu editor", would be compatible. I understand the xdg specs are not binding and each desktop environment has implemented slightly different features that may not always be compatible. However, is there really any good reason to write out an empty "Path[$e]="? This field prevents other desktops, such as Gnome3, from being able to read the desktop files that kmenuedit writes. The end result from the user's perspective is that a new custom launcher created in kmenuedit for a custom cannot be found in GNOME3.

Now, admittedly this is a minor corner case, and a knowledgable user can find the file kmenuedit writes and hand-edit it to delete the offending "Path[$e]=" line to make the desktop file visible to GNOME3, but this is tedious and ugly. It would be better if kmenuedit did not write out such fields, since they seem to serve no purpose, thereby making it more interoperable with other environments.

Thanks,
Ben

Reproducible: Always

Steps to Reproduce:
1. In a gnome-shell session, start kmenuedit
2. In an appropriate category (i used "Utilities"), File > New Item ...
3. Give it some values, such as: Name = test, Description = test, Command = xeyes, icon = gnome-eyes-applet.
4. Save
5. In gnome-shell Overview, Type to Search for "test"
Actual Results:
The new test launcher does not appear with the icon we gave it.

Expected Results:
The new test launcher should have appeared.

6. Hand-edit the file kmenuedit created, locate the line "Path[$e]=" and delete that line
7. Perform step 5 again (In gnome-shell Overview, Type to Search for "test")
-> The new test launcher appears.
8. Click on the launcher.
-> The test program will be launched.

I suspect, but don't know for sure, that other desktop environments are affected. I only tested in gnome-shell.

Comment 1 Christoph Feck 2013-06-15 10:03:15 UTC

We tried several years ago to make this KDE feature part of the standard, but there was no reply.

http://lists.freedesktop.org/archives/xdg/2009-November/011121.html

Comment 2 Ben Armstrong 2013-06-16 18:03:22 UTC

I do understand "[$e]" could be useful for some purpose. If that were the case, you might consider keeping it for kmenuedit's primary users on KDE itself, even if that made the files unusable for other users on other desktops. However, since it doesn't seem to serve any useful purpose in this case, I don't think there is any downside to fixing this bug. Drop the "Path[$e]=" line entirely, or at least when it is empty, and it looks like all gain and no loss.

Comment 3 Martin Kimmerle 2019-01-31 13:13:47 UTC

Thank you Ben for reporting this issue.

(In reply to Ben Armstrong from comment #2)
> Drop the "Path[$e]=" line [..] at least when it is empty
I fully agree.

(In reply to Ben Armstrong from comment #2)
> you might consider keeping it for kmenuedit's primary users on KDE itself
Well, an empty "Path[$e]=" line isn't necessary even for KDE/Plasma users.

-----

For the record, I ran into this issue like this:

* I created a new Desktop Entry using kmenuedit (a simple web browser wrapper)
* I set the default web browser using systemsettings5 > Applications > Default Applications > Web Browser > "in the following browser"
* I recognized that the new default was not applied for all applications.

This is my debugging summary:

> $ xdg-mime query default x-scheme-handler/http
> my-web-browser-wrapper.desktop
(This is correct.)

> $ gvfs-mime --query x-scheme-handler/http
> Default application for 'x-scheme-handler/http': firefox-esr.desktop
> Registered applications:
>         firefox-esr.desktop
>         chromium.desktop
> Recommended applications:
>         firefox-esr.desktop
>         chromium.desktop
As you can see, "my-web-browser-wrapper.desktop" is not there.

> $ gvfs-mime --set x-scheme-handler/http my-web-browser-wrapper.desktop
> Failed to load info for handler 'my-web-browser-wrapper.desktop'
The solution, as already mentioned by Ben, is to simply remove the following line
(in `$HOME/.local/share/applications/my-web-browser-wrapper.desktop`)

> Path[$e]=

Please fix this issue

Comment 4 nyanpasu64 2021-11-20 01:36:39 UTC

I encountered this issue too. The empty Path[$e] field breaks multiple menu editors:

- When I try to open a single .desktop file in Xfce's exo-desktop-item-edit, it doesn't open a window and complains in the terminal: "exo-desktop-item-edit: Failed to parse contents of "file:///home/nyanpasu64/.local/share/applications/Dn-FamiTracker.desktop": Invalid key name: Path[$e]"

- When I try to open MenuLibre (which lists all .desktop files), it doesn't show KDE-edited apps, and instead prints "Invalid desktop files detected! Please see details.". Clicking Details lists the .desktop file with the message "Unable to load desktop file due to the following error: g-key-file-error-quark: Invalid key name: Path[$e] (1)".