## Debian Category Missing From Plasma Menu.

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 : )

With KDE 3 it was a common feature, that users could arbitrarily edit their K-Menu, which is the Linux equivalent of a Windows 7, etc., Start Menu. But what frequently took place, is that users would change their K-Menu in ways that resulted in poor organization, or in deleted entries which were almost-impossible to un-delete. One undesirable side-effect of this sort of menu-editing was, that if we added a custom-launcher into the middle of an existing, default sub-menu, and if we then installed packages from the package-manager, then the K-Menu positions of the more-recently-added entries, would come before anything the user had inserted in his custom-editing. Hence, the default K-Menu would lose control, over the order of entries.

The more-recent Linux computers which I’ve been operating, are based on KDE 4, which is also the final, most-complex version of KDE, and as I had installed them, they also had a K-Menu, with no obvious way to customize its entries.

What I had not understood until recently, is that under KDE-4, there is a separate package we may install, which is called ‘kmenuedit’, which gives us the ability to edit our KDE-4, K-Menu, once more, as it was with KDE-3.

Apparently, the version of Linux I generally subscribe to has been ‘Kanotix‘, and the versions that I downloaded from them have been KDE-4-based versions, but with a suggested set of packages pre-installed, that correspond to the best-possible, initial configuration of a Linux computer, according to the Kanotix devs. And their approach may well have been, that having a K-Menu-Editor, under KDE-4, might only encourage some people to mess up their desktop-arrangements. What KDE-4 has, and what KDE-3 did not have, was a separate category in the K-Menu, which is the Favorites category.

Under KDE-4, we can add or remove applications to and from the Favorites category, for quick access, easily, and without having ‘kmenuedit’ installed. And the way 99% of my own desktop-activity has taken place, being able to do so has completely made up, for what the ability would once have given me in the past, actually to edit the K-Menu ad-hoc. So it seems to be a wise decision from ‘Kanotix’ devs.

However, some desire may exist on the part of certain users, to modify their K-Menu after all. And if we want to do that, then to install the named package would be the way to achieve it. If we do so, as an apparent, added safeguard, this GUI-based utility does not add itself to the actual K-Menu. This could prevent less-knowledgeable users on the same computer from running it accidentally, and from messing up their K-Menus. We run it for the first time, from the command-line. And, when it is installed, of course the task should be trivial, either to wake up this utility by adding it to the K-menu itself, or by way of a Global Hot-Key-Combination. This is what it looks like:

If the reader does decide to start altering his KDE-4, K-Menu, then my advice to him would be, Create Only One Sub-Menu, with All your custom entries and launchers. That way, if you install more packages from the package-manager, their place in the default K-Menu sub-menus, will not be interfered with. And then, you may obtain a desktop which is free from the clutter of custom-launchers.

One item which has always been useful to me, is a (somewhat large) Folder Widget, which by default, displays the ‘~/Desktop’ Folder. But unlike how I was used to organizing desktops in the past, this Desktop Folder Widget is a place into which I drop small file-projects of some kind, which seemed important temporarily-there, but not a place to put launchers by default.

I have two custom-launchers left on the desktop above, because

• One of those launchers does something, when an image-file is dragged on top of it,
• In the case of an HTML URL, ‘kmenuedit’ might still work, or it might not, but I felt that an HTML URL, would have been out-of-place in my customized K-Menu.

Otherwise, if the order of default entries does get messed-up, then the KDE-4 Version of ‘kmenuedit’ has a feature which the KDE-3 system did not have: A Sort button! The way to use this, is to select one sub-menu, and then from the Sort-button drop-down-list, to select either ‘Sort Selection By Name’, or ‘Sort Selection By Description’. The system-default was actually to ‘Sort By Description’. And so chances are good, that we could take over the arrangement of one sub-menu completely, and then to duplicate what the default order would have been, just using ‘Sort Selection By Description’. I do not recommend, to tell the utility to Sort Everything… , because most-probably, doing so would also change the order of all the sub-menus.

Also I should add, that If the reader wishes to do this, he may also wish to make sure, that he’s installing a Version 4.x of ‘kmenuedit’, and not a version 3.y , since only the KDE-4 Package-Versions will be compatible with KDE-4.

Dirk

## Running JACK side-by-side with PulseAudio

On the laptop I name ‘Klystron’, the default sound server is PulseAudio, as is often the case with desktop setups. And yet I found myself installing a lot of Linux music-authoring software on it, only to find that in order to get the full benefit of that, we need to be able to use JACK as our sound server. This was not really a new observation.

Specifically, in order to allow ‘Rosegarden‘ and ‘QTractor‘ to work fully, we need to have JACK. Without JACK installed, Rosegarden will complain when run that it can produce no sound output, but is still installable. And QTractor has the actual JACK daemon as one of its install dependencies. More generally, I did not find any DSSI hosts, that could run without JACK.

Under Linux, ‘LADSPA’ and ‘LV2′ are effect-plugin-APIs, which can also be used from applications such as ‘Audacity‘, while ‘DSSI’ is The Linux instrument plugin-API. One needs DSSI for any type of plugin, which receives a MIDI sequence and plays that, regardless of whether the MIDI-sequence came from a sequencer, or from a live, real controller-instrument.

And so I took the time last night, to set up the actual JACK daemon – not just its libraries – to coexist peacefully with PulseAudio.

The approach I took, was to install QJackCtl, a GUI that allows the user to start and then stop JACK, and that allows the user to configure this starting and stopping to taste. In order for JACK to do what it is supposed to do, I needed to change the ‘Server Path’ with which QJackCtl launches the daemon, to


pasuspender -- jackd



This field within QJackCtl tells the GUI what command to execute, to launch JACK, and has recently been renamed to the “Server Prefix”. Nevertheless it can still be customized in this way.

pasuspender‘ is a utility that comes with PulseAudio, which tells this server to suspend its access to the sound devices, for as long as the program is running, which follows as its command-line parameter. The two dashes are important.

I found, that although ‘pasuspenderdoes suspend PulseAudio, it also fails to resume this service, once the program has terminated, that was given as its parameter. I suspect that this happens, because QJackCtl terminates the command


pasuspender -- jackd



instead of actually terminating the child-process


jackd



Thus, pasuspender cannot act on ‘jackd‘ having exited, because the parent process was terminated, right along with the child-process. And so there is another field within QJackCtl, where I get to specify a post-shutdown script for JACK, where I simply inserted the command


pasuspender /bin/true



This second invocation of ‘pasuspender‘ exits without error, and actually causes PulseAudio to resume.

It is important to give this command in the correct field. I.e., If we gave this command in the pre-shutdown field, we would get a mess.

Now, this is a configuration which allows me marginal use of JACK, and while I have QJackCtl running, PulseAudio will just not work. There exist some script-artists, which will go further, and who have written more-complex scripts for QJackCtl to execute, and that will insert JACK as a back-end, for PulseAudio to continue sending sound-output to, once JACK has been launched. And then those scripts will also reverse this setup, and set PulseAudio back to running in its default mode, once JACK has been terminated.

I had two reasons not to go this route.

1. On my systems, the back-end which PulseAudio uses are fragile. While they can be reconfigured, doing so messes up the PulseAudio instance running, until my machines are rebooted again. Changing this configuration within a session is poorly advised, on my setups.
2. Trying to do so struck me as somewhat ambitious, and there are many ways in which an attempt can get stuck, due to minor logical errors between the scripts. The fact that I needed to execute

pasuspender /bin/true



at shutdown, to get PulseAudio truly working again, reminded me that unexpected logic glitches can come up, and that maybe I should not try to get JACK and PulseAudio working concurrently, part of the time. If this was a full-time setup, this option might actually make sense, but for temporary use – controlled with some scripts – this option seemed to make little sense to me.