[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

szalkai posted on Mon, 24 Aug 2009 22:41:19 +0200 as excerpted:

> Now that this exciting little flamewar has finished, and everybody is
> friends again :), could you Duncan please give some examples of major
> breakage in KDE4?

Altho some of it's covered down-thread by others, I did promise it if any 
one asked, and you did, so below you'll see a bit of a list, some 
mentioned in the followups I've read so far, some not.

> I have been using it since 4.1.something and it is
> getting better and better.

Absolutely!  I've been trying it on and off since before 4.0 actually 
came out, and you're 100% correct, it *IS* getting better and better.  
But 4.0 was NOT release quality and at least KDE has allowed /that/ much, 
tho we still differ on where release quality actually looks to be 
achieved, and they had a LONG way to go.

Again, as noted previously, part of the problem is actually how 
exceedingly good kde 3.5. was, a point that's even more amazing when you 
consider the age of the technology involved.  Kde4 was pretty much a 
ground-up rewrite, and no matter HOW you slice and dice that, it WILL 
take awhile, especially when the previous version was as good as 3.5 was/
is.  I just wish they'd continue to properly support 3.5 until 4.5 or so, 
when I believe it'll finally be comparable, plus of course the new 
features 4.x has.  And that they'd have handled the whole transition 
better, but that can't be helped now, tho they /could/ still actually 
support 3.5 another year if they wanted to.

>  Also, it took me nowhere near 80 hours to
> switch from 3.5.10 to 4.

Well, as you'll see below, I depended on much in kde3 that simply hasn't 
made the transfer, yet, at least not in fully functional form.  That has 
been a HUGE problem, or rather, multiple problems, thus the 80 hours.

> I admit that I have a konsole with seven tabs open all the time, and do
> most of my work from there (and use firefox for browsing and thunderbird
> for emails), so I am not a KDE poweruser by far (while definitely a
> linux poweruser at least),

I'd say that anyone actually using Gentoo (not just surviving it, 
following rote directions) is a Linux power user by definition, at least 
by definition of comparison to the average user on most of the binary 
distributions.

That's not a putdown of the binary distributions, BTW.  There's 
absolutely a place for the Ubuntus of the world, and their users, and we 
were all newbies at one point.  But some of us at least don't stay 
newbies...

And Gentoo is suitable for newbies too, if they're willing to actually 
pay attention, read docs, and learn!

I know for a fact (from the postings on the docs list from the guy who 
developed and taught it) that Gentoo is used in at least one decently in-
depth high school and college level intro to computers and computer 
technology class.  He starts by explaining the basics of memory, etc, in 
a karate-kid/guru style format (the kid visits an old computer guru who 
starts teaching him what he knows).  By the middle of the second week
(in a semester class), they've covered the basics, and are getting into 
Gentoo.  The rest of the semester, they do the install, I think from 
stage-1, gradually bootstrapping the system over the weeks, with the 
function of each new package in the system level explained along with 
configuration, etc.  By the time they are done, they have a fully 
functional Gentoo system, AND know enough about the software components 
and how they fit together and work, to do a decent job of teaching it to 
those newbie Ubuntu users, given the chance! =:^)

Now I **WISH** that's how I was taught computers!  But there's at least 
/some/ folks getting that sort of quality instruction. =:^)

> but even 4.2 already seemed stable enough for
> me. Actually, the thing that made me switch in excitement was the
> promise of the semantic desktop stuff, not the eyecandy, but it has
> disappointed me so far.

Actually, the semantic desktop and etc weren't a big sell for me at all.  
Rather the opposite, in fact, as I do reasonably well with the 
organization I've developed over the years, and the semantic desktop, 
while nice in theory, is sort of like the locate command and database 
update that always seemed to be running at the most inconvenient times 
(and I don't have a set enough schedule to really schedule it at a better 
time, because what's better this week might be terrible next week, and 
merely tolerable the week after that), so I quickly decided I didn't need 
it and shut it off.  I don't think I ever merged it on Gentoo.  I've not 
missed it.

And I've kept as deactivated as possible all of the semantic desktop 
stuff too.  And if I /do/ forget where that file is, grep and find are my 
friends.  =:^)  Of course, they don't necessarily work so well for say 
image files... but then, neither does the semantic desktop, unless you've 
tagged them effectively, and that's what choosing a proper name and 
directory layout is all about, only without all the trouble.

At least it works that way for those who seem to groke computer style 
directory layouts and the like.  I do understand that not everybody 
does,and that the semantic desktop should really help the types of folks 
that download something, and then can't remember where they told they 
system to save it when they want to open it.  But that's just a problem 
I've never had, and the semantic desktop stuff seems, at least at this 
stage, to be more trouble than the hassle involved is worth.  Maybe after 
a few years of further development.  Not now.

> BTW Duncan, I do enjoy and appreciate your posts here.

Thanks, both to you and others.  I've said before and I'll say it again, 
that the reason I'm here is to help and at times be helped.  When that's 
no longer happening, I've no further interest in being here, and I'll 
find someplace else where I'm better able to contribute something 
worthwhile.  So I'm glad people are still finding my posts useful.


OK, to that list...

Hotkeys:  KDE bug 161009.  In kde3 I used hotkeys extremely extensively, 
probably launching 95% or more of my apps that way, etc.

Now, I have one of those Internet aka Multimedia style keyboards (a 
Logitech Cordless Desktop Pro, to be exact, it's also an ergonomic "wave" 
design -- I can type /hours/ on it, day in and day out, with no problems, 
but only a few minutes on a "straight" keyboard without PAIN), with a 
bunch of extra keys.  However, it's FAR from enough extra keys to 
dedicate a key per function I want to hotkey.  Thus, the way I had it 
arranged on kde3, while I had one hotkey to launch the (seldom used) 
kmenu, and another to use the (actually frequently used, but for 
different things) run dialog, now called krunner, most of those keys were 
setup as two-key menus with multiple functions.  I'd hit the key, say 
XF86HomePage, and kde3's hotkeys would popup a menu that listed all the 
second-level keys I'd setup, "w" for web browser, "m" for mail, "e" for 
text editor, etc.  Of course, the menu really didn't matter that much, as 
it was usually HomePage,W to launch the web browser, for example, in 
quick enough succession the menu may not have even fully displayed.  And 
I'm a touch-typist and know the hotkeys by position and touch, so I never 
had to look at the keyboard OR shift to the mouse OR use the several more 
key sequence that would have been necessary to launch it from the kmenu, 
even if I remembered that longer sequence to do so.

That's quite a productivity booster once someone's used to it, quickly 
becoming more of a necessity than a luxury.  I had similar menus for 
window functions, display resolution changes (since the old Ctrl-Alt-Num+/
Num- zooming sequences died and were buried as xorg switched to RandR 
technology, better for monitor hotplugging, but RIP Num+/- zooming!), 
etc, plus the dedicated single-function media keys for changing volume 
and play/stop/next/prev.  One of the nice things about it was that 
because those are non-ordinary "extra" keys, none of the sequences 
involving them interfered with any application built-in sequences using 
the more standard Ctrl/Alt/Shft/Meta keys, so those were still entirely 
free to be used by the applications themselves without any conflict or 
interference.

That functionality, multi-key global hotkeys it's called in the bug, is 
flat broken on kde4.  What's worse, the bug implies the problem is 
actually in a support library somewhere, perhaps a different part of kde 
(not khotkeys), more likely somewhere in a third party library.  Given 
kde's dependence on qt, I'd /guess/ it's a problem there.  Regardless, 
the functionality is broken, and looks likely to remain broken for the 
near future, at least, until someone either hacks a workaround into kde, 
or convinces whatever library upstream to provide the functionality.  
What I /don't/ understand is why kde3 could have it, then, unless they 
simply coded up their own solution there, and took the half-solution 
provided by the library instead, once it became available.

Anyway, given the circumstances, it's understandable that there's no kde4 
solution, but that doesn't help the folks that depended on that feature 
in kde3 to find a useful substitute for kde4.

Solution?  There are other hotkey programs available for Linux, tho many 
of them don't handle multi-key either.  One that actually DOES handle 
multikey is xbindkeys.  However, in it's "simple" mode it doesn't handle 
multi-key, and its "advanced" mode involves guile and scheme (lisp-like 
language) macros.  Basically, the first key triggered the macro, which 
then set up a countdown to timeout, waiting for the second key.  
Depending on which order keys were pressed and released, different 
actions were configured to be triggered by the macro.  So... I started 
studying guile and scheme, having never used a lisp-like language before, 
so I could groke what was going on and program it effectively to do what 
I wanted.  Of course, that's WAY more powerful than khotkeys, but it all 
takes time to learn, especially when you've not an EMACS devote and don't 
otherwise have any previous LISP experience...  You seeing where those 80 
hours might be going now?!

So, several hours after starting on that... actually, as with a lot of 
this, I got tired and slept the few hours shorter sleep I was getting 
much of the time during the several weeks I spent working on all this, as 
I was putting all the time possible into get kde4 working... then came 
back to it the next day...

Anyway, several hours into trying to groke guile and scheme, just as I 
was actually beginning to get the hang of things, I had an epiphany...

I realized that what was /actually/ happening was as I mentioned but 
glossed over above... that what xbindkeys was actually doing was a
single-key trigger of a /second/ program, the guile macro, which detected 
the second key (or timed out if none came), and triggered the programmed 
action accordingly!

Well, I don't know scheme or guile, tho it /was/ beginning to make sense 
by that point, but I *DO* know bash scripting well enough to write my own 
sysadmin scripts, hack on ebuilds, hack on the boot cycle initscript 
system, etc.  The epiphany was that **I** could do the SAME thing in what 
I already knew, bash, using kde4's more limited single-key hotkeys to 
launch my bash scripts, to do what the guile macros would have done for 
xbindkeys!

So then another sleepless nite of bash hacking later, after 16 hours of 
hacking or so, I had a set of scripts to do pretty much just that.  I had 
khotkeys setup to launch the starter script with one key.  The starter 
script then launched a second script in a konsole window, displayed in 
that window a hotkey menu read in from a data file and a prompt, waited 
for a timeout or a single key, detected what they key was (a second data 
file contained a lookup table mapping returned control-key sequences to 
text representations that could be easier entered in the corresponding 
line of the first data file, which had three columns, hotkey, 
description, command; part of that time was spent those sequences and 
setting up that second mapping table), checked for a corresponding line 
in the first table, and ran the corresponding command from that table.

I then setup a special konsole profile for the window to display that 
menu, setting it to turn off the tabs, scrollbar and menubar, etc.  
Further I setup a special window settings config (kwin profile) for that 
window, setting it to an appropriate size (different from my normal 
konsole windows), always-on-top, centered placement (I tried under-mouse 
but that didn't work so well as it cause the launched window to displace, 
the centered option didn't), etc.

Finally, after testing each shortcut sequence, (menu-launcher,app-
launcher, menu-launcher key set in khotkeys, app-launcher key set in the 
script datafile along with the command and a description, as I said), I 
unset the temporary assignments I'd set for them in khotkeys, and for 
kmenu entries I'd created in ordered to apply a hotkey, I deleted them 
too, thus cleaning up my kmenu apps menu substantially. =:^)

So now I have a working dual-key launcher again, this time partially 
implemented using my own scripting, and hopefully kde won't be pulling 
any MORE functionality out from under me so it should continue to work, 
at least thru the kde4 series. =:^)

That's ONE problem and solution. =:^)

The second problem was color settings.  There's some background here, as 
the LACK of a decent per-role color-setting app way back in GNOME 1, when 
even MICROS~1 could manage /that/, was the triggering factor in my 
original decision to choose KDE (then kde2.x) as my desktop environment 
of choice, way back in early 2002 shortly after I switched from 
MICROS~1.  Kde2 of course DID have that color choices app, much like it 
does today, while GNOME forced a user to either set an entire scheme at 
once, or hand-edit text config files, to get the same results KDE did 
with their nice GUI color settings applet.  Of course, as we now know in 
hindsight, that choice was the correct one, as Gnome got even /more/ anal 
about insisting they had the "One True Way" that simply MUST be correct, 
removing even more configuration functionality with Gnome2.  To be fair, 
I've not spent a whole lot of time (read none, the closest I get is GTK 
apps) on Gnome recently, and perhaps they've reversed that trend, but 
from what I've seen and heard, it hasn't changed substantially.  KDE is 
still the choice for power users that like to tweak their system.

Of course, that's part of my problem.  As any self-respecting power user, 
I had kde3 heavily customized, and was using and depending on 
functionality like multi-key hotkeys that's not mainstream, and that in 
many cases is still broken in kde4, or was in 4.2 anyway tho 4.3 is 
markedly better.

Anyway, back to colors.  I happen to have a low tolerance for "glaring" 
white backgrounds.  Further, the default muted grays that seem to be the 
corporate-safe defaults shipped by most distributions and environments 
make me almost physically nauseous!  As a result, I have STRONG 
preferences for a generally light text on dark background scheme that is 
none-the-less much more colorful than color-scheme default tend to be.

The /problem/ is that because dark on light is the default, it's also the 
all too frequently assumption made.  As anybody with such preferences can 
tell you, light text on a light background, because the author simply 
assumed a dark text default when he set the background, or the reverse, 
dark text on a dark background, because the author simply assumed a light 
background when she set the foreground, instead of consistently setting 
BOTH foreground and background whenever ONE is set, is an **ALL** too 
frequent problem on the web!  (FWIW, I use privoxy as a personal web 
proxy for that reason among others, with a filter scheme I've been 
tweaking for years, setup to darken light backgrounds and lighten dark 
foregrounds, without reducing to mono-color as enforcing such preferences 
at the browser CSS level seem to do.)

Well, the same set of problems occurs on the desktop.  It can take /
years/ of tweaking to get a reasonably colorful light foreground on a 
dark background scheme setup, one that deals well with all the curves 
various developers' wrong color scheme assumptions throw at you from time 
to time.

What's worse is that unlike those with an apparently more normal dark on 
light preference, light on dark schemes are around, but rather less 
frequent than dark on light schemes.  That makes it much harder to find a 
reasonably close to personal preferences match to form a base for further 
tweaking as needed.

I was thus naturally rather frustrated when I realized that kde4 had /no/ 
provision for even /trying/ to import kde3 color schemes, including the 
one I'd been tweaking for years to get "just right".  I was looking at 
not only quite some time to find a decent kde4 color scheme base to work 
from, but also the prospect of spending /years/ tweaking it a little here 
and a little there, until it again met my needs as well as the one I'd 
already spent /years/ tweaking for kde3.

As it happened, the kde dev that maintains the color control applet 
happened by the kde-general list after I'd posted this as one of the 
issues I was struggling with.  He and I now have a reasonably good 
working relationship, with mutual respect, I believe, and I and another 
user regular on the list have worked with him throwing ideas back and 
forth, etc.

The complicating factor for kde4 is that its color scheme is **FAR** 
richer than kde3's was, with six different role variants of several more 
base color roles than kde3 had.  There's thus no direct conversion 
possible.  However, it IS possible to do an indirect conversion, doing a 
passable first-guess at some of the new roles based on similar but 
multiplexed roles in the kde3 color scheme, with a warning for any kde3 
scheme that more tweaking will likely be necessary to get the best 
results.  I'm HAPPY to say that a kde3 color scheme importer and 
converter has been committed and should be part of kde4.4.  Whether it'll 
be backported to 4.3.x I'm not sure, but that's just /one/ of multiple 
bugs and wish-list items, the polish that has been so lacking in kde4 to 
date, that I KNOW are fixed for 4.4.

That was /my/ problem solved, but in the back and forth, we succeeded in 
coming up with a better UI for the color choices that are there, as 
well.  Take a look at the 4.3 color choices applet, in particular, the 
preview.  Can you truthfully say that it's obvious what those mysterious 
"a i ! = +" symbols are all about?  What about the two separate lines 
(altho that's a bit easier, normal vs selected text)?  I know /I/ didn't 
understand what those symbols were, tho the selected vs normal text was 
obvious.

Here's a hint.  Switch to the colors tab.  On the colors tab, select 
anything /other/ than the default "common colors".  See the word 
descriptions?  Now take a look at the line of symbols from the other tabs 
and from common colors on this tab that I typed above and see if it 
clicks.

CORRECT!  a=active, i=inactive, !=negative, ==neutral, +=positive.  
There's also hover.  Those are the role variants I mentioned above.  Some 
of that is set directly, some of it selected automatically based on 
chosen colors.  The display with the words is setup so that the lowest 
contrast matches of foreground to background are shown, and if any of 
those words are invisible due to inadequate contrast, it's because the 
person who designed whatever color scheme you are running, didn't 
properly understand how kde4's color schemes work.  FINALLY!  Finally 
there's a nice built-in tool allowing devs and color-scheme authors to 
see if any of their choices aren't going to work due to invalid 
assumptions or an improper understanding of kde's color roles!  Once how 
this works is well understood, it'll hopefully mean MUCH better designed 
color schemes, without those nasty but all too common "invisible writing" 
bugs.

OK, so if you're like me, that's entirely new information, and you 
understand far better what's going on in the color dialog and previews 
now.  So what was the problem?  Well, the problem was (and still is with 
4.3.0) that the present arrangement doesn't effectively convey all that 
information.  Granted, it's a really TOUGH thing to do -- effectively.  
We threw ideas back and forth for several rounds before we came up with 
something better, but all of those in the exchange agree with the new 
solution -- this one almost certainly 4.4 not 4.3 backported, as it 
involves string changes, and 4.3 was in string freeze for translation 
purposes by the time we worked this out.

BTW, the i18n (internationalization, i, 18-letters, n) issues were 
significant complications here as well.  Apparently, the descriptions are 
rather longer in certain other languages, and the dialog either ends up 
with horizontal scroll bars or too wide for small displays.  That's with 
things as they are, and our initial solutions were making it worse!

What we eventually came up with, after realizing that some of the other 
system-settings dialogs are longer (vertically) than the colors dialog, 
was splitting the lines, thus using more space vertically but less 
horizontally.  While it might add vertical scrolling in some cases, the 
colors dialog will still be shorter than a couple of the others, and 
vertical scrolling is FAR more acceptable than horizontal scrolling in 
any case.  This solved the problem he was already trying to tackle with 
the long translations, while also addressing the cryptic symbols issue a 
bit better! =:^)

Now THAT'S how user/developer communication is SUPPOSED to work! =:^)

Meanwhile, with the better understanding that gave me of how kde4's 
colors worked, I found a color scheme on kde-look that worked very well 
for me -- very close to as good as the kde3 scheme I had taken so long to 
tweak had worked there for me! =:^)  It's not the same, but if anything, 
I think it's even nicer than I'd have had even if the kde3 scheme /had/ 
been able to transfer perfectly. =:^)

All-in-all, this one turned out by far the best of any of the problems I 
had, all because one dev was willing to come visit the user groups and 
not too offended at a user desperately crying for help due to frustration 
with his applet and its limitations! =:^)

That's only two of my issues, but this is long enough, and that should 
give people an idea, anyway.  Very quickly, however, I'll mention that a 
couple of the others were performance and multi-monitor related, much as 
others are already posting.  But I'll cover those in replies to those 
posts, as I may be able to help others with them based on my own 
experience and knowledge now, having spent all that time desperately 
working on it, getting the system back to usable enough that I could 
actually be somewhat productive once again.

And, if I'm lucky, that colors dialog information will turn out to be as 
concretely useful to at least one other user here as it was to me!  After 
all, I /did/ say I'm here to help, otherwise it's not worth the bother.  
But I expect it'll be of use to someone, because it SURE was new and 
useful info to me. =:^)


-- 
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