David Edmundson's Web Log

We're making the next magic release of KDE Telepathy next week, now would be the perfect time to help test and squash any final bugs before our second milestone release.

Included in this release:

• KWallet integration
• Auto Away and Now-Playing status messages
• A contact plasmoid
• Hundreds of bug fixes and other minor improvements

Compilation instructions are available here.

If you have any problems check the troubleshooting page, also I will be around most the weekend in #kde-telepathy if you have any further questions or difficulties.

We are still very much in a development phase, there are still plenty of rough edges, and we are still not as feature complete as other IM clients out there. However things are vastly improved from 0.1.

Note:
There are daily-build packages available for SuSE, but do not use the currently daily-builds from our Ubuntu PPA as they are currently broken and as such you will not be able to connect any account.

What is padding?

Padding refers to the space between a border and an item, and between items. For simplicity we'll call padding, margins and spacing the same thing.

There are a few basic rules to follow:

Leaving room to breathe

If text or an icon ever touches the border it immediately looks wrong, visually you can't tell if something has been cropped, and it just looks generally messy. Anything less than 3 pixels looks cramped.

Being even

The amount of padding on the top and bottom should generally match so things look centred, and with even spacing each side. There are exceptions to this rule, but generally only when it is a conscious decision.

Consistency

This is one of the hardest ones to sort out. Consider the following two buttons. Both of these are perfectly valid, and obey the two rules above, and viewed on their own either of these are great. The problem is, if you put these side by side it looks wrong, one has a smaller icon and has larger spacing between the icon and the text - there's an immediate lack of consistency and they both end up looking out of place.

Of course all of these "rules" have exceptions, there are reasons when you want to be different or need to be, but this should only be the result of active decisions rather than accidents, which is what most issues appear to be.

Avoiding Mistakes

Widgets

In general we don't have this issue with QWidgets, widgets are in layouts and Qt adds appropriate margins (of 4 px on each side). However if a developer adds a custom paintEvent on a widget, manually adds fixed spacers to their dialogs or nests QWidgets with layouts this all needs thinking about again.

Below is a screenshot from a dialog in KDE with some straight lines drawn on.

Hopefully with the lines issues become apparent:

• The word "Search" and "Calendar system" do not line up. They're at the same level of indentation, therefore they should line up.
• There is a different level of spacing between the top header and the second header. Because both headers are in the same font, they 'must' mean the same thing, and therefore should have identical levels of subsequent padding. If one is meant to be a full title, the other a subtitle they should not be using the same font. (This is arguably a fault in KTitleWidget always adding a large space.)
• Having any indentation on the form for the Calendar or Holidays section is inconsistent with (most) other KDE settings which don't indent after a title.

I think some of this can be sorted by making some special classes in kdeui which inherit from QLayoutItem and are at various fixed sizes to match normal indents and spaces. These needs to be exported to QtCreator to be useful. Rather than adding fixed spacers and setting them to 20px, it would be more consistent if people added a KStandardIndenter which made sure everyone used the same indents as defined here in KDE HIG Guidelines.

Another thing to watch out for is when making your own custom widget (in this example KHoliday::RegionSelector) to remove any margins in your widget otherwise you get double margins when it is actually used.

Plasmoids

With plasmoids it becomes an even bigger more common issue. Whilst some applets will use plasma layouts, with QML a lot more people are using direct anchors to position relatively to parent items. This means there is no code doing it for you and it's very easy to be inconsistent.

Here are some KDE examples; one good, one requiring some work.

The example on the left has no gaps round the outside and the text is not evenly spaced. There are three different sizes between the frame, the two lines of text and the bottom. There should be an equal gap between the top of the box and the top of first line of text and the bottom of the second line of text and the bottom of the frame.

The image on the right has a gap of 5 pixels between top text and border whereas the one on left only has 2.

Note how on the other example on the right has a large gap on the bottom yet still looks ok. This is because there is still a consistent spacing between the first line of text and the second and there is a big enough gap at the bottom that it looks deliberately lined up with the first line of text, rather than looking like it's floating in the middle of nowhere.

The big issue is the consistency if everything looked like the example on the left it wouldn't be too bad, but having a mix makes things worse.

Because the main is inconsistency rather than being right or wrong, this is a problem that needs to be solved with communication as much as code.

Another task that's worth doing is using the kwin zoom function and checking the plasmoid out more closely. If you can make it look good zoomed in 3x it's going to look great at a normal zoom.

Are single pixels really that important?

Yes! I think most people (myself included) don't notice the actual padding issues but see it and think "urgh, that's ugly" but can't immediately identify why.

As an example of how noticable the most minute detail is mouse over the close button in krunner, once someone points it out you can see the cross is ever so slightly shifted to the left. That's something that's out by only half a pixel! That's obviously being overly pedantic, but it shows how when we have things out by 4 pixels or more (like the difference above and below the line edit in krunner, the notification buttons, most of the panel settings) these things are glaringly obvious when you look for them, and subconciously irritating when you don't.

It's hardest to spot these things in your own designs. KDE Telepathy isn't perfect (nor is my website!) so this needs everyone to report bugs on even the most minor detail and to get involved with fixing them. It can feel stupid reporting on bugs this small, which has put me off doing it till now.

---

I've had some comments last blog post that my spam filter gets over-excited. If it does trap your comment, don't get stressed about it or resubmit, I'll look through the queue and mark them as non-spam in due course.

A title that is effectively social-suicide to post on PlanetKDE, but I'll risk it anyway. I spent some time last week trying out Gnome 3.2, and it has a lot of really good ideas that we can steal take influence from.

I think as desktop developers it's always worth spending some time to see what our "competitors" are doing in both the open source and commercial world.

I've shared just a few of the things that stood out in Gnome 3 as things I liked.

Smart use of font colours

In this screenshot, we can see for a list of "label: value" the labels are slightly greyed out. I really like this, as your eyes are instantly drawn to the information you want to see, the values that change not the label. My brain doesn't need to see the label to know that "100 Mb/s" refers to the speed, or see something formatted like an IP address and it makes it quicker to find this information.

The equivalent KDE application uses this (IMHO) the wrong way round. What's worse is on the KDE the use of when to bold text is inconsistent. The battery plasmoid uses bold text on the values in the applet, but in the tooltip, this is reversed. We have inconstancy within a single applet. Also generally bold fonts are harder to read and should be used with caution.

Use of fonts are a risky business, using too many will make the desktop look inconsistent and messy. A good desktop experience needs a small set, with clear defined rules as to what to use where.

Borderless windows

With the drop-shadow effect, window borders aren't needed. The shadow shows where the window ends and removing borders not only gives you a few extra pixels, it removes one layer of the "boxes inside boxes inside boxes" look that tends to plague KDE apps. Below is an image of dolphin in Gnome's window manager.

"But you can already do that in KDE".

That's sort of true. In KDE you can remove the border, but not in a way that actually works. In Gnome they've done something clever, the borders are missing but moving to the edge of the window (on any size) still displays size grips for a few pixels around the window, a larger size area to resize from than the standard thin borders KDE has. It's a move that results in a better appearance and an easier to use experience, something that's much better than having lots of options.

Consistency

Every indicator in gnome has mockups and was designed by a single group who talk to each other. Each KDE plasmoids are mostly created by a single team/person, which doesn't lead to consistency. Click on one of my icons could open a plasma applet, a QWidget styled menu, or even open a dialog in the middle of the screen. Visually each applet is different, with a mixed use of fonts, padding and design.

Number of tray icons

Whilst Gnome just has a few indicators, my desktop has millions. This is caused by the lack of a regulating team that says "this panel is only allowed to have XYZ". A lot of the indicators here do nothing, they just inform me that an application is running. I don't need to be told that. KOrganizer for example has an icon to show me that the event reminder daemon is running? No-one needs that, if I have reminders in my calendar it should be running a daemon, if not, then it shouldn't be running. No point giving me as a user an option to break my event notifications (by turning it off) and I don't want to be notified that things are working as expected.

All this effort to phase out system tray icons in plasma hasn't really been helped by the number of applications making things that still use them, for no real reason.

Proper padding

Padding refers to the spacing between the inside of a border and the content, with plasma and QML this moved to being something done by the developer and not the widget engine. Whilst this gives flexibility to be clever it allows developers to do it wrong. I intend to make an entire blog post about proper-padding in the future, along with hopefully a bucket load of patches.

It's not perfect

Whilst Gnome 3 is very very polished, it is missing quite a few things. Our desktop needs a lot of work and extreme focus on user experience to match theirs, but there's plenty of chance for staying continually better. At least our users can shut down.

In our project we had to move several files between git repositories. Having searched the internet, there didn't seem to be any well defined way to do it. I don't claim to be a git wizard, but I came up with a solution that I wanted to share in case it was useful to anyone else.

There is a method to filter a folder in a git repository which can then be used to move between repositories, but not so easily for files. I came up with a method that effectively involves rewriting the history to put everything into a folder which we then steal.

As we are using filter-branch we first need to take a clone of the source repository. Filter-branch is a destructive command that actually edits the history and will destroy your repository.

#!/usr/bin/python
import os

files = ["service-availability-checker.cpp",
"service-availability-checker.h"]

for filename in files:
    if not os.access("keep", os.R_OK):
        os.mkdir("keep")
    if os.access(filename, os.R_OK):
       os.rename(filename, "keep/"+filename)

move-files.py

git filter-branch --tree-filter /path/to/move-files.py

Now we can grab the folder we wanted

git filter-branch --subdirectory-filter keep/

Now we turn the directory into a set of patches

git format-patch HEAD^ HEAD

This gives us a nice set of patch files which contain commit information which can be imported into a new repository.

KDE Telepathy 0.2 isn't too far away, so I thought I'd give a bit of a progress update.

We've mostly been working hard to tidy up and stabilise most of what we offered in 0.1, but we've also brought in a few shiny features:

Most anticipated of all, there is no longer a dependency on gnome-keyring! Upstream (telepathy) had provided a (mostly working) mechanism for us to provide our own passwords, so we have perfect KWallet integration.

Over the sprint I implemented drag+drop on our contact applet plasmoid so they interact nicely with the contact list.

We've made it even easier to see other contacts on your local network (bonjour) added auto away and "now playing" presence messages.

There's still a lot of things left to sort out, but 0.2 but it is shaping up to be a solid release!

We're about 1 week away from a hard feature freeze, aiming for a full release in early november. If you want to get involved, or start early beta testing please join us in #kde-telepathy.

Now for some pics and videos!

Vimeo Link

It was an amazing week! I met some really cool people from both the Gnome and KDE camps, and had a fantastic time.

A particular personal highlight was attending the Gnome IM Integration BOF (what Gnome is doing with telepathy), some of the discussion wasn't relevant to me, but it was still incredibly productive and informative. I hopefully was able to help them with some parts, and they were able to help me with some technical issues I was facing. It was great to be able to talk to someone who had faced exactly the same problems only a few months ago, and had managed to come up with a way round it. When coming up with requirements for common backend components, the best way is for us to work together.

I spent a lot of my free time with part of the Gnome documentation team who gave me a lot of insight into ways KDE could do help a lot better.

I also had an opportunity to finally meet my GSOC student, Francesco, in real life. That was quite the (terrifying) experience 🙂

So many new ideas, new projects and not enough time to do it all!

We definitely need more close collaboration like this in order to make both Linux desktop environments achieve their full-potential.

Thanks to all the organisers, the rest of the volunteers and to the KDE eV for sponsoring my accomodation.

This is the (very late)part two of our mini-series about why the tech preview KDE Telepathy 0.1 rocks.

One thing I really wanted to do with KDE Telepathy was making setting up accounts as easy as possible. Setting up common accounts like Facebook or Gmail should be only a few clicks away. It has all the server settings already set up, all that's needed is your name and password. We've tried to do this in a way that keeps things simple but still keeps really advanced options still available.

KDE Telepathy supports text chat in a wide range of different accounts. As many as Kopete, and more than Empathy.

KDE Telepathy is still very much a work in progress, but results are looking promising.

"The hope lies in the telepathy KDE guys, assuming they ever manage to get something out." - einar77 from Reddit.

After lots of delays, we're about ready to make our first release of KDE Telepathy, the new IM framework.

The release coincides with KDE4.7 and the release of digikam, so it's an exciting day to be part of KDE.

It's still very much an early release, there are plenty of things that are a work in progress, but it's showing plenty of promise.

I'd like to share below details on a project I've been working on before I try pushing on the KDE mailing lists and seeing if there's any interest.

What is LightDM?

LightDM is a cross-desktop display manager (think KDM). It's designed to be fast and lightweight, it is written to replace GDM Gnome's display manager.

What makes LightDM interesting for KDE is it is designed to to have multiple 'greeters'. This is the front end that sits on top of the daemon and does the displaying to the user asking them for login details. This means we can have our own KDE interfaces, whilst the Gnome people do their different UIs all whilst sharing the same daemon that handles all the hard parts.

By having this this multiple greeter system, we don't need have to have just one KDE greeter. It becomes very easy to experiment with new ideas too. There was talk about a plasma interface to KDM which I don't think ever got anywhere. With LightDM and my QLightDM library writing a plasma greeter would only take a few evenings at most. (I remain convinced that using plasma here is a good idea, but I fully support anyone wanting to try.)

Each greeter could also be themeable, so this is a bit like KSplash; we have the normal KSplash engine with a big collection of themes, but we're in time also adding KSplashQML which is an engine to allow a different set of themes on a different technology.

What's wrong with KDM?

Nothing in particular. I'm not trying to oust that project or say anything bad about it (except I can't stand the KCM. There are far too many options that don't do anything if you're using a theme. Greeters help solve this.). I simply think this a cool project, which I'm getting involved in.

By using a cross-desktop project we get to share working on the daemon backend, so we will have wayland support at the same time Gnome does. I'm a massive fan of freedesktop projects and not duplicating work! It's much better to try and get involved from the start, so we can shape it where we want it to go.

What's been done?

I got interested in the project after seeing a post on Planet Ubuntu and thought "KDE could use some of this.". I've written a Qt library for making greeter engines, as well as a very basic demo greeter which is more for testing than a real demo of what can be done. This library is designed to be very QML-ready, with a strong emphasis on using models rather than simple lists.

This is all stored within the main lightdm source code repository.. There is also a PPA available if Kubuntu users want to try it out themselves.

I've got an idea in my head for the direction I want to take it with QML themes that will be hopefully lead to the same broad range of designs that KDM has, but more flexible whilst keeping a really sensible config dialog.

Alex Fiestas has been working on some changes in KDE4.7 to make sure suspend, shutdown and user switching work still work whilst using lightDM. Making it a fully replaceable manager.

Obligatory screenshot

If you'd understood the above you'll realise this is all about the backend library, and having a flexible structure, however I can't leave a blogpost without putting in a screenshot.

Given the various blog posts, and (somewhat unnecessary) hysteria over the news of Skype I felt like I should give an update on what's going on in KDE Telepathy.

Pace over the past 5 months has been ace, we've got a lot done, and as mentioned by a few people already - we're releasing "soon"! We don't have a fixed date, but instead we will release when a set list of outstanding bugs are fixed. Probably about 4 weeks time. (unless I die of stress organising it all in the meantime)

What's in this release?

There's not as much as we'd like, but we're making a concious effort to ship something that really works. You should be able to create any type of IM account and have basic contact-list tasks and have normal text chats.

At this stage nothing is really fixed, and we're in early stages of shaping where we're going. Hopefully you'll see what we're aiming for with KDE Telepathy and a start to the realisation of some of what telepathy is about.

This first release won't have all the nepomuk integration blogged about by George Goldberg, nor will it have audio/video chat. Rest assured that there are a lot of cool designs, ideas and even code floating around and that this will come, but only when it's ready.

There's still plenty of opportunity to get involved, we've got some junior jobs left that need doing. Testers are great, providing they're really willing to read a lot documentation and really get stuck in, there's quite a bit of effort needed in getting a working setup at present.

What else is coming?

We have a GSOC student that I'm mentoring over the summer to really nail bringing instant messaging into the core of the Plasma Workspace. I won't spoil the details as he'll be blogging soon, only to say it's an exciting time to be in KDE.