Post by Esben Mose HansenPost by DaleIt's mostly missing features for me. I went into KDE 4 the other day
after some updates and while playing around I still find some things
that are grayed out[.] I google around and read mailing lists and I
know the things are coming and after updates I can see things getting
better. It's just not there yet. I can't recall the specific things
without logging into KDE 4 a digging around a while.
just one example would really help getting a handle on the issue :)
I'm not him, but we do seem to have the same opinions and general
experience, even if it might not be the same individual issues, and I
muscled thru them, scripting my own solutions to fix the broken kde
functionality where necessary, to fix the issues I had to and get kde4
running reasonably well now for me -- but only with hours and hours of
work, my own scripts, etc.
Here's a little list of my problems, since you want some examples:
1) khotkeys global multi-key is broken and unlikely to be fixed in the
near future. There's a big bug about it with lots of votes, but the
problem is apparently the non-kde libraries (presumably qt4, tho that
wasn't stated specifically) that khotkeys uses, that simply don't have
the necessary functionality to implement it correctly.
By "global multi-key", I mean stuff like using the "extra" keys on
Internet/Multimedia keyboards as hotkey menu-launchers, *NOT* modifier
keys stuff like Ctrl-Alt-Win-Shift-X. In kde3, I came to rely on this
/very/ heavily, hitting "Launch,F"[1] to open my filemanager (konqueror
back then, dolphin now), "Launch,E" to launch my text-editor (kwrite),
"Launch,M" to launch my mail client (kmail), etc. I had well over 20
defined, and used them to launch likely well over 90% of my program
launches, bypassing the kmenu or quicklaunch bars, so not having that
working in kde4 was a serious blocker to switching, for me. Multiple non-
modifier launcher keys worked in kde3, they don't and likely won't for
quite some time in kde4. Since I needed well more individual launchers
than I had extra keys, the single-key method that kde provides just
wasn't going to work, and while modifier keys might have, keeping them
all straight, especially when some combinations are in use by apps
already, is a nearly impossible task, so that wouldn't have worked in
practice either.
The solution here was a script and matching config I hacked up. I now
have a single kde hotkey configured, attaching my launcher script to the
target launcher key. That script in turn launches another one, using a
special konsole profile, with a special kwin application profile attached
to it as well, so it opens always-on-top, centered, at a specific size,
with focus stealing disabled so it always gets focus, etc. The second
script reads a config file that lists (single, with modifier) hotkey,
command, description trios, one per line, then issues a read command that
waits for exactly ONE key to be pressed. When that key is pressed, it
compares it to the hotkey entries in the config file, and if one matches,
it launches that entry. The script then does the usual disown and sleep
just briefly dance, so the SIGHUP at close won't shutdown the app it just
launched, and then closes.
The effect is a two-key (with modifiers if desired) hotkey launcher, tho
it's implemented as two separate single-key triggers, the initial kde
based single-key Launch (aka XF86_WWW) trigger, which launches the
script, which in turn waits for the second key, launching the app or
otherwise performing the action configured for that second trigger key.
2) "The application formerly known as ksysguard" (tafka-ksysguard, aka
system monitor in kde4, tho that's troublesome as it's way too generic
and there's very possibly dozens of plasmoids and etc that are referred
to as system monitor as well -- system monitor covers the whole
category!) has MULTIPLE bugs that make it practically unusable for any
serious system monitoring, and there's no replacement plasmoid at all for
kde3's ksysguard kicker applet.
Among the bugs, tafka-ksysguard (a) won't retain manual range settings,
insisting on setting its own at every start, thus forcing the user to
jump thru hoops repeatedly to adjust them -- automation of such repeated
actions is what computers are supposed to HELP with, not GENERATE the
need for even more rote repeated actions. The settings do get saved, but
tafka-ksysguard ignores them when it reads them back in, in favor of its
own idea of what they should be despite the fact that the user went to
the trouble of unchecking auto and set them manually, previously.
Unfortunately, that means that if the config file isn't set read-only and
the user forgets to re-range a plotter, the bad automatic value will get
stored at shutdown and read back in at the next start. Not that it
really matters since tafka-ksysguard doesn't obey it anyway, but...
(b) tafka-ksysguard won't let you configure your own worksheet as the
default worksheet started at launch. (IIRC, ksysguard didn't either tho
I'm not sure on that, but in any case the ksysguard kicker applet used
its own separate config, which the user could setup as desired, and
wonder of wonders, the thing actually /obeyed/ the user configuration!)
While I was still using it, I had to rename the hard-coded tasklist
sheet, replacing it with my own sheet of plotters, so I'd get the plotter
sheet displayed at each launch and could thus monitor my system.
(c) tafka-ksysguard won't even obey the user's ranges when they do
uncheck auto and configure them. It chooses its own numbers generally
/close/ to the ranges the user set, but not /that/ close. One of my
graphs is the speeds of several system fans, ranging from 1220 or so to
3000 or so RPM. tafka-ksysguard would not take 1200 as a minimum,
insisting on either 1000 or 1500. Naturally the plotter dropped off the
bottom of the 1500 plot, and the additional 200 RPMs never used at the
bottom of the 1000 minimum plotter means the lines are actually far
smoother and display far less change than they should. The same thing
happened with other plotters as well.
(d) Possibly due to the same root issue, tafka-ksysguard in auto mode
defaults to a 1.0 max when there's zero or very low activity (fine so
far, but...), but when the value goes above one, the plotter won't change
the (automatic) max until it hits 2.0. Thus, the plot is off the graph
between the ranges of 1.0 and 2.0, until it reaches 2.0, at which point
the plotter starts auto-ranging as it should. The place this was most
noticed was on my load average graphs. Normal system load-average is
well under 1.0, typically 0.05 to 0.3 on my system. When I started a
multi-job compile or something else that increased load average, I was
flying blind as it headed over 1.0, until it hit 2.0 at which point
things worked as they should.
(e) The base plotter widgets that tafka-ksysguard and other apps, at
least certain plasmoids such as yasp-scripted, use, have a plot-maximum
bug when the maximum is in the range of 90-120. With the maximum in that
range, they always plot the maximum as if it's 120. This royally sucks
for percentage plots with a 100 maximum such as CPU load (user/system/
nice/wait/total), since again, the active plot area is significantly
lower than the space actually taken up by the graph. 100/120=5/6, or
83.33...%, so > 16 percent of the plot area is entirely useless, because
100's the fixed top value.
I should mention one that has actually been fixed, as well. In kde
4.2.4, which is where I really got serious about switching, the network
stats were broken -- in fact, it couldn't even see my Ethernet connection
at all! I don't know but /suspect/ that it was relying on the
"automagic" of network-manager for its information, as if /nobody/ in
the /world/ ever configured their stationary desktops and servers with
wired Ethernet connections as a system service started at boot!
Fortunately, that one was fixed for 4.3.0 or 4.3.1, IDR which.
Clearly, tafka-ksysguard is /not/ yet ready for regular use in any role
in which people are actually relying on it to plot their system vitals.
Again, as I regularly rely on having such information available to me,
this was a major blocker for my upgrade to kde4. Fortunately, the yasp-
scripted plasmoid from kde-look was a reasonable workaround for most of
the problem. As mentioned above, tho, it uses the same base plotter
widgets tafka-ksysguard uses, and as such, suffers from at least the
90=120 bug, and I think the 1200=1000 bug as well, tho I believe to a
lessor degree as it's not as evident, at least with the values I'm
using. If you check the site, the big 8-plasmoid-in-a-row screenshot is
mine, and the scripts are now shipped with yasp-scripted. =:^) But it
took me hours to come up with them and even more hours to get them
looking right, for something that "just worked" on kde3, and /should/
"just work" on kde4, if it's claimed by word and action to be ready for
kde3's users, as it is.
There were some others as well. Some of them were config issues, but not
well defaulted and not properly documented, and sufficiently obscure, I
know several ordinary users that have abandoned kde4 as a result, when I
expect a few simple config changes might have made all the difference in
the world for them.
3) One of these is the composite video setting. For people with older
video -- and kwin already measures performance and disables composite
entirely when it thinks it's too low, so it certainly has the tools to do
it -- for these people, rather than disabling composite entirely, having
it set effect delay to "immediate" would likely SERIOUSLY improve things
as it did for me, without the drastic step of disabling very useful and
popular features of kde such as the desktop grid and present-windows
effects, as happens when compositing is disabled entirely.
4) While on video settings, with kde 4.3.2 and previous, I can't use the
display settings at all. I have dual monitors setup with xrander.
Actually, kde3's display setting didn't work very well either, but at
least they didn't screw things up just by opening the tafka-kcontrol
display applet, not even changing anything, as I believe it was 4.3.0 did
here. (4.2.4 only screwed it up when I tried to change something, 4.3.0
screwed it up opening the applet at all, 4.3.1 I believe it was returned
it to only screwing it up when I changed something, again.) Apparently
that too is a known issue, with a fix supposed to be in for 4.4, among
other very useful fixes I've seen mentioned as already in for 4.4.
5) Still on video settings, but this one's more a usability issue than a
functionality bug. When OpenGL rendering is disabled, the effects that
require them should be disabled in the config, so it's easy to see what
choices one has that actually /do/ something, as well. As it is,
something like 2/3 of the effects don't work here, because my card's max
OpenGL is bounded at 2048x2048 px, and I'm running dual 1920x1200
monitors stacked for 1920x2400. While OpenGL still works on the upper
2048 px, it won't work on the bottom 2049-2400 band, so KDE disables it
by default (it got that right, but took until 4.2 to do it 4.0 and 4.1
would simply crash the entire system!), yet there's no indication which
effects will actually do something and which won't do anything, because I
don't have OpenGL. That needs fixed on very basic general usability
principles -- if an option does nothing in a particular mode, disable it
so the user won't be trying it and getting nothing! That basic has been
a UI given since at least 1995, yet KDE still has it wrong in this spot,
at least.
Another one that has already been fixed... Qt has a painter bug that kde
was triggering in a number of apps, whereby if an object is deleted
before being specifically removed from its canvas, it triggers a repaint
of the entire canvas, where it /should/ only trigger a repaint of the
area the object covered. The most visible case of this was in plasma
itself, since it /is/ the kde4 desktop. The effect on slower graphics
cards (decent ones evidently recognized the larger than necessary repaint
and accelerated it away) was that any desktop plasmoids, /particularly/
dynamic ones like the CPU temp and CPU activity "System Monitors" (that
are NOT "System Monitor", aka tafka-ksysguard), seriously hobbled
performance any time composite was enabled, particularly when multiple
windows covered the plasmoid in question, thus forcing the constant
updates at multiple composite layers. Of course, with composite off, the
problem disappeared, as the windows would be opaque and the updates going
on behind them didn't matter. But some of us knew that composite in kde3
worked at a particular level of performance, and refused to give up
transparency and all those nice desktop grid and similar effects, just
because kde4 was such a performance dog compositing the same basic stuff
kde3 handled with hardly any slowdown at all. This too I'm sure caused a
lot of folks to giveup on kde4 thru 4.3.0 (the fix was in 4.3.1, IIRC),
particularly when combined with the effect delay config bug above.
I was fortunate enough to be running Gentoo, which has both kde3 and kde4
able to run without interfering with each other, and apps from one able
to run without overwriting the settings of the apps from the other.
Thus, when it became obvious that there was so much wrong with kde 4.2.4
that I really couldn't get anywhere booting to it directly, I started
switching individual kde apps to kde4, one at a time, uninstalling the
kde3 version of the app so the kde4 version would be invoked when I
invoked the app from inside kde3, configuring it to my liking, and then
moving onto the next one. After I did the basic apps (konqueror, kmail,
konsole, mainly), I killed kwin (3) and started kwin4, and worked on it.
Thus I noticed how much slower the system was immediately after switching
to kwin4, and was able to detect, search for until found, and finally
adjust, the effect delay setting I mentioned above, quite apart from the
plasma issue just above that's now fixed. Once I found and properly
configured that, I had a responsive kwin4, and after configuring other
things (like the color prefs), I was ready to move on. Only now, about
the only thing left from kde4 that I wasn't already running was the
plasma desktop itself. So I rebooted to the kde4 desktop proper, and
AGAIN noticed a huge slowdown -- I had cpu temp and activity plasmoids
already setup on my desktop from trying things out versions earlier, when
the panels weren't properly functional, and they were hoovering my
performance big time! Well, since I already knew kwin wasn't at issue,
and I'd already tested pretty much everything else, the only thing left
that could be doing it was plasma, so I worked on it until I figured out
that dynamic desktop plasmoids hoovered performance like crazy!
The point being, had I not splitup the config into individual apps like
that, I'd have continued to get pretty much nowhere, because the plasma
suckage was masking kwin's bad config, and kwin's bad config was
preventing my discovery of the problem with dynamic desktop plasmoids.
Splitting up the config like that in ordered to solve the problems is NOT
something a normal user's willing to do... or even knows HOW to do, or
CAN do, if his distribution isn't setup to allow kde4 apps to run on kde3
without screwing up the config for both, as can easily happen if the
distribution hasn't taken pains to prevent it. Yet that was 4.2.4, and
4.2 was claimed by KDE on their website to be ready for ordinary users.
No WONDER so many are having such serious problems that they're running
FAR FAR away from kde4, and may never try it again, thinking it's as much
of a dog as the current issues lead them to believe, especially after
reading all those claims about how it's ready for ordinary use!
Now of course all these sorts of bugs are perfectly fine, just the usual
things one deals with in the course of running prerelease software... for
alpha software that *IS* actually prerelease, or that isn't claimed to be
ready for normal usage yet. Unfortunately, that's NOT the claim KDE made
with 4.2, which was according to the kde web page appropriate for normal
users. This is broken stuff, known-broken. Much of it doesn't work for
/anyone/ trying it. It's not simply some obscure corner-case configs,
it's /anyone/ trying to work with the apps in question. That's the
problem. The things are broken, they KNOW they're broken, the bugs are
filed, in many cases they have hundreds of votes, yet KDE's claiming
kde4's appropriate for normal use even in this known-broken state! And I
didn't even mention the problems konqueror has had with SSL yet -- the
SAME SSL that "ordinary users" relying on the claims on the KDE site will
be ATTEMPTING to use to connect to their BANKS, etc. IOW, bugs that
could well cost REAL USERS REAL MONEY if someone intercepts their
connection due to kde's KNOWN bugs on versions shipped as usable for
ordinary people.
What's worse, they're refusing to provide basic maintenance level updates
to kde3, to keep it working with current libraries and toolchains.
Nobody's expecting further development, but at least ensuring it
continues to compile and function properly with current fully updated
systems until a good portion of these known-broken bits of kde4 are fixed
so it actually works to the level kde3 did, is pretty basic in the keep-
your-users-happy department, especially when such support was promised,
"as long as kde3 has users", by someone no less prominent than Aaron
Segio, President of KDE's legal entity at the time and thus the person
empowered to speak "in the name of KDE", which is what he did. Thus,
given the actual actions we've seen as opposed to the words, it's
certainly a very good thing few distributions actually /believed/ him.
Imagine the headaches Kubuntu would have been going thru now had they
shipped the then-current 3.5 as their 3-year LTS version! They took a
LOT of heat for refusing to do it, but given the way things unfolded,
they certainly made the correct decision. Unfortunately, some of us
users wanted to believe it enough that we let Aaron's pleasing words
deceive us into actually believing what he was saying, and thus, weren't
as worried about how bad the switch was every time we tried it even if we
weren't getting much of anywhere, because we thought no problem, they're
supporting kde3 as long as there are users to support, which will
certainly be until a reasonable number of these issues get fixed! How
deceived we were! =:^(
----
[1] Launch actually being the key X has registered as XF86-WWW or XF86-
Homepage, depending on the xorg version and the config used to activate
it.
--
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-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.