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.)
Thursday, May 09, 2013
Wednesday, May 08, 2013
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!
Friday, May 03, 2013
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".
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 ...
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 ...
Wednesday, April 24, 2013
Luminosity of Free Software, Episode 11
After a week away at an intense dev sprint in Germany, I'm back in the home office and that means another Luminosity of Free Software episode! This week on the menu are:
I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.
- Riak: a distributed data store that strives for eventual consistency rather than ACID. Inspired by the CAP theorem, this key value store is aimed at big data but is really fascinating for anyone with even a passing interesting in computer science.
- Little boxes: We all know how fun the Raspberry PI is and the utility one can get out of an Arduino. What would be possible with higher-spec devices with more useful base configurations that were still affordable and completely driven by Free software? That's the question I found myself asking the other day.
- KLyDE: This is an attempt to package KDE's Plasma Desktop in a more conservative way with a goal of trading out features for resources. We'll look at what they are actually dong, how it works with the Plasma Workspaces as they are now and what sort of impact this kind of effort could bring in future releases.
- Q&A: Where we explore the meaning of the universe, or at least the questions you lob at me. Leave questions ahead of time in the comments below or during the show in the irc channel.
I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.
Due to daylight savings changes here in Europe, the time in UTC is being pushed back by an hour. We'll go live at 19:00 UTC this Thursday, the 25th of April. See you then!
Tokamak 6: A Plasma Workspaces 2 Milestone
Members from the Plasma team assemble a couple times each year to get some face time with each other. This is good both for team building and for making large strides forward in the technology we maintain and work on. When we get together on our own, rather than as part of a bigger event, we call the events "Tokamaks". We held the sixth such meeting last week in Nürnberg, Germany where we were hosted by SUSE with additional support coming from KDE e.V.
We always set a theme for these meetings so we go in with a goal. We usually spend the first day catching up with the state of the project and each other as well as defining in detail the topics we will cover in the coming days. After the first day's presentations by attendees, we ended up with a wall full of sticky notes arranged in tracks and ready to be marched down towards the finish line.
We organized things into four tracks: the shell, kwin and Wayland, session services and startup and a catch-all miscelaneous track. Unlike some of the past Tokamaks, particularly some of the earlier ones, where we had a very clear and obvious design with implementation gaps that needed filling with code, at this Tokamak the sticky notes on the wall were dominated by design topics.
This really reflects where we are in the development lifecycle of Plasma Workspaces. Currently we have a stable desktop environment with some minor annoyances left to be addressed; bug fixes and user interface cleanups are the norm for development these days when it comes to the desktop shell. This is great for our downstream partners and users as they have a reliable environment to build upon and use.
Simultaneously, over the last year we have also been working on a few very important developments: realizing our device spectrum vision and moving to Qt5 with KDE Frameworks 5.
In the process of creating Plasma Active (and three subsequent major updates to it) we learned a lot about the power of the Plasma framework and QML. We also learned how it could be better. Sometimes it was simply confirming what we knew needed more work and sometimes it was revelatory. It all came to a head at Tokamak 6 where we took the opportunity to put firm blueprints down on our sketches.
Perhaps the most critical development is the creation of the unified shell. Right now all of the Plasma Workspace share most of their code, but they each carry a separate binary that essentially launches the desktop layer. Bringing together the efforts from desktop, netbook, active and elsewhere, we have developed a single binary that can load any of these shells and which will be able to switch between them at runtime.
The power of this idea was aptly summed up by Marco Martin who wrote, "One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment." This is an ultimate form of doing more with less and the culmination of some 6 years of effort.
This causes an interesting series of knock-on requirements. First, we need a package that can describe what a given workspace means. What makes up a desktop, what makes a tablet, what makes a netbook? We now have a package definition that includes all custom QML for the shell, the initial setup (done with Javascript, just like it currently is), default settings, processes to ensure are started (and later stopped), window manager tweaks, etc. We are still researching some aspects of this, but a working definition was put down.
This also implies that KWin needs to be able to adjust at runtime. Much of the underpinnings are already there, so this will ultimately be a short hop for KWin. A new KDE daemon plugin (kded module) has been written that tracks what the current shell is along with its runtime attributes (e.g. does it have a mouse, or does it rely purely on touch?) to coordinate this between the different processes.
With a single shell, this also means that all the "helper" interfaces need to follow suit. Things like the lock screen, the logout interface, user switching, the login manager, etc. We've worked hard over the last few releases to make sure that all of these things can now be done in QML. In Plasma Workspaces 2 we will be introducing a new Look and Feel package that can contain QML for all of these components. This means that you can switch, customize and share themes using a single package in a single location on disk. (That's a bit of a simplification as there is a transparent fall-back mechanism, but this is already getting long enough. :)
 |
| Tokamak 6 Kaban starting line |
We always set a theme for these meetings so we go in with a goal. We usually spend the first day catching up with the state of the project and each other as well as defining in detail the topics we will cover in the coming days. After the first day's presentations by attendees, we ended up with a wall full of sticky notes arranged in tracks and ready to be marched down towards the finish line.
We organized things into four tracks: the shell, kwin and Wayland, session services and startup and a catch-all miscelaneous track. Unlike some of the past Tokamaks, particularly some of the earlier ones, where we had a very clear and obvious design with implementation gaps that needed filling with code, at this Tokamak the sticky notes on the wall were dominated by design topics.
This really reflects where we are in the development lifecycle of Plasma Workspaces. Currently we have a stable desktop environment with some minor annoyances left to be addressed; bug fixes and user interface cleanups are the norm for development these days when it comes to the desktop shell. This is great for our downstream partners and users as they have a reliable environment to build upon and use.
Simultaneously, over the last year we have also been working on a few very important developments: realizing our device spectrum vision and moving to Qt5 with KDE Frameworks 5.
Single Shell Theory
Many readers of this blog are familiar with Plasma Active which is a Plasma Workspace template for mobile devices; our reference device there has been tablets, but it certainly is not limited to that in any way. This effort which started in 2011, with the first release coming in October of that year, was the next logical step in the plan to build a user interface that spans devices from phones to tablets to media centers to desktops to things we aren't even looking at right now but you might be.In the process of creating Plasma Active (and three subsequent major updates to it) we learned a lot about the power of the Plasma framework and QML. We also learned how it could be better. Sometimes it was simply confirming what we knew needed more work and sometimes it was revelatory. It all came to a head at Tokamak 6 where we took the opportunity to put firm blueprints down on our sketches.
Perhaps the most critical development is the creation of the unified shell. Right now all of the Plasma Workspace share most of their code, but they each carry a separate binary that essentially launches the desktop layer. Bringing together the efforts from desktop, netbook, active and elsewhere, we have developed a single binary that can load any of these shells and which will be able to switch between them at runtime.
The power of this idea was aptly summed up by Marco Martin who wrote, "One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment." This is an ultimate form of doing more with less and the culmination of some 6 years of effort.
This causes an interesting series of knock-on requirements. First, we need a package that can describe what a given workspace means. What makes up a desktop, what makes a tablet, what makes a netbook? We now have a package definition that includes all custom QML for the shell, the initial setup (done with Javascript, just like it currently is), default settings, processes to ensure are started (and later stopped), window manager tweaks, etc. We are still researching some aspects of this, but a working definition was put down.
This also implies that KWin needs to be able to adjust at runtime. Much of the underpinnings are already there, so this will ultimately be a short hop for KWin. A new KDE daemon plugin (kded module) has been written that tracks what the current shell is along with its runtime attributes (e.g. does it have a mouse, or does it rely purely on touch?) to coordinate this between the different processes.
With a single shell, this also means that all the "helper" interfaces need to follow suit. Things like the lock screen, the logout interface, user switching, the login manager, etc. We've worked hard over the last few releases to make sure that all of these things can now be done in QML. In Plasma Workspaces 2 we will be introducing a new Look and Feel package that can contain QML for all of these components. This means that you can switch, customize and share themes using a single package in a single location on disk. (That's a bit of a simplification as there is a transparent fall-back mechanism, but this is already getting long enough. :)
Qt5, Frameworks 5 and Wayland
Complimenting the single shell approach is the move to Qt5 and KDE Frameworks 5. These are the new releases of the libraries we currently use from the Qt Project and KDE. Thankfully, most of the API has not changed much or at all in these version bumps. Unfortunately, Plasma Workspaces uses two things that have changed a lot: interaction with the windowing system and the QML engine internals. So we've had to pick up our socks and do a lot of work on the internals of the libraries and some of the core apps.
We've actually been able to do quite a lot of this in the Qt4 based versions, so many of you have already seen some of the benefits of this work probably without even being aware of it. After the 4.11 release this summer, however, we plan to shift our focus to pushing out the Qt5 based release.
When will that release happen? We have not discussed it with the KDE release team, nor do we have a firm fix on some aspects of Frameworks 5 so it's too early to commit just yet. We did something equally important, however: we defined what would make this release qualify as being "done" for release.
The principles we agreed to are simple:
- Do not break current workflows; what works now, must work as well or better in the new release
- Stability; it needs to be usable for daily use
- Harmonize all the interface pieces that are now on a common technology footing (QML) but do not reflect that due to disharmony in the visual and interface design
Also part of this move is completing on another multi-year goal we've been working on: being able to support Wayland for the graphics stack and windowing system. We are relying on features in Qt5 for this and KWin has also needed much work to make the transition cleanly, but now it is all coming together. While some seem to be viewing the move away from X11 and x.org as a sprint, we have viewed it as a marathon: a long distance run that you have to plan careful and resolve to finish in the best time you can.
Miscellaneous?
There will also be a number of other small improvements here and there under the hood. For instance, I presented a proof-of-concept rewrite of RunnerManager which is used by KRunner, Plasma Netbook, Kickoff, Home Run and others. The goal is to simplify its threading and thread the things which aren't currently threaded for a zero-interface-thread-blocking design that is also a bit more flexible and which should also be kinder on memory.
Improvements in network management, power management and session startup are also on the table and being worked on.
I highly recommend reading some of the blogs by others who attended this or the parallel Solid sprint to get a further feel for things. That would include Marco's, Martin's, Sebastian's and Lukas' entries.
Wednesday, April 10, 2013
The Luminosity of Free Software, episode 10
Last week went without a LofS show, sadly, due to me laying about in bed being ill after what had been a very enjoyable and blissfully peaceful Easter weekend get away. That'll teach me for having fun, right? ;) Well, I'm back and that means another episode this week. Due to my schedule this week, it will once again be on Friday but I will be returning to the "full length" format. So what will we be exploring this week?
- Plasma Workspaces 2: Next week there is an extremely important meeting taking place in Nürnberg, Germany to devise answers to some of the remaining open questions, draft a roadmap to the first Plasma Workspaces 2 release and hack until dawn. With this event coming up, I'll take some time to explain the main changes that are coming with Plasma Workspaces 2 and how it will make your usage experience a bit better.
- What is QML? After an interesting set of discussions recently with people about just what is QML, I thought a segment on this topic from someone who has actually been there from pretty much the start, who has actually read through things like the parser code and worked extensively with it (namely: me ;) could be interesting. In a nutshell: we'll look at how QML gets process from text files into pixels on your screen.
- Vivaldi's open hardware: I'll share some photos of the silicon we've developed for the upcoming Vivaldi that is just now coming out of the factories along with some descriptions of the technologies we've decided to use, including how we've created what will probably be the first upgradable tablet to hit the market.
- Q&A: The usual game of "throw a question at Aaron", this time sparkles and rainbows! Well, maybe sparkles and rainbows. Definitely answers, though.
So, yes, this episode is a little more self-indulgent than past episodes in that I'll be talking about things that I'm involved with in some fashion or another .. but perhaps that's a fun way to celebrate hitting episode #10.
I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.
We'll go live at 20:00 UTC this Friday, the 12th of April. See you then!
Thursday, March 28, 2013
Luminosity of Free Software, Episode 9
Today I will be recording the 9th episode of "Luminosity" and it will be a short episode, in part because of time constraints I'm facing today but also because I'd like to experiment with the setup of the show to see if it can fit into a 30 minute form and how the viewing audience finds that.
So .. there will be only one topic this week plus the usual Q&A session:
So .. there will be only one topic this week plus the usual Q&A session:
- Mer: A (not so) new (mobile Linux) hope. The project and the community, a history and an update. We will look at what the Mer project provides and who uses it, visit the community structure and introduce the brand new build service that rolled out to replace the MeeGo build service that is being closed down.
- Q&A: Ask me anything, and I might answer it .. history shows the likelihood of that is actually pretty high.
See you there on Google+ Hangouts at 20:00 UTC. Chat and questions can be found on irc.freenode.net in #luminosity.
Saturday, March 23, 2013
freedom abhors singularity
Today on the interwebs I read an interview with a certain Free software project leader who stated that they were making:
Usually the only way to ensure a monopoly exists in a free society is to mandate it via government (or its equivalent) regulation. Very rarely do monopolies form on their own in free societies, and usually when they do form it is due to an abuse of the system and unless systemic corruption is maintained to support that situation (in which case, is it a free society?) then society tends to attack the monopoly resulting in either a curbing of its power or even a forced breakup. This creates a new period of opportunity and competition and the singularity is removed.
Sometimes a group comes up with an idea first, or figures out how to apply an existing idea in practical ways first, and due to this first-mover position initially monopolizes a given niche. In a free system this innovation is often very quickly replicated, or at the very least reacted to, by others and such monopoly is short lived. We can find endless examples in biological evolution as well as human technology for this exact process. This is also why the patent system came into place: this replication of good ideas in free societies can be so efficient that it makes it hard to profit from good ideas without some mechanism of protection.
(Aside: this implies that patent systems are only valuable when they reflect the real ratio of initial effort investment to reward rate.)
This is why most markets (economic, political, social, ..) have multiple competing parties. This competition drives everyone forward and reduces the risk associated with a single point of failure, which is socially beneficial. As a result, free societies tend to outpace societies with less freedom: by artificially enforcing singularities improvement incentives are reduced and risk associated with failure is driven up.
So whenever I hear someone say that their plan involves being "the only" thing in a free society, I assume they don't understand much about free societies. When this is coupled with adjectives such as "true" it starts to smell of fundamentalism.
Free software intrinsically exists in a free society: it is mandated in the licenses. The only ways around this are to artificially create singularities by monopolizing the talent pool (hiring all the developers) or keeping all decision making power in one central place that is guarded by veils of inscrutability and a lack of accountability. People who think this way are not the sort of people I would like to see directing free software; it is a recipe to curb the intrinsic freedom brought by free software.
Instead, we must embrace the sustainable and powerful forces of free systems, which includes diversity and competition and almost never being the "only" of anything that is usefully important.
The world's premier and, in fact, only truly free software operating system.Ignoring that it doesn't actually hold up to scrutiny (there have been many "truly free software operating systems"), this brought to mind a spectacular feature of freedom: it abhors singularity. Indeed, monopoly positions are exceedingly rare in free systems.
Usually the only way to ensure a monopoly exists in a free society is to mandate it via government (or its equivalent) regulation. Very rarely do monopolies form on their own in free societies, and usually when they do form it is due to an abuse of the system and unless systemic corruption is maintained to support that situation (in which case, is it a free society?) then society tends to attack the monopoly resulting in either a curbing of its power or even a forced breakup. This creates a new period of opportunity and competition and the singularity is removed.
Sometimes a group comes up with an idea first, or figures out how to apply an existing idea in practical ways first, and due to this first-mover position initially monopolizes a given niche. In a free system this innovation is often very quickly replicated, or at the very least reacted to, by others and such monopoly is short lived. We can find endless examples in biological evolution as well as human technology for this exact process. This is also why the patent system came into place: this replication of good ideas in free societies can be so efficient that it makes it hard to profit from good ideas without some mechanism of protection.
(Aside: this implies that patent systems are only valuable when they reflect the real ratio of initial effort investment to reward rate.)
This is why most markets (economic, political, social, ..) have multiple competing parties. This competition drives everyone forward and reduces the risk associated with a single point of failure, which is socially beneficial. As a result, free societies tend to outpace societies with less freedom: by artificially enforcing singularities improvement incentives are reduced and risk associated with failure is driven up.
So whenever I hear someone say that their plan involves being "the only" thing in a free society, I assume they don't understand much about free societies. When this is coupled with adjectives such as "true" it starts to smell of fundamentalism.
Free software intrinsically exists in a free society: it is mandated in the licenses. The only ways around this are to artificially create singularities by monopolizing the talent pool (hiring all the developers) or keeping all decision making power in one central place that is guarded by veils of inscrutability and a lack of accountability. People who think this way are not the sort of people I would like to see directing free software; it is a recipe to curb the intrinsic freedom brought by free software.
Instead, we must embrace the sustainable and powerful forces of free systems, which includes diversity and competition and almost never being the "only" of anything that is usefully important.
Subscribe to:
Posts (Atom)
