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

Posted on

Bye, bye KDE 4?

Wer die OpenSource Medien gestern oder heute verfolgt hat, dürfte ja schon mitbekommen haben, dass Nokia Qt 5 für nächstes Jahr angekündigt hat. Das hat natürlich auch Auswirkungen auf KDE. Um die Neuerungen von Qt 5 verwenden zu können, müssen wir gegen die neue Version linken, wodurch unsere KDE Platform eine binär inkompatible Änderung erhält. Die Folge davon ist recht logisch: KDE Plattform 5.

Für mich ist die Ankündigung von Qt 5 und dem daraus zwangsläufig folgendem KDE Plattform 5 keine Neuigkeit, besonders mit einem KDE 5 rechne ich eigentlich seit der Planung des “Plattform 11” Sprint für die zukünftige Entwicklung der KDE Plattform. Dass nun Qt 5 kommt, ist da sehr passend. Sehr erfreulich ist auch das nun offenere Entwicklungsmodell von Qt sowie einem Qt Contributors Summit direkt nach Plattform 11. Auch bei Plasma haben wir bereits mit den Planungen begonnen mit libplasma2 und im Compositor und Window Manager planen und überarbeiten wir auch unsere APIs. Hier ist natürlich ein sich ankündigender ABI Bruch eine schöne Sache, da man besser planen kann und nicht den Bruch in der Laufzeit der KDE Plattform 4 bringen wird.
Ich persönlich freue mich auf diese neue Entwicklung, da ich bei der Entwicklung zu KDE 4 noch nicht dabei war und das eine sehr interessante Aufgabe ist. Das Designen einer guten API betrachte ich als große Kunst und eine der schönsten Disziplinen der Informatik. Daher freue ich mich darauf die Dekorations-API den modernen Anforderungen anzupassen.
Nun habe ich die ganze Zeit sehr bewusst von der “KDE Plattform” gesprochen. Die KDE-libs werden ihre Versionsnummer erhöhen, für Anwendungen und die Plasma Workspaces steht das aber noch nicht fest. Nach aktuellem (noch nicht wirklich existierendem) Planungsstand soll Qt 5 hauptsächlich neu kompilieren sein und natürlich wäre das auch für die KDE-Libs eine sehr schöne Lösung. Anwendungen und Plasma werden also einfach weiter funktionieren. Wir sind sehr zufrieden mit unserem aktuellen Stand und sehen keinen Bedarf erneut den Desktop zu brechen. Sehr schön hat auch Aaron diese Gedanken zusammengefasst. Ob das ganze dann KDE 5 heißt, weiterhin KDE 4 heißt oder einen ganz anderen Namen bekommt, ist aktuell noch völlig offen und noch nicht entschieden oder diskutiert.
Für mich ist es bei der Entwicklung – gerade auch in Hinblick auf Wayland – oberste Priorität den Desktop nicht zu brechen. Auch wenn es sich zeitlich anbieten würde mit KDE 5 auf Wayland zu setzen, werde ich solche Pläne nicht verfolgen. X11 wird für uns zumindest in nächster Zeit weiterhin eine wichtige Plattform sein.
P.S.: alle Kommentare wie fürchterlich KDE 4.0 war und dass sich sowas nie wieder wiederholen darf, werden konsequent moderiert. Das wissen wir selbst gut genug.

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

Posted on

On Stability

KWin has been known as a rock-solid window manager in the KDE 3.5 times. I was wondering how the situation is nowadays with focus no longer on window managing but on compositing. Currently we are experiencing a major problem in combination of Intel/Mesa drivers with either fullscreen flash videos or OpenGL screensavers. Since the release of Kubuntu Natty we receive two to three new duplicates each day. In case you are experiencing this issue: do not report! Neither to us, nor to Mesa nor to (K)Ubuntu. It is a known issue and Upstream is working on a fix! As a workaround, do not use Flash to watch Youtube videos and do not use OpenGL screensavers. The issue is the most often reported bug against KWin of all time, now.

The fact that we receive duplicates for an issue clearly recognized by DrKonqui as already reported multiple times can tell us a lot about other problems. If we have a real stability issue we receive many bug reports and we have seen this in the past. Apart from the noise of mentioned crash above we have hardly received any new issue lately, so I thought about going through all our crash reports to get an overview of our current stability. I am also a KWin user and cannot remember a single KWin crash at work with openSUSE 11.4.
After todays and yesterdays triaging there are less than 20 open crash reports and I am only able to reproduce one of them and fixed another one. Most of our previously open crash reports have not seen any activity over the last year(s). Many of them had been reported against 4.4 or an even older release without duplicates of newer versions. All those have been closed, given that we most likely fixed these issue. Many thanks to Thomas for fighting crashers in various effects and the window grouping functionality. (Keeping the crash reports open does not make any sense as there have been too many code changes to make any use of old crash reports.)
The remaining open issues which I am not able to reproduce are in most cases missing a description how to reproduce, so it is very unlikely that these affect our users and it is possible that they are already fixed. Given this, I am happy to say, that also as a compositor KWin is rock-solid 🙂

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

Posted on

Die Bugtracker Lüge

Über Jahre hinweg hat die freie Software Gemeinschaft gepredigt, dass freie Software proprietärer Software überlegen ist, da die Bugtracker offen sind. Jeder Nutzer kann sich an der Weiterentwicklung freier Software beteiligen und mithelfen sie zu verbessern indem er Fehlerberichte einsendet. Ja die Entwickler freier Software nehmen sogar Wünsche an und warten nur darauf alles zu implementieren, was ein Nutzer als Wunsch äußert.

Wie sieht aber die Realität heute aus? Ist ein freier Bugtracker eine Hilfe für freie Software? Holen sich Entwickler Inspiration aus den Wünschen der Anwender? Gibt es bei der Entwicklung überhaupt Überschneidungen zwischen den Vorstellungen der Nutzer und der Entwickler?
Ich kann natürlich nicht für die gesamte freie Software Gemeinschaft schreiben und beziehe mich jetzt im weiteren auf meine Community also den KDE Plasma Workspaces. Persönlich bin ich Maintainer des Plasma Compositors und Window Managers mit aktuell > 400 offenen Fehlermeldungen und > 300 offenen Wünschen. Wöchentlich erhaltet unsere Komponente etwa 20 neue Bugs. Bei den Plasma Desktop Shells sieht es noch schlimmer aus mit > 1200 offenen Fehlermeldungen und > 1000 offenen Wünschen. Alle KDE Software zusammen hat mehr als 24.000 offene Fehlermeldungen und mehr als 17.000 offene Wünsche bei einer Änderungsrate von etwa 500 neuen Fehlermeldungen pro Woche und 50 neuen Wünschen pro Woche.
Als ich vor ein paar Jahren mit KDE Entwicklung angefangen hatte, lag KDE noch deutlich unter 20.000 offenen Bugs. Man müsste also annehmen dass die Qualität unglaublich sinkt wenn man den Zahlen glauben schenken würde. Jeder, der die Entwicklung von KDE Software über die letzten Jahre verfolgt hat, wird mir zustimmen dass die Qualität unglaublich gestiegen ist und nicht gesunken ist.
Was ist also die Erklärung für die steigende Anzahl Meldungen? Ganz einfach: der Bugtracker vermüllt! Kaum einer der neu gemeldeten Fehler sind zu gebrauchen. Nutzer sind nicht in der Lage korrekt zu suchen und melden wieder und wieder die gleichen Fehlermeldungen. Selbst wenn unser Dialog anzeigt, dass es schon mehr als 20 identische Crashreports gibt, wird ein neuer aufgemacht. Anderen Crashreports fehlt dann eine Anleitung sie zu reproduzieren womit eine Behebung unmöglich ist. Andere sind für komplett veraltete Software, wie sie von den Distributionen ausgeliefert werden. Wieder andere melden den Fehler und reagieren nicht auf Rückfragen. Oftmals reicht es nicht einfach nur einen Fehler zu melden, man muss mit den Entwicklern zusammenarbeiten um den Fehler zu erkennen. Wirklich gute und nützliche Meldungen sind leider die Ausnahme.
Für die Entwickler ergibt sich daraus natürlich ein Problem: wie findet man den nützlichen Report in all dem Müll? Und wie kann man den Bugtracker zur Koordination einsetzen? Ein Tool zum Verwalten der Aufgaben ist extrem wichtig und kann wirklich hilfreich sein und ich wünschte mir, ich hätte eins. Nur unser KDE Bugtracker ist es nicht. Was hilft mir ein Tool bei dem ich mit den Nutzern diskutieren muss, dass ich ihren Fehler nicht als wichtig ansehe? Oder ein Tool in dem ich stundenlang erst mal suchen muss bis ich einen Report finde, der genügend Informationen enthält um ihn zu beheben? Natürlich überhaupt nicht. Ich gehe nicht in den Bugtracker um einen Fehler zu suchen an dem ich jetzt arbeite. Über die letzte Woche habe ich viele Fehler behoben – kaum einer davon war im Bugtracker vermerkt. Die Existenz der Fehler war mir jedoch bekannt. Mein Bugtracker ist mein Kopf. Und das menschliche Gedächtnis skaliert nur sehr eingeschränkt.
Und wie sieht es mit den Wünschen aus? Gehen Entwickler in die Liste und picken sich eins davon aus und implementieren es? Auch hier ist die Realität, dass ich die Wünsche als komplette Müllhalde betrachte. Ändere ich einen Report von Fehler auf Wunsch ist es gleichbedeutend wie “> /dev/null”. Es gibt keine Wünsche der Nutzer, die sich mit meinen Entwicklungszielen überschneiden. Wenn ein neues Feature einen Wunsch erfüllt, so ist das reiner Zufall und nicht darauf zurückzuführen, dass Nutzer es als Wunsch geäußert haben. Dies führt natürlich zu einer weiteren Vermüllung des Bugtrackers: Wünsche, die implementiert werden, werden nicht auf geschlossen gesetzt. Und dass ein Nutzer kommt und es nachträglich macht, ist leider auch die Ausnahme.
Kein einziger Wunsch der Nutzer deckt sich mit den Entwicklungszielen, die ich habe. Nirgends gibt es einen Wunsch “KWin mit OpenGL ES/EGL” oder “Aufspaltung in mehrere Bibliotheken” oder “Unterstützung von Wayland”. Ein Nutzer kann nicht wissen wohin ein Projekt der Größe sich entwickelt und was die Ziele sind. Da Nutzer jeden Bugreport lesen und schreiben können (muss ja offen sein!) ist für mich der Bugtracker zur Planung völlig nutzlos. Ich kann mir nicht meine eigenen Bugs aufmachen, die nur von meinem Entwicklerteam gelesen und bearbeiten werden.
Dass Nutzer der freien Software durch das Melden von Fehlern und Wünschen helfen, ist für mich die größte Lüge der freien Software. Kein Fehler gemeldet von einem Nutzer hilft ihr, wenn es ihn mal gibt, geht er in der Menge von Müll einfach unter. Meldungen von Nutzern binden nur sinnlos Ressourcen der Entwickler, so verschwende ich wöchentlich etwa eine Stunde darauf immer und immer wider den gleichen Treiber Crash als Duplikat zu markieren. Neben all den anderen Meldungen die ich sinnlos beantworte. Ich mache dies (noch) um zumindest die Möglichkeit zu waren irgendwann einmal den Bugtracker noch sinnvoll zu benutzen und die Vermüllung einzudämmen.
Freie Software braucht Qualitätssicherung und auch Bugtracker – so wie jedes andere Projekt auch. Ein Bugtracker, der für jeden offen ist, kann aber keine Lösung mehr sein, dafür ist freie Software zu populär und Nutzer sind Nutzer und keine potentiellen Entwickler und Informatikstudenten mehr.

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

Posted on

Things I want to see in KWin

Now with the GSoC application timeline ended, I feel like blogging about some more ideas what I want to see in KWin in our next releases, but are not enough for a GSoC. Nevertheless most of it is in the scope that it can also be handled by new developers. But some parts have to be done by KWin/Plasma developers.

Stable kwineffects ABI:

This is one of the most important pre-requisites for the other ideas. KWin currently has no stable effects ABI and it is rather difficult to get it stable as it would become almost impossible to extend the API in future. Up to now this has never been a real issue as KWin includes (almost) all existing effects – the only effects on kde-look are from KWin developers knowing about the situation. Nevertheless last year we had to face for the first time the situation that an effect was proposed for inclusion which did not fit our own goals. For 4.7 I have already done a great deal on getting the kwineffects library into a state that makes it easier to provide a stable ABI and I want to do another round of changes till 4.7, but due to the size of the library it will not be possible to provide a stable ABI before 4.8.

Move effects out of KWin:

KWin has a large amount of effects which are not really usable. Here I have also to look at myself, because I implemented some effects I nowadays consider as useless. Now I don’t want to remove features and I don’t want to just drop the code. We need to define a set of effects which we want to ship and move the remaining effects either to kdeplasma-addons or to extragear. This would allow us to concentrate more on the effects which improve the user experience than just adding eye-candy. Of course this change requires that the kwineffects ABI is stable. For this task new developers can help by writing up a proposal on which effects to move and how to group them.

Define the Workspace Helper Effects:

KWin has a set of effects which are helper effects for either the Plasma workspace or KWin core itself. Examples for the Workspace integration is the Dashboard effect or sliding windows. For KWin core there is the resize effect or window geometry. Now these effects are really important as they are mostly hughe optimizations over the existing X11 code base. There is no reason at all to have them in the UI and to make it possible for the user to disable them. For this a new effect group has to be defined which is not presented in the effect selection. On the other hand at least the dashboard effect has a config UI and this needs to be accessable. So it needs to be moved somewhere where it fits better.

Better Effects Configuration Module:

KWin uses KPluginSelector to provide access to the configuration of all effects. The plugin selector is a nice tool but not made for the requirements of KWin. We have effects which do not work together – for example it does not make sense to use minimize and magic lamp effect at the same time. Such groups of effects cannot be modelled with the current solution. It would be nice to have a real UI to configure the effects and to provide more information about all the effects than what is currently provided. If I were a user I would be lost in this UI 🙁

JavaScript bindings for effects:

As soon as the ABI is stabilized I want to have the possibility to write effects in an easier way than C++ code that is JavaScript. Of course the current API is not very useable for that as the interpreted code would be called up to 60 times per second. I am currently working on a new additional Effect API which would allow to have the often called parts in normal C++ code and only the window/effect system interaction in JavaScript. I hope to have the foundation for that ready at the time of the beginning of the next release cylce. Help is welcome on exporting the methods to JavaScript and providing the required interaction as I personally have no idea about it 😉

Unit Test Framework for the Window Manager:

I would like to be able to properly test the window manager so that we don’t see regressions. Testing a window manager is non-trivial as it requires interaction with X11. My idea is to load KWin in a Xephyr environment and execute tests written in JavaScript and using KWin’s scripting interface. Having such a test environment would allow to properly define tests for all window manager functionality and ensure the regression free transition towards Wayland.

Standalone Build of the Compositor:

Being able to just build the compositor and run it in a window would give us quite some new possibilities. We would be able to develop without constantly restarting the window manager and to properly debug it. Furthermore we could execute the effects in the standalone application and compare rendering results against pre-rendered images and by that having a set of unit tests for us and the driver developers. The optimum would be if the complete compositor and effect system could be integrated into the piglit test suite.

“IDE” for Effects:

With the standalone compositor and the JavaScript bindings it should be possible to develop effects in a way like developing Plasma Applets with Plasmate. I would like to have something were you can just specify “move window from here to there” and maybe define an additional OpenGL shader to animate the window. As all of it is interpreted code it should be possible to see the results instant and with that giving our designers a better tool to define the effects we want to have in our Plasma workspaces.