For "start menu" is defined by lots of .directory files in plasma-workspace
The file to say which desktop files go in which directory is in kservice
It doesn't seem right.
Things happen to work, until you make a change then we get a situation.
For more details see D24423 where someone is making a change and hitting a problem
IMHO kbuildsycoca should find applications.menu dynamically at runtime from the system it seems it would be more cross desktop?
applications.menu is installed at /etc/xdg/menu/kf5-applications.menu. The folder contains multiple *.menu files. The freedesktop.org spec is here https://freedesktop.org/wiki/Specifications/menu-spec/
Plasma is able to read:
If I install the new file as kf5-applications-new.menu or kf6-applications.menu, it gets ignored.
@guoyunhe can you propose a solution for KF6 that would make sure we don't have future conflicts
Makes sense I guess. The code to parse the menu files is still in kservice/src/sycoca/vfolder_menu.cpp but kservice's job is just to read whatever is there, it doesn't need to provide it by itself. We'll just keep an uninstalled copy for the autotest ;)
Just to flesh that out more. KF5 will be presumably be co-installable with KF6 and Plasma 6 so we can't just move the file.
We would need to:
Given we have to handle a rename anyway, it's presumably doable within the KF5 lifetime?
If we want to ship applications.menu with Plasma 5.18.0 that needs to happen effectively today.
Look like we didn't catch the opportunity of Plasma 5.18.0. But I have some idea on the naming.
*.directory files are located in plasma-workspace/menu/desktop/*.directory. So I guess the applications.menu file should be moved to plasma-workspace/menu/desktop/applications.menu. Maybe in future, there will also be different category trees for Plasma Mobile or Plasma Tablet.
Then the *.menu file can be installed with name like plasma5-applications.menu. And future KDE6 can have plasma6-applications.menu. Because these files will come from Plasma packages, instead of KF5 packages.
The work plan is:
KService should use a copy of applications.menu for its own unittests, so that the file can move to plasma. I can work on that.
Actually, that's done already, src/CMakeLists.txt makes a copy of applications.menu into the right build dir for the unittests to pick up.
So this will keep working even if kservice stops installing that file, all we'll have to do for cleanliness is to move it from src/ to autotests/.
And copy it to plasma.
But all this has to wait for KF6 branching.
There's a problem: Without applications.menu KService stops working on Gnome. Even basic usage like KService::serviceByDesktopName("org.kde.konsole") then fails
Gnome ships something for sure (applications.menu or gnome-applications.menu, not sure, see https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html), but overall, we should be able to find org.kde.konsole independently from menus, IMHO.
That's what Type=Service desktop files (installed in kservices5) are for.
IMHO konsole should install such a file, like konqueror does.
This isn't about services in the KDE sense though, it's about applications. (It's not about konsole*part* but the actual Konsole application)
I got confused by my incomplete Gnome installation, Gnome indeed ships gnome-applications.menu and this is a non-issue
My proposed course of action:
Move the file to plasma-workspace and rename it to plasma-applications.menu
Set XDG_MENU_PREFIX in startplasma
Remove the one in kf6-kservice (or rather keep it only for tests)
https://invent.kde.org/frameworks/kservice/-/merge_requests/153 and https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3053 implement that