Cube Gears

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

How to secure your email address correctly on the web

This is a follow-up post to my yesterdays post that obfuscating an email address does not work and is useless. Many comments on the blog post stated that they think that obfuscation helps because the bots are not interested in the obfuscated email addresses.

So let’s recap: we use obfuscation to prevent spam bots from harvesting email addresses. So we obfuscate in a way that

  • Humans are able to read the email address
  • Computers are not able to read the email address

That sounds like a CAPTCHA. If you don’t know the do’s and dont’s of CAPTCHAs I recommend to read the information on captcha.net. One of the most important facts is that you shouldn’t use a CAPTCHA which will break as soon as everybody uses it. That is in the moment the bots start to support it.

Now let’s get back to the obfuscated email addresses. I think we can agree that the obfuscation is conceptually broken. I think we can compare it with cryptography: even that there is no real usecase to attack MD5, nobody would use it to digitally sign important documents any more.

As soon as the harvesters start to search for obfuscated addresses they will find them. If you obfuscate an email address on the web today and in five years the harvesters start to unobfuscate addresses they will find your address. Bad luck.

So instead of using a broken CAPTCHA like obfuscation we should use a secure CAPTCHA like the Mailhide service provided by reCAPTCHA. There are plugins for many programming languages and it can be used to e.g. automatically replace all email addresses in a Mailman archive with a link to the CAPTCHA. It looks like that: jsm@example.com

And solving reCAPTCHAs is mostly much easier than solving the normal CAPTCHAs as you have a complete word and it is probably much easier than solving some obscure obfuscation rule and it helps to digitize books and newspapers and in the end you get a link to click on.

So I know, that you will say “reCAPTCHA belongs to Google and Google is evil. I don’t want Google to give them my email address”. If you think that, rethink. You think that the world’s biggest web harvester is unable to break your used obfuscation? You have never ever sent an email to a gmail/googlemail account? You don’t use Jabber with Google Talk users? You do not have a Google account? Do you really think that Google doesn’t already know your email address? And if you really don’t trust reCAPTCHA, you could still use scr.im to get a tiny, CAPTCHA protected URL. But I recommend to use a well tested CAPTCHA system.

To summary: I agree that you should secure your email addresses on websites. But please do yourself the favor and do it properly. Obfuscation is broken and it is only a matter of time till harvesters start to harvest the email addresses. There are services which provide a secure CAPTCHA to protect email addresses. Please use those. And no this is not an advertisement campaign for reCAPTCHA – it is just the best CAPTCHA service I know. If you know a better and more secure which doesn’t belong to Google, please leave a note 🙂

About obfuscating email addresses

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.

Picasaweb

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.

Why distributions shouldn’t ship development versions

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.

Quick tiling and TabBox updates

During the last weeks quite some work has gone into KWin, which is great and needs to be mentioned here. First of all a big thanks to Hugo Pereira for his work on Nitrogen. You might have heard that we imported Nitrogen from kde-look.org to replace Ozone. Lots of work and realy great improvements has gone into it and it’s just awesome that we can provide the two highest rated window decorations from kde-look in the next KDE release. If you want to see some screenshots have a look at the web gallery. I hope we will finally merge Nitrogen back into Oxygen and only provide one decoration.

As already mentioned in the dot story I worked on a feature known as “Aero Snap” during Tokamak. (Btw. big thanks to Mario for the great event and thanks to the Plasma crew for the invitation. You are a great group of people 😀 And I hope I will find the time to go to next Tokamak.) Currently a new contributor, Robin, is working on adding keybindings to quick tiling, so it will rock even more. It’s difficult to show it in a screenshot, but here it is:

Von KWin

Finally (un)loading effects does not result in flicker any more. This is a real improvement but it feels strange when you are used to the flicker as indication that the changes were successfully applied. The fix will be backported to 4.3.2 and thanks a lot to Robin for the help on that one.

One of the biggest changes for 4.4 so far is the new TabBox which has been merged into trunk today. I already blogged about it but some things have been improved since last time. It’s now possible to have two independent switchers with different shortcuts. So you can have for example alt+tab with windows from all desktops and meta+tab with windows only from current desktop. It’s also possible to assign different effects to the two switchers which allows to use both the “normal” TabBox as well as a fancy switcher (when effects are disabled it will of course fall back to the normal switcher). Most improvements went into the classic switcher so far, but some will be implemented in the effects as well. E.g. switching with cursor keys might be useful if you use Present Windows. One of the nice new features is that you can close a window with middle click on the entry in the list.

Since my last blog post I improved the KCM as well. The layout bits were moved into an own dialog with a live preview (sorry for the black border, it worked correctly yesterday evening):

Von TabBox
Von TabBox

TabBox NG

I’m currently working on the TabBox “Next Generation”. For those who do not know, what the TabBox is: it is the list view shown when using Alt+Tab and can display the windows or desktops (in static or most recently used order). It is also possible to replace the list view by a KWin effect.

This new implementation is the second part of my rework for alt+tab. The first is already implemented and available as a window runner so KRunner also lists your open windows and you can even interact with them, like closing, minimizing, etc.

In KDE 4.3 the classical TabBox already received a nice facelifting and looks integrated into the Workspace. So why working on a new implementation? Well to answer that I will present a list of the new features:

  • If the list doesn’t fit on the screen items are not cut off, but the view scrolls
  • Mouse wheel scrolls the list
  • User can choose if the items are laid out vertical, horizontal or tabular
  • Navigating with left/right/up/down keys – useful for tabular layout and for present windows
  • Model for clients and for desktops; adding new switching modes just requires to write a model and the delegate. (That could become useful when we integrate Plasma activities – more after Tokamak)
  • Static and most recently used desktop switching is just a different sort mode in the model
  • Optional Integration of highlight windows effect
  • Outline can be turned off
  • Disabling the view does not break the behaviour
  • And last but not least: Completely configurable item layout. That is the user can choose between some predefined layouts like an informative, a compact, small icons only, big icons only, text only and can define custom layouts. In combination with the view layout configuration you can build a TabBox which looks like the MacOS or the Windows XP without any problems.

So I can talk a lot but there is no better thing than a video, showing the new features:

Download ogg video

There are some things I still have to do:

  • Config interface for the item layouts
  • Layouts for desktop items
  • A second optional view for showing just the selected item – needed for icon only mode to show the text of selected item (that is the MacOS style 😉 )
  • Adding a secondary TabBox with own shortcuts and own settings, so that you can have a TabBox for e.g. only clients on current desktop and another one for clients on all desktops

I hope to get it into a state for review when Tokamak starts as I will go by train and have lots of time for working on it.

And if you never understood why your focus policy destroyed your alt+tab behaviour: have a look at this screenshot.

Von TabBox

Get Hot New Stuff support in Aurorae

Thanks to Frank Karlitschek there is a category for Aurorae themes on kde-look.org. He also added a GHNS provider and of course I already implemented it and updated the Aurorae version. Here the obligatory screenshot:

Von Aurorae

There are many themes already available for Aurorae and that’s awesome. I just want to say thanks to everybody who designed a theme. Some are really great looking and working nicely together with a Plasma theme. That’s exactly what I wanted to achieve. Have a look for example at the Gaia 09 theme. It’s really great to see so many users picking up the theme engine although it was quite difficult to use as it has a 4.3 requirement (well that problem is solved since yesterday).

How to write a KWin effect

This blog post has been in my drafts folder for weeks and I just thought it’s time to publish it – ready for Akademy 🙂 And if somebody is really interested we could have a BOF session at Akademy. I think Plasma devs want us to write a slide effect to replace their custom popup animation. That would be a perfect example to get your hands dirty.

I wrote a new Kwin effect and thought this is the ideal effect for writing a small howto. It is an effect which helps resizing windows by colouring the changed geometry. I was told that resizing is not optimal in KWin, that is if the window content is shown while resizing it is slow and if the window content is not shown it is ugly. This effect should fill the gap. Unfortunately the current code will only work with the slow show window content while resizing (the API has to be changed). Nevertheless I decided to show the code in this tutorial.

Von KWin

The effect has been committed to trunk. So you can have a look at it and if you’re running trunk you can even try it. The effect which we will write has the name “Resize”. It will support both backends: XRender and OpenGL. Each effect has an own directory in kwin/effects so we create a new directory resize. There we create the following files:

  • CMakeLists.txt
  • resize.h
  • resize.cpp
  • resize.desktop

We have to include this directory into the build, so we edit the CMakeLists.txt in the effects directory. We just add the following line to the section marked as “Common effects”:

include( resize/CMakeLists.txt )

If it were an OpenGL only effect we would place this line in the section marked as “OpenGL-specific effects”.

So at this point we are finished with the preparation. So let’s start looking at the files. First the desktop file:

[Desktop Entry]
Name=Resize Window
Icon=preferences-system-windows-effect-resize
Comment=Effect to outline geometry while resizing a window

Type=Service
X-KDE-ServiceTypes=KWin/Effect
X-KDE-PluginInfo-Author=Martin Gräßlin
X-KDE-PluginInfo-Email=kde@martin-graesslin.com
X-KDE-PluginInfo-Name=kwin4_effect_resize
X-KDE-PluginInfo-Version=0.1.0
X-KDE-PluginInfo-Category=Window Management
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=false
X-KDE-Library=kwin4_effect_builtins
X-KDE-Ordering=60

Most of it is self explaining and just needed for the “All effects” tab in the compositing kcm. The most important value is the “X-KDE-PluginInfo-Name”. This is the name used to load the effect and has to start with “kwin4_effect_” followed by your custom effect name. This last part will be needed in the source code.

Each effect is a subclass of class Effect defined in kwineffects.h and implements some of the virtual methods provided by Effect. There are methods for almost everything the window manager does. So by implementing those methods you can react on change of desktop or on opened/closed windows. In this effect we are interested in resize events so we have to implement method “windowUserMovedResized( EffectWindow *w, bool first, bool last )”. This method is called whenever a user moves or resizes the given window. The two boolean values indicate if it is the first, last or an intermediate resize event.

But there are more methods we have to implement. The effect should paint the changed geometry while resizing. So we have to implement the methods required for custom painting. KWin’s painting pass consists of three stages:

  1. pre paint
  2. paint
  3. post paint

These stages are executed once for the complete screen and once for every window. All effects are chained and each effect calls the stage for the next effect. How this works we will see when looking at the implementation. You can find a good documentation in the comments of scene.cpp

Now it’s time to have a look at the header file:

#ifndef KWIN_RESIZE_H
#define KWIN_RESIZE_H

#include <kwineffects.h>

namespace KWin
{

class ResizeEffect
    : public Effect
    {
    public:
        ResizeEffect();
        ~ResizeEffect();
        virtual void prePaintScreen( ScreenPrePaintData& data, int time );
        virtual void paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data );
        virtual void windowUserMovedResized( EffectWindow *w, bool first, bool last );

    private:
        bool m_active;
        EffectWindow* m_resizeWindow;
        QRegion m_originalWindowRect;
    };

}

#endif

We see that there are three member variables. The boolean is used to indicate if there is a window being resized, that is if we have to do some painting. The EffectWindow is a pointer on the window being resized and the QRegion stores the windows’s geometry before the start of resizing.

So now we can have a look at the implementation. I will split the code in small parts and explain the code. So first let’s look at the includes:

#include "resize.h"

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
#include <GL/gl.h>
#endif                                               
#ifdef KWIN_HAVE_XRENDER_COMPOSITING                 
#include <X11/Xlib.h>
#include <X11/extensions/Xrender.h>
#endif                                                                

#include <KColorScheme>

As our effect should support both XRender and OpenGL we have to include the headers for both. As it is possible that the effect is compiled on a system which does not support one of both we use ifdef. We can be sure that at least one of both is available or the effects wouldn’t be compiled at all. If you write an OpenGL only effect you do not have to bother about such things. Also if you only use KWin’s high level API you don’t need to include those headers. But we want to paint on the screen using OpenGL or XRender directly.

So let’s have a look at the next part:

namespace KWin
{                    

KWIN_EFFECT( resize, ResizeEffect )                                                                                                                                                            

ResizeEffect::ResizeEffect()
    : m_active( false )                                                                                                                                    
    , m_resizeWindow( 0 )                                                                                                                                         
    {                                                                                                                           
    reconfigure( ReconfigureAll );                             
    }                                                                                                                           

ResizeEffect::~ResizeEffect()
    {                                                                                         
    }

Here we see the use of a macro. This has to be included or your effect will not load (it took me ten minutes to notice I forgot to add this line). The first value is the second part of X-KDE-PluginInfo-Name – I told you we will need it again. The second value is the class name. Following is constructor and deconstructor.

So let’s look at the pre paint screen stage:

void ResizeEffect::prePaintScreen( ScreenPrePaintData& data, int time )
    {                                                                                                                           
    if( m_active )                                             
        {                                                                                                                       
        data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;           
        }                                                                                                                       
    effects->prePaintScreen( data, time );                                                                                                                     
    }

Here we extend the mask to say that we paint the screen with transformed windows when the effect is active. That’s not completely true – we don’t transform a window. But this flag indicates that the complete screen will be repainted, so we eliminate the risk of artefacts. We could also track the parts which have to be repainted manually but this would probably be more work for the CPU than the complete repaint for the GPU. At this point we see the chaining for the first time. The effects->prePaintScreen( data, time ); will call the next effect in the chain. effects is a pointer on the EffectsHandler and a very useful helper.

So now we start looking at the heart of the effect:

void ResizeEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data )              
    {                                                                                                                           
    effects->paintWindow( w, mask, region, data );                                                   
    if( m_active && w == m_resizeWindow )                                                                                                                 
        {                                                                                                                       
        QRegion intersection = m_originalWindowRect.intersected( w->geometry() );                                                                                                                
        QRegion paintRegion = m_originalWindowRect.united( w->geometry() ).subtracted( intersection );                                                                                                                                                          
        float alpha = 0.8f;                                                                                                                                              
        QColor color = KColorScheme( QPalette::Normal, KColorScheme::Selection ).background().color();

We first continue the paint window effect chain – this will paint the window on the screen. Now we check if we are in resizing mode (m_active) and if the currently painted window is the window which is repainted. In that case we calculate the region which has to be painted. We just subtract the intersection of current geometry with saved geometry from the union of those two. The next two lines are for the color definition. We use the background color of a selection with 80 % opacity.

Now we have to do a little bit OpenGL. In most effects where you just transform windows you don’t have to write OpenGL at all. There is a nice high level API which allows you to translate, scale and rotate windows or the complete screen. Also transforming single quads can be completely done without knowing anything about OpenGL.

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
        if( effects->compositingType() == OpenGLCompositing)                                  
            {                                                                                                                   
            glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT );                                                                                                                                    
            glEnable( GL_BLEND );                              
            glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );                                                                                                                               
            glColor4f( color.red() / 255.0f, color.green() / 255.0f, color.blue() / 255.0f, alpha );                                                                                                                      
            glBegin( GL_QUADS );                               
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                {                                                                                                               
                glVertex2i( r.x(), r.y() );                                                                                                                                                  
                glVertex2i( r.x() + r.width(), r.y() );           
                glVertex2i( r.x() + r.width(), r.y() + r.height() );                                
                glVertex2i( r.x(), r.y() + r.height() );          
                }                                                                                                               
            glEnd();                                                                        
            glPopAttrib();                                                                  
            }                                                                                                                   
#endif

We check if KWin uses OpenGL as a backend. We enable blending in the OpenGL state machine (needed to have translucent colors) and set the color for our rects. OpenGL clamps colors in the range [0,1] that’s why we can’t use the values from QColor directly. Last but not least we just paint one quads for each rect of our regin.

Now just the XRender part is missing. This part is taken from show paint effect – I don’t know anything about XRender 😉

#ifdef KWIN_HAVE_XRENDER_COMPOSITING
        if( effects->compositingType() == XRenderCompositing)                                 
            {                                                                                                                   
            XRenderColor col;                                                                      
            col.alpha = int( alpha * 0xffff );                                                                 
            col.red = int( alpha * 0xffff * color.red() / 255 );                       
            col.green = int( alpha * 0xffff * color.green() / 255 );                   
            col.blue= int( alpha * 0xffff * color.blue() / 255 );                      
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                XRenderFillRectangle( display(), PictOpOver, effects->xrenderBufferPicture(),                                                                                                                          
                    &col, r.x(), r.y(), r.width(), r.height());
            }
#endif
        }
    }

This does the same as the OpenGL part just with XRender.

Last but not least we have to track the window resizing:

void ResizeEffect::windowUserMovedResized( EffectWindow* w, bool first, bool last )
    {
    if( first && last )
        {
        // not interested in maximized
        return;
        }
    if( first && w->isUserResize() && !w->isUserMove() )
        {
        m_active = true;
        m_resizeWindow = w;
        m_originalWindowRect = w->geometry();
        w->addRepaintFull();
        }
    if( m_active && w == m_resizeWindow && last )
        {
        m_active = false;
        m_resizeWindow = NULL;
        effects->addRepaintFull();
        }
    }

} // namespace

So and that’s all. When a resize event is started we activate the effect and trigger a repaint of the window (probably not needed, but doesn’t hurt). And when the resizing is finished we deactivate the effect and trigger another repaint of the complete screen just to make sure that there are no artefacts left.

The CMakeLists.txt could just be taken from any other effect and be adjusted. So here’s the example:

#######################################
# Effect

# Source files
set( kwin4_effect_builtins_sources ${kwin4_effect_builtins_sources}
    resize/resize.cpp
    )

# .desktop files
install( FILES
    resize/resize.desktop
    DESTINATION ${SERVICES_INSTALL_DIR}/kwin )

#######################################
# Config

Now you can compile and try your new effect.

A new KWin window decoration theme engine

I started to work on a new theme engine for window decoration. The goal is to make deco themes as easy as Plasma themes. So it’s using Plasma technologies, that is FrameSvg 😉 Well here is a screenshot of current state:

Von KWin

The decoration background is based on Air’s translucent background and the icons… well you see I’m not an artist. And there is only a minimize and a close button. As you can see it uses KWin’s new ARGB decoration and the theme paints it’s own shadows. The engine does not yet really support opaque decorations that’s one of the left todos. But it’s thought with ARGB decos in mind 🙂

Currently two things are still missing: a name and example themes. So if you have ideas for names please leave a comment and if you are interested in creating a theme, please contact me.

Ah I have not yet committed any code into SVN, but you will soon find the engine in playground. There are some blockers (like the name) which have to be fixed before I want to share the code.

Some not so wobbly news from wobblyland

Long time no post on what has changed in KWin lately. So I’m going to show you some new features.

There has been some work going on to improve the tabbox (alt+tab) when no effect is used. Andreas Pakulat added an outline for the currently selected window like it was in KDE 3 time. Very nice and usefuel – thanks a lot. The tabbox has received some face lifting and uses the Plasma style. On that part I want to thank Nuno for his great help on making the whole thing nice. Adding some pixels here and there – I could not have done it.

Well nothing is as good as a screenshot:

Plasma styled tabbox with outline
Plasma styled tabbox with outline

But that’s not the only thing which has improved. Some might have noticed that they activated an effect but it just doesn’t work. This can have different reasons: you want to activate an OpenGL only effect and you are using XRender or the effect requires OpenGL shaders and your hardware or driver does not support shaders. To solve this problem the best solution would be to deactivate the not supported effects in the plugin selection, but that’s not possible as you can change the effects if compositing is suspended or deactivated. So testing if OpenGL is used does not work and we cannot deactivate the effects in the UI.

To give some feedback to the user a notification is shown when you change effects and you have selected a not supported effect. It just checks which effects are loaded and which effects are selected when you change your settings.

Notification for not supported effects
Notification for not supported effects

We also added a D-Bus method toggleCompositing to suspend/resume compositing. This is already used by PowerDevil when the option to disable Compositing is set. In that case another notification is shown, telling you the shortcut to resume compositing. So if you are the author of an application which you know performs badly with compositing (I have heard there are some drivers which don’t like you to play videos when compositing is enabled – should be solved with DRI2) you can automatically suspend compositing.

And last but not least there is a new on-screen-display which is shown when you change the desktop. It’s Plasma styled as well and looks very much like the pager. It highlights the new desktop and arrows from the old desktop to the new desktop are shown. Please don’t tell me that this is just a copy from Mac OS – of course it is inspired. But this one is better. Ever looked at the Mac OS spaces OSD? Does it look like the other parts of the workspace? No it doesn’t. Our OSD uses the workspace style, so it’s better integrated 🙂

This OSD replaces the old popup info. So you just have to check the “Show desktop name on change” option to receive this OSD. If you want to keep the old just name option: please leave a note. If there is need for it I will add an option to select between OSD and only desktop name.

Desktop change OSD
Desktop change OSD

And as an image can’t show the dynamic animations (Plasma has really great stuff for that) here’s the video (Link for planet reader):