put a file called .editorconfig in the project’s root directory
specify a default style and then a specialization for certain filetypes
Here’s what my .editorconfig file looks like:
# EditorConfig is awesome: https://EditorConfig.org
# for the top-most EditorConfig file, set...
# root = true
# In general, tabs shown 2 spaces wide
indent_style = tab
indent_size = 2
# Matches multiple files with brace expansion notation
indent_style = space
indent_size = 2
This does the job nicely and has the following advantages:
It doesn’t affect my other projects, so I don’t have to run around in the configuration to switch when task-switching. (Editorconfigs cascade, so will be looked up up in the filesystem tree for fallback styles.
It works across different editors supporting the editorconfig standards, so not just KWrite, Kate, KDevelop, but also for entirely different products.
It allows me to spend less time on formalities and more time on actual coding (or diving).
This week, Dan Vratil and me have merged a new feature in KScreen, Plasma’s screen configuration tool. Up until now, when plugging in a new display (a monitor, beamer or TV, for example), Plasma would automatically extend the desktop area to include this screen. In many cases, this is expected behavior, but it’s not necessarily clear to the user what just happened. Perhaps the user would rather want the new screen on the other side of the current, clone the existing screen, switch over to it or perhaps not use it at all at this point.
The new behavior is to now pop up a selection on-screen display (OSD) on the primary screen or laptop panel allowing the user to pick the new configuration and thereby make it clear what’s happening. When the same display hardware is plugged in again at a later point, this configuration is remembered and applied again (no OSD is shown in that case).
Another change-set which we’re about to merge is to pop up the same selection dialog when the user presses the display button which can be found on many laptops. This has been nagging me for quite a while since the display button switched screen configuration but provided very little in the way of visual feedback to the user what’s happening, so it wasn’t very user-friendly. This new feature will be part of Plasma 5.13 to be released in June 2018.
At Akademy 2016, the KDE community started a long-term project to invigorate its development (both, technically and organizationally) with more focus. This process of soul-searching has already yielded some very useful results, the most important one so far being agreement of a common community-wide vision:
A world in which everyone has control over their digital life and enjoys freedom and privacy.
This presents a very high-level vision, so a logical follow-up question has been how this influences KDE’s activities and actions in practice. KDE, being a fairly loose community with many separate sub-communities and products, is not an easy target to align to a common goal. A common goal may have very different on each of KDE’s products, for an email and groupware client, that may be very straight-forward (e.g. support high-end crypto, work very well with privacy-respecting and/or self-hosted services), for others, it may be mostly irrelevant (a natural painting app such as Krita simply doesn’t have a lot of privacy exposure), yet for a product such as Plasma, the implications may be fundamental and varied. So in the pursuit of the common ground and a common goal, we had to concentrate on what unites us. There’s of course Software Freedom, but that is somewhat vague as well, and also it’s already entrenched in KDE’s DNA. It’s not a very useful goal since it doesn’t give us something to strive for, but something we maintain anyway. A “good goal” has to be more specific, yet it should have a clear connection to Free Software, since that is probably the single most important thing that unites us. Almost two years ago, I posed that privacy is Free Software’s new milestone, trying to set a new goal post for us to head for. Now the point where these streams join has come, and KDE has chosen privacy as one of its primary goals for the next 3 to 4 years. The full proposal can be read here.
“In 5 years, KDE software enables and promotes privacy”
Privacy, being a vague concept, especially given the diversity in the KDE community needs some explanation, some operationalization to make it specific and to know how we can create software that enables privacy. There are three general focus areas we will concentrate on: Security, privacy-respecting defaults and offering the right tools in the first place.
Improving security means improving our processes to make it easier to spot and fix security problems and avoiding single points of failure in both software and development processes. This entails code review, quick turnaround times for security fixes.
Defaulting to encrypted connections where possible and storing sensible data in a secure way. The user should be able to expect the KDE software Does The Right Thing and protect his or her data in the best possible way. Surprises should be avoided as much as possible, and reasonable expectations should be met with best effort.
Offering the right tools
KDE prides itself for providing a very wide range of useful software. From a privacy point of view, some functions are more important than others, of course. We want to offer the tools that most users need in a way that allows them to lead their life privately, so the toolset needs to be comprehensive and cover as many needs as possible. The tools itself should make it easy and straight-forward to achieve privacy. Some examples:
An email client allowing encrypted communication
Chat and instant messenging with state-of-the art protocol security
Support for online services that can be operated as private instance, not depending on a 3rd party provider
Of course, this is only a small part, and the needs of our userbase varies wildly.
Onwards from here…
In the past, KDE software has come a long way in providing privacy tools, but the tool-set is neither comprehensive, nor is privacy its implications widely seen as critical to our success in this area. Setting privacy as a central goal for KDE means that we will put more focus on this topic and lead to improved tools that allow users to increase their level of privacy. Moreover, it will set an example for others to follow and hopefully increase standards across the whole software ecosystem. There is much work to do, and we’re excited to put our shoulder under it and work on it.
Since I’ve been playing with various home automation technologies for some time already, I thought I’d also start writing about it. Be prepared for some blogs about smart lighting, smart home and related technologies.
Most recently, I’ve gotten myself a few items from IKEA new product range of smartlight. It’s called trådfri (Swedish for wireless). These lights can be remote-controlled using a smartphone app or other kinds of switches. These products are still fairly young, so I thought I’d give them a try. Overall. the system seems well thought-through and feels fairly high-end. I didn’t notice any major annoyances.
My first impressions are actually pretty good. Initially, I bought a hub which is used to control the lights centrally. This hub is required to be able to use the smartphone app or update the firmware of any component (more on that later!). If you just want to use one of the switches or dimmers that come separately, you won’t need the hub.
Setting everything up is straight-forward, the documentation is fine and no special skills are needed to install these smartlights. Unpacking unfortunately means the usual fight with blister packaging (will it ever stop?), but after that, a few handy surprises awaited me. What I liked:
The light is nice and warm. The GU10 bulbs i got give 400 lumens and are dimmable. For my taste, they could be a bit darker at the lower end of the scale, but overall, the light feels comfy warm and not too cold, but not too yellow either. The GU10 bulbs I got are spec’ed at 2700 Kelvin. No visible flickering either.
Trådfri components are relatively inexpensive. A hub, dimmer and 4 warm-white GU10 bulbs set me back about 75€. It is way cheaper than comparable smartlights, for example Philips Hue. As needs are fairly individual exact prices are best looked up on IKEA’s website by yourself.
The hub has a handy cable storage function, you can roll up excessive cable inside the hub — a godsend if you want to have the slightest chance of preventing a spaghetti situation.
The hub is USB-powered, 1A power supply suffices, so you may be able to plug it into the USB port of some other device, or share a power supply.
The dimmer can be removed from the cradle. The cradle can be stuck on any flat surface, it doesn’t need additional cabling, and you can easily take out the dimmer and carry it around.
The wireless technology used is ZigBee, which is a standard thing and also used by other smarthome technologies, most notably, Philips Hue. I already own (and love) some Philips Hue lights, so in theory I should be able to pair up the Trådfri lights with my already existing Hue lights. (This is a big thing for me, I don’t want to have different lighting networks around in my house, but rather concert the whole lighting centrally.)
Pairing IKEA Trådfri with Philips Hue
Let’s call this “work in progress”, meaning, I haven’t yet been able to pair a Trådfri bulb with my Hue system. I’ll dig some more into it, and I’m pretty sure I’ll make it work at some point. If you’re interested in combining Hue and Trådfri bulbs, I’ll suffice with a couple of pointers:
If you want to try this yourself, make sure you get the most recent lights from the store (the clerk was helpful to me and knowledgable, good advice there!). You’ll also likely need a hub at least for updating the firmware. If you’re just planning to use the bulbs together with a Hue system, you won’t need the hub later on, so that may seem like 30€ down the drain. Bit of a bummer, but depending on how many lights you’ll be buying, given the difference in price between IKEA and Philips, it may well be worth it.
\edit: After a few more tries, the bulb is now paired to the Philips Hue system. More testing will ensue, and I’ll either update this post, or write a new one.
In the past weeks, we have noticed an increased interest in Plasma Mobile from different sides. Slowly, but surely, hardware vendors have discovered that Plasma Mobile is an entirely different software platform to build products on top of. For people or companies who want to work or invest into Plasma Mobile, it’s always useful to know where upstream is heading, so let me give an overview of what our plans are, what areas of work we’re planning to tackle in the coming months and years, where our focus will be and how it will shift. Let’s talk about Plasma Mobile’s roadmap.
Our development strategy is to build a basic system and platform around our core values first and then extend this. Having a stable base of essentials allows us to focus on an achievable subset first and then extend functionality for more and more possible target groups. It avoids pie-in-the-sky system engineering something that will never be useful and designed for a unicorn market that never existed. Get the basics right first, then take it to the next levels. These levels are:
Prototype (already finished)
Let’s look at these steps in detail.
Prototype and Product Vision
The first public release of Plasma Mobile was this prototype. It showed a very basic and incomplete-for-daily-use system on actual, modern smartphone hardware. You could make phone calls, start and manage apps, and manipulate some basic system functionality. It showed a smartphone system based on Plasma could be done, and more importantly, it taught us a lot about where we want to take things on a technical level.
Along with the prototype, we developed a product vision for Plasma Mobile, a direction where we want to take it (emphasis added by yours truly):
“Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.”
The feature phone milestone is what we’re working on right now. This involves taking the prototype and fixing all the basic things to turn it into something usable. Usable doesn’t mean “usable for everyone”, but it should at least be workable for a subset of people that only rely on basic features — “simple” things.
Core features should work flawlessly once this milestone is achieved. With core features, we’re thinking along the lines of making phone calls, using the address book, manage hardware functions such as network connectivity, volume, screen, time, language, etc.. Aside from these very core things for a phone, we want to provide decent integration with a webbrowser (or provide our own), app store integration likely using store.kde.org, so you can get apps on and off the device, taking photos, recording videos and watching these media. Finally, we want to settle for an SDK which allows third party developers to build apps to run on Plasma Mobile devices.
Getting this to work is no small feat, but it allows us to receive real-world feedback and provide a stable base for third-party products. It makes Plasma Mobile a viable target for future product development.
The basic smartphone extends the feature set of Plasma Mobile to a wider group of target users. The plan is to add personal information management features, such as reading and sending emails, calendaring and reminders. We also want to add file management capabilities in this milestone, because we think that the user should be able to deal with the data in her phone in the most transparant way, and file management is something that allows users to look into the fabric of their data, and that of the phone itself. Another big topic for the Basic Smartphone milestone is extending the app ecosystem through third-party and original applications to allow the user to do more things with the device.
For the featured smartphone, we want to add more system-level integration features such as deeply integrated private cloud storage and have grown our own ecosystem with more apps and of course games. An often requested feature is support for Android apps. Supporting Android apps could give Plasma Mobile a huge boost in terms of possible target groups, since it allows users to switch away from Android more easily, even when they are requiring a few apps and can’t really live without these. Being able to run Android apps on a Plasma Mobile device can ease the transition considerably and it allows us to capture potential target user groups that rely on proprietary services which Plasma Mobile, at first, cannot serve simply because as a smaller player, it’s not an attractive enough platform to have the likes of WhatsApp develop native clients for.
When it’s ready!?
On purpose, we did not add a specific timeline to this roadmap for two reasons: First, Plasma Mobile is a participative project, if you want to see something done, get involved. We’re not running the show all by ourselves. We want to create an open eco system where people who do the work decide on its direction. This means if you get involved, you can help us shape the future of mobile computing instead of being just a code monkey that does what someone else has decided. Secondly, we don’t want to deliver half-assed software just because we set a timeline. We want to create quality software to build products upon. If you or your company want to ship on a specific date, work with us and we’ll plan together. We won’t make promises when something is ready beforehand, but as an upstream project, we want to ship “when it’s ready”. This “when” depends on all our input and hard work. So don’t sit in your armchairs and wait for someone else to do the heavy lifting, but let’s get cracking!
In the past days, the campaign to crowd-fund a privacy-focused smartphone built on top of Free software and in collaboration with its community reached its funding goal of 1.5 million US dollars. While many people doubted that the crowdfunding campaign would succeed, it is actually hardly surprising if we look what the librem 5 promises to bring to the table.
1. Unique Privacy Features: Kill-switches and auditable code
Neither Apple nor Android have convincing stories when it comes to privacy. Ultimately, they’re both under the thumbs of a restrictive government, which, to put it mildly doesn’t give a shit about privacy and has created the most intrusive global spying system in the history of mankind. Thanks to the U.S., we now live in the dystopian future of Orwell’s 1984. It’s time to put an end to this with hardware kill switches that cut off power to the radio, microphone and camera, so phones can’t be hacked into anymore to listen in on your conversations, take photos you never know were taken and send them to people you definitely would never voluntarily share them with. All that comes with auditable code, which is something that we as citizens should demand from our government. With a product on the market supplying these features, it becomes very hard for your government to argue that they really need their staff to use iphones or Android devices. We can and we should demand this level of privacy from those who govern us and handle with our data. It’s a matter of trust. Companies will find this out first, since they’re driven by the same challenges but usually much quicker to adopt technology.
2. Hackable software means choice
The librem 5 will run a mostly standard Debian system with a kernel that you can actually upgrade. The system will be fully hackable, so it will be easy for others to create modified phone systems based on the librem. This is so far unparalleled and brings the freedom the Free software world has long waited for, it will enable friendly competition and collaboration. All this leads to choice for the users.
3. Support promise
Can a small company such as Purism actually guarantee support for a whole mobile software stack for years into the future? Perhaps. The point is, even in case they fail (and I don’t see why they would!), the device isn’t unsupported. With the librem, you’re not locked into a single vendor’s eco system, but you buy into the support from the whole Free software community. This means that there is a very credible support story, as device doesn’t have to come from a single vendor, and the workload is relatively limited in the first place. Debian (which is the base for PureOS) will be maintained anyway, and so will Plasma as tens of millions of users already rely on it. The relatively small part of the code that is unique to Plasma Mobile (and thus isn’t used on the desktop) is not that hard to maintain, so support is manageable, even for a small team of developers. (And if you’re not happy with it, and think it can be done better, you can even take part.)
4. It builds and enables a new ecosystem
The Free software community has long waited for this hackable device. Many developers just love to see a platform they can build software for that follows their goals, that allows development with a proven stack. Moreover, convergence allows users to blur the lines between their devices, and advancing that goal hasn’t been on the agenda with the current duopoly.
The librem 5 will put Matrix on the map as a serious contender for communication. Matrix has rallied quite a bit of momentum to bring more modern mobile-friendly communication, chat and voice to the Free software eco-system.
Overall, I expect the librem 5 to make Free software (not just open-source-licensed, but openly developed Free software) a serious player also on mobile devices. The Free software world needs such a device, and now is the time to create it. With this huge success comes the next big challenge, actually creating the device and software.
The unique selling points of the librem 5 definitely strike a chord with a number of target groups. If you’re doubtful that its first version can fully replace your current smart phone, that may be justified, but don’t forget that there’s a large number of people and organisations that can live with a more limited feature set just fine, given the huge advantages that private communication and knowing-what’s-going-on in your device brings with it.
The librem 5 really brings something very compelling to the table and those are the reasons why it got funded. It is going to be a viable alternative to Android and iOS devices that allows users to enjoy their digital life privately. To switch off tracking, and to sleep comfortably.
Are you convinced this is a good idea? Don’t hesitate to support the campaign and help us reach its stretch goals!
There’s hardly a better way to spend a sunday diving, even in early fall when the weather gets a little colder and rainier. We went to Zeeland, at the Dutch coast, to a divespot named Langedijk for two shallow shore dives. The water was a somewhat brisk 14°C, but our drysuits kept us toasty even through long dives.
In one of my latest blogs, I’ve explained what convergence is, how Plasma benefits from it, and why we consider it a goal for Plasma. This time around, I’ll explain the how, how it works across the stack and how we implemented it. Naturally, this article dives a lot deeper, technically, than my previous one.
Convergence plays a role at different levels of the whole software stack. In this, more technical article, I’ll look at different layers of the software stack, from boot/kernel and middleware to UI controls and overall layout and input methods. After reading this article, you’ll understand how Plasma allows to use the same software on a range of devices, which parts are different, and where code sharing makes sense, and thus happens. Keep in mind that Convergence, at least for Plasma, doesn’t mean that we ship a lowest-common denominator UI so it “kind of” runs on all things computer, but that it provides a toolbox to build customized UIs that allow taking advantage of specific characteristics of a given target device.
Lower Levels and Packaging
One aspect of convergence that is of course the deployment side. This doesn’t just include the kernel and bootloader, which needs to be compiled differently for ARM devices and for x86 devices. The rest of the stack is by now largely the same. We are now using the same set of packages and CI for both, mobile and desktop builds, in fact most packages are the same, and the difference between a device set up for mobile use cases and desktop is the selection of packages, and what gets started by default. Everything is integrated to a very large degree, lots of work is shared which means timely updates across the device spectrum we serve.
When it comes to user interface controls, such as buttons, text fields, etc., convergence is mostly a solved problem. Touch input is possible, Qt nowadays even ships a virtual keyboard (which Plasma uses for example for password input in the lock-screen), and buttons react to touch events as well. QtQuick-based user interfaces often work quite well with both, keyboard/mouse and touch input, in fact touch is one of the design goals of QtQuick.
Not everything is perfect yet, however, especially text selection and keyboard control of QtQuick-based UIs often still requires custom-code, meaning it needs more development and maintainance time to get right. QWidget-based UIs are still a bit ahead of the game here, though often the benefits of also being able to deploy an app on touch devices (such as many Android devices out there!) make QtQuick an attractive technology to use. We see more and more QtQuick-based applications, as this technology matures also for desktop use-cases.
Plasma is made of widgets. Even in a standard Plasma desktop, everything is a widget: The menu in the bottom left is a widget, the task manager is, the system tray is a widget, and there are widgets inside the system tray for notifications, battery, sound, network, etc.. Plasma is widgets.
These widgets can be used on any device of course, but it doesn’t always make sense. Some of these widgets are very specific for desktops. The task-manager (that thing you use to switch windows, which is usually located in center of the bottom panel) doesn’t really make sense on a mobile device. For a mobile device, which needs larger areas to touch, something more aking to a full-screen window switcher is useful (and in fact what we use for Plasma Mobile). Other widgets, such as the network connections widget or battery and brightness widgets are perfectly suitable also for mobile devices. Plasma’s architecture allows us to re-use the components that need no or just little changes and use them across devices. That means we can concentrate on the missing bits for each device, and that in turn means we can deliver a feature-rich and consistent UI across devices much easier, while making sure the specific characteristics of a given form-factor are used to their fullest extent.
Again, by sharing the components that make sense to share, we can deliver higher quality features for a given devices with less effort, and thus quicker.
Shell and Look & Feel
Plasma can dynamically load different so-called shell packages. The shell package defines the overall layout of the workspace environment. On the desktop, it says that there’s a fullscreen wallpaper background, with a folderview, a panel at the bottom and the widgets which are loaded into that panel: application launcher, task-manager, system tray and clock for example.
The shell package is different for each device, as this defines the overall workflow, which is highly dependent on the type of device.
To take differences between devices even further, Plasma has the concept of “Look and Feel” packages, which allow further specilialization how a device, well, looks and feels. There’s the widget style and the wallpaper of course. The Look and feel package also defines interaction patterns, such as if a settings interface should use “instant apply” when a setting is changed, or if it should present an “Apply and Okay” button for the user to save settings. Mobile devices typically use instant apply, while desktop interfaces (at least Plasma’s) use the “Apply and Okay” concept throughout. For Plasma UIs, this can be changed dynamically. Plasma’s Look and Feel features is not just useful in the convergence aspect, it allows also for example to switch between a traditional default Plasma setup and a workspace that closely resembles Unity. These “Look and Feel” packages are available through the KDE store, so they’re easy to install and share. There’s even a cool tool that allows you to create your own Look and Feel packages, very much like themes.
Finally, at application level, we see more and more convergent applications. Kirigami, a high-level toolkit that supplied components for consistent, touch- and keyboard/mouse-friendly application nagivation and layout makes it very easy to create applications with responsive UIs that adapt well to screen size and density and that show flexibility in their input methods. This doesn’t just work between Laptops and phones, but also allows to create one app that works equally well on desktops, laptops, phones and tablets.
Kirigami complements Plasma’s convergence feature on application side, and we recommend it for most newly developed apps. With Qt and QtQuick being a viable target for Android devices, it increases the possible target audience by a very large degree. As an example, Subsurface Mobile, an application for scuba divers, uses Kirigami and works on Linux desktops, Android and iOS, all from the same code-base.
Make it happen…
If you like the idea of convergence, why not join KDE and help us work on Plasma? Perhaps you’d love to see Plasma on a mobile phone? In that case, consider backing the crowdfunding campaign for the librem5 so we can build a convergent phone!