KDE, LightDM and the Mir Kerfuffle

With Canonical’s decision to make a new display server, there’s been some questions as to how this affects LightDM and the KDE front end I’ve spent a long time working towards.

It’s a perfectly sensible question, LightDM has heavy Canonical sponsorship, and a display server needs to be supported in the display manager.

Canonical (and Ubuntu) have decided not to adopt Wayland as their new display server, but a new in-house system called Mir. We in KDE have already made the decision that Wayland is the future, and work in kwin has already begun on that. Having a Display Manager that supports a Wayland system compositor is essential to our long term strategy.

I’ve been asked to address this a lot, so I’ll put my thoughts in a blog post.

The back story

After a bad experience customising KDM for a really important and scary client I wanted to redo the UI and customisation experience of KDM.

I wanted to rewrite the whole UI and config side, so started looking through KDM code. It was around this time Robert Ancell posted about LightDM, a new display manager that aimed to be greeter agnostic. This was around 2 years ago when everyone was getting excited over Wayland, it was clear it was in LightDMs roadmap.

This seemed like a win, win situation. I get an easier platform to write my new login manager on *and* I get to bring Wayland support to KDE.

I wrote Qt bindings around LightDM upstream, along with a reference QWidget based greeter. I then started working on the KDE greeter in our repository.

The KDE greeter is approaching version 0.4. It is included in many distros, and generally feedback has generally been very positive.

The current state

Whilst LightDM is made by Canonical it is community driven and all patches go through review where anyone can comment. I have an opportunity to argue if anything is greeter specific in the libraries.

LightDM is used by my KDE greeter (used in some distros, not all), XFCE, and Razor Qt and of course Unity.

The Qt library was originally only used by us and Razor Qt, but with Unity’s move to QML this means that Canonical are now dependant on the libraries I made. I am still in charge of the Qt library and still get final say on all reviews, I have rejected some Canonical employee patches as needing a rewrite and them with some of mine, it feels like a real open meritocracy community.

The rant

The golden-egg of using LightDM in KDE was that we wouldn’t have to support all the boring things we need to make a display manager work, we wouldn’t need to support a Wayland system compositor we get it for free. We all write stuff that helps each and open source progresses faster.

If I’d known they weren’t going to add Wayland support, I’m not sure I would have invested my time in LightDM. I don’t feel decieved, they thought they would do it at the time and Canonical are perfectly within their rights to decide to do something else.

The problem for me isn’t that Canonical changed their mind, but that they didn’t (or the developers weren’t allowed) to tell me! If you know for 6 months that you’re not going to do something you said you would it’s rude not to tell people. It now sets our schedule back and that’s really really frustrating.

Where does this leave us?

The state of LightDM hasn’t got _worse_ however it does mean we need to add Wayland support ourselves. I’ve heard the argment; if we need to add Wayland support in something else, is it worth using it? I’ve been asked to address this, I’m writing this blog post to express my feelings, then I’ll be having a meeting later this week to discuss things.

Our requirements are:

  • We need to have a display manager that works in Qt5 in the very near future.
  • We need a display manager that supports Wayland as a system compositor in the medium term.
  • Our options are:

  • Patch KDM to support X and Wayland (something hard to do, this code is built on top of XDM) AND fix Qt5 support (again not trivial in this case)
  • Write something new from scratch. In this case we still need to write a Wayland system compositoranyway!
  • Patch LightDM to also support Wayland (given it’s already switching between Mir and X, the infrastructure is in place, it’s designed to be able to switch backends and we have half-done Wayland patches to start with). It already all works in Qt5.
  • Writing a display manager is one of the things that sounds simple but in reality is very difficult; but there’s a lot of stuff behind the scenes which is really difficult to get right: a tonne of environment variables to set, Xauthority files to set up, .dmrc files to manage, all sorts of session hooks let alone remote sessions and security.

    From the above, I think my viewpoint on the matter is pretty clear, we just have a bit more work ahead than I’d initially hoped for.

    That said, I will be having a meeting with a few interesed parties later this week to discuss future direction.

    KDE Telepathy 0.6 Beta Released

    Today we released a beta of 0.6.0 of KDE Telepathy KDE’s instant messaging client.

    New Features

     

    Kopete log migration

    KTp now imports logs from Kopete accounts into our log format. For new KTp users this will be asked if they wish to import when they create an account, existing users can also import logs by opening the log viewer.

    Clearer message notifications

    We had some feedback to improve the notifications of new messages. We now show an icon in the contact list when a new message arrives, change the icon in the system tray, and for group chats we now show who is typing.

    Better text editing

    The chat window now features tab completion for group chats, as well as text navigation for editing messages.

    We’ve made adding emoticons easier too, with a new optional emoticon toolbar.

    Advanced notifications

    KTp now supports setting different notifications for each of your contacts. This means it is possible to set an optional notification if your favourite friends come online, or play sounds when messages arrive from certain contacts but not others.

    Improved password and security management

    We are now able to connect to password protected jabber rooms, a much requested feature. We have also improved our connection certificate handling, now using KDE SSL certificates manager and allowing the user to override invalid certificates.

    Under the hood changes and cleanups

    A lot of our effort has been spent in a big refactoring under the hood, getting ourselves ready for the future as well as bringing speed and stability. We have closed over 70 bugs between 0.5 and 0.6.

    We’ve completely redone connection error notifications and other important UI areas.

    More filtering plugins

    We have extended our range of message plugins.

    Text messages can be formatted in bold or italics

    Youtube links are show and can be played directly in your chat window

    Links to bugzilla are shown inline with the bug title and resolution

    When sending messages can use your KDE webshortcuts to make it quicker to send links

    Messages containing your name are highlighted and a special notification with sound can be emitted. This is especially useful if you lurk in conference rooms

    Getting the 0.6 beta

    Our beta is stable for everyday use and we made sure there are no major bug before release. There are packages being built right now for Fedora, Arch, Kubuntu and SuSE.

    Source tarballs are available from http://download.kde.org/unstable/kde-telepathy/0.5.80/src/

    This contains our full set of applications and applets



    Getting involved

    This is a beta and there will of course be bugs that we are aware of and want to fix by 0.6.0, there are also bugs that we are not aware of that still need to be reported.

    You can help make 0.6.0 an awesome release by running the beta and reporting any bugs to http://bugs.kde.org.

    You can also help by fixing bugs, to find out how to contact our team and get involved please see our wiki page at http://community.kde.org/KTp/Getting_Involved.

    KDE Telepathy Enters Hard Feature Freeze

    With KDE Telepathy 0.5.3 out the door out our entire focus is on 0.6.0 our next major release. We have just entered a hard feature freeze to allow for a solid month of bugfixing.

    Important Dates

    Hard Feature Freeze – 3rd March

    A hard feature freeze is when no new features can be added to the code. All work has to be on fixing bugs and polishing.

    Beta Release – 6th March

    We will make a public beta release so you can see all the new features and provide useful feedback before the full release.

    String freeze – 16th March
    After this date we are not able to change any of the text used by our applications, It gives our translator team a stable set of text (strings) to work with without us changing them the whole time.

    The release – 30th March
    Hopefully self-explanatory 🙂

    What’s going to be new in 0.6?

    Find out yourselves by running the latest code 🙂
    A real announcement will come with the official beta release.

    How do I run the latest code?

    KTp is generally really stable as all the developers use IM on a daily basis always running the latest code. It helps us to have lots of people running the latest code before we release a piece of software so we know about, and can fix, issues from a wide variety of set ups as we introduce new code, before it hits the general masses.

    It helps us, and you get to be on the “bleeding edge”. Please report all bugs as they come in.

    From Source

    We have instructions in our wiki at http://community.kde.org/KTp/Getting_Set_Up

    (K)Ubuntu Packages

    If you use Kubuntu we have a PPA of our latest code.
    Install instructions are:

    sudo apt-add-repository ppa:telepathy-kde/daily-builds
    sudo apt-get remove kde-telepathy-minimal plasma-widget-telepathy-presence
    sudo apt-get install ktp-desktop-applets

    OpenSuse packages

    zypper ar -f http://download.opensuse.org/repositories/KDE:/Unstable:/Playground:/Telepathy/openSUSE_12.2/KDE:Unstable:Playground:Telepathy.repo
    zypper in telepathy-kde

    How can I get involved?

    Join our mailing lists and IRC channels and get hacking on any outstanding bugs. Note that we are in a feature freeze, but any bugfixing/polishing is always a really good way to get involved in a project.

    For contact information see our wiki page http://community.kde.org/KTp/Getting_Involved