let's play a game!

Let's a play a game of "Spot the New Feature"! Here's a screenshot, submitted by our own Helio, that shows a new feature in Plasma that will debut in KDE 4.4:

Can you spot it? If so, leave your answer in the comments! Once someone has guessed it correctly, I'll blog again about this new feature, and other things coming in 4.4, in greater detail.

(Oh, and if you hang out in #plasma on irc or are a member of the Plasma team, please don't give the answer away. :)

This feature is also a neat example of how we work together in Plasma, building on top of what each other does, filling in the blanks when someone else gets stuck and riffing on each other's ideas. This particular feature was built on top of some work done in 4.2 by Jason Stubbs; the feature itself was started by Sebastian Kugler and finished by Marco Martin using some hints from a similar feature I fixed up for 4.3 in the system monitor widget, which in turn was written primarily by Petri Damsten.

(... and yes, I know, 4.3 isn't even out yet and we're already teasing you with new things ;)

Read More

saving freedesktop.org together

You know that scene in movies where the doctor comes out of the surgery with a mask dangling around their neck and a solemn look in their eyes to greet the family who has been waiting what seems like forever in the waiting room? This is that scene. I'm that doctor. freedesktop.org is the patient. You are the family.

freedesktop.org is in really bad shape. There, I said it. Most of us knew it, but now it's been said. The good news is that it's rescuable. The even better news is that people want to rescue it, and some are actually doing things to make it happen.

Let me back up a bit, though. What is freedesktop.org supposed to be? Well, it's supposed to be a place for people working on F/OSS desktop projects to come together and collaborate on shared designs and shared software. It's been successful in bringing together drag and drop, window manager hints, application menus, icon themes, bookmarks, D-Bus and much more. This is valuable work and freedesktop.org is, or at least should, be vital to the F/OSS desktop platform.

It has seen better days, however. Currently it suffers from two major illnesses: administritus and anarchiosis. ;)

First, the administritus. freedsktop.org has infrastructure related to it: a website, cvs and git hosting, a bugzilla instance. This infrastructure is overseen by a group of administrators. These people are expected to be around whenever needed to set up accounts, approve projects and specifications for entry and do general sys admin type stuff as well. This means that they not only have to have lots of time and energy, but have to have a good idea of what's going on in the F/OSS world for each and every topic brought to freedesktop.org. They need that knowledge because it is them who gives the final "yes" or "no" to something being hosted on freedesktop.org. This is a completely irrational set of expectations, and the admin team is therefore performing as one would expect: below the par of what we need.

Now, I don't blame them as individuals .. I just think the expectations are insane and we, the projects, haven't given them enough support. We ought to have more KDE, GNOME, XFCE, etc. project people with admin privileges to help out. We don't, and that probably needs fixing.

However, that's just infrastructure. freedesktop.org isn't, however, infrastructure. freedesktop.org has infrastructure. It is the people who come together to work collaboratively who are freedesktop.org. Think of it this way: if KDE's svn server disappeared tomorrow, a new system would get set up in short order as best the community could manage and we'd get on with it. New infrastructure would emerge. If the KDE contributor community disappeared tomorrow, the existing infrastructure would not magically create new community. Therefore KDE is the community, not the infrastructure. freesktop.org, indeed any F/OSS project, is the same.

So while we work on solutions to the administritus, we are already working on the anarchiosis. What is that?

Right now it's very hard to get things on freedesktop.org, and not everyone trusts the freedesktop.org hosting due to past outages. The result is that we have work being done all over the Internet with little transparency to others.

There's also no way to know who has implemented which specification or uses which pieces of software associated with freedesktop.org. That's bad enough for those of us in the related projects that participate in freedesktop.org, but it's a deal killer for third parties on the outside looking in who'd like to implement support for the platform.

The admin team has the final say in what goes in and what doesn't, which means that people are not allowed to just work on what they want and let things bubble up. It's a top down approach that discourages people and prevents the best decisions possible from being made.

Finally, there is little to no leadership or process applied to freedesktop.org. When two people have a problem with each other, it's up to them to duke it out. When someone wants to use org.freedesktop for a D-Bus service name, there's no way to figure out if that's Ok to do and, if it isn't, no way for the rest of the participants to veto that.

The result is an inefficient system that is completely opaque to most would be participants that revolves around politics, bad decisions and arguments. Anarchy, and the bad sort at that. Several specifications are in danger of becoming defunct, forked or simply never see the light of day because of this case of anarchiosis.

So .. what do we do? We damn well fix it.

To bring some stability to the ills of freedesktop.org I gave it a swift kick in the nuts this past week in order to wake up the slumbering souls that populate the xdg list. This came via Plasma's implementation of the galago notification spec in 4.3. At issue were some very poor moves that accompanied the creation and maintenance of that specification, starting five years ago and continue to today. (I won't go into the details, it's been hashed through enough on the list and there's nothing to be gained by airing it even more publicly.)

Simply put: we had had enough of the shenanigans that are a direct result of the structure, or lack thereof, within freedesktop.org and we put our collective foot down. I wanted to make people own up to how broken things are. I think that was accomplished. Awareness alone isn't enough, though.

To bring some transparency to the process of specification writing, I've gone ahead and created an xdg-specs gitorious project that enables anyone who wants to get involved to do so. I started this a while ago, but it seems more critical than ever now and people are actually using it. If and when the freedesktop.org administration issue gets sorted and it's as easy as gitorious makes it to get involved with the specs process, this repository will move there. In the meantime, there's a README file explaining the proposed process in the repository, people are free to clone and work and I'm happy to add any specification author to the xdg-specs team to manage their spec in the main repository.

We can finally put all our work in one shared place, work together and document it in a way that third parties will know what we are up to. Which drafts are specs and which specs are standards can be deduced in future by simply measuring things in that documentation, such as how many, and which, projects implement which versions of that spec. You don't have to ask for permission to get involved, you just do. That's how F/OSS should work.

There are also the social ills, of course. Since nobody seems to have wanted to do much more than deepen the politics or bitch at each other or sit quietly and try to get something done amidst the chaos, I've done the silly brash sort of thing I do ... I've stepped up and have begun playing the role of facilitator on the xdg list. Nobody asked me to and I didn't ask for permission, but that's why it hasn't been done up until now: nobody is going to ask and there is nobody to grant permission. Catch 22? Nope. Sometimes you just have to step up and do it.

I'm not sure I'm the best person for the job, but at least I'm a person who will do the job. I'll stand in between people when needed, get out of the way when I can and generally make sure things work. However, I have no interest in control, title or even administration rights within freedesktop.org. (I make a crappy sys admin anyways. ;) I just want some oil applied to the moving parts so there's less friction and more movement that we can all live with.

I strongly urge the people who are attending GCDS next week to discuss these issues in person. Come up with some commitments between the projects. Get some people putting effort into these things. Stop screwing around and get your hands moving.

Save freedesktop.org, together. Or continue watching it die, day by day. It's our choice.

Read More

KDE 4.3 Plasma Overview Screencast

Ho, ho! Finally! The KDE 4.3 Plasma screencast arrives! It's 10:36 in length and covers some of the nice improvements we've in Plasmaland for 4.3, including:

• The new Air theme


• Small panel sizes


• KWin integration


• Stability & performance improvements (over 2300 bugs.kde.org defect reports triaged and closed during the 4.3 alone!)


• New widgets, including social desktop integration, remember the milk and unit converter


• New DataEngines, including Geolocation


• System tray and job notification improvements


• KRunner improvements in looks, speed and usability

The screencast doesn't cover everything new or improved in 4.3 .. that would take at least an hour instead of the ten minutes I spend in that screencast. You can find a more complete changelog here but even that is just the big stuff and doesn't catch the numerous little tweaks and improvements that have ben made.

We're not done, though. Not by a long shot. There are a lot of things the Plasma team still aren't satisfied with and several goals from the original design sketches that we have yet to implement. The good news is that we have plans in place and code underway for the KDE 4.4 release that will address many of these open issues. In my next blog entry on Plasma I'll give an overview of what we're working on, and why, for KDE 4.4.

Until then, you can grab the KDE 4.3 Plasma screencast via BitTorrent.

Update: Please keep seeding the torrent after you've downloaded it if you can. I do have a version of the .ogv on plasma.kde.org and will probably post a link to it eventually via identi.ca, but I'd really like to be kind to the server bandwidth and rely on bittorrent as much as possible.


Update 2: Direct link for those who can't torrent because they have nasty sys admins: plasma_4.3_overview_small.ogv. Over 400 seeders showing up in KTorrent right now for the torrent, though. :)

Read More

erf

Sorry for the delay in the Plasma 4.3 show-and-tell session. The last couple of days have been consumed by some (much needed) drama on the xdg freedesktop.org mailing list, cleaning out some more annoyances in Plasma (e.g. dropping the time the device notifier takes to initialize by ~85% as it was contributing to a massive slow down on startup; apps are starting to install hotplug activation entries, and the algorithm in the hotplug dataegine, which hadn't been touched since 4.0 it seems, was not ready for it) and our semi-annual "planning the next release cycle" Plasma meeting (though that's always big brush-stroke stuff; the usual flood of fixes, features and new plugins is something we just take for granted ;).

So instead of having a nice calm second half of the week, I've had a silly-busy one. No rest for the wicked, right? :) Anyways, I will be getting that Plasma show-and-tell out this weekend. It will be a screencast. I have already written out the talking points script for it.

Read More

KDE 4.3 branched, trunk is now 4.4

The release team has just done something a bit different from past release cycles to test out some modifications to our usual work flow: with the release of the first release candidate, 4.3 has been immediately branched off of the mainline trunk, and trunk is now 4.4. In the past we've done this only when the new release is actually made, not during the release candidates.

This gives people working on 4.4 features, or fixes that can only go into 4.4 due to things like string changes, a free hand without having to wait out the weeks during the extra hard freeze that comes with release candidates. This is very nice timing for Akademy, which is coming up very soon now.

That means that if you fix a bug in trunk, you now have to backport it to the 4.3 branch. I updated the svnbackport script in kdesdk/scripts/ today to target the 4.3 branch by default. Please keep up with all the great bug fixing for 4.3 so we can make 4.3.0 as solid as possible. Even though 4.3 has been branched, there is still time for yet more fixes.

It does sort of really send home, at least for me, the fact that 4.3 is essentially ready to go and to start thinking about the imminent start on 4.4. Today I bumped the version of libplasma and started a new changelog file for 4.4. The changelog for Plasma in 4.3 has become rather impressive, despite us sticking to our "only significant changes" mantra.

With this moment upon us, I feel compelled to write about some of the more interesting changes in Plasma and the KDE workspace in 4.3, and I will do so tomorrow. It'll either be text with screenshots or less text and a screencast. I'm still deciding, though I have a small list of topics written down.

Later in the week I'll lay out what we already know is going to be happening KDE 4.4 with regards to Plasma.

To those working on other parts of 4.3, I'd be really interested in reading something similar in your blogs. Little "wrap up" pieces are fun, enjoyable and informative. They're like little hugs wrapped in RSS.

Right now, however, I have to clean up and get ready: this evening I'm hosting a small "I'm leaving, huzzah!" evening at a local fine cheese shop for some friends and family. The shop is providing one of their cheese-heads, er, maître fromager to walk us through the 50-something cheeses they have in their display cabinet. Together with good company and a little wine, it should be great fun. I can't wait! :)

Which reminds me how this week is all about flux: not only is 4.3 trundling to the launch gate and 4.4 picking up its first sparks, but P. finished grade 3 this week and will be off to Vancouver in just one more week. That will mark the start of my "pack the house and move" period. So many changes and so much going on ... while it feels like there's never enough time (there isn't), I wouldn't have it any other way.

luv 'n hugs, aseigo.

Read More

weather info in plasma

So over the last week two of the major weather information providers we use and rely on, Environment Canada and BBC UK Met, have changed the location of the XML weather information on their servers. This means that weather information has broken for people using Plasma widgets with them. We don't pay for the data, so we can't complain too much, but this is really poor behavior on their part in my opinion. Evidently we can't rely on online services maintaining any sort of day-to-day compatibility.

So how do we deal with this? Right now we have 4.3.0 coming out quite soon and it will have the new URL locations in it, and we'll backport those changes to 4.2 for KDE distributors to pick up. This is a short term solution and certainly not long-term.

Update: After some further digging, it appears that BBC's weather information has changed significantly in how it is delivered (split across two files now and using RSS XML). Backporting to the 4.2 branch will be trickier than just pushing an updated URL. :/

What we will be doing in 4.4 is implementing something that's been on our roadmap for a while now: widget and data autoupdates. We'll likely be using Get Hot New Stuff and DXS for this, and the packages will be cryptographically signed. This means we'll need to finally get that KDE gpg key rocking as well as a place to host these bits of data.

Personally, I'm thinking of hosting it on opendesktop.org as they are stable, reliable, have F/OSS as their focus and already run DXS services. That does mean that your Plasma would contact opendesktop.org every so often for updates, though we'll obviously make it configurable.

The end result will be widgets that don't fall out of date on you (if they are scripted) and things like weather data not suddenly stopping.

I apologize for the inconvenience in 4.2, and I ask for your patience and understanding as we work on complete and long-term solutions.

Read More

urgent testing prior to rc-1

Dear KDE-from-SVN user,

A new an interesting breed of crash in libtaskmanager came to light today and I spent the day (that was supposed to be spent on other things, but oh well) fixing it up. The change set was not .. small. However, the crashes are gone.

Unfortunately We are dangerously close to the tagging of 4.3rc1, and I'm hoping that lots of you can update kdebase/workspace/, give it a rebuild and let me know if anything is looking off in your tasks widget with your configurations. Normally I'd go through and test as many as I can, but with time this short, I'm appealing to the masses to do that "many eyes" thing with me using the biggest bullhorn I have at my disposal. :)

If you do run into troubles with current svn, please let me know ASAFP so I might be able to fix it for rc1.

Of course, if I hear nothing back, that will be good news. :)

Thanks.

Read More

innovate much?

It's funny: some years ago the F/OSS desktop was said to not be innovating much, if at all. Woe from above was upon us due to our tail-light chasing! Today, maybe we are innovating too much, posits Bruce Byfield.

Are we? It's a good question.

There are two kinds of changes: changes for change's sake. Those sometimes work out, though most often they don't. There is also change with a purpose. Those often work out, though sometimes they don't. Due to this shaky track record on both paths, it's hard to tell them apart.

It's also true that as a species we fear change, which is a successful evolutionary trait. This does not help when we are trying to create. Creation is change. Change is scary. We fear creation. This, too, does not help in making good decisions.

What we ought to be aware of is that we aren't making change for change's sake, but that we are making change where it benefits us. How do you measure that, though? Hard to do, but here's a way I've discovered that's not half bad: talk to people. Lots of people. Lots of different kinds of people.

If you tell them the story of what you're doing as if you'd seen someone else was doing it (if you say you're doing it, people tend to be too kind out of politeness in my experience) they'll often tell you what they think. If they sort of stare at you blankly, you know you don't have anything compelling. If they move on to another topic, then it's probably not much better, but at least understandable. If they start talking about it themselves and relating it to their own lives, then you have something.

Now, it's easy to figure that some changes are needed: our software needs to look beautiful and work well. We have sore spots, like multimedia (which we tried to address with Phonon only to have the distributions yank the rug out from under us by introducing media servers that, at least currently, suck), and those we need to work on. You won't get people chatting about it, but we all know that if we put a pretty piece of iCandy in front of someone they'll tend to pick it over something less appealing.

Other changes, however, are more elusive. For those we need clear purpose and vision, backed up with a clear reason for them.

The social desktop is a interesting example, as are remote widgets (not windows, as Bruce wrote; that's something slightly different :), as is the idea of a re-targetable user interface layer. What are the use cases for these? How do they make people's lives better in some compelling way?

Well, I'm not going to try and convince you in this blog entry. I've talked about the use cases in previous blog entries, and I've talked with rediculous number of people on the street about them. The ideas appeal to rank-and-file human beings, and that's what matters.

The other stuff (beauty, working sound) are the bar we have to clear before we are considered contenders ... but it's the innovative features, and having the "right" mix of them, that we will win or lose on.

There is one thing I agree, at least now, with Bruce on: our users who make up our "online community" (a.k.a. the people who read this blog, or slashdot, etc..) don't want much innovation on the desktop. That's sad: most of you are happy with what most of the world is frustrated by. I don't know many things more tragic than that.

All is not lost, however. We have new devices and new forms of computer usage. That is where innovation will continue, and from there it will seep down into the "traditional desktop" bit by bit until you can't imagine it not being like that forever.

I've watched as individual after individual has warmed up to the ideas we've put forward in KDE 4; and we aren't even at the end post yet. There are those who are still unhappy and doubters, but such is the way of change. Even change with purpose. We need to escape the single % market share we have, and that takes change. Doing what we've done with limited, though still surprising, success won't cut it.

The true irony in all this is that I was holding off on a new blog entry because I wanted to post about the number of crashes we've resolved in 4.3. We killed some of the truly annoying ones, including some reports that had 50 or more duplicates in bugs.kde.org. Those are satisfying kills, if hard won. I wanted to write about the patterns in these bugs that I've been noticing, something that I think is a directly result of the rather different design of Plasma. Instead I'm writing about innovation, and not the dirty work of bug fixing and combing through backtraces.

Too often it gets lost than in the midst of pushing forward and innovating and dreaming and inspiring and ... well, whatever else we do that's scary and dangerous and evocative .. we are in the trenches making strong what once was weak, a task that takes great effort and determination.

Einstein Edison said that genius is 1% inspiration and 99% perspiration. He was right. We do have a lot of inspiration around us, but it's hardly light-hearted and we match it with perspiration. I enjoy reading articles like Bruce's, as they remind us to keep our head in the clouds but our feet on the ground. As long as we don't pull our heads from the skies and plunge them into the sand, we'll be just fine.

Read More

Social Desktop

A few people have blogged about what's up at Social Desktop and Open Collaboration Services already, including Frank Karlitschek, Luis Villa and Henri Bergius, but I think it really can't be talked about enough.

Why? Well, today's crop of online services really disappoint the user in all sorts of ways, namely:

• They tend to lack freedom. The user should have rights to their data (escrow services, downloadable in useful formats without loss of information) and choices in hosting (which implies open standards and open implementations). This is something that even people outside the tech industry understand: talking with a financial advisor recently who was quite enthused about the possibility of things like Google Docs, I was impressed when he noted he couldn't ever seriously use them because of a lack of guarantees to his data and privacy.


• They are usually stuck in the browser. The social networking crew wants us to use the web browser (or a browser on our phone) because it's convenient for them. Not because it's a great experience, but because it's easy. Those are the wrong priorities.


• The innovation essentially stopped at "things I used to do on paper". I want to do more than just have an easy place to dump my embarrassing photos of others from last night, keep up a public journal, read an annotated map or exchange small blocks of text with othes. I want the network to make my computing life more interesting, more immersive and more useful. The innovation has all but dried up in social networking, however, and what we have is an electronic version of the library and post office. A really freaking cool library and post-office, but that's about it. We can do better than that, can't we?

There are very few shining stars that buck this trend, and even then they often fall down by not offering things like data escrow or a richer user experience. They do deserve credit, though: Wikipedia, OpenStreetmap, identi.ca .. (does Gitorious fit in here? Hmmmm.) They should only be our beginning, however.

This is where an opportunity for Free software lies. Our strength is community. We understand it, we are driven by it, we eat and breath it. We don't need to find financial justifications for trying new things out and we have an entire stack of software (that goes waaaay beyond "stuff I used to do on paper") to play with. There are only two companies I can think of that come even close to breadth we have there, and neither of them can match our agility, freedom to experiment or respect for the values that make social groups thrive.

We have all the pieces coming together to create computing experiences that take into consideration the context of the person's location and concentration, their social/professional lives, their personal and shared information and reflect that in a myriad of ways in all of our interfaces, not just the web browser. Imagine being able to take your netbook into the lecture hall and have it switch to the "right" activity on screen, broadcast a widget to the class room and locate which students aren't there (maybe including a note from them explaining why). Imagine being able to walk into a train station and grabbing the train schedule on the device of your choice, finding you're stuck for the night, asking who that you know is in the area and then prodding one of them for a ride or some company to pass the evening hours away. Imagine being able to recommend a friend on one social network to a friend on a completely different social network without any interoperability weirdness. Imagine being able to sync your online data, leave with it (maybe working on it a bit), then re-sync it back later to a different provider.

In this world, I see our computers becoming helpers rather than mildly frustrating tools; I see services becoming a true web of interacting greatness rather silos with the occasional rickety handmade (and often one-way) rope bridge between them; I see "social networking" and "personal rights and freedoms" being mutually supporting at every level.

This is the "Social Desktop" that Frank spoke about at last year's Akademy, and which many others have been buzzing about in one form or another for some years. It was high time that we stopped talking about it and started doing it. So Frank started with outlining a set of Open Collaboration Services (OCS) and then implementing them in his popular *-look.org and *-apps.org community websites. Those specs are open: people can implement them, people can use them client-side and people can help evolve the specifications and implementations.

Cornelius implemented a KDE library to access them, as he's had a long standing interest in socializing software. (I believe this was one of the reasons he began working on KOrganizer waaay back, in fact.) Then Sebastian and Marco got to work, and now we have a budding set of applications for people to use. You can geolocate people near you in your network (or who are publicly available), you can browse and interact with an online knowledgebase that's very wiki-style and more.

This is very early days, however, and I fully expect this world and Nepomuk's local information stores to start intersecting in applications in interesting and fun ways, our geolocation systems to be come ever more useful/integrated, more devices and more possible opportunities with fewer compromises (e.g. "I want to work collaboratively on a slide presentation .. but I can either use a good rich client app or a far less powerful and useful web app. *sob*") and a User's Bill of Rights to emerge much as the GPL did for software code bases.

We can, by taking advantage of the Social Desktop concepts in our server, web and rich client software, take the whole social networking world to a new plateau that includes more invention, less lock-in and lock-out, better user experiences and freedom. This is a vision that has something in it for everyone in F/OSS: server, infrastructure, web, embedded, desktop ...

Ok, enough of the excited ranting from me. This is potentially big stuff and I'm happy that we are finally at the point that we are moving to implementation. There is so much to do and so many more ideas to be had and then realized.

To help push this all along a little bit further, Frank has initiated a contest for OCS implementations which you can read more about on his blog. I can't wait to see the entrants, and I'm extremely excited that the jury panel is so diverse: KDE, GNOME, OpenOffice and OpenDesktop are all represented.

Help us build the future of social/contextual computing by co-imagining it with us: enter the OCS contest and let's get to making the social networks and contextual computing experiences the world ought to have .. and lots of them. :)

Read More

some quickies

JavaScript (and other) Plasmoid Tutorials: It was pointed out to me that we do have tutorials on Techbase for Plasmoids. There are Python, Ruby and "QtScript" tutorials. The QtScript one needs some work, though it covers the basics. For one, all references to QtScript should be changed to JavaScript, and they need to start covering the actual API, e.g. using widgets, using files from packages, storing and reading configuration, etc. These all vary slightly from the C++ varieties to be more handy when used from JavaScript code.

So first: kudos to Pippin, the author of the current JavaScript tutorials; but second: we need more written. I'm happy to mentor someone through this (which means you'd get a free course in writing Plasmoids in JavaScript in the process ;), but just don't have the time or motivation to write tutorials right now. It's a casualty of everything else going on in my life.

I Miss Airports? I went to the airport today, a place I have been to much this year. Well, for a normal human being I probably have, but not at my usual pace. Oddly ... I discovered I experienced a sort of nostalgic response to being there. It was the oddest experience and not a reaction I expected. Weird.

Tokamak III: It's actually in planning now! We have a Techbase page and everything! Very excited about that. I need to come up with a theme for the event with the rest of the attendees that will be thematic and relevant to what we're up to. That shouldn't be too hard as we have some awesome projects happening right now. The media center components are coming along, the remote widgets are shaping up, the netbook interface sprints forward, the desktop experience continues to tighten up, etc...

GSoC Coolness .. I have to say I'm really impressed with this year's summer of code projects. I read about the KDevelop code visualization today and added that one to my list of "woah, NICE" projects we all get to watch evolve and mature.

OpenExpo in Winterthur Help: Alexandra posted a blog today about help need with the OpenExpo event. If you're in the area at the end of September, think about dropping them a line an helping out.

KDE Developer Sprint at LatinoWare? It looks very likely that we'll have a KDE developer sprint in Brazil alongside LatinoWare. Lots of planning left to do on it, but I'm looking forward to seeing that happen and the Latin American communities growing even stronger.

Read More

python, javascript or web?

While going through bug reports on bugs.kde.org, I had to install a Plasmoid over the internet using the Add Widgets dialog. It all worked pretty nicely (aside from the usual larger-than-good delay from kbuildsycoca4; I really need to find something to do about that ...), and soon I had a new widget. I dragged it to my desktop and got the "couldn't create a python scriptengine" error. Whoops! My PyKDE is currently not in a good state and I haven't had a chance to fix it yet, so no Python Plasmoids for me at the moment. :(

What was odd, though, was that it said in the description in Add Widgets that it was a JavaScript Tetris game. What would Python be needed for to run JavaScript? So I looked ...

# -*- coding: utf-8 -*-
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyKDE4.plasma import Plasma
from PyKDE4 import plasmascript
from PyKDE4.kdecore import KUrl

class jstetrisApplet(plasmascript.Applet):
    def __init__(self,parent,args=None):
        plasmascript.Applet.__init__(self,parent)

    def init(self):
        self.setHasConfigurationInterface(False)

        self.theme = Plasma.Svg(self)
        self.theme.setImagePath("widgets/background")
        self.setBackgroundHints(Plasma.Applet.DefaultBackground)
        self.setAspectRatioMode(Plasma.IgnoreAspectRatio)

        self.layout = QGraphicsLinearLayout(Qt.Horizontal, self.applet)
        webView = Plasma.WebView(self.applet)
        webView.setUrl(KUrl("~/.kde/share/apps/plasma/plasmoids/jstetris/contents/jstet.html"))
        self.layout.addItem(webView)
        self.setLayout(self.layout)
        self.resize(340,350)

def CreateApplet(parent):
    return jstetrisApplet(parent)

A-ha! So it's creating a web viewer and loading the contents, all implemented in Python.

Unfortunately there are two errors there: first, calling resize there will not have the effect desired and second, there's a literal path to the jstet.html file. I blame myself for this because the scripting is still under-documented.

As penance, I re-wrote it in JavaScript:

plasmoid.hasConfigurationInterface = false
plasmoid.apectRatioMode = IgnoreAspectRatio

layout = new LinearLayout(plasmoid)
webView = new WebView()
webView.url = Url(plasmoid.file("scripts", "jstet.html"))
layout.addItem(webView)

In the metadata.desktop file I put:

X-Plasma-DefautSize=340,350

Both problems are fixed. The solution to the file path was to ask the plasmoid for the file from the package: plasmoid.file("scripts", "jstet.html"). This meant also moving the html (and JavaScript) files to the contents/code/ area of the package. Now there's no assumptions about where the package is installed to!

With JavaScript it's guaranteed to work everywhere (no additional dependencies) and it's even less typing.

Then it dawned on me: this is a web Plasmoid! So I deleted the JavaScript file I'd just made and changed the metadata.desktop file so it said:

X-Plasma-API=webkit
X-Plasma-MainScript=jstet.html

Note that the X-Plasma-MainScript entry only works with web plasmoids in 4.3, though it works with JavaScript, Ruby and Python Plasmoids in 4.2; previous to 4.3, you need to call your main html file main.html (which is still the default in 4.3 of course).

The only downside to this over the JavaScript Plasmoid approach above is that the WebKit ScriptEngine is in kdebase/workspace while the JavaScript ScriptEngine is in kdebase/runtime. I wonder if I should move the WebKit ScriptEngine over to runtime/ as well? Hm.. maybe something for 4.4. In any case, it means writing zero Plasma specific code.

Anyways, what's the result? All three approaches gives us this:



I can't take any credit for the actual hard work here, the JavaScript, was done by one Cezary Tomczak and the original Python plasmoid by Tomatz on kde-look.org. :)

Read More

beta cycle

Today 38 new defect reports were opened against Plasma; that's one third the number of the entire previous six days. People are really pushing on the betas and we're getting great feedback and reports. It's really helping to increase the quality of what will become 4.3.0, and we're managing to stay half a step ahead: 49 reports closed today, 142 over the last week.

There have been some duplicates, but remarkably few for the volume. The rapid turn around time between betas is helping there, I think. People who tried beta1 have generally upgraded to beta2 now and people joining in on the testing are on beta2 which included a bunch of fixes over beta1. The result is new issues being reported, not the same old ones. Much thanks to the release team for helping improve this part o the cycle.

The new crash reporting system in 4.3 is also really coming through and helping people with their reportig. I can't really call it a "crash dialog" anymore since it does so much more than that. The results are already evident, at least to me: the quality of backtraces is up, the consistency of the reports is much better (it's rare to get a report without a "what I was doing" section now) and I've even had some direct feedback on how much nicer the new dialog is from reporters.

Some very long standing crashes and numerous "annoyance" bugs have been cleared out already, and we have several weeks yet to go!

For those reporting issues, if you haven't read the How To Create Useful Crash Reports page yet, please do so. There are some great tips in there.

Things aren't all perfect, though. Like every project on the planet, we only have so many human resources, and 4.4 development started a bit early on us due to a combination of Google Summer of Code / KDE Season of Code and some strategic projects around netbooks that have timed themselves "just right". Most of the team is spending most of their time now on things that will land in 4.4; given the "must have" nature of these things and the relative complexity of some of them, I decided yesterday to adjust our bug count target for 4.3.0 to give the team a freer hand to work on these 4.4 issues.

We still have a target goal and 4.3.0 will be an outstanding release, it's just a bit more reasonable given our priorities for 2009. A number of our team showed up on IRC today and helped slay the dragons as they rolled in, so there's still a lot of attention being paid to polishing up 4.3.0 for the release.

On a side note, one thing that I have found a bit frustrating is that we don't have a branch to work on stabilization in. That means that bugs that require string changes, for instance, can't be made and I have to just remember to come back to them once 4.4 devel opens up. I really think we should branch for stabilization and leave trunk "open"; this is that whole "always summer" concept and I'm missing it more and more as time goes on. :) There is the social problem of making sure that people spend time on stabilization, but that is a social issue and one that we've managed to strike a very fine balance on in Plasma, though what the balance is varies from release to release in accord with our goals.

To really make that happen requires, I think, something other than svn into the mix. Chani has done some much needed work on the translation workflow and now scripty works with git. Michael Pyne also found time to make kdesvn-build (will one day become an anachronism of a name? :) to work with git repositories as well. So we're making progress on that point, getting some of our pieces of infrastructure into place so we have the choice to move when the time is right for us as a project.

There's still much to do, including documentation for KDE contributors so we don't experience unnecessary slow downs during transition (I think this is trebley true for the translation team efforts), hooks between our bugzilla installation and git and then the actual move-the-svn-repos (though Thiago has done a lot of work on that already).

Never a dull day in KDE. :)

On a more personal note, I bought some wonderful parchment paper the other day and some terrific inky black pens to write with. It's been a while sice I sat and wrote my personal thoughts down in this manner. I use pen and paper for software design and writing presentations quite often, but I've fallen out of the habit of putting my inner meanderings down in some form. Last night I was struck by the urge to write some verse, in fact, though I got no further than some music on the stereo and the strings on my guitar. :)

Read More

phrase for the day: cross platform

I know that what follows will probably be considered by some as "flame bait" but it's simply the truth. If nobody stands up an speaks the truth, people will continue to make decisions without all the facts at their disposal, and that's just a recipe for disaster. So, donning my birthday suit (because I like facing the flames the way I came into this world: nekid) ...

---

I just read an article on Ars about Google Chrome for Linux where Ryan Paul writes:

"After extensive discussion, the Chromium developers decided to build the Linux port with GTK+, the toolkit that is used by the popular GNOME desktop environment. This will eventually make it look and feel somewhat native on GNOME-based Linux distributions, such as Ubuntu."

The rest of the article goes on to document the woes of developing on Linux, including Ben Goodger's "situation is a clusterf*ck" comment about developing on Linux. It was the above quote that really struck me, though, as it's the right idea (to "fit in") meeting a less-right idea ("ergo we ought to use Gtk+").

The mistake isn't so much in using Gtk+ itself (I know a number of people who really like working with it and there are some great apps written using it), but rather in expecting the use of Gtk+ to make an app fit in well on the Linux (let alone the broader F/OSS) desktop or feeling that you have to make a choice to target one desktop system and forgo the rest.

There's a much better solution: choose them all by using Qt.

Qt does quite a bit to Work Natively(tm) for you these days, right down to using the platform's widget styles, file dialogs and even dialog button orders (Ok/Cancel vs Cancel/Ok) without any special application code or user settings. That means you'll look and work native on Windows, Mac, KDE and GNOME if you write using Qt. On Linux, one binary gives you the Qt, KDE and GNOME looks all in one go.

So instead of Chrome looking and feeling native at some point on one desktop, it could look and feel native on them all. This is due to the Qt development team caring deeply about the whole platform, not just pieces of it. Gtk+ strives to do well in its own world, but that's where it basically ends. For that reason, if you want your app to look good on F/OSS desktops regardless of what is being used, you probably want to be using Qt.

And Ben G.: people glow on a regular basis about how they can make the coolest looking UIs using Qt.

(You have to read the Ars article to get that last one. :)

Read More

build brand together, adendums

The other day I blogged about creating a shared "meta" brand we could all use to amplify our combined marketing weight. Here are a few clarifications and comments based on reading feedback here and elsewhere.

It's Not About Logos

Some people thought I was talking about logos. Logos are certainly a usual (though not inviolable) part of branding, but they aren't the totality of successful branding. As such, the idea is really not about logos, though some logo work may happen. For instance, integrating the downstream logo (if that's how they do things) into a wallpaper or elsewhere may occur. That would be a way to satisfy and align with the distributor's practices, but it's not what creates or destroys the shared brand image.

What does build up that shared brand image is consistency in visual, audio and textual messages embedded throughout the product and support materials.

It's Not About KDE's Brand

This is not an attempt to replace $BRAND with the KDE brand, because it's not about KDE's brand (exclusively, anyways). It's about a shared brand in the client-side F/OSS consumer market that can be employed wherever KDE is used.

It's an attempt to build a brand together with the KDE project as a participant along with those who package KDE. It just so happens that we not only create some great artwork (though certainly not all of it; there is great artwork elsewhere too), we are a natural and neutral place to coordinate this.

I don't think any of the distributions could make an honest case for a common brand; it would be too suspect by other distributors, or would be shouted down by them out of competitive concern. It's even been tried before.

When I spoke about a common logo for the application launcher, I was specifically thinking about something that isn't the KDE logo which people could all ship in their packages. I don't know what such a thing could be, and it's definitely a longer term task and I'm not sure it's possible to unify that. It is the probably most difficult point to come to an agreement on, and it probably wouldn't be a K inside of a gear, though, judging by what gets shipped right now.

Distributors Matter Here, Other F/OSS Projects Less So

I am reaching out to distributors of KDE because they make the final decisions as to what hits the user base in most cases. They therefore have the biggest impact here of all the actors. They also have a relationship with KDE already and a vested interested in all of our success.

Harmonizing branding with other F/OSS projects aimed at the desktop is probably a little out of reach right now, and it still wouldn't create immediate change what the end user sees as the distributors make that set of decisions. If there was more harmony here, it may make it easier for distributors to support the effort, but it's the harder achievement.

We can always look beyond distributors later, of course. For now I'm just looking for what's directly in reach, and it's really up to the people behind those other projects to decide whether they care about this kind of thing themselves.

Branding is Unnecessary, Maybe Even Evil

For those who say that: you are right .... for you. For you it isn't necessary. For you it may indeed even be "evil", or at least unwanted. However, I'm not doing this for you, or even for me, directly.

I'm doing it for the people who actually do "need" it in order to make a decision to use F/OSS. It happens that the overwhelming majority of people in this world fall into that category, and I think that if working on branding and marketing helps bring software Freedom to those individuals then it's worthwhile.

You can ignore the branding and marketing, and I'll be sure to return the favor when working on it. However, it's unfair to the rest of humanity who would benefit from such a thing to deny marketing efforts just because you don't personally need it.

Linux Is Awesome Enough

Yes, Linux is awesome enough for Linux but it's a wide, wide brand with virtually no acceptance or meaningful recognition in the consumer market. While it's done well on the server side and there are balkanizing brands like Google's Android, there is not really an identifiable "client side Linux" brand position. The F/OSS desktop also extends a fair ways beyond Linux these days. For all of these reasons, we can't afford to just ride the marketing tailcoats of Linux as a brand name alone. We can certainly work with it, but we need more than it alone.

It's All Dooooomed Because Nobody Will Take You Up On It

That's perfectly possible. I've already been contacted by some distributors, however, so we'll see how far it gets. But maybe when it all shakes out it just won't work as proposed.

Failure is a risk of trying, but the risk of failure should not prevent one from trying.

I consider this a "fair chance" try that we all deserve. If it does fail, there are other possibilities, though they are probably a lot less efficient, useful and friendly.

Read More

building brand together

There are many reasons given for desktop Linux not "taking off". Some are accurate, others considerably less so. One of the challenges we face with KDE is creating a meaningful, visible brand that people value and relate to on an emotional level.

Those of us in the F/OSS community have already built that kind of relationship with F/OSS brands: we see, desire, often straight out breathe the message of Freedom in technology, and go to bat for our favorites. Not everyone will get that, however, and not everyone cares.

We make our life harder than it needs to be in the quest to build brand. We have a small visible market share right now, even when the total of our deployments is summed up. Yes, we have huge deployments in the education sector, have made terrific inroads into private and public offices and have annual global retail sales rivaling Apple's but these deployments are both limited in their visibility and geographically bound (meaning: we are doing a lot better in, say, Brazil than in the USA).

From a brand building perspective, something that people can recognize on a billboard, during a cameo in a T.V. show or "on that guy's laptop on the other side of the coffee shop" is pretty important. Achieving this requires design that has a positive impact at an emotional level and that is applied consistently.

We are at a moment in time where we have just enough market share that we could achieve some great strides forward over the next few years ... if we pulled together.

What KDE Has Done To Date

The KDE community has spent a lot of time and effort putting together things like the Oxygen icons and themes. This was done with the hope that we could build a common visual language, at least for the KDE software in the world and maybe even for some of the other F/OSS apps out there. We certainly did not put as much time and effort in the past into art and presentation as we have with KDE 4 (I think it shows) and this is a big part of the reason why.

We even put ourselves through rather painful transitions like changing all our icon names to the freedesktop.org naming scheme. Thankfully we have great text processing tools to work with in UNIX-land, but still ... hunting through several million lines of code and changing all the icon names in there isn't trivial. Then we had to retrofit all our existing icon themes. These are the sorts of changes that do not add any (user visible) useful features or fix any "big" bugs .. and that's if you get it right; it can cause problems if you get it wrong.

We also introduced things like the branding.svg file that allows someone to pop in their logos and web links and have them show up automatically in places one might expect some branding to be, such as in the launcher window that pops up when you click on the Kickoff button, without the need for patching the source code.

The new emphasis on and effort put into these kinds of things was made specifically to increase our competitive edge with the proprietary offerings out there, and that included a marketing angle. We continue to spend great amounts of time on our choice in wallpapers or widget stylings, and we've gotten them to the point in 4.3 where they are, by all accounts, pretty stunning.

They are also visually identifiable from a distance with just a glance, without being off-putting to the user (quite the opposite, in my experience). This is not by accident.

However, it's not much good if all the work that we collaborate on and house upstream is not used downstream and therefore passed on to the user. We instead end up with N different visual identities - where N approximates the number of distributions out there - and a continued identity crisis for the F/OSS desktop.

What The F/OSS Community Is Doing

Unfortunately, in the F/OSS world we like to build little fences around our plots of land and then design the gardens in them like the unique little acres of wonder we feel they are. This is natural and expected: the people creating F/OSS systems take as much pride in their final product as anyone else and wish to mark it as "that thing I've done". Similarly, companies wish to push their own brand for commercial purposes. Neither set of motivations is wrong or unnatural, but they are hurting us right now more than they are helping.

The truth is that none of the F/OSS operating systems, not even the Linux ones, have enough individual market share to press out a meaningful visual brand image. Even with the most successful brand creation efforts amongst the distributions with countless millions thrown into it, it's all still just "Red Hat versus Novell versus Canonical versus Mandriva versus FreeBSD versus..." and near-zero real-world brand identifiability.

Which is to say: we have made it hard for people to take notice of what we are doing with the Linux Desktop since none of the brands are identifiable as "belonging to the same thing". Instead we end up with microbrands that nearly no one outside of the server room or the hardcore F/OSS community recognizes.

Many (most?) operating systems bearing KDE packages come with their own logo as the application launcher button, many ship their own icon sets or their own (for branding purposes) customizations of the default icon set, many ship their own wallpapers, many change the default window borders or widget themes.

This is even more unfortunate because there is a scarcity of quality artists in the F/OSS world, and when each distribution or project gobbles up one of them to work exclusively on their own mojo ... we just divide and conquer ourselves.

While this may make their individual believers-in-the-cause users happy and may make corporate management feel they are getting some good corporate marketing out there with that happy little logo in the bottom left hand corner ... this is obviously inspired by the "old way" of doing things that is centered around corporate balkanization of the consumer space: flags or fruits, right? (Microsoft and Apple .. :) We need to rise above that and consider the long term benefits of the entire ecosystem because each of our projects thrives or diminishes in step with it.

Right now, it's almost tragic how we feel ourselves to be so rich and so well established that we can afford N different art teams creating N different visual identities. It's time to wake up from that quaint dream so we can take on reality.

What Can We Do?

So how do we remove barriers that stand in the way of improving the situation? Whatever we do (if we do anything), it will be a one-step-a-time process, surely. Thankfully we are usually a patient and hard working lot in F/OSS. We're also a group made up mostly of people who understand the concept of "meeting people half-way".

John F. Kennedy famously said, "Ask not what your country can do for you, but what you can for your country." So starting with 4.3, KDE is putting together a small service for KDE distributors (that hopefully one day could turn into a big service, maybe even one that is eventually funded by benevolent forces out there) where we will help others customize the default elements of the KDE visual appearance to suit their needs. We are starting with something simple and achievable: wallpapers.

Why wallpapers? It's a single set of images (so relatively low overhead for us) and it's also what takes up a huge portion of the screen upon log-in and dominates screenshots in review articles.

Eventually it would be great if we could come up with a shared logo for the launcher menu button, manageable customizations in the desktop widget theme, commitment to a standard window border and further usage of branding.svg. We need to start somewhere, however, and to build a working art relationship.

How Will This Service Work?

If you provide a KDE distribution (defined as "a set of KDE binary packages or means to distribute them that includes at least kdelibs and kdebase”) and would like to collaborate with us on this, we will work with you to bring your logo and/or color scheme into our default wallpaper(s).

The quid-pro-quo is this: you commit to setting that wallpaper as the default in your KDE 4.3 (or whatever version is next at that time) packages. The logo and colour scheme work will be done in coordination with your art director(s) (if you have such a person or team) so that it does indeed make sense with your visual identity, but it needs to be based on the upstream defaults. (And yes, the defaults do not include a KDE logo. ;)

We only have so many artists ourselves, so we will operate on a first-come-first-served basis along with some prioritization based on size of user base for the "close ties" in request timing. If you, as a KDE distribution, would like to donate some of your art team's time to helping customize our wallpapers for your look, that'd be great too. (We don't expect your artists to work on images for other distributions; we're looking and hoping for enlightened, not purely altruistic, gestures here. :)

If this works out, then we can extend and expand the program together over time to include other visual elements that we can all agree on.

This is indeed a simple plan with open questions remaining, but it starts to address the issue. We are open to and desire feedback from distributors regarding how this could work right now and how it could evolve over time: the better we understand the needs and patterns of others, the better we can make this program work out together.

... and what's the goal again?

The desired result is the ability to build a visually identifiable F/OSS desktop brand together, one that fits nicely with your brand as well. This way people can continue to say, "Oh hey, that's $COMPANY $NAME Linux" while giving the human population half a chance to build a relationship with F/OSS itself as a visually identifiable thing.

In short: the goal is to increase our net effect in the market by working together.

It's Big Picture thinking, and I hope you will invite us to join your efforts.

So What Can I do?

Remember Aesop's words that he wrote with so much wisdom so long ago: together we stand, divided we fall.

If you are an artist, consider getting involved and help us make beautiful art! (kde-artists at kde dot org is the email address you're looking for ;)

If you are a KDE distributor, contact us so we can include you. (kde-artists at kde dot org, or if you want to start out a bit more cautiously/quietly then aseigo at kde dot org wil reach me privately)

If you are a KDE user who feels this is a good idea: spread the word. Blog, microblog, copy pieces of this blog without apology, write to your KDE distributor about this issue so they are aware of it ....

Together we can build a shared and identifiable brand with great value that we all benefit from.

Read More

Plasma and RTL

A huge number of people read and write languages that run right-to-left (aka RTL) so it's good to have solid support for RTL. I fixed a few RTL bugs in Plasma's panels the other day and I noticed Marco killed another one a few days before that, but while running `plasma-desktop -reverse` I spotted a couple cosmetic issues.

I run plasma-desktop and some of the other tools maybe a couple times a year in RTL mode, and usually because someone has filed a bug report about it. That means new RTL bugs creep in far too easily.

What would be just excellent is if we had a developer who runs their desktop in RTL who could keep an eye on it and work on RTL patches. That way our RTL experience would be a lot better. The workload is probably fairly minimal as most things Just Work(tm) thanks to Qt; it's mostly where we do custom painting and placement that things sometimes go haywire.

If you have Qt development experience and would like to make Plasma rock in the RTL world, find us in #plasma on irc.freenode.net or post to plasma-devel at kde dot org. We'd love to have you on board. :)

p.s. I also fixed the Plasma calendar to work with calendars that don't have 12 months in them, though there are a couple of bugs in two of the calendar engines in kdelibs. The author is aware of them, but help there would also rock; I'm completely date illiterate even with my native calendar (ask anyone who's had the pleasure of dealing with my "amazing" ability to think it's Thursday when it's really Wednesday, for instance) ... ;)

Read More

aseigo.brain().idle();

Yesterday was "one of those days" for me where my brain just refused to kick into gear. This happens every so often. Think of it as a sort of Paris-in-my-mind where the workers just up and strike every so often refusing to let the creative juices get moving. Inconvenient, but then I push myself pretty hard at times so I'm just happy it doesn't happen more often. ;)

So I took care of boring and mundane things, the sort of things I can do without my creativity cap on. Today, however, the Parisian mob was back at work and my fingers are moving again. On the day after such events, I always feel compelled to try and work a bit harder to make up for time lost. I'm perhaps overly aware of my own mortality and that I have been given only so many days in this life to do the things I wish to do.

This didn't stop others from kicking ass and taking names in the wild worlds of Qt, KDE and Plasma, though.

The people behind KDE Latino have been organizing a great KDE presence for the Latinowarea event in October, and I think we may have found some additional resources to bring even more people to it and set up an actual KDE Developer Sprint in conjunction with the event. It's still in the early planning stages, but if it all goes down according to plan I think this will be the first developer sprint KDE e.V. will have helped fund in South America. Hopefully the first of many ...... :)

Then Jani Hautakangas showed up on the plasma-devel mailing list with this nugget:

Yes, that's Plasma running an S60 device. Jani had to craft a few patches for KDE's libraries to make it all go (hopefully we'll get those patches and upstream all the ones we can!), but when he was done it all worked on his S60 device. As is evident from the video, we still have some work to do, but it shows that KDE and Plasma are indeed in the right ballpark to run on today's mobile devices... even the smaller ones like phones, and even ones running operating systems other than Linux.

Marco also posted a blog entry showing what the Plasma Netbook interface looks like after ~1 week of work by two people (Artur being the other). Neither are paid (yet? :) to work on this stuff, and yet the results are already impressive. You can read Marco's blog to learn more about the newspaper-style widget layout, the Search and Launch full screen interface and what else is coming down the pipe. We are eschewing the desktop paradigm completely here: no home desktop, no taskbar (we use "present windows" for that instead, giving you an overview only when you need it) and an emphasis on full-screen usage. You can grab the .ogg file from Marco's blog, or preview it via Youtube here:

What could you make with one week and two people working on it as they can in their own time? No other primary user interface ("desktop" is one PUI paradigm) framework that I know of comes close to providing the tools to do what Marco and Artur have just done. They key is re-usability coupled with an intentional bias towards being able to re-purpose objects. (Oh, and props to the KWin devs for making the desktop effects rock so we can take advantage of them ... :)

We (the Plasma community) also did another round of design and API work on the remote Plasmoids and QtKinetic-based animations system projects. Along with the other SoC projects and our usual development frenzies, Plasma is set to take another major step forward and we'll be sure to share it all with you as it lands.

This is one of the things I love about Plasma development: we hit new plateaus with each release (one Tech Republic said Plasma is "widgets done right"), and it feels great; but then we go and best ourselves with the next release. I don't know how many releases in a row we can keep this up (one expects there is a limit to the sky somewhere out there, right? ;) but I'm absolutely loving how we are progressing.

We already know some of the important components that will be released with 4.4 in January 2010, so we can safely say that the roof on the sky not not yet have been reached even two years out after the first actual release of Plasma (which followed quite a bit of design and development prior to that).

We're able to do this because we have a clear design philosophy that permeates the entire project and which we do not allow ourselves to compromise on. In turn, a very "hooked in" community with a steady stream of new faces has evolved around this efforts. Clarity and community: they are two ingredients to a successful project that produces tangible results. Many of the people in our Plasma community go on to work on other parts of KDE and even Qt itself as well, so the effects are not limited to Plasma itself either.

(Example: one of the main developers working on Qt's animation framework started as one of Kevin's University students and got sucked into Plasma and eventually went to work as a Troll; many more go on to work on areas of KDE itself that needs more hands than Plasma does.)

Read More

Okular and DRM

Jonathan Corbet wrote a piece on LWN about Okular and it's implementation of user permission restrictions in PDFs (sometimes errantly refered to as "DRM"). This is actually something it has done since it was KPDF back in KDE 3. Obviously, permissions in PDFs are a generally misguided attempt at protecting the agenda of a publisher in a demonstrably ineffective way that comes at a cost to things like the concepts of fair use.

So what's up with Okular having support for permissions? It's quite simple: not only is permissions in the PDF spec, but there are organizations in the world who, for contractual or legal reasons, require permissions in PDFs be respected.

Do we simply not serve those users needs? Do we "know better" for the user who says "I want to accept the terms of the publisher of this document"? Of course not; that's rather user unfriendly in itself.

So the strategy adopted was quite simple: make it an option that the user may choose to abide by the permissions flags in a PDF or not.

With the KDE configuration lock-down system, this can even be made as a policy decision within an organization, either by providing a locked-down default value for this option or just removing the option altogether with the "skip_drm" KAuthorization entry. It's even a compile time option for those who wish to be particularly hardcore about it: -DOKULAR_FORCE_DRM.

The important point, however, is that Okular (and KPDF before it) does not make that decision for the user. Okular is intentionally crafted in such a way that permissions are not pushed on anyone while at the same time not removing it by force from anyone either.

That choice is the ultimate in user respect.

As for KDE itself, as much as such a statement can be made for a globally distributed community of individuals, we do not support the notion of permissions in principle due to its impact on individual rights and freedoms. If we felt otherwise, we'd simply enforce permissions in PDFs rather than go to lengths to make it optional.

There's an old addage that goes something like "I may not agree with what you say, but I will defend your right to say it". With Okular, we do not agree with permissions but we do defend your right to opt into it should you wish. We do not see it as our role to go around telling others what they can and can not do and "fixing" PDFs by ignoring permissions with no option to do otherwise. By the same token, we also do not see it as our role to remove rights from the user and force such silliness on them either: if you wish to disagree with the author's usage of permission restrictions, you are empowered to do so with Okular.

You choose, and we defend your right to do so.

(Albert Astals Cid has also blogged about this issue. It's a nice read from one of the primary people behind KPDF/Okular.)

Read More