Building Converging UIs

I just blogged about my article on linux.com about the just-released KDE Frameworks 5 sneak preview.

Convergence in 2010: Plasma Netbook

Converging Form Factors

On the Frameworks, one can soon expect to see releases of KDE's Plasma Workspaces. A Technology Preview of Plasma 2 has already been released and this ambitious project has not lost any of its goals. Today, I noted that ZDNet's Steven J. Vaughan-Nichols wrote about what he expects from Ubuntu in 2014. There, he quotes Jono Bacon talking about formfactor convergence. And the intarwebs are full of people making jokes that Microsoft is copying Ubuntu with their single UI for multiple devices. But let's not forget where they got their ideas...

What is real ambition?

I would argue that neither Apple, Microsoft, GNOME, nor Ubuntu/Canonical are even half as ambitious as the KDE Community in the area of convergence. They are all merely catching up to the state of KDE technology in 2010. In that year, the KDE community released Plasma Netbook, a plasma-based shell optimized for another form factor: the netbook. With far more advanced convergence than anybody today has yet shown: Plasma Netbook and Plasma Desktop share well over 90% of their code, as opposed to not even sharing toolkit or display shell (Ubuntu) and having a completely separate desktop (Apple). On Plasma, widgets can dynamically adjust to the constraints of their environment, be it on a panel, free-form on the desktop, full-screen, in a window or in a tiled environment. And yes, the different form-factor optimized shells be switched on-the-fly. No separate login or account, no loss of functionality, no separate applications for each shell, nothing like that. It just works. See this blog from 2011 to get an idea how the tablet plans were doing.

Plasma on desktop/netbook/phone in 2011.

I understand what Microsoft is doing - trying to build a single user interface for vastly different devices. And I guess we've all seen how it does not work - Apple is smarter, in that regard. Underlying technology can of course be re-used but you simply can not make a UI which works equally well on a 75 DPI 24" screen with mouse & keyboard, on a 455 dpi touch phone, on a 300 DPI touch tablet and a 64" television with Kinect or something like that...

Instead, the Plasma team has build a technology which separates presentation from logic, allowing you to build UI's which adapt dynamically to the needs of the form factor.

Below is a video of Plasma's awareness of the container size in action, like it has functioned since it was released in 2008.


Now I don't deny that in terms of resources, MS and Apple are so far ahead they can make pigs fly. Our more advanced architecture and ideas can't really compete with what they do and as long as we have 0.5% market share on the desktop, Free Software will probably not get the resources it needs to polish things to the same degree. That's a bit frustrating but it doesn't mean we frequently do things far beyond what the big boys do: anybody who has seen the introduction of the upcoming release of Mac OS X and knew about KDE Connect knows we're way ahead of them when it comes to phone-desktop integration ;-)

Moving Forward

All this technology will be brought to a new level with the release of Plasma 5, where your workspace will be able to smoothly morph into a different form factor without even a hickup. So, when it comes to the convergence of formfactors, KDE is lightyears ahead of what the competition is even aiming for. And outside of that, we're doing awesome stuff, for sure.

Did I say something about the power of innovating in the open? That's what I'm talking about.

Basic Usability Testing at Home - notes from the workshop at Akademy 2013

In the weeks before Akademy 2013 I convinced KDE Usability Guru Björn Balazs (from User Prompt) to lend his experience to a usability workshop I wanted to organize at the conference. The goal was to teach developers how to do 'basic usability testing at home' by guiding users through their application and watching the process. To help developers who didn't make it (and those who did but can use a reminder) I hereby share a description of the process and some tips and notes.

User Application Testing

The goal of this exercise is to get input from a user about the applications being tested. The test works by putting the user in front of the application, giving them a task and letting them execute it, guided by the developer asking questions.

Process

The process works as follows: The user is put in front of the opening screen of the application/tool. The developer or usability expert guiding the process gives them a goal, something like 'play a song from Cold Play' or 'connect to the wireless network'. You can use this nice guide by the Canonical usability team on picking tasks for the users to execute.

Then the following protocol is executed by the person guiding the process, asking the user:

1. What is your first impression?
2. What do you think you can do here?
3. What would you do to reach your goal?
4. What do you expect to happen when you do it?
5. Please do it... (let user execute action)
6. Did it do what you expected?
7. if not: was it better or worse?
8. If task is not completed yet, go back to 1 

Important:

• Make clear that the user is ONLY to execute a SINGLE action in step 5. This means that most of the time, you are checking the expectations and ideas of the user instead of watching him/her clicking around.
• As guide you're not supposed to give any hints as to what button the user should click or what he/she should do, other than perhaps remind him/her of the end goal he/she has been given
• Despite the above point, there is of course no reason to let the user helplessly waste his/her time. If the user get stuck, help them to get unstuck. 
• Try to closely stick to the protocol, not skipping questions. Of course, if a user has already answered question two in his answer on question one, there is no need to ask that question again...

If the task is finished, asked what the user thought of it all, discuss improvements etc.



Note that this kind of testing is very good to find grave issues in applications; it is not very good at fine tuning the interaction with your application. You also have to be a bit wary of the feedback from a single user: repeat the process at least once with somebody else to make sure that what is an issue for one person is really a problem. Ideally, run the test a few times with various people to increase the reliability of the feedback.

Extra tip: it is very valuable to record the sessions. Often you see things later on that you were not aware off during the session..

Results

In practice, it can be a bit hard to stay disciplined, not giving hints or telling the user what to do... And to stick to the protocol instead of just quickly letting the user click to the end. Try to keep to the structure anyway, it works best.

This process works incredibly well at showing which things are unexpectedly non-obvious for users. For your enjoyment, here is a youtube video of the Network Manager session with myself as subject:
Part 1:

Part 2:


I think the results speak for themselves and you can probably imagine the frustration on the side of the developers.

I've put the notes of the workshop also on the wiki.

Thanks to User Prompt for supporting the travel and support of Björn and Heiko Tietze as they were running the actual workshop, I was just there as participant ;-)

using software.opensuse.org

A Frequently-Asked-Question: should I grab packages from software.o.o and should I add the repositories offered by One Click Install? Read on for an explanation of what is going on with One-Click-Install and what is wise.

software.opensuse.org in action

What does it all mean?

A basic explanation of repositories, packages and software.openSUSE.org.

On Linux, Software usually comes from a central location: your distribution. Apple used this model for its appstore, so did Google with the playstore - they are the same thing, expect that there is a payment system included. Every piece of software comes in a package (.rpm on openSUSE, .apk on Android). Like with Android app stores, there are various locations where you can get 'additional software'. As we all know, Apple prefers to keep you in your golden cage, no additional legal application stores for you there.

Thanks to the unique Open Build Service, openSUSE has also been offering a central place to get additional software outside the distribution: software.opensuse.org. This web based application store allows you to search not only in the official, released openSUSE packages but also offers access to the numerous (200K+) packages on build.opensuse.org. These are build as part of the process of developing openSUSE (in the 'devel projects', often offering newer versions of official software) or by private users for their own purposes (in their 'home projects', offering newer versions, obscure packages or special builds).

OBS is not all about obscure or updated software: some software is build by software vendors or otherwise 'officially blessed'; other things are there because they are too big for openSUSE Factory (games for example) or require very frequent updates (some software development tools and libraries).

The web interface works with openSUSE's One Click Install, a tool which makes it easy to install packages while adding the originating devel- or home projects to your software sources ('repositories').

Software vendors integrate OBS for official packages

When your openSUSE checks for updates to your packages, it will not only look in the official openSUSE sources, but also go over these additional repositories added when you installed extra software, making sure you have the latest security, feature and stability updates.

Adding repositories or not?

So, should you use software.opensuse.org and should you add the repositories which One Click Install will offer you? Installing software from software.opensuse.org should be fine as long as you follow the rules below.

• Add the repo. Yes, you should. Your package gets updated/fixed, giving you security and stability improvements and preventing future system updates from getting stuck on a single obsolete package.
• Make sure you pick repos for your specific openSUSE version. Don't mix repo's of Factory with 12.2 and 12.3 or such...
• Pick 'devel projects' over home repos, devel projects are maintained by a group of people and thus safer from a stability and security point of view. Home projects start with 'home:'.
• When upgrading to a new openSUSE, make sure all repos are modified for the new version or remove those which are not available (yet). Use the Apper or YaST repository management tool for this.
• Don't use zypper dup after adding repositories unless you keep a very close eye on what is changing repositories and know what it means. Zypper up should service you fine (tools like Apper and YaST are safe by default).

The biggest potential issue with additional repositories is that besides the package(s) you wanted, they might contain more. And a 'zypper dup', in which zypper will pick the newest updates no matter the repository they're from, can thus break things. That chance is relatively small with special-purpose software sources like the games repository. But in some home projects a wide variety of things is build. The Devel projects for KDE and GNOME are a interesting case: you can indeed grab ONE updated application from there, but usually, it is wise to make it an either/or deal: grab them all or none of them. You can grab them all by doing a 'zypper dup --from REPOSITORY' on the command line and the YaST UI similarly allows you to switch packages to a specific repository.

What and how to pick on software.o.o

In the image above, you see the choices presented after clicking 'show other versions' and then 'show unstable packages'. Unstable, here, refers of course to anything not available as official update. Here, the official update is as new as anything and unless you want a testing version (2.7.9XXX) you should stick with it. But IF there were other options, this are the options:

• KDE:Distro:Factory - Factory is where we develop openSUSE. The packages are often available for older openSUSE releases, but be careful, Factory is usually not very stable!
• KDE:Release:410 - the KDE team maintains repositories with KDE releases. You can pick one of these and be sure to have quite stable, yet up to date software.
• KDE:Unstable:Playground - guess... No, it is not very stable, as a matter of fact, this is a checkout directly from the source repositories at KDE - no guarantees, applications might not even start up.
• KDE:UpdatedApps - this is a repository with updated applications. It is by far the best, safest choice.
• devel:ARM:AArch64:12.3 - this is where the openSUSE ARM team develops their software. Only interesting if you run ARM hardware!
• home:XX - these are home projects from individual users. If they are your only choice you should proceed with caution. Note that SOME home projects have tens of thousands of users and are very reliable - it just isn't visible from software.o.o (something we should indeed fix, help is welcome).

Zypper power

In dealing with multiple repositories, there are a few more advanced things you can do to keep things from breaking.

• locking - if a package tends to break often and you want to keep total control over what happens to it, you can lock it. Commandline: "zypper addlock PACKAGENAME"
• repository priorities - you can set priorities on repositories. "zypper dup" will always prefer packages from the highest priority (lowest number). Commandline: "zypper mr -p PRIORITY REPOSITORY"
• zypper help - learn more on any command from zypper by typing "zypper help COMMAND"

You can find more information, as well as some more tips, in this article on news.opensuse.org.

Klyde coolness update

I've heard Will Stephenson, Klaas Freitag and Frank Karlitschek talk about a lighter and/or easier KDE based desktop forever. And while I shared the ambition, implementing it is always easier said than done.

So when Will asked me to join his Klyde Hackweek project, I thought - awesomeness, let's try and finally move something forward! And that happened, we had lots of fun and I learned some real packaging tricks. I'll bore you with epic details at a later time ;-)

We realize the idea of Klyde and what we aim to do is a tad vague so Will and I had a long chat yesterday and came up with some more details about our focus.

1. Modular for everybody

The first goal is to make everything more modular. The openSUSE KDE team did a huge effor here, simplifying dependencies so you can have a Plasma Desktop without most applets, Activities, Nepomuk or Akonadi. Of course, that means you give up on good and useful functionality but reality is that we don't always need everything. This way the functionality is optional and this will hopefully become the default packaging state for openSUSE. What you don't use will not add menu items, widgets and memory usage to your system.

By default, a 'Klyde' desktop comes with none of the above-mentioned things and only a minimum of applications and applets. But upon installation of Activities the widget will be added to your panel and Akonadi will fire up the first time you start up KMail or Akregator!

2. Low footprint if you want

We know that 'lightweight' is not easy to define and it is hard to do scientific measurements of memory usage and all that.

Currently, the Klyde settings have some obvious things (disabling animations, disabling some services etcetera) and lots of temporary choices (plastique as widget style for example). We WANT to make informed choices here and input from developers on what is faster (even if that means loosing some functionality or eyecandy) is very much welcome. And we realize work will be needed: we would greatly welcome help creating a fast and efficient widget style, for example.

3. Simple by default

systemsettings simplified.

Systemsettings exposes about 80 different modules to the user. Some of these you'll (almost) never use. And many which, from an user point of view, belong in one place (like theming) are split over several categories due to technical implementation details. It is noticeable that this was designed from the technology up, not from the user requirements down. I spend a big part of my hackweek figuring out how these categories are populated and the modules are shown, then creating an alternative tree with only about 35 modules. Will made a patch to allow systemsettings to either show the basic or the full set of KCM's.

This is an example of what we mean by simple, although we're not done yet. Ideally, these and other improvements will go upstream and we intend to put work into that.

Note that this simplification, in no way, can be scientific. Of course 30 KCM modules is more 'simple' than 80 but it is very much a matter of taste to decide which ones need to be there and which ones don't. That's why we want to put effort in having our cake and eating it too: creating a proper theming KCM might allow us to get rid of a whole raft of theming-related KCM's, for example. Yup, we're still KDE people... But in other places, we are willing to make hard choices based on common sense, research and simply our taste. Unless a designer can convince us he/she Is Right™ we reserve the right to make bad decisions.

Feedback?

We're open for feedback and would love to hear input. Please remember that we're trying to get stuff done so if you have input, put in the effort to make it useful. Have mockups, refer to what others do or scientific facts. Remember that we are not trying to create a desktop for experienced computer users and tinkerers: they can easily morph the normal Plasma Desktop into what they want. It's what I do myself, its what the vast majority of people who read this do.

Instead we aim for a wide cross-section of people who don't want to put in the cognitive effort to understand abstract stuff like virtual desktops or activities. If you understand and use these things to be more productive (which I do myself, by the way), you're not our target audience.

If you want to help out, join the #opensuse-kde channel on freenode and check out our trello board.

Enough talk

Enough talk? Wanna try it? Yeah, it ain't perfect yet, but I've created an initial Studio image and published it in the Gallery. It can be installed, if you insist, but this is a beginning of a work in progress: it will eat babies whenever it can.

Click to go to SUSE Studio for the testing appliance.

About packages and a repo, this isn't easy as you would either have to remove packages by hand or start with a very basic system with only X for this to work. We're looking for a solution there ;-)

EDIT: User and root password for the appliance are the SUSE Studio default 'linux'.

Have fun with it ;-)

Klyde in a VM.

Libre goodies in LO 3.5

A little under a year ago I wrote a happy post about LibreOffice. The team back then showed a strong focus on cleaning up and re-architecturing LibreOffice to make it ready for the future.

Much work

SUSE's Michael Meeks recently made the awesome graph on the right about the stuff being cleaned up from LibreOffice - besides removing a large amount of unused code there has been translating of comments and much other stuff. As I wrote in my previous post: that was (and still is) much needed. Without a lean and mean code base you can't get and keep contributors and making changes takes forever. As say the 3-months GSOC project needed to just get a multi-line edit in Calc shows... And getting contributors is a major goal of LibreOffice - with over 200 new people commiting code, they're quite good at it!

I've had plenty of complaints during the 3.4 series. Stability has been a serious issue. But I do realize that re-factoring and cleaning up takes time and often causes (temporary) issues so I can live with that. And as Meeks said in the announcement of LibreOffice 3.5, we can "now benefit from a substantially cleaner, leaner and more feature rich LibreOffice 3.5.". So I went and downloaded ~600 MB of Free/Libre goodness which is now packaged for openSUSE...

Features

In part thanks to the substantially cleaned code base a number of big improvements can be found in this release. The coolest is imho the grammar check - I know grammar is hard to test but the grammar check has been tuned to have almost zero false positives so if and when it tells you something is wrong, it'll be wrong. The improvements in typography are very noticable as well, fonts look much nicer. And I greatly appreciate the new header/footer interface. Finally, there is the real time word count - I used to use Calligra Words for this feature and its nice to see LO getting it too. Yes, I mostly use writer - can you tell?

But there are plenty of other improvements in the other apps too, including the multi-line input area in Calc so LO 3.5 is certainly a worthy upgrade. I did find a bug, which I have reported ;-)

Speaking off...

On the note of Words - Calligra is on the verge of releasing Calligra 2.4 and I must say that's another FOSS Office release I greatly look forward to, if only due to its about 10 times smaller footprint on my too-tiny SSD ;-)

That release will be even more packed with goodies but then again, it's taken the team about a year to finish it. I especially look forward to Krita, which is now ready for professional artists and from what I've seen of the beta's and RC's it'll be something good enough to make artists move over to Linux. And I'd recommend openSUSE as you can hear Krita lead developer Boud frequently complain that he'd have an easier time supporting users with issues if they'd all just run openSUSE which works flawlessly with tablets.

Getting it

Muktware wrote an article on how to install LO 3.5 in openSUSE but I wasn't particularly looking forward to downloading and installing RPM files by hand so I've waited until a more convenient installation method was available. It is now, just click the link below, give your password and it'll get installed. This works for openSUSE 12.1, openSUSE Tumbleweed users get the upgrade automatically once it is deemed stable enough - the spoils of a Rolling Release... Awesomeness :D

click here for a convenient one-click-installation of LibreOffice 3.5.2 from the LibreOffice-Unstable branch in openSUSE


On an entirely different note, my google plus stream is full of complaints and praise about GNOME Shell which I'm using on my laptop this week (during travel to Nurnberg and Prague). Certainly an interesting experience.

criticism towards GNOME Shell

Reading all the controversy around the decision by the GNOME Shell designers to remove the minimize and maximize buttons from GNOME shell reminds me quite a bit of the discussions around Plasma. Especially for stuff like the brilliant yet controversial Folderview widget.

criticism

It also makes me wonder if those complaining have ever tried GNOME Shell... As is adequately explained in this rationale, minimizing simply has no place in the concepts behind GNOME Shell. Period. And if you've tried GNOME Shell you would realize that.

GNOME Shell in openSUSE 11.4

Yes, Shell takes getting used to, it does enforce certain habits. If you want to customize your environment for maximum 'getting-work-done' then maybe GNOME Shell is (currently) not for you. But that's the crowd KDE has always appeased to anyway. There is after all a trade-off between efficiency and ease of use (or rather, discoverability) - it is why most seasoned sysadmins use a command line.

Newbies!

But the power of GNOME Shell lies somewhere else. Put a newbie in front of it. Observe - in 5 minutes they've figured out how to use it, really. It is very simple and intuitive. I find that very impressive. Especially on a touch screen, it all makes a lot of sense. And it also works on very small screens. And yes, you'll see, the minimize button DOES NOT make sense in GNOME Shell. Really.

If you want to criticize GNOME Shell, talk about technology. I would've advocated to not build a new tech platform but build Shell on something like Plasma which is designed to make interfaces like GNOME Shell, or do like Ubuntu did with Unity 2D). But I kind'a get why they didn't, it's software 'from the other camp'. A more harmful thing is that they didn't get involved with the fd.o systray/notification rework done by KDE and Ubuntu, I see it as a big miss for GNOME Shell, and I'll consider it narrow-minded until I see or hear a good rationale somewhere ;-)

Plasma 4.6 and KDE Apps in openSUSE 11.4

But don't balk at the design until you've tried it with your grandmother... And in the end, Shell is innovative and new and will need maturing. I always have a soft spot for innovative and new things, it's why I like Plasma despite the issues it still has. So I do look forward to the final release of GNOME 3 and I'm happy that we (openSUSE/Novell) decided to press GNOME 3/Shell LiveDVDs as soon as the release of GNOME 3 is out. Yes, we'll also make KDE ones, 4.6 on openSUSE 11.4 really rocks and deserves it ;-)

picture viewers/editors

Hi all!

Scanned an A4 using my HP all-in-one. It doesn't print (days of struggeling) but the first time I choose 'scan image' from KWord it worked all fine. Life's like that, I suppose. And I primarily bought it for the printing. Blegh.

Anyway, that's not the topic. The scanned image is, in a way. I scanned with defaults, so that's 600 DPI - resulting in a rather large 7000x5000 something pixels. Enthousiastically I opened it in Gwenview, which took at least 5 seconds to start, then freezed another 15 sec to open the file. And the file looked horrible - while the original was perfectly readable, on screen, resized to fit, it was almost impossible to read!

So I fired up showfoto. Which opened right away, showing a progress bar loading the file. And it looked great, while zooming works much smoother!



But it's not very nice to browse through pictures, like Gwenview, which is very easy to use and has all these nifty features... So I'm wondering... How about putting the thumbnail stuff, the image loading & zooming all in a lib or something and sharing it? Cuz really, showfoto and Gwenview share so much functionality and purpose yet it seems less code than they should ;-)

Yes, I'm not closely involved with either teams and I know it's easy to call for such things from the sideline. But I know both apps are actively developed, both are innovative and not afraid to experiment (I actually use both digikam and gwenview together with dolphin, showing their unique variations on the dolphin file selection mechanisms, during my presentations about KDE and innovation). Come on guys, make me even more proud of you!

GCDS over

It's over. Sitting here in the lobby of my hotel, contemplating a swim. Still a bit tired of all the writing and running around, but generally satisfied with the whole thing.

I've been playing catch up to my backlog of email and blogs. Almost done. Now on to some more writing and wrestling through the businesscards and other stuff.

(ok that was 2 days ago - forgot to finish and publish the blog. So I'll just continue)

This time I'm in my hotel room. Just had Japanese food with Kenny - interesting, as usual. Yesterday we took a car and drove through the center of the island, stopping a few times to admire the view. We also climbed some big rock to the highest point of the island. That was fun (and I got a bit sunburned). Kenny was less lucky, aside from the sunburn his cold got worse and his left ear has issues with the differences in air pressure. I hope for him it gets better before he boards the plane...


The rock from a distance


Rock a lot closer :D

None of my pics actually gives a reasonable impression of the actual size of that thing (hint: in the previous pic, you wouldn't be able to see a human standing next to it...) but I do have a photo showing the view standing at the feet of the rock:





Spot kenny ;-)

I'm working on some more geeky blog stuff, but that'll have to wait a bit - I think I deserved some relaxation after all the running around I did last week.

BTW you might have noticed that Troy is back working on promo stuff - first articles are online already, and more is on the way.

another more geeky thing, I agree with Richard: Moblin "We don't have menus, we think they're useless" 2 is seriously awesome! Great performance and a very interesting take on small-screen interfaces. Seems very usable. The more technical among you might say Intel would've done it faster and cheaper by choosing 'the right technology' (probably starting with a Q or a K) but the enduser in me thinks "bullocks: I couldn't care less, it works great!". That doesn't mean I don't like the stuff notmart and the others are doing, btw ;-) I do think they should probably have a very good look at Moblin.

usability in KDE

I'm not a usability dude, and following the usability mailinglist has taught me it's an art I shouldn't get too involved in. Unfortunately, while we have a few hard-working usability experts in KDE, they can't thoroughly check each and every application.

Luckily, we have users joining KDE from a platform known for a strong focus on usability. I'm not saying we should copy the approach others have chosen for usability. KDE is different and has different ideas about usability - enough has been said about that. However, advice never hurts - and there are several points in this blogpost that make sense. The contents have been discussed a bit on the usability mailinglist, and as I said - several points make sense, others might not. Yet Sebastian's blog might be helpful for somebody who wants to improve some obvious areas in KDE in terms of usability, so I thought it'd be good if ppl read it.

Personally I think such articles (I can hardly call it the usual blog) can help in improving KDE, as they point to issues and solutions developers might not have been aware off. Peter Penz (of Dolphin fame) has read it and implemented at least one suggestion, while several others were already done in KDE 4.3 branch. Who's next?

Who did this?

Here another "KDE4 is really usable" blog. Well, I just want to point that out up front. Oh, and my day was different from Wade's. Yesterday I gave a talk to dutch students about KDE 4, I didn't get machette's to my head. Aaah well, everyone's different.

The real topic is something else, though - I wanna know who did the following:


That person deserves some kudos. I haven't seen any blogs or whatever about it, but I think it's a great job. Solid Usability Work the KDE Way (tm): make it easier to use and more powerful at the same time. Yes, it's a bit harder, but much more rewarding to not take the easy route of 'dumbing down'. Nice work... Of course, there is more to do, maybe the person who did this can spare some time on the 'edit toolbars' dialog as well.... Currently drag'n'drop is broken ;-)

Another thing which I wanted to mention: Cornelius said he was amazed by the speed of KDE 4 apps. Now I took that with a grain of salt, as I hadn't seen any amazing speed yet - Okular was slow, I had seen konqi using 100% cpu and still stutter on scrolling, KWin didn't exactly go smooth... But while making the above screenshots I used kwrite, and indeed - kwrite4 starts faster (feels at least twice as fast) as kwrite3 (both in my kde3 session)! And other apps do the same. Gwenview is like 10 times faster, and konqi4 seems faster without pre-loading than konqi3 with! Konsole seems a tiny bit slower, though.

Sure, you don't want kbuildsycoca4 to run first, but after that's done - applications are wonderfully fast. It's like someone turned 'speed' on in Trunk, somewhere in the last week... Whoever did that, nice work!

Now, the last thing: colors. I've just been trying the colorscheme things, and they work great - see the following screenshots (yes, the second one, called Beos(?), gives the higher contrast many ppl seem to want from Oxygen).





The oxygen style also does a pretty nice job on darker colorschemes (unlike most KDE3 styles):

picture viewers & widgets

While writing stuff about KDE, you have to make screenshots. And often modify them basically (resizing, converting, stuff like that). So I get to play with some image viewers like Gwenview and showFoto and with image editors like KolourPaint & Krita. Kolourpaint and Krita are rather complementary. Kolourpaint, after all, is basic, quick and easy to use while Krita can do the heavy lifting. Gwenview and showFoto, do have more overlap, but Gwenview is faster, smaller and does the basics, showFoto is more featureful. Now I know there are more imageviewers in KDE (kview, kuickshow, and some third party things like squirelsomething) but I'm glad I don't have them installed - I'd rather see showfoto as fast as Gwenview, and I'd ditch Gwennie (or the other way around). Now Gwenview gets some love for KDE 4, and as far as I can tell, it's going to be the default imageviewer. Maybe. Why maybe? Well, I'm unsure - it seems Okular also wants to be an image viewer, right? On one hand - cool - annotation. But I'd rather then see the annotation stuff shared between KDE apps with Nepomuk or Strigi or something...

Now on to something more positive. Someone started a discussion on the kde usability mailinglist. It's rather long, but I became interested when the pretty pictures came. Someone pointed to this problem:







I found a solution which is already used in KOffice:




It looks pretty good, but there where some comments - discoverability isn't great. A right mouseclick is needed to be able to enter text, and it isn't obvious that it is possible at all. Plus, the guys wanted a drop-down. So Hans Chen made a mockup:



I'd say, with a editable combobox instead of a 'hidden' one on hovering (see top right mockup), it's great and should be the default zoom thing in KDE 4... ;-)