KDE developer, Nate Graham on the project’s bug-fixing blitz
KDE is a vast project that celebrates 22 years in October. We spoke to nate Graham about KDE’s ongoing bug-fixing charm offensive
KDe developer nate Graham spearheads KDe’s usability and productivity initiative, which is one of the three major goals of the organisation that were agreed in 2017.
“The thrust of this goal is we want to make KDE Plasma and our KDE apps easier to use, and more approachable for typical users,” Graham told us, chatting over VoIP from his sofa at home – and the response, particularly for recent Plasma point releases, has been positive. Going further, KDE wants to make complex workflows a lot simpler and easier for anyone to use: “We want our software to be a lean, mean productivity machine,” says Graham. Read our, (lightly edited) interview below:
Let’s start with what you do on the KDe project…
I write documentation to help people get involved in the project. I do bug triaging, so that we can have bug-tracking systems that are accurate. I mentor for new contributors to help them get involved in this; I submit lots of patches myself. I review patches that other people have submitted. I do user interface design, and usability and visual stuff. I’m involved in this process quite a lot, and my work takes me into contact with lots of other members of the KDE community, which is one of the most rewarding parts of it, because I get to learn from them, and I hope that they get to learn from me, too.
I wondered how you ended up working on KDe from working at Apple?
It’s a funny journey. Working at Apple was always one of my childhood dreams. I always loved Apple’s software and hardware, because I felt that they really focused really aggressively on both the overall user experience and also the little polished details that were often overlooked in other software. They really said, “It’s not okay that we get 95 per cent of the way there. We need to get 100 per cent of the way there.” I worked at Apple for eight years, but eventually, it was time to move on. Once that was done, I decided that I wanted to be involved in a part of the Linux community.
So I looked around for a little while, and I tried to find a Linux project that I felt matched the most what I saw Apple was doing. And I found a number of different ones. But ultimately, the reason why I settled on KDE was not so much I felt they were currently the most Apple-like, but because I felt like KDE’s community was the one that was most welcoming towards becoming this way – and the most welcoming towards me, as well.
You put in your usability and productivity proposal last year. You’ve covered it a little bit, but could you tell us a little more about the initiative?
When I initially proposed this and it was accepted, I set a timeline for two years. I said to myself,
‘I think we need to do basically 10 years’ worth of improvement every year.’ So 20 years’ worth of product usability improvements in two years, maybe 30 in three years. But I think we can absolutely get there and as the excitement for this initiative has built up, I think we see an increasing number of people wanting to become involved in it, which is really rewarding – because lots of new contributors means lots of new help, and the pace of the change happens faster. Which makes everybody else excited, and it becomes a virtuous circle.
Has that led to changes in quality testing? Has it changed how you test the apps and framework? The way we do our testing is somewhere I feel like we still have some improvements to make. This is sort of an endemic problem everywhere, because testing is one of the least fun aspects of software development, of course. And all of our software has very aggressive release schedules – we release three new versions of Plasma every year. We release three new versions of all our apps every year. And
we release a new version of the frameworks that support all of them once a month – so 12 times a year. Often, this doesn’t leave enough testing time.
For frameworks, there’s always the possibility that if something breaks or if there’s a regression, we can just ship a fix the next month. But for all the other ones, it means that we have very abbreviated release schedules, which means that the demand for testers and testing is always quite extreme. One of the things we’re really looking to do is to help people test the beta versions of our software.
We already have quite a number of testers who do this. Those people are amazing. I want to give a shout out to them because they are so important and awesome. But we can always use more help. Testing the beta versions of KDE software is probably one of the biggest ways that a nonsoftware developer contributor can help to keep the quality levels up.
You’ve had quite a focus on Discover recently? Yes, I feel Discover has made huge strides in the last few releases. When I started with Plasma, the feedback that I always saw with Discover, at least online from users, was quite negative – and often quite hostile, which was a little bit demoralising.
That was one of the reasons why I felt we really needed to focus on this project. It wasn’t that it was a bad project: there were a few little niggling issues of the sort that tend to annoy users. Even if the foundation is really stable, if the interface isn’t polished to the extent that people want or it’s not totally reliable, people often find they’re frustrated.
So I worked with the lead developer, Aleix [Pol], who is an amazing guy, and has been involved with KDE for a very long time. He, himself, had noticed most of these issues and was already moving towards resolving them. So I helped out, mostly on the user interface side, to make Discover look and feel more like a Desktop app when it’s running on the Desktop, and to solve some user interface inconsistencies, and to propose some better behaviours, and to redesign some of the pages to look more visually attractive.
I think we saw a pretty good response for the
5.12 release. The 5.13 release, we got a really good response. And the upcoming 5.14 release, I think people are going to like it even more, because we’ve made even more of the kinds of changes that they want. And now Discover is stable. It has lots of features. It’s very visually attractive. So personally, I think Discover is an example of a current success story, where we focused a lot of our resources aggressively on one app that needed some attention. Now that we’re there, we can redirect those resources elsewhere, and move onto the next thing.
It’s a very large project, so how do you deal with the interoperability and compatibility issues with KDe in terms of dependencies and consistency? KDE Plasma and KDE apps are run on so many different distros, and some people even run some of them on Windows and Mac operating systems. We often do have lots and lots of bug reports from users. To a certain extent, this happens in lots of computer software, because developers tend to use certain
I want to give a shout out to our testers because they are so important and awesome
types of systems, and users tend to use a vastly more diverse set of hardware and software than we do. This is why having beta testers is so important.
I want to really thank the users of rolling release distros at this point, because to a certain extent, in the whole Linux ecosystem, they provide a release QA for everybody else. This is, I think, especially true for KDE software, because of our aggressive release schedules. Every single month, we release a new version of KDE frameworks. So that gets into the hands of Arch users practically immediately.
So if we get a whole bunch of bugs from Arch users that say, ‘Hey, this broke’, we can fix it in the next release of KDE frameworks. And that’s going to be completely invisible to the people who use Kubuntu, who use Debian, who use openSUSE. They basically benefitted from the Arch people’s QA. So I’d just like to say thank you, Arch and Manjaro and Tumbleweed users. You’re all doing the community, and the wider Linux ecosystem, a really incredible service.
what do you feel are the barriers for KDe?
I gave a presentation at Akademy [KDE’s community gathering], and I targeted a number of user personas whom I think can benefit from KDE Plasma. For the most part, these are technical professionals, business professionals, students and teachers, people along those lines.
I think what we need to do is look at the reasons why they don’t currently use our hardware and software. A major one is a lack of pre-installation on people’s hardware. I think that really is the biggest one. Because most people don’t buy software; they buy hardware. To most people, the physical thing they can hold in their hands is the product. So we need to get KDE Plasma and KDE apps on more hardware. But in order to do that, what we need to do is first focus on our software to the point where hardware vendors can look at it and say, ‘Hey, wow, this thing is so good. I really want to put this on my hardware.’ And then it’ll be attractive to users. So I work backwards from there. I say, ‘We’ve got to put it on hardware. To do that, we have to focus on software. But which ways do we focus on software?’
We need to make sure that it’s meeting business and enthusiast power-user use cases, and that it’s meeting student and teacher use cases. Those are the primary ones.
From that very high level perspective, that leads to some technical things. The people who I’m talking about very frequently use remote files on Samba shares, for example. This is something that technically we’re a little bit behind on. Our tech for accessing files and folders on Samba shares is not a reliable as it needs to be. So that’s something I would really like to focus on. I feel like if we managed to do that, we reduce the friction a little bit for the people in those use cases. Then we make the software more attractive, and the hardware vendors are going to want it, and then people are going to be able to buy stuff with it on. And then we take over the world…
As product manager for Kubuntu, how’s 18.10 coming along?
Pretty well. We’re going to have Qt 5.11. We’re going to have Plasma 5.13. We’ve gotten a very good reception from Kubuntu 18.04, users are pretty happy with it. We’ve made a couple of very bold user interface and defaults decisions, too, that I was hoping people would respond well to – and so far, they have. This included one that I wasn’t fully on board with originally, which was using a dark theme
for Plasma and a light theme for apps. That was something I fought against internally, but now it’s been released, people really seem to like it. So I’m going to say: I was wrong, you were right – that was a great decision. That’s one of the things that I think makes our community really strong. We have a lot of people who are interested in pushing the envelope.
what do you feel were the key developments from Akademy this year?
That’s a really great question. I think there were a couple of things that were really important. First of all, the Kate and KTextEditor developers did probably a year’s worth of work in one week, which was astonishingly amazing. It was an incredible pace of improvement. Other than that, there was lots of work on Plasma, too. There were lots of really great conversations that we all had regarding topics that are sometimes hard to discuss over the internet but are a little bit easier to have face to face. There isn’t really anything specific that I’d like to talk about just yet, but we got rid of a lot of bottlenecks.
So for developers interested in getting involved, what kind of support does the KDe project offer? We have a wiki page that’s linked from the main page on KDE.org. Just click ‘Get involved’ at the very top, and it takes you to a whole list of things that you can do. We’ve got detailed documentation and instructions for how to file good bugs, how to triage bugs, how to get involved in development, how to get involved in visual design and translation. We’re always working to improve that documentation, but we think it’s at a pretty decent stage right now.
Once you decide that you want to get started, there are a lot of great resources for communicating
with developers. We’ve got IRC channels, we’ve got Telegram rooms, we’ve got mailing lists and then of course, our system for code review and test management – Phabricator [https://phabricator. kde.org] is somewhere where we’re all very active.
On privacy, what developments are happening? The privacy side is not as active as the other two [goals], but there are definitely some things going on behind the scenes. There’s been a lot of preparation for work that hasn’t been made public yet.
Is that related to Purism’s Librem 5 phone?
I think it’s related, in the sense that all of these things are kind of related, because we’re doing lots of work with them. I think when it comes to the Librem 5 phone, we want to make our platform more attractive for that target. I think one of the ways we’re doing that is with the GNU Ring [a universal communication platform focused on protecting privacy and freedoms]. This is the KDE client for the GNU Ring software. We’ve just released a new version recently that uses our Kirigami framework in order to improve the user interface. So we’ve just got to keep going with that, and we really hope that we can strengthen our partnership with [Purism], and eventually convince them to use Plasma Mobile.
we were under the impression that Purism wanted to support it?
My impression is that [Purism] are, right now, going with a custom-made GNOME solution. But they’re committing to supporting a community-maintained KDE Plasma version. So by default, I don’t believe they’re currently planning to ship with Plasma Mobile. That’s something we hope to change.
We’ve gotten a very good reception from Kubuntu 18.04– users are pretty happy with it
Above Kubuntu’s 18.04 new dark theme for Plasma, with a light theme for KDE apps, turned out to very popular
Above KDE has recently released a Qt-based client for GNU Ring (https://ring.cx), the free and universal communication platform. Ring uses distributed hash table technology to create its own network. Since July 2018, GNU Ring now supports featuressuch as audio and video call recording and push notifications