KWin runs on OpenGL ES

Last weekend I could announce that KWin compiles with OpenGL ES headers. This weekend I was able to proceed even more: I got the first windows composited using OpenGL ES 2.0. Not everything is working and there is still lot’s of work to be done and it has not yet been tried on actual devices (yes you can use OpenGL ES on a desktop), but nevertheless it’s a very important step.

As it just looks like normal desktop compositing with rendering artefacts, I don’t show a screenshot. This has to wait till Present Windows (or preferable Cube) works on a mobile device ­čÖé

I think it is important to give some credits to those who helped me directly or indirectly:

  • Fredrik for providing a nice example application showing how texture from pixmap works on OpenGL ES and for all the help on IRC
  • Mesa/Gallium for providing ES libraries for desktop systems
  • Nouveau for making it possible to use ES on my notebook. Without Nouveau it would have been very difficult to do any testing on ES.
  • Debian for packaging Nouveau with 3D support in the experimental repository
  • Linaro for investigating about the possibilities for texture from pixmap on OpenGL ES
  • Addison Wesley for donating a copy of the fifth edition of the OpenGL SuperBible. Really a great help if you want to develop for the core profile.
  • Marco and Alexis for nagging about missing ES support
  • Marco for promising to trying out the patches on actual devices

It is incredible how clean the ES code looks compared to the glx backend. I’m really looking forward to be able to drop the legacy OpenGL code and I hope to have the ES port in a state that users can use it as a runtime replacement on desktop systems as well. It would be nice to provide users a modern compositing backend.

Powered by Blogilo

KWin compiles for OpenGL ES

While others are having fun at the KDE Mobile Sprint in Berlin, I am at home and hacking on KWin mobile and could achieve a huge milestone today: KWin compiles for OpenGL ES 2!

This does not yet mean that you can run KWin on an ES powered MeeGo device, it just means that it compiles. There is still lots of work to be done, so there is no compositing code at all. The code for binding textures from pixmap or performing the actual painting is completely disabled. It’s lots of ifdefs currently and that has to be cleaned up first.

Of course nothing of it will hit 4.6, it’s all 4.7 material and the code lives only in my private git branch. Nevertheless if anybody is interested in the code I can provide the diff (or complain loud enough so that we need git :-P).

The impact to the codebase is not as bad as I feared. After dropping the idea of going to OpenGL ES 1.1 first and writing the required shader for the desktop edition, the changes are rather small. In most cases it’s just a huge set of legacy drawing commands which can be easily removed.

Oh and currently all effects are removed from the build as my shader does not yet support the required transformations and many effects use legacy code, which would be too much work to get it compiling in the current state. We will have to see which effects we want on a mobile profile and enable the build of just those (e.g. Present Windows).

So the next steps are setting up a build environment where I actually can test the stuff. KDE Mobile team: I need your help!

Powered by Blogilo

Debugging Rendering Code visuell

Ich bin aktuell dabei den Rendering Code von KWin neuzuschreiben f├╝r OpenGL ES und auch OpenGL 3. Das stellt einen nat├╝rlich vor Probleme: wie ├╝berpr├╝ft man, dass der neue Code ausgef├╝hrt wird und, dass der alte noch funktioniert?

Der neue Zeichen Code verwendet nun einen Shader – hier ist es einfach einen Test einzubauen. Aktuell f├Ąrbe ich einfach alle Pixel gr├╝n ein, wenn der Shader verwendet wird. Somit sieht man sehr leicht, welche Bereiche den neuen Pfad verwenden. Neben dem eigentlichen Zeichnen, ist es auch noch interessant zu sehen wie die Geometrie aussieht, die da eigentlich gerendert wird. Vor einiger Zeit hatte mir ein Compiz Entwickler einen Screenshot gezeigt, wo das zu sehen war und ich dachte mir, irgendwie n├╝tzlich. Heute abend hab ich es mal schnell eingebaut.

Ich lese zur Zeit die f├╝nfte Auflage der OpenGL SuperBible (dazu mehr mal in einem anderen Post) und zwar von vorne ohne gr├Â├čere Grundlagenbereiche auszulassen. Somit bin ich heute auf eine Stelle gestossen, die beschreibt wie das geht. Nat├╝rlich kannte ich die Technik schon, nur ich hatte nicht daran gedacht. Beim Lesen dachte ich mir: ach das war doch das was Compiz auch hat, w├Ąre ganz n├╝tzlich einzubauen. Das sieht dann insgesamt eigentlich schon sehr h├Ą├člich aus ­čśë

Debug OpenGL rendering
Debug OpenGL rendering

Was man sehr sch├Ân sieht, ist wie gro├č der Schatten der Fensterdekoration doch ist.. Den debug Modus kann man in Zukunft ├╝ber die Umgebungsvariable KWIN_GL_DEBUG aktivieren. Da wir ja schon im Feature Freeze sind, sprechen wir hier von 4.7 im Juli 2011. Wer trotzdem den Bildschirm bunt sehen will, kann ja den Show Paint Effekt verwenden.

Powered by Blogilo

Multihead KWin needs YOU!

Aaron wrote a nice blog post about multihead in Plasma and mentions that "there are still some KWin issues" and he is right. I don’t expect these issues to go away in the foreseeable future. Multihead in KWin is unmaintained as long as I have been developing for KWin and considering the rather small amount of bug reports we get for multihead it seems to be not worth spending time on it. Sorry.

So if anybody wants to use multihead and thinks that he needs multihead (multi-screen and multi-seat are working fine), he would have to sit down and investigate what is working/missing in KWin. I assume that it is not much which needs to be changed – probably working around the Kephal issue mentioned in Aaron’s blog.

So if you test on the Plasma desktop changes, please also have a look into what’s missing in KWin and report it to bug 256242 (it incorrectly mentions multi-screen in the title).

Powered by Blogilo

Going down the programmable pipeline road

As you might know OpenGL comes in two flavors: fixed functionality and programmable pipeline. With the fixed functionality you have to use API calls to influence the execution of each stage of the rendering pipeline. It is a very powerful API allowing you to do most of the stuff we use in KWin. The programmable pipeline allows to directly execute code (called a "Shader") to do vertex and fragment processing. For example we are able to saturate a complete window as a whole with fixed functionality, but we need a fragment shader to be able to change the color of each pixel depending on the input color. This is for example used in the invert effect. A vertex shader can be used to influence the geometry. E.g. we could use it to transform a cube into a sphere. OpenGL 1.x is completely fixed functionality, in OpenGL 2 the programmable pipeline was introduced to exchange parts of the rendering stack, but fixed functionality was still around. With OpenGL 3 everyone expected the fixed functionality to be removed, but it was only deprecated and you can still use it. All the modern calls have been moved into a "core profile".

KWin uses OpenGL 2, that is most of our code is fixed functionality as it was around with OpenGL 1, but we can use shaders to exchange parts of the rendering pipeline to e.g. invert a window. As our shaders are used to emulate fixed functionality the code they use is mostly deprecated as well, KWin does not yet use the core profile.

To make it all more complicated there is also an OpenGL version for Embedded Systems (ES/EGL), which also comes in a flavor for fixed functionality (1.1) and programmable pipeline (2.0). In opposite to the desktop version of OpenGL, the ES version does not include the fixed functionality API calls in ES 2. This means that our source code cannot be compiled directly for ES.

Up to now I only blogged about that I want to port KWin to ES. I started working on it and in 4.6 there is some code already which was written to ease the porting effort. The rendering code has been partly split into legacy painting and modern painting, which makes it easier to just #ifdef away the unsupported calls when compiling for mobile. My initial plan was to first port KWin to ES 1.1 as the code base is closer to 1.1 than to 2.0. The work on it is quite boring and basically stalled. So I decided that this is no solution and instead want to add a core profile compatible rendering path to KWin – this would work both with OpenGL 3 and OpenGL ES 2. Of course no existing code will be removed and most likely it will become opt-in as I expect the changes to break some current effects when using the core profile (at least I can see that cube is partly broken in my special kwin version I’m running here).

With the feature freeze for 4.6 behind us, it’s the perfect time to play around with a new rendering path as it can mature on my systems before it is made available to a broader developer testing. So yesterday I set down and implemented a core profile compatible shader for basic rendering without transformations. This is to be used when no effect is active and only parts of the screen need to be repainted (visible with show paint effect). The first results of this change look promising as our EffectFrame overlays can already be rendered with this new coding path. I would like to present a screenshot, but it is boring as it just looks as always. If you want beautiful pictures, go to Nuno’s blog ­čśë As soon as the window rendering is also based on this new shader I have a base to use it in the ES porting. Luckily I can reuse the work I spent for porting to ES 1.1, as the same code has to be removed there. So the initial version for mobile will be based on this code and by that just support basic compositing of windows without any effects as those might do transformations or use own GL calls, which have to be ported, too.

Unfortunately the state of the OpenGL API with all the deprecated function calls make it unnecessary difficult to port to the core profile. When passing the geometry to the graphics card we have to either use the legacy code path (for OpenGL 1) or a modern one. Now the modern one we already have, is also deprecated and the code path which has to be used with the core profile and core shaders is incompatible with our existing shaders replacing fixed functionality and the no shader case (but not legacy). Changing all shaders is a lot of work without any gain and the risk to break them. This means that the easy check based on is a shader used, is impossible to decide which code path to use and we have to introduce states into our rendering code to decide which path to use.

These changes will allow us to optionally use OpenGL 3 in KWin. I would like to have at least one effect using a geometry shader in 4.7. And it is required to get KWin on OpenGL ES 2. While that used to be a nice to have feature with a low priority up to now, it looks like it will become very important in the future as Wayland requires ES. This is a very sane decision by the wayland developers. As everybody is writing about wayland nowadays I had to mention it at least once ­čśŤ I am very interested in the topic and hope that it will happen.

And now to something completely different: There is an old saying that something didn’t happen, till you blogged about it. So… Lubos stepped down as KWin Maintainer this week and asked me to become the new Maintainer. I want to thank Lubos for the long time as maintainer and all the work he has done for KWin to make it the extraordinary window manager it is today.

Powered by Blogilo

Interessante Zeiten liegen vor uns

In der Nacht auf den heutigen Freitag war der gro├če Freeze f├╝r die KDE Plattform, Workspaces und Application Releases in Version 4.6. D.h. es d├╝rfen keine neuen Features eingespielt werden und keine ├änderung an Texten vorgenommen werden. Die KDE Entwickler Community wird sich nun ganz auf das Stabilisieren und Bugfixing konzentrieren bis zum Release Ende Januar. Die erste Beta Version wird bereits am 24.November erscheinen.

Wie man sich vorstellen kann, war der gestrige Abend noch etwas stressig. Code wollte noch geschrieben werden (sonst m├╝ssten die User noch ein halbes Jahr auf ein Feature warten), Review Requests angeschaut, getestet und kommentiert werden und so weiter. Zum Gl├╝ck ist das Release Team nicht ganz so streng was das Einhalten der Frist angeht und so hat ein KWin Entwickler heute morgen um halb sieben noch einen Commit eingespielt ­čśë

F├╝r mich war der 4.6 Entwicklungszyklus auch sehr interessant. Es war der erste Zyklus in dem ich nicht mehr Student bin und musste diese Doppelbelastung auch erst einmal organisiert bekommen. Gerade wenn man als Softwareentwickler arbeitet, hat man ja abends nicht immer die Lust noch einmal zu programmieren. So muss ich leider auch erkennen, dass ich weit weniger f├╝r KWin implementieren konnte, als ich mir eigentlich vorgenommen hatte.

Das 4.6 Release ist aus KWin Sicht nun f├╝r mich besonders interessant, da es das erste Release ist, bei dem mein Name in den aboutData als Maintainer aufgef├╝hrt ist. Nat├╝rlich f├╝hle ich mich geehrt Maintainer einer der wichtigsten, ├Ąltesten und ausgereiftesten Komponenten des KDE Workspaces sein zu d├╝rfen. Wenn mir jemand vor drei Jahren gesagt h├Ątte, dass ich Maintainer von KWin werde, h├Ątte ich ihn wohl nur verwirrt angeschaut. Aber das ist ja das sch├Âne, dass man nicht in die Zukunft schauen kann.

Trotzdem werde ich das nun machen. Mit dem Freeze hinter sich, hat man mehrere Monate Zeit um sich Gedanken zum n├Ąchsten Zyklus zu machen. Was wollen wir in 4.7 neues bieten, worauf sollen wir achten? In den letzten Wochen hat sich f├╝r mich angedeutet worauf wir uns konzentrieren m├╝ssen. Wayland wird vermutlich kommen, genauso wie ARM. KWin ist hier sicherlich die Anwendung aus dem KDE Lager, welche am st├Ąrksten angepasst werden muss. 4.7 wird also der erste Releasezyklus auf dem langen Weg zu Wayland. Insgesamt ist es nicht so viel Arbeit wie ich anf├Ąnglich dachte, jedoch wird es sicherlich mindestens zwei Jahre dauern, bis diese Anpassung abgeschlossen sind. Ich hoffe hier vor allem mit den Compiz Entwicklern zusammenarbeiten zu k├Ânnen.

Insgesamt bedeutet das nun eine Verschiebung meiner Implementierungsideen. Wollte ich eigentlich KWin zuerst auf OpenGL ES 1.1 portieren, werde ich die Arbeit daran nun einstellen und direkt auf OpenGL ES 2 gehen. Dies ist nicht nur f├╝r mobile Ger├Ąte interessant, sondern wird auch ben├Âtigt um Wayland zu unterst├╝tzen. Alle ├änderungen, die ich dabei mache, werden auch direkt f├╝r die aktuelle Desktop Version vorteilhaft sein. So plane ich das einfache Rendern von Fenstern (keine Effekte aktiv) auf einen moderneren Code zu heben. Der Shader daf├╝r liegt schon auf Papier niedergeschrieben auf meinem Schreibtisch ­čśë Leider ist das auch immer eine Gratwanderung: Optimierung bei einem Treiber kann zu riesigen Performanceproblemen bei einem anderen f├╝hren. Da aber der alte Code nicht entfernt wird, sollte es problemlos zur├╝ckschaltbar sein.

Interessante Zeiten liegen vor den Entwicklern von s/Fenstermanagern/Compositor/.

Powered by Blogilo

Tragt Fahrradhelme

Mein Fahrrad hat heute morgen gemeint, mich nicht mehr zu m├Âgen. Das Vorderrad hat blockiert und mich vorn├╝ber geworfen. Wie man merkt, geht es mir ganz gut und bin mit einer Platzwunde am Kinn davon gekommen. Ich m├Âchte aber nicht wissen, wie es mir gehen w├╝rde, wenn ich keinen Helm getragen h├Ątte, denn ich bin auf den Kopf gest├╝rzt.

Daher einfach an alle: tragt bitte einen Fahrradhelm. Egal wie sicher ihr euch auf dem Fahrrad f├╝hlt – es gibt immer auch unaufmerksame Autofahrer oder nachlassendes Material, wie in meinem Fall. Ach und auch wichtig: neuen Fahrradhelm kaufen nach jedem Sturz (ich lasse jetzt mein Fahrrad stehen bis ich einen neuen habe (das Fahrrad mit dem ich gest├╝rzt bin, wird verschrottet)).

Powered by Blogilo

Wayland in Ubuntu – oder viel L├Ąrm um Nichts?

Mark Shuttleworth hat in einem Blog Post geschrieben, dass Ubuntu eine der ersten Distributionen sein wird, die Wayland verwendet, was einiges an medialem Echo hervorgerufen hat. Pers├Ânlich hat mich der Blogpost ├╝berrascht, da auf dem Ubuntu Developer Summit f├╝r mich nicht ersichtlich wurde, dass Wayland schon zur Diskussion steht. Nur in einer Sitzung zu OpenGL ES in Composited Window Managers hatte ich Mark eine Frage zu Wayland stellen h├Âren und war etwas verwundert. F├╝r mich auch Anlass mal wieder in die Commit Historie zu schauen und ich habe erfreut festgestellt, dass die Entwicklung an Wayland aktiver geworden ist.

Nun was ist Wayland ├╝berhaupt? Wayland ist im Prinzip der Nachfolger des X-Servers, jedoch bedeutend schlanker. Wayland ist nur noch ein sehr d├╝nner Display Manager mit eingebautem Compositor, der die Fenster zeichnet. Damit das ganze funktioniert braucht es viele der Technologien, die in den letzten Jahren Einzug erhalten haben, wie KMS und GEM. Genau hab ich mich auch noch nicht mit Wayland auseinandergesetzt, da es meiner Meinung nach, noch viel zu weit in der Zukunft ist. Jedoch sollte ich mich langsam aber sicher, damit besch├Ąftigen, denn sonst steht KDE am Ende ohne Compositor dar (KWin als X WindowManager ist nat├╝rlich in einem X freien System nicht wirklich sinnvoll) ­čśë

Warum sollte man X ├╝berhaupt ersetzen? X11 ist ├Ąlter als ich, xlib ist nicht gerade die sch├Ânste API um mit zu arbeiten – nicht ├╝berraschend bei einem Alter von fast 30 Jahren. X11 ist entwickelt f├╝r die Anspr├╝che der Rechner aus den 80er Jahren. Xlib enth├Ąlt also einiges was man heute nicht mehr braucht: Farbverwaltung, Zeichnung, etc. und so ziemlich alles was man heute mit OpenGL machen sollte. Heutige Anwendungen nutzen die primitiven Funktionen von X zum Zeichnen nicht mehr, so ziemlich jedes Toolkit hat daf├╝r bessere Methoden. So bietet Qt an komplett auf der CPU zu zeichnen, statt native Aufrufe zu verwenden und ist dabei bedeutend performanter. Das ganze f├╝hrte so weit, dass Bereiche von X ├╝ber Jahre kaputt waren ohne dass es irgendjemand aufgefallen ist.

Die X Entwickler um Keith Packard kennen auch die Probleme und haben immer wieder neue L├Âsungen angebracht. So zum Beispiel XCB – ein etwas sch├Ânerer Ersatz um nicht auf Xlib aufsetzen zu m├╝ssen. Nur hat das erst mal niemanden interessiert – KWin zum Beispiel verwendet immer noch XLib und nicht XCB. Genauso die Toolkits: mittlerweile hat man die Erfahrung an den Problemen von X herumzuprogrammieren und warum sollte man etwas neu programmieren, wenn es funktioniert? Ein anderer Bereich ist die Erweiterung des Protokolls durch Erweiterungen wie XFixes – welche wie der Name sagt Fehler im X Protokoll behebt.

Warum sollte aber ein Display Manager eine bessere L├Âsung sein? Dazu kann man sich anschauen wie aktuell Fenster auf den Bildschirm kommen. Das Fenster wird zuerst gemappt – erh├Ąlt also einen Bereich auf dem Bildschirm. Der X Server sorgt daf├╝r, dass nur die nicht ├╝berlappten Bereiche gezeichnet werden. Die Anwendung zeichnet in der Regel in Pixmaps als Buffers und diese werden von X dann auf den Screen geblittet. Der X Server ist also zust├Ąndig daf├╝r zu sorgen, dass die Inhalte aktualisiert werden. Wenn man also ein Fenster ├╝ber einem anderen verschiebt, werden st├Ąndig beide neu gezeichnet. Nun schalten wir die XComposite Erweiterung dazu und betrachten uns das neue Verhalten. X leitet die Ausgabe der Fenster in eine off-screen Pixmap um (Moment? Die Anwendung zeichnet selbst doch auch schon in eine Pixmap…) und benachrichtigt einen externen Client (in der Regel den Fenstermanager) ├╝ber die XDamage Erweiterung wann sich die off-screen Pixmap ver├Ąndert. Das geschieht sch├Ân asynchron und in klitze kleinen H├Ąppchen (man kann sich vorstellen, was passiert, wenn der Compositor nicht alle ├änderungen mibekommt). Der Fenstermanager (oder auch Compositor) nutzt nun die GLX Erweiterung Texture from Pixmap um aus der Pixmap eine Textur zu erstellen und mittels OpenGL diese auf den Bildschirm zu zeichnen. Der ganze "legacy" Bereich des X Servers wird nun nicht mehr ben├Âtigt. Man muss keine Zeichenoperationen unterst├╝tzen, keine Fenster verschieben k├Ânnen und so weiter und so fort.

Ein kleiner Display Manager ist genau das was man will. Jede Anwendung wird automatisch und immer umgeleitet. Sie braucht also auch keine Informationen wo sie sich befindet. Interessant ist nur die Gr├Â├če, ob sie aktiv ist oder nicht und vllt. ob sie sichtbar ist oder nicht (z.B. f├╝r Videoplayer um automatisch zu pausieren). Wenn man sich nun auch festlegt, dass Compositing generell ├╝ber OpenGL erfolgt, kann man auch statt einer Pixmap direkt einen Buffer verwenden, der in OpenGL direkt benutzt werden kann. Der X Fenstermanager entf├Ąllt und kann nun durch einen viel schlankeren Compositor ersetzt werden.

Viele der heutigen Probleme im Compositing Stack von X sind vermutlich unl├Âsbar. Ich denke da zum Beispiel an das Problem der "L├Âcher in Fenstern" oder die Tatsache, dass man keine Live Bilder von minimierten Anwendungen hat (was auch der Grund ist f├╝r das Stottern der de-minimier Animationen ist). Auch L├Âsungen um Live Bilder von Anwendungen auf anderen Desktops zu erhalten ist eigentlich nur ein riesiger Hack. Warum wird mein Bildschirm neu gezeichnet, wenn sich etwas auf einem anderen Desktop ├Ąndert? Bei einer Architektur, die sich prim├Ąr auf Compositing ausrichtet, ist das nat├╝rlich viel einfacher.

Der Wechsel auf Wayland ist nat├╝rlich nichts, was schnell vollzogen werden kann und ich denke mal, dass es locker noch f├╝nf Jahre dauern wird. Alle Toolkits m├╝ssen dazu die X Abh├Ąngigkeit verlieren, Desktop Shells m├╝ssen portiert werden – hier ist es vor allem wichtig gute Compositor zu erstellen, da sonst Funktionalit├Ąt verloren geht und die wichtige Adaptierung von Wayland verhindern wird. Dies ist zum Beispiel bei KWin ein etwas schwieriges Unterfangen, da die Anwendung komplett X voraussetzt – nur die Effekte k├Ânnten fast komplett wiederverwendet werden (nach einer Portierung auf OpenGL ES 2). Es gibt sicherlich auch Anwendungen und Toolkits die niemals portiert werden – f├╝r diese wird es dann in Wayland auch einen eingebetteten X Server geben. Die Angst, dass geliebte Anwendungen durch die Transition verloren geht, besteht also nicht. Auch die Netzwerktransparenz von X bleibt somit erhalten.

Und was ist nun von der Canonical Ank├╝ndigung zu halten? F├╝r mich klingt es danach, dass sie Unity so schreiben, dass es keine X Abh├Ąngigkeit erzwingt (wie zum Beispiel Plasma auch nicht) und dass sie wohl daran arbeiten werden Compiz als Compositor f├╝r Wayland fit zu machen. Dies w├Ąre nat├╝rlich sehr interessant, da ich mich dort dann auch bedienen kann ­čśë Bzw. dass man in den Bereichen zusammenarbeiten kann. Wir sind gl├╝cklicherweise so weit, dass wir grundlagen Technologie nicht mehr getrennt entwickeln. Vorerst bedeutet das wohl, dass Compiz auf OpenGL ES portiert werden muss – genauso wie KWin. Abgesehen davon wird wohl nicht viel passieren. Die Anwendungen werden weiter X verwenden.

Nat├╝rlich ist das jetzt auch nichts unglaublich herausragendes von Canonical in dem Bereich fr├╝h dabei zu sein. Sie werden es wohl auch nicht schaffen als erste Wayland einzusetzen, da MeeGo auch daran arbeitet (Kristian H├Şgsberg arbeitet f├╝r Intel) und gerade f├╝r Mobile Devices X nicht die beste Technologie ist. Au├čer Maemo setzt aktuell kein Linux Handy OS auf X. Um es ganz klar zu sagen: alle Distributionen werden so schnell wie m├Âglich ein etwas funktionierendes Wayland ausliefern, um den Entwicklern eine Basis zum Portieren geben zu k├Ânnen.

Ich pers├Ânlich begr├╝├če die Entwicklung, auch wenn es gerade f├╝r meine Anwendung viel Arbeit bedeuten wird, auf Wayland zu portieren und ohne eine Vollzeit Stelle wird so etwas kaum machbar sein. Dass Ubuntu nun diese Ank├╝ndigung macht, ist wirklich nicht ├╝berraschend, aber man muss Mark gratulieren zum guten Marketing ­čśë

Powered by Blogilo

Wechsel auf KDE SC 4.6

Diese Woche war es mal wieder soweit und ich bin auf den Entwicklungszweig der kommenden Version 4.6 der KDE Plattform, KDE Plasma und KDE Anwendungen umgestiegen. Normalerweise wechsel ich erst zum ersten Beta Release, jedoch wurde der Wechsel bereits nun erforderlich. Auf Grund der schlechten Erfahrungen des letzten Entwicklungszyklus, hatte ich mein Entwicklungsmodell angepasst und hatte unter Plasma 4.5 immer den Fenstermanager KWin in der Entwicklungsversion (plus pers├Ânliche Anpassungen) eingesetzt. Ich hoffe dass dies hilft Probleme fr├╝her zu bemerken, als wenn die Nutzer mit dem Beta Release die ersten Tester sind.

Um KWin "trunk" fahren zu k├Ânnen, darf KWin nat├╝rlich keine Abh├Ąngigkeiten auf andere Komponenten aus trunk haben. Das einzige Problem war dabei bisher die Fensterdekoration Oxygen, welche mit dem Widget Style zusammen eine gemeinsame Bibliothek in kdebase/workspace hat. Da diese sich ver├Ąndert, zerst├Ârt das eine ├ťbersetzung (ich sage als immer, dass ich ein reicher Mann w├Ąre, wenn ich f├╝r jedes Mal wenn mein KWin trunk nicht kompiliert wegen Oxygen, einen Cent bek├Ąme). Meine L├Âsung war Oxygen einfach in der Build Datei zu deaktivieren. KWin l├Ądt dann einfach Oxygen von 4.5 (dank bin├Ąrkompatibilit├Ąt der Fensterdekorationen m├Âglich) und das Problem ist umschifft. Und ich bin stolz, dass ich mehrere Monate entwickelt habe ohne jemals Oxygen durch ein git commit -a && git svn dcommit deaktiviert zu haben ­čśë

Letztes Wochenende wurden nun ├änderungen f├╝r die "Activities" eingespielt, welche auch eine weitere trunk-Abh├Ąngigkeit haben. Da diese ├änderungen nicht mit einem Kommentar in CMakeLists r├╝ckg├Ąngig gemacht werden k├Ânnen, stand ich vor einem kleinen Problem: zur├╝ck auf 4.5 und test Account zur Entwicklung oder kompletter Wechsel. Das ganze verbunden mit dem Zeitdruck des aufkommenden Feature Freeze. Also einmal trunk neu durchkompiliert und auf 4.6 als prim├Ąrer System gewechselt. Hat mich leider einen Abend gekostet, an dem ich eigentlich noch wichtige Features f├╝r 4.6 einbauen wollte ­čÖü

F├╝r mich war es das erste mal seit Wochen, dass ich 4.6 neugebaut habe und es war f├╝r mich auch spannend, zu sehen woran die anderen Entwickler gearbeitet hatten und noch erfreulicher war, festzustellen, dass man nach ├änderungen regelrecht suchen muss. Ein klares Zeichen daf├╝r, dass KDE Plasma mittlerweile sehr ausgereift ist und die gr├Â├čten ├änderungen weiter unten im Stack sind – so wie die Optimierungen in KWin.

Sehr erfreulich ist auch bereits die Stabilit├Ąt von 4.6. Bisher ist mir noch keine Anwendung abgest├╝rzt, obwohl wir gerade in der Phase sind, die wohl die instabilste ├╝berhaupt ist: zwischen soft feature freeze und hard feature freeze. Der klassische Zeitraum f├╝r "it compiles, ship it". Ich freue mich, dass wir in 4.6 den Nutzern wohl ein noch besseres Produkt liefern werden k├Ânnen als wir bereits in 4.5 konnten.

Powered by Blogilo

KDE erfolgreich bei den Readers’ Choice Awards 2010

Auch dieses Jahr hat das Linux Journal seine Leser abstimmen lassen ├╝ber die besten Anwendungen/Softwareprodukte und hat die Readers’ Choice Awards 2010 vergeben. Dabei hat KDE Software sehr erfolgreich abgeschnitten. Amarok und digiKam konnten jeweils in ihrer Kategorie gewinnen. Besonders f├╝r die Amarok Entwickler freut mich das sehr, da sie doch in den letzten Jahren viel Kritik einstecken mussten. Da ist es sch├Ân zu sehen, dass die Anwender die Arbeit sch├Ątzen.

Ein sehr sch├Âner Erfolg ist auch das Abschneiden der KDE Plasma Workspaces (im Artikel als KDE bezeichnet): es konnte mit GNOME gleichgezogen werden und beide Desktopumgebungen belegen den ersten Platz. Im Vergleich zum Letzten Jahr konnte Plasma GNOME 10 % abknapsen. Als Plasma Entwickler freut es mich, dass die Anwender unserer Arbeit sch├Ątzen. Hier bin ich auch schon auf die Ergebnisse n├Ąchstes Jahr gespannt. Ich hoffe dass die Kategorie in Desktop Shell umbenannt wird, um auch unsere neuen Kollegen GNOME Shell und Unity neben KDE Plasma, GNOME Panel, XFCE, etc. antreten zu lassen.

KDE hat auch ein paar richtig tolle zweite Pl├Ątze belegt: Platz zwei hinter Android als "Product of the Year", OwnCload hinter MeeGo als "Best New Open-Source Project", KDevelop hinter Eclipse als "Best IDE", Choqok hinter Gwibber als "Best Microblogging Client". Hier sind auch ein paar neue und vielversprechende Projekte dabei. Gratulation und weiter so. Gerade KDevelop freut mich als Nutzer ungemein – ich muss leider auf Arbeit mit Konkurrenzprodukten arbeiten.

Man kann allen Lesern des Linux Journals nur danken f├╝r diese tollen Ergebnisse. Aber nat├╝rlich auch Gratulation allen anderen ausgezeichneten Produkten. Ein ganz besonderer Dank jedoch und Gratulation an all unsere Nutzer. Wir k├Ânnen zwar Software f├╝r uns selbst schreiben, aber ohne Nutzer ist es halt doch nichts. Und nur Nutzer k├Ânnen uns so tolles Feedback, wie diese Auszeichnungen geben. Daher: Danke

Powered by Blogilo