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
