KDE Telepathy has quite a lot of work left to do, so I'm running a day to get more people involved and help hacking. I intend to focus purely on the System Settings module where people set up their IM accounts.

The interface needs a lot of UI attention and tidying up so we need people of all skills and interests.

Each protocol (MSN/Yahoo/etc) needs it's own user interface, this is a fairly straightforward task, but there are a lot of protocols Telepathy supports!

On Saturday join us in #kde-telepathy on freenode we'll help make sure you're set up with the current source, and you can get hacking! Hopefully we can get the entire system settings module nearly finished by the end of the weekend.

Below are some screenshots of the current state (which aren't much to look at) hopefully this time next week I'll be posting something much nicer.

"max-width:100%"),"");
?>

"max-width:100%"),"");
?>

The Autostart folders in KDE/Linux

When you first log into your KDE session a large amount of application/system tray programs are automatically started. It can be quite hard to work out who is starting what, and in particular to make changes.

Applications are started by a .desktop file in one of the autostart directories.

The following folders are all checked for .desktop files:

• ~/.kde/Autostart
• ~/.kde/share/autostart
• ~/.config/autostart
• ~/.local/share/autostart
• /etc/xdg/autostart
• /usr/share/autostart

I don't really know why we have so many.

Anything inside the /usr/ or /etc folder will have been installed by your distribution.

Disabling Autostart Files Provided By Your Distribution

KDE provides a wonderful tool in systemsettings ("Startup and Shutdown" -> "Autostart") for managing your personal autostart services (in either of the .kde directories) however it doesn't cover systemwide autostart scripts provided by your distribution packages, or created by the gnome apps.

Sometimes however it can be useful to override your distribution autostart preferences, for example I don't like having the printer-applet running as I don't own a printer, but it seems a shame to uninstall it in case I need it.

The Wrong Way to Disable Application Autostart

Contrary to what most people actually do, the correct way to disable service is not to delete the files your package manager has installed. There are a few reasons for this:

• It will affect all users on the system
• It's an abuse of your root access (which you may not have)
• As soon as the package upgrades, the file will be restored and it will come back to autostarting again - which isn't what you want

The Right Way

The correct way to disable a package installed is actually to copy it to your personal autostart folder. Anything of the same name in ~/.kde/share/autostart overrides the .desktop file in the default installations. Once we have copied the .desktop file we can make changes.
Add the following line to the .desktop file you have just copied:

Hidden=true

A personal opinion

I think everyone would agree we could do with normalising how many autostart folders we have, which would be easier to do by us losing our kde specific ones and following freedesktop standards.

I also wonder if disabling systemwide autostart services in the manner listed above could be handled, it seems do-able to me. If someone comments approving it, I'd try and see if I can make a patch.

I'd also like it if developers really think hard about whether something actually needs to have a system tray icon constantly loaded on startup or whether it can be an easy to find seperate application for a user to run. It provides less visual clutter as well as a faster initial load time.

References

The Freedesktop Autostart Spec - note this doesn't actually cover the real state on a Linux box, only what it should be doing.

As someone who posts to kde-apps.org repeatedly one of the biggest cause of problems I encounter is users missing out the flag '-DCMAKE_INSTALL_PREFIX=/usr' when running cmake.

The current situation is somewhat ridiculous, applications default to installing into /usr/local, which is in the user's application path but not in the KDE path. The result of this is an application that can load (because it's in the executable path) but not be able to find any of it's resources.

You can check your kde path by running:

kde4-config --path data

The best solution to this is to add '/usr/local' to KDE's path, this allows you to install KDE apps separately from where your package manager installs applications and save you having to worry about compile options.

To do this, set your /etc/kde4rc file to the following:

[Directories-default]
prefixes=/usr/local

Today I got a patch for a piece of software I released almost a year back and had totally forgotten about

The patch adds support for setting the broadcast address in KWakeOnLan so that it is possible to make it work over a VPN or potentially any internet connection.

It's the first time I've had someone submit a patch for a piece of software that I'd written exclusively till that point, and it feels really good - it shows people are using your software enough to want to edit it

So thanks to Sebastian Kloska I present KWakeOnLan 0.2 + (a few interface tweaks by me)

The current tool bar system in KDE is a bit dated, the window is filled with lots of buttons, and reordering items isn't all that intuitive. It's not all that 'user friendly'.

The existing toolbar configuration

My suggestion

I've made a working prototype of a new click and drag solution. Essentially it's a very similar toolbar configuration scheme to that of Firefox. A lot of the code required already existed in KToolBar, it just wasn't being used. This demo only really has changed to the toolbar editing dialog. If this is accepted by kde-usability people, I'll try tidying it all up, ready to be a patch to show to the kdelibs guys.

Below is a screencast showing my prototype mockup:

Ogg vorbis video

Source code