LXDE and Plasma 5 .desktop -Files don’t meet the same requirements.

I’ve just switched a Linux computer of mine from the LXDE to the Plasma 5 desktop managers, because Plasma 5, the successor to KDE 4, is infinitely more-powerful. But then there were some issues with the transition, that may be relevant to my readers, if the readers also wish to switch desktop-managers, on an installed Linux computer.

One fact which I learned, was that even though LXDE and Plasma 5 both use .desktop -Files to launch applications, each system’s .desktop Files are different.

There is a directory named:


In which we find .desktop -Files that are to be run when the user first logs in. And we may find that the initial log-ins don’t run those files:


Also, because the configuration in question is just a set of files, trying to click on these entries  in the Plasma 5 settings center does not enable them.

One main reason for which this happens, is the fact that the professional who set up these configuration files, gave the original ones a line that goes like this:


On my system, this fact was a life-saver, because the LXDE version initially had Compiz installed, which is a fun compositor, but which is not compatible with KDE or Plasma 5. If that had launched, it would have messed up my first attempt to establish a Plasma 5 session.

But there exist other applications which I’d want to have run, even if I’m logging in to Plasma 5, for which reason I used the GUI, to create a Plasma 5 -compatible launcher for the script that updates my version of Flash to the latest version:


And I edited-in a line with a text-editor, which now goes:


The exact appearance of the icons here is purely coincidental. But if we wanted to transfer such scripts to:


Then a big problem for a user like me would be, that scripts which we created in our own home-folders, are likely to contain configuration-details, which will only work for the one user who created them. And so I kept this .desktop -File spartan, to make sure that it will work, regardless of whose home-folder it eventually ends up in.



Freshly switched to KDE 4 or Plasma 5, and unable to Browse Network Shares using Dolphin?

I just installed Plasma 5 from the package-manager, on my tower-computer named ‘Plato’, only to find that for some time, I was unable to browse Windows File Shares – i.e. ‘SMB Shares’ – casually, just using the ‘Dolphin’ File Manager. Yet, I was able to mount these shares using ‘Smb4K’, making them visible in my local folders as though there.

Dolphin was showing me an essentially empty set of icons when displaying the Network.

As it turns out, we need to install a package named:


Which will give Dolphin the additional plug-ins it needs, to recognize ‘smb://’ URIs. If our Plasma 5 desktop manager was set up professionally, then the person doing so would know about such details. But when individuals set up KDE or Plasma for the first time, we need to learn such details first-hand.




As an added note, we might find that when we click on the Trash widget in our Panel, which I left just at the right-most end, we may get the error-message to the effect that ‘trash:/’ was a corrupted URL. Yet, from within Dolphin, the trash bin displays just fine.

In my case this was happening, because I did not have Dolphin set up as my default File Management application, in my Plasma 5 Settings, where instead I had an application selected which would have been appropriate to an LXDE desktop, and which does not recognize URIs that begin with ‘trash:/’. Switching this setting to make Dolphin my Default File Manager, fixed this problem.



Distinguishing between Different Battery-Types

One of the things I recently did, was to pair my Linux-laptop, which I name ‘Klystron’, with an external Bluetooth-Mouse, because even though this advanced, HP laptop has as its hardware, an advanced Synaptics touchpad, that emulates a mouse quite well, we can grow tired of always using the built-in touchpad. I documented here, what I needed to do, to accomplish this pairing.

Well one of the features which the KDE Desktop Manager gives us under Linux, is to indicate the battery-charge-levels, not only of the laptop’s built-in battery, but also those of attached BT-mice, or of anything else which is connected, that has a battery, and the hardware of which is able to report as telemetry, the battery-level.

What was surprising me about this arrangement, was that the indicated battery-level of the mouse seemed to track accurately over the days, that the mouse was connected. This surprised me, because as I was remembering events, I had placed Nickel-Metal-Hydride batteries into the mouse some time ago, and most devices which are physically designed to accept batteries in the AA-format, or in the AAA-battery-format, would be calibrated for Alkaline, Zinc-Manganese-Oxide batteries. When such accessories try to gauge the battery-level, if they have the chip to do so, the voltage-curve of a Ni-MH battery tends to remain lower than that of an Alkaline. A fully-charged Ni-MH only generates about 1.2V per cell, while an Alkaline generates 1.5V. And so when a Ni-MH battery is inserted, this chip will usually indicate a partially-discharged battery, even immediately after it has been charged, and then, when this battery-type finally goes dead, its voltage will collapse almost instantly.

Before the indicated charge-level dropped below ‘70%’, I decided to take the AA-format batteries out, and to put them into a charger I have, that’s designed for Ni-MH batteries, and what I found was, that the LEDs in the charger refused to light up, for the inserted batteries. They did not indicate partially-charged or anything, they just stayed ‘off’.

And so next, my thinking was, ‘Darned! I now have either batteries which have failed on me, or worse – a charger which has failed on me 100%…’

Continue reading Distinguishing between Different Battery-Types

Editing the KDE-4 K-Menu

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.