[kde-linux] Another KDE 4.x print problem?

[Duncan]

Esben Mose Hansen posted on Mon, 02 Nov 2009 15:40:51 +0100 as excerpted:

> On Monday 02 November 2009 14:23:20 Dale wrote:
>> It'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