I use several Linux-based computers, which include an older machine running Debian / Jessie and the KDE 4 desktop manager, and a more-recently-installed machine, running Debian / Stretch and the Plasma 5.8 desktop manager.
Under KDE 4 – which I’ve grown used to over the years – the K-Menu – aka, the Application Launcher – would display a nested menu-system, that included the KDE categories into which applications should fit, which are defined essentially by ‘.desktop’ files, plus a separate category called ‘Debian’, which was denoted by a folder-icon, and which was nested several levels deep, into which almost every installed application should be sortable, defined essentially by the contents of the directory ‘/usr/share/menu’.
Under my Plasma 5.8 setup, one fact which I was missing, was the earlier presence of this Debian -category:
Instead, this computer has a larger abundance of entries, in its Lost+Found category (not shown), which is really just another way of saying, ‘entries which it cannot otherwise put into categories’. In fact, many of the entries that now occur under Lost+Found, also occur under listed categories.
(Updated 12/14/2017 : )
There exist several commands which a user can give – as user – to straighten out various bugs in the Plasma 5 desktop cache, such as:
…Which should clear up such problems, in case they are due to a bug. And for almost a full day, I pursued this behavior as if it was a bug…
After much exhaustive reading and experimenting, I have to come to the conclusion that this behavior is by design. With Plasma 5.8, the (Debian) developers have decided to make sure that the menu does not extend more than 3 levels deep.
Yet, if we have the package ‘kmenuedit’ installed, then we can edit this menu either way, to our own liking. In fact, with the added package ‘extra-xdg-menus’ installed, we can even enable or disable the additional categories ‘Electronics’ and ‘Ham Radio’, which operate automatically.
Apparently, lengthy searching for applications in menu-levels that go too deep, is not fashionable right now. We might be better off just to type whatever we’re looking for into a search-field.
(Edit 12/14/2017 : )
It’s very likely that several distributions of Linux, such as ‘Kanotix’ and ‘Kubuntu’, offer this Debian Menu as a feature. This would be caused by certain default files, which are copied into a user’s home directory, with sub-directories, each time a new user is created. But as it looks to me right now, a stock Debian install of Plasma 5.8, just from the package-manager, doesn’t have it.
Now, there is a command which copies the default files into an existing user’s home directory, which would be given as the affected user:
cp -rf /etc/skel/* /etc/skel/.* "$HOME"
! But This will also reset ALL the user’s desktop-configuration customizations, and should only be used as a last resort, to rescue a home directory, in which a user has valued data, and when that user has lost all control over his desktop – i.e, may not even be able to log in.
! The above command assumes that $HOME exists.
IMHO, simply editing the menu with ‘KMenuEdit’ seems easier, as long as my desktop is not really corrupted.
On a similar note, I had previously written somewhere, that after we’ve installed ‘kmenuedit’, we can edit our Menus at will, but will be doomed to having to invoke ‘kmenuedit’ from the command-line.
As fate would have it, after we have rebooted and started a new session with KDE or with Plasma 5.8, right-clicking on the Application Launcher reveals a new entry, named “Edit Applications”, which launches this feature in a user-friendly way, for all users.
Assuming that our Panel is working.
The following experiment demonstrates, that If ‘origin’ is a directory, and If we use the Unix-style:
cp -rf origin new_location
…and If a sub-directory named ‘new_location/origin’ already exists, Then the new contents, taken from ‘origin’, are just overlaid onto the old contents, which were already present under ‘new_location/origin/':
dirk@Phoenix:~$ mkdir target dirk@Phoenix:~$ cd target dirk@Phoenix:~/target$ mkdir new_dir dirk@Phoenix:~/target$ cd dirk@Phoenix:~$ cd ~/tmp dirk@Phoenix:~/tmp$ mkdir target dirk@Phoenix:~/tmp$ cd target dirk@Phoenix:~/tmp/target$ mkdir prev_dir dirk@Phoenix:~/tmp/target$ cd dirk@Phoenix:~$ cp -rf ~/target ~/tmp dirk@Phoenix:~$ cd ~/tmp dirk@Phoenix:~/tmp$ cd target dirk@Phoenix:~/tmp/target$ ls new_dir prev_dir dirk@Phoenix:~/tmp/target$
But I already knew that.