Mobile/UMPC stuff is on my mind today for a few reasons: Summer of Code candidates have shown up on the panel-devel mailing list proposing to work on mobile projects (huzzah!); I was contacted by two different vendors today about getting Plasma on their devices; I had that recurring dream again where I'm stuck inside an Apple Newton ... crying. ;)

I noted in the Containments blog entry yesterday that Plasma is designed to be rather flexible in it's presentation. One of the (several) reasons for this has been to allow Plasma to travel to devices that aren't laptops or desktop computers: televisions, media center devices, ultra-mobile PCs (UMPCs such as the EEE PC, Classmate, OLPC, etc) and even plain mobile devices... without requiring one to start totally from scratch.

Where are we right now with Plasma on mobile devices? Well, first the good news: it works. ;) Here is a video of Plasma running on an OpenMoko handheld from back in December of '07. Getting it compiled and on the phone was the work of Marijn Kruisselbrink.

It's pretty impressive given that it was pre-4.0 code running on a mere 266Mhz of FPU-less ARM processor with 128MB of RAM and no hardware graphics acceleration. This is anything but a powerful setup by today's standards; newer OpenMoko devices are rather more muscled and things like the OLPC (let alone the EEE PC) blow it away in terms of performance.

And that's where the not-so-good news starts: from a bare start it takes ~40s to load up. Some of that is going to be library loading, but a lot of it is going to be plasma itself. Once it's up, though, it's not too bad. So what can we do about the load time?

In the video you can see how the exact same widgets and Containments we ship as part of the KDE4 desktop workspace are being used. Code reuse and ubiquity! =) This makes the performance rather impressive given that it uses all the plugins that were built for full sized, modern machines. The wallpaper file it loads is not small, the Animator is not designed for small devices and none of the utility dialogs are designed to be used in that small of a space (or at least not those fonts). It's a sort of worst case scenario, really. The toolbox works nicely there, though. ;)

So one obvious avenue of improvement is to write a Containment that is designed for the phone, e.g. something with a lot simpler wallpaper management and skipping the desktop icon loading code entirely. By whittling away at the DefaultDesktop containment one could get to something much smaller code-wise and that executes far fewer instructions during startup.

At the very least one could provide a wallpaper that matches the screen resolution, even if you kept the DefaultDesktop containment as-is.

Mod'ing the Containment alone would probably shave most of the ~9s it took to show the desktop containment in that screencast, meaning in theory we'd be down to the low 30's. Admitedly still not great.

Since it's a phone, we could probably get rid of the traditional desktop panel as well. Or at the very least create one that doesn't render a complex SVG and load the default set of desktop-appropriate applets. The panel appeared to take another 3-4s to load, so if we dropped it entirely in favour of a single Containment (aping more traditional phone interfaces) we could erase that too.

Other tricks would include an SVG theme for the phone that was simpler (and so faster to load). We don't have an on-disk pixmap cache for Plasma::Theme either, which would allow us to skip the whole SVG-rendering-storm-on-load thing as well by providing a populated cache.

Cutting back on the number and nature of default applets would also probably help somewhat, e.g. not using the rather complex kickoff launcher UI.

These are all things that occur to me off the top of my head before we even get to the work of actually profiling and improving libplasma itself. It may even make sense to whittle away at the plasma binary itself which probably has a number of desktop appropriate things that we don't care about (like the dashboard); it's only 914 lines of code, but there's likely to be some savings even there to be had.

So there is a lot of low hanging fruit out there, and most of it doesn't even involved touching core plasma code at all but rather coming up with device appropriate plugins and artwork. One exception would be the SVG pixmap cache, which would likely be done using KPixmapCache and involve touching the Plasma::Svg::Private::findInCache method.

Making things potentially even a bit easier: Sebastian Sauer commited a small patch (around a dozen lines or so) that makes it possible to load scripted Containments. So my "in theory scriptec Containments are possible, but probably needs a bit of patching to work" comment from yesterday is now ancient history. ;) This would allow one to implement things like new Containments in ECMA Script, which would be run using the built-in QScript interpreter. While obviously not as fast as C++ virtually all the execution time would be in the C++ libraries, and you could edit the code right on the phone (so no need to cross-compile, etc). Bonus points for not worry about crashes while working on these things. Given that the Tiger script example is four lines of ECMA Script, one could imaging a ECMA Script containment being about that size as well ... even with the desktop toolbox retained. We're talking about some serious development time savings here.

With the webkit ScriptEngine, one could even use HTML+JavaScript to render various screen presentations on the phone ... hmm.. haven't I heard about something like that somewhere already? ;)

So I'm happy to see that our work thus far translates to even rather modest (by today's standards) systems with acceptable results: For one, it works, even with no tweaking to the default desktop targeted plugin suite it works albeit with rough edges. I can only imagine what it will be like once we get some more people actively working on optimizing plasma for these kinds of devices, and I really hope we get at least one of the plasma-on-mobile SoC projects going =)

Just to clarify some stuff that seemed to cause a fair amount of (predictable) drama in the previous post:

• No, I wasn’t referring specifically to dirk’s blog. There was parts I disagreed with in his post which we have since talked about on IRC but I think he made some good and needed points also. Dirk’s blog was one in which I felt the tone wasn’t great but was did not provoke the post I made, it reminded me of a selection of far less friendly earlier interaction on the Planet since KDE 4.0.0 was released. May I issue a formal and public apology to dirk for the confusion.
• I’m overly touchy about this topic because I’ve seen a major FOSS project that I care about go down the toilet mostly due to (in my observation) snarky blog posts causing a lot of developers to leave.
• I think criticism is necessary and valuable I just think we can all improve our interactions with others; I know I can. I think we should set the bar high on how we seek to treat others online and how we communicate.
• Whilst I agree that it is good that people care enough about the project to get riled up and flame others I don’t think that this is a good outcome, however positive the reasoning behind them may be.

In summary, much was assumed about my post that wasn’t actually my intention and I should have communicated it better. I am intentionally vague about points when I don’t want to criticise individuals but instead general behaviour. If one tiny bit of KDE works a bit better as a result or one relationship within the project is strengthened then I think it has been worth it.

Stay happy folks and apologies again for any offence caused.

A lesson I’ve learned from the KDE4 HIG is that it is too large of a project for 2 busy people to work on (before you all go off on the HIG, we (Ellen and I) plan on getting 1, possibly 2 OpenUsability Season of Usability interns to work on it this summer). The HIG was a hard project because it required contributors who had experience in styleguides, experience in design, and experience analyzing and making decisions for ambiguous guidelines. When there are only a handful of people who meet that criteria and other things come up, the project becomes very volatile and ends up slowing to a halt.

In all its glory it might have been in a few years ago, there aren’t many active contributors to the KDE Usability Project at this time. This is very disappointing and discouraging, so I have thinking of ways of making usability and design a more sustainable effort in KDE. One of the most basic and important things you need to be able to do good design is to understand your user and what you want to enable them to do. Without this information (documented), it is all too easy to lose sight the big picture and focus on individual functionality instead of overall workflow.

Even in the real world, clients realize they need help with design when it is too late. When I join a project, one of the first things I try to do is back fill on user research, even if it isn’t something I’ve been tasked to do. It is both a necessary requirement for me to do the best job I can, and, it provides the client useful documentation they can use in current and future development.

It’s hard to know where you’re going or what you’re doing if you don’t know who you are developing for and what they are doing with your software. IMHO, each project should have the following information documented somewhere:

1. Vision statement or concept of operation
2. User group definitions supplemented with profiles or personas
3. Use scenarios and use cases (these are distinctly different)
4. Task and workflow documentation (not as necessary, but very useful for complex software)
5. Probably some other things that would be useful, but not as necessary and I can’t prioritize without making the list really long

This information will be different for each project. Each project has its own goals and users, so it does not make sense to create a generic set of user groups and profiles for the entire environment to be applied to sub projects. KDE (the entire environment) should have its own vision and user group definition, but so should Kopete, Konqueror, Kmail, Dolphin, etc.

For example, imagine how useful it would be to know the exact goals and users for Konqueror versus Dolphin. And have it documented and easy to find!

I’m sure all of you are on the wagon now, but it is still a lot of work and I want to make sure this is something people want.

• If templates were available, would you fill them out and keep them up to date?
• Does your project have a developer or someone else who knows the project well enough to be able to document (or research and then document) the points I’ve mentioned?
• Once you collected this information, would you refer back to it and use it during development? Really?
• Where would this kind of information live? KDE techbase?

So what I have been up to these past days? I started a GUI interface for KAppTemplate. KAppTemplate was (still is) a bash script (in kdesdk) which generates some templates projects for people who want to start a KDE app but do not want the full KDevelop. Somehow I ended up in porting KAppTemplate to KDE 4 (being bash, it was not too difficult, I hear you mumbling! true, but the templates themselves needed the port). One of my contributions in KDevelop 3 was to maintain some templates and I added some (as I began from scratch, I guess I am grateful for those tools and I want to help newcomers in KDE as much as I can).
KAppTemplate interface will be based on QWizard and the idea will be to share the templates with KDevelop (probably having a KHNS repository for them). So it's like a total rewrite in fact. KDevelop at the moment has only a Qt4 template and KAppTemplate has 2 KDE 4 templates.
I digged into model/view and also wrote 2 unit tests, thanks to David Faure and Kévin Ottens for the inspirational talk they gave at last Akademy. I took me time to assimilate the concept of tests but when I found myself writing several small test cases to check some chunks of my code, I remembered about tests :) Pretty neat! The whole code is in /playground/devtools/
KAppTemplate as it'll maybe look like:


Clarisse was 2 last Sunday but as we were away we could not celebrate properly and it'll be done next Sunday. She starts talking and is very funny, inventing syllables and concatenating words like "Joachim" (our son aged 17, her idol) and "Clarisse" give "Yo'isse" (she cannot say J or R). While as she is always around it's often difficult for me to concentrate when coding, on the other hand I'm lucky to share every step she takes. During the second week holiday I went to the "Cité de l'espace" with Léah and also to the circus. Léah will be 10 in May and is interested by everything, constantly asking questions and always smiling... To a soccer match with Joachim (our team at the moment is meant to go to the 2nd League...)

Although there are other serious topics to address -- the importance of process, what the e.V. is and what niche markets can do for KDE -- my immediate pressing needs are related to a few jars I just got from Peru. I don't know what they contain or what to rightly do with them:

- A jar of huacatay. It's a green paste, tastes salty.
- A jar of awaymanto marmelade. It's orange and very very tasty and sweet. The contents look sort of like fig and eyeball puree.

My initial reaction is to throw away the huacatay and put the awaymanto on toast. Is that vaguely the right thing?

[[ I got Qt 4.4 compiling on OpenSolaris and working again -- although I didn't test out the WebKit browser app this time, I was satisfied that the apps came up at all. There is definitely something somewhere in our build or the optimization flags that is making everything hang when we use the regular KDE-Solaris flags. That's a long hunt, given the number of factors involved. ]]

I managed to dodge most of the photos, however, one person managed to get a non-blurry shot of me.

Was a good conference, I’ll write more about it later…

I was driving home from dropping P. off at school. The air outside was crisp (-5C) but it was warm inside the car and I was just a few blocks away from home. The radio was keeping me company and the song "Alive" by Edwin was playing as I pulled up to a pedestrian crosswalk in an intersection.

As I'm waiting to make my turn through the crosswalk, Edwin sings out Ain't it good to be alive and this woman walks out into the street: 30-something, blond hair, three-quarters length dress jacket, a tall coffee in her hand steaming away ... my turn signal is clicking on-off, on-off as she walks in front of my car.

And then she just collapses .. crumples over like a switch had been turned off inside her.

Straight down she went onto the pavement in a heap, her coffee hitting the ground and spraying everywhere. It was thick and white with cream (a cappuccino?). She lay face down in the coffee puddle explosion, not moving.

Ain't it good to breathe the air, Another spin around the sun...

One of her legs was twitching very slightly, but otherwise not a sign of life. The turn signal continues to click inside the car as traffic stopped so as not to run her over. People got out of their cars and ran over to help her. Thankfully there were people with some medical knowledge who started to checked her over. Calls were placed to 9-1-1, the paramedics were on their way.

On this spec of light in the universe, A little peace of love in everyone

She didn't move at all the whole time. I thought, "I hope it was 'just' a seizure and not something even more serious. Like a heart attack, a stroke, ..." Since there were other more capable people already on the scene, I moved my car out of the way as soon as it was safe to and continued on home.

Aint it good to be alive, To feel the sun strong against your face

Yes it is good to be alive. Fragile as we are, we never really know how long we have left. Right now, it's time for me to go find someone I haven't said "Hi" to or hugged in a while and fix that.

Musical instruments are fun to draw.


Two more illustrations; steel strings for phosphorus and a digger for manganese. The digger is drawn from a photo I took a couple of years ago of a old digger (Åkerman) belonging to my brother. The light in the photo was from the wrong side so I mirrored It.

A few days ago, my good old Audigy 2 ZS decided that it was time to give up, and start doing weird stuff to my PCI bus, so it's been replaced.

Thanks to Creative taking years to provide any linux X-Fi support (I know they've released a closed-source 64-bit only license, but if you've looked at it, you'll understand me when I say the less you think about it the better; I'm also aware that there's now some open-source OSS and ALSA support for it), and for Vista, I've broken my tradition and not got a Creative card.

I'm now very happy with my Terratec Phase 22, which is cheaper than some X-Fi cards, has balanced analogue audio connections, and much better drivers.

Next on my list: In 18 months or however long it is until I next replace my graphics cards, unless NVidia pull off something very, very impressive with their drivers, I'm going for ATI/AMD; I would have over Christmas instead of NVidia if the RadeonHD driver wasn't quite so new.

For the first time this winter -- since it is now spring and all the trees are blossoming -- it has snowed. My brother, over from Honduras for this week, is not impressed and quite a bit cold. I am really looking forward to spring and bicycling and pottering in the garden in general this year. We have rented a plot of land of 100 square meters to use as a vegetable garden, so there will be zucchini and worse.

It seems snark is the new constructive criticism. Mike said it really well, so I won't repeat it here. I kind of liked Jos's examination of the KDE4 logout process, but the same thing could have been done without the snark, really. I sympathize with Jos's, point, though, as I said at FOSDEM "the logout thing drives me up the wall." And one thing Jos forgot was that your X session must support Xrender or alpha blending to logout at all -- some thin clients can't, so I became quite proficient with qdbusviewer's method call window. For real deserved snark, the comics curmudgeon is a good place, while the original websnark tends to have a more positive look at webcomics.

My enthusiasm for ZFS has been tempered somewhat by a subsequent half-dozen installs, but I've found another 200G disk in a dusty box somewhere, so at some point I'll blog about the good bits (and the bad bits of the various installers that OpenSolaris uses). But first I must become a doctor. And maybe next weekend, I can learn French.

100_5656

Originally uploaded by vanRijn

I’ve been looking for a better screen protector for my PSP than the one I had (a Hori) and was just about to go out and spend $20 on an Invisible Shield, but I found people talking about using 3m Scotchgard instead. It’s certainly less expensive, and if it works, $11 gives me more than enough for everything I could possibly want to cover (Palm Treo, PSP, 3 iPods, Swatch watch, etc.). So I gave it a shot. Pretty good results too!

In my first trial run, I used Windex to apply the Scotchgard to the PSP and there were really tiny bubbles that I just couldn’t get out. But the second time, I used a 33% rubbing alcohol, 66% distilled water solution and it seems to be working much better.

Anyway, I’ve put up a series of pictures about this madness as a follow-up to my previous post about it…

I realise I’m probably going to get lynched for this but I think it needs to be said.

If you, as a KDE developer, get annoyed with a KDE feature you didn’t write and feel like blogging about your bad interaction with a part of KDE or a spat with another KDE developer then please don’t. You have every right to do so but it isn’t good for you, it isn’t good for the other developer and it is really bad for KDE.

The problem with a community like KDE doing the majority of their work online is that sometimes we forget basic social rules of interaction. If your blog is on Planet KDE then you are held as a representative of KDE and your blog posts are read by a lot of people. Some of these people are KDE fans, some are other developers and some are journalists. When you publicly insult other people it creates tensions in the community between people.

If there is one thing I have learnt in my (short thusfar) career as a software engineer its that the most important thing for a team to do is get on well and be polite to one another. If I have a serious problem with a coworkers work or behaviour I should privately confront them and explain not only the problem but also how it made me feel. I realise that most FOSS developers are men and most men don’t like talking about their feelings but it is important in resolving conflict that both parties understand why the other feels the way they do. When someone communicates on the internet, unless I’ve hacked their webcam, I can’t tell if they are laughing or crying. You get cues but these are far more subtle than face-to-face or even vocal interaction.

I’ve seen too many FOSS projects destroyed or severly damaged by petty infighting. Please don’t let KDE be another one.

I think KDE needs something like a “Conflict Resolution Manager”. This probably sounds ludicrously stupid but there has to be a better way than flamewars and passive-aggressive blog posts.

I realise this post alone might seem to violate things I’ve said above and for that I’m sorry but I feel the point needed to me made and not just to a few individuals. If anyone wants to call me an idiot, beat me with a stick or let me help them then send me an email, call my mobile or ping me on IRC/IM.

Lets sort this stuff out guys. Be part of the solution, not the problem.

PhotoFlow, which I introduced less than 48 hours ago, can also be realized as a plasmoid. It is the top left applet in the screenshot above. I have never written a plasma applet in my life before, so it took me quite a while to figure out how the mechanism works. And frankly, I am still not sure whether such a kind of widget can be really useful at all.

I guess I will wait until KDE 4.1 before I place this stuff in KDE's playground. By that time, Plasma itself should already stabilize. Probably it is even better to integrate it with the Picture of the Day data engine. Or even with the slideshow plasmoid. Or perhaps do you have any other idea?

The last week-end me and Martin manned the openSUSE booth at Chemnitzer Linux-Tage:

Executive summary: the organizers counted 2400 visitors, Martin gave an "openSUSE project" talk to 100-120 people, we distributed 400 Promo-DVDs, several openSUSE caps and some Novell pinguins. More photos from me and from others are available.

In Plasma all the "top level" groupings of widgets are Containments. Desktops are containments, panels are Containments ... everything that holds a group of desktop widgets is a Containment. In addition to being the atom of grouping, Containments are responsible for the presentation of things beneath widgets (e.g. wallpapers) and around widgets (e.g. context menus, toolboxes). All the Containments live in the scene, which is called Corona in the code.

Containments themselves are plugins; in fact, they are a specialization of Plasma::Applet and come with all the same flexibility plus a little bit extra. (I suppose that means that in theory you could have a superkaramba theme or a Mac Dashboard widget as your desktop or panel ... it would require some minor patching in corona.cpp around line 400 to work in practice, however.)

Right now there are four Containments that I'm aware of available for the Plasma workspace: DefaultDesktop, Panel, Null and AnalogClock (of course ;). I believe the Amarok guys have also written a Containment specifically for Amarok's needs. To give you an idea of the complexity involved, Panel is 329 lines of code (including the header) and DefaultDesktop is 2,213 lines (though that also currently includes wallpaper Package support, threaded wallpaper rendering and all the legacy Desktop directory loading code). With scripting, you could do this without C++ even (though right now we lack some useful/necessary bindings to the Containment class to make this practical ... not a huge amount of work though).

The runtime definition for a Containment (such as your desktop area on a given physical screen) is stored in the configuration file looking something like this:


[Containments][1]
formfactor=0
geometry=0,0,1280,800
location=0
locked=false
plugin=desktop
screen=0


The Containment plugin that is loaded is defined by the plugin= entry. Change that entry and you change the containment. The widgets inside stay the same, only the Containment changes ... (to protect the innocent?)

Changing the screen= entry alters which physical screen, if any, a containment is associated with. This is where this feature overlaps with the zooming: zooming out is how one gets an overview of all available containments (modulo panels) to switch between them or just interact with widgets that on other Containments (including moving them between Containments). This has all been there since 4.0.

(By the by, if you have been looking for a longer explanation of the zooming concept, here's a blog from last July where I wrote such a thing.)

Plasma has been designed with this idea of switching Containments as a very basic and rather central concept. Those following closely will have noticed that I've mentioned this idea more than once in various screencasts and blogs in the last year or two.

However, it seems that the full implications of this particular feature set is being missed, because when, in passing, I noted what this means in relation to something like the toolbox (remember, that's the containment's job) on panel-devel people were ... surprised. I was surprised they were surprised. I thought I was stating the bleeding obvious, but apparently I wasn't. So, lots of surprised people all around. To join in the party of surprised people, here it is:

If you want a different feature set, select a different Containment.

So if you want no toolbox, a completely different neat/crazy background concept, something that incorporates a different widget layout schema, or $WHATEVER ... you just need to find a containment that provides that. This is similar to how instead of having one clock applet with a bazillion configuration options and widgets, we instead have clock visualizations that share most of their code with each other and you select between the different clock faces when choosing a clock to stare at.

The inspiration for this approach was watching the various Kicker PanelExtension classes and feeling the pain of just how limited they were in what they were allowed to do. Because of that, people creating things like the Mac dock would fork bits of kicker, write their own panel system from scratch, do it in Superkaramba, etc. That seemed really unfortunate. People want radically different ways of dealing with panels, and I figured they'd want the same with their desktops, media centers and mobile devices. So why not make that part of the interface a plugin that's as flexible as any desktop widget itself is?

Now let's reflect on the idea that I'm not keen on making the desktop toolbox configurable: maybe it starts to make sense to you that it's an unnecessary complication because the whole Containment is a plugin. The toolbox has a point and purpose, it's improving nicely as we go and, yes, I personally think it will become something rather compelling .. but at the end of the day it's just part of another plugin loaded at runtime. The only hardcoded bit is that it's the default plugin to load in lieu of other configuration directives.

(If you're wondering if other Containments can take advantage of the toolbox if they wish, yes they can. The Containment class provides access to it for any Containment plugin that so wishes to use it.)

Currently, Containment switching and creation is "hidden" in the appletsrc config file. We will be making UI for it, hopefully for 4.1. It's been pending completion of the DefaultDesktop config dialog which we will then genericize into a general Containment config. To the user this will appear pretty much like any other wallpaper setting dialog, only with a hell of a lot more punch as it will give access to more than just wallpaper changes when you hit that "Ok" button.

Today we are helping novice KDE users to log out of KDE 4. Logging out of KDE 4 is nowhere near as hard as with some other popular programs. Here you do not need esoteric keyboard commands like '<esc>:q!' or 'ctrl-X followed by ctrl-c'. In KDE 4 you can easily log out by using your mouse.

Stop 1: move you mouse to the bottom left of your desktop and click on the picture of the K in the cogwheel.

Stop 2: Now you see the 'kickoff menu'. From here you can start programs. But you can also stop using KDE. Move your mouse the the button labelled 'Leave'.

Stop 3: Hmm, that thing called 'Leave' was not really a button. Clicking does not help you, but simply hovering (moving your mouse over it) does help. By doing that, you unlock a new batch of buttons. And there are many of them too. Such a plethora of choice: there are various degrees of 'stopping with KDE'. You can choose between:

Logout

This means: stop all programs and stop KDE but do not stop the computer.

Lock

This means: keep all programs running and stop other people from using this computer.

Switch user

This means: let someone else use the computer while your programs keep running in the background.

Shutdown

This means: turn off the computer.

Restart

This means: turn off the computer and start it again immediately. What the computer does when it restarts depends on how you installed it.

Stop 4: We decide we want to 'Logout' so we move the mouse to the button 'Logout'. You can press it. It really is a button.

Stop 5: Now your screen becomes gray and a single window stands out in the middle. Are we logged out now? No we're not. Not for another 58 seconds. You can check this from the countdown on the bottom of the window. If you want to experience the full satisfaction of logging out click 'Logout' once more.

Goodbye! Come back quickly!

Today I had an interview with Emanuel from kubuntu-de.org about the progress and future of Akonadi. After the interview we talked about different stuff and to my surprise Emanuel studies ethic and history on lectureship. So he is the second KDE fellow (Carsten Niehaus is the first one) I know, who will teach the pupils of the next generation how great KDE is ;)

So I thought about how to combine KDE with ethic and history. Ethic is a difficult thingy, but history is fine. I really miss a program which shows me a time line with
all important things that happened in history. Honestly I was no keen on history during school, but that has slightly changed nowadays.

So after some hours of hacking I can present a neat, little application, which reads facts about historical events from a XML file and shows them in chronological order.
For every event the file contains:

• the date of the event
• a short description
• a reference to an image
  
• a link to a source that provides more information (e.g. wikipedia article)
• a category tag

At the moment it's only a small pet project, however it can be extended for general purpose. For example you could provide a XML file that contains information about all KDE releases, with small screenshots of the desktop and links to the release announcements.

And here comes the obligatory screenshot:

When you click on the link, the wikipedia page for Martin Luther King is opened in the default browser.

With the imminent release of KDE 4.0.2, Konqueror will not only have a bigger Acid3 score than Firefox, it will also include 50 languages (49 translations + original English) which equals 50 Firefox 2.0.0.12 translations (44 official + 1 beta + 5 language packs) so if you belong to a language that still is not well translated into KDE join the amazing l10n team of KDE and help us surpass Firefox there too ;-)

Here are the pain points I've culled thus far on the desktop toolbox:

• My corners are already occupied (Possible solution: user moves the toolbox)


• It disturbs the feng shui of my wallpaper (Research: less intrusive default appearance ... improved themability?)


• I don't have a use for it (Deferred: revisit when zooming is complete)

Past pain points that have been fixed include:

• It "spasms" if you mouse over it the wrong way


• Innactive state is too bright


• It animates out when not intentionally triggered (e.g. when closing a maximized window)


• It shrinks when I zoom out


• When I zoom out on the second screen, the toolbox is no longer visible, leaving me without a way to get back

If I'm missing pain points for the toolbox, put them in the comments section here and I'll add them to the list.

I really need a tool for managing this. Something collaborative, a bit more structured than a wiki but as easy to use. Bugzilla is way too clunky and defect reporting oriented (not to mention that as a user, I dread being confronted with a bugzilla report form =/). Something like review-board, but for enumerating feature sets, recording pain- and plus-points, gathering votes on them, noting possible avenues of research, recording cures for the pain points as they happens ... Right now I'm keeping lists pretty much manually and as a user I would have no idea where to effectively drop my pain point.

This is the first post from CeBIT - We are here in the LinuxPark at the very end of hall 5. Currently we are 4 people - danimo, tackat, eckhart and /me.

Today in the morning I entered the train and the first handouts were already given in the train. Then I meet tackat in front of the exhibition center and we got into our small booth. The booth box arrived at around 13:00 and danimo arrived only shortly after that ;-).
People really want to know a lot from the basics of FOSS to the features of KDE on Windows. We try to give as much as we need - since KDE is so cool...
Btw. kind regards of the amarok folks, they don't have network access;-)
Some more fotos will follow as soon as I get my camera back...