SUMMARY (Version on my system is 5.22.5, but it's not in the version listing above) KMenuedit no longer adheres to directory structure in ~/.local/share/applications on writing, but still does on reading. STEPS TO REPRODUCE 1. Use KMmenuedit to make a change to an existing menu item within a submenu, or create a new submenu within an existing menu. 2. Save menu settings. 3. Open KMenu and select application newly edited or created. OBSERVED RESULT Selecting the newly edited application results in executing (or trying to execute) the application with the original, unedited settings. None of the newly entered items are shown at all, be they new items or new submenu items. EXPECTED RESULT KMenu system to utilize one simple to understand system, and not get confused by using many, hard to understand systems. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-37-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: AMD Radeon RX 5600 XT ADDITIONAL INFORMATION Using as example, Scrivener under wine. For the edited item, KMenueedit creates a new .desktop file ~/.local/share/applications/wine-Programs-Scrivener 3-Scrivener .desktop and the original ~/.local/share/applications/wine/Programs/Scrivener 3/Scrivener.desktop remains unchanged. When the application is selected to run from KMenu, the original .desktop file is used and the new one it just created in applications is ignored. During a test, when trying to create a new submenu within a menu, adding an entry to it creates the .desktop file within the applications directory without any prefix indicating it's part of a submenu. Creating the following: Multimedia -> Testing -> Test item one Multimedia -> Testing -> Test item two Multimedia -> Test item one Creates the following in ~/.local/share/applications: Test item one.desktop Test item two.desktop Test item one-2.desktop After saving, the only none of the new testing entries appear in the menu, and opening KMenuedit again shows only Testing as a blank application rather than a submenu containing two items, and Test item one-2 is not in the Multimedia submenu. Furthermore, ~/.local/share/applications is filled with .desktop files that appear in my menu under submenus, but there is no indication as to what submenu they belong to, neither in the name, as in does in 'wine-Programs-Scrivener 3-Scrivener.desktop', nor anywhere within the file. Two examples (of many): my ~/.local/share/applications directory has these two files: PyCharm.desktop, which is under the Development submenu, and SimpleNote.desktop, which is under the Interenet submenu. I have no idea how KMenu knows where these two items should appear. It seems whatever changes are being made to the menuing system is making things confusing and the menu system starting to break. KMenu should use either a <menu><submenu><Application Name>.desktop, or a menu/submenu/Application Name.desktop path system. Personally, I like the path per menu system my self, but either one would be preferable to a broken mix of the two, plus an extra non-submenu filename, that it's using now.
When you say "KMenu" are you referring to Kickoff (Application Launcher) or Kicker (Application Menu) Or something else? Does it work if you restart Plasma manually with `plasmashell --replace` in a terminal window and then try to launch the app whose menu entry you edited?
(In reply to Nate Graham from comment #1) > When you say "KMenu" are you referring to Kickoff (Application Launcher) or > Kicker (Application Menu) Or something else? > > Does it work if you restart Plasma manually with `plasmashell --replace` in > a terminal window and then try to launch the app whose menu entry you edited? I've tried Application Dashboard, Application Launcher, Application Menu, Excalibur Menu and Simple Menu, all three show (or don't show) the same items. Does it really matter which I meant, though? All menus should be using the same data and structure, and KMenuEdit should handle it properly and consistently. I've rebooted several times since, and the issue hasn't changed.
Right yeah, so there does seem to be an issue with KMenuEdit for you.
There's no issue with the menu editor. Kickoff has "flat: true" set on the model.
The reporter said it reproduces with menus that aren't Kickoff, though.