interesting comment from a poster on phoronix

Duncan 1i5t5.duncan at cox.net
Fri Aug 21 09:50:15 BST 2015


Hussam Al-Tayeb posted on Thu, 20 Aug 2015 21:27:07 +0300 as excerpted:

> On Thu, 2015-08-20 at 13:10 -0500, J. Leslie Turriff wrote:
>> On Thursday 20 August 2015 11:44:32 John Layt wrote:
>> > On 20 August 2015 at 16:15, J. Leslie Turriff <jlturriff at mail.com>
>> > wrote:
>> > >         Another of the many good reasons to stay on KDE3.
>> > 
>> > Now that is just trolling :-)
>> > 
>> 	True.  I'm still really unhappy about the KDE4 upgrade fiasco
>> and the lost functionality that still plagues KDE beyond KDE3.
> 
> what functionality did KDE4 miss?

Among other things...

1) Multi-key khotkey support -- the key[1] to multiplexing a single 
"extra" keyboard key as a custom launcher, allowing launch of a user's 
most-used apps with 2-3 keys in sequence, without having to go thru the 
kmenu or krunner and without having to use up more than one "extra" key 
as they tend to be in short supply.  It also solves the problem of "OK, 
was it win-ctl-shift-p to launch kpat, or did that launch palapeli and 
it's win-ctl-alt-p that launches kpat?"  Similarly, it solves the "emacs 
hand contortions" required to hit all those keys at once, since the keys 
are hit one or occasionally two at a time in sequence, instead.

In kde3, it worked. I could hit <launch>, g, p, for instance, to "launch, 
games, kpat", <launch>, c, to "launch, console" (konsole in this case), 
or <launch>, f, to "launch, filemanager" (then konqueror in filemanager 
mode, would be dolphin in kde4).

What I ended up doing to replace that missing functionality was a rather 
complex set of manually maintained bash scripts (bash being what I know), 
key-to-launched-app config files, kwin window rules[2] and a single 
khotkey configured launcher key.  It works, but being in bash it's not as 
speedy as it would be if the support was still in khotkeys.  And it was a 
rather complicated script to have to write and debug, for functionality 
that worked just fine in kde3, but remains broken in kde4.

I'm just glad I know bash scripting.  If I didn't, I would have been SOL.

2) I know someone that still uses kde3 for kworldclock.  I believe 
there's a plasmoid similar to kworldwatch, the kicker applet, but there's 
no kworldclock, the stand-alone app.

3) AFAIK, there's still no replacement plasmoid for the ksysguard kicker 
applet.  There's a lot of specific function monitor plasmoids, but 
nothing that lets me configure monitoring for any sensor available in 
ksysguard, in my choice of multimeter/bar-graph/line-graph, allowing 
multiple sensors per graph, etc, like ksysguard.

There /is/ a plasmoid called yasp-scripted (yet another system-monitor 
plasmoid, scripted) available from kdelook, that I originally setup when 
I was trying to switch from kde3, but while rather more flexible than the 
ksysguard kicker applet, it requires a LOT more configuration, most of 
which is done by manually editing a config file.  Also, unlike the 
ksysguard kicker applet, it's not shipped with kde by default.

Later I switched to superkaramba, a bit more complex than yasp-scripted 
to configure, but also a bit more powerful.  And it /does/ ship with kde4.

But neither of these is full-GUI configured, like ksysguard and its kde3 
kicker applet, so they're not replacements.

Additionally, ksysguard for kde4 had a number of bugs that broke graphing 
in some cases, back in the kde 4.2/4.3 era when I was trying to switch.  
I don't remember the details, but IIRC one of them was something like a 
0-100 graph (as commonly used for CPU usage, for instance) not being 
settable, it'd either cut off at 80, which couldn't display the top 20%, 
or 120, which would waste space and make 100% not appear to be full 
usage.  IIRC there was a second bug similar to that as well, but I don't 
remember anything about it other than there were two bugs that for me 
made it unusable.   I'm not actually sure if they ever got fixed, as it 
wasn't properly usable at the time so I had to find/create actually 
usable alternative solutions.

Of course that's not even counting all the bits of kde4 that were still 
very *VERY* broken in the kde 4.2 time frame when kde declared it ready 
for ordinary users and kde devs refused to support the actually still 
working kde3 any longer, *AFTER A VERY PUBLIC PLEDGE TO CONTINUE 
SUPPORTING KDE3 AS LONG AS THERE WERE USERS!!!*[3]

It's also not counting the things, like a mail client that actually 
worked without losing messages, that actually broke in the middle of the 
kde4 cycle.

And the semantic-desktop thing... but that's below.

> Things improved heavily throughout KDE4 lifecycle especially after the
> switch to baloo.
> I found KDE4 by 4.14.xx (with the patched akonadi) to be as perfect as a
> desktop can be (It ranked up there with XPSP3). I used to have weeks of
> uptime without memory increases or crashes or anything. The system
> resources footprint was minimal too.

While I've been building kde (gentoo) with USE=-semantic-desktop since 
shortly after kmail jumped the akonadi shark and broke (forcing my switch 
to claws-mail, after the nearly a decade of "just works" that I used 
kmail, since I switched to Linux and kmail from MS Windows and OE in the 
kde2 era), users are still complaining about baloo's indexing hogging IO 
(particularly on spinning rust) and bringing the system to its knees, 
making it nearly unusable until baloo has finished doing its thing.  See 
the "baloo_file_extractor - huge disk usage" thread from only a week ago 
(OP Mark Knecht, on the 13th) on the kde-linux list.  Someone posted this 
list of bugs on the topic:

https://bugs.kde.org/show_bug.cgi?id=349096
https://bugs.kde.org/show_bug.cgi?id=233471
https://bugs.kde.org/show_bug.cgi?id=333655
https://bugs.kde.org/show_bug.cgi?id=332317
https://bugs.kde.org/show_bug.cgi?id=333774


Unfortunately, while as I said I build with semantic-desktop disabled, 
that breaks a bunch more stuff that worked just fine in kde3 -- without 
semantic-desktop, obviously.  Luckily, it's not critical stuff, but it's 
useful stuff, like the exif data on jpeg files (data like the camera 
used, exposure settings, date and coordinate grid, etc) and the id3tag 
stuff on mp3s (artist/album/year/etc).  In kde3, that additional metadata 
was generally available as long as the appropriate kioslaves, etc, were 
installed.  In kde4, it's all semantic-desktop-indexing based, and if 
that's off or even disabled at build time due to the resource hog that 
semantic-desktop tends to be, that metadata's missing as well.  But it's 
a small price to pay to be rid of that indexing that steals IO and CPU 
resources as well as gigabytes of storage space, with little positive to 
balance it out, at least for people who tend to organize things in 
logical directory trees where they can actually find them again in the 
first place, instead of dumping everything on the desktop or who knows 
where and not being able to find it without an indexer of some sort, that 
"everything in a heap" use-case apparently being the one semantic-desktop 
is designed to help.

---
[1] Originally unintentional wordplay. =:^)

[2] OK, the window rules have a GUI dialog to set them, but I still have 
to actually do so; kde3's multi-key hotkey setup didn't take any window 
rules to work.

[3] Aaron S, president of KDE's legal entity, the name of which I've 
forgotten, at the time, pledged kde3 would be supported as long as there 
were users, saying that's how open source works.  While I suppose he may 
have had the best of intentions, he couldn't support it all by himself, 
and he obviously didn't get buy-in from all the other kde folks that he 
would have had to have on-board to be able to make that pledge with any 
hope of actually sticking to it.  Unfortunately, many users, including 
me, actually took him at his word, making the already painful dropping of 
kde3 support well before kde4 replacements were actually working 
properly, even more so.  Had he actually told the truth about support 
instead of promising something he couldn't deliver, at least people would 
have known a bit earlier and would have had time to make an orderly 
switch to something else, if kde folks wouldn't actually support the last 
working version until a replacement working equally well was available.
-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list