Pushing Immature Technology onto the User

KDE4’s new Desktop shell called Plasma is meant to do everything better then KDE3’s kickoff+kdesktop did. Innovations over innovations, exciting stuff is going on there. The development goes on in a high pace, and with every release there is new features all over the place. It would be a really great project, if there wasn’t one tiny little problem: It is the core desktop shell of one of the 2 major linux distributions, still they refuse to care about a large part of their current/potential users. Yes, I’m talking about the poor souls who don’t have good enough hardware for full desktop composition, don’t have good enough graphics drivers for stable desktop composition, or the rebels like me, who simply cannot stand the slight lag always feelable on a composited desktop.

I don’t even want to open a discussion on graphics drivers here. Fact is, I have very good graphics hardware, but when using composition, you _always_ pay a price for it, especially when you have a 3280×1200 Desktop setup, and when your system is under heavy load. As desktop composition becomes more popular, the drivers are maturing, but still the general architecture is far from perfect.

Apart from that, a 2000 MHZ computer with 512 MB of ram and without a 3D accelerator card should be able to run any good desktop environment without problems, and it should even be able to look good. There is no technical reason speaking against it. I don’t consider Windows Vista a good desktop environment in this regard btw.

I also don’t want to start a discussion on desktop composition in general. I want to start a discussion on the way those people are treated, who do not want to jump on using the newest immature technology, or simply aren’t able to.

Now along came Plasma. It has tons of beautiful themes available that are downloadable through GetHotNewStuff. The only problem: Most of those themes look like total crap when composition is disabled, because plasma does not allow the panel to blend over the underlying desktop without desktop composition. 100% exact transparency by definition can not be achieved without composition, but all desktop environments except KDE4 support something called “fake transparency”, where the panel uses a blended version of the underlying wallpaper as background, which leads to a nearly correct result, with the only downside that windows covered by the panel are not visible through it. But seriously, who puts windows under his panel, and wants to see them?

However, and I knew this before, the plasma developer consider something like that an evil ugly hack, and don’t want to put something like it into plasma.

Since I’m an aesthetically sensitive person, I got tired of the grey brick at the bottom of my right screen, and put a few evenings into finding out how hacky it would really be to make it look nice. It couldn’t be that hard, after all the plasmoids on the desktops themselves also use the same software aka. fake transparency. And behold: Due to the fact that the desktop and panel live in the same application, and because of the logical API, in the end it turned out quite easy to do, and quite un-hacky. It works unbelievably well: Wallpaper blending animations, moving plasmoids under the panel, or putting animated plasmoids under it works exactly as expected. Here you can see the result. About 80 added lines of code, no evil stuff, no API added, and this result:

Before (Actually this is one of very few themes that don’t look like total crap without composition):

After (To my eyes, about 100 times more beautiful than before):

Still, not the slightest interest in adding this. To them it might be a hack, but to me, it is the only way of achieving a nicely looking desktop without composition. 80 Lines of code, for at least 36% of all linux users(According to this survey, in my experience it would be even more).

Instead, I get told that I should use composition(btw. games run a lot slower with nvidia just from enabling it in the xorg.conf), I get told that drivers are getting better, and I get told that hardware is getting more powerful. And this is where I see a basic problem with plasma: They seem to be developing for the future, and only give a small part of their attention to the present.
I don’t care whether future drivers will be better, I don’t care whether future system tray specifications will be better, when at the same time my desktop does not look nice, my systemtray doesn’t work properly, and my krunner doesn’t run the commands I type. KDE4 is a technology of _today_, and should work _today_, for everyone.

This goes for all of KDE4: I sincerely hope that in future, we can find a better balance between innovative development, and present usability.

Advertisement

Portable Meta-Information

KDE4 is all about new technologies, and standardizing. Now we have a central mechanism to store metadata, called Nepomuk. However it basically still follows the somewhat problematic approach that all the metadata is stored in one central place.

I think there is nothing more valuable than the data of the user, and meta-information like for example ratings of a song, tags, or comments attached to a file, are user-generated data, that needs to be treated as carefully as the files themselves.

I have already used many different applications in my lifetime, different email-applications, different music-players, image-management software, etc., and all kept the user-generated meta-information closed within the application, which means that when the lifetime of the application is over, the information is lost, or with luck, can be exported with some effort into some re-usable format.

Due to those experiences, application-specific meta-information has only a low value to me. I think, for the future, we need to find a way to keep the users data together, so it is as persistent and approachable as the files themselves:
– When the user copies his photo archive or backs it up to a CD, no matter what application he uses, meta-information like ratings, comments, or tags, have to move together with the photos
– When the user has a fresh install, and copies his photo archive from a CD to the disk, the meta-information for the photos should be just there
– User-generated meta-data should _never_ be lost just because a file/directory was renamed, a mount-point changed, or whatever
– User-generated meta-data should not be lost when a file completely unrelated to the item is damaged or deleted(Database)
– In 20 years, when KDE4 is history for a long time, and I find an old photo backup CD, the meta-data should still be readable

When these conditions are met, then metadata would finally be worthy. But how can it be reached?

I think with Nepomuk and Strigi we have most of the needed infrastructure available, there is just a few missing pieces:
1. Store user-generated file-related meta-data directly where the file is stored, in a standard format, example:
File:
/media/archiv/pictures/picture1.jpg
User-generated meta-information:
[/media/archiv/pictures/.picture1.jpg.meta] or in shared directories: [/media/archiv/pictures/.picture1.jpg.meta.nolden]
Could contain something like:
RATING=2/5
TAGS=funny,family
…
2. Change file-managers to move/copy meta-information together with the files when handling them individually(I think this already is the case in dolphin), and delete the meta-information when the file is deleted
3. When finding orphaned meta-information, ask the user what to do withit(Don’t forget: It’s valuable information)

Strigi could collect the information from those meta-data files, and nepomuk would manipulate them. Nepomuks database would be a kind of cache for the metadata.

The whole behavior should be standardized among desktop-environments at some point, so the meta-information would not only be persistent, but also accessible from within every application.

With this reached, I could finally start doing using image- or music-rating, tagging, etc. without having the feeling of wasting my time in my stomach.

What do you think?

Update:
Actually probably the best way would be this:
picture.jpg
picture.jpg.meta
With the meta-information not hidden at all, so you will be aware of it when using the command-line. Aware file-managers like dolphin should hide the meta-information automatically, and all other file-managers that are not aware would show it. I think as long this would only be used for user-generated meta-information like ratings, it would be worth it.

Really rapid C++ development with KDevelop4

Code Assistants
When developing for a statically typed language like C++, there usually is quite a bit of redundancy during the development, especially when creating a completely new piece of code. A powerful IDE with deep code understandic theoretically could save a significant amount of the writing work. My goal with KDevelop4 is to allow the user only to concentrate on the “content” of the code, without wasting too much time with creating or adapting declarations in several different places.

To reach this goal, code-completion is not enough. Sometimes it is not possible to properly guess what the user wants to do during typing, but once a statement is completed, it becomes clear. Also the completion-list is not suitable as a user-interface for everything.

During the last weeks I have implement an Assistant architecture within KDevelop. In general it is kind of similar to the bulbs or paperclips known from several office applications, with the main difference of actually bein useful. 🙂 An assistant can watch the happenings in the editor, duchain, etc., and pop up a non-intrusive popup with some keyboard-accessible options as soon as the assistant thinks it can do something useful for the user.

Declarations/Definitions
The first assistant I implemented already more than a week ago was one that could automatically adapt changed function-signatures of declarations and definitions. Personally I hate having to do exactly the same thing twice, thus this thing compes very handy. As soon as you significantly change a definition- or declaration-signature, you will see this:

At the bottom you see the assistant popup. Every popup has an associated action with a number, and you can execute the action using the ALT+Number combination. So you will get this effect:

This is already a quite useful assistant, since it saves you from a part of C++ that I personally sometimes find a bit frustrating. But not any more. 🙂

Automatic Declaration Creation
There is other much more significant types of redundancy when programming for statically typed languages. One such example is iterator names. Why do I always have to write out their name completely? Even with code-completion, it sucks, since the iterator variable type is logically completely determined alone by the value you assign to it. Now with KDevelop, you can save a lot of this. If the type of the variable is determined by the assignment, just don’t write the type by yourself, but let the IDE do it for you:

Just push ALT+1 and get this:

Now when you’re designing an algorithm, you can just write as if you were writing python, and let KDevelop create the variable declarations for you:

The assistant gives you this:

But it gets even more interesting. If you try calling a function that does not exist yet, you will get this option:

And the assistant will give you this, notice that even the return-type has been correctly matched to the context:

This also works within the local class:

Here the result, notice that the return-type is automatically a reference when you assign something to it in the call:

Together with all the other conveniences of KDevelop4, like automatic adding of includes, automatic creation of function-definitions, a class-wizard that correctly places all the includes and writes added files into the CMakeLists.txt, the Qt Documentation Integration, Code-Browsing, etc., KDevelop is a really productive IDE.

Development Update
This is one of the few large features that I yet wanted to implement before a release, now there’s not many major features left on my todo list. Although I’m quite sure I will get some more ideas, the next major task is improving the usability, killing all the little bugs, and improving the performance and scalability of the duchain store so it doesn’t get slow once some size has reached.

The other parts of KDevelop are doing ok, but unfortunately the debugger still hasn’t made it into a usable state, it’s the one big gap that’s still there in KDevelops functionality.

Typedefs in Templates, and Code-Completion

Sometimes you have to decide between being “correct”, and being user-friendly.

Also, sometimes you have to do one painful change with many regressions, to reach an ultimately better state.

I hope I had to do the last such step before the stable KDevelop release(Though you never know). I have changed the internal representation of the C++ DUChain, so typedefs spawn custom types, instead of being just pointers to the targets. This is not exactly what the C++ standard says, but this means that KDevelop will no more replace std::string with “std::basic_string<blah bla>” if you implement a function or do other simple refactoring stuff.

There is some problems with generally doing this though, because for example in a template container like “std::list”, you want the types in the completion-list not to show “std::list::reference_type”, which also is a typedef, but instead the type you gave to the container. So how should this be done to be most userfriendly, while still staying correct enough?

I’ve implemented this simple logic for the completion-list: If the typedefs target type recursively contains less template parameters, show that one, else show the typedef type. I’m quite sure you can construct a case where this does not work as expected, but for 99% of all cases, it should show the nicest thing that could be shown.

But there is other problems with representing typedef types as real types. The C++ standard explicitly states that typedef types given as template parameters, spawn exactly the same template instantiation as the typedefs real type. For that reason, a typedef has to be resolved before doing any template stuff. If this would be done, you as well be back to “std::basic_string<bla bla>” as return-types in “std::list<std::string>”, so a decision had to be done here.

I have decided to spawn different templates for typedef types, so that the user will see the nices possible representations.

And here the glorious results:

Unbelievable that such a simple-looking thing can be so painful. 🙂
The good thing is: After some time of finding all the regressions, KDevelop is better than ever!