The wolf is looking mighty good. There are obviously still quite a few missing features, rough edges and things that make it crash (it is pre-alpha software, after all). But it plays music, and it looks good.

Edit: I’m not an Amarok dev. My entire contribution to Amarok has been a single three-line patch (and that was to the Plasma-based part of it). I’m just a bleeding-edge junkie.

I decided to post this after reading Adriaan’s blog on licensing.

My editor of choice is vim. It has a steep learning curve, but once passed it allows speedy editing. It has more features than I have any hope of discovering, let alone mastering. I’ve more than once wished I had a simple way of doing something, then accidentally stumbled across just such a feature in vim.

All this is besides the point, however. I’m not here to convince you to use vim if you are currently happy with Kate or Emacs (or any of the dozens of other editors out there). For those that do use vim, however, kdesdk has a very handy vim script: kde-devel-vim.vim. Simply copy it (or create a link) from kdesdk/scripts/kde-devel-vim.vim to ~/.vim/plugin. Or put a line like source ~/src/KDE/kdesdk/scripts/kde-devel-vim.vim in to your ~/.vimrc.

After this you get several neat features. One of them is that spaces at the end of lines, and all tabs, are marked with a dot, so you can see excess whitespace or tabs where there should be spaces (if you are following the KDE coding style). It has a few helper functions that automatically adjust spaces around parentheses and insert braces in the correct place depending on the coding style of the module you are working on.

All this is very useful, but why did Adriaan’s post trigger this one? Well, I discovered a few more useful features it provides recently. If you type ,i, for example, it inserts include guards in the file you are editing based on the file name. ,h will switch between the header and the main cpp file, and ,p will do the same for the private header and the implementation file. And, incredibly usefully, there are similar keysequences that insert license headers.

You need to do a little bit of set-up for this. You need to create some files in your home directory. GPLHEADER should contain the text to insert for a GPL header. Such as the following:

/*
 * Copyright 2008  Name <email@domain.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor,
 * Boston, MA  02110-1301  USA
 */

This will be inserted at the top of the file when you type the sequence ,lg. Likewise ,ll will insert the contents of ~/LGPLHEADER, and ,lm will insert ~/MITHEADER. The script is trivial to extend to do the same for BSD headers, for instance.

I was asked for screenies…

I’m using KMail 1.9.50, and I love it!

There’s still the odd quirk hanging around, such as not saving expire settings, but on the whole it’s a pleasant experience. And I love the Oxygen theme.

There are various improvements over KMail from KDE 3, as well. For example, threading is specified on a per-folder basis - so you can disable threading on lists where people abuse it (such as my college mailing list, where people send emails to the list by using reply-all on a previous email) or where you don’t want to look for emails by thread but by date (such as sent-mail), but enable it on something like kde-core-devel.

It has a very weird interaction with the plasma system tray, though. Having started KMail, sorted through a bunch of emails and quit it again, my system tray looks like this:

I’m starting to get really cheesed off with mail clients.

I’ve been using KMail for some time, and I love it. It does everything I want it to (well, almost - virtual folders would be fantastic, but I hear rumours that they are on their way…). Unfortunately, my KDE 4 setup first of all decided it didn’t want to run any KDE 3 apps, and when it changed its mind KMail just stopped working. It wouldn’t do anything that involved talking to a mail server (including setting up an account, since that involves checking the capabilities of the SMTP server).

I went for mutt for a while (which was what I used when I was a console junkie). But I’m addicted to GUIs now, and mutt didn’t understand KMail’s directory structure. And I didn’t have anything to tell me if a folder other than the main inbox had email in it.

Currently, I have a dovecot IMAP server running. This works quite well in that there are no directory structure problems. A bit of procmailing brings back the filtering I love so much (although I have to run fetchmail manually each login as KDE 4 doesn’t seem to support autostarting apps by symlinking them from the Autostart directory).

I decided to go with Mailody. On the whole, it’s quite good. I like a lot of the interface. I have a few gripes: next-unread doesn’t, in fact, go to the next unread message. It scrolls down the current message. Only when you are at the end of the current message does it skip to the next unread message. This is quite irritating on things like kde-commits.

Not only that, but it occasionally tells me “the SMTP server does not support authentication” when I try to send an email (this is nonsense - the SMTP server requires authentication). The solution is to save the message, close Mailody, open it again and re-send it.

Oh, and Mailody only supports one account, so I’m back to webmail for my university account.

“All mail clients suck. This one just sucks less.” -the creator of mutt, circa 1995

[edit] It’s KMail from KDE 3 that’s decided to stop working, not KMail from KDE 4 [/edit]

Just to say that a few Plasma bugs/wishes are likely to be recurring themes on bugs.kde.org. Rest assured we know about them.

• Background image sometimes doesn’t load, and the background preview in the “Configure Desktop” dialog doesn’t always update. Fixed for 4.0.1.
• Applethandles don’t always disappear when you move the cursor off the applet. This is due to a deficiency in the Qt Graphics Canvas hover event handling. We’re looking into either a sensible work around or for TrollTech to fix it. We have a 99% workaround for 4.0.1 (see aseigo’s comment on this post).
• No panel configuration (apart from adding & removing applets). It’s coming.
• If your desktop crashes (or you kill it with killall plasma - handy tip: use kquitapp) part way through your first run, only part of the config gets saved and you no longer have a panel. Fixed for 4.0.1 (see aseigo’s comment on this post).

Planet KDE already has more than enough release banners, so I’m not going post another one.  I will, however, say one thing: of the complaints that I’ve seen levelled at the 4.0.0 desktop so far, most are already fixed for 4.0.1.

I’ve occasionally been posting bugs.kde.org stats for Plasma on #plasma.  So here are the latest for the planet:

Total bugs filed against plasma, excluding duplicates: 195

Currently open bugs for plasma: 62

Of which wishes: 28

Leaving “real bugs”: 34

The “open bugs” totals have been pretty steady over the past few weeks, while the total number of reported bugs has been steadily increasing as more and more people use the desktop.

Just remember this when you complain about problems with the desktop: if you don’t file bugs, they won’t get fixed!

(PS: for crashes, please install the *-dbg or *-debug packages before you file the report and reproduce the crash to get a useful backtrace if you can.  If you can’t, don’t worry - a detailed description of the problem without a backtrace is better than us not knowing at all.)

There have been many complaints about how resizing and rotating happens on widget handles. Hopefully most of those should be assuaged with the last few commits I’ve made.

Here’s what you used to get if you rotated an widget, moved off the widget (so the handles disappeared) and hovered over it again:

You’ll notice that the handle isn’t rotated, even though the widget is. Also, you’re expected to resize and rotate with a single button (which is the rotate symbol, despite the fact that you’re much more likely to want to resize than rotate the widget). There were also odd quirks with rotating where it would jump about when you released the mouse button or moved off the widget; and if you rotated it, released the mouse button then started rotating again (without leaving the widget), the widget would jump back to its “unrotated” state and start from there.

Well, now all that’s fixed:

There’s a separate resize button (it still maintains aspect ratio by default, because most widgets have an “ideal” ratio that they start with, but you can freely resize it with CTRL). The rotate button works as expected. And the handle starts at the same rotation as the applet.

Edit: A couple of things I meant to mention and forgot - this will be in 4.0.1, and the jagged edges do exist in the original, but are made worse by the scaling of the images (click on them to get full size).

Until this morning, resizing plasma applets meant maintaining the aspect ratio. There was no way to make them wider without changing the height, or vice versa, without manually editing the plasma config file.

Well, if you are running trunk, you can now freely resize applets by holding CTRL while resizing. This won’t make it to 4.0.0 (which has already been tagged), but all the current fixes in plasma should be backported to the 4.0 branch before we move on to 4.1 development. So it should make it to 4.0.1, which is good as it’s quite an important feature for certain plasmoids.

Also, I’ve greatly improved the Now Playing applet:

The text size will stretch to fit the height of the applet and, if the text doesn’t fit the width of the applet, any excess text will be ellided:

This is why I needed free resizing…

If you’re reading this post at randomguy3.wordpress.com, the title of this post will display as “Planetary Exploration”. If you’re reading it at planetkde.org, the title of this post (and, indeed, every other post by me) will be “randomguy3″.

You may have noticed this with several other planetary bloggers, by and large people who use WordPress. But not everyone who uses WordPress has this issue - Wade Olson, for one, gets his post titles displayed on Planet KDE.

The common theme, as far as I can see, is avatars. If you have an avatar, a <media:content> tag is placed in each item of the feed linking to it, with a <media:title> subtag. The Planet appears to pick this up (the title for the avatar) and use it as the title for the feed item (ie: the post).

I can’t check this for sure, though, since WordPress won’t let you remove your avatar, only change it.

I suspect using /feed/atom as the feed url (rather than /feed) will fix the issue as well, since that doesn’t make any mention of the avatar.