Qt 4.6.0, KDE SC 4.4, configChanged()

As a heads up to everyone out there: we're getting a lot of bug reports, particularly crashes, from people using Qt 4.6.0. That version of Qt has a handful of crashes in it that some KDE apps trigger all too reliably. A patch release of Qt, v4.6.1, has been released that addresses a number of these issues. Qt 4.6.2 that's upcoming will be even better, and I understand that some distributions have been backporting some of these critical fixes. If you are having a hard time with the 4.4 release candidates, please check your Qt version first.

Then there's this bug in glibc, which has been fixed, and some distributions have backported those fixes to affected versions already. Unfortunately, some of our users are still getting exposed to it. Not fun.

Just one of those months, it seems.

The 4.4 release for KDE SC is coming along well. We've been hammering nasties, of both the crasher and general misbehavior sort, over the head at a reasonable pace, even though 4.5 is open and some work is going on there. I count 52 backport commits to the 4.4 branch in just Plasma-land in the last seven days.

(A "backport" is when we fix something in the main development branch, in this case it is what will eventually become KDE SC 4.5, and then after testing it there merge the fix into the previous stable branch, in this case what will become KDE SC 4.4.0.)

(Trunk teaser: Marco is doing some really nice work on notification and job display right now. Woo! This is why you want to join us and run an svn trunk build of KDE SC so you can help us test while you get the first tastes of things coming down the pipe! ;)

Read More

Gwenview Redux

As to be expected, my last blog entry on Gwenview drew quite a bit of commentary. The start of it all was:

• The file dialog defaulting to $HOME instead of the currently viewed directory when opening it from places like the KIPI Batch Processing plugin.


• No options for image size or file size in the thumbnails

Well, the file dialog problem doesn't seem to exist in 4.4 (I don't know if it existed in 4.3 or earlier as I don't have an installation to test on) and the image and file sizes are now available in the thumbnail views in trunk, which means that will be part of Gwenview that comes with the KDE Software Compilation v4.5 this summer.

What I found really interesting was how difficult it was to get the use case for why that information was needed in the thumbnail out of the people who wanted that feature. Aurelien wasn't sure why they were needed and I had to do a fair amount of careful reading and picking through comments to figure it out. Here is a formulation of the use case:

"Carla have a folder with several pictures in it that she will be posting to a blog
as part of an article (or to some other resource that puts a constraint on the
size of the image, the file or both). She looks through the folder to see which
images are too large and scales those that are above those limits."

Coming up with use cases isn't hard, but it isn't perfectly simple either. When you a clear use case is provided, sans rant and extraneous "analysis of the bigger picture", work gets done quicker. Not every use case will result in the change hoped for, but it really does increase the odds. Even when a use case is deemed "out of scope" it helps document much clearer what that scope is.

Read More

Tokamak 4 cometh

Tokamak 4 commences on the 19th of February in Nuremberg. Novell will be hosting our band of merry developers, designers and dreamers. This Tokamak is going to be the biggest one yet with 25 participants, not counting the visitors we are expecting to swell those numbers even further.

At Tokamak 3 we invited a few people who weren't "strictly" in the Plasma project, including a KWin developer. That was due to a conscious realization at Tokamak 2 that our world in Plasma was not an island unto itself, but a larger expanse that touched or was touched by several other parts of KDE and beyond. Tokamak 4 is going one step further and we are actually hosting three parallel development sprints side by side: one for Oxygen, one for KWin and one for Plasma. These three projects have a large contact surface area with each other, so it's only natural to bring them together like this for a large sprint where we can get work done in our usual heads-down-and-moving fashion across the board. Obviously, Oxygen and KWin and not completely defined by Plasma, and vice versa, but we are trying to harmonize and improve our results together.

Due to the size of this Tokamak, even just counting the Plasma contingent, we will be hosting break-out groups each day covering different sub-topics. There will be a break out track for activities, and I think this is the Tokamak we finally nail that topic down with greater definition. I removed the zooming code from plasma-desktop the other day in preparation for what we will be replacing it with. I can already hear you asking, "What will you replace it with?" We'll all just have to wait for Tokamak 4 for more details, but here are tantalizing hints: it uses Nepomuk and it will blend in visually with the rest of KDE Plasma Desktop much better.

Another exciting break out group will be the Plasma On The Go track. In addition to Plasma Netbook, which is designed for mid-sized screens (it also supports multitouch), we will be diving into the new Plasma Mobile project. Plasma Mobile is meant for smaller devices such as smart phones. We will have at least one Intel based smartphone type device and some N900s to hack on. I'll also be lugging a MIPS based netbook with me (thanks, Armijn! :) so we'll have a bunch of different devices to work on. Hopefully we can get everyone who's interested set up in pair-programming teams around their own device. Marco and Alexis will both be hosting "how to develop on these things" workshops so everyone can get up to speed. There are some really interesting ideas floating around the Plasmasphere about interesting interaction workflows we can enabled with Plasma and Qt, especially using Kinetic and even QML. I've also heard that there are plans to do a Technical Preview in 2010 of Plasma Mobile on top of the Ubuntu stack, so the snowball is starting to grow here.

We'll keep all of you posted as Tokamak 4 progresses via our blogs, identi.ca and of course KDE's own TheDot. It's a big event with big challenges to tackle. I can't wait.

Read More

gwenview: user friendly?

Carla Schroder wrote an editorial piece this week on Linux Today (a website I enjoy and frequent daily via their RSS feeds) entitled Editor's Note: What is User-friendly, Really?.

In it, Carla claims to be "90% satisfied" with KDE3 and "60% satisfied" with KDE SC 4.3. Why? "KDE 4 sacrifices customizability and efficiency for glitz. [...] There is a trend to dumb Linux down in a fruitless attempt to appeal to Jane and Joe Sixpack. Which is wasted effort, because in doing so computer-savvy users are being ignored and frustrated, and Jane and Joe Sixpack don't care anyway."

What's interesting about this for me is that Gwenview's redesign wasn't to appeal to Jane and Joe Sixpack. It was to take a powerful app with a rather clumsy UI and turn it into a powerful app with a slick UI. Now, I don't know about you, but I like tools that fit my hand when I use them; creating tools that fit the tentacles of an octopus might be interesting as an academic exercise in design, but I don't live in the ocean and I have arms with hands, not tentacles with suction cups. Similarly, I like slick UIs. I'm not the only one, as fans of MacOS and other nicely designed UIs will be happy to relate.

The example she uses is Gwenview: "In KDE 4.3, the same data have been shuffled around to different locations, it is far less configurable, and the thumbnails only display filename and date. To get any other information requires viewing each image one at a time. It's like being given a little porthole to look through. In KDE 3.5, Gwenview is very configurable [...] In KDE 4.3, where did all the configurations go? Why do they even bother with a configuration menu? "

It seems that Carla was "tricked" by a UI that doesn't scream in your face "I HAVE LOTS OF POWER!!!!! LOOK AT EVERYTHING I CAN DO BECAUSE IT'S ALL PLASTERED ON YOUR SCREEN IN SUCH AN INELEGANT WAY THAT YOU CAN'T IGNORE HOW POWERFUL I AM!!!! HOPE YOU WANT TO DO LOT OF POWERFUL THINGS, RATHER THAN VIEW YOUR IMAGES!" Yes, Gwenview in KDE 3 screams just like that. :) If you go from a "screaming" UI to an elegant one, one might assume the elegant one simply doesn't have much power to it because it's so much "quieter". Let's see if this is really the case with Gwenview.

(For simplicity, let's refer to Gwenview's KDE 3 version as G3, and it's current version as G4.)

Where I Agree

Let's start with where I agree with Carla: "The thumbnails display image size, file size, filename, and date, and I can see this information on several images at once." In G4 only filename, date and rating can be shown with the thumbnails. As far as I can see, G3 lacked rating information in the thumbnails, but you could make it display file and image size as well. I think adding back those two bits of information to the thumbnails wouldn't be a horrible idea for G4.

Even here, though, we start to see some real differences. To set the thumbnail preferences in G3 you would:

0. Open the Settings menu and select "Configure Gwenview"


1. On the "Image List" page there is a section called "Thumbnail View"; under that are the various options


2. Click Ok or Apply+close the window

In G4:

0. Open the View -> Thumbnails menu


1. Select an item to show

This is rather quicker to do and puts the options within reach under a menu that is topically relevant ("View"). There is no reason the two extra size entries from G3 couldn't appear in the G4 menu, as well. Maybe Aurelien (or someone with some time and patch-fu) could do this for KDE SC 4.5.

So here we have an example of a UI that is quicker to use, particularly if you just want to turn on/off some extra details in the thumbnails, but which currently has one new option but missing two old ones. Will this pattern continue?

Where Has All The Configuration Gone?

Carla asks, "In KDE 4.3, where did all the configurations go?" after showing a screenshot of G3's settings dialog. That certainly does look impressive! Look at all the knobs and levers one can push and pull! True, G4 doesn't have nearly as "impressive" a configuration dialog. Where have the features gone? Let's see what G3 offered:

• "Show folders and archives": This is indeed gone in G4 because the browsing has been merged into one view so that you aren't bouncing around the window with your mouse. In the version I have here, there is an (optional) tree view of your file sytem in case you do want to bounce around like that.


• "Margin between thumbnails": Seriously? Setting the absolute number of pixels between images in the view is at all worth it? Bzzt, gone.


• Four thumbnail caching settings! The only one left in G4 is the "empty when exiting" option because that's the only one that matters: everything else simply follows the desktop wide settings for caching. Extra bonus for G4: it uses the freedesktop.org standard for thumbnails, thanks to KDE Dev Platform v4, which means those thumbnails are shared between Konqueror, Dolphin, the file dialogs, Gwenview and many more, including Gtk+ apps.


• "Enlarge small images when auto-zoom is enabled": In G4, this is still there and more sensibly labeled "Enlarge small images". But more importantly, this is only a default setting in G4. You can access several zoom controls directly when viewing the image, which puts it right where you can get to it when you actually want it (namely, the viewer). Again, G4 manages to keep the power but do so far more efficiently for the user.


• "Show scroll bars": This belongs with "Margin between thumbnails" and is probably there in part because G3's window is cluttered with so much irrelevant widgetry all the time that every pixel counts. Not so in G4 where things are well organized and where the fullscreen view seriously rocks. Another G4 win.


• "Background color": still there in G4, and in the settings dialog. Sensible.


• "Smoothing": 5 options for smoothing, all fairly cryptic in what the actual results will end up being. In G4 the smoothing is progressive and fast enough to not require such a configuration feature.


• "Mouse wheel behavior over image": two options, both till there in G4, and in the settings dialog.


• "Show busy mouse pointer when loading image": This belongs in the same rubbish pile as the margin pixel setting. Showing a busy pointer when the application is busy is a sensible default and follows basic user interface guidelines.


• Full screen "on screen display" configuration: this is a complex "format string" with things like "%f %p". In G4 when you are in full screen mode, there is a configuration button which allows you to set the meta data shown. You just point and click at what metadata you want. Much faster, much more intuitive and, most importantly, if you want to change it while in full screen mode (one of the most likely cases, actually) you don't have to exit full screen mode and hunt through a config dialog only to find yourself confronted with cryptic % escape values. Oh, and G4 allows you to show any metadata that is availabe for the file, not just the 10 hard code possibilities G3 offers.


• Moving and copying files: options to show or hide the move/copy dialogs and where the default destination is. This is all replaced by desktop wide defaults in G4, which means there is one system that applies to all your KDE applications. Say goodbye to tweaking dozens of apps individually so they all have that exact same preference.


• Deleting files: G3 lets you configure whether to move to trash or delete, and whether to ask for confirmation. In G4, both options are available in the side bar actions or in the context menu. There is no need for an option because G4 actually shows more features in the default UI!


• Slideshow: 5 options for controlling slideshows. Hey, didn't we have some full screen options previously? Yes we did, and on a completely different page in the dialog. Fail. In G4, all of these options are right there in the full screen view. Again, more efficient, same powerful app.


• KIPI Plugins: still there, and they are rocking in KDE SC 4.


• What to do when leaving a modified image: three options including "ask", "save silently" and "discard", but really this is a per-image choice isn't it? I don't want to set this globally! In G4 there is a bar that appears at the top of the viewing area when an image is (or images are) modified; you can even jump to the modified image if you navigate away. You can save them individually, or all at once. This unintrusive bit of user interface not only tells me more about what is going on and lets me work uninterrupted, but it obsoletes the need for these configuration entries.


• Automatically rotate image on load: G4 just pays attention to EXIF data. That's what it is there for.


• Remember state of filter on exit: G4 does not provide this. Debatable if it's valuable, but it could be a nice (re-)addition.


• Remember last opened URL: G4 implements a whole new system for this and it completely wipes the floor with G3 in this regard: there is a starting page shown which shows the last several locations you viewed along with places and bookmarks. All there in one nice view, adapts to your usage, integrates with other KDE software (thanks to the Places model) and doesn't require entires in the configuration dialog.

So by my count, and including the thumbnail info issue, G4 does 12 configuration topics better, 4 things the same and two things worse. It manages to do this with 12 items in the configuration dialogs instead of 43, with better text and layout in the dialog to boot. G4 isn't less powerful or less configurable: it's just better designed and so it isn't so painfully obvious that all those features are there.

What Does G4 Do Better?

So if G4 can match G3, does it go any further? I'd say miles and miles further.

For one, there is the above described welcome page which is so much more intuitive and easy to use that it isn't even funny. You don't have to manually create bookmarks and it adapts to your behavior and usage. G4 uses a breadcrumb navigation (which with one click becomes a trusty old plain text URL editor) that we know from many other KDE 4 Powered apps. I never have to open a file dialog in G4 as a result. Speaking of which, the file dialog handling in G3 was very difficult to use: try to open a folder to view (nope, it isn't File -> Open, and that file dialog will not give you any hint about that).

In G4 I can easily resize, remove red eye and much more right from the side bar. I can also just hover an image and click the rotate buttons (or select, or save, or..) in the little toolbar that floats right above it. This is so much faster it isn't even funny, and it lets me select multiple images without having to resort to one hand on the keyboard and one hand on the mouse.

G4's full screen view offers instant access to configuration options and it provide a thumbnail bar. It also offer an auto-play slideshow feature that is really handy.

G4 keeps the image I'm viewing in focus. If I want to view and browse at the same time, there is the thumbnail bar right at the bottom. That's right next to zoom options for "Fit", "100%" and a free moving slider. This is not only more featureful and easier to use than what is in G3, it's also consistent with the browsing view where you can resize the thumbnails!

That's just what occurs to me with a quick glance through both applications running side by side.

User Friendly?

G4 provides a cleaner view with less clutter and manages to not only keep almost all the features of G3 but adds a large number of new features as well. As an added bonus, G4's interface works far better on netbook-sized screens (I've used both G4 and G3 on them; G3 is, frankly, unusable on such a device). It looks nicer, but that's just icing on the cake. The two configuration features that I can find missing in G4 have lot of room to be added back.

Complaining about how Gwenview (and all of KDE 4 software as an extension) has been "dumbed down" and is "less featureful" because two small options aren't there (yet?) when the rest of the app is actually more featureful, powerful and elegant is pretty hard to understand.

On A Personal Note

Carla is a KDE user, and she has been really happy (by her own admission) with KDE3. That's awesome, and as someone who contributed a fair amount to KDE3 that makes me really happy.

How should I feel when she posts a really poorly crafted critique on a big web site like Linux Today? Should I start to not feel happy, maybe resent Carla's existence in our community because she writes such things? I mean, if the analysis was accurate and honed, that would be one thing. But it isn't. Human nature is to experience negative feelings attached with such an event.

That's not good at all! Carla is a member of our community and someone who, from what I can gather, not only means well but contributes via communication on Linux Today. I do not want to have wedges driven between people in our community needlessly, but that's what we risk happening when we let loose from the hip and start proclaiming that the sky is falling.

I wonder if Carla sent an email to Gwenview's author, to one of KDE's "front line communicators" such as myself, Sebas or Jos, to kde-promo or one of the press contacts on kde.org? Would that have resulted in a better article, one that would have done less unnecessary, unearned damage?

On A Less Personal Note

KDE has taken a change in direction with the 4.x series. We are more committed to sleek, elegant and organic user interfaces. We aren't always going to get it "right", at least not on the first try. These kinds of apps are far more difficult to write, but we are making great progress and seeing successes. Yes, like Gwenview.

We aren't interested in creating less powerful software, however. We should not confuse the two things, nor should we mistake how others may have approached the "how to make the UI elegant" question with how KDE is doing so.

I fully recognize that there are some people who really do like very complex, cluttered interfaces that expose "everything" all at once and hide "everything else" in arcane configuration dialogs. To those people, I can only say that I'm sorry if KDE no longer fits your worldview. I suggest maintaining KDE3 or working on new software that fits that worldview. I know that is hard because there aren't that many of you in that category, but that may also explain why KDE itself isn't making that kind of software as much anymore.

For those who are interested in powerful software that exposes that raw power through an elegant interface, I welcome you along for the journey we are on known as "KDE 4". It's exciting and it even feels a little "dangerous" at times because we are trying some new moves out here. I'm really amazed by how far things have come already and the direction is very promising. I was working on a patch to KDE 3 yesterday for a company that is supporting a KDE 3 deployment, and after that experience I was left with the realization of how much we've done.

That said, there's a lot more to do as well, and I should probably get back to that. Cheers ...

Read More

we do it to ourselves

Writing opinion pieces about a field that one is, for all intents and purposes, a "lay person" in is a pretty gutsy thing to do and fraught with the danger of, well .. getting it really wrong. This is why those who are recognized critics of food, wine, theater, movies, architecture, etc. tend to have expert-level knowledge of their respective field. They usually know many of the people in the industry very well and can recite arcane facts about their topic with command, ease and accuracy. This is not to say that all professional critics are competent, but professional critics do tend to have a certain standard of competency applied to them that lay people offering their personal opinions, valid as they may be, just don't have. The resulting difference in quality of analysis offered tends to speak for itself.

Everyone certainly has an opinion and an experience to relate. This, however, is different from an analysis or a critique. By way of example: when eating a meal at a restaurant cooked by a professional chef (and their staff), most people can identify whether the food tastes "good" or not to them. Different people will say the same dish is better or worse depending on their personal taste, of course. However, relatively few people would be able to identify all the ingredients used or preparation methods employed in the making of that dish. Even fewer would be able to accurately identify things that would improve the dish, such as which spices/herbs/flavours may have been a better compliment to the meal, what cooking method would have produced better results or what variations in ingredients would improve the result. Any food critic who can't do that, however, has no business being a food critic and will likely never make it to the "big leagues" of food criticism.

The difference between having a personal experience or opinion and offering an analysis or critique is therefore significant. I believe that sharing one's personal experience is great. Creating an analysis that one is not equipped to do is the opposite of great. While I may like or dislike the way a certain software product does something, and I may share that opinion with others, I am hesitant to proclaim why the flaws exist or how the flaws ought to be addressed unless I have made an effort to understand the fundamentals at work beyond just my own experience with that software. It's not unlike being a food critic in that way.

Unfortunately, many people who write about technology rarely could pass muster as a critic if we used the kinds of standards employed in most other fields. There are bright lights in the darkness, including people who are quite critical of the results of F/OSS projects. Those people tend to know of what they write and I really enjoy (even when I disagree) with what they write. They tend to either be people with deep first-hand personal experience in the act of creation of what they are writing about or they are people who have done a lot of homework and research into the matter to ensure they have a deep understanding of the field. They do not simply shoot from the hip and hope it sticks.

When people in our community write with a nonchalant attitude and offer analysis without the basis to do so, they do us a significant disservice. After all, we don't need competition creating FUD when we are doing it ourselves by generating gross misinformation that undermines our own activities. The amount of inaccurate information in circulation in our community can quite often, in my experience, be traced back to such unfortunate "analysis" pieces.

To quote Radiohead: "You do it to yourself, you do, and that's why it really hurts."

What really sucks is that these same people really do mean well and are, with all honesty in their souls, trying to participate in a positive manner in our communities. As such, I can't bring myself to get upset with them as individuals, but I do wish we could improve the situation and avoid a lot of needless energy wasting. Perhaps having a minimum set of standards we hold each other to when publishing what amounts to technical critique and analysis, just like other fields with critics try to, would be useful.

What do you think? How can we improve this situation?

Read More

key quest: webkit

The list of "Key Quests for 2010" was alphabetical. It was a sensible ordering and it prevented me from having to prioritize them in some linear fashion that could never be definitive anyways: all the points are important, though often in different ways, for different reasons and even with different key audiences. So, alphabetical ordering it was! This meant that WebKit was going to be the last topic, and now here we are. (Honestly, I'm glad I'll be able to get back to more "stream of consciousness, spur of the moment" blogging! :)

The topic of WebKit is not the easiest one. It's had its share of controversy and until recently QtWebKit wasn't really, at least in my opinion, quite up to scratch for production usage outside of fairly simple use cases. With Qt 4.6, which came with improvements across the board and new API for things like DOM access, it has turned a very important corner and makes the topic of "What does KDE want to do with QtWebKit?" ever more pressing.

When it comes to a web rendering stack, there are generally three kinds of uses for them:

0. Web browser: this would be things like Konqueror, Firefox, Chrome, Internet Explorer, Opera, etc. They have one purpose in life, and that is to wrap themselves around a web content stack and give people the ability to "browse the web"


1. Displaying XHTML/JS content from Internet sites inside a non-web-browser application: examples include the web or Remember The Milk widgets in Plasma, the Wikipedia content for geographical locations shown in Marble or the plethora of web based information shown in Amarok. These applications are not web browsers, and the content shown is highly specific and even pre-selected by the application developer. Done well, the user doesn't even think "oh hey, I'm browsing the web!"


2. Displaying XHTML/JS content in a non-web-browser application that is locally generated: this includes things like KDE's documentation reader and the email viewer in KMail. These applications are using the web stack as a rendering system and little more. That you can fetch content from web servers on the network isn't too relevant and, done well, there are no "visible seams" between the "native" parts of the application and the HTML rendered content.

When it comes to WebKit and KDE, it is quite evident that it is in the latter two categories where it could have the biggest "footprint": there are simply dozens of applications that could be using it (versus our one web browser). They are also the easier topics since the usage of a web stack is simpler and more straightforward than in a full blown web browser. The conversation around whether to use WebKit in a web browser is not nearly as clear cut and we already have that conversation happening in the form of projects like Rekonq and Arora, in any case. So I'd like to focus on the non-web-browser application usage of WebKit in this entry.

As 2009 closed out, a couple of very significant QtWebKit events came about for KDE: the API around QtWebKit expanded considerably (the DOM API, for instance, which is often used in our applications now) and KDE WebKit was added to kdelibs. KDE WebKit takes QtWebKit and implements all the platform-specific integration bits, where the platform in this case is KDE. Things like KIO (and therefor the proxies set up in KDE's control center), KParts, cookies and more have been made available to users of QtWebKit as a result. These developments have made QtWebKit a serious contender for usage in KDE applications.

Of course, just because it exists is no reason to jump on the QtWebKit bandwagon. If we are going to use QtWebKit (or not), we need have reasons for doing so (or not doing so). We already have KHTML and it works rather well and is still under development, after all. Is there any compelling reason to use KDE WebKit in our applications instead of KHTML?

The Network Effect

We all know that WebKit, which was birthed from KHTML, is now used in several top tier web browsers and even more applications. Apple's Safari and Google's Chrome are both well known examples. This means that there are, relatively, huge numbers of people working on WebKit. This matters because web technologies and standards are not standing still. In fact, it's moving faster than ever and it requires a large effort to keep up. While I have all the admiration and respect in the world for the team working on KHTML and believe that given enough time there isn't anything they couldn't implement, the reality is that the amount of person-hours are limited and it is a far more sure bet that WebKit will keep pace in a relevant manner relative to the standards given the companies and communities behind it.

This affects all applications that would like to use the newer XHTML features that are becoming available.

There is also the issue of bug and feature compatibility. It is not true that every usage of WebKit is bug compatible or even feature compatible. This is because different products that use WebKit often ship with a branch or fork of WebKit that is slightly different from other branches out there. In part the differences stem from the branches coming off of mainline at different points in time (so it's an artifact of different release schedules) but also in part due to some customizations that are application-specific that get made. Still, there is greater similarity than difference and due to the number of WebKit apps and web browsers out there in daily usage, WebKit variants get more testing by web developers than our own KHTML does or likely ever will.

This is something that primarily affects usage in a web browser, such as Konqueror, however. For applications that generate their own content (e.g. KMail's email viewer), it's a non-issue. It does still come into play for applications that are doing "mash ups" using content directly ripped from sites online.

Technical Advantages

WebKit also has a number of technical tricks that have given some projects, such as Plasma, to already start using it.

First, it's canvas friendly and is easy to make at home on a QGraphicsScene. The Plasma team already did up some basic integration for gestures and zooming, but the Qt devs have recently gone even further and cooked up a really nice, mobile-ready implementation with things like "over scrolling" where you can scroll into areas of the page that haven't been rendered yet and they are "grey" until filled. That's mostly a mobile platform issue, but it shows what is not only possible but available today.

Then there is the really nice support for "mashing up" C++ (or, I suppose, Ruby/Python/etc) elements from your app with the web canvas and control element presentation and content from the app's "native" language.

The JavaScript runtime from WebKit now also powers QtScript, which means that if the application is using WebKit and QtScript then the JavaScript runtime code is shared (not the actual runtime environments, of course :).

There are also things like the very nice Web Inspector that comes along with WebKit for free. There are efforts underway for things like accelerating animations and effects and web slices/scraps. These are all cool things above and beyond "just" WebKit and shows that even in the Qt layers there is really interesting progress that continues to be made.

The above are all reasons why QtWebKit was the best fit choice for Plasma: we use QtScript, we are doing "mash ups" fairly regularly and we need as many of the current web features as possible. The Silk project is also relying on QtWebKit for things such as the site-specific browser, Selkie.

Release Schedule Challenges

One challenge that comes up in regards to relying on QtWebKit is whether or not KDE's release schedules and our development needs (read: feature requests) can be met by relying on a project with a different release schedule and even different feature priorities.

Features we need in a web rendering stack essentially come down to this: what does the current web dev community expect to be available in a web rendering stack (WebKit generally has the upper hand here) and what integration points into KDE technologies does the stack have? When it comes to integration points, the QtWebKit team has shown themselves to be very responsive to this and solutions have been forthcoming. It it what enabled the work done for KDE WebKit to be possible. For this reason, I don't think that features are a reasonable objection at this point.

As for release schedule timing, we have turned the art of "when will Qt get feature $FOO" into a science in KDE. I'd rather coordinate with Qt's schedule to get the desired features and performance results than have a perfectly melded schedule. Yes, it's a trade off, but the benefits outweigh the costs here.

Of course, others may have different opinions ... but we really ought to stop waffling just because there are different opinions.

Embracing Evolution

WebKit came from KHTML. It is, in my mind, the next step in the KDE Web Experience odyssey. (Again, others will differ in viewpoint, I'm sure.) WebKit has "taken over the world" as much as that is possible, becoming probably the most widely deployed web stack in terms of usage in different projects. The user base is also huge. These are successes that used our own people's efforts as a springboard. We should embrace that success and make it our own again rather than be put off due to it.

To speak to the "elephant in the room": I don't want to see KHTML development cease, nor do I think it should be limited or even needs to be. However, KHTML's existence alone does not mean that KDE applications must use it if there are more appropriate alternatives. "More appropriate" is a somewhat loaded term; in my mind WebKit would need to meet the integration requirements (using technology stacks which are so foreign that they degrade integration is not a good answer). It's an unenviable position to have competing technologies to choose from, especially when they are so close to our hearts, but this is the kind of decision we are faced with.

As more KDE applications use QtWebKit, if only because it offers features and functionality that we can't expect to get elsewhere in reasonable time frames, we are faced with a poignant question: are we comfortable with having some applications using one web stack and other applications using a different one? (That is our current reality.) Should we be aiming for consistency here, using the web stack that has the most to offer, weighing integration together with features and developer resources? Or are we alright with the extra overhead of having multiple web rendering stacks required for a KDE experience?

This is a discussion that's been simmering for a couple of years now. I think it's been somewhat academic up until this point because we didn't have KDE WebKit and QtWebKit was still missing important functionality. The current state, however, is that we do have KDE WebKit and QtWebKit is ready for what we use it for in our applications. I know because I've spent time over the last year looking at how we use XHTML in our various applications, whether it's in the KDE Help Center, KMail, the application welcome screens or apps like Plasma which are a bit more dynamic in their XHTML usage. The questions are therefore no longer academic but practical.

KDE application developers should form a consensus around this issue as much as is possible. We should want KDE applications do what is best for the applications and therefore our users. I personally believe that KDE WebKit is our best option, but consensus followed by action is what will really count. This is not the easiest decision, but then again it isn't really the hardest of decisions, either. If we decide make KDE WebKit (already it is included with kdelibs) as part of our applications' evolutionary path I think we will gain enough from it in terms of features and performance to justify the efforts.

Beyond What We Could, And Recognizing What We Are Already Doing

WebKit is already an integral part of Plasma, Amarok, Selkie and Rekonq. I can only assume it's being used in even more KDE applications and I just haven't noticed it yet. Regardless of what other KDE applications do, usage of WebKit in these applications means WebKit will be making a significant impression within the KDE universe in 2010.

Using it to write Plasmoids, both via QtScript as well as directly using XHTML/JS in a WebKit container, is just one example of where it is taking us. Due to this emergence, and the question we now have in front of us regarding just how pervasively we want to use KDE WebKit in KDE applications, this will be one topic that will be a noticeable part of 2010 for us.

Epilogue

I'd like to close with a huge "THANK YOU" and an expression of my respect and gratitude to everyone who has worked on KHTML today or in the past. I think it's been a remarkable project from day one and remains a remarkable project right to this day. It blazed trails for F/OSS web stacks and has become insanely successful in various ways. This stands on its own, inviolable and untouched by the contents of this blog entry.

This also closes out the "Key Quests for 2010" blog entry series. I hope those who have read it have enjoyed it or at least been moved to thinking about some of the opportunities, challenges and ideas we who make up KDE are going to come across in the year ahead. I also truly hope that it inspires further discussion throughout the community and that they entries serve not as end points but as conversation starters, though provokers. None of us alone have all the answers, but together we can get pretty close. This has been key to the success of KDE.

There are so many compelling and exciting things afoot in KDE right now that 2010 is almost certainly going to be an amazing year for all of us. The 14 areas of interest I discussed in this series just scratch the surface, and mostly in areas of KDE-wide needs. There is so much more that happens at the "local" level within KDE and so many more things that are going so well that we hardly need to add to the discussions those topics already receive. That why KDE in 2010 is an experience I can't wait to be a part of along with all of you.

*hugs*, aseigo.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: web presence

When I was contemplating the topics for my "Key Quests for 2010" list in December 2009, even before I had decided whether I'd share the list with others, the issue of KDE's web footprint came up pretty quickly in the process. It is very often our first impression for people who would like to get involved or who would like to find out more about us. It is where people go before they know how to (or if they want to) communicate with us directly. It also has been something we've really struggled with improving.

Nobody really "owns" the web sites, which makes it a bit trickier (as it can devolve into a free-for-all), and we haven't historically been very good at integrating web designers and developers into the workflow without a bunch of C++ geeks piling on. ;) So, it's been a struggle.

It would be great if we were able to give the web sites completely over to a web development team and rely on them to consult the people who have been around KDE the longest and with the greatest sense of the "pulse" of the project from a communications and marketing point of view. That, to date, hasn't happened.

There are brights points in our web presence, however: we have TechBase, Userbase and the Community Wiki now. We have the KDE Forums, which also hosts KDE Brainstorm. These are all vibrant, functional and relevant, proving that it can be done.

So when I put this item on my list, I was at once pensive due to our track record on the topic and optimistic given that the newer sites mentioned above do have a lot of positive things going for them. Since I crafted the list, however, something very interesting and relevant happened: at the KDE Promo sprint the topic of the web sites was addressed. Since then, people have been putting together plans and starting to follow through on them. Lydia announced this effort on her blog just this week, in fact! You can get involved and help out as well: you can find the web team on #kde-www on irc.freenode.net and consult the WWW Rework Scratchpad on the Community Wiki for additional information.

It will not happen overnight, of course, and will be an ongoing effort. I am so excited to see this happening, however, and it's something we all need to get behind and support. Getting the right messaging out will require the cooperation of the promo team, the revitalized web team and the rest of us creating KDE's set of products. Hopefully, with enough people lending a hand over this next year, this item will not reappear on my list for 2011. :)

For my own part, I need to finally get to completely re-doing plasma.kde.org. Now that we actually know what the name will be referring to (which is why the branding discussions were a blocker), this is on my "4.5 dev cycle" list. It's not kde.org, but it will be the Plasma team's contribution to the larger effort.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: quality

Preamble

The topic of "software quality" is tricky and full of potential traps. There are so many ways to define and measure software quality and so many different kinds of audiences to think about when discussing it, that software quality discussions far too easily fall of the tracks of usefulness. If at all possible, I'd like the comments to this blog to not fill up with bug reports or comments like "well, it's about time because poor-user-me has ...". While those are assuredly valid comments to make, we could probably all make one of them and then we won't be able to discuss what we are actually going to be doing in terms of software quality improvements in KDE for 2010. The result would be to verge on futility.

We have bugs.kde.org, brainstorm and other places for such feedback that are much more useful than my blog for those comments, after all. As such, I will be removing such comments with prejudice if posted to this entry. I will be deleting them "non-permanently" (to use blogger's definition of that), so people will be able to see which comments were removed and who posted the comment.

But enough of that ... onwards!

Why 2010?

In this series I've been highlighting a set of issues that I personally believe to be potentially critical issues for KDE to be mindful of in the coming year. Some issues didn't make the list because they are sufficiently in hand, limited in scope (even if important!) or unlikely to get attention in 2010 (though in some cases I'd love to be proven wrong there!). The issue of software quality in the context of KDE's efforts in 2010 followed naturally in my mind. Why?

Many key projects that have been part of KDE's 4.x odyssey have reached interesting points in their development by the end of 2009. Most of them have reached a level of general utility and even polish that had been the primary locus points of attention for our developers. THis is because many of these technologies were very new or trying to do new things. Whether we look at Amarok2, Plasma, Nepomuk, Solid, Phonon, KDE integration for PolicyKit/PackageKit along with many other examples, there was simply a lot of newness. This was a necessary step towards bringing to the table much needed advances in what we are able to offer to people using computers.

It also reminds me of the early KDE 2 releases; while much more contained in their scope (KDE has grown a lot since then), those releases were also "obviously new code" in their feel. They quickly became robust, release over release, and started maturing with an impressive path towards a great set of software. The fierce commitment to KDE 3.5 we have all seen on the part of various users is a result of that process.

As we are exiting, able to see the exit point or have exited from the "newness" stage for most of these key technologies, it is natural that the software based on the KDE Dev Platform v4 are going to be going through a similar journey.

How Fast, How Focussed?

I don't think it will take as long to get our current generation of software to the same levels (and beyond) of reliability linked to the the 3.5 series as it did KDE 2.x. In large part, this is because we are building on top of those rock solid bodies of work: we still have KDE Core, UI, KIO and many others. While these are all still seeing work and improvement (KIO recently got a new and improved scheduler, for instance), they give us a wider base of stability than KDE 2 ever had the benefit of. On the other hand, we've also created huge spans of new functionality that needs to go through a process of quality improvement.

One question will be how to balance the forward progress of new features versus quality improvement work. New functionality increases our user base as well as our developer base, so is crucial. Quality improvements also do this, but much more incrementally. Still, without a certain level of quality met, it becomes a weak point for us. This balancing point will need to be found. Still, I believe 2010 will be a year that we experience across the board quality improvements in KDE software. This is not to say we're in a horrible position right now, but rather that it can be better and that it is highly likely, given our exiting from the "newness" stage of development, that we will see more quality focused work and results in 2010 than in 2008 or 2009.

How Can We Achieve Quality?

How we can achieve greater quality is a starting point for an ongoing conversation. Part of that conversation will be how to measure where we are at any point in time. Measurement allows us to know if we are going in the desired directions or not. That's why things like tracking defect report numbers on bugs.kde.org, Paul's continued work on metrics and tools like the English Breakfast Network and automated build farms will likely play even larger role in our efforts in 2010.

We have a slew of the "usual suspects" for increasing quality: automated testing, improving documentation and even just simply "using it more for longer". What concrete actions we will take will be another interesting set of discussions, and one that I think will be different for each project in KDE since not all projects are at the same points in their development.

We've been discussing this a bit within the Plasma project and it will be one of the focus topics for Tokamak 4 next month. Currently my plan, with the proviso that this is not final and will likely shift with further team collaboration at Tokamak, is this:

For the KDE Software Compilation 4.5 release, we will be focusing primarily on "finishing and polishing". We have a number of existing projects that aren't "quite there yet". Things like Plasmate are tantalizingly close while others such as Plasma Mobile and Plasma Media Center are still in their larval stages. We need to put more focus on finishing these things out and shipping them in useful states.

Then there is the issue of smoothing off the edges. A number of features offered by Plasma components are pretty compelling, but have a "last mile" left to be walked before they have the "right feeling" to them. An obvious example that jumps to my mind is notifications: we have more work to do there for queuing and passive management of them. I don't think anyone has really got this nailed yet, which isn't very surprising since right now I only know of two F/OSS groups even paying attention to the various pieces involved (which includes system tray icons, notification pop ups, logging and user interaction). Notifications aren't the only thing that needs tightening up so it feels "finished, polished, meeting our dreams for coherency and organics".

Finally, there is the more pedestrian issue of defects. With each release of Plasma and the applications we build around them, such as plasma-desktop, we've slayed huge number of defects. Some releases have seen, quite literally, hundreds of defects fixed relative to the previous release. We're shipping a couple hundred thousand lines of code with each KDE SC release that Plasma participates in. That code is very feature-efficient, in that there is little "boilerplate" duplication and a lot of functionality sharing (often commits reduce code count rather than increase it, these days). So with 4.5, and potentially 4.6, we will be focusing more on the existing code than adding more newness. There will certainly be new features and noticeable expansions in existing features (part of the "finishing things we've started" part of this), but there will be less focus on completely new things relative to the focus on working what's there now. In sports that involve swinging sticks, this is often referred to as the "follow-through".

Now, this is not the strategy that every project in KDE will adopt for 2010. I don't think it's even appropriate for some KDE projects that are either still in "newness" or are already in a nicely mature state. However, I do expect to see more KDE project mulling over these kinds of topics in 2010, relative to 2009, and as such for the 4.5 and 4.6 KDE SC releases (not to mention the KOffice 2.x, Amarok 2.x, Digikam 2.x, etc) releases to reach new quality peaks.

Don't Stop The Innovation!

I spoke earlier about a balance, and I'd like to close by re-iterating that point. We shouldn't aim to stop innovation (things like Silk, which was the topic of my previous blog entry require we don't, in fact) and aim to ossify our projects and start down the road of diminishing incremental returns. However, I do think that we've had the luxury and even need to focus more on getting the "newness" phases of KDE 4 behind us and that now it's a good opportunity to swing things to a new balance point with an increase on product quality.

I'll personally be watching various KDE projects with great interest throughout 2010 to see how this all pans out.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: silk

I used to have a silk dress shirt. It was a rich blue color, a bit loose fitting and just great for the hot and humid semi-tropical climate of Hawaii where I was living at the time. That isn't the kind of silk this blog entry is about, however. Rather it's going to be about KDE Silk which is a project which aims to deeply integrate online content and communication into the user experience.

To quote the KDE Silk wiki page: "The goal of Project Silk is deep coupling of the web with the user experience while overcoming limitations of the browser. "Freeing the Web From the Browser", so to say. Project Silk takes the opposite direction of Google's Chrome OS, instead of making the browser the Operating System, we integrate the content and the communication deeply into the desktop and application "

I don't think we will, or even should try to, ultimately get rid of the web browser and online services can be insanely terrific for many different kinds of needs. What's unfortunate is that the online services world has (to speak in slightly broad generalities) artificially restricted itself to a world where the web browser is the only container while on the other hand non-web-browser software has traditionally watched the online services train come down the tracks with that deer-in-the-headlights look.

Nobody is winning from these non-strategies. I call them "non-strategies" because they aren't the result of someone(s) really sitting down and saying, "You know what, I think that's the best possible set of answers, all things considered." They are the result of people attacking the problem from the assumption that we only have what's directly in front of us to work from. There is very little "step outside the box" thinking and so instead we get people writing excessive amounts of code to get native assembler to run in a web browser window. Seriously?

When it comes to KDE specifically, we can do better and, in fact, we already do in some cases. Things like the KIPI Plugins used in Digikam, Gwenview, KPhotoAlbum and elsewhere that have integration with online services, Amarok's pervasive online service integration or Marble's usage of OpenStreetMap and Wikipedia are good examples. These certainly aren't going to improve the web development world's obsession with the web browser, but they will give people who use KDE software improved ways of working with the great services created by the web development world. At the very least, it will keep our software from becoming needlessly irrelevant just because web services take off. At best, it may provide a template for others to consider. Somewhere in between we manage to bring smiles to the faces of our users.

We have terrific tools at our disposal to achieve this right now: we have KIO's network features, we have Plasma which is much more service oriented than what it replaced, we have QtWebKit which let's us do all sorts of really cool XHTML/Javascript/C++ (yes, C++) mashups .. and now we have Silk which is bringing us things like site-specific-browsers and hightened online service integration.

In my opinion, KDE software needs to take advantage of the rising tide of features and capabilities available through online services (where applicable, anyways) to remain interesting and relevant in the long term. We need to consider that software is becoming increasingly social in usage for people and that things like pervasive availability of data and collaboration with others are becoming things computer users are starting to take for granted as "must have features". We also have a responsibility to the world at large to not aid in the creation of a situation where the only online services that are viable and interesting are vendor lock in traps; the Free web needs allies and it is hard to imagine a better candidate for such an ally than Free software communities like KDE.

I've actually written about all of the above in previous blog entries in the past, but I believe now that with Silk, the ever-growing trend of online services and the tools that have become available to us in the last year or so that 2010 may well be an inflection point for KDE and online service integration.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: scripting and dynamic language support

Let me say it right at the start here: I really enjoy coding in C++. To some that makes me a very odd sort of animal, I know. (There are also probably more convincing reasons to consider me a very odd animal, but that's another blog entirely. ;) Still, despite my enjoying slinging C++ around, I also know that trying to insist that everyone else does the same is probably not the best thing for KDE. I believe that in 2010 we may see the "next step" in acceptance and adoption of languages-other-than-C++ around the KDE community and that it could be an important part of how things shape up this year.

There are two different topics here, really: in-application scripting and application development proper.

Creating Applications Without C++

We have some great language options for people writing KDE code, and have had for a number of years thanks to the foresight and diligence of the KDE Bindings community. We owe them a debt of gratitude for these efforts, because as a result of them we can choose to write applications in Python, Ruby and other languages. For the sort of code that gets written in the vast majority of applications, the added overhead of these languages is a complete non-issue in terms of user experience impact.

The benefit is that people can write applications faster and with fewer errors, not to mention they don't have to learn C++ if their language of choice and expertise is Python or Ruby. That means that we could see more applications with fewer defects coming from a larger audience.

In 2009, we saw the first non-C++ application ship with the KDE Software Compilation: a printer configuration tool. There are many other great Python/Ruby KDE applications "out there" coming from the wider audience of people who write software with the KDE Development Platform. It would be great if in 2010 we can raise awareness of this and as a result grow our third party development audience as well as see increases in efficiency amongst some of our own application projects.

Now, there is some downside to divergence from C++ as a "lingua franca": it is harder for someone who doesn't know Python to contribute to a Python application. However, based on my experience in doing so, it's completely within reason. (I don't "know Python", per se, but I have contributed patches to Python applications despite that. :) This is in large part offset by the fact that we don't rely on the language itself as much as we rely on the great APIs that Qt and KDE deliver as our "lingua franca". Which is to say: a KFileDialog in any language is still a KFileDialog. ;)

In-Application Scripting

While having a multiplicity of languages and not caring particularly for the overhead of them is completely acceptable, and even comes with some benefits, in the application development arena, the landscape is a bit different when it comes to application automation, aka "scripting".

Such scripting encompasses a wide range of applications: from writing bits of glue in a spreadsheet to writing extensions for Amarok to Plasma widgets, in-application scripting can transform an application into a static black-box experience into one that can be easily extended at runtime by even novice users (by using scripts from other less-than-novice users) while still keeping the default user interface sane.

The choice of language here is probably a bit more critical than with application development. The choice should appeal to the widest possible audience, should be available (e.g. installed) on the widest number of systems and should (paradoxically) not include so much more functionality than actually needed that it becomes a management nightmare for the user. That last point is one that is usually learned by application developers the hard way by offering support for, e.g. Python scripting, only to find that some of the scripts written and being shared around require some obscure or version-incompatible bindings/additions/API extensions to the language making it much trickier for users of the application to reliably use scripts from a shared repository.

This is why in Plasma we have elected to support various languages (including Python and Ruby), but to also try and promote the usage of Javascript: it's included with Qt, it has a very very large user base and it is limited in scope allowing us to craft the scripting experience we want in a more reliable (for our users) fashion. This is also why at Akademy in 2007 there was general agreement amongst the attendees (some 50+ core developers were at this particular meeting, if I recall correctly) to promote Javascript as the preferred default for such applications, even when we also support other languages, such as Python and Ruby, as viable options at the discretion of our users.

In 2010, I think that such scripting is going to take a larger role than ever before in KDE software. The Javascript APIs for Plasma are really shaping up (some distributions are already shifting to it for management of Plasma Desktop installations and we're getting more questions about Javascript Plasmoids than C++ ones these days), Amarok 2 is really hitting its stride and the idea as a whole seems to really be getting more and more legs. Consider today's posting by Fred Emmott of a Javascript based Qt application testing framework: it allows recording and playback of interface interaction and application execution, all powered by QtScript for the automation.

This strategy, which can be seen being employed to great results in other hugely successful pieces of software such as Microsoft Office and Mozilla Firefox, can help us create more streamlined default interfaces with more options for our users in a manageable fashion. Combined with the increased traction we're seeing right now, this could be one of the signature shapers of KDE software in 2010.

We have excellent tools (QtScript as well as Kross) that make it really quite easy to accomplish it in our applications. What are we waiting for? :)

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: promo messaging

In 2009 we set in motion a set of tweaks to our usage of names in relation to our brands. This was the culmination of a set of discussions some of us had starting at least as far back as Akademy in 2006 that resulted in various stages of planning leading up to the 4.0 release of the KDE Software Compilation and eventually put into writing and implemented. The goal of these changes is to increase the clarity of our messaging as well as to knock down some long standing and rather silly barriers to adoption of KDE software.

For it to "work", however, we will all need to be mindful of these changes and use them in our public communication consistently. This is because such messaging only works when it is repeated. In one speech training program I was in years ago, they would "grade" various aspects of speeches given and one of the metrics sometimes used was "repetition for emphasis". It really does work, and without it branding simply falls apart.

When it comes to promotional messaging in 2010, we are going to be facing a lot more than "just" words we use around our main product brands. The principles around each of these opportunities and challenges will be similar to the branding re-positioning, however:

• They will need to reflect the realities of KDE as it is today and the near future


• We will need to achieve agreement over them


• We will need to be consistent in our implementation and repetition of them

The KDE Promo group is currently extremely alive and vital, more so than it perhaps ever has been in the past. There is real coordination and organization going on, rather than just a small handful of people pulling on the ropes as hard as they can when they can. There is a Promo Wiki that is slowly filling with content and there is movement on getting our web presence more in order. These are great opportunities for those with people and/or web skills who would like to get involved with making KDE even more successful and enjoyable. (The relevant KDE Promo mailing list is here if you are interested. :)

As a result, the practice of accurately and compellingly communicating what we are doing and what we are producing as a result is going to be one of the activities that will be quite visible in 2010 for KDE. This "key quest" has great momentum already, but there everyone in KDE will want to keep an eye/ear on what is happening here so that we can help out with, at the very least, being part of the accurate transmission of these ideas to others as we go around and repeat, repeat, repeat the ideas at the core of our efforts.

I'm also personally hoping that we can come up with some really moving and fundamental "reasons for KDE" messaging in 2010 that can answer "Why should I be using KDE software, and which KDE software in particular should I be using?" Sparking new appetites for Free software will be aided immensely if we can do this.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: nepomuk

Nepomuk, the "social-semantic desktop" framework named with a cute half-dragon namesake. It's an amazing set of technologies, but there are two huge challenges for it in 2010. If we conquer those challenges together, we will be laughing.

Communicating Nepomuk's Benefits

Right now there are a lot of questions surrounding Nepomuk: What is it good for? Why does it take so much CPU / disk? Why do I need it if I don't plan on doing any socializing or semanticizing (?!) on my computer? This translates to a lack of enthusiasm, appreciation and even frustration amongst our users and even at times developers.

The thing is: all of those questions have good answers. Whether it's the performance improvements of Virtuoso, educating our users about how Nepomuk is being used by various "every day tasks" (such as indexing and relating email, contacts and other PIM data via Akonadi, all behind the scenes and with good perormance) or making it easier to figure out that it's quite easy to turn off the disk indexing parts if you want, these things aren't getting communicated very well yet.

There is a page about this on our Community Wiki. That needs to be fleshed out as needed, read by everyone who is doing communication on behalf of KDE and then shared as often and widely as possible.

As developers or technophiles with a deep understanding of these esoterica, we know the benefits of Nepomuk and get rather excited about it. Everyone deserves to feel that excitement, too. :)

Delivering Nepomuk's Benefits

This one is easy to describe, but harder to do because it takes effort. A lot of it over a period of time. Delivering on Nepomuk's benefits means using Nepomuk features in as many of our applications as possible in as many creative ways as possible so that people who use KDE can just start to take for granted that those features will be there in KDE applications. Think of it as the new copy and paste, maybe. :)

In 2010, if each of our application projects implemented even just one feature that used Nepomuk in some relevant way, even if it was completely behind the scenes, we'd end up with an amazing network effect as the user's data swirls around in the crunchy ontologies of Nepomuk.

I'll admit that we haven't done nearly enough of this yet in the Plasma Workspaces (we wanted to have some Nepomuk features in 4.4, but they got punted till 4.5 as they aren't quite finished to our satisfaction), so we'll be on this key quest like a dirty shirt in 2010. :)

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: mobilizing and enabling KDE users

KDE has added new dimensions to our repertoire over the last few years. A move towards greater awareness that we are part of a larger free culture movement that has taken hold in various ways and form around the world is one such shift. It hasn't changed what we do (create client-side software with all the trimmings) but it has changed some of how we do it and what we include in our software.

A key concept in free culture is participation: it isn't a spectator sport or a watch-the-rock-star-on-stage-from-the-audience experience. We each take our turns as audience and the performer, sometimes simultaneously. The implication here is that the people who are our audience can also be performers in their own right. We're starting to see this happen, but to be honest it's all a bit awkward at times. That is not too surprising: it's something new, and new skills take time to build up. We also don't have many examples in history to pattern our behavior after; most examples we could look to are contemporaneous to our own experience. (Examples might include Wikipedia and OpenStreetmap for content, Mozilla for software, various social media sites, ..)

If we can find ways to enable KDE users to spend more time "up on stage" themselves, at least to the extent they feel self-compelled to, I think we could all win a lot. It would be more enjoyable for our "fan base" (I'm a card carrying member of our fan base, btw :), it could help spread the KDE love and experience and it would bring new rewards to the KDE community.

In 2009 we saw some seeds sown that may well turn into our "first crops". The bug days are doing terrific things, and the trick there is simple: advertise then facilitate IRC meetings then report on the good that was achieved for everyone to take notice of. There is the KDE brainstorm is helping people connect in a much more positive and helpful way with developers (I"ve snagged a few good ideas from there already, in fact, and it's much more enjoyable than the usual dysfunction at bugs.kde.org). Then there is Userbase that is aiming to collect a body of user-generated content and documentation. I'm especially inspired by the various ideas and efforts that Anne Wilson is spearheading with Userbase.

I think 2010 could be a breakthrough year for these efforts, where they transition from "new additions to KDE" to things we just take for granted and come to rely on with a healthy amount of support from our users.

Then there is promo and communication. The organization of release parties (in this case for the KDE Software Compilation v4.4) is good and the level of attendance for trade show booths year after year is very impressive, but perhaps we can do more and get more people involved. Can we make it easy for people to give KDE related presentations in their area through materials or even some online training? How can we enable KDE fans to show KDE to others as much, as often and as accurately as possible?

In one question: What else can we do to harness the latent energy in our biggest fans?

I'd love to see 2010 be a year where more of our closest users feel more involved with achieving our shared goals than ever before.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: managing the wave of new apps

When looking ahead to 2010 relative to 2007-2009, I sense a trend emerging right now that is bringing more apps into the KDE universe. That may sound like I just got off the phone with a 1-900 psychic hotline, but hear me out. ;)

There are two kinds of "new apps" that I'm thinking about as I write this: the traditional monolithic wonderbeasts we're used to and the new nimble toyland children known as "widgets" (or more specifically Plasmoids for the cool cats in the audience). I think we're going to see a lot more of both in 2010, and that creates both opportunity as well as challenge.

Recently a set of three applications joined KDE's source repository, and they have a few things in common. First, they are all finance applications: KMyMoney and Skrooge for personal finance and Kraft for small/medium size business finances. This is significant as it means the central KDE community just went from zero to three extensive applications in this category.

Second, they all had a life before joining the KDE mothership; they aren't first-draft applications. In fact, KDE e.V. itself uses Kraft for its finances quite successfully. This shows how KDE's boundaries are growing to encompass more and more of our community to make the most of the network effects that result from doing so. From pages on Userbase to project pages on Techbase, entries on the KDE Extra Gear website, bug tracking on bugs.kde.org, better access to our translation heros and more, the integration of these apps into the community is coming along pretty well.

Then there are other new comers that pop up more and more often, from games to media players. We're sprouting apps right now, it seems. This is not unlike my experience with KDE 3 where we started sprouting apps sometime around 3.2 or so. We made this an explicit focus (I believe it was Waldo who kept beating that drum, in fact) and it paid off in spades. It's time to do this again, I think.

We also, however, need to ensure that can pass on to them our community values as well as the value of our community. Developer sprints would be one way, ensuring they get settled nicely into our cozy source code repository and get to know others in the community so they are well connected with others. (Hm, am I starting to sound a bit like Paul Adams? ;)

So both attracting new development while helping them build firm foundations to build on (so that we don't have to worry too much about identifying them in future as projects in trouble :) is going to be a key quest for 2010. At least it will be a fun one!

Then there is the march of the widgets. We have hundreds of Plasmoid widgets available for Plasma
apps, not counting any of the ones available via Google Gadgets and what not. If we play our cards right, with the combination of hitting the device spectrum harder and opening the gates of scripting in 2010, we should be able to make our current numbers look paltry.

This is going to mean some new challenges. Managing thousands of widgets, providing good online access to them (Store? I want a warehouse! Only more like a community garden. :) and ensuring that there is security and levels of quality that match.

There are terrific opportunities around harnessing the power of these "thirty minutes and you've got something really interesting, a week and you can have something awesome" type mini-applications which people can glue together into their favorite constellations. From the Plasma side of KDE, and as a way to get KDE into more hands in more ways, this becomes part of our key quests for 2010.

What's most interesting about the issue of these new apps is that most of the work needs to be done on processes and code that already exists, be it in people moving more to the center with their mature apps in tow such as with the finance apps or to support the growing number of third party widgets in the Plasma framework itself. Sometimes making "the new" work means working out the existing and the old. It's going to be an interesting 2010 on this front.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: KOffice

When I first joined the KDE party, I was using Blackbox (and eventually due to my KDE involvement got to meet Brad Hughes, author of Blackbox :) and the only KDE app I used was KMail. KDE hacking was at first just a fun way to pass the time during some lull moments in my life. That seems like .. quite a while ago now. :) Even back then, KOffice was around.

When it started there was no other F/OSS office suite. Today, there is OpenOffice which "rules the roost" and then some office document apps like AbiWord (which is doing some rather cool things on the collaboration front). KOffice is the only other "suite", however, by which I mean it is a collection of applications that shares a strong identity through shared technology and design.

Even though KOffice 2 was recently released and has some really great ideas at its heart, it still plays to a bit role part in things. This is pretty unusual for a set of KDE applications that has been around as long as KOffice has been. Usually KDE applications post really good to very strong showings among F/OSS users. What has held it back? A few things, prime amongst them high fidelity support for Microsoft Office formats and a lack of effective promotion.

KOffice has always had a relatively small team, but it's been a gutsy and productive one. The team has been growing lately, though. There is a consulting company doing KOffice work now and they are slowly building up paid developers. Nokia has been working with pieces of KOffice for a document viewer for Maemo, which is great news for the MS Office compatibility front. KOffice people recently had a successful developer sprint and have moved to a use case centric development strategy. Even the icons are turning all Oxygen glory thanks to Pinheiro and the Oxygen Icon Cohortory. (yes, I just made that word up. ;) So things are growing and KOffice is on its best footing since I've been around.

I also think that the promotion of KOffice is getting aligned nicely. First off, KOffice is more than just a set of word, presentation and spreadsheet apps. It's also Krita, which is turning into one of the best image editors in the F/OSS market, and Kexi, a great database application creator. Both are very solid tools, and Kexi helped blaze trails for KDE on MS Windows. Other apps like KPlato for project management also exist. The promotion of KOffice as a development library for these kinds of applications plus a nice set of "not just office docs" apps is starting to come around.

Ok, fair enough. So why did KOffice make my list of Key Quests for 2010? I think 2010 is going to be a pivotal year, one way or the other, for KOffice and if it goes well it can rise the tide for all of KDE.

If KOffice can plant a flag on Maemo and other similar platforms, even if it is "just" the document display parts (and not the full word processing or other apps in all their UI splendor), this will be an important step forward for KDE in the device spectrum effort.

If KOffice can stabilize the key apps and continue to grow the contribution community around it, the lightweight, integrated, featurful and "good times UI" feel they have developed could propel them into a contender alongside OpenOffice. This is so critical because OpenOffice is not the most healthy of projects, and hasn't been for some time. It's not dead nor is it dieing (nor do I want it to), but it isn't exactly springing forth with life and the code base isn't exactly the most manageable thing in the world either. F/OSS would be much better off with a nimble, highly useful set of Office apps that can play back-up to (or even first fiddle eventually with) OpenOffice. It gives us more eggs in our basket and fewer single points of failure.

For KDE, it would give us a very compelling increase in our proposal to the world if we have a good office suite (and all those other crunchy happy apps, too) that (eventually could) have hooks into things like Nepomuk and Akonadi (share-what?), that start up quickly and which get the job done.

By the end of this year, I think we'll have a very clear indication of whether KOffice will be on its way to that summit or whether it will be another 10 years like the last 10. I like the energy in the project right now and the way they are going about things, and given what's at stake here, it easily made my list this year.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: identifying projects in need

This one should be really short, because it's more of an open ended question and some food for thought than a long exploration of a tangly topic. That question is: are we doing enough to ensure that projects that start to wobble a bit don't fall off the rails, crash and burn on us?

Every so often someone approaches me (or, more rarely, I approach them) to let me know that their project is in trouble in some way. Since this is a recurring issue for KDE (and other F/OSS projects, too), we can expect it to continue (and in larger numbers as our product count grows). It seems we most often just fail to identify the problem spots until it's gone a bit too far. The price we pay is great applications will stall even start to "bitrot" without achieving their full potential. There is no time like the present, however, so this made my list of Key Quests for 2010.

What's at the root of projects wobbling to their own demise? There are two issues that most often arise, and in both cases they seem to present an "unsolvable" roadblock to further development. This happens due to either technical issues such as an upstream project causing problems, or due to social issues such as one or more of the key developers no longer having the time or ability to work on the project, though on rare occasions it's due to disagreements between active contributors (though I can count the number of times that's been a real problem since I've been around KDE on my hands :).

We have a couple projects that are flagging right now and which I'm a bit concerned about. You may also be aware of some. I don't think that the sky is falling or anything; most of our projects are really rather healthy, but we can do better here, especially for the projects that are experiencing some downtime. How can we help them out?

One solution to the social issue of people dropping off due to life changes is to ensure that no one person is absolutely critical to the project in such a way that their leaving would kill the project. A constant stream of new developers is needed, and that's something we can all help with. We do a pretty good job of it already, with a pretty impressive rate of new commit accounts being generated. Can we more effectively direct some of these new hands to old projects that need them? Would it make sense in some cases for a few of us to descend upon a particular application and help get it moving again with a few months of involvement and a good jolt of energy?

The "nasty arguments" social situation is thankfully far rarer. A good, positive, supportive community really helps there, and our terrific Community Working Group fills in so many of the remaining gaps. They really are unsung heroes in the project at times. :)

For the technical issues, it is often a matter of getting the "right" people talking with each other and encouraging some creative thinking. That means that many technical issues can find solutions with some social work. Sometimes a face-to-face meeting is the best answer, and that's something that KDE e.V. can help with if there is one of us working out the logistics. This isn't rocket science, so can we get more developer sprints going where they are needed?

I enjoy helping with these things as I can, especially when it helps bring smiles back to the faces of the people I care about (read: everyone in KDE) and the code rolling in svn again. There are a few people in KDE who do this kind of work, but having more people involved in doing some health monitoring and even some nursing as necessary would be great.

I also wonder what other things we could be doing to help keep projects on their feet?

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

key quest: git

As we move from 2009 to 2010, KDE's source code is in a sort of odd limbo itself. The majority of our code is in a subversion revision control installation hosted on svn.kde.org, but more and more of the code we produce is ending up on gitorious.org. The idea is to eventually have everything moved over, with the exception of translations (and documentation?) which will stay in svn for the sake of the translation teams workflow.

Why Git?

For many people in KDE, svn no longer meets their needs for teamwork-based development. The ability to easily merge branches, to work radically off-line and a fairly impressive list covering various benefits of git are often cited as reasons to make the move. Personally I don't think it's a panacea as git comes with its own set of issues, though it is getting better and better every time I upgrade to a new version of it. I think it is quite a bit better than svn is for how we tend to work, though. That hardly matters, though, because our developers are voting with their feet.

Not only are some projects already hosted on gitorious.org, including some big ones like Amarok, a growing number of KDE developers are using git-svn so they can use git for their work and simply sync svn up with their changes periodically. The result is that our world is getting more and more fractured, with some work happening in git repositories and some on svn.kde.org. This is not optimal for the health of our community as there is a real benefit from having each other's code within "close reach" of everyone else's and only having to learn a limited number of tools to work with. When it was just svn being used (and before that cvs), we benefited from a kind of network effect and a lower barrier to entry. We're in danger of eroding both of those things.

So unless we say "no, you can't use git for anything KDE", which seems a bit draconian and probably not only unfair but risky (in terms of losing contributors), we need to get this house in order again.

The bonuses like having a better revision control system and being closer to Qt's mainline development are just bonuses next to that.

What Should Git Be For KDE?

When it comes to the migration itself, I think it is pretty important that we avoid some evident pitfalls.

First, we need good documentation on how to use git so that when the time comes we can all move over and waste as little time retooling as possible. It will help alleviate the apprehension carried by some KDE developers as they being moved to something new, and we all know how much people dislike change. :) This has been started on Techbase and seems to be making really good progress. So, with some more effort (and possibly helpers), that looks like one issue is (being) taken care of.

Next, git must not be allowed to cause "developing in secret bunkers" to start to occur in KDE. Due to its highly decentralized and off-line features, git (and other systems like it) can lead to people working on their own, self-isolated from the group for extended periods of time. This really isn't very healthy, but since it's a social problem it needs a social solution. Just being aware of it and reminding people who seem to be dropping out of the picture for extended periods of time should hopefully be enough.

Git must also not be allowed to make developing for or following development of KDE software harder. A single, canonical mainline must be kept to keep that bar low. We really don't have the need for long lived personal branches that deviate significantly from mainline and which people then have to pick between when getting KDE source code. This seems very common (and for good reasons, in my opinion) in the Linux kernel project, but it isn't a necessity when using git. Git enables a lot of workflows, and I think we should be careful about straying too far afield from the workflows which work for us today. I can't wait for feature branches to be easy to do in Plasma, but I really don't want to see the notmart-plasma and the aseigo-plasma. ;)

Between some good decision making on the part of the people doing the git migration (so we don't, for example, end up with a mess of modules with no clear purpose) and some social engineering we should stand to profit handsomely from the git migration. Seeing how we already have the kde-developers group on Gitorious (so we can all commit to the whole code base once it is in git, just as we can now in svn) and the plans the migration team have put together, I think we'll do fine.

But first we need to do the actual migration...

What Are We Waiting For?

The Move To Git page has a nice list of things that are yet to be done. Some things left are business topics such as KDE e.V. and Gitorious entering into an SLA. Some are technical (such as getting rid of svn externals, of which there are two blockers still there, one of which I'll be getting rid of in the next week or two), some are social. The team meets every week on irc and has been making fine progress.

So we aren't quite there yet, but we're a lot closer than we were a month or two ago. I'm really hoping we can complete the migration before 4.5 is out and do a great job of helping our community move over to the new system. That will allow us to do some git hand holding at Akademy and develop the 4.6 release with some shiny new tools at our disposal. As such, this made my "Key Quests for 2010" list.

(This article is part of the "Key Quests for KDE in 2010" series)

Read More

scripting widgets for the Plasma Desktop

Before moving on with today's two entries in the "key quests" series, I wanted to note a couple of interesting things that have made it in KDE SC 4.4 when it comes to writing Plasma widgets, Plasmoids, in languages other than C++.

We've had rather nice Python and Ruby support for some time, thanks to Simon Edwards on Python, Richard Dale on Ruby and Carter Beauford on the drums .. wait, no, Carter is part of some other cool group, but Simon and Richard do indeed rock out with us. ;) While I think that these are great languages for writing full applications with, I also feel that there are possibly better choices for little plugins like Plasmoids. I won't get into all those reasons here (I probably have already done so in a past blog entry, though), but there you have it.

Unfortunately, those other choices, namely JavaScript and WebKit, haven't been so great. Things have improved a lot for the 4.4 release, however. The JavaScript API has been fleshed out and pretty seriously extended. Documentation is catching up as well. There are a few improvements in particular that wanted to highlight, however.

Run-Time Extensions For JavaScript Plasmoids

The first is the ability to request API extensions for JavaScript Plasmoids. The base API is meant to be pretty safe, so that it isn't overly scary to run code from $RANDOM_PLACE on your desktop. (There are a couple of loopholes still before I'm ready to call it "sandboxed", and those will be worked on in the next development cycle and should be part of the 4.5 release.) This means that there isn't access to network access, file dialogs, reading or writing files, etc. by default. This also rather limits what is possible. While a lot of the possible annoyances are alleviated by using a DataEngine, they don't cover all the bases. So starting in 4.4 you can put things like this in your metadata.desktop file:

X-Plasma-RequiredExtensions=FileDialog,http
X-Plasma-OptionalExtensions=LaunchApp

The entries case insensitive, and if security says "yes" then the extensions are activated and the API available to that instance of the widget grows accordingly. This also allows us to quite easily know which Plasmoids will be doing things like, well, opening files or launching applications. You can read about these extensions in the aptly named Extensions section of the API documentation or by looking at the http and fileOperations examples in the kdeexamples module.

In 4.5, we'll be offering additional capabilities including writing to files. There will likely be two levels to that: one that restricts a Plasmoid to writing to files in its own package and a more "full powered" one. The control over which extensions are allowed or not allowed will also be seeing some improvements in 4.5. DataEngines will also be getting tagged for security as right now DataEngine usage is wide open for all widgets and some of the DataEngines have gotten pretty powerful. Speaking of DataEngines, in 4.5 this same extension system is also available to DataEngines and search plugin Runners written in JavaScript.

WebKit Plasmoids Improve

Thanks to work done by Petri Damstén on the WebKit Plasmoid ScriptEngine, you can now do a lot more with the HTML and JavaScript derived widgets. Besides the things that QtWebKit provides, access to DataEngines and configuration values reading and writing are also available. Petri also knocked out some annoying bugs with the WebKit ScriptEngine along the way.

This resulted in people actually writing WebKit based Plasmoids which led to a feature request for Web Inspector support. QtWebKit made that insanely simple: a one line patch and the results are:



There is more to do with the WebKit ScriptEngine, but it's already pretty nice for the 4.4 release of the KDE Software Compilation. One of the biggest things lacking is documentation. We have two examples in kdeexamples now (the above screenshot is from one of them) and there is an introductory article on Techbase, but it's really embryonic still.

Read More

key quest: device spectrum

The idea of a "device spectrum" is a bit easier of a topic compared to the "deployability" one I covered in the last blog entry. It's really more of a concept and a possible way of thinking about things than a set of concrete technological challenges/opportunities KDE faces.

Here's how I've been explaining it to people in person: one of the innovations the Linux kernel brought into the mainstream during its evolution was the idea of viewing the idea of "a computer" as a generic concept made up of a set of very different kinds of devices. On the one hand you have tiny little (by today's standards, anyways :) system-on-chip devices and on the extreme other hand you have high performance computing (both of the single system image and cluster variety). In between lies everything else: desktops, laptops, workstations, server appliances, business servers of various sizes. Instead of providing a different operating system for each of these targets, Linux aimed to provide one, reconfigurable collection of source code that would just as handily power your wrist watch is it would the world's most powerful super computers. Instead of building walls between kinds of systems and targeting each in a separate-silo type project, Linux took it all on. This opened my eyes (and I assume many others) to the idea of computing as a spectrum, from small to large, in which software can scale from one end to the other successfully.

Yes, there are niches at both extreme ends of the spectrum where specialized software is the best fit. You won't be getting the Linux kernel on an Arduino any time soon, right? :) Being able to cover 9x% of the computing spectrum is enough, however.

While systems software has been doing this like it was nothing special anymore for a while, we in user interface land haven't been. There have been some brave and visionary types out there, like the people behind Qt, who have realized that large portions of the GUI frameworks can travel from device to the largest of workstations. I still get all giddy thinking about how Qt apps run just swell on, say, a Symbian phone and that it's the same Qt that powers electronic design apps that do real time simulations of data sets so large that you have to run them on 64bit systems to have enough memory address space. Amazing!

The challenge here for KDE is: what do we have that can also be spread out across the spectrum?

Not everything will move very much. I don't see Digikam making the leap to smart phones, for instance, nor should it try to in my opinion. That's not the point of Digikam, and trying to do so would probably ruin it.

Other applications will travel very well across parts of the spectrum. Take Gwenview for instance. (Hm... what's with my KDE Graphics obsession today? :) It has a user interface that scales down very nicely to netbooks/smartbooks and up very well to very large displays. Will it be an answer for image viewing on, say, smartphones? I don't know. (I haven't tried it, and haven't really given it much though, to be honest :) Perhaps it won't, and that's OK, of course. Knowing, however, that it's appropriate for that area of the device spectrum might be useful for its developers: perhaps they want to push the boundaries out further, or maybe they just want to preserve their current stance and ensure they don't shrink it accidentally by making it uncomfortable for use on netbook sized screens.

Some of our applications have been written from the ground up to fill as much of the device spectrum as possible. We can see this in how Plasma applications are running not just on desktops and laptops, but also netbooks (with a different primary UI, but the same special sauce under the hood) as well as phones (again, with a different primary UI).

Then there are our libraries: which work across the device spectrum? Which don't? Which could do better? Which library facilities are we missing that would be good to have to expand our device spectrum reach, in both directions?

I thought it was interesting when Akonadi people blogged about how Akonadi wasn't really designed for or necessarily ready for things like smartphones right now. That's important and useful information to have, both for those working on Akonadi as well as those who might use it in their own applications.

What I'm suggesting by all of this is that we may want to keep our eyes and minds open as we are developing our software. Instead of just assuming that we're working on "desktop software", consider that it lives in a larger world where there is a spectrum across which devices of various sizes and shapes and purposes live. Consciously placing our software, and our software's targets, on that spectrum will help us create a coherent set of solutions (and information about them) across the wide range of computers people have today in their pockets, backpacks, briefcases, server rooms and on their desks. And that can't hurt. :)

Read More