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