One of the facts which I’ve been blogging about, is that I have erased Windows from a computer I had, which at the time was named ‘Mithral’, and that I had then installed Debian / Stretch on it, at which point I also changed its name to ‘Plato’. Debian / Stretch is the successor to Debian / Jessie, the latter of which I still have installed on two of my computers.
One of the main differences between the Debian / Stretch and the Debian / Jessie code-repositories is, that the newer Debian / Stretch is based on the desktop manager ‘Plasma 5′ – assuming we choose that desktop-manager – while Debian / Jessie was still based on ‘KDE 4′ as its desktop manager. And so one aspect of my ‘new’ Debian / Stretch system which I’ve been curious about – and anticipating – was how I’ll like Plasma 5 as opposed to KDE 4.
One of the facts which should be noted, is that although Plasma 5 has been altered enough to create major version issues with KDE 4 builds of applications, Plasma is not really that different, finally, from KDE 4.
The developers have focused on simplifying the experience. KDE 4 had almost unlimited options by which the user could fine-tune the appearance of his desktop, while Plasma 5 has reduced the number of settings. And yet I find, I can still do everything under Plasma 5, that I was used to doing under KDE 4. I do not necessarily need to be able to fine-tune, how translucent the Task-Bar is – which under Plasma 5 or KDE 4 specifically is named a ‘Panel’ – while its center-region, where entries exist for applications currently running in user-space, is actually named the ‘Task-Switcher‘. Linux people are sometimes particular about not wanting to seem to be copying the conventions of some other O/S.
Under Linux, we have a variety of methods, to display what processes are occupying the CPU, one of those being the command-line ‘top’, and another being the slightly-more-colorful, but still text-based command ‘htop’. We refer to htop as a ‘Process Viewer’.
One detail which went a bit far for me however, was the degree with which the default Theme – named ‘Breeze’ – made the icons and widgets seem uninteresting. From a package-manager, we can still install a throwback ‘Oxygen’ Theme, the appearance of which is more-similar to how KDE 4 looked. But if we choose the Oxygen Theme, then the default assumption would be that we want our desktop to have a dark look. I actually bypassed this result, by choosing my Look And Feel to be Oxygen, but by choosing my Desktop Theme to be ‘Air’, from the System Settings center. Air is what’s keeping the background-colors of most of my desktop bright-looking.
Also, I always took care to keep wallpapers which I had chosen, and not to allow any switch in Themes to replace those, since a bright-looking wallpaper is also necessary, for obtaining a Desktop Appearance which is bright-looking.
I suppose that one loss which I mourned at first, was that ‘Apper’ no longer works with Plasma 5. Instead we have a new suggested package-manager named ‘Discover’, which I do not like as much as I did Apper. But then, we can still use Synaptic as the GUI for our package-manager, which still works well, and which I actually use to pick and choose software to install.
Aside from that, re-installing capabilities which I already had on my KDE 4, Debian / Jessie -based computers, is often just a question of installing applications from the package-manager, the names of which have not changed, since the switch to Plasma 5.
One change which I also noticed, is that an application which I used to use, to preview images, was called ‘gwenview’, but no longer previews all the images which I need to preview. Specifically, I ran in to some TIFF-Images that the new gwenview could not display, and a possible reason could be the fact, that these TIFF-Images have an alpha-channel – although having an alpha-channel, did not prevent similar TIFF-Images from displaying in gwenview, under KDE 4. And so what I needed to do, was change the default program with which I preview images, to ‘ImageMagick’.
I discovered that changing such things as File Properties, and under that, File-Type Options, is as easy under Plasma 5 as it was under KDE 4. We can select whichever installed application we like, as our default for opening a File-Type – a feature which is still important enough, to be implemented fully.
I suppose that I should add another observation about the newer way of doing things. Under Debian / Jessie, the Session Manager was a time-proven piece of software named ‘kdm’. This is a program that runs with System / Root privileges when we boot the computer, which assumes the responsibility of launching the X-server, and which then led to a KDE 4 log-in, that benefits from being displayed in an X-window environment.
I believe that under Debian / Stretch, if we want to run Plasma 5, kdm is replaced with a similar program named ‘ssdm.’ From a purely practical standpoint, I’ve observed, that if we perform an accustomed log-out, followed by a log-in, ssdm no longer goes so far as to restart the X-server. The X-server just keeps running. Not only that, but doing this will also cause disconnected dbus-daemons to keep running, that were once associated with expired user-sessions.
This means that if we did a log-out, log-in, and then ran the following command from a terminal-window:
kde-mv somefile trash:/
Apparently, that file will still get moved to the trash correctly, but only after several error-messages are printed, which we would not get to see, if we were just moving the file to the trash, by pointing and clicking, from the GUI. Supposedly, similar error-messages will then also be spamming our syslog.
What this currently does, is make the maneuver useless to me, to log out and then log in again. I was kind of relying on this also restarting the X-server, and fully cleaning up what was left of the previous session, when I was doing this on my Debian / Jessie systems. And so on ‘Plato’, I need to replace a log-out, log-in maneuver, with an actual reboot, in general.
I regard this as a bug, because it may mess up a future ability to use ‘Plato’ as a Web-server.
Further, Debian / Stretch is not so old. It was only released on June 17 this year. This actually puts Debian Team behind, because various other Linux versions have come out, also sporting Plasma 5.
One of the consequences of this is, that Debian / Stretch has somehow been tied to Plasma 5.8 , even though Plasma 5.9 or Plasma 5.11 did come out, with specific features that Plasma 5.8 does not have:
Because Plasma 5.8 is the ‘long-term support’ sub-version of Plasma 5, and because Debian Team has decided that their priority for Stretch is to make it stable, what needs to be expected is that they will stick with Plasma 5.8 .
Now, I have never installed a blue-light-filter on any of my desktop managers specifically. If I did feel that these computer-monitors were causing insomnia, I’d need to take into account that supposedly, only brief exposures to that nasty, short-wavelength light are required, to re-awaken a person who’s supposed to be going to sleep, and to re-awaken his insomnia. I mean, less than a full minute of exposure can wake me back up, after which I am usually able to get to sleep anyway.
So I would need to do something about every source of blue light in my home, starting with all my monitors, but also including my smart-phone, since it, too, can give off blue light briefly. And so, I’d be looking at a cross-platform solution that installs and configures quickly.
And in that case, I can still find the package ‘redshift’ in my package-manager, to do so. I have not really tested that it still works, but would assume that it does. It does not depend on Plasma 5.
And there is an aspect about ‘Plato’, which I don’t feel 100% enthusiastic about. It happens to have a 1920×1080 computer-monitor, because that hardware never changed, and it responds to this resolution, by choosing a 48×48 font automatically, as well as to apply some unknown, high number of DPI for the font-sizes, that it might be reading from the monitor via the H/W connection.
This leaves me with less space on the desktop, to place large icons and widgets.
Now, just as it was with KDE 4, Plasma 5 allows us to micro-manage these things, if we have the ‘kscreen’ package installed, and so I could decide to make my fonts and icons smaller, or to change display-resolution to something other than what the system chose for me. But as it stands, I risk creating an effect that even looks worse than what I started with, which are settings presumably correct because read directly from hardware.
Also, an unexpected side-effect of having a high resolution in pixels, but large icons and widgets, is that this makes the screen-shots look slightly better, when viewed in this blog. Imagine trying to examine the windows above from an iPhone, because the reader just happened to be reading my blog on an iPhone, but with tiny features… The reader would certainly need to pinch-zoom a lot.
As it was with KDE 4, a basic way in which we customize our desktop, is first to right-click on the desktop, and to “Unlock Widgets” – in case they’re not already unlocked – and then to choose a Widget, which we can either Add To the Desktop, or which we can Add To any given Panel.
In the box used to select a widget, from which we drag it, each available widget has a number in its upper-left-hand corner, that indicates how many instances of the widget are already showing. Depending on whether we Drag it to a Panel or the Desktop, we get a slightly different result. And the (1) in the upper-right corner of the widget which is named “Task Manager” in the above screen-shot, denotes the fact that this widget has one instance, currently in the center of my one panel. I could choose to have a panel along the bottom of the screen, as well as another along the left-hand side…
There are two ways in which I find this to be better-managed under Plasma 5, than it was under KDE 4:
- There were always only these two basic ways, to build up our desktop. Only, under Plasma 5, the layout makes the choices more-obvious, whereas under KDE 4, I myself was more prone to look for additional ways, which did not exist.
- Under Plasma 5, if I delete a widget from either location, the number in the upper-left corner, of the selection box, gets updated reliably and immediately. Under KDE 4, the danger was very substantial, that this number would not get updated or removed, because in terms of code running in the background, the widgets would continue to be running, even though deleted, until we started a new user-session.
(Edit : )
A feature of Plasma 5, which has stayed the same as it was with KDE 4, is a possible “Folder View Widget”, that is only meant to be Added to the Desktop. Rather than to have the special user-folder ‘~/Desktop’ appear as the entire desktop, we’d typically create a special widget, that continuously displays a given folder, that folder usually being ‘~/Desktop’.
This way, we can actually reserve more space on the desktop itself for widgets, and for individual launchers which we may also drag there.
I had overlooked the fact that this widget has its own Icon-Size Settings, under Plasma 5. On ‘Plato’, the icon-size was set rather large, and it was a simple matter just to reduce the icon size there, not system-wide.
It would have been a huge mistake of me, to change the size of icons and/or fonts, system-wide.