So this topic made me really curious and I tried an up-to-date Plasma 5 installation again. Last time I did that was about three or four months ago, on 5.12 (on an OpenSuSE machine). I installed 5.13 on one of my home machines running Arch.

Here come a few (hopefully) useful notes.

What I had to change

1. My biggest pet peeve so far is the nasty, huge space between desktop icons, and between icons and their labels. It's been reduced lately (it used to be even huger). It can still be improved by hand-patching /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderView.qml and /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml . I don't know what computers KDE developers are using but I honestly don't understand how anyone can live with that huge space. I get why it's useful on tablets but I don't run KDE on a tablet.

2. There's a fairly interesting usability... thing, I'm not sure how to call it, where Alt-Tab has a delay (90ms by default, I believe) before it shows the window list. So if you press Alt-Tab quickly, it switches to the next window without showing the window list first.

If you use the default Plasma window switcher, which draws window thumbnails on the left side of the screen, this makes sense, I guess, because that thing is huge. If you use the icon list view, like I do (the old school alt-tab switcher we've known since, what, Windows 3.11? 95? I can't remember anymore), it looks slow and choppy.

Here is the incantation to change all that, you can thank me later:

You can edit kwinrc by hand, actually, but apparently kwriteconfig5 is the right way to do it today.

3. I had to change the compositor speed to "instantaneous". I love gratuitous animations like the lamp effect or the the desktop cube thing. Unfortunately, there seems to be no way to tell KWin "do alt-tab instantaneously but linger a bit on the desktop cube thing". Setting the compositor speed to a value where the desktop cube is nice to look at (or even, at the very least, noticeable) makes window switching unbearably slow.

Oh well, the cube wasn't properly anti-aliased anyway .

4. I use Plastik and a classic (it's actually called "Klassik") panel theme because a) I don't really like flat themes and, more importantly, b) Breeze wastes a lot of space. Again, I get why it's useful on tablets, but I'm on a real computer here . I think Breeze spacing can be tweaked via CSS, but due to a) I don't have a lot of motivation to try it.

4'. Oh yeah, since we're on the topic of themes: Smaragd has been ported to Kwin5. You want this.

5. I disabled Baloo and a lot of services that I don't use -- automounters, Bluetooth, whatever. As far as I can tell, except for Baloo, everything works fine, I just don't need it.

What I wish I could change

1. So, uh, remember when I said I don't know what systems KDE developers are running? This is how System Settings looks now:



This is vaguely reminiscent of the old NeXTStep column file manager, if anyone remembers it. Except it's huge and appropriate for tablets. Only for tablets. What the fsck?

The icon view is still there, but it's half useless because you can't resize the System Settings dialog below a certain (huge) size. The perfectly useful tree view is gone.

I'm really gonna love this when I get a tablet or shed 2000 USD on a touchscreen-enabled laptop that can be used for more than Facebook and showing off. In the meantime, I'm in old man yelling at cloud mode.

As far as I can tell, the fine folks at SuSE patch their systemsettings source so that it has less innuvashun and UX and more usefulness.

2. The Quartz decoration theme is gone. Man, that was my favourite since, like, forever . (OK, I knew about that one prior to trying Plasma 5 again today. I just wanted to whine a little more).

What I like

1. It's super snappy. On a seven year-old computer (admittedly it was pretty fast seven years ago) it moves very well. Way better than Gnome, in any case, and more or less on par with XFCE.

2. You can still get a desktop that doesn't look like someone shoved an iPad clone into your PC and plugged in a mouse and a keyboard. On the other hand, it's still customizable enough that it can actually work well on a touch-enabled laptop, too.

3. It's still very easy to tweak and customize. You do need to hack it a little in order to get e.g. screensavers running properly, but a) it's still possible, so that's great and b) I understand why this isn't the default choice in 2018. No biggie.

What doesn't work

1. KMail is still basically useless.

2. Hot corners are weird. Unless you're continuously pushing your mouse in the direction of the corner, it won't trigger, even though you get the visual feedback that indicates it's being triggered (i.e. the soft glow). This means that, if you use large timeouts, you're eventually gonna run out of desk space to drag your mouse on before you trigger the corner action. I don't really use that, to be honest -- I think it's neat but I'm too used to alt-tabing, but Gnome refugees probably like it more than I do.

What I think: this has finally reached the point where I think it's more hassle-free than the Openbox setup that I rigged together, so I think I'm gonna keep it . If it were the default DE in Slackware, I'd use it. It's definitely less hassle than downgrading to KDE4 would be. It's kindda more polished than LXQT, I guess (but not necessarily in ways that many people would notice. E.g. I'm very fond of the "classic" Kicker layout, with large launcher icons and two rows of taskbar buttons. lxqt-panel chokes on that setup), though definitely more heavyweight.

There are a bunch of things that tickle me the wrong way, but I think that's mostly because I'm nostalgic about KDE 3.5 and I keep trying to make it look and work like that, now that we finally have a KDE compilation that works properly . I wish all three tablets that can run KDE wouldn't get priority over, you know, virtually all hardware that can run KDE, but I guess that's just me lately. I can use it way better than anything GTK3-based.

2 members found this post helpful.

@adunr

I did not know that the delay of the window switcher appearing was a "feature". Very odd. The delay seems JUST long enough to be annoying and JUST short enough such that if I hit alt+tab quickly, I still almost always see the window switcher appear for a split second.

Anyway I hope it keeps up, but since deleting and having Baloo rebuild my index, and subsequently using alien's 5.13 ktown update, I've had nothing but amazing performance so far. I've never seen Plasma5 run quite this smoothly... Ever. Not on Kubuntu 18.04, not on ktown 5.12 since before my Baloo index crapped out. Fingers crossed...

1 members found this post helpful.

I suspected it was deliberate, because it was way too obvious -- it was the only slow thing when a bunch of other, far more complicated things happened instantaneously.

I sort of understand why it was introduced. It probably makes sense for a lot of people, I don't know. I'm just not used to it and it was hard to get used to it.

I've been on the lookout for Plastique and Clearlooks (the version native to KDE4, not the GTK version) widget themes for Plasma 5. Where did you get these?

You're right about that. So much of Plasma5 is very smooth. And I noticed today for the first time in a while, because everything was running so snappy, my workflow was smooth as silk and I was getting my work done more productively.

Again I don't know if this is a function of improvements in 5.13 or just baloo being fixed, but running ctrl+N on Dolphin to open a new window happens about twice as fast as it did before for me. Ctrl+t to open a new tab was already instantaneous, but I prefer opening new windows for drag and drop operations.

Also things like opening Chromium have sped up significantly. I'm thinking the performance enhancements the KDE Devs say have gone into 5.13 have paid off. But I have a habit of jumping the gun and speaking too soon, so we'll have to see how things work in the long run.

Anyway, although it seems counterintuitive to go with the newer 5.13 rather than the 5.12 LTS, it seems to have been the right decision, as per usual when it comes to Pat and Eric.

They're in qt5-styleplugins (see https://github.com/qt/qtstyleplugins ), but I'm not sure how long they'll be supported. IIRC, it was recently moved out of the Qt main tree. They still work fine on 5.11, in any case.

Edit:

You and me and other people who learned Linux (and Unix) before the whole DevOps thing and before super widespread access to broadband may not like this, but this is how software is developed nowadays. Especially in the FOSS world, and especially for large collections of programs like KDE, it's always going to be a mixture of (more or less) stable core components that nonetheless have beta-quality features, and applications of various levels of quality and "final-ness".

It may not be what we were used to fifteen years ago, but it's how it's done today. IMHO, sticking to an LTS release brings very little benefit. The "S" is often mistakenly taken to stand for "stability", but it only stands for "support" .

2 members found this post helpful.

I agree, the non-KDE environments should not be there. I just checked on my Slackware64-current and it is not in ~/.config/autostart. I also have not started KDE4 for that install either.


Maybe it is added when KDE is started? I will be playing with slacklive plasma tonight. I bet I will see the baloo desktop file in the autostart folder after KDE is started.

That would happen to me on new installs with 5.8, but rarely.

Look in /etc/xdg/autostart/

Not there. :-)

That install I have only started XFCE4 and have not rebooted for a week or more. Which I should but I have too much work open.

Yes, that's the containing directory of the .desktop file. That wasn't clear in my earlier post.

As I said, I've reported a bug upstream:

https://bugs.kde.org/show_bug.cgi?id=396940

Perhaps this is intended behaviour, for Baloo to keep running and indexing files even while XFCE (and in theory, GNOME and Unity) are running, but it seems very silly to me.

I'm not sure how active Baloo development is, though. I reported another bug to KInfoCenter that essentially amounted to a .desktop file getting amended, and it was fixed within the day:

https://bugs.kde.org/show_bug.cgi?id=396977

1 members found this post helpful.

I keep hearing people say this. Can you explain why? I am currently using KMail from KDE 4 as my main email client (which works fine for me), and I was hoping to do the same with the next version.

1 members found this post helpful.

I find disturbing to see you discussing about integration of whatever desktop environment in Slackware while testing it in Arch Linux and/or OpenSuSE.

With all respect, your tests have a questionable value for Slackware, because it differ hugely by OpenSuSE and Arch Linux starting even with its PID EINZ.

Believe or not, Slackware even does not use systemd.

IF you want to comment about Plasma5 on Slackware, please do a fresh install of slackware-current, then add the Eric Hameleers' Plasma5 build on top of it.

Because this one will eventually arrive in Slackware, and definitively not the uber-patched variants from OpenSuSE or Arch.

I can't care more less about how behave Plasma5 on OpenSuSE or Arch Linux. I am interested exclusively about how it behave in Slackware.

The latest KDE plasma 5 is working great for me on 64bit current
I use the nvidia 390.77 driver.
My machine is i7_7700. It is not new now but is still.quick.
i use multiple.monitors usually two or.three.
no issues with new.version

1 members found this post helpful.

Arch and Slackware differ in many regards, but how much they patch upstream code is not one of them. The Arch packages are about as uber-patched as Eric's.

Arch's PKGBUILDs are public if you're curious to count the patches yourself, but a full KDE installation has a lot of packages and you'll likely find that the patches/number of packages ratio wasn't worth the effort . E.g. here is the uber-patched systemsettings package that totally invalidates everything I've said about systemsettings above.

SuSE does patch KDE quite heavily. Now I can either happily ignore what they're doing and sit in my Slackware bubble, or I can peek and see what issues were considered important enough that someone actually sat down and started writing (or at least copy-pasting) code in order to fix them. Sometimes (not always, but sometimes) there's a pretty good correlation between the quality of upstream code (or the quality of upstream's technical and design decisions) and how much patching downstream needs to do. I'm also a fan of the "strictly vanilla" approach; how much patching other users do is sometimes a good indication of whether "strictly vanilla" works for a program in its current state.

As for systemd, I'm glad you dislike it too, but I'm not sure what feature/behaviour I described above you think depends on it.

3 members found this post helpful.