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

Posted on

And There was Text

Short update from the Wayland efforts:

This is quite a success as it took me several days to work out how to activate the window and get keyboard events to it. Now with that done I can start looking at the real window managment bits.

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

Posted on

Discovering a New World

This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:

desktopgrid-with-wayland
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better 😉
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.

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

Posted on

Guest Post: A Hello From KWin GSoC

This is a guest post by my Google Summer of Code student Arthur Arlt.

Hello everyone,

in this very first blog post in my life I first want to introduce myself. Then I 
want to give an overview on my GSoC objectives and say some words about code I 
already produced for KDE’s compositor KWin.
My name is Arthur Arlt. I am studying Applied Computer Science (MSc) at the 
University of Heidelberg. I reached my Bachelor degree at the University of 
Mannheim, where I studied Software- and Internet Technology (BSc). I still 
live in Mannheim and shuttle to the university, since all my friends live here 
and Heidelberg is not that far away (and much more expensive to live, as 
well;).
My GSoC project deals with refactoring KWin’s workspace class. In consequence 
of more than twelve years programming work this class grew to a giant 
‘monster’. Very many functionality was just added to the workspace class 
leading to a header file of almost 1500 lines of code. The objective of my GSoC 
project is to refactor this one big class, structuring the functionalities to 
reasonable own classes as modules. On the fly it is possible to rename 
variables and functions to follow a consistent naming scheme.
Doing all this is not only just for fun. The main reason for the 
modularization of KWin is to ease the port to Wayland. Also some 
functionalities are not required for special devices like tablet PCs. E.g. the 
functionality of screen edge handling is not needed for devices controlled by 
touchscreen.
In the past three month I started to code some peanuts for KWin. The first idea 
I had was to extend the quick tiling feature with tiling to quarters. My 
mentor Martin Gräßlin showed me where the changes have to take place and I got 
my first feature implemented 🙂 As a foretaste of my GSoC I moved the outline 
functionality to an own class. This made it possible to easily write an effect 
for outlining windows and replace the old X implementation.
My first GSoC step was to remove the non-working functionality of TopMenu. As 
replacement we now have Kubuntu’s AppMenu. The second step I am currently 
working on is to break out the TabBox (Alt+TAB) from workspace to an own 
class.


Cheers!

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

Posted on

The Compositing Modes of KDE Plasma Workspaces Explained

In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, why we wrote new code and what is the best mode for whom (at least one distribution did it wrong in their first packaging approach). With this blog post I hope to shed light on the various modes.

OpenGL 2.x/GLX

This is our default compositing backend. It uses only the so-called programmable pipeline or also known as the “core” profile. For rendering we use only shaders written in the OpenGL Shading Language (GLSL) without making use of any fixed-functionality emulation code. For the interaction with the underlying graphics system we use GLX and the extensions for compositing. Namely the texture from pixmap extension to get an OpenGL texture from an XPixmap (the window content). As the code matches the core profile it would be easy to add “support” for OpenGL 3 or 4, just in case someone is wondering. But as we do not make use of anything provided by OpenGL 3, there is no need for this.

OpenGL 1.x/GLX

This is our legacy backend and the code we only had in 4.6 and before. The code uses only fixed functionality. Up to 4.6 it was possible to also use Shaders written in GLSL. This is no longer possible. Effects requering shaders may provide a shader using the ARB Shader extension which can be used only in this mode. The code to access the underlying graphics system is shared with the OpenGL 2.x backend.
The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver. Furthermore there is an option to enforce this mode in the Advanced Desktop Effect settings: uncheck option “Use OpenGL 2 Shaders”.

OpenGL ES 2.0/EGL

This is the backend for the future. It’s primary target are mobile devices (Plasma Active), but also on the desktop it is very important as it is the requirement for supporting Wayland. Like OpenGL 2.x it uses the programmable pipeline and shaders written in GLSL. In fact the OpenGL ES 2.0 and OpenGL 2.x backend are identical to more than ~ 95 %. The difference is in the way how to access the underlying graphics system. Instead of GLX we use EGL and the EGL_KHR_image_pixmap to bind an XPixmap (window content) to an OpenGL texture.
In opposite to the other two OpenGL backends this one is not a runtime option, but a compile time option. OpenGL ES 2.0 is (mostly) a subset of OpenGL 2.0 without the legacy code. So the old code would simply not compile against the libraries and that’s why it is a compile time option. To enable use the CMake flag “KWIN_BUILD_WITH_OPENGLES”. Be aware that EGL is not supported by all drivers. To my knowledge only the Gallium radeon and nouveau drivers support it at the moment. This means especially for distributions: don’t use the build flag for the default package, but provide an additional one. For the next release cycle I hope to make it a runtime option.

XRender

XRender is a completely different backend. It can be selected in the advanced Desktop Effect settings in the dropdown “Compositing type”. Furthermore it is used as a fallback when the OpenGL backend fails in an expected way (e.g. Software Rasterizer). The XRender backend can only provide 2D animations, so e.g. no Cube effect. Performance on the backend depends on the driver, but can be rather fair (I once did not notice that the XRender backend was used in a virtual machine).

No Compositing

Not really a backend, but also a mode which has to be mentioned. KWin also supports no compositing at all. This mode can be entered at all time by the Shortcut Alt+Shift+F12 and in the General Desktop Effects settings through option “Enable desktop effects at startup”. Also at runtime self checks may disable compositing and also applications can block compositing bringing KWin into this mode. The Composited mode can be re-enabled through the same shortcut.

How To Notice which one is Used?

This can be quite tricky, because KWin automatically falls back to a different backend if one fails. E.g. if OpenGL 2 is not available OpenGL 1 is used. Or if OpenGL fails, KWin might fall back to XRender. KWin does nowhere log which backend is really used, but there are some messages printed to stdout which can help recognizing the version. KWin always prints out the used OpenGL version information. This looks for OpenGL like this:

OpenGL vendor string:                   Advanced Micro Devices, Inc.
OpenGL renderer string:                 Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2
OpenGL version string:                  2.1 Mesa 7.10.2
OpenGL shading language version string: 1.20
Driver:                                 R600C
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

And for OpenGL ES:

OpenGL vendor string:                   X.Org
OpenGL renderer string:                 Gallium 0.4 on AMD RV710
OpenGL version string:                  OpenGL ES 2.0 Mesa 7.10.2
OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.0
GLSL version:                           1.0.16
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes


To distinguish OpenGL 1 from OpenGL 2 backend there is one debug message related to "KWin::ShaderManager::initShaders". There should be three messages for valid - then OpenGL 2 is used or at least one message on failure, then OpenGL 1 is used. Recognizing XRender is even more difficult. In case that we face issues for debugging we will add more precise debug messages. Personally I test which backend is used by using functionality tests: the Cube Effect requires at least OpenGL and the Sphere and Cylinder effects require at least OpenGL 2.




Why a new Backend?


There are several reasons why I started to work on the OpenGL 2/OpenGL ES 2.0 backend. First of all we wanted to have support for everything which is nowadays known as Plasma Active, but also Wayland is very important on the longer term. Currently Wayland requires an EGL backend, so having support for EGL is a prerequisite. Last but not least to give our users the best possible performance and user experience. The programmable pipeline is a way nicer API to write GL code and especially the ES code can benefit users as it throws out all the legacy code and state tracking, which is rather complex in OpenGL and should ensure better drivers.




=-=-=-=-=
Powered by Blogilo
Posted on

Plasma Compositor and Window Manager in 4.7

With the first Beta for KDE Plasma Workspaces 4.7 out of the door it is time to look back what we achieved in the last half year for the KDE Plasma Compositor and Window Manager. Personally I think this will become a very great release with hughe improvements for our users. The best about it is, that users should not even notice that anything changed at all. Almost everything we did is under the hood improving performance, stability and rendering.

Programmable Pipeline

The Compositor received a new OpenGL compositor based on OpenGL 2.x or OpenGL ES 2.0. Our default rendering nowadays uses the programmable pipeline instead of fixed functionality as in 4.6. In order to support the programmable pipeline quite some parts had to be rewritten and got optimized at the same time. Overall this brings a vast performance improvement for all users. From my experience this can even be increased when using the OpenGL ES 2.0/EGL backend which is unfortunately a compile-time switch (as not all drivers and hardware support EGL). I hope that distributions will provide an additional package.
As with all such changes there is the chance that on some hardware/driver combinations the performance decreases due to the raise of requirements to OpenGL 2. If that is the case the user can switch back to the legacy rendering mode by unchecking the option “Use OpenGL 2 Shaders” in the advanced Desktop Effects settings. This will disable all GLSL Shaders. Nevertheless Blur and Lanczos are still useable as they will fallback to ARB Shaders.

Blur Effect

Fredrik has done some great work to improve the performance of the blur effect. Effects can know recommend whether they should be enabled by default and for Intel hardware, the effect does not get enabled any more by default. Users can still manually enable the effect. But there is also some real optimization to ensure that less screen estate gets blurred in each rendered frame and some optimizations on the shader giving a ~60 % improvement in shader performance with R600G.

Blocking Compositing

Thomas worked on a way to allow applications to block compositing. The primary goal is to have video players or OpenGL Fullscreen games be able to block compositing as for such use cases compositing is only a bad overhead. We have heard interest from VLC and Wine to support this new flag, but users  can even make use of it if the application does not yet provide support for it by using a window specific rule. Given that we have now this new way to suppress compositing we disabled the unredirection of fullscreen windows by default.

New Shadows

Together with Jacopo, Hugo and Aaron we worked on adding a new Shadow system allowing to provide their own shadows. This is currently used by Oxygen Qt and GTK to render shadows for so-called unmanaged windows. As the control for the look is with the client, the widget style is able to adjust the shadows for e.g. Mozilla Firefox. Also Plasma is making use of the new Shadows for the Panel and KRunner fixing some annoying issues with the old implementation like window snapping to the panel shadow and clickable shadows in KRunner. Not to mention that the new shadows look way better 🙂 Special thanks to Jacopo for writing the XRender code for the new Shadow system.

Outline

Arthur, our GSoC student, did some refactoring already before the GSoC project and brought all outline related code together in one class. This allowed me to add a new Effect to render the outline using a nice looking Plasma FrameSvg. If effects are not active the old X11 code is used. I am looking forward to Arthur’s GSoC, what I have seen so far looks very promising.

Graphicssystem Raster

Very short before the release we received a Patch from a new contributor, Philipp, allowing KWin to support the graphicssystem raster. Before KWin enforced the native system. In the beginning I was reluctant to integrate it, but got convinced that this is a hughe improvement. Especially with the NVIDIA blob this is a nice addition as we circumvent the slow transparent filling of XPixmaps improving the performance of resizing windows (caused by decorations) and the effect frames in e.g. Present Windows effect. There are more improvments to come from Philipp like a heap optimization for glibc in KWin, scheduled for 4.8.
And of course much, much more happened which I just don’t remember at the moment 🙂 And for the next release cycle we can expect more great things to happen, more about that on Desktop Summit.

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

Posted on

Where ends the Workspace and where begins the Application?

This week there was an interesting, but too heated discussion on kde-devel about the feature or bug of dragging windows from any empty space. I don’t want to comment on the topic as I participated in the discussion and by that are biased and this is post is not about the feature but more about what we can derive from such discussions.

When we look at the thread, we can distinguish three groups of people participating:
  1. Users – they either like or dislike the behavior
  2. Application developers – they consider the behavior as a bug which breaks their application. They want the behavior either weakened or disabled by default
  3. Workspace developers – they consider the behavior as a feature provided by the workspace. It is not a bug that the window can be dragged. No application gets broken by it; in the worst case it’s an annoying, but very consistent behavior.
I would have expected a fourth group in the discussion, namely Application developers who don’t care and either like or dislike the behavior. Given that the discussion was quite heated this is not really surprising that they did not participate.
For the further discussion we do want to concentrate on the second and third group. The most interesting issue is the homogeneity of the two groups. The developers from both groups have a very clear and uniform opinion on the matter and both groups are completely disjoined. No workspace developer could accept that this is a “bug” and on the other hand no application developer could accept that it is a “feature”.
What I derive from this discussion (which also confirms what I have been thinking for a long time) is that application developers and workspace developers are different group of people with different interest. We are all united under the KDE umbrella, nevertheless applications and workspace do not always and must not always pull towards the same direction.
The workspace developers have I would say more the view on the big picture. For the workspace developer it is (to keep in the example from above) important that there is a consistent and predictable move behavior. We have eliminated the visual distinction between window decoration and window content therefore everything that is empty content has to be a target for window movement. If we look at other platforms this is quite acceptable. Examples are MacOS X or Ubuntu. The workspace defines the platform and behavior and the application has to integrate. If they don’t do they are forced by enabling such features by default.
We have seen such differences between workspace and application developers quite often lately. Other examples are the switch from Legacy Systray to StatusNotifiers. With Legacy Systray the application has control over behavior and visualisation of its icon, while with StatusNotifiers both is moved to the desktop shell. Another non-KDE example are the action-less notifications of Ubuntu. The application developer considers its notifications as important and wants actions while the workspace defines that there are no notifications so important that they should have actions on them.
To me this results in the question: Where does the workspace end, and where begins the application? What is allowed for a workspace, how far can we “break” the application?
The KDE workspaces are still very bad at providing such a unified workspace compared to our competitors. The shining examples in this area are clearly MacOS X and Ubuntu, but also GNOME is still doing a better job in that area. Lately KDE improved. This is mostly thanks to the efforts of the Oxygen team to develop a GTK+ style. Thanks to that GTK applications integrate wonderfully into our workspace from look and also behavior. Nevertheless there are still quite some blockers like the horrible file dialog (which is for me reason to not use any GTK application):
But even for the look there is still lots of work to be done. E.g. consider the following screenshot of a popular Microsoft VoIP software:
Although it is a Qt application there is no way to get it use our style and not even the Qt plattform integration kicks in. This is a clear candidate where it does not matter what the application actually wants. For the consistency which we want to provide the application has to follow what we want. If we look at other platforms we see that Skype integrates perfectly into MacOS X, so enforcing our own look’n’feel seems to be acceptable.
Another area of the workspace version application are the client side window decorations (CSD). As it’s probably known I am not a fan of CSD and see hughe advantages for classic decorations from the consistency and integration point of view. In fact I think the advantages of server side decorations are so many that a “break” of applications with CSD would also be justified. I am even considering to try the changes for 4.8. If we look at the EWMH we see that there is nowhere specified when a window should be decorated. It is up to the window manager to decide on sensible defaults. Chromium currently does not get window decorations as it uses a legacy Motif hint. In fact the EWMH clearly states that Motif is deprecated and we would be fine to remove it:

Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style).

The specification has last been updated in 2006, so yes removing legacy code is something we can think about. 

Lately there has been some discussions about Wayland and Client Side Decorations and I have been asked why I don’t participate. From the issues I presented last year, some were X11 specific, but the general consistency problem remains. Therfore I see no reason why we should start to allow broken apps. (I also think that Wayland should concentrate on providing a good architecture and leave decisions on the workspace behavior to the various workspace implementations.) And for those not understanding why I consider all applications with CSD as broken: here a nice screenshot (I only enabled window decorations from Alt+F3 menu).


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