Using a fast and reliable, still not obsolete, desktop environment with Fluxbox

Something like 6 years ago, I already described desktop environment I used over years. I was, since then, decently satisfied by KDE/Plasma/however you name it. Mostly because kmail works properly with IMAPS and handle CardDav-cloud server out of the box, because Dolphin is the best file browser (immediate filter and group files and directories by day are the feature I enjoy most and none other file browser I know got right) and the rest (akregator, korganizer with CalDav) ok.

But systemd arrived. I was curious at first and encouraged, on this very blog, people to give it a try. But soon  enough I found out I was faring better without, reaching the conclusion that “Point is with systemd, I’m able to do less and it takes me more time”. I moved away from systemd and, then, as consequence, of Debian. And I found out that KDE was increasingly getting dependant on systemd, with bug reports about regression in their software being closed advising to use systemd.  It led me, in 2015, to ask on /. Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd? as follows:

Early this year, David Edmundson from KDE, concluded that “In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit“. A perfectly sensible explanation. But, then, one might wonder to which point KDE would remain usable without systemd?

Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the “Debian fork” I’m using to “ripe out” systemd without “coming with any of the supported solutions Plasma provides“. I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.

While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as “optional extra defeats its main benefit”. So, is it likely that we’ll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?

I replied once to comments in this article, for instance (not that l like to quote myself, but I’d rather avoid repeating myself):

Yeah and no. As pointed out in the article, the culprit is upower. But upower is mandatory for KDE power management. So it does not really matter whether it is Powerdevil that requires systemd or upower. ConsoleKit2 recently gained support? Was ConsoleKit2 actually been packaged? Does upower supporting ConsoleKit2 been packaged? If not, user experience wise, that is not palatable. And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd? Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not? If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative? Just as a reminder, ConsoleKit2 exists “because there isnâ(TM)t currently a standard for system actions like suspend/hibernate anymore. We use these features in Xfce and it would be nice to keep the session manager and power manager in sync (i.e. you inhibit something and the session manager doesnâ(TM)t see it). Obviously thereâ(TM)s systembsd in the works, so this is a stop gap until that matures (however long that may be). But Iâ(TM)ll happily continue to maintain and support ConsoleKit2 as long as someone finds it useful”. https://erickoegel.wordpress.c… [wordpress.com] The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won’t do. And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers. Hence the question: will KDE be still usable in 2016 without systemd.

Since then, I noticed a few other small issues which I did not bother to report: the answer would have been the same. So it is near one year later after my question asked on ./ and the answer is grim. More KDE parts got broken for me (sound, etc).

So I resorted to old answers, tested previously using desktop. I found Fluxbox to be the easiest to set up in a way that suits my needs.

Along with fluxbox, you need tint2 and xcompmgr, all properly packaged in Devuan. Then it is just a matter of editing files in ~/.fluxbox (after starting it once):

~/.fluxbox/startup :

#!/bin/sh
#
# fluxbox startup-script:
#
# Lines starting with a '#' are ignored.

# background image
fbsetbg ~/.fluxbox/backgrounds/selje.png &
# modern panel
tint2 &
# desktop transparency
xcompmgr -c &
# sysinfo panel
conky &
# required for dolphin to show up cleanly
export XDG_CURRENT_DESKTOP=kde
# desktop pager
fbpager -w &
# XMPP client
pidgin &
# cloud sync client
owncloud &
# gpg/ssh agents
eval "$(gpg-agent --daemon)" &
eval "$(ssh-agent)" &
# screen temperature
redshift &

[...]

~/.fluxbox/keys :

Control Mod1 A :Exec urxvtc
Control Mod1 I :Exec firefox
Control Mod1 M :Exec kmail
Control Mod1 E :Exec emacs
Control Mod1 D :Exec XDG_CURRENT_DESKTOP=kde dolphin

[...]

# if these don't work, use xev to find out your real keycodes
XF86AudioRaiseVolume :Exec amixer sset Master,0 2%+
XF86AudioLowerVolume :Exec amixer sset Master,0 2%-
XF86AudioMute :Exec amixer sset Master,0 toggle
#XF86AudioPlay
XF86AudioPrev :Exec /usr/local/bin/switch-sound
XF86AudioNext :Exec /usr/local/bin/switch-redshift

[...]

# sleep fluxbox CTRL-ALT pause
Control Mod1 127 :Exec sudo hibernate-ram

[...]

~/.fluxbox/init (just to set of fluxbox toolbar since we use tint2 instead) :

session.screen0.toolbar.visible: false

~/.conkyrc (need to be edited, for instance eth device names, etc):

conky.config = {
 alignment = 'bottom_left',
 background = yes,
 border_width = 1,
 cpu_avg_samples = 2,
 default_color = 'white',
 default_outline_color = 'white',
 default_shade_color = 'white',
 draw_borders = false,
 draw_graph_borders = true,
 draw_outline = false,
 draw_shades = false,
 double_buffer = yes,
 use_xft = true,
 font = 'Oxygen Mono:size=10',
 gap_x = 25,
 gap_y = 25,
 minimum_height = 5,
 minimum_width = 5,
 net_avg_samples = 2,
 no_buffers = true,
 out_to_console = false,
 out_to_stderr = false,
 extra_newline = false,
 own_window = true,
 own_window_class = 'Conky',
 own_window_type = 'override',
 own_window_colour = '#3d3d3d',
 stippled_borders = 0,
 update_interval = 2.5,
 uppercase = false,
 use_spacer = 'none',
 show_graph_scale = false,
 show_graph_range = false
}

conky.text = [[
# in red if sound off
${if_match "[on]" == "${exec amixer get Master | egrep -o '\[on\]' | tail -1}"}$
{color #4d4d4d}${else}${color Dark Salmon}${endif}
# assume left/right channels have same volume level
${execbar amixer get Master | egrep -o '[0-9]+%'| sed s/\%// | tail -1}
############
#${color #4d4d4d}$hr
${color grey}↑${color #4d4d4d}${upspeedgraph eth2 25,140} ${color grey}↓${color 
#4d4d4d}${downspeedgraph eth2 25,140}
###########
#${color #4d4d4d}$hr
#${color grey}CPU: ${color white}${i2c isa-0228 temp 2}°C$color - MB: ${color wh
ite}${i2c 9191-0290 temp 1}°C
###########
#${color #4d4d4d}$hr
${color grey}Name PID CPU% MEM%
${color lightgrey} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}
${color lightgrey} ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
${color lightgrey} ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
${color lightgrey} ${top name 4} ${top pid 4} ${top cpu 4} ${top mem 4}
${color lightgrey} ${top name 5} ${top pid 5} ${top cpu 5} ${top mem 5}
${color lightgrey} ${top name 6} ${top pid 6} ${top cpu 6} ${top mem 6}
${color lightgrey} ${top name 7} ${top pid 7} ${top cpu 7} ${top mem 7}
]]

shot.png

With this setup, the only thing I actually miss is a icon-tasklist.

Getting back suspend/resume with KDE 5’s powerdevil and no systemd by installing an obsolete version of upower

Using a package out of date since more 2 years ago does not sound like a success story but that is the only way so far I found to get suspend/resume to work without systemd within KDE5 without headaches. pm-suspend and pm-hibernate, on the command line, work perfectly though.

Why? Because Powerdevil, KDE’s power management tool, use upower which itself deprecated pm-utils support in favor of systemd.  So, no matter whether your hardware can actually suspend and hibernate, no matter if the kernel, GNU/Linux itself, can handle, upower won’t.

When calling upower -d, it should output something with can-suspend and can-hibernate. Since they dropped support for pm-utils, it won’t if you don’t use systemd . It’ll behave as if it knew what it was doing except it does not.

I filled a bug report and this one was discarded very fast. Martin Gräßlin immediately marked it as RESOLVED DOWNSTREAM with the comment “This works fine on Debian testing. Please get in contact with your distribution to figure out why this broke in your Debian fork. You might consider of course to install systemd”. You get the idea.  Thanks to Michael Palimaka, I got confirmation that it was tied to upower version (which I guessed beforehand because of several related messages by some Ubuntu or else users – hence the mention “with upower 0.99.3 and Devuan” in my report title) and he listed working solutions: using systemd; using ConsoleKit2; using upower <=0.9.23.

Using systemd to fix a problem caused by an attempt not to use systemd? Not an option. Using ConsoleKit2? Except I have no knowledge of ConsoleKit2 being packaged yet, neither do I know which release of upower actually got ConsoleKit2 support.

So I went for the third option, the lamest obviously, that is installing obsolete, unsupported software, and put in on hold. It can be done as follow:

echo "deb http://ftp.debian.org/debian wheezy main" > /etc/apt/sources.list.d/oldstable.list
apt-get update
apt-get -t wheezy install libgnutls26 libgcrypt11 libtasn1-3 libusbmuxd1 libimobiledevice2 upower libupower-glib libplist1
echo "upower hold" | dpkg --set-selections

Then a call to upower -d gives:

Daemon:
 daemon-version: 0.9.17
 can-suspend: no
 can-hibernate no
 on-battery: no
 on-low-battery: no
 lid-is-closed: no
 lid-is-present: no
 is-docked: no

It is better but still no good. As root it’ll work, though. You need to add some PolicyKit rule to allow regular users to use it. The following assumes that powerdev group exists and that your regular users are in this group (if they are not, add them with adduser thisuser powerdev):

echo "[Suspend power group override]
Identity=unix-group:powerdev
Action=org.freedesktop.upower.suspend
ResultAny=yes
ResultInactive=yes
ResultActive=yes

[Hibernate power group override]
Identity=unix-group:powerdev
Action=org.freedesktop.upower.hibernate
ResultAny=yes
ResultInactive=yes
ResultActive=yes" > /etc/polkit-1/localauthority/50-local.d/power-group.suspend-override.pkla

Now, if done properly, upower -d returns:

Daemon:
 daemon-version: 0.9.17
 can-suspend: yes
 can-hibernate yes
 on-battery: no
 on-low-battery: no
 lid-is-closed: no
 lid-is-present: no
 is-docked: no

Logout and login should be enough to have back suspend and hibernate within KDE5.

So this works. For now. But there is no doubt, this is wrong in so many ways. I wonder for how long it will be possible to run a modern desktop environment on GNU/Linux, and not on systemd/whatever.

 

Locking KDE (plasma) desktop

(Not talking about the whole desktop environment, just the desk, actually) You have plasmoids and a consistent layout. Nice. Then you have end-users, a bit clueless. And after a few month, their desktop is an absolute mess and they don’t even know why, it’s not even like they wanted to change anything to it. But you had set “lock plasmoids”. So you’re obviously locking for a way to remove the “unlock plasmoid” option.

You can do so following this advice:

you’ll have to add [$i] in the first (blank) line into the plasma-desktop-appletrc

Great! Except it looks like a dirty hack so I wonder if it will still work in the long run. I’d gladly take any further advice.

Package: amarok 2.4beta1 for Debian testing

Amarok is a nice music player for KDE. Inspired by iTunes interface, it features a clever random mode, provides Wikipedia/lyrics/photos pages for the currently played song, handles mtp devices and works with lastfm so you can have online stats of what you listen to and find people that listen to the same crap too. That’s definitely a nice software. But, unfortunately, it’s quite buggy.

This morning, Amarok would not start, no matter what. Well, it’s started once I erased .kde/share/config/amarok and .kde/share/apps/amarok. Then, shortly afterwards, it failed to start once more. I’m not quite frankly prepared to remove my Amarok config twice per day. So I decided I would just give a shot to a more recent version and the first beta for 2.4 around seemed a good pick.

Here’s amarok 2.4beta1 (2.3.90) packages for Debian testing amd64.

It was built with amarok Debian experimental directory (a new entry added in debian/changelog, usr/share/doc/kde/HTML/* removed from debian/amarok-common.install, usr/lib/strigi* removed from debian/amarok.install, usr/lib/kde4/*.so and usr/lib/*.so* added to debian/amarok.install, target override_dh_shlibdeps: added to debian/rules and all patches removed from debian/patches/series) and amarok official latest source package (renamed amarok_2.3.90.orig.tar.bz2) using the command dpkg-buildpackage -rfakeroot inside the amarok-2.3.90 directory (source tarball decompressed) containing also the debian directory.

Next Step towards GNUStep within KDE

Back in the days I started using GNU/Linux, the only user-friendly desktop environment available was KDE 1. So I started using KDE 1. Afterwards, considering license issue of Qt (that was no Libre Software at that time) KDE was depending on, considering progress being made by the GNOME project, I switched to GNOME 1.

Then, my brother Philippe advised me to give a try to WindowMaker. I did. At first, I was puzzled. But finally, I adopted this desktop environment inspired by NextStep. The main point is to kick the taskbar and the big start menu and, instead, going through apps with the right or middle click on the desk and having each important app to get a dock, which one could be used to launch the app or show the app if already launched.

Years afterwards, WindowMaker seemed to make no longer any progress and I wanted a modern desktop environment. Which means I wanted a desktop environment in which every piece of software is neatly integrated, where configuring new features is easy – while toying with both WPrefs and wmakerconf was not. And Qt was freed. So I get back to KDE. GNOME was longer an option, as I do not trust GNOME leaders like Miguel De Icaza to make the right decisions (the Nautilus and Eazel story was revealing enough for me: trying to behave corporatish, they chose the worse software to be the GNOME file manager, but they did while it wasn’t even coded, they only trusted a newly founded company made by people with no experience in Libre Software to do the right and good thing) and it was no surprise to me when HelixCode/Ximian/whatever-crap-it-is-renamed started to sell proprietary software under the denomination commercial software after implementing .NET, I expected nothing more from people talking about Open Source mumbo-jumbo ESR style, instead of Free Sofware, while they were getting popular just because of their involvment in a GNU project. KDE is powerful, rock-solid. But it is also über-conventional. They know what is working good in MS Windows, they clone it, improve it and release it. Moreover, KDE tries to address a broad audience, so KDE is made to seem familiar even to people having no clue about GNU/Linux. Moving back to KDE meant loosing the interesting design of WindowMaker.

Then, I had the opportunity to look at an Apple Macbook Pro. The dock, for good reasons, reminded me of WindowMaker. And finally, I found Daisy. It is a clone of Mac OS X dock, it works like the WindowMaker dock. But it is a plasmoid for KDE. It’s only just clumsier to set up (no easy drag and drop), prone to bugs (sometimes, a click on the dock app launcher start two instance). But it works. And I trashed once more the taskbar I definitely do not like.

KDE with Daisy, WindowMaker/Mac Os X style!

There is no Debian package, so I went to Ubuntu plasma-widget-daisy page. There, I downloaded the source tarball and the debian part (which contains the debian folder necessary to built the package). I extracted them all in a temporary directory. Then:

1/ I edited the debian/changelog file to add a new entry.

2/ I edited “Build-Depends:” in the debian/control file to depends on the pkg-kde-tools version that comes with my system (Debian unstable).

3/ I installed necessary dependancies to build the package – as the package was not in debian trunk, I made the guess that it had the same deps than the similar package plasma-widget-ktorrent:

# apt-get build-dep plasma-widget-ktorrent

4/ I rebuilt it:

$ dpkg-buildpackage -r fakeroot plasma-widget-daisy

5/ Then I installed the package.

You can fetch my plasma-widget-daisy_0.0.4.22a-0ubuntu2-fordebian1_amd64.deb package built against debian sid (unstable) for an amd64 architecture.

I also posted a RFP (request for packaging) against wnpp in debian BTS (bug tracking system).

Superkaramba vs gkrellm

I’ve been using gkrellm since several years – with WindowMaker, KDE, whatever desktop environment. Considering old venerable it is, clearly, gkrellm does not really fit with nowadays eye-candy. So its tempting to give whatever may be available a try.

As I run KDE, Superkaramba it must be.

Well, I tried it a year ago already: it was full of transparencies effects, composite-whatever-2.0, but it was also clumsy, bloated, and definitely prone to segfault.

I gave it another try today.

Well, I took some time to browse KDE apps for nice Superkaramba widget. Not easy to pick, I must say.

I went for EasyMonitor, mainly because it is modular and easy to tune.

So far, no segfault. And it does not seems to consume too much CPU resources – that always the issue to keep in mind, the damn thing is supposed to help checking resources usage, not to burn half of them.gkrellm and superkaramba (with EasyMonitor)

Finally, I customized several files to fit my expectations and limit resources consumption. Here they are: EasyMonitor_Filesystem.theme, EasyMonitor_Memory.theme, EasyMonitor_Network_Interface_eth0.theme, EasyMonitor_Procesor_multi.theme, EasyMonitor_Top.theme. All these files should be put where EasyMonitor is installed, ~/.kde/share/apps/superkaramba/themes/ in my case.