briancarper.net (λ) (Tag: KDE)

X automation with xte

Fri, 06 Aug 2010 13:03:01 -0700

I learned today (via a great blog post) about xte. This program lets you simulate X Windows mouse and keyboard events from the commandline. How much more awesome can you get?

Hans illustrates how to integrate xbindkeys and xte to make KDE4 effects activate. I wanted the KDE4 "Desktop Grid" to appear when I press a mouse button (because my new mouse has a lot of buttons to spare), so this is exactly what I was looking for.

xte is the kind of glue that makes Linux awesome. KDE lets you set global keyboard shortcuts for lots of things. xbindkeys lets you assign shell commands to mouse buttons. And xte ties the two together. Possibly none of the programmers on these three tools knew about the others, but they interact perfectly to let you do anything you want.

You may be thinking, "If you want to work with KDE from the commandline, why not use DBUS?" That's what I tried to do first. But I can't for the life of me figure it out. There's some indication that we might be able to do this somday, like so:

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut ShowDesktopGrid

Or maybe it's already in the latest version of KDE and I haven't upgraded yet. Either way.

By the way: could DBUS possibly have a more verbose or cryptic interface? I was hunting through the available DBUS commands looking for something that would show the Desktop Grid, and I ended up having to scan through lists of crap like this:

~ % qdbus org.kde.kwin /KWin                         
method Q_NOREPLY void org.kde.KWin.cascadeDesktop()
method void org.kde.KWin.circulateDesktopApplications()
method bool org.kde.KWin.compositingActive()
signal void org.kde.KWin.compositingToggled(bool active)
method int org.kde.KWin.currentDesktop()
method QList<int> org.kde.KWin.decorationSupportedColors()
method void org.kde.KWin.doNotManage(QString name)
method Q_NOREPLY void org.kde.KWin.killWindow()
method QStringList org.kde.KWin.listOfEffects()
method void org.kde.KWin.loadEffect(QString name)
method QStringList org.kde.KWin.loadedEffects()
method void org.kde.KWin.nextDesktop()
method void org.kde.KWin.previousDesktop()
method Q_NOREPLY void org.kde.KWin.reconfigure()
method void org.kde.KWin.reconfigureEffect(QString name)
method void org.kde.KWin.refresh()
signal void org.kde.KWin.reinitCompositing()
signal void org.kde.KWin.reloadConfig()
method bool org.kde.KWin.setCurrentDesktop(int desktop)
method void org.kde.KWin.showWindowMenuAt(qlonglong winId, int x, int y)
method Q_NOREPLY void org.kde.KWin.toggleCompositing()
method void org.kde.KWin.toggleEffect(QString name)
method Q_NOREPLY void org.kde.KWin.unclutterDesktop()
method void org.kde.KWin.unloadEffect(QString name)
method bool org.kde.KWin.waitForCompositingSetup()
method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value)
method QString org.freedesktop.DBus.Introspectable.Introspect()

This is line noise to me.

Screenshot June 2010

Tue, 08 Jun 2010 12:27:44 -0700

I haven't posted one of these in a while. I've been in an 8-bit kind of mindset for a while:

What I actually stare at for 8 hours every day:

KDE4, Buuf icons, QtCurve, wallpaper is from somewhere on the internets.

Fluxbox, we meet again

Sun, 15 Nov 2009 16:32:59 -0800

I'm sort of tired of KDE4 crashing left and right and Plasma barfing all over me all day. So I decided to check out the current state of lightweight window managers.

Lo and behold, Fluxbox is still going strong. It was the first WM I used way back in 2000-something when I started using Linux full-time. Last time I tried, there were always weird compatibility problems with system tray icons and pagers working properly when running a mix of KDE and Gnome and other apps, but those seem to have cleared up nicely; I have yet to hit any snags. Here's a screenshot.

This took very minimal effort to install and set up. Maybe a couple hours total. I'm using ipager and conky. The wallpaper comes from the UniQ KDE theme. Vim and Emacs themes are my own.

The Fluxbox style is mydefcon_4 from tenr.de which is probably the largest and most thorough set of themes created by one person that I've witnessed. That fellow is motivated.

For all the bells and whistles of KDE4, what features did I actually use regularly?

A menu of apps
Taskbar + System tray + Clock
KWin's good window management.
Global keyboard shortcuts galore
One widget: current CPU/RAM/Network usage
Mouse/keyboard management, background-setting, etc.

Fluxbox gives me all but number 5, and Conky gives me that. Number 6 you can do with xset and feh and such.

And I like being motivated to use keyboard shortcuts for more things. I'm already halfway there. Maybe I can take the plunge eventually and try a tiling window manager. Not sure I've reached that level of nerditude yet though.

And now I can move and resize windows without my graphics card bursting into flames. Maybe when I can afford a few more cores worth of CPU I'll try KDE4 again. Honestly I think I have too much monitor real-estate for my ancient computer to handle smoothly in KDE4.

Not to knock KDE4; it's awesome and I'll probably go back someday. But everyone needs a break now and then.

Amarok 2.2: DISBER GROGTH GROCKS

Fri, 06 Nov 2009 01:14:49 -0800

Remember Amarok 1.4? Remember how awesome it was? Here's a screenshot just in case you don't remember.

Does it bring back fond memories of music and comfortable GUI interfaces? It does for me. Those were good times. Keep that picture in mind.

Let's play a game called "Can we make Amarok 2.2 look like Amarok 1.4"? I've heard this as a response to complaints about Amarok 2's GUI: You can make it look like Amarok 1.4 if you want.

So let's try. Ready? Here it is:

Does it look the same? Not really. Kind of close. That's as good as I could do though. There are no headers on the columns in the playlist, so you can't tell what half of those things mean. You can't resize the fields (like you could in 1.4). You can't sort them by a simple click of a header (like you could in 1.4); instead you have that strange breadcrumb thing up there. You can't add new fields by right-clicking and picking them from a menu (as you could in 1.4). Not as many songs fit in the playlist in 2.2, but it's pretty close.

Now, here's the good part. How do you get Amarok 2.2 to look this way? By doing THIS!

AAHHHHHHH! Too bad Halloween is gone, because I could use that dialog to scare children. The title of this blog post, DISBER GROGTH GROCKS, comes from the mangled and truncated labels in that horizontally-scrolling list of icons. Doesn't it sound like the deranged grunting of a once-proud beast, now fallen into ruin, stumbling zombie-like through the world, a mere shambles of its former self? I think so.

Once in a blue moon, I'll witness the behavior of an application that's so off-the-wall, bat-honking insane that I'm reduced to maniacal laughter. That's not an exaggeration; I literally gape at the computer screen and cackle like a madman, curling reflexively into a fetal position. This was one of those times.

It took me well over a half hour to drag and drop all of those controls into that window in the right order with dividers between them. Thank God for 1920x1200 monitors or the dialog wouldn't even have fit on the screen. (No, it's not resizable.)

Why a half hour? Because I also had to click every single one of those elements and set its width as a percentage using a slider in a sub-dialog. By default every field is an equal width, so that a field with a single digit in it has a mile of whitespace on either side, while song titles are displayed as "C...". And this dialog is the only way to fix it:

How did I come up with 25% there? Laborious trial-and-error. Amarok 2.2. takes what was a click-and-drag-to-resize operation in every other application ever written, and turns it into an algebra problem. Twelve fields I had to tweak, one by one. I was probably in and out of that dialog 3 or 4 dozen times.

(I'll spare you what happens when you resize the window in Amarok 2.2. Suffice it to say once you get it looking OK, never touch it again.)

Now, I'm no expert on GUI design. But I'm guessing there's a reason most applications don't do things this way. Columns of data with headers at the top are nice. They're kind of boring, but they're boring like a doorknob. You turn it and the door opens. There isn't much room (or need) for improvement. I don't want to have to solve a logic puzzle to get out of the bathroom every morning, and I don't want to play a video game of line-up-the-widgets and guess-the-percentages just to get a playlist to display some fields of information.

In Amarok 2.2 there's also no button for Repeat/Shuffle, and the Equalizer tells me it disabled itself because I don't have the right version of Phonon, and the collection list is very unresponsive (even expanding / collapsing an artist's albums lags), and there are no visualizations, and no themes, and the volume slider is hidden behind a button in the bottom-right there unlike Amarok 1.4's perfectly functional slider, and well you get the picture. But hey, you can browse Flickr in Amarok now. Finally!

Amarok 2.2 is what I'd now call "just barely usable", which is actually an improvement from previous versions, but that's not saying much. I've used it for over a month, only because 1.4 can no longer even scan a collection on my computer, Last.fm is broken, and I got a notice today that Gentoo is deprecating KDE3 entirely. Amarok 1.4 is the new XMMS; Qt3 is the new GTK1. Some people will cling to them, somehow barely keeping them running on their systems, until bitrot and neglect force them to fade away into history, whether there's a good replacement around or not.

I was a huge cheerleader for Amarok 1.4; it was a flagship KDE / Linux GUI app. Now I don't know what to say. Final grade, Amarok 2.2: D+. It avoided an F because I can get sound to come out of it, and it didn't erase my hard drive.

(Anyone out there reading this, if you port Amarok 1.4 to Qt4 intact, I will pay you. Seriously. I will pay you money.)

KMail is slow

Sun, 18 Oct 2009 13:38:48 -0700

KMail is a pretty good app, except that it's slow as glacier. If I select a few thousand spam emails in KMail (4.3.2) sitting on my IMAP server, and I try to delete them, KMail laboriously iterates through them deleting them one at a time and updating the GUI after every deletion. I'd say it averages about 4 or 5 emails deleted per second. Yes, for a few thousand emails this adds up to 10-15 minutes of waiting.

I got tired of waiting, so I decided to try out Mutt for the first time. In Mutt apparently you can delete a folder full of emails by pressing D and then specifying ~s .* as the search pattern. Mutt deleted 8,000 spam emails for me instantaneously.

This is what I get when I ignore the collective wisdom of the Linux group-mind. I've long heard that Mutt is good but I never bothered trying it, because Thunderbird and KMail and friends were "good enough".

Complacency, my old nemesis. You have beaten me again. But I am now going to give Mutt a good try. Next on the list is zsh.

Force Google Chromium to have a normal title bar in KDE

Sat, 19 Sep 2009 01:58:26 -0700

KDE is awesome largely because KWin is awesome. If I had to name one reason I gave up using Gnome and moved to KDE, it'd be KWin.

Some programs (for example, Songbird, aTunes, Google Chrom(e|ium)) try to manage their own windows in silly ways like hiding their title bars and window borders, or fiddling with how they appear in pagers or task managers / application lists, or trying to manage their own sizes and positions. KWin lets you override and force sane preferences upon such programs.

Chromium for Linux is nice enough to give you an option to "Use system title bar and borders" if you right-click the top. But this only changes how Chrome looks; it doesn't make the KWin title bar and borders appear.

Why would you want KWin title bar and borders? Because by default, Chromium's self-managed title bar only gives you Windowsy options like minimize/maximize/close. It doesn't give you Linuxy options like double-clicking the title bar to window-shade the window, or right-clicking the title bar to get the KDE menu to send it between desktops or make it Always on Top, and such goodness. If I wanted gimped up window management I'd go use Windows 95.

To get the normal KWin title bar to appear, go into System Settings, Window Behavior, Window Specific, then New...

Click the Detect Window Properties button and then click an open Chromium window to fill in the details, as in this screenshot.

(Note that for most apps you can right-click the title bar of the window, go to Advanced and Special Application settings and get to the same place, but in the special case of windows without normal title bars, you have to do it in this more roundabout way.)

Then go to Preferences and set No Border to "Force", and uncheck the box. (This is kind of confusing because it's a double-negative; a checked box means to hide the window borders, and an unchecked box means to show them.)

Once you save and apply all of this, Chromium will have a normal window title and border forever, whether it likes it or not. Rejoice as sanity is restored to the world.

You can use this dialog to do other helpful things like make your IM windows be sticky across all desktops by default. Or to sort your applications to always start (and stay) on certain desktops. Or to force applications to start maximized or have a certain geometry.

Another thing I find very helpful is to turn Focus stealing prevention to the highest setting for any program that likes to throw dialog boxes at me and demand immediate attention. Thunderbird used to be really annoying in this way.

Most other Linux window managers can do some of this kind of thing too with either built-in options or via 3rd-party scripts (last I checked Gnome was the latter but it's been a while). However few do it as well as KWin. The only thing I've used comparable to KWin is probably FVWM, and KWin's GUI configuration is orders of magnitude easier to work with than FVWM config files.

Plamsa + Ruby = Ouch

Tue, 08 Sep 2009 23:34:17 -0700

I wrote my first KDE4 plasmoid the other day. I can't release it because it's essentially a clone of something you aren't allowed to copy (maybe I can replace him with a penguin and release it that way though).

But I need to rewrite it first anyways, because I did it using the Ruby bindings for Qt4 and Plasma, and wow it's painful. It has a 50/50 shot of even initializing at any given point. When it does initialize, it has about a 1 on 8 chance of immediately crashing Plasma. And some things I just can't get to work at all, e.g. setting a default size or resizing the applet programmatically; X-Plasma-DefaultSize in the metadata is supposed to do it but it does nothing. And it's not just my system (using KDE 4.3), because I tried it on a Kubuntu machine using stable KDE 4.2 and had the same problems.

The other snag is that the documentation of the Plasma API is buried so deep on the KDE site that I don't even know how I found it. Here it is for those who care (and for my own future reference). I hit lots of dead links on the KDE site on the way there.

Next step is to rewrite the plasmoid in Python or C++ I guess.

Way to go, Arch

Tue, 04 Aug 2009 20:38:23 -0700

KDE 4.3 is available in Arch already. If the Arch MB is to be believed, it was available for install a few hours before KDE even announced it. Good job Arch devs. Arch seems to have pretty fast turnaround on new packages.

The stable release of KDE 4.3 is looking good too. I wiped my KDE profile because I think I've been running the same one since KDE 3.1 and the cruft was becoming noticeable. That helped resolve a lot of things (I can add widgets to the main panel without crashing things now).

One thing that has caused me tons of problems historically is CJK input in KDE. In KDE3 Skim worked OK, but I couldn't get it to work in KDE4. Instead there's UIM which so far has been better than Skim in terms of stability and predictability of interface.

As per a comment by knef on a recent post, you can set per-desktop wallpapers now (as in virtual desktops, workspaces, whatever you call them). You have to:

Zoom out (via the cashew)
Hope it doesn't crash
Go into the Plasma options there
Pray it doesn't crash
Enable the setting to make each desktop have its own "activity"
Yeah you probably crashed right here. In the off chance you didn't crash, once you zoom in you can set per-desktop wallpapers now.

Not just wallpapers, but widgets in general. This is kind of good, kind of bad. If you want to go back to a single wallpaper per desktop, you have to go back and screw with activities. Also I don't think you can "sticky" a widget to span all desktops. It's either everything per-desktop or everything global. I'd bet this will change in future versions.

But I read a suggestion somewhere (probably Slashdot) to set up a different Folder View on each desktop, each pointing to a different folder, and that's actually a great idea. You can set kwin to always open Gimp on a certain desktop and have a folder view of your pictures folder underneath, or something.

Kudos KDE devs, KDE is awesome and keeps getting better.

KDE 4.3 Looking Good

Sat, 25 Jul 2009 19:48:25 -0700

I just installed KDE 4.3 and it's looking good. Some features returned that I was missing. You can now once again display applications by name rather than description in the K-menu. You can now enable a nice kcontrol-like tree-view in the System Settings.

Some things are still missing though... like different wallpapers on different desktops. There are "Activities" which can have different wallpapers, but I can't for the life of me figure out how I'm supposed to be using them. I also lag and/or crash every time I Zoom Out in the cashew, possibly thanks to 3840x1200 screen resolution. I'm going to assume Activities are still a work-in-progress.

I was horrified to open Kopete and see that configuring the contact list window now uses the same completely broken configuration dialog that Amarok 2 uses for their playlist. Oh how I hope someone rethinks this.

There's a new Qt and Plasma theme in KDE 4.3 that looks pretty nice. Overall every release of KDE4 seems to become more stable, more polished, more eye-candy (if you want it).

Songbird vs. Amarok: How not to design a GUI

Sat, 11 Jul 2009 21:09:23 -0700

Recently I forced myself to uninstall Amarok 1.4 and try Amarok 2 again. I saw there were some nice updates to the interface coming in the next version so I grabbed the latest version from SVN.

I very quickly started looking for other alternatives, and you'll soon see why. The best I could find was Songbird.

I'll start with a disclaimer that both of these programs are great, and they are free. I am not suggesting, let alone demanding, that anyone change anything in either program to suit me. Kudos and thanks to the devs of both. These two programs are both probably better apps than I could dream of coding. Feel free to respond "Ask for a refund" and "Fix it yourself" anyways if you like. I think it's still useful to give some constructive feedback, and maybe I'll learn something myself about how to make a good GUI along the way.

Next I'll start with my conclusion, so you don't have to read further, because this is admittedly long. Amarok 2's interface is extremely painful, but at least it plays music. Songbird has a wonderful interface, much like Amarok 1.4 had a wonderful interface; if only I could get Songbird to make sound come out of my speakers, I'd be set.

I think it's interesting to compare Songbird and Amarok 2, both being bleeding-edge music players for Linux with a similar philosophy and feature set. So let's compare GUIs. I sized the two windows exactly the same and tried to have them display mostly the same bits of information, so it'd be easy to compare. Click below for larger versions.

Amarok 2:

Songbird:

Playlist

In Songbird the playlist dominates the window by default. This is good because seeing a list of music is what I want. It's the whole point of a music player.

I strongly dislike the "filter pane" style of browsing my music. Thankfully you can turn it off in Songbird. You can also install "cover flow" sorts of eye-candy extensions if that floats your boat. I avoid such things, and Songbird's interface is easy and comfortable by default.

In Amarok by default the playlist is a little sliver of GUI off on the right, and the middle context pane dominates the window. Enough people complained about this that in later versions you can turn off the context view entirely, in which case the playlist will stretch to a reasonable size. Whether the information in it will look good is another story (see below).

Amarok's "Local Collection" browser is an expandable tree. You can customize how things are grouped. This was great in Amarok 1.4. It works similarly here. It's not as lightweight or responsive as in 1.4, but I can't complain. By default it's way on the left, with the playlist way on the right and the context view in between, but in later version of Amarok you can change the order of the panes.

I'll call this a tie even though you have to fight for it in Amarok.

Sorting the playlist

Songbird has a bunch of columns with column headers. To sort things you click the headers. Note that this is how Amarok 1.4 worked. This is how every program in the universe works.

In Amarok you have drop-down menus that you can add and remove with buttons, and you pick sorting criteria from that list, left-to-right in order of priority. This is clumsy. According to the devs' blogs this part of the GUI is a work in progress, which is fine, maybe it'll improve.

But note that the design of Amarok's playlist fundamentally limits the ways you can sort it. There have to be some magic GUI controls floating up top, disconnected from the playlist. You aren't going to get a bunch of column headers that you can click because the playlist isn't just rows and columns. Each song in the playlist can take up more than one row and there are grouping-headers interspersed. This is painful and I imagine it's always going to be painful.

Playlist readability

There are no labels in the Amarok playlist to tell you what information you're looking at in the playlist. I initially customized my playlist to show disc number and track number. Doing so, you get a bunch of numbers. What do the numbers mean? At a glance you can't tell. Am I looking at an Artist or Composer? Play Count, or Score? Does that big empty space mean my song is missing a Genre or missing a Year?

In Songbird the columns have headers.

Playlist length

How many songs can you squeeze into the playlist vertically? This is an important metric for me. I want to be able to find a song quickly without scrolling through a list for a year and a half. Sure I can search, but search doesn't replace my eyes in all circumstances.

In Songbird even with those filter panes above the playlist it fits a few more songs than Amarok. You can turn off the filter panes entirely, in which case you can display tons more songs in Songbird than in Amarok. Songbird wins.

In Amarok, by default the playlist has a bunch of multi-row header stuff mixed into the middle of your playlist to show artists and album names and cover art. You can make the headers not take up so much room (or turn them off entirely), in which case Amarok gets pretty close to Songbird. You'll just do without album or artist names. Unless you can manage to cram them into the playlist in the rows beside the track titles.

Which brings us to our major problem...

Playlist customizability

In Songbird you can right click and add and remove columns. You can drag-and-drop columns to rearrange them. You can drag the edges of the columns to resize them. It's simple and it works. This is how Amarok 1.4 worked too.

Amarok fails hard in comparison. In Amarok to customize the playlist you go into a special dialog. You pick your components from a horizontally-scrolling list of huge icons. Then you arrange them into rows.

You can put two or more items side-by-side in which case they become multiple columns on that row in the playlist. Kind of. To control the width of the columns, you hover over that component in this magical dialog, and a weird circular icon appears. When you click it, a drop-down appears with a microscopic slider at the bottom that looks like it was pulled from KDE2. This is the only way to resize columns in the playlist. Here's a screenshot.

What in the world is this? What are simple drag-and-drop operations in Songbird and every other application ever made, are buried in this cryptic dialog under non-standard controls in Amarok. I've been using KDE and Amarok for a long time and it took me a good couple minutes to even figure out how this thing works.

I think the widths are percentages and have to add up to 100%, I don't even know. The slider is so small that if you drag it one pixel it usually jumps 5-10%, so it's nearly impossible to get anything to look nice. And when you resize the Amaork window later, the columns don't resize sanely; some fields are smashed into each other or overlap as others take up too much space.

Maybe this will all be fixed before the next release; I realize I'm looking at bleeding-edge pre-release software. But this whole idea is so fundamentally broken I don't know how it's going to be salvaged.

I've heard many times that "You can make Amarok 2 look like Amarok 1". No you can't. You can tediously stuff lots of information into the playlist so that it approaches the level of info you could easily and painlessly get in Amarok 1.4. But it will neither look nor act anything like Amarok 1.4. Resizing the playlist will break things. Nothing is labeled. Nothing is easily customizable.

Playlist consistency

Songs in Amarok are grouped into albums by default. If you have a song that doesn't belong to any album, it's displayed completely differently than a song that does. You can alter this in the scary playlist editor dialog mentioned above, under the "Single" tab (as opposed to "Head" and "Body" which control the "grouped" songs). Sound confusing? It is. Needlessly so.

In Songbird songs are displayed the same whether they belong to an album or not, since the play list is just a list of songs. This seems like it should be a no-brainer.

Playlist: overall

Amarok 2's playlist is unique, imaginative, and I'm sure it's a clever bit of code. It's also nearly unusable.

Why can't we have a grid of rows and columns? There's a good reason so many apps use such a control. It's simple and familiar and it works. I'm open to learning something new if it's an improvement. Amarok 2's playlist is not an improvement. Why can't the playlist be a simple list of things to play?

There's nothing about QT4 preventing someone from making a good GUI. Look at ktorrent.

The little things

Say I want to email or IM someone and ask them if they like some artist, whose name happens to be Japanese and difficult to type on my gaijin keyboard. How do you copy and paste the name of an album or artist in Amarok 2? In Amarok 1 you could just click any field in the playlist twice, and it'd let you edit or copy/paste that field inline. Same in Songbird.

In Amarok 2, you have to right click and go into the Edit Song Details dialog, and do it from there, then close the dialog. A tiny step backwards.

How do you change the rating of a song? In Songbird you click the stars in the playlist beside the song you care about. Same in Amarok 1.4.

In Amarok 2, you can display the stars for each song in the playlist, but to change the rating you have to click in the context pane. (So if you dislike and therefore hide the context pane, you're screwed.) Clicking in the playlist does nothing. A tiny step backwards.

All of these tiny steps add up.

Extras

So how well does each player serve as a web browser?

This seems like a ridiculous question, except that both really do try to be a web browser. You can open song lyrics and wikipedia pages and such things right in the music player. I find these features nearly useless. Lyrics are nice when it works (which isn't often, for the music I listen to), but browsing Flickr? Really? Does someone really use this?

Songbird does use its inline browser in a nice way to let you browse and install addons from the Songbird website, and Songbird has a cool feature to let you rip audio files from web pages. Amarok doesn't have these, but I don't hold that against it. I can easily live without any of this stuff.

So in Songbird you have an embedded Mozilla engine. It's hidden behind a tab. You can just avoid opening such a tab and then you don't see it. You can even hide the tab bar itself. Victory.

In Amarok the browser stuff inhabits the middle context pain. The size is limited for this pane, which means information is crammed into the available space, which greatly limits its use. It's also clumsy and difficult to turn components on and off, and I can't figure out how to resize them. The context view itself is either in your face, taking up most of your screen real estate, or it's gone and not easily retrievable.

Note in the screenshot, how in Songbird the lyrics pane is big enough to display all the lyrics, yet small enough not to be annoying. You can also hide the pane (as you can hide every other pane in the GUI) via that tiny button with an arrow under the pane. Amarok's lyrics widget is either too big (if you let it occupy the whole content pane) or too small (if you want to have anything else in the pane with it).

Note that Songbird's lyrics pane is added via an addon. It's a completely optional part of the GUI, which is nice. (Note that Songbird also mangles certain text in the lyrics due to encoding problems, which is a point against it.)

Wasted screen real estate

See that tiny little red icon in the bottom-right of Songbird? That's the Last.fm integration. It's all hidden in a little square of pixels, out of my face, not sucking up screen real estate. This is a common theme in Songbird. Everything is tiny and/or hideable. Tiny is good.

In Amarok everything is huge and round. Even ignoring the content pane, there's white space everywhere. There are buttons strewn all over the interface, like the seven in the lower right. Export Playlist? Does that really need a button? And other buttons appear (and disappear) in awkward positions at the top. "Add Position Marker"? Does this really deserve a prominent button right beside the main play controls?

And yet things I do need buttons for, such as changing the Skip or Repeat options, have no buttons. This is possibly the first player I've ever used that doesn't have a button for Skip and Repeat.

GUI skinning

Songbird is skinnable. So was Amarok 1.4, to a degree. Amarok 2 isn't and I don't know if it ever plans to be. I can live without skins but it's nice to have the option.

Desktop environment integration

As one might imagine, Amarok wins here, if you use KDE, as I do. Global keyboard shortcuts are already set up, it sits in the system tray, and there are nice Plasma applets you can put on your desktop.

Songbird meanwhile does not play nice. First, it has window hints set to hide its border and window title bar, and it tries (and fails) to manage windows itself, giving your window manager the middle finger. I had to force kwin to display the title bar and border just so I could resize certain dialogs that were otherwise broken.

Then, Songbird doesn't sit in the system tray. You can force it down there via alltray, but right-clicking the icon doesn't give you Play/Pause/Next/Back options like in Amarok.

There are no global hotkeys, but you can easily fix this in KDE too because you can set your own global hotkeys to do anything, and Songbird has a commandline interface to let you do what you need. It's still not as graceful as Amarok.

So KDE thankfully rescues Songbird from its own deficiencies, which is nice. Except...

Playing music

Ah, Songbird. Why oh why won't you work? Songbird uses gstreamer. In my years of bouncing between Gnome and KDE and XFCE and others, and using various distros, gstreamer has never worked for me consistently. I can get Songbird to play music, but Flash videos stop producing sound while Songbird is running. This is a known and reported bug, I'm not the only one. While Songbird is playing, other KDE apps randomly produce sound or not depending on the phase of the moon.

Amarok actually plays music, so I'm stuck with it. Unless I go back to Amarok 1.4 which I may still do.

Conclusion

Songbird is pretty good. If I can figure out how to make gstreamer play nice, I'll probably use it.

Otherwise just consider this yet another voice in the wilderness wishing for a Qt4 version of Amarok 1.4. There was nothing wrong with it, from a user's perspective. I'm not the first wishing for this, and won't be the last. If I had a couple years to get good at C++ and a team of programmers to help, I'd probably try it myself.

Why write an 87-page essay about the GUI of a music player? Because Amarok 1.4 was a really good program. I'm a programmer and I appreciate a good program. Songbird has a pretty darned good GUI too. It's painful to see Amarok 2 going in this direction.

KDE4 Konsole Kolor Skheme Kdownload

Sun, 12 Apr 2009 20:31:19 -0700

I put a color scheme for KDE4's Konsole up for download. From a cursory glance I think KDE3 and KDE4 color schemes are the same format, but I haven't tried it.

Also I know I'm not the first to say it, but all of the K's in KDE program names are a bit annoying after a while, aren't they?

KDE

Sat, 11 Apr 2009 15:59:45 -0700

Bzorp - A KDE4 Konsole color scheme.

Vim cterm colors

Sat, 04 Apr 2009 12:48:06 -0700

Note to self. Vim color schemes that only set cterm colors don't work unless you export TERM=xterm-256color in your terminal emulator. Konsole in KDE4 seems to default to plain xterm. Took me a half hour to figure out why my color scheme wasn't working in Konsole.

Trying Arch

Wed, 01 Apr 2009 00:52:41 -0700

Thanks to all who gave helpful suggestions about running VMs in Gentoo. The main reason I wanted a VM was to play around with some other distros and see what I liked.

But then I got to thinking, and I realized that I have over 250 GB of free hard drive space sitting around. So I made a new little partition and per Noah's suggestion, threw Arch Linux on there.

I'm fairly impressed so far. The install was easy. In contrast to the enormous Gentoo handbook, the whole Arch install guide fits on one page of the official Arch wiki. Why doesn't Gentoo have an official wiki? I know there are concerns over the quality of something anyone can edit, but in practice is it a big a deal? Is it worth the price of sending users elsewhere, to potentially even WORSE places, when the Gentoo docs don't cover everything we need? The quality of the unofficial Gentoo wiki is often very good but sometimes hit-or-miss, and it also sort of crashes and loses all data without backups every once in a while.

The Arch installer is a commandline app using ncurses for basic menus and such, which is more than sufficient and a good compromise between commandline-only and full-blown X-run Gnome bloat. The install itself went fine, other than my own mistakes. I'm sharing /boot and /home between Gentoo and Arch so I can switch between them easily. During the install Arch tried to create some GRUB files, but they already existed care of Gentoo, so the install bombed without much notification and I didn't notice until 3 steps later. No big deal to fix, but I'd have liked a louder error message right away when it happened. The base install took about 45 minutes.

Another nice thing is that the Arch install CD has vi on it. I didn't have to resort to freaking nano or remember to install vim first thing. A mild annoyance to be sure, but it bugged me every time I installed Gentoo.

After boot, installing apps via pacman is simple enough. KDE 4.2 installed in about 15 minutes, as you'd expect from a distro with binary packages. I found a mirror with 1.5 Mb/sec downloads, which is awfully nice. Syncing the package tree takes less than 2 seconds, which is also nice compared to Portage's 5-minute rsync and eix update times. Searching the tree via regex is also somehow instantaneous in Arch.

Oddly, KDE didn't seem to pull in Xorg as a dependency, but other dependencies worked fine so far. Time will tell how well this all holds up. Most package managers do fine on the normal cases but the real test is the funky little obscure apps. pacman -S gvim resulted in a Vim with working rubydo and perldo, which means Arch passed the Ubuntu stink test.

Another nice thing is that KDE4 actually works. My Gentoo install is years old and possibly crufted beyond repair, or something else was wrong, but I have yet to get KDE4 working in Gentoo without massive breakage. Possibly if I wiped Gentoo and tried KDE4 without legacy KDE3 stuff everywhere it'd also be smooth.

Regardless, it all works in Arch. NVidia drivers and Twinview settings were copy/pasted from Gentoo, and compositing all works fine. No performance problems in KDE with resizing or dragging windows, no Plasma crashes (yet), no missing icons or invisible notification area. QtCurve works in Qt3, Qt4 and GTK just fine. My sound card worked without any manual configuration at all. My mouse worked without tweaking, including the thumb buttons. Same with networking, the install prompted me for my IP and gateway etc. and then it worked, no effort.

I've mentioned before, but one nice thing about Linux is that if you have /home in its own partition, it's no big deal at all to share it between distros. With no effort at all I'm now using all my old files and settings in Arch, and I can switch back and forth between this and Gentoo without any troubles.

So we'll see how this goes. So far so good though. Arch seems very streamlined and its goal is minimalism, which is nice. Gentoo has not felt minimalistic to me in a while. Again, may be due to the age of my install, cruft and bit-rot.

Conky Goodness

Sat, 21 Mar 2009 18:52:59 -0700

I uploaded a new screenshot:

The conky with weather pictures in it is stolen from RAMC's conkyrc which you can find on the Gentoo MB and also apparently here. There's a python script there to fetch and display weather info.

Whoever thought up the idea of making a font that consists of little weather pictures was pretty clever. Whoever thought up making a font that consists of Linux distro emblems has a bit too much time on his hands.

Oddly enough, Unicode itself includes glyphs for weather symbols. e.g. this is Unicode character 2603:

☃

If your font supports it, it should show up as a snowman. If your font doesn't support it, it may show up as an ice cube.

KDE 4.2.... so close

Wed, 25 Feb 2009 16:31:13 -0800

I tried KDE 4 (again) on Gentoo last night. It's unmasked in the tree so it was simple enough to install (if you're willing to use a masked Portage so you can use sets).

You can easily see improvement in KDE 4.2 compared to older versions of KDE 4. Everything generally works now, which is itself a change. Performance issues are almost gone; I can at least move and resize windows now without my system freezing. Delays in rendering popup menus are gone. All the shiny desktop effects worked right away with no hassle and everything looked great. A lot of the little nooks and crannies of previous missing features are filled in.

Some things are still not quite right though. I experienced massive stuttering in mplayer when I tried to watch a movie and do some other things at the same time. I managed to crash plasma once or twice just by resizing the main panel. I'm using two monitors and one monitor went totally blank for no reason I can determine, with only a one-inch strip of blue wallpaper at the top which was still right-clickable, while the other monitor kept working fine.

And other things are still broken beyond belief. All my system tray icons were invisible (reading the Gentoo MB apparently I'm not alone with that problem). Icons were a problem in general; random parts of the kmenu still had question-mark icons. Trying to download new themes of any sort via the "New Themes..." buttons in various system dialogs silently did nothing. When I opened Dolphin, all the menus were labeled "No Text", which was amusing. And I did manage to freeze-crash KDE4 when I tried to quit once, just like old times. Qtcurve wouldn't let me configure itself. GTK apps were themeless until I found an ebuild for a gtk-engines-kde4 ebuild in an overlay.

Installing KDE 4.2 and KDE 3.5 in parallel breaks tons of things in KDE3, e.g. the K menu is missing tons of stuff and has tons of extra KDE4 stuff that doesn't work, KControl no longer functions at all, the splash screen when you start is just a blank blue box, and so on. I'm now in the process of uninstalling KDE 4 (again) and trying to salvage my system (again).

Starting KDE 3 again after using KDE 4 for an hour, it's depressing how much smoother and more responsive it feels. I have hopes for KDE 4, it's clearly headed in the right direction, but I feel like it's going to be another year before it comes close to catching up to KDE 3.

I hope someone maintains Amarok 1.4

Sun, 14 Dec 2008 16:40:46 -0800

Amarok 2 was released on December 10th. I have KDE 4 on my experimentation laptop, so I tried it. I don't like it. Aside from technical glitches and missing features which will hopefully be added again someday, the whole idea of it is wrong.

Amarok 1.4 is good because it gives you extremely dense, detailed information about your songs. I've got 13 columns of information in the playlist pane and I look at them all. Score, Rating, Play Count, Year, Disc number, Track number... I like to see these things. I like to sort by these things. I like being able to see the bitrate of my MP3s at a glance. I'm a nerd, that's why I'm using Linux in the first place.

Amarok 2 on the other hand has a tiny little column down the right hand side to display song information. It groups things together so you don't need as many columns, but it's nowhere near what Amarok 1.4 gives you. Bad bad bad.

On the very rare occasion I want to see lyrics or something, in Amarok 1.4 they're hidden away in tabs I can ignore most of the time. This is good. The majority of my window should be devoted to DISPLAY SONGS.

Instead, in Amarok 2, half of the GUI is devoted to this center pane to display "context" information. This is bad. I don't care about browsing web sites to buy music, or browsing Wikipedia from inside my music player, or "discovering" new music. And if I did care, I would use a WEB BROWSER. A music player is not a web browser. If I want to discover music, I'll go use last.fm or some website that's devoted to it, using Firefox. If I want to see a Wikipedia article, I'll look at Wikipedia in Firefox.

Music players should play music, and web browsers should browse websites. When you have one enormous program that tries to do both, it just ends up doing both poorly. This is nearly universally true and it's certainly true in what I've seen so far in Amarok 2.

KDE 4 isn't even usable (as of KDE 4.2 beta1) and Amarok 2 fits right in, unfortunately. I hope they give us back some of the things that made Amarok 1.4 great. Or else that Amarok 1.4 keeps working for a long time.

Clojure, Qt4, memory leaks

Fri, 05 Dec 2008 00:13:18 -0800

I'm still exploring Clojure + Qt Jambi as a nice way to build GUI apps. I have some code to upload, if I can ever figure out how github works. The learning process really never ends for a programmer, does it? Not that I mind it, I actually love it. I love learning new tools and new languages. Git seems interesting and so many people say such good things about it that I almost have to learn it now.

Anyways, anyone who uses Qt Jambi should be aware of issues with memory leaks. Turns out you need to explicitly dispose of toplevel Qt objects or else they're never garbage collected. (This isn't as bad as it might be... most Qt objects aren't toplevel, they have parent objects.) I made a long-running system tray app and I noticed it slowly but steadily increasing in memory usage over the course of a week. I added a few calls to dispose and so far so good.

On that note, while Clojure is awesome and I think a lot of people's "OMG it's on the JVM, run!" reaction is unwarranted, the JVM still does seem to have some memory issues, on my system anyways. You do pay a RAM tax for using the JVM. A simple Clojure Qt4 app that just sits in the system tray and checks my email every couple seconds:

  PID  PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  TTY      COMMAND
 3282  20   0  282m  54m  17m S    0  2.7  11:08.75 pts/3    /usr/lib/jvm/sun-jdk-1.6/bin/java ...

54MB seems excessive. I need to look into ways of reducing that. I've passed in all kinds of parameters to the JVM limiting the heap size etc.; it was actually MORE than that before, which is even sadder.

One of the things that's either really good or really bad about Clojure, depending on your perspective, is that it forces you to learn Java and the JVM better. You don't need much Java knowledge to use Clojure, but it surely helps as soon as you want to interoperate with Java libraries. As much as I dislike Java, I recognize the need to have a job and acquire money with which to purchase such things as food and shelter. Java is good for that kind of thing.

Qt4 in Lisp?!

Fri, 31 Oct 2008 16:31:43 -0700

NOTE: Updated 2008-12-12 to reflect Clojure's new syntax.

Imagine Qt4 bindings for Lisp that are:

Officially supported
Thoroughly documented, with tons of examples
Cross-platform
Consistently up-to-date

Keep dreaming, right? Your first thought might be to check CLiki for some Common Lisp bindings. There is indeed a Qt project there. Except at a glance, it's listed as working only for CMUCL. And the last update was 2003. And the download link is 404'd. Oops!

But there's a link to a some QT4 bindings, CFFI style. Much more promising. Except... last update: March 2007. "Project status: dead." Never mind. There's also this and maybe a few others you could Google up, but I haven't tried them and I'm not going to.

Kudos to the people who wrote the above; providing bindings for all of Qt4 is a daunting task and it's no wonder it's not done for Common Lisp. Doesn't change the reality of the fact that Qt4 (like many other libraries) is a no-go in Common Lisp. There's nothing stopping Common Lisp from having great libraries except lack of manpower; but lack of manpower and lack of mature, tested, up-to-date libraries is still a real problem when you want to write an application today.

Enter Clojure

Luckily, it turns out there ARE Qt4 bindings that you can use from Lisp. That Lisp is Clojure, and the bindings are Qt Jambi. Many people are excited about Clojure nowadays, and this is one big reason (of many). It's hard to beat Java when it comes to libraries, and Clojure gets them all for free.

Let's try to write one of the official Qt4 examples / tutorials in Clojure and see how it goes. Keep in mind that I'm still learning Clojure, so this may be far from ideal, but it should give you a bit of a taste of Clojure and Qt Jambi if you've never seen it before.

To spoil the ending a bit: It works! In Vista and Linux (I don't have an OS X box to try, but it'll probably work there too):

Setup

To set up Clojure, follow the directions on the Clojure wiki. Be sure to get the SVN version of Clojure, because it's being developed very rapidly and is often updated many times per week. You can also check out some recent posts on Bill Clementson's blog, and this movie on LispCast which walks through setting up Clojure and Emacs/SLIME.

To make Qt Jambi available to Clojure, you may have some options. If you use Linux, your distro may make this available via your package manager. Otherwise go to the Qt download site and download "Qt for Java" for your OS. This is a freaking huge download, but it includes all the documentation and source code and plugins; all you need out of it are a couple of JAR files. There are two JARs you need, one cross-OS and one specific to your OS.

You have to put these JARs on your CLASSPATH so Clojure can find them. There are lots of ways to do this; one way is on the commandline:

java -cp qt-jambi-4.4.3_01.jar:qtjambi-linux32-gcc-4.4.3_01.jar:clojure-lang-1.0-SNAPSHOT.jar clojure.lang.Repl

There's also add-classpath in Clojure, which lets you edit the classpath while Clojure is running. I was unable to get this to work with Qt Jambi, but I didn't try very hard. In reality I just use a shell script so I can dump a bunch of JARs into a directory, and they will all be added to CLASSPATH automatically when I start Clojure.

That's it. Installing libraries in Clojure couldn't be much easier.

The Code

Here's the complete example code for download. Let's walk through it a bit. First we have to import the Qt Jambi apps into Clojure. Qt Jambi is on our CLASSPATH and available to Clojure, but we still have to explicitly import the bits of it we want:

(ns clojure-qt4-demo
  (:import (com.trolltech.qt.gui QApplication QPushButton QFont QFont$Weight)
           (com.trolltech.qt.core QCoreApplication)))

ns creates a new namespace, and provides convenience syntax to import Java classes at the same time. It can also import other Clojure files or Clojure libraries, among other things.

Note immediately how this is nicer than Java. In Java you would be writing something like

import com.trolltech.qt.gui.QApplication;
import com.trolltech.qt.gui.QPushButton;
import com.trolltech.qt.gui.QFont;
...

And so on, over and over. If you're lucky you have a bloated IDE to type those things for you. In Clojure, macros let us factor out the repetition; we name the big long path once, and pluck out the things we want. The other option in Java is to import com.trolltech.qt.gui.*, which pollutes your namespace unnecessarily; Clojure lets us succinctly take just what we want.

One thing I couldn't find documentation for is the way to import a static inner subclass of another class. To do this you have to use syntax like SomeClass$SomeSubClass. My first thought was QFont/Weight or QFont.Weight, but those don't work.

If you're typing all of this at a REPL, you now have to do:

(in-ns 'clojure-qt4-demo)

to switch to the namespace we just created. Next we set up some convenience functions:

(defn init []
  (QApplication/initialize (make-array String 0)))

In Qt4, the first thing you always do is initialize QApplication. QApplication is essentially a singleton class, and it has to be initialized via QApplication.initialize(), a static method call, before you do anything else. In Clojure this becomes (QApplication/initialize), which says to call the function or static method called "initialize" in the namespace called "QApplication". Static methods in Java become functions in a class-namespace in Clojure.

This function expects an array of Strings, which in a normal app would be commandline parameters. In Clojure we can make a native Java Array of Strings via make-array. I just pass in an empty one because I'm running this from a REPL. Note, a native Java Array of Strings is different from a Clojure persistent array, [ ]. This is a bit nasty, but necessary for Java interop. Most of the time you will be able to get by with [ ]. Next:

(defn exec []
  (QApplication/exec))

This function (again a static method call) is generally the LAST thing you do in a Qt application. It starts displaying widgets and fires up the event loop.

A gotcha here is that certain things must happen in a certain order. A Qt app looks something like this:

QApplication.initialize()
Initialize and set up all of your widgets etc.
QApplication.exec()
Either the program exits, or go to step 1 to start over.

For example if you try to exec() before you initialize(), it does nothing at all. If you call initialize() more than once, it dies with a RuntimeException. When I was playing around with this at the REPL, it was very common that I called initialize multiple times by mistake. It's often safe to swallow the exception though.

All of that bookkeeping really wants to be made into a macro. Here's a simple macro:

(defmacro qt4 [& rest]
  `(do
     (try (init) (catch RuntimeException e# (println e#)))
     ~@rest
     (exec)))

This kind of thing lets you avoid the insanity of Java, which forces you to re-type exception-handling code and other boilerplate code over and over and over. You can abstract that all away in Clojure.

Macros in Clojure are much like Common Lisp macros. ~@ is a splicing-unquote, like ,@ in Common Lisp. Another interesting thing here is e#, which is a shorthand way to create a gensym. It creates a unique symbol; this prevents our macro from stepping on the toes of any other symbol called "e".

Using this macro we can finish our simple example:

(defn hello-world []
  (qt4
   (let [app (QCoreApplication/instance)
         button (new QPushButton "Go Clojure Go")]
     (.. button clicked (connect app "quit()"))
     (doto button
       (.setFont (new QFont "Deja Vu Sans" 18 (.. QFont$Weight Bold value)))
       (.setWindowTitle "Go Clojure Go")
       (.resize 250 100)
       (.show)))))

EDIT: Updated doto's to reflect Clojure's latest syntax.

The hello-world function is pretty straightforward. It makes a button, sets up an event handler that closes our app when the button is clicked, then sets its title and font, resizes it and shows it. Note how seamless this is. Aside from all the new's and .'s, you could barely tell this was Java. It's all tasty Lisp.

Clojure has a bunch of simple convenience macros that make writing Java less painful, two of which I show here. One of the biggest problems with Java is its extremely verbose and punctuation-heavy C-like syntax. Compare:

button.resize(250, 100);
button.setFont(new QFont("Deja Vu Sans", 18, QFont.Weight.Bold.value()));
button.setWindowTitle("Go Clojure Go");
button.show();

Look how much repetition there is in the code. button.blah, button.blah, button.blah. Repetition is bad. Clojure has the doto macro which says "take this thing, and do a bunch of stuff to it" without having to retype it every time:

(doto button
  (.resize 250 100)
  (.setFont (new QFont "Deja Vu Sans" 18 (.. QFont$Weight Bold value)))
  (.setWindowTitle "Go Clojure Go")
  (.show))

EDIT: Updated doto's to reflect Clojure's latest syntax.

Another macro is .. which says "take these things and put dots between everything", chaining method calls. So instead of QFont.Weight.Bold.value(), you can say (.. QFont$Weight Bold value). Handy.

To run this from a REPL, type

(hello-world)

Verdict

This app of course is a silly toy and just scratches the surface. But in my opinion, Clojure already beats all other Lisps by providing access libraries like this one. This is one of its killer features for me. The fact that you can seamlessly and easily use any Java library from Clojure is pretty amazing.

Why would you want to run Qt4 apps from Lisp anyways? Java (and thus Clojure) already have other GUI frameworks, like Swing and SWT and AWT, so why bother with this? Well, a few reasons...

Because I can.
Qt4 has a lot of impressive features nowadays. Run this Qt Jambi example to see some of those features.
Qt's design may appeal more to you than Swing's, which can be clunky at times.
Maybe you want to integrate well into KDE. I first started exploring GUI programming in Clojure when trying to make an icon sit in the system tray, and while Swing can do this, it's a bit painful to get it to look just right. It's trivial to do in Qt4.
If I'm forced to write a Qt4 app, I'd much rather write it in a highly interactive and iterative way using Clojure than struggle with a write/compile/debug/recompile/wait-for-hours cycle. At the very least Clojure would be ideal for prototyping.
Because I can!

Verdict: Clojure rules. But Java interop is just one reason it rules. Clojure has native Perl/Ruby-like reader support for hashes/arrays/sets/regexes/etc., support for easy and safe concurrency, cross-platform-ness galore, and a much more modern feel than Common Lisp. It's being worked on by some very smart people and the community is vibrant, enthusiastic, and welcoming. It has all the strengths of Java and Common Lisp, and very few of their weaknesses.

KDE4 disaster

Sun, 05 Oct 2008 13:49:10 -0700

From reading the bug it sounds like KDE4 is getting close to being ready to hit the tree, which is awesome. Foolishly, I decided to try it early from the overlay last night. It was a total disaster. Things were crashing left and right, panels would resize themselves to be fullscreen (with hilarious results), half of my apps didn't work at all. I found three or four ways to bring down the entire X server. It took me many hours to get KDE3 running again. This is totally to be expected from installing masked packages as I did, so it's my own dumb fault, it was amusing and I wanted to get a taste.

I'm afraid it's going to be inevitably difficult or impossible to migrate cleanly from KDE3 to KDE4. I had the same problem in Kubuntu when I tried a while back. KDE is so huge and so many things link to it or interact with it that it's going to take a year to track down and remove all the cruft after the switch.

I couldn't even import my old KDE3 color schemes or Konsole color schemes into KDE4, which was surprising. QtCurve was un-configurable, dekorator didn't work, and so on. I didn't get far enough to figure out if my preferred icon themes work or not. I didn't realize they broke backwards compatibility to that large an extent, but I maybe it's to be expected.

There were other problems that were seemingly due to the lingering immaturity of KDE4. I can see all the pieces there which are going to allow people to do really neat stuff eventually. In the meantime KDE4 feels horrible.

KDE4 fonts look nice though.

Gentoo still rules

Fri, 26 Sep 2008 18:56:44 -0700

The version of akregator I have always displays article link text in an ugly dark blue, which doesn't show up well against my dark Qt theme. I can barely read an ebuild to save my life, and the KDE ebuilds are full of all kinds of odd KDE-specific stuff, but it still took me just a couple of minutes to:

Find the sources in /usr/portage/distfiles
Cludgily patch akregator to use normal text color for links (underlines still distinguish them)
Copy the akregator ebuild into an overlay, throw the patch in there and add one line to the ebuild to read it
emerge away

Et voil?, custom-patched, package-manager-managed app. Gentoo is pretty good for this kind of thing, whatever its other shortcomings. Does any other distro make it this easy to do such things? (I'm genuinely curious.)

Desktop screenshots

Mon, 01 Sep 2008 13:00:38 -0700

I've been using this theme forever and I'm thinking of changing it, so I wanted to grab some screenshots before I did. I have bandwidth to kill anyways, so enjoy my 3.5 MB PNGs.

My KDE color scheme is here, my QTCurve config is here, my Konsole theme is here, my Vim colors are here, the icons are Buuf, and I uploaded those wallpapers.

I really need to re-upload all the screenshots I took over the past 5 years. That was always one of the more popular sections of the site, for whatever reason.

KDE 4.1

Thu, 24 Jul 2008 17:29:17 -0700

I've been avoiding KDE4 for a while. But yesterday I threw KDE4 onto my laptop, because it runs Kubuntu and I don't really care if my laptop breaks.

When I first tried installing it, I accidentally got KDE 4.0 somehow. That version was massively incomplete. After I upgraded to 4.1 it was very apparent how much more work went into KDE between the 4.0 and 4.1 release.

Regardless, looking at 4.1, I know I'm echoing what a lot of others have already said, but I agree: KDE4 is nice, but it's nowhere near KDE3 quality yet, and nowhere near complete. Some issues:

The default theme is usable but bland. It's far better than some of the garish, loud, cartoony default themes KDE has had in past versions, at least. But it doesn't have a lot of life to it.
Most icons are missing or broken (showing up as "?"). This is probably due to KDE being packaged improperly for Kubuntu, or something choking during my install, but regardless, it's annoying. Given the behemoth size of KDE, I expect there will be a lot of this kind of problem for a long time. Who knows when KDE4 will be stable in Gentoo, for example. One good thing about KDE3 is that a lot of these little bugs have been worked out already.
Kickoff, the KDE launcher menu replacement, is no fun at all. There's way too much wasted space and you have to mouseover and click a million times to open anything. Same with the new-style control panel. You have the option of switching back to the old-style menu, which is a good thing.

There are a lot of funky compiz-like animations that you can enable. Transparency, desaturating or tinting or dimming windows, and fading / exploding / zooming window animations etc. At this point, given Compiz and OS X and Vista which have mostly the same things and have been out for a while, these features are nothing new or mind-blowing, but it's nice to have them built into KDE if you like that kind of thing.
Dolphin in KDE4 has some nice new features that my KDE3 version is missing, like a split-column view, and the ability to show thumbnail previews in more situations.
The panel configuration window is gone, replaced with a neat graphical WYSIWYG kind of thing. You drag the panel edges to resize it, and click some buttons to alter the justification (right, center, left). It's nice, but after playing around a bit, when I tried to resize my panel to be 100% of the width of the screen, I had a lot of trouble; I had a pixel or two between the panel and the edge of the window. That's the problem with WYSIWYG: it's not as precise or fast as just typing "100%" into a text field.

Many KDE apps aren't ported to QT4 yet, apparently. This introduces YET ANOTHER look-and-feel for Linux. Now I have to find a GTK2 theme, a QT3 theme and a QT4 theme. There are a few unified themes (qtcurve for example) that work for all three and look essentially the same, but there are only a few and the choices are limited.
With animations disabled, when I open a menu I get a second of garbage as my video card freaks out trying to render it, before the menu appears. I can't imagine what the problem is there. KDE3 never does that on the same computer.
Confusingly, deleting an icon from the desktop doesn't delete the file, it just removes the icon. Then I made a "folder view", which is a desktop applet that displays icons for an arbitrary folder, optionally filtering the folder by name. It's a neat idea. I'm unsure it's neat enough to replace the whole concept of a desktop full of files. Regardless, when I made one, it overlapped all the icons on my desktop to the point where I couldn't get it sorted out and had to remove it. What's the difference between icons directly on my desktop, and icons in a Folder View? It's very confusing to me, a long-time KDE user, so it's probably confusing to mostly everyone.
The version of KDM that comes with KDE4 looks nice, but also crashes randomly.

However, my biggest problem with KDE4 is how sluggish it feels on my laptop. KDE3 runs very smoothly, but KDE4 lags left and right, when resizing windows, opening popup menus, clicking icons to open applications, or doing much of anything. It may be I need to upgrade my video card driver (I'm not sure if mine is properly hardware-accelerated), but should I really NEED to, just to run a window manager? KDE was never what you might call "lightweight" but it seems to be even further from that ideal now.

It'll be a while before I switch from KDE3 to KDE4 on my main workstation. It looks promising and there's clearly tons of potential. But it wouldn't be my first choice of environment for getting work done at the moment.

Mmm... window management

Sat, 29 Mar 2008 18:19:21 -0700

I gave Compiz another try today after a good many months. It's in Portage and it installed easily, as did Compiz Fusion. Which itself is a change from the last time I tried it.

Compiz still never works quite right with KDE. The desktop pager and taskbar are always wonky. However there are some patched versions of kicker applets floating around which make kicker's pager and taskbar work correctly. Though I'm using KDE 3.5.9 and those apps are meant for older versions of KDE, they work fine for me.

I've been in love with kwin for a while now; it does exactly what I want. So I'm questioning whether I want or need to switch to Compiz at all. Aside from gratuitous graphical effects, does Compiz do anything kwin doesn't?

One "yes" to this question is the way Compiz lets you view and manage virtual desktops. Of course there's the infamous Enormous Rotating Cube which at this point in my life I can accept as totally worthless other than to impress people. But Compiz also has a flat desktop "wall" view which is more minimalistic and very nice.

Something I do often is throw windows back and forth between desktops. Kicker gives you a tiny little pager which you can use to drag windows around between desktops, but my 2x4 grid of desktops is far too tiny for this to be easy. I could make the pager bigger but then kicker itself would grow to monstrous proportions and hog far too much screen real estate.

Or you can right-click a window and move it to a desktop that way, but then you're almost working the dark, not quite sure what the target desktop is going to look like once this new window plonks down onto it. (And right-clicking and navigating popup menus is too slow for my impatient self.)

Compiz on the other hand gives you a huge view of your desktops, and this desktop view stays out of the way until you activate it (by putting the mouse in the corner or by hitting a key combo), which is exactly what I want.

You can drag and drop windows between desktops on that thing. You can also easily see which apps are open on which desktops, something that a tiny little kicker pager never quite conveys. And it looks as good as any fruit-based desktop OS, which it likely is copied from to begin with.

Compiz actually does have quite a few nice features like this that can improve your window managing enjoyment a bit. Compiz also has a lot of incredibly annoying and distracting features. The good thing is that you CAN disable the wobbly windows and rotating cubes and other distractions. You can set windows to gently fade in and out of existence rather than explode into giant fireballs. You can disable the silly window opacity and motion blurring plugins. Yeah you can make it snow on your desktop and have your tooltips beam onto your monitor like Star Trek, but you don't have to.

Compiz also has a nice rule-matching engine to let you manage window placement, size, stickiness, etc. based on window names or classes or other attributes. It's not quite as easy to configure as kwin but it's usable. Compiz lets you configure shortcut keys for everything too, which is essential for me.

KDE rules

Thu, 07 Feb 2008 22:42:21 -0800

A few short years ago the majority of apps I used were GTK2 apps. I alternated between Gnome and/or XFCE4 regularly. Compiz and Beryl came out and they were all gconf'd and whatnot so it was more Gnome. There was Gaim, Firefox, I think Thunar for file management, Gvim, GIMP, and so on.

It's strange when you're so immersed in your own world that you almost forget that another world exists. I kind of had in the back of my mind that KDE was probably dying out there somewhere and that all the KDE apps were just clunky crappy versions of GTK apps. This is what happens when you go a long time without using them. Eventually I gave KDE another try around a year or so ago, and I haven't looked back. I've mentioned before some of the reasons I like KDE. (The window manager in KDE actually manages windows, for one thing.)

Today I found another reason. Interestingly, lately more and more GTK apps I thought were indispensable are being sniped by QT apps. Not KDE4 apps either, I haven't installed KDE4 and don't plan to for a long while. Just old mature QT3 apps. Today on a whim I tried Kopete and much to my surprise I find that it's a nice alternative to Pidgin. Last time I tried it years ago it was really not a lot of fun to use, but it seems to have matured. It's a lot more customizable in look and feel than Pidgin, almost Adium-like.

Lately also I've taken to using Akregator for RSS feeds, and again, I'm largely impressed. It sits in the taskbar unobtrusively, and overlays a number on its icon indicating how many new feeds there are. You can then view them in what appears to be an embedded Konqueror tab, or in an external browser, depending if you left-click or middle-click. Embedded view works fine for the things I RSS for (webcomics and geek blogs).

I've even given up urxvt, which I'd used for many many years, for Konsole. KDE apps tend to be loaded with features, but also tend to be loaded with ways to disable all of those features and keep the one or two you actually want. Konsole is a good example of that. You could barely tell that my Konsole window isn't a lightweight terminal, until you right clicked it and got a billion options. No menubar, no statusbar, no tabs, no scrollbar if I don't want one (but I do). And under the hood you have sane font selection dialogs rather than screwy xft:strings:of:crap or -*-*-*-*-font-*-*-**-*specs-**-- no one can read. You can turn on/off visible or audible bell via a menu selection. You can save/load color schemes rather than waste endless amounts of time hacking of .Xdefaults. You have session management, pre-set standard row/col sizes, selectable word boundaries for double-click-highlight, etc. etc. etc. All those features only if you want them, otherwise go ahead and pretend they don't exist. It has everything you could want and more, yet it runs just as fast (on my machine) as any other terminal, and it looks identical.

Same for Kopete actually. My Kopete contact list has no toolbar, no menubar, no statusbar, nothing but a window frame with people's contact icons in it. And you have four or five different ways to display those icons. KDE somehow has some reputation for being bloated or having a bloated interface, but I find just the opposite. It has an interface you can make exactly as bloated or non-bloated as you want at any given moment.

Had I not blindly tried KDE one day I would never have realized how nice it all was nowadays. Sadly this train of thought leads me to the conclusion that I should blindly try Gnome again sometime soon. How depressing.

Once someone ports Firefox to QT and revives Kvim I'll be set. I'm sure that'll happen. Any day now. May as well start holding my breath.