The Luminosity of Free Software Episode 14

It's that time again: Luminosity! In episode 14 I'll be visiting the following topics as well as taking your questions as we go:

• Grass roots Free software promotion: A lot of the effort of introducing and generally marketing Free software to the public lands on the shoulders of companies these days. They tend to be able to grab a larger audience than the average individual and they can keep pounding out a message for an extended period of time. Yet .. Free software as a concept and many of the best Free software products are not very well known. Is there an opportunity for effective grass roots promotion?
• Wesnoth: Looking at my list of possible topics, I realized that I had been covering a fair number of serious topics and very few frivolous and fun ones. So why not .. let's have some fun this week and take a look at Wesnoth, what makes it tick and keeps people not just playing it but still developing it after all these years. We'll try not to get sidetracked into an actual game as we look at this venerable Free software game.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

You can join live tomorrow on G+ or Youtube at 18:00 UTC, with live chat on irc.freenode.net in #luminosity, or catch the show later on my Youtube channel. See you there!

New Plasma scripting features in 4.11

Since Martin blogged about the new scripting related features in kwin coming to 4.11 today, I figured that I would do the same for plasma-desktop.

Plasma Desktop Scripting

After having been asked for the ability to read and write from other user config files in Plasma Desktop Scripting for the Nth time, I finally buckled down and implemented it. It is documented on the desktop scripting wiki page and using it looks something like this:

// open the kickoffrc file
var config = ConfigFile('kickoffrc');

// switch to the RecentlyUsed group
config.group = 'RecentlyUsed';

// write an entry into it
config.writeEntry('MaxApplications', 25);


// now put Yes=20 into RecentlyUsed/Test
var config2 = ConfigFile(config, 'Test);
config2.writeEntry('Yes', 20);

This is actually re-using the KConfig bindings written by Sebastian Kügler for QML that we ship in the Plasma Active Settings QML import, so it turned out to be very little work to add it, test it and push it for 4.11.

QML

QML is the way write visual Plasma addons such as plasmoids these days, and so it is the support that gets the most attention and love. In addition to numerous bug fixes to the various components and imports, the following new features are available in 4.11:

• A plasmoid (or other) package can provide fallbacks for SVGs that are themed. This allows a plasmoid to safely use an SVG that may only be in some themes while providing its own fallback. Taking this even further, you can even provide SVGs for specific themes by dropping them in a folder that shares the theme's name.
• A units object was introduced that provides compatibility with Ubuntu Touch's object of the same name. They work identically, and the idea is to make writing apps that target multiple platforms a bit easier. Scanning through various QML applications written with Ubuntu Touch in mind, this was by far and away the most often used bit of their API. Personally, I disagree with using such literal units and prefer to have fluid layouts, but compatibility is a boon for all QML platforms.

Most of the work done for 4.11 in the QML support was bug fixes and polishing. This is to be expected as the support is now quite mature and further feature work for QML support has shifted to Qt5's QML2 for Plasma Workspaces 2.

Polish all the UI!

I've been watching a great set of threads roll by in my email related to a re-boot to the human interface guidelines used by the KDE community. The blog posts by Thomas and Björn explaining what they are up to are great reading and it gives those of us who are developers a really good reminder about user interface fit and finish. ( .. and therefore the above ironic memegif ;)

Inspired, I spent a bit of time in the wallpaper setting dialog yesterday working on visual consistency and typography issues. The fixes were all little things that are pretty unsexy and would not make for an interesting blog if weren't for this new HIG work. It is these "little" things, however, that make things feel not just more polished but more trustworthy and desirable to use. It creates a comfort that people respond to on an emotional level. They find themselves moving through their tasks with more ease and less distraction; the human mind is very good at ignoring sameness and by contrast picking out differences.

So this is a little note of encouragement to my fellow developers for us to pay attention to the human interface guidelines as they take further shape and to redouble our effort to polish the GUI.

Note that we've been working on a HIG that is relevant for touch, also led by Thomas, and as that has been taking more and more shape it will become an important resource for those building applications with QML for devices who wish their interfaces to rock. Just as we have managed to keep a unity on the desktop between the user interfaces, we can do the same on mobile.

App stores: the disappointments

During development of Plasma Active, I resurrected an idea that a couple of us had tinkered with a year or two earlier: creating an open content store. We have ended up creating something fairly different than what is available out there right now and none of these differences are accidental. Before launching into a description of what this system is and how it works, I thought I'd start with a short blog entry describing the things we were not happy with in the state of the art of app stores. Later in the week I'll follow up with a description of our solution. For now, here is a little list of disappointments:

• Proprietary implementations. For some reason there haven't been significant Free software offerings in this area, even in Free software contexts!
• Centralized control. Trusting your content delivery to a gatekeeper entity's whims is madness.
• It's a store. Emphasis on "a": one front end, one catalog of content.
• App stores are .. well .. app stores. Music and books and art and other things are usually presented separately. 
• Feedback mechanisms are quite obviously afterthoughts. No one makes money off of those star ratings and commens, so why bother?
• Single economic theory. There is a single economic theory that drives all these stores. Want to have a store for a school system that uses a different economic model? Good luck.
• Limited opportunity for tie-ins with Free culture (including free software) and independent production houses.

These are the things we identified as unnecessary and annoying. We went to work on something that was different. It's in git.kde.org right now and actively developed. As mentioned earlier I'll be presenting the model it embodies in a blog entry later in the week.

Until then: what are your least favorite things about the current incarnations of online services we have come to know as "app stores"? Let us know in the comments below!

quick update on vivaldi hardware

Here's a very quick and terse update on where we are with hardware for the long-awaited (by me if noone else ;) Vivaldi tablet hardware:

• SoC PCBs: done
• Mer: booting
• Plasma Active: starts
• X11: running, still toying with opengl
• Still waiting on a pair of drivers
• Casework being tweaked to smooth out some rough edges
• Screen components: sourced and ready

Which means we are finally, after months of unexpected delays (it's amazing how many different ways a PCB can be done in not-quite-the-right way ...) we have production designs in the box. We're not quite at the point where we can send them shuffling off the production line into little boxes to send to you, but we actually have a device that works and whose design we own so that our ability to deliver is in our own hands.

During this time we've moved our focus from the single core SoC to a pin-compatible dual core version to keep up with the times a bit as well as brought a better screen into the mix. I would like to post official specs but I don't want to tempt fate into changing anything on us as a result. See how projects like this can turn an otherwise secular minded person superstitious? ;)

We will be rolling out the new website, specs, ordering and unveiling content store opportunities nearly simultaneously. The path to an open device has been insanely long. We aren't doing this on our own, however. We are working with a number of companies in Europe and a handful of companies in Asia on the engineering and production sides. In the process, we've ended developing what is a pretty snazzy little hardware tinkerer's device as well which we plan to make available separately from the tablet devices for those of you who like playing with such things. Below is a video showing one of these devices in action:

theming plasma

Lately I've noticed a number of new themes popping up for Plasma Desktop, which is quite cool. Things like this mash-up by Pawan Yadav:

and this Google inspired one by Half-left:

Combined with things like the Plasma Panels Collection it is pretty impressive what one can achieve. Moving into the Plasma Workspaces 2 era, this is only going to get more interesting as we introduce the Look and Feel packages that compliment the icon and SVG themes and bring the various user experiences (desktop, netbook, tablet, etc.) closer together for fast UX switching.

One thing I keep dreaming about is a group of artists who enjoy this kind of work and have experience bending Plasma to their will coming together to create some ellegant and distinctive artwork and then pitch that work to the wider KDE art community. No asking of permission involved, just come up with a refined and audacious proposal for the desktop theme. In the worst case scenario we'd have something great for users of Plasma workspaces to optionally select .. and in the best case scenario we might find consensus on a new visual twist for Plasma Workspaces 2.

Until then, I'm enjoying the swell of art and presentation that can be used right now with Plasma Desktop.

The Luminosity of Free Software, Episode 13

Lucky number 13? Maybe! Tomorrow "Luminosity" will get its thirteenth installment.

• Why we work together, and why we sometimes don't: In Free software, forking used to be seen as a really bad thing reserved for unfixable situations. These days it happens all the time. Duplication of  effort was usually met with "Why?" rather than "Why not?", and typically reserved for the "beginner's application topic" (Was text editors, then irc (or mud!) clients, then media players, ..) Have we forgotten culturally the benefits of working together? Have new priorities shifted the playing field? When does it make sense to I'll try to make the case for less diversity than we have now, or at least a more responsible investment of effort.
• Open Build Service: We'll be looking at one of the coolest tools out there for people building software, images and operating system distributions: Open Build Service. We'll look at how it works, how it can be extended and at some self-hosting options.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

You can join live tomorrow on G+ or Youtube at 18:00 UTC, with live chat on irc.freenode.net in #luminosity, or catch the show later on my Youtube channel. See you there!

Plasma Workspaces 4.11: A long term release

We are nearing the soft feature freeze for the 4.11 release, and that seemed like a good time to share some news. Plasma Workspaces 4.11 is going to significant for two reasons:

1. It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
2. We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.

Before going into more details, let me offer a preemptive clarification:

This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.

With that out of the way, some details!

Long Term Release

One of the most exciting things about this direction is that our distribution and packaging partners will be able to have a version that will see releases which focus exclusively on stabilization for at least two years. There will be no new features added after 4.11.0 to Plasma Desktop and Netbook, though the code will be adjusted as needed to maintain and improve existing functionality. This should make Plasma Desktop 4.11 an excellent candidate for inclusion in distributions that have a longer shelf-life.

This is a great opportunity to get changes in that polish things up as they will be available for a long while. Often between releases whole components are revamped and sometimes this results in some polish being lost temporarily. With a long lifespan, these improvements will be allowed to naturally accumulate to the benefit of those using it.

We expect that these ongoing releases to overlap with, and indeed continue after, the initial release of Plasma Workspaces 2.

This was one of the secrets behind the success of KDE 3.5 (back when we called the whole thing "KDE" .. more on that later, though): it had releases for a very long time that focused nearly exclusively on stabilization and polishing. We were working towards the 4.0 release at the time, but it showed that having such a release supported for a longer time can be quite a good thing. We actually did two releases for 3.5.x after 4.0; we even announced our intention to do this when we released 4.0. Unfortunately, the world basically ignored that and one reason might have been because it got buried beneath the excitement around the new major release.

Hopefully by announcing it early and getting the long term release version out well in advance of Plasma Workspaces 2 it will work better and distributions will be able to build plans around it effectively.

Decoupling the Software Compilation (Somewhat)

As KDE's software projects have grown in scope and number, one thing that became increasingly clear is that a single development and release cycle no longer fits all of the projects equally well. Large mature libraries benefit from longer and more conservative cycles while smaller and newer components benefit from rapid iteration. Releasing twice a year may be enough for a desktop shell, but for many applications six months is a larger window than is comfortable. When we add in dependencies between the libraries and the applications, having to time everything just right to take advantage of additions to the libraries becomes increasingly difficult.

This was one of the concerns we took into consideration when repositioning the KDE brand a few years back. We reappropriated the term "KDE" for the community of participants and gave names to each set of software. With KDE Frameworks 5 (the next major release of KDE's core libraries) and Plasma Workspaces 2 both being developed in tandem, we are now free to set each on a release and development schedule that works for them. We won't have to compromise in either direction just to find a single release date that works for both. This also means that application developers won't be hung up waiting for Plasma Workspaces 2, either. They'll have a great 4.11.x workspace to use and develop in and will be able to move to Frameworks 5 independent of where Plasma Workspaces 2 is in its development and release cycle.

I fully expect that we will continue to have coordinated release days for KDE software, and I actually hope that more software will release on those days as we move beyond the strict nature of the "software compilation". However, development cycles will not be the same and some projects will release more often than those couple of times per year. There is a lot of discussion and planning to be done before this is fully implemented and working. This is simply a first small step from the Plasma team towards this.

It's taken a few years to get to this point due to having to wait for the right moments to engage certain aspects of these plans, but it feels very good to approaching the place we envisioned.

Shortening the Wait for Plasma Workspaces 2

Due to all of the above, we will be able to focus our feature development efforts squarely on Plasma Workspaces 2. We will also be able to do releases when it is ready, independent of Frameworks 5. It is not outside the realm of possibility, for instance, to see an initial Plasma Workspaces 2 release on top of a technical preview of Frameworks 5.

By focusing our attention and creating sensible schedules for each component, we will be able to get to Plasma Workspaces 2 as quickly as possible (though no quicker). It also is allowing us to broaden the scope of Plasma Workspaces to bring in a number of "orphaned" modules, such as networkmanager or bluedevil. These components are currently developed in their own repositories and outside the KDE software compilation development cycles. This makes lots of sense for these projects as they can iterate faster and release when necessary more easily. Unfortunately, it makes coordination and integration harder.

With Plasma Workspaces 2 approaching and following it's own rhythm we will be looking to pull more of these projects together. The networking plasmoid, for instance, should not be an add-on developed outside the main workspace efforts, but a properly integrated feature with the ability to participate in the direction setting. So instead of producing a core shell and then waiting for all the pieces to eventually catch up, as we have done in the past, we're working to ensure a complete experience sooner.

How We Arrived At This Decision

We first discussed these ideas among developers who work on Plasma Desktop. We broadened the discussion to the general Plasma developer community, and finally looked for the consensus within those discussions while at the recent Tokamak 6 meeting. We communicated this back to the wider KDE community, first by approaching the release team and ensuring the idea was feasible from their point of view. We then posted an announcement to the kde-core-devel and packagers mailing list with further details. Those discussions have run their course, and so now I'm taking some time to share it with you. :)

The plan has been formulated by consensus (which is not the same an unanimity) and it took quite a while to arrive at as a result. However, it got a lot of great feedback and realistic concerns which has improved the resulting plan in many ways. It's still plastic, however, and we can and will adapt it as necessary as we move forward with its implementation.

Visual harmony in Plasma Workspaces 2

One of the big things we've accomplished on the road to Plasma Workspaces 2 is making all the desktop "chrome" use Qt Quick (nee QML). The log out dialog, the lock screen, the splash screen, the log in screen, the activity manager and widgets explorer .. everything.

(Well, with the exception of KRunner, which I actually have rendering with QML in a branch in kde-workspace, though it is not quite complete yet. You can do searches, results come back, etc. but a few things like configuration are missing.)

We recently defined a new package type, the Look and Feel package, that will hold all of the QML used to render these various components. The idea is simple: by having everything in one package, you will only need to select your preferred look in one place and the entire desktop will conform. This is a natural extension of the ideas behind the SVG theming, bringing consistency to the user interface itself.

I'm very excited about this as it will allow us to put some of the professional, elegant touches that are currently missing. I've probably mentioned it in my blog before, but the fact that the log out dialog is a dialog at all (with a moon!) bugs me every time I see it. Understanding why it is a dialog (with a moon!) helps explain how we got to this point in general.

Each of these user interface components were originally designed way back in either the KDE1 or KDE2 eras. Windows and widgets fit the design sensibilities of the time, so when you go to log out you just got a little window that sat in the middle of your screen asking for confirmation. There were no desktop effects (so no nice fading of the screen) and certainly no ability to do anything very pretty other than traditional widgets like push buttons as seen in every other application; but we could do images. So someone put a picture on the left side of the dialog. Pretty! Shiny! .. and it was. For the time.

Since then we've iteratively improved everything around and under these components, but these bits of the UI themselves were translated faithfully from one version to the next. So even though there is no reason to do it this way now, the log out dialog still has things that look like little push buttons and it still has inexplicable picture on the left, despite now being written in QML and having all the power that implies.

Plasma Workspaces 2 is our opportunity to improve these parts by harmonizing and modernizing them. The log out interface ought to look like it belongs with the lock screen; the log in screen ought to mesh with the splash screen; the activity manager should echo these components visually; etc..

We have a couple people who can do this kind of work, but they have lots on their plate already. This is a great opportunity for someone with a flair for design to get involved and help draw all these pieces together to help create an improved KDE Plasma Desktop.

If you are that person, or know someone who could be, get in touch with us and let's talk. (aseigo at kde.org works for email.)

The Luminosity of Free Software, Episode 12

Here it comes: episode #12 of The Luminosity of Free Software. Tomorrow we will do the usual three-topics-and-questions dance on a Google+ hangout. The topics will include:

• Emergence of the Linux Design Philosophy: The UNIX philosophy of "do one thing, do it well" and "everything is a file" are both being increasingly marginalized by new design concepts in Linux which put more emphasis on consistency, completeness and service architecture. As the effort and attention that UNIX enjoyed in past decades has shifted significantly onto Linux, this is an important development and I'll look at some examples of the new philosophy in action and share my thoughts on the upsides (and potential pitfalls).
• haproxy: I had the pleasure of finally getting to know this interesting bit of software and was impressed by its power and flexibility. It bills itself as the "reliable, high-performance TCP/HTTP load balancer" but what I was really impressed with was the number of things you can do with it.
• VTK: The visualization toolkit, by the same folk who bring us CMake, is an amazing visualization library and recently hooked a $2.4 million research grant. What makes VTK special, and is public funding a viable model for technology creation?
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

You can join live tomorrow on G+ or Youtube at 18:00 UTC, with live chat on irc.freenode.net in #luminosity, or catch the show later on my Youtube channel. See you there!

Recently Muktware started covering KDE related news in a section they call KDE Sutra. The writers and editors are people who believe strongly in Free software and it shows through in their efforts in my opinion. In any case, they recently invited me to write a little bit about KDE. I ended writing a bit more than a little, and you can read the article here: "A Community Made of Momentum".

While writing it, I rolled around a lot of old and familiar thoughts in my head. Free software is focused on technology; however, there is a strong social and ethical aspect to it, whether one cares to pay attention to that or not. This is because there are people at the center of it all creating that technology. Whenever groups of people get together to make things, there are social and ethical profiles that emerge from these activities. Often the social aspects don't receive much attention: they just are.

Free software is a special (though not remotely unique) construction in that there are people who care deeply about those social constructs and the ethical implications and who spend time thinking about them, documenting them and shaping them. The GPL was perhaps the first step in this, but it has certainly not been the last.

Many Free software projects don't spend much, if any, time considering the shape of their community constructs. They rely on the emergent properties of humans coming together to do the right thing. This often works, and it also often doesn't. Many of the worst dramas in Free software in past years could have been ameliorated, and possibly avoided outright, had it been left a little less to chance and self-emergence and purposeful thought applied to this side of things.

I'm not suggesting that the hackers should put away their IDEs, the artists their digital paintbrushes, the documentation and translation teams their editors. There ought to be a few people in each Free software community that is bigger than small who spend some time ensuring that the non-technical structures of their community are kept in working order and progressing forward.

A goal of such efforts is to bring it full circle and have these efforts expressed by improvements in the technology that is created and in the reach into the world around us that it has.

The balancing practice in such efforts is to ensure that these efforts do not retard the pace of technological advancement or otherwise hijack the technical efforts.

No system of people is perfect, but they can progress and they can be healthy and sustainable. They can be rewarding and enjoyable and productive. KDE is one such system, and the technology we've created over the last decade-and-a-half are the record of that.

This is what I was trying to capture in the article written for Muktware, and hopefully it comes through when you read it.

Cheers, hugs and happy hacking ...