https://bugs.kde.org/show_bug.cgi?id=443503
Bug ID: 443503
Summary: KMenuedit no longer utilizes application directory
structure
Product: kmenuedit
Version: unspecified
Platform: Neon Packages
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: lnx...@westlot.net
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
