Martin’s Blog

Unfortunately Tokamak is already over for me I’m just sitting in the train back home, as my Thesis wants to get some finishing touch. I really enjoyed these three days. From the social point of view Tokamak is just like Akademy a great experience. And this Tokamak was really big. The openSUSE offices are a perfect place for the sprint as there is one room big enough for all of us and several small meeting rooms for the small breakout groups. Thanks again to Will for organizing everything.

On Saturday we mainly had presentations and today the breakout groups started. In the morning we had a small discussion about activities/context/whateveritscalledthesedays and came up with a small API for activitiy management. Looks like the KWin part will be easier to do as initially expected as we can use quite some of the virtual desktop code to (un)hide windows whenever the activity changes.

After lunch we started two discuss Plasma/KWin integration. I had a list of points for better integration and the funny thing is, that most of the issues the Plasma guys and girl mentioned were on this list. Quite good that we see the same points for improvements. The discussions were really productive and I think we found consensus in all discussed topics which will hopefully result in code written and a way better user experience. One of the discussed issues was an improved dashboard. Currently the dashboard is just a normal window, resulting in issues like it’s possible to alt+tab or start present windows. The idea is to tell KWin that the window is a dashboard and that we add special support for it including a nice fade-background effect replacing the currently black background rendered inside the dashboard.

Due to overlapping schedule I was unable to attend the mobile session. I will probably try to get KWin compiling on Maemo, which requires a port to OpenGL ES 1.1. I thought that N900 requires ES 2.0 which would require a shader scene and way more changes to KWin code base including huge #ifdef areas. OpenGL ES 1.1 on the other hand is just a stripped down version of OpenGL 1.5. So getting KWin compiling should be much easier. Of course there have to be some changes as some currently used calls are unsupported, but removing glBegin/glEnd and switching from rendering quads to triangles will probably improve overall KWin and as I have a "port" of KWin to OpenGL 3 in my local git repository I can (hopefully) just cherry-pick those changes.

=-=-=-=-=
Powered by Blogilo

There are a few things in KDE’s desktop shell which have not changed for a very long time. For example I remember that the first KDE version I used (that was a 3.x with x << 5) had the same control module for window decorations as the one we will have in KDE SC 4.4. The interface displays a dropdown list with the names of the available decorations, a configuration panel for the selected decoration and a preview. This results in wonderful tabs inside tabs user interfaces – just look at the Oxygen configuration in 4.4.

With KDE SC 4.5 there will be a new interface which could be called the Qt 4 port of the decoration control module. The dropdown is replaced by a list view displaying previews of each decoration. The configuration panel is moved to a dialog which is accessible from a configure button next to the preview.

New decoration KCM

As I think it’s important to honor those who should be honored a button to access about data has been added. So if you have written a decoration please add your author information to the desktop file of your decoration.

Aurorae themes are included in the list just like "normal" decorations. The fact that Aurorae is a theme engine is an irrelevant implementation detail for the user and by that it should be hidden. And so KWin finally supports Get Hot New Stuff for decorations – that’s just awesome. I hope we will be able to integrate deKorator themes in the same way.

Unfortunately I was not able to finish this for 4.4.

=-=-=-=-=
Powered by Blogilo

Yesterday evening just before the hard freeze a nice feature was added to KWin: window decoration painted behind translucent windows. Have a look:

Currently it’s supported by Aurorae, our only translucent decoration, and I think there are no applications yet which use the feature. But as it is proposed as an addition to EWMH I’m sure there will be in future. Somewhere I read that Mozilla Firefox wants to use translucent backgrounds. So that is your solution for the X11 platform.

Well this feature illustrates that we need a blur effect

=-=-=-=-=
Powered by Blogilo

This weekend I worked on some KWin OpenGL Shaders. That is I wanted to bring back the blur effect. It seems like many users want to have the effect and well with translucent window decorations a nice blur is kind of needed (yes we get compared to Windows 7 and that blur is really well done). The first results look very promising: it’s fast and doesn’t render artifacts to the screen. But I decided to not rush it into 4.4 as there are still some minor glitches around the decoration shadows which render the nice Oxygen glow useless. As well the blurring is not yet as nice as one produced by Krita. I will merge the branch as soon as trunk is open again and so we will have a blur effect in 4.5 again

But blurring is not the only OpenGL shader I started to work on this weekend: I started to implement a shader to replace the complete fixed functionality rendering of KWin. Our current rendering uses lots of OpenGL 1 commands as we also want to support older hardware. We have some OpenGL 2 shaders like the blur which replace parts of the fixed functionality.

In OpenGL 3 the fixed functionality is deprecated, in OpenGL ES 2.0 it’s even completely removed and replaced by the programmable pipeline. So getting the rendering completely into a shader is a prerequisite for using the new awesome stuff of OpenGL 3 like geometry shaders as well for porting KWin to OpenGL ES.

So why porting to OpenGL ES? Well I would like to see KWin running on Hardware like the N900 I think that KWin although developed for the desktop would be a nice window manager for small devices. We have some outstanding effects and a great decoration API as well as a nice SVG decoration engine when you don’t want to write your own decoration. And of course we see that some projects use Clutter based window managers for their small screen systems and it would be nice to provide an alternative, a window manager which is rock solid and has been used with compositing enabled by default for now almost a year – in some distributions already since KDE 4.1. And last but not least optimizing for small devices is useful for desktop systems as well.

So after spending some hours hacking the basic window rendering is implemented in a shader and if the shader is bound no deprecated OpenGL functions are used. Not only the basic rendering is supported, but some effects like present windows, desktop grid or even cover switch (as long as not using multiple screens) work as well. Other effects like cube, all shader effects or important benchmarking tools like fps are completely broken (Nevertheless my completely unprofessional benchmark called “top” looks very promising – kwin is not shown any more when idling or just doing a few repaints).

I don’t know when I will have something that could be shared as my development time is currently very limited and I only work on KWin at weekends. As well for the OpenGL ES part it could be a problem that I don’t have any hardware For OpenGL 3 it’s no problem as the drivers I use support it. I hope to have it in a state to push to trunk when it gets unfrozen.

=-=-=-=-=
Powered by Blogilo

One effect to rule them all. One effect to find them,
one effect to bring them all and in the darkness bind them
in the Land of KWin where the Wobbliness lies.

I wanted to present a video of it, but recordmydesktop does not want to record my desktop. So here is only a screenshot of new KWin fun:

Desktop Grid uses Present Windows (if activated) to lay out the windows as you might know from the previews of GNOME Shell or Mac OS Spaces. In the not existing video you can see that dragging the windows from one desktop to the other is nice and smooth. As soon as the dragging starts the windows on the starting desktop will be rearranged and the window, which is being moved is, bound to the cursor. When dropping the window onto another desktop the windows start to rearrange immediately.

The Present Windows effect has a proxy which allows other effects to call some of the methods from Present Windows. So Desktop Grid uses the proxy to get the layout for a group of windows. The proxies are also used in other effects, e.g. Sliding Popups disables the Fade animation and CoverSwitch uses a proxy to get the thumbnail bar from BoxSwitch.

Other goodies from Present Windows like filtering or mouse actions are not used. Therefore the effects have to be merged to become the one effect to rule them all. (Yes The Lord of the Rings is currently again the book on my bedside table.)

=-=-=-=-=
Powered by Blogilo

I broke a promise, the promise to never ever implement the most useless Compiz effect in KWin: cube gears. Well I was not motivated enough to work in a productive way yesterday and thought “just have a look on how Compiz does the gears”. I looked at it and there aren’t many Compiz dependencies, it’s just painting gears. So I just took the code added it into cube and there was a gear. Kind of funny, that the most useless effect can be ported while the useful ones seem to be impossible

Here the video as proof:

For those who don’t see the embedded flash: download

There are some differences to the Compiz effect: the rotation is disabled as it looks very bad. In opposite to Compiz we don’t use the depth buffer and so there can be glitches. You can see them when rotating the cube manually. Because of that I’m unsure if I will add the gears effect to 4.4. Perhaps it’s time to use depth test in KWin as well (would be useful in other effects as well – e.g. FlipSwitch and CoverSwitch).

Many people obfuscate their email address on web sites in the hope that bots are unable to extract their address from websites. That could look like the following:

email [AT] example [dot] tld

This approach is for example used by Mailman’s archiver pipermail and the MARC mail interface used by the KDE mailing lists. Some people even ask to “not quote the e-mail address unobfuscated in message bodies”.

So is it useful to obfuscate the email address? Does that add any security?

The answer is No. This obfuscation is a kind of a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) which requires that a computer cannot solve the Artificial Intelligence problem when it has access to all information required to create the test. Yesterday I tried to proof that this kind of CAPTCHA is broken and wrote a small application which is able to extract the email addresses from a public pipermail archive. The application is less than 300 lines of code and can automatically download all emails for a given month and year and extract the sender’s address by just extracting all a elements from the online accessible emails and applying a regular expression on the text to get the email address. I only wanted to work half an hour on that. In the end I had to compile Qt 4.6 because I needed the new QWebElement If someone is interested in the source code I could create a repository on gitorious.

The following image shows the result of an “attack” on the plasma-devel archive. For privacy reasons I blurred the user part of the mail address.

I don’t think there is any reliable way to obfuscate an email address using simple text. If there is an algorithm to obfuscate the address, there is a regular expression to unobfuscate the email. The only way to protect an email address is to not include it anywhere where a bot could harvest. That is replace it by a “real” CAPTCHA that will reveal the email address when solving it. For websites there is for example the Mailhide API of reCAPTCHA. For mailinglists that is completely useless as the email address is already included in plain text in the email headers. Instead of parsing websites bots could just subscribe to the mailinglists.

So please stop obfuscating your email addresses. It is useless and makes it impossible to just click on an email link. Instead the reader has to solve the useless CAPTCHA.

At Desktop Summit Lubos asked me what openSUSE has to do that I will switch back to SUSE. I replied that I am satisfied with Kubuntu and so I don’t see any need to switch the distribution. So what has changed since July?

Kubuntu will ship the Plasma Netbook Shell in their next release. Of course the Netbook Shell is under heavy development and will be shipped in KDE 4.4 for the first time. Given the current release plan we can consider the current state as pre-alpha. But that seems not to be any problem for Kubuntu – they even are able to support it for 18 months as it is in the main repository. They are even able to ship a recent SVN revison: the current package is svn rev 1016996. So quite decent and no problem at all, isn’t it? Well no, KDE 4.3 got branched way before and since then trunk is KDE 4.4 and code in trunk may depend on trunk. But if there were a dependency it would break at compile time, wouldn’t it?

But couldn’t there be runtime dependencies? No way, that’s totally impossible. It’s a plasma netbook shell, not a KDE workspace netbook shell! So it’s totally impossible that KWin added changes to improve the netbook shell. So we have in the netbook shell a commit with this commit message:

Activate present windows by setting a property instead of faking keys. Requires kwin svn rev 988110

Of course a distribution checks all the svn log entries and knows about such issues. So they will probably use the old code, which was just a placeholder to be replaced as soon as trunk becomes 4.4 as happened. So I downloaded the source package and woops it contains my commit. Hmm so there is still the possibility that KWin was patched. That would be really bad as present windows received lots of changes at the beginning of 4.4 release cycle. Which is great but shouldn’t be shipped in a distribution before it has been tested probably. So I thought, let’s check the patches in bazaar. Well there is no such patch to KWin. So the applet is basically broken in the Kubuntu edition. Kubuntu will not only ship and advertise a development snapshot, they will be shipping broken software. (which btw is not the first time that Kubuntu ships development snapshot unsuited for usage – just remember the NetworkManager Plasmoid).

Update: Kubuntu assured that the Plasma Netbook Shell will only be published as a tech preview and that it will communicated as that. This makes of course the points mentioned above invalid.

While browsing the patches in bazaar I found a different patch which really upset me. It is a patch which was discussed on kcd last week and was rejected by all workspace developers who replied to that patch. So a patch which is not good enough for KDE is good enough for Kubuntu. I though Kubuntu wants to be the best KDE distribution. Sorry, that isn’t. I am disappointed and I think it is a bad sign if decisions by the upstream project are ignored (the change to package kdebase-workspace was commit after the discussion started on kcd). I objected to the patch for technical reasons and there was agreement to improve the notification instead of stepping back to present nag dialogs.

For quite some time I am disappointed by the developments of Kubuntu. With 4.3 packages the translations broke again (as every half year) and that is just the worst which could happen to user experience. Because of that problem I stopped to recommend Kubuntu to my friends. But now I see a development in Karmic which I do not want to use myself. There is a broken development snapshot of the netbook shell, an alpha release of k3b is shipped, which is not even shipped by Fedora, because it “isn’t quite ready, and not recommended for use by upstream” and Karmic will ship an additional notification system, which doesn’t support actions, to “test” how KDE users will get along with it. I don’t have any problems with Canonical deciding to develop and ship a different notification system but as soon as it degrades the KDE workspace it has to stop. By shipping that patch there is a degeneration of the user experience as a dialog is shown instead of a notification. If you doubt that the change was done just because of the Ayatana notifications please read this mail. I do not want to know how many additional changes there are breaking user experience.

Update: Scott stated in the comment section that the patch is controversial in the Kubuntu community and it has not yet been decided if the patch will be shipped.

So to me this is the end. It’s time to part from Kubuntu after four years of usage as I cannot say any more that it is a good KDE distribution and satisfies my needs. I won’t update to Karmic and instead will install a different distribution. I do not yet know which one I will choose, maybe I return to openSUSE, maybe I will use Debian testing/unstable or switch to Gentoo. Probably Debian will win as I do not want to learn a different packaging system.