This weekend I prepared my slides for next weeks talk at Akademy about the mobile edition of KWin. I will talk about the reasons why we need a KWin mobile edition and why that will also benefit the desktop edition of KWin. For those who are not that familiar with KWin’s Compositing stack I will explain how the system works and where and how we can work on the OpenGL ES port. So that requires to illustrate the differences between the various OpenGL versions and what we have to do to get KWin’s codebase compiling on Maemo. As I have not yet started to implement the port (I think 4.5 is currently more important) I will also provide a roadmap on when we will see the pieces hitting trunk.
As my talk has a very special time slot I prepared a KWin effect on Friday evening for the talk. It’s a small but useful effect for the purpose and took me only about one hour to implement it and a nice effect to illustrate KWin’s flexibility, which is of course also part of the talk. Now I don’t want to spoil it, but I think it’s a nice and elegant solution to the problem that my talk collides with the second half of the quarterfinal Germany vs Argentina or Mexico. So please come to my talk and don’t stay in front of the TVs 🙂 I really love football and I can’t remember that I ever missed a German match at a World Cup. Given the way Germany played today, it will be really hard to miss the game. Who btw planned Akademy during World Cup?
=-=-=-=-=
Powered by Blogilo
I think that Kwin needs a DirectFB branch to go beyond Meamo and making KDE one of the first Desktop Environments that can ship on DirectFB. DirectFB has been used a lot on the mobile front and can make it possible to have faster linux desktop.
DirectFB would mean no X Server. That is impossible with KWin and would not make any sense at all.
my Idea is to rewrite the windowing code while maintaining the UI and compositing effects.
And exactly that is impossible. KWin code assumes everywhere that there is an XServer. It’s an X Window Manager, it’s written for X. Porting KWin to anything what is not X means to rewrite KWin and if you do that it’s easier to write from scratch without all the X specific code. Even the effects assume that there is X.
So the only way this would be possible would be to create an X like compatibility stack on top of DirectFB.
and if we implement a X compatibility layer we have X. So we could just skip this step. And implementing something like that would be more difficult than writing a new wm. Really it does not make sense to port kwin away from X. I once did a blog post about porting KWin to Windows – it was written on April 01…