Bug 412852 - A way to locate .desktop files corresponding to menu entries
Summary: A way to locate .desktop files corresponding to menu entries
Status: RESOLVED FIXED
Alias: None
Product: kmenuedit
Classification: Applications
Component: general (show other bugs)
Version: 6.2.90
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: regression
: 499261 500864 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-11 14:17 UTC by leftcrane
Modified: 2025-03-23 13:15 UTC (History)
10 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/kmenuedit/-/commit/1cb3e619b4990d2dfab421ace30399d0eb070581
Version Fixed In: 6.4.0
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description leftcrane 2019-10-11 14:17:01 UTC 
Many variables for desktop launchers are not supported by the menu editor. So it would be helpful to have an option to locate the actual .desktop file and edit it in a text editor (or an integrated editor).
Comment 1 Matt Alexander 2022-02-06 21:43:56 UTC 
Ping. 

I would like to second this request. I really need to know where the .desktop file is located for the menu items I'm editing. I've been hovering over things, looking for the path in tooltips, but it doesn't seem to be anywhere.
Comment 2 Ilya Bizyaev 2025-01-19 15:22:54 UTC 
This became particularly relevant with Plasma 6.3, where because of https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4969 there is now no way to locate .desktop files from Kickoff's model.

Previously, having this information in Kickoff's properties dialog was useful for troubleshooting all kinds of problems caused by user-edited versions of launchers. I'm not aware of any other way to do this that regular users can follow through, so I consider this a regression from the user support perspective.
https://invent.kde.org/plasma/plasma-desktop/-/issues/140#note_1107206
Comment 3 Shivang Rathore 2025-02-13 08:31:44 UTC 
Another thing we can do, keep edit application to open kmenuedit but add another context menu entry 'properties', I was used to this behavior and sudden change is causing so much problem.
Comment 4 Nate Graham 2025-02-28 16:49:42 UTC 
*** Bug 500864 has been marked as a duplicate of this bug. ***
Comment 5 Bug Janitor Service 2025-03-17 23:12:47 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kmenuedit/-/merge_requests/40
Comment 6 Oliver Beard 2025-03-19 23:43:11 UTC 
Git commit 1cb3e619b4990d2dfab421ace30399d0eb070581 by Oliver Beard.
Committed on 18/03/2025 at 22:02.
Pushed by olib into branch 'master'.

Add file actions including path, open containing and file properties for entry
Now, you can open the normal file properties dialog for any entry by pressing the standard shortcut or in the file and context menus. Also included are actions to copy the location and open that location in the file manager, comparable to Kate/KWrite.

This works for both menu entries and directories.
FIXED-IN: 6.4.0

M  +12   -0    kmenuedit.cpp
M  +7    -1    kmenueditui.rc
M  +70   -0    treeview.cpp
M  +7    -0    treeview.h

https://invent.kde.org/plasma/kmenuedit/-/commit/1cb3e619b4990d2dfab421ace30399d0eb070581
Comment 7 Oliver Beard 2025-03-23 13:15:06 UTC 
*** Bug 499261 has been marked as a duplicate of this bug. ***