Google Chrome OS: ein Angriff auf FLOSS

Google hat ja bekanntlich ein neues Netbook Betriebssystem angekündigt. Ich sehe dieses als größte Gefahr für FLOSS der letzten Jahre und ich hoffe und wünsche mir, dass es kein Erfolg wird. Der einzigen anderen Firma, der ich bisher nicht Erfolg gewünscht habe ist der Riese aus Redmond. Ich habe jetzt so sehr Angst vor Chrome, dass ich selbst mit dem Teufel, in Form von MS, paktieren würde, um dieses neue Betriebssystem zu bekämpfen.

Nun woher kommt diese Abneigung gegen Chrome OS? Laut der Ankündigung ist es doch Open Source. Also alles in Ordnung, warum sollte Open Source ein Angriff auf Open Source sein?

Nun allein die Ankündigung, dass es Open Source ist, ist ja schon der erste Punkt. Von Lizenz wurde noch nichts gesagt. Warum nicht freie Software? Ich gehe hier mal vom schlimmsten aus und denke es wird eine recht unhandliche Lizenz.

So schauen wir uns doch mal ein paar Schmankerl aus der Ankündigung an:

The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.

D.h. Chrome OS wird nicht mehr sein als ein Browser. Alle Anwendungen laufen im Web. Nun ist es ja toll, dass Chrome OS komplett Open Source ist. Aber die Anwendungen, die man nutzt laufen auf Servern, nicht auf dem Gerät. Kann man da noch von Open Source sprechen? Wer hat schon den Code von GMail gesehen?

Wer Chrome OS benutzt, wird nicht nur seine Daten an Google geben, sondern auch die Berechnungen auslagern. Das Gerät wird ohne Internetzugang so gut wie unbenutzbar sein. Google ist schon eine Datenkrake, aber man muss sich bewusst machen, welche Daten sie mit Chrome OS in der Hand haben. Sie werden alles wissen. Sie werden wissen wie genau der Workflow aussieht, sie werden einen kontrollieren. 1984 – here we come. Ich hätte nie gedacht, dass der Angriff auf die Privatspähre in dieser Form nicht vom Staat ausgeht. Ganz klar: Stasi 2.0 ist Kindergarten dagegen.

Nun denn, der Leser mag sich denken: hey ich benutze doch die Webanwendungen gar nicht. Ich installiere einfach meine übliche Software und gut ist. Ist ja Linux – Chrome OS ist nichts mehr als eine weitere Distri. Tja leider nicht:

The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel.

Das entscheidende ist hierbei “a new windowing system” – es wird nicht X11 eingesetzt. Ach ja nicht weiter schlimm, X11 ist alt und verursacht viele Probleme. Ich plage mich tagtäglich damit rum. Aber es bedeutet viel mehr. All unsere freien Anwendungen verwenden X11. Keine GNOME/KDE/$DE Anwendung wird auf Chrome OS lauffähig sein. GTK+ und Qt müssten zuerst portiert werden. Window Manager wie KWin/Compiz/Mutter sind eng an die X11 Plattform angepasst und sind kaum portable. Diese sind nicht geschrieben worden mit dem Gedanken an andere Plattformen. Das heißt eine andere Benutzeroberfläche wäre nicht startbar, selbst wenn es jemand schaffen würde die Toolkits zu portieren.

Nun kommen wir dabei gleich zum nächsten Problem. Google spricht von einer simplen Architektur und nennt das Betriebssystem “lightweight”. Für mich bedeutet das, dass das windowing system so designt ist, dass es nur eine Anwendung ausführen kann: Chrome. Und wenn wir uns das Design vom Webbrowser Chrome anschauen, so stellen wir fest: hey das ist ja schon ein windowing system. Es hat eine Architektur, die pro Tab einen eigenen Prozess hat. Möchte man dies gut unter X11 erstellen, läuft es darauf hinaus, dass es ein eigenes Windowing System wird – vermute ich zumindest. Chrome scheint für mich bereits das komplette Windowing system zu integrieren.

Es gibt noch etwas was mir Angst macht: die Tatsache, dass die Ankündigung für Chrome OS während GCDS erfolgte. Google war Sponsor, wusste also, dass der Summit stattfindet. Für mich ist es kein Zufall. Für mich ist es ein Zeichen Googles, dass sie KDE und GNOME als überflüssig ansehen: “Lasst die mal diskutieren – hier das ist die Zukunft”. Ein sehr beängstigendes Zeichen.

Fassen wir zusammen: Chrome OS wird es unmöglich machen für existierende freie Software auf der Plattform zu laufen. Zusätzlich wird die komplette Berechnung auf die Server in Mountain View verlagert. Der Quellcode der Präsentationsschicht wird zwar freigegeben – ist aber recht wertlos. Es ist nur die Präsentationsschicht.

Ach und da ist noch ein anderes Problemchen: hat Chrome OS Erfolg, nimmt es unseren Marktanteil weg. Windows und Mac OS werden davon nicht wirklich beeinträchtigt werden. Für uns ist es aber eine Gefahr.

Hat Chrome OS keinen Erfolg, so steht FLOSS ziemlich schlecht da. Wir werden verspottet werden und es wird heißen, dass man mit freier Software und Linux doch keinen Erfolg haben kann. Dass das Produkt, was Google ausliefert, nichts mit dem existierenden FLOSS Stack zu tun hat, ist dann irrelevant. Egal wie, wir sind die Verlierer.

Chrome ist für mich eine riesige Gefahr und wir müssen gemeinsam den Leuten klar machen, was es bedeutet, wenn dieses “Betriebssystem” Erfolg hat. Niemand sollte es benutzen. Die Leute, die sich nicht so gut auskennen, werden den Angriff auf FLOSS nicht verstehen, wir müssen sie mit den Gefahren für sie aufklären. Chrome OS bedeutet die Verlagerung sämtlicher Daten und sämtlicher Berechnungen auf die Server von Google. Man hat keine Privatsphäre mehr. Google weiß alles. Sie wissen wie lange man auf youporn war, wie oft und was man zuvor und danach gemacht hat. Leute macht euch klar: mit Chrome gibt es keine Privatsphäre mehr. Das Verfassungsgericht hat uns letztes Jahr ein tolles neues Grundrecht gegeben. Seid stolz in einem Land zu leben, in dem die Vertraulichkeit informationstechnischer Systeme und die informationelle Selbstbestimmung grundrechtlich geschütz ist. Zerstört es nicht, indem ihr alles an Google gibt. Geben wir freiwillig unseren Schutz auf, schützt uns auch das Verfassungsgericht nicht mehr, wenn die Politik wieder begehrlich ist.

Gran Canaria Desktop Summit – persönliche Zusammenfassung

Die letzte Woche war ich auf dem Gran Canaria Desktop Summit, der erstmalig gemeinsamen Konferenz von GNOME und KDE. Ich muss sagen es hat sich gelohnt und hoffe, dass in Zukunft öfter aKademy und Guadec zusammen stattfinden werden.

Ich war am Freitag in Las Palmas angekommen. Das Wetter war bei weitem nicht so schlimm, wie ich befürchtet hatte – es war richtig angenehm. Der starke Seewind und die Bewölkung machten die Hitze durchaus erträglich. Trotzdem: die Sonne ist gefährlich – das sagt mir zumindest mein Rücken 😉

Am Freitag Abend war das erste Social Event gesponsort von Canonical. Es war somit die erste Möglichkeit die GNOME Leute kennen zu lernen. Wenn man sich so umgeschaut hat, sah man aber, dass die KDE Leute mit den KDE Leuten sprachen, die GNOME Leute mit den GNOME Leuten. War ja irgendwie zu erwarten – man kennt sich halt 😉 Dennoch gab es wohl auch einige Gespräche über die Grenzen hinweg und ich hab ein ausführliches Gespräch mit einem GNOME Shell Entwickler gehabt und Ideen ausgetauscht.

Am Samstag morgen begann die Konferenz – trotz Party am Vorabend gut besucht. Das Konfernzgebäude war einfach gigantisch. Die Mitarbeiter wurden aber wohl nicht richtig darauf vorbereitet, dass eine freie Software Konfernz nicht wie eine normale Konfernz ist. Bei Lightning Talks jeweils neues Wasser und ein Namensschild zum Rednerpult zu bringen ist irgendwie overkill 😉

Die Konferenz wurde von einigen Vertretern von Gran Canaria/Spanien eröffnet. Leider hab ich keine Ahnung was sie uns sagen wollten, da sie auf Spanisch gesprochen hatten. Am Besten war ein Redner der anfing mit “mein Englisch ist nicht wirklich gut, daher halte ich meine Rede auf Spanisch”. Bei schlechtem Englisch hätte ich ja was verstanden, bei Spanisch leider nicht.

Nach der Eröffnung folgten die drei Keynotes. Ich war ja besonders an der Stallman Keynote interessiert. Da er ja zuvor schon auf Mono rumgehackt hatte, hatte ich erwartet, dass er auf die Problematik eingeht. Und ich wurde in dem Punkt nicht enttäuscht: seine ganze Rede ging eingentlich um die Mono Problematik. Die Rede war sehr gut aufgebaut: er begann mit einem Rückblick auf die Qt Problematik und wie es zu GNOME führte. Dass damals die freie Software bedroht war, weil der einzige freie Desktop auf eine unfreie Komponente aufbaute. Er erwähnte auch, dass dieses Problem heute gelöst ist. Mit diesem Rückblick motivierte er die Mono Diskussion: da Microsoft Patente auf C# hat, stellt das Entwickeln in dieser Sprache seiner Meinung nach eine Gefahr dar. Es sei schwer zu sagen an welchem Punkt es gefährlich wird, einzelne Anwendungen sind ok, aber komplett darauf aufzubauen nicht. So könnte man sagen, dass Tomboy ok ist, weil man es problemlos durch Gnote ersetzen kann. Also falls MS jemals auf die Idee kommt die Patente einzusetzen, wäre nichts verloren. Wie sich am Anschluss seiner Diskussion zeigt, kennt er sich jedoch mit der Problematik nicht wirklich aus. Er weiß nicht welche Teile patentiert sind, er weiß nicht in wie weit MS versprochen hat, keine Patente einzusetzen und seine Argumentation dreht sich um den Punkt “MS ist böse, MS hat gesagt sie wollen freie Software zerstören, also dürfen wir keine MS Technologie verwenden”. Auch wenn ich persönlich die gleiche Argumentation für mich folge und daher C# nicht verwenden würde, klingt seine Argumentation in meinen Ohren als FUD. Besonders die Empfehlung Lisp anstatt C# als Sprache zu verwenden, ist nun ja irgendwie weltfremd.

Ich persönlich habe vor der Rede ja auch eine Meinung zu Stallman gehabt und die ist nicht wirklich positiv. Er hat tolles für freie Software geleistet, aber irgendwie glaube ich nicht, dass er heute noch die richtige Person dafür ist. Und leider wurde meine in diesen Punkten ablehnende Haltung bestätigt. Nach seinem Mono Bashing verwandelte er sich in “St. IGNUcius of the Church of Emacs”. Eine meiner Meinung nach sehr peinliche Vorstellung und ich habe mit niemandem gesprochen der dieses gut geheißen hat. Es gab zwar viel Gelächter und Applaus aber irgendwie glaube ich mitlerweile die Leute haben ihn eher ausgelacht als das gutgeheißen. Für mich war dieser Teil der Rede ein “nein ich will nichts mit soetwas zu tun haben”. Da sage ich dann doch lieber ich bin ein Open Source Programmierer und kein Freie Software Programmierer. Ich kann mir nicht vorstellen, dass Microsoft ihn Ernst nimmt, wenn er als “Heiliger” mit Heiligenschein auftritt. Für eine Keynote bei solch einem Ereignis eine sehr schwache Nummer und ich war nicht der einzige, der sich daran störte.

Nach den Keynotes folgten die ersten Talks – zuerst einige Lightning Talks mit zum Teil grandiosen Projekten. Am nächsten Tag begannen die eigentlichen Vorträge, jeweils vier gleichzeitig – ich muss noch einige Videos anschauen. Es wird an doch bedeutend mehr Stellen zusammengearbeitet als ich dachte.

Nachmittags begann dann die eigentliche aKademy mit einer sehr guten Keynote von Glyn Moody. Ein schöner Rückblick wie Freie Software die Welt bereits veränderte. Die folgenden anderthalb Tage war ich also damit beschäftigt mir Talks anzuhören 😉

Am Dienstag war mein freier Tag, da ich nicht im e.V. und somit nicht zur Hauptversammlung gehen konnte. Die Zeit ein bißchen am Strand verbracht und ein bißchen für 4.4 gehackt.

Mittwoch wurde die Konferenz in die außerhalb Las Palmas gelegene Universität verlegt. Obwohl sie erst 20 Jahre alt ist ohne Klimaanlage – recht überraschend. Zumindest war hier das Internet – im Gegensatz zum Konferenzgebäude – top. An jedem Platz Ethernetkabel und Steckdose. Perfekt für Akademy. Die erste BOF session betraf die Umstellung auf git. Der Raum war komplett voll und überhaupt nicht wie ein BOF sein sollte. Es gibt einiges zu tun und es haben sich einige Freiwillige gefunden. Grober Zeitplan bis zum 4.4 Freeze – also wohl noch dieses Jahr 🙂

Am Donnerstag war das wichtige Plasma/KWin Treffen und es wird einiges tolles kommen – ich verrate jetzt mal noch nichts. Wir haben tolle und ehrgeizige Ideen, die wir aber erst noch weiter ausarbeiten müssen.

Am Mittag war der Tourist Trip. Tja Tourist Trip auf Gran Canaria bedeutet wohl nur, man geht an den Strand. Dass wir dazu mit dem Bus zum Süden der Insel fahren mussten, verstehe ich nicht wirklich – schönen Strand gab es auch in Las Palmas. Am Abend ging es für mich dann zum Flughafen, da ich einen Nachtflug hatte (wie konnte ich nur so blöd sein – ich weiß doch dass ich im Flugzeug nicht schlafen kann).

Insgesamt war es eine richtig tolle Woche und ich freue mich schon auf die aKademy nächstes Jahr. Die Community ist einfach richtig toll und es macht super Spaß in ihr zu arbeiten. Auch mit den GNOME Leuten war es eine sehr angenehme Erfahrung – aber man sieht doch Unterschiede. Mir kam es eigentlich die ganze Woche so vor, als ob mehr KDE Leute anwesend waren. Vermutlich ein rein subjektives Wahrnemen, da wir alle beim Social Event das Kubuntu T-Shirt angezogen haben und bei den Vorträgen unsere Laptops benutzten und man daher überall nur KDE sah.

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.