Posted on

KWin turns 12

Today twelve years ago at 23:26 Matthias Ettrich did the first ever commit to KWin:

Say hello to kwin. WARNING: NOT USABLE YET. See README.

Given this nice warning we also have to show the content of the README:

This is the beginning of kwin, kwm next generation.
WARNING: this thing is hardly usable now, neither ICCCM nor KDE
compliant yet!
All it has is a context menu that allows you to switch between two
decoration styles, KDE classic and an experimental style.
Please don’t work on the code, I’ll finish it during my summer
vacations (four weeks from now on).
kwin was only commited to allow people like Mosfet to have a look at
the Client API (and StdClient) to write nifty new themable decorations.
Have fun,

   Matthias

As we can see KWin has its root in KWM from KDE 1 (there are still one or two comments in KWin source tree saying KWM) and it seems like the capitalizations was added in later times 🙂 
Matthias seems to have been a little bit too enthusiastic about how much time it needs to write a window manager. It took 8251 commits (1195 translation commits) by 284 contributors (including scripty and cvs/svn migration tools) to get to where we are today. And still we are not finished with KWin. After adding Compositing Support to the Window Manager we are now adressing the second big transition to support more than just X11. So exciting times are ahead of us.
Let’s work together to make KWin rock the next 12 years even more than the last 12. Billions of devices are out there which want to be using KWin as their Wayland Compositor. Let’s work on the future for the free software eco system!

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

Posted on

Thoughts about Network Trancparency

Every time there is an article about Wayland you can see that there a lots of uneducated comments about the “fact” that Wayland does not support network trancparency and because of that it is completely wrong to go for network trancparency. These discussions contain a lot of myths and even FUD and I consider it important to share my thoughts about these concerns as I am belonging to those who actively work to bring the benefits of Wayland to the KDE Plasma Workspaces.

Wayland Could Use Network Transparency

Nothing in the Wayland protocol forbidds network transparency. It is not yet implemented, but it is possible to implement it. Wayland uses a Unix Socket for communication but I think it would be rather trivial to either add network transport to the Wayland protocol or to just forward the buffer in the compositor. Stating that Wayland does not support Network Transparency in general is just wrong. It’s not yet implemented but many things are not yet implemented. Obviously it’s true that the Wayland protocol does not support the X11 Network Transparency as it’s not X11 (and that is a good thing). Obviously even a direct X11 successor (let’s name it X12) would also not support the X11 Network Transparency.

X11 Network Transparency is not Suited for Modern Applications

The idea behind the network transparency is to send drawing commands over the wire (useful idee for the requirements of 30 years ago). Nowadays modern applications do not use X11 any more for rendering. They use technologies like Cairo, Clutter, QPainter (Raster) or OpenGL directly. Without using X11 for rendering you end in streaming pixels over the wire. And there are clearly better technologies to do that than X11. Face it: network transparency is going to break very soon even without Wayland. I want to see the Qt 5 used over the wire.

Modern Applications require DBus

Yes DBus is not network transparent and yes most modern application use it, for things like StatusNotifier (this one has fallback to Xembed) or moving the menus somewhere else. Now without network transparency these things are just shown on the wrong system or not at all. Damn stupid devs not thinking about network transparency… So face it: no modern app can be used without DBus which breaks implicitly also the X11 Network Transparency.

Wayland targets Mobile Devices

Those who attended my presentation at Desktop Summit or who have seen my slides might have already got the message: we don’t want to break the desktop and will therefore only target mobile devices in the beginning. The same is true for MeeGo (they don’t have a desktop) and hopefully also GNOME Shell and Unity. So do you really want to forward your X11 application from your (mouse+keyboard) desktop to your touch tablet/smartphone? Probably not. So why do you care about network transparency not available on mobile? For mobile the target groups are the billions of users out there who do not even know that network transparency existed and not the five geeks who cannot live without it. Face it: you are not in the target group of Wayland on mobile devices if you need network transparency. (You probably wouldn’t use an iPad either).

Desktop will continue to Support X11

We will only switch to Wayland as our primary windowing system if we can continue to support legacy X11 applications, because we don’t want to break the desktop. This means you can still run your legacy X11 windows over network even under Wayland and also X11 applications on the Wayland system can still be forwarded to a remote system. So I hear you already complaining about the Wayland windows not being able to be forwarded. Well if the toolkit (like Qt) supports multiple backends there is no reason why you should not use the X11 backend to forward the window. Apart from that: remember, it would not be working at the time when we switch to Wayland even under X11 (see above).

Network Transparency Does Not Belong Into The Windowing System

Adding Network Transparency in the Windowing System is the wrong layer. The windowing system only receives the pixels and that can never be performant. Network Transparency needs to be added to the layer which does the rendering. That used to work with X11 as X11 also did the rendering, but this is not true any more. We need support for Network Transparency in the toolkit. Just imagine the possibilites: remote applications picking up your local font settings, color themes, icon themes… That’s what needs to be done!

But Distros will remove X11 support in $X Years

As long as there is a demand for legacy support distros will still support it. Especially I don’t think that enterprise distributions will dare to remove it in the next 10 to 20 years. Remember that also Mac OS X still supports legacy X11. And even if the distro removes the support: who stopps you to package X11 yourself and provide it to everyone who needs X11? Btw we are talking here about at least three to five years – others have predicted the death of desktop till then.
I hope this post can help to bring future discussions about Wayland to not keep repeating what has already said and is just wrong.

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

Posted on

KWin at Desktop Summit

Wow, what a week! It’s just great to be at Desktop Summit again and meeting all those KDE people again and also the GNOME people which gives the event a different and pleasant touch.

The big topic for me at this Desktop Summit is to lay out the foundations for bringing the KDE Plasma Workspaces from the X11 Windowing System to the upcoming Wayland windowing system. This is an effort which will most likely take years, nevertheless I am hoping that we find enough interested developers to have something ready as a developer preview in our next release. The complete plan has been outlined in my presentation here at Desktop Summit. It seems like my slides and video recordings are not yet uploaded, but I put my slides in our wiki. If you can read German you can also have a look at my article in the current issue of freiesMagazin, where I wrote down what I talked about.
As there was some media coverage about my talk and also about other changes in KDE which are completely unrelated I just want to point out that the work going on for KDE Frameworks 5 does not influence our development of the desktop at all. This means we will continue to release further 4.x releases of the KDE Plasma Workspaces. Also given the changes which are going to happen in KDE Frameworks it will not be disruptive to the desktop. This means that there is no reason to use a “5.0” release to switch the windowing system from X11 to Wayland. We will switch when we are confident that we do not break the users’ desktops.
I also read some concerns about that we would remove the X11 Network Transparency. Relax: we don’t want to break our users’ desktops. Just have a look at this architecture:
As you can see even with Wayland as the windowing system we will continue to support remote X Clients.
Yesterday we had a BoF about the changes needed for Plasma. We did unfortunately not agree on that much, but I will put up a wiki page with small TODOs, so that others can work on it. The BoF turned out into a discussion about Client Side Windowdecorations, which I did not want to spend time on. But in the end I think it was useful as now developers from other projects understand our position better and can understand why we will stick to server side decorations even with Wayland. I will soon write down a policy to exactly specify when windows will be decorated and when not and implement it for 4.8 (should only require minor changes).
On a completely unrelated note: thanks to the decision of three persons, I will be going to Akademy 2012. Thanks very much for the award.

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

Posted on

Continuous Integration for KWin

I decided that the life for my server is too boring as its only used to host this blog and functions as my mail gateway. As the system is rather powerful I decided to setup a Jenkins installation in order to continuously build KWin.

The first step is finished: the kde-workspace repository gets polled regularly and whenever there was a commit to master the sources are rebuild and in case it breaks I will be notified by mail. As KWin is not a standalone project, the complete kde-workspace repository is rebuilt. I want to further improve this process by doing several builds with varying configuration (e.g. the build for Plasma Active) and also for the kwin-wayland branch. But for those I first need to build a recent version of Mesa (no OpenGL ES on Debian Squeeze).
The really useful part of a CI system is that you can also perform some checks on the code. Unfortunately KWin does not yet have any unit tests (it is rather difficult to unit test an X11 Window Manager and OpenGL Compositor), but thanks to our modularisation effort I’m confident that we will soon be able to integrate the first unit tests.
But there are of course other possibilities except running unit tests. So I integrated a cppcheck execution on KWin’s repository as well as setting up Krazy tests, which are unfortunately broken for kde-workspace on quality.kde.org. Due to the lack of automated Krazy runs I have not managed to keep track of the issues lately.
I hope that these efforts help in the long to improve the quality of our software and to ensure that the code doesn’t break with unusual build options especially now when we transit to a major new windowing system.

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

Posted on

Shadow and no Oxygen

All users who do not use our default Oxygen widget style and window decoration might have had an unpleasant surprise after upgrading to 4.7. Our old shadow effect provided generic shadows for all windows no matter which widget style or decoration is used. In case the decoration provided its own shadow that one was preferred.

The new shadow system does not provide any generic shadow. The compositor is just providing a service to the widget style for rendering the shadow. This means that the widget style has to implement support for the new shadows. This has been done at least for Oxygen and Bespin, but it might also be added for other styles – so if you miss your shadows, check whether there is a new version of your preferred style, get in contact with  the author of the style or best of all: provide a patch.
Of course there is also the option to add a generic implementation again to KWin (which seems to be a need), though I must say that I will not spend any time on that myself. Given the experience from our old shadow effect, it is my belief that you cannot have a generic shadow which looks good with all widget styles, windows and color schemes. Nevertheless I am open to patches which add a generic shadow which can be used if decoration and widget style do not provide a shadow. The basic ideas of the new Shadow system are documented in our wiki. If you want to work on it and have questions just get in touch with us through either #kwin or #plasma on freenode or kwin at kde dot org.

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

Posted on

Running KWin with OpenGL ES 2.0

Today we expect the release of the KDE Plasma Workspaces in version 4.7 which is the first release including an OpenGL ES 2.0/EGL backend in KWin. This does not only allow us to run KWin on OpenGL ES powered devices (I am particular looking forward to see KWin on Tegra 2 devices), but also gives us a much better compositing experience on the desktop systems. Thanks to the work on OpenGL ES 2.0 our default compositing backend is now OpenGL 2.x based instead of OpenGL 1.x as it was till 4.6.

I want to thank all users who tested our beta version and release candidates and ensured by that a regression free update. I am very glad on how smooth this major transition of the compositor seems to work according to the very low number of bug reports in this cycle.
On Mesa enabled desktop systems there is also the possibility to go a step further and leave GLX completely behind by compiling KWin for OpenGL ES/EGL only. My personal experience is that it is often a much better experience to use the OpenGL ES build. If you compile KWin from sources ensure that the OpenGL ES 2.0 and EGL development libraries are around and enable the CMake option “KWIN_BUILD_WITH_OPENGLES”. If everything is setup correctly, CMake will tell you “Compiling KWin for mobile”.
Of course compiling from sources is not what most of our users do, so it needs distro help. Thanks to the awesome Kubuntu crew there will be a kwin_gles package available in Kubuntu 11.10. So users can switch to use this package.
But that’s still not perfect as users need to know that there is a better GLES variant. So today I pushed a change to master to build KWin twice: once with OpenGL and once with OpenGL ES. Thanks to our CMake Gods for all the help on getting this done :-). Now if OpenGL ES is available at buildtime a “kwin_gles” binary is compiled and can be used just like “kwin”. For all users of masters, do a git pull, recompile and run: kwin_gles –replace & and enjoy.
And that’s also just an intermediate step. Our GSoC student Arthur is currently working in close collaboration with me on decoupling our compositor from the window manager so that we can build just the compositor once with OpenGL and once with OpenGL ES. We will then put the compositor into a plugin and do a runtime check whether OpenGL ES is working and if it is we will load the OpenGL ES compositor. So if everything works fine, in 4.8 we will be able to offer and default to OpenGL ES 2.0 for most of our users.
This is also important for Phase 1 of Plasma on Wayland, which I will highlight in my talk at the Desktop Summit: Compositing after X – KWin on the road to Wayland. Hope to see you there.
Posted on

Why I would not sign a Harmony Agreement

Jos blog post today reminded me that I had a look at the Harmony Agreements and tried to decide for me whether I would consider to sign such a CA. To make it short: signing a Harmony Copyright Assignment is for me unacceptable. I think it could be valuable to others why I would not sign such an agreement. As a note: I have signed the KDE Fiduciary Licensing Agreement, so I am not in general opposed to licensing agreements.

Issue 1: The Name

The name “Harmony” is really bad. Not only as there is already a relevant FOSS project called Apache Harmony, it is also the meaning of the name. The name implies that you have to sign it to have harmony. Harmony between whom? Obviously the company who wants the CA being signed and the developer who should sign it. So without the CA there would not be harmony? Why shouldn’t there be harmony? If the developer chooses to develop to a company driven FOSS project under a given license (e.g. GPL) I do not see any reason why there should not be harmony between developer and other corporate partners. So given the aim of the Harmony Agreements to standardize CAs, I only see one possibility to destroy the harmony: requiring a CA from the developers. If the CA is an obvious problem then I do not understand how the Harmony Agreements are going to fix this. To me the name just sounds like an euphemism or worse like Newspeak.

Issue 2: Written by a Company

The Harmony Agreements have been written under the lead of Canonical, a corporate institution. Personally I doubt that a corporation has the individual developer’s best interest in their mind. Especially in the case of Canonical I am very doubtfull since the Banshee incident. If I cannot trust that the other party does not fleece me, I cannot sign such an agreement without consulting a legal expert in that field. This means quite a monetary factor on my side just to contribute something for free. If I have to pay to donate, I rather do not donate. I would feel way more open to the agreements if they would have been written by the FSFE, an organization I as a developer can trust and do trust.

Issue 3: Patents

Disclaimer: I’m neither a lawyer nor is English my native tongue, I might just be missreading it (see Issue 2). The agreement contains the following sentence:

(b) You own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2.

To me this sounds like I have to state that I own all possible patent claims for the code I contribute. I would not have a problem with that for Germany (where patents on Software are not allowed), but worldwide? Considering the completely broken American software patent situation I would be sure that for any code I write there is at least one trivial patent claim for it. This is a point in the agreement I cannot sign without calling myself extremely stupid. As far as I remember my law term at university as a private, non-corporate developer no company could sue me for patent claims. By signing such an agreement patents become a serious issue for me as an individual developer. If donating code results in a threat to my monetary future I rather not donate source code.

Issue 4: Copyright in Germany

Germany has a “Copyright” very different to the rest of the world. There is no fitting translation for Copyright into the German langue and vice versa. In Germany (and some German influenced contries) you are the author (“Urheber”) and you will always be it. There is no possibility to assign your authorship to someone else. There is also nothing you have to do to become the “Urheber”, when you do creative work you are automatically the “Urheber”. Being a German, living in Germany and have been educated with this in my mind, I consider the authorship as something very important and I am very respectful for the author.
Obviously a Copyright Assignment is not possible if you are German. The Harmony Agreements handle this case:

(b) To the extent that any of the rights in Section 2.1(a) cannot be assigned by You to Us, You grant to Us a perpetual, worldwide, exclusive, royalty-free, transferable, irrevocable license under such non-assigned rights, with rights to sublicense through multiple tiers of sublicensees, to practice such non-assigned rights, including, but not limited to, the right to reproduce, modify, display, perform and distribute the Contribution; provided that this license is conditioned upon compliance with Section 2.3.

The agreement is just reduced to what the Contributor License Agreement is about. But it leaves me in legal doubt. What if I am at a conference outside Germany? Is the code I write there covered under the License Agreement or the Copyright Assignment? What if I move into another country where Copyright Assignment is possible? Given my German background it is for me unacceptable to assign the Copyright to anyone as nomatter where I live or work I consider myself as the “Urheber”. This is again a case of Issue 2. If it is just a license agreement in practice, why am I not allowed to just sign the license agreement? If the company is interested in controlling the copyright worldwide, wouldn’t it be a subsequent step to say that they don’t accept contributions from Germans due to the legal situation? How can a company know what parts of the code they have the copyright and for what they don’t?

Issue 5: Termination

There is plain simple no way to terminate the assignment. This is clearly in the interest of the company, but not neccessarily in mine. I am not sure if a could sign a treatment legaly binding for the rest of my life without the possibility to change my mind. Again compare issue 2.

Issue 6: Who benefits?

Why does a FLOSS centered company require CAs? I don’t have an answer for it and if I try to find one I can only come up with one solution. The company in question wants to improve the corporate value by having the option to make the software they develop in a community process proprietary. Or that the owner of the company considers to sell the company in future and wants to make it as profitible as possible. I hope there are better reasons for it and I am looking forward to the Panel discussion, but I fear my thoughts could be right. I personally would not give a company the right to turn my contributions to free software, and by that to mankind, into proprieatary software or even worse to sell it to $evil_company I would never want to work for, neither directly nor indirectly.
Overall there are just too many issues for me that I would consider signing it. As a note again, I do not in general consider copyright licensing as harmful and would also sign other agreements in case I am convinced that I can trust them. E.g. I would sign the FSF CA and would also contribute to Qt as the free software state is ensured by the KDE Free Qt Foundation.

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

Posted on

KWin Scripting’s Future Depends on You

In last years GSoC scripting capabilities have been added to KWin and have been shipped with 4.6. Unfortunately the student did not stick around so far which results in a situation that during the complete 4.7 releasy cycle there have only been two commits to the scripting component: one to fix some Krazy issues and one to change the coding style. With other words: the development of the component is dead.

For a new component this is very bad as it is unlikely that it is bug free and feature complete. There are probably many usecases where scripting integration might be useful and which is just not yet implemented. It also shows us that the core development team is not able to also maintain this new component. In fact due to lack of provided documentation the core team does not have the knowledge to further extend it.
This unfortunate development raises questions for the future. Currently we have a GSoC to modularize KWin core and it is likely that such a refactoring will break the scripting component at some day. Given that no core developer is knowledged about the scripting component, we are not able to see this in review requests (and we don’t have unit tests for it and cannot add them due to the lack of knowledge about the component). We are also not using the component so we won’t notice a breakage. My expectation for 4.8 is that scripting will be no longer functional and even if bug reports arise we would not be able to fix them.
The GSoC project is preparing KWin core to properly add support for multiple windowing system backends. I have already started to add support for a new windowing system and all the code so far does not integrate scripting. In the far future we want to be able to switch to this new windowing system which has also implications for scripting. Due to the current lack of scripting integration in the new written code it would mean that scripting no longer functions in future.
Overall this does not look good for the scripting component and I am currently considering various options. One of them is to remove scripting support again in 4.8. This is something I don’t want to do and I would feel very bad about it. Lots of work has gone into the code and it is a pity to remove it. Especially given that it was a successfully finished GSoC project and the slot might have been used in a better way for KDE if we remove the code after a year again.
I don’t want to do that! But I need your help to prevent that from happening. Step up and share scripts on kde-apps.org, provide a way to exchange scripts through GHNS, maybe add support for writing scripts to Plasmate and most important get in touch with the development: ensure that the code does not get broken in master, add support for further parts, help to document scripting in techbase, fix some glitches in the scripting related code.
I will keep the code at the moment and look how it evolves over the next months. In case the situation has not improved till soft-feature-freeze of 4.8 I see no other solution than to exclude the code from building 🙁

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

Posted on

Stripping Down KWin for Plasma Active

For the usage of KWin in Plasma Active many of KWin’s advanced features are just not needed. For example on Plasma Active we target OpenGL ES/EGL compositing, so the for desktop usage still useful XRender compositing is just unneccessary bloat added to the binary.

In 4.7 we started to add some build-options to remove unused parts from the build. We decided that on Plasma Active we do not need window decorations and added an option to exclude the decorations from the build and the basic functionality to start KWin without any decoration plugin present (which was not possible before).
Now with master open and a GSoC working on modularizing KWin, we were able to split out more stuff which can be disabled at compile time. There is a new build option to group all the settings for KWin on Plasma Active which currently includes:
  • No window decorations
  • No configuration modules
  • Reduced set of effects
  • No Alt+Tab (window switching)
  • No Screenedge interaction
  • No XRender Compositing
  • Default build to OpenGL ES if available at compile time
Some of the removed parts also affect the size of the KWin binary and/or the KWin internal libraries. I was interested in the differences of size when building KWin for desktop and for Plasma Active. So today I did a release build of current master with “normal” build flags and with the active build flag and compared the size of:
  • kwin.so
  • kwin_effects_builtins
  • libkdecorations
  • libkwineffects
  • oxygen decoration
For the desktop this sums up here on my system to 3239.5 KB and for active it’s only 1987.3 KB. And this is without considering the size of the installed package where the difference is much bigger as we do not install any decorations and configuration modules on Active. I’m really quite impressed seeing that the size of KWin is so much decreased. The biggest impact has the removal of some desktop effects: the size of kwin_effects_builtins goes from 927 KB to 269 KB. And there is more to go like disabling window tiling support, desktop change OSD and so on and so on…
I hope to get some “real” numbers on comparing the package size once both builds based on master are available as a package.

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

Posted on

Need an ATI R300

The ATI R300 is a very “special” and rather old GPU. It supports OpenGL 2 with one well-known limitation: there is no full non-power-of-two-texture support. KWin has code to handle this situation, nevertheless I broke our R300 support completely one week ago just before the branching of 4.7 without noticing it.

R300 used to be a very important Notebook GPU chip, so we cannot just stop to support it. I am sure that I will fix the regression with the help of users willing to test my patches, but for the long run it’s no solution. Even if we fix this regression I am (after reading our code again) very sure that some new features are not working at all with R300.
Given the situation that we do not notice such regressions during development, it is likely that changes will break support in future again (at least I am not able to develop correctly without testing ;-). This makes it very difficult as we cannot easily bisect. I see only one real solution: I need to have such a GPU to be able to test recent changes for regressions and implement the (rather trivial) adjustments for R300.
If anyone has such an old card and would be willing to donate it for KWin development, please get in contact with me.
Thanks.

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