go with the flow

A new feature release of the KDE Software Compilation has been made, bringing us to version 4.4.0. What a development cycle it has been! I won't bother recapping all the progress made, as you can read all about it in the above links.

With Tokamak 4 coming up in just ten days and the new KDE website up on its feet but still getting lots of love, attention and work done on it, it is certainly a busy time for us all.

Things are not going to slow down one bit, though. :)

There are the predictable events, such as "we will be working on the first 4.4 patch level release as well as features and improvements for 4.5 which will appear this summer". There are also the to-be-expected happenings, such as the odd kerfuffle about this or that (today's one was about KAuth and what it means for Linux distributions such as Slackware). There's more afoot this week than just the usual suspects, though ..

For instance, today I'm working on tagging a first alpha release of Plasmate, the Plasma add-on creation tool, as part of an effort to move Plasmate to a regular release cycle with the ultimate aim of it being in fighting form for 4.5.

I'm also hearing rumblings of at least one very cool KDE event coming up in April that I'll be keeping my eyes on. It's exciting to see the number of quality KDE events growing around the world!

The most exciting thing for me today, however, is an announcement I'm working on that will be going out at the end of this week on February 12th. What is it about? We'll have to wait for Friday to find out for sure, but I do have something related to that announcement that I'd like to share with you right now:

KDE SC 4.4 comes with vastly improved and expanded Javascript Plasmoid support, and I'd like to personally introduce them to you. I will therefore be hosting open training sessions on both Friday and Saturday at 18:00 UTC on irc.freenode.net in #plasma-training. I will demonstrate, step-by-step and with examples how to write Javascript Plasmoids from the very basics on up. All you need to do is bring your enthusiasm, a text editor, a web browser, an irc client and hopefully a KDE 4.4 install to test your creations out with. Each session will last 2 hours, including an open Q&A at the end and you will walk away having written your first Javascript Plasmoids and I will be repeating the material on each day to give you the greatest number of opportunities to catch it. I hope to see you all there!

krunner responsiveness

The RunnerManager interface in libplasma which powers KRunner (among other interfaces) was designed to allow plugins a-plenty so that one search term could be matched in "real time" by several different components, each one looking for answers in different ways or places. This isn't a particularly unique design by any means, and the concept can be seen in many search interfaces out there.

A "run command" app faces a challenge with this sort of design: in usage, one expects the interface to appear "instantly" when called up and remain responsive during use. This isn't the web where pages can take significant fractions of a second without anyone caring or where we can stack dozens/hundreds/thousands of servers behind your queries to offer mindcrushing amounts of compute power to chew through whatever gets thrown at it. No, we have to be fast with limited resources while looking in all kinds of places. Basically, KRunner has be as responsive as the KDE 3 minicli while doing orders of magnitude more processing. Interesting problem.

To address the problem we made the query plugins, or "runners", multi-threaded even when we only had 2 of them. This ended up involving lots of queue management, but Threadweaver made that as easy as possible. We got rid of many locks as development went on, improving interactivity, and eventually ended up introducing the concept of a query "session". In KRunner, a session starts when the user interface is shown and ends when it is hidden. Runners are given the opportunity to set what they need during searching up at that point. Later, when the session is over, they can tear down all of that allowing us to conserve resources and not wake up KRunner every time a window twitches. This also helped speed up querying in some cases as it meant moving initialization routines that were being run in some cases on every keystroke to once-per-session.

The prep and teardown for sessions is not multithreaded, however. Or rather, the signals that a session is about to begin and end are not. This gives runners some comforting guarantees as to their ability to manipulate pixmaps or x.org information (things that can not be safely done from outside the main application thread) as well as to the order of events: prep, querying, teardown is a guaranteed order.

The new issue that query sessions brought was that some runners have grown time consuming code that is run during session preparation. There were a handful of runners that were taking 20-80 milliseconds each every time the user interface was to be shown. That may not seem like much, but it quickly added up to over 150ms on my dual core 2Ghz laptop which is very noticeable to the human eye. Since this code was running in the main application thread, popping up the KRunner window felt really slow. The question was: which runners were responsible for this and why? Some profiling was in order!

So I popped a small three-line patch into libplasma that measured how long each runner was taking during session preparation. The problem plugins were immediately highlighted. So I went through each of those and did some profiling to see where they were spending their time and pushed code around until the prep time was more reasonable. Most of the work was taking synchronous operations and making them asynchronous. At this point, none of the runners on my system take more than 1-2 milliseconds to prep, which means instead of waiting 0.15 seconds for something to happen after I press Alt+F2, it appears almost immediately. The difference is very noticeable and very pleasing.

What's interesting is that, with one exception, none of the runners are doing any less processing. In fact, in a couple cases they are doing a little more (though nothing to write home about), but the result is something that feels much smoother and more pleasant to use.

I backported the results after testing to the KDE SC 4.4 branch. I don't think the improvements will make it into 4.4.0 (it's already tagged and being packaged) but should be in the 4.4.1 release at the latest. So if you have been finding KRunner sluggish to appear and build from sources, try updating kdebase/workspace/plasma/generic/runners/ and kdeplasma-addons/runners/ and see if things improve after a restart of KRunner.

interesting bits in 4.4.0 for plasma-*

With KDE Software Compilation v4.4.0 tagged and going through final release engineering processes, early reviews and discussions about it are appearing around the Internet. It's great to see the interest bubbling around it all.

One interesting meme is that "not much has changed". That sentiment is a sign that things are settling down nicely in KDE 4: things aren't moving around as much and there's a sense of predictability again. This is an important milestone.

However, some people are under the impression that pretty much nothing has been done except "under the hood changes". I think this highlights a challenge for our communication around SC 4.4.0: just because KDE 4 has hit an externally visible stable trajectory and the SC 4.3 -> SC 4.4 jump is smooth, that doesn't mean that there aren't lots of new and exciting things in SC 4.4.0.

Let's take the Plasma Desktop, for example. As can be seen in the 4.4 changelog for libplasa, plasma-desktop, plasma-netbook and krunner, we've been busy doing as much new stuff as refining the existing.

We have added a number of "usual suspect" type things: drag-and-drop for wallpaper plugins, ten new Plasma widgets, one new DataEngine and five new Runner search plugins. Let's not forget, though, the plasma-destop Kiosk lock down features or the brand new Plasma Desktop Scripting tool for sys admins, power users and packagers. This feature is being used in several upcoming distribution releases already and offers something KDE has never provided before. (In fact, does anybody know of any other production system that provides such a system for the desktop shell layout?)

Then there is the first release of Plasma Netbook, which is a whole new shell consisting of a little over 6,700 lines of code that isn't shared with other Plasma apps.

There is also the new mouse actions plugins that let you associate any combination of mouse and meta-key (Control, Alt, etc) on activities with actions. In KDE SC 4.4.0 there are six such plugins included: activity switcher, window list, desktop switcher, default context menu (highly configurable, btw; you can turn on/off pretty much every individual entry via the config UI), paste (e.g. to attach to middle click :) and an app launcher. Sensible defaults are provided for these, and those defaults can be overridden by an libplasma application to suit its needs. Since they are plugins (and the API is part of libplasma, so guaranteed to remain BC from SC 4.4.0 on out), it's also possible for people write new plugins of their own. You aren't limited to menus, either!

We have Plasmoids in the system tray, improved and extended animations and many other improvements. Per-virtual-desktop-activities is very smooth in SC 4.4.0 as well, and there were multi-screen fixes even.

Then there are all the nice improvements in KSysGuard and more than you can shake a stick at in KWin, so if we want to cover the KDE Workspaces we'd have to go on for quite a bit longer than this one blog entry. Then we'd have to move on to all the applications that come with a KDE Software Compilation release, many of which have individually important improvements.

It is quite true, however, that much work did go into refinements, bug fixes and infrastructural improvements. For me, the KDE SC 4.4.0 release is a very well-rounded release in this respect. It is full of new features and capabilities (without becoming a Frankenstein of configuration overhead, either!), but it is also full of good maintenance work. This is why, combined with KDE SC 4.3 being a good predecessor, some aren't noticing the new things we're delivering in this release.

Hopefully we can communicate both the feature adds as well as the refinement work effectively, because that is indeed the whole story.

n900, thoughts

I received an N900 a couple days ago and was quite excited to unpack it. It came with the usual dizzying array of wires for power, audio, etc. The instruction manual was short but useful. The box was a nice charcoal gray. Yadda yadda yadda. Those were all but details, of course: I wanted to see the thing in action!

Now, I don't intend to keep the stock UI on there for very long. This device will be traveling with me to Tokamak IV to get a make over, but I wanted to have a good feel for what it was already capable of and how things worked. I've been working on bug fixes, mostly for Plasma Desktop and scripting, for the upcoming 4.4.0 (sometimes into the wee hours of the morning) so having something to play with in between debugging sessions has been nice. What follows below are my impressions of the device to date, all which is just my personal experience and personal opinions. Don't take them as gospel or even as a proper review.

Hardware

The thing is a bit of a brick, but that seems to be the Nokia aesthetic. It's small enough to fit in my pocket and while it weighs significantly more than my LG phone it's not off-puttingly heavy.

The heavy bevel of the N800 series is gone and the screen is much more attractive as a result. Playing movies on the device is actually very enjoyable: video playback is smooth (as is pausing, seeking and audio controls) and the picture is crisp and rich in color. The various graphical transitions between applications is very smooth for a phone. P. noted early on that it is a lot nicer than the iPhone his mom has due to these things.

The camera and speakers are similarly nice. They certainly aren't going to replace a proper camera, still or video, quite yet but they are better than the ones we have in our various phones around the house here.

I still have 26.5 GB of storage available on the device and once plugged into my laptop with the included USB capable, not only does it start charging but I can mount it and start chucking media and other files onto it painlessly.

The keyboard is well done and works nicely for thumb typing. The kick stand in the back is a little too small to keep it stable on a table top while pocking at images or web pages, though.

Software: The Good Bits

Being able to multitask is a god-send. Having a phone that you can easily add software to with a nice point and click interface is tremendous. (Hello, apt-get! :) The included media player looks good and works well, even if it isn't jumping up and spinning around the room with bells and whistles. Details like having media that is playing pause when you switch to a phone call or some other similar "I'm now busy, no audio please / I can't watch something right now" context, and then have it resume when the context is left, is great.

There really are a large number of details that it gets "right". Swiping to move between widget layouts on the desktop is smooth enough and works nicely. The application task management is rather nice, such as the transitions that happen when you close an app while others are running.

Nice prompts to import contacts, and that the contact book seems to be pervasively shared by apps on the phone show nice attention to software integration. The notification bar that pops down onto the screen is noticeable without being annoying, easy to read and easy to dismiss; bonus points to whoever got that oh-so-right.

These are all great things. Up to this point, I could really feel the potential of this phone platform. Excitement flowing through my veins and all that jazz.

Software: The Flip Side Of Good

Unfortunately, there are so many warts on this otherwise amazing bit of kit that I'm not sure I'd actually recommend it to others who "just wanted a good smart phone". Why? Most of the software, well .. sucks. I'm really hoping that the updates that will be arriving before the N900 is more widely available will plug most of the holes I stumbled across, but for now the N900 simply could not replace my current S60 phone. Let's look at some of the things I ran into.

I managed to lock up the device while setting the time in the setup app that is available when the device is first turned on. The only way to set the clock is to rotate the hands using touch. That's cool, but there's also a little label that shows the time right there and it's completely non-touchable. I could live with that ... if the analog clock wasn't prone to locking up the input on the device. :/ (Insult to injury for me: no Canadian cities, regions or timezones on the device.)

The email application looks reasonable, except I can't use it because it can't authenticate against my IMAP4 server which uses the "plain" login method over TLS.

The WiFi plays well with some AP's but not others. At the coffeeshop here I can download and browse like a mofo on the thing, but here at home it's so bad I can't download software or updates for it and the web browsing is a bit of a pain.

UPDATE!: Armijn told me that Sebas told him (small worlds!) that this is a known issue and can be dealt with by turning off power management when connected to troublesome APs. The way to do this is to go into the settings app, go to internet connections, press Connections, select the problem AP, click Edit then Next, Next, Next to the end where it offers an Advanced setting button, press that, click on the Other tab, select "Off" for "Power saving", dismiss the scary warning about it taking lots more power from your battery and voila ... intarwebs come a-streamin' down the tubes that were once cloggedy. ;) Thanks Sebas (who needs to go pick up stuff at Ade's place! ;)

The GPS doesn't seem to want to pick up satellites and the included mapping software doesn't let me bookmark locations (e.g. where my home is); or if it does, it's very cleverly hidden. The download-maps-over-whatever-connection-you-have-for-the-are-you-are-viewing is a nice step up from the N810, though.

The "app store" is anemic and too often I have to try to download an app more than once because it "can't connect to the server", even when I'm connected to a "good" AP for Internet.

The idea of tracing a spiral to zoom in/out of the web browser just doesn't do it for me, and web pages don't automatically scale to anything resembling a useful size in too many cases meaning that I'm starting to actually get good at that spiral motion. Stumbling upon a website with an unsigned SSL certificate sent me through the obnoxious Firefox "obstacle course of certificate exception approval"; worst of all it is exactly the same one as on the desktop. That means it doesn't fit on the screen and all the buttons are rendered using the default themed Gtk+ widgets. Compared to the rest of the slick chrome on the device, these web browser dialogs stand out like ugly ducklings with no hope of ever becoming swans. The thumbnails for browser history navigation is really neat, though.

Then there are the Mystery Zones on the screen: when a prompt with information and confirmation buttons (essentially the Maemo version of an informational or yes/no dialog) appears there is no immediately obvious way to dismiss it. You just have to press somewhere outside of the area to cancel the action or dismiss the information. That means there is a button saying "Yes, do this!" right there, but the "Get me out of here!" isn't obvious at all. When you are in the application launcher (a grid of icons, essentially) if you press just outside one of the icons (and with a finger that's really easy to do) it also triggers this "cancel the operation" Mystery Zone and the application launcher goes away. To get to the "desktop menu" stuff (for things like internet connections or setting your theme and background) you have to know where to touch (the top of the screen) and when (when the "desktop" is visible).

Which brings us to the desktop. It's separate from the application launcher and so I'm constantly feeling like I'm dealing with two paradigms that don't like each other much. One is the desktop with widgets, the other is a smart phone interface with icon grid launchers and app stores. As P. said, "This is really complicated." Yes, son, it is. Really annoying is that while you can set the background or theme from the "desktop menu", you can't launch the device's settings app. No, that's buried two different clicks away (three if an application is running). Networking, time, bluetooth and USB connectivity, audio volume and profile setting is in yet a different hidden menu on the destop (in the status area). At least this, however, shares the look of the "desktop menu", unlike the settings application.

I could go on as well about things like how the kinetic user interface elements like the flickable list boxes really don't work overly well, or how the 'rounded corner' widgets have bits of black squares in the corners (composition failure, no doubt) but .. well .. I think I've already said enough to give you an idea of the impression I've received.

Not Just Light, But Rainbows, At The End of the Tunnel

If this was a normal device, I'd be left with mixed feelings. I'd be really enthused about some things about the N900 but totally discourage about others. I'd probably discount it as a contender for now and wait to see how the software updates go over the next few months, fingers crossed.

Thankfully, this isn't a "normal" device, relative to other devices out there on the market. The N900 is an open software platform. I can work on it and replace the bits I don't like. I can fix things and improve things to my heart's content (and time budget).

This is why I see not just some light but full-on rainbows-in-technicolor-glory at the end of the tunnel. When Qt hits this device in all its glory, there will be a very powerful stack of software that works very well on these kinds of devices that we are very familiar with and already have a ton of software built on top of. At Tokamak 4 we will have a few N900s, all of which will be sporting Plasma interfaces before we leave I'm sure, along with 4 smartphone-ish devices from Intel to give similarly loving to.

Right now, as I type these words, I am imagining this device with a beautiful Plasma powered interface. Qt applications galore, a sensible melding between apps and widgets and a more unified UI experience that not only blends with but works seamlessly with my laptop and netbook with all of that wonderful, wonderful hardware pulsing and beating beneath it, driven by what looks like a rather nice kernel and userland.

The N900 (and other such devices) are ours to make in our own image. They can be, and as a result will indeed become, more than they have been originally designed to be. This is what happens when a shared commons is allowed to blossom with Free innovation and Free market concepts.

Others will have different ideas for it, I'm sure, and it will be very exciting to see what others imagine into life on these kinds of devices. Ultimately, none of us are locked in on these devices. We don't need to be happy to plod away on individual applications that play in someone else's jailhouse lock-in system, like some slave who's "allowed" to go into town on their own on Sundays. We aren't relegated to only creating Free software that rocks on our desktops (even if that is all I've been personally doing these last couple of weeks :), we can make stuff that rocks quite freely on almost any kind of device form factor we wish.

I remember dreaming about this part of the future as a young person. It's odd, in the most wonderful way, to be smack-dab in the middle of it playing out in reality.

A Word on Closed Device Platforms

I remember when BeOS R3 was released for the Intel platform and talking to some of my friends who were great fans of it . "Linux will never gain traction next to other niche operating systems that are so much more slick than it is," one of them said, hailing BeOS as a nail in the coffin of Linux outside the server room. "No chance," I said. "Yes, BeOS is far better than the Free systems. But it is a guaranteed dead end because it is closed. That can never compete with an open ecosystem. That only works for entrenched players and monopolies." (Irony in the story: BeOS lives on today, more or less, as a Free operating system called Haiku, to which the KDE Free software stack was recently ported to.)

I've seen this played out many times while I've knocked around the industry. To maintain a closed ecosystem in the face of an open one, you have to be insanely better (mostly at lock in techniques) or have a monopoly position. Open ecosystems far too easily generate a network effect that can quickly trump funding, partnership politics and even quality.

There is no successful, closed ecosystem monopoly in the devices world yet. There is Apple (who is growing, almost entirely due to there being a vacuum to fill), there is Android (which isn't open enough to avoid the pitfalls and pratfalls of competing against truly open ecosystems), there is Windows Mobile (but that's all a lark these days) .. but nobody has claimed title of Insurmountable King of the Hill (IKotH). Any of these players can tumble down, and likely will if they stick to their closed ways. This isn't to say they can't carve out a respectable and even sustainable niche, they just won't define the market long term unless the open up.

Open stacks based on Linux, Qt and similar tools are in a much better position simply because more people and companies can participate and therefore create a larger pool of shared resources that is hard to impossible for a closed platform to match without joining in. (Let's not forget that S60 is opening up, either, and bringing Qt along with it too.) I don't know what the ultimate role Maemo itself will play in all of this, but in an open ecosystem it doesn't need to be IKotH to be successful either, anymore than any of the Linux distributions need to be IKotH in the server space for server side Linux to flourish.

The only thing that could fail us now is for too many of us to consider open device platforms to be uninteresting and "somebody else's problem". This is one big reason why I've spent a good porition of the last few years of my life working on a software stack that I feel can be transported between the various kinds of devices I'd like to use. I want to be one small part of the huge success that can be, nay, will be the open mobile space.

Over the next few hours, though, I'll be working on a folderview bug that exhibits on multi-screen desktops. :)

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! ;)

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.

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.

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 ...

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?