Background:
If you're a technologically inclined person like me, you've probably heard of linux, the free open source operating system. You may even have run it once or twice on the side, just to see what the fuss is about. I did so a few years back, and wound up building a box almost specifically for linux use. That box is dead but its legacy lives on in the box I'm typing this from.
The specific distribution I settled on was Gentoo, at the time an upstart little distro that had the gall to require you to compile your packages for the mad optimizations. It still gets flak for that, and rightly so in some cases. Where this comes in handy though, is with up-to-date packages. Unlike some distros, it's extremely easy to get packages ready for mass consumption, since you offload the building process on the users. That as an aside I can make sure I'm not running a package built for only the capabilities of a 386 on my Core 2 Duo is just gravy here (if I was running 64 bit the difference between the standard Debian packages and my own would be much, much lower to the point of not mattering). However, sometimes letting the Gentoo devs test packages before giving access to this source isn't fast enough. For the mildly adventurous, there's the unstable branch, which you can hit on a per-package basis, or for the whole system. Then there's the truly insane, where you get direct access to the developer repositories via source control (typically subversion or git these days).
Guess which category I fall into.
I've used wildly pre-alpha window managers before (compiz, beryl, and compiz-fusion), and vacillate between the newest and newest with compatable ABI (svn for ffmpeg breaks other packages at the moment, though it works on its own), but I've finally met my match. The offending package here, astonishingly, is KDE 4. To be fair, it was a subversion build of KDE rather than the current stable, but that didn't particularly matter as KDE being stable was a little horribly relative.
The Good:
KDE 4 finally dumps Qt 3 for Qt 4 as the main windowing toolkit. This is mostly an under-the-hood thing, but I'm a programmer so I appreciate it. Also, there are some nicer Qt 4 themes (both widget and window decoration) than are available in the older toolkit. It's worth noting that Qt 4 is actually three years old now, and is only just becoming the standard. The new window manager does 3D compositing, like OSX has for a couple major revisions, Windows Vista's Aero engine, and the three I previously mentioned. If you have a modern 3D card, this basically means you'll have much better performance for basically every program window related function, as well as support for some useless but neat eye candy. KDE 3.5.10 has no such thing, but dumping compiz-fusion in place of KDE's own KWin allows you to pretend it does.
The Bad:
Everything else. No, seriously, it was an awful experience for a number of reasons. For the unaware, the KDE suite includes far more than a default install of Windows from official Microsoft media (if your disc came from your computer manufacturer, it probably comes with things not originally intended to be there). Most of those other things, however, don't work well yet. Mapping keyboard shortcuts, for example, is an exercise in frustration. KDE versions before 4 used an audio manager called aRts to do sound mixing, though most people these days make sure it is either never installed or at the very least never run. The kernel level sound system allows you to perform the same function, but in a much less irritating way as it doesn't block out everything but KDE apps. I'd list aRts' demise under the previous category, but sadly its replacement isn't good enough to make me cheer for it. Worse still, you can't do a damn thing about it now. Phonon is theoretically less intrusive than aRts was, as you can theoretically make it work with ALSA (the kernel drivers), but it takes a bizarre level of work that just raw ALSA users never had to touch. Also, this impacts every sound playing application in the suite, like the music player Amarok. An equalizer is something you expect in all modern music players, whether you use it or not (I do occasionally), but Amarok 2 stripped it because they're not compatible with Phonon.
Amarok is actually a whole can of worms in and of itself. On the back end, Amarok 1 uses a database for its music library. By default, it uses SQLite, a mature product designed to give you a database without a server, which makes it easy on regular users. Odds are, you've used an application that uses SQLite and not even known it. Any Mac user who has used Mail.app has, for example. The user could, however, decide to use an actual standalone database server if he wants. As someone who has done his share of web development, I have mysql running anyway, so using it instead of SQLite (good for most uses, can get slow for particularly large databases, like mine) was a no brainer. Amarok 2 removes both of these, instead requiring MySQL embedded, which performs like SQLite but requires MySQL be installed (another virtue of SQLite is that you can just link the source into your program directly rather than requiring it installed separately), and is less free in terms of license. If it performed as well I might not care, but it's definitely slower than my older version. Worse, it seems prone to explosion with albums by more than one artist, as there are a number of bugs in the Various Artists handling, ranging from the inability to remove albums from that listing to creating pointless duplicate entries that also cannot be removed. The scripting API from Amarok 1 has been completely removed, so there is no period of backward compatibility whatsoever. If you cared about any scripts (I personally use weekalarm and amarokpidgin regularly) you'd better hope that you didn't care much as they don't work and there's no alternative written in the new style yet, and the documentation for writing new scripts isn't even good enough to expect either available anytime soon. Also, if you've used Amarok 1 and really enjoy the context tab, you're in luck! The majority of the program's UI is now devoted to that data. If, like me, you never used it, you now are stuck looking at it anyway, while the playlist is crammed off to the right side and collapsed significantly, and you can't do anything about it because the developers don't want you to. A final insult here comes from the controls; the previous and next buttons (and functions via dbus) will actually start the player, rather than merely move around the playlist. The play function will occasionally not work if the the playlist pointer isn't active (highlighting a track doesn't help this directly), and when it does work at all most of the time it starts playing the NEXT track. If you want to play the first track in a playlist, typically you'll need to right click its entry in the now smaller and further away listing, and push play there, as the much larger button will sometimes skip it just because. Some other more minor features have either changed or been removed, but since some are planned to return (not in time for 2.0 final admittedly), and because this is already too long, I won't get into them.
KTorrent's new release fares better, but not much. Two extremely useful plugins were butchered: RSS and UPnP. The RSS Plugin simply doesn't exist anymore, though it may return. If akregator were more up to snuff (I'm getting ahead of myself) I'd give that a pass, but as it stands that's quite irritating. Also, the UPnP plugin still exists, but it doesn't work properly; it is for whatever reason causing issues with all libupnp applications, so things like MediaTomb (not KDE and therefore working properly) fail to run while that plugin is active. The KDE3 version has no such issue despite providing the same functionality.
Akregator is a special sort of mess, as the svn build I was using did not allow you to read articles in the default mode. Imagine the value of an rss reader that fetches feeds and tells you when you have new articles waiting, but refuses to show them to you. The mode I eventually stumbled on essentially renders the rss with an XSLT sheet applied to a set of the feeds, but does not let you pick which articles to read directly. As a result, you must mark the entire feed read at once, since it's showing you all of the articles and therefore marking none specifically. Adding torrent site rss feeds to this almost replicated the functionality of the ktorrent plugin, though the torrents could not be passed directly to ktorrent, but first had to be handed to Opera (my browser of choice). Also, obviously the auto-download features weren't going to work.
The Ugly:
K3b. The KDE4 subversion version of this (it's a CD/DVD burning front end, if you're unfamiliar) simply does not work. The lead developer claimed yesterday on a bug report that it's pre-alpha, though I'm wondering why such things are in this sort of repository at all given that. Typically these are for very early testing of usable applications rather than useless builds. The most bizarre part of this though, is that the GUI seems to work perfectly fine, it's only the burning features that fail miserably, but the burning is not handled by k3b itself. It basically passes off your file list and options to command line programs like growisofs.
Plasma's Plasmoids deserve a special bit of derision too. Plasmoids are basically like OSX dashboard widgets, which KDE used to use via the application SuperKaramba. There is a KDE4 version of SuperKaramba which is basically an interpreter so you can theoretically use old themes with Plasma. It doesn't work reliably in that fashion, and the two I use (one is a system monitor, the other is a weather montior) don't work with it. A few others I tried did, but there's no indication why mine were different here. I mentioned OSX dashboard widgets specifically for a reason though; Plasma is supposed to be able to render them as plasmoids. To some extent it does. That extent, however, is not even remotely usable. The alpha channel simply doesn't work, so each of them has a large solid color box in the background. Also, the few I tried (all weather type) didn't even fetch data or let me pick my locale, so they weren't even functionally ugly.
If there's one thing KDE 4 had going for it, it was that KDE3 apps can run inside of it. Unfortunately, this creates a bunch of mostly useless overhead as you need the KDE3 versions of every support library to do this, but worse Qt 4's Qt3 support does not let Qt 3 apps use the widgets of your current style. This means you're able to use versions of the KDE apps that actually work, but only if you're willing to make your whole system disjoint and ugly. Worse still, you lose the ability to change the KDE 3 apps' style/colors to even come close to what you're using for the Qt 4 apps.
Conclusion:
Needless to say, I dumped the overlay I was using from my system, but sadly much of KDE 4 (version 4.1.2) has made its way into the "unstable" branch of Gentoo. This of course suggests that much of it is considered quite usable by the developers, and reasonably safe in a Gentoo system itself, as only full releases ever get unmasked at all. This also means that I'm currently building a large number of these applications, because it's easier than manually masking all of them to keep them out, and much easier than adding the unstable keyword to every package I currently have built for the unstable branch (removing the keyword from a global context would keep KDE 4.1.2 from building, but require basically everything else to be downgraded). Fortunately, they run side-by-side, but most of these things are a nuisance at best, so it's a bit of a waste of time, bandwidth, and harddrive space. Best advice here is stay the hell away from KDE 4. The best things about it can be replicated in KDE 3.5 without much difficulty, and the worst things require you to have most of KDE 3.5 around anyway. Don't bother.
No comments:
Post a Comment