From the land of wobbly windows
I’m proud to present the very first screen cast on how to implement a KWin Effect in JavaScript using current git version of Plasmate. As an example I’m using the new Maximize effect for 4.10. When watching the video, please note that this has been the first screen cast I have ever made 😉
Tutorials on techbase to be added quite soon.
First of all I want to say sorry for not providing an update for the last few weeks, which makes this post more a “This month in KWin” than a “This week in KWin”. There are many reasons why I haven’t provided an update, one of them is that not that much has happened, as new features were merged in just this week and given that 4.9 has been out for quite some time not so many new bugs are reported.
Since Thursday we are in soft feature freeze, which means that only features listed in the Planned Feature Document are allowed to enter master. And there are quite a few nice additions which went into master lately. We have two new effects: one to animate when a mouse click has been performed. It’s a really nice effect especially for screen casts. The other one is a small JavaScript effect which animates the maximize window state change. If you don’t want to wait till 4.10 for this effect: it’s compatible with 4.9 and can be downloaded.
This brings me to the next topic: finally the categories on kde-look.org for our new scripted elements have been created which means we get GHNS integration. Luckily I prepared the code for Scripts and Window Switcher Layouts for 4.9 and the download button was just visually hidden. Now that the integration works, I pushed a change for 4.9.3 to show the button. For scripted effects this had not been prepared, but GHNS integration will be available in 4.10.
Given that GHNS for effects works and I really want to see many effects being developed, I was finally forced to create the API documentation. Tutorials will be added sometime soon, also including how to write C++ effects, my old tutorial is no longer up to date at all.
Today I once more present some easy tasks to help the KWin development. This time it is a small coding task, though it’s not a very difficult task, but a very important one.
As you might know there is a new C++ standard available, which is called C++11. This standard provides quite some nice and useful additions to the language which we would like to use.
Unfortunately the new standard is not completely backwards compatible and there are some usages inside KWin which would no longer compile if we would enable C++11. This used to be totally valid code which did not even raise a warning. With gcc 4.7 we nowadays get a warning for all these code fragments which would not compile with C++11.
We need to fix those warnings, because we want to use C++11 in future and because they make it more difficult to spot the “real” warnings.
Therefore I set up a wiki page which contains all the warnings the compilation of KWin is currently causing and I would like to fix them all and that’s an easy way to help.
All you need is a current checkout of KWin and you need to be able to compile it with (at least) gcc 4.7. Please follow the instructions about building KWin. When you work on a warning just set the row in the table on the wiki page to InProgress and add yourself to the contact information. Please do this step as it prevents that multiple people start to work on it. Once you have a warning (or multiple) fixed, just open a review request on Review Board for group KWin.
If you work on it, please concentrate on warnings mentioning C++11.
Ich bin gerade dabei mein Demo-System fuer meine Einfuehrung in die KDE Plasma Workspaces auf der Ubucon am Samstag vorzubereiten und wollte dabei noch einmal kurz daran erinnern, dass ich immer noch gerne Themenvorschlaege annehme zu was ich denn im Vortrag alles beruecksichtigen soll.
Also falls jemand einen Wunsch hat, einfach in den Kommentaren hinterlassen, dann kann ich was vorbereiten. Ansonsten einfach zu meinem Vortrag kommen und die Frage/Antwort Session nutzen 😉
This weekend I had a look on enabling the OpenGL compositor when running in a virtual machine. My assumption was that given that the next version of Ubuntu is going to require OpenGL, there should be no problem with getting OpenGL running in a virtual machine.
I normally use KVM when I have need for a virtual machine running a Linux guest. As far as I know you cannot get OpenGL with this technology, so I hadn’t looked into it for quite some time.
My first attempt was to just use the project neon weekly build. Unfortunately I failed to convert it to a VirtualBox image, nevertheless I decided to run it and verify that KVM does not support OpenGL. Well I was rather surprised once the machine was up to see that OpenGL was functional, but well it was slow. Restarting KWin showed me that there is a missing slot (which I am aware of and is already fixed in one of the pending reviews) in master which makes the fallback to XRender not work, but KWin just uses llvmpipe. OK, result incorrect, but at least validated that KVM is not working.
I then decided to try VirtualBox with an install of Kubuntu Natty. Install went well but no OpenGL available. The Xorg log file told me that VirtualBox does not know the XServer version. Installed the latest version of VirtualBox, installed the latest version of guest additions in the Kubuntu guest, but no success: driver does not work.
So I decided to test with an outdated system, aka Debian Testing as I’m also running this on my workstation. Here I was more successful. After installing the system in the virtual machine OpenGL worked out-of-the-box. And what surprised me even more was that OpenGL in KWin worked when using KWIN_DIRECT_GL=1 and KWIN_COMPOSE=O. This means OpenGL works in general and it’s only blocked by KWin not knowing the driver.
The main reason is that KWin does not use direct rendering if it finds an unknown driver and VirtualBox only provides OpenGL in direct rendering mode. If LIBGL_ALWAYS_INDIRECT is set, it falls back to Mesa’s software rasterization and KWin sets this environment variable if it doesn’t know the driver.
This meant I had to perform some coding to recognize the driver and had to test it in the virtual machine. Thanks to host and guest running the same version of Debian I was able to setup a NFS share and just use my normal development version of KWin.
After a little bit of hacking and fighting with NFS I got the driver reported correctly and KWin running with OpenGL without using environment variable hacks. But VirtualBox’s driver is not complete. Some methods we (optionally) use from GLX 1.3 are not implemented and trying to use it resulted in warnings. That unfortunately needed a hack inside KWin (it’s small and well contained, so it’s not much of an issue).
With VirtualBox working I decided to also look into VMware and have installed VMware Player for the first time in years. Converted my Debian image into a VMware compatible format, enabled 3D acceleration and started the system, just to be presented with warnings that 3D is not working.
The Internet told me to add
mks.gl.allowBlacklistedDrivers = TRUE
to the vmx file. But that did not resolve the issue. The two warnings went down to one, but still a warning. Apparently one has to install libtxc-dxtn-s2tc0 in order to get 3D support.
Installed and no warnings: yeah. Started the system, but no OpenGL. Installed the guest additions, but it told me that the system already has X11 integration. Looked into the Xorg log and yes it complained that something is wrong with the module. So no OpenGL inside Debian guest.
Resolved to my previous plan of trying Kubuntu 12.10. Started it in a live session and KWin is not composited. But glxinfo reported a driver, so I restarted KWin with KWIN_COMPOSE=O and there it was: OpenGL running also in VMware.
Looking at KWin’s output I was quite happy to see that it is a Gallium3D driver, which means we don’t need any adjustments at all. KWin uses OpenGL out-of-the-box, it was only not running, because of the live session of Kubuntu. So all that was needed was adding some detection code, that KWin doesn’t print out “unknown” in the debug output. Unfortunately using my KWin from Debian did not work, so I could not yet verify the output, but that can be done once it hit project neon.
Once the patches are merged into master KWin will use OpenGL in virtual machines – if supported. But given the experience it looks like at least on Linux hosts OpenGL is basically not supported in default setups. I would like to also support Parallels and Windows Virtual PC, but am of course lacking both required host operating system and licenses.
Disclaimer: this post represents my personal opinion and does not represent the opinion of any community I’m involved with. The motiviation of this post is mostly the fact that I tried several times to get the project to stop their fork.
This week the Trinity Desktop Project released a bug fix release with very bold statements in their release announcement especially emphasizing on the 141 bug fixes and 1193 applied patches. Given that they include a fork of an application I know quite good I decided to try to validate their work on kwin. The release has been in work about a year and KWin has quite some bug fixes for reports dating back to the times of the forked application. I just used our bug database and searched for all KDE 2/3 bugs we fixed in the last year and I found the following 20 reports:
Overall there are eight commits to kwin (Trinity) in the range v3.5.13..v3.5.13.1 performed by exactly one developer. The diffstat is an impressive:
62 files changed, 410 insertions(+), 397 deletions(-)
If I look at current KWin statistics our churn is much bigger, though most changes are most likely introduced by scripty and I don’t know how to filter out those commits.
Now lets have a look at what actually changed and whether the bold statements still hold. I did not expect much but I was really shocked when I looked through the diff. I did not see anything useful. The complete diff is cluttered with garbage like the following:
- positionGeometryTip(); // shown, otherwise it would cause tqrepaint problems in case + positionGeometryTip(); // shown, otherwise it would cause repaint problems in case
or
-// fLay->addColSpacing(0,QMAX(autoRaiseOn->tqsizeHint().width(), -// clickRaiseOn->tqsizeHint().width()) + 15); +// fLay->addColSpacing(0,QMAX(autoRaiseOn->sizeHint().width(), +// clickRaiseOn->sizeHint().width()) + 15);
and even in ui files we find this junk:
diff --git a/kwin/kcmkwin/kwinrules/detectwidgetbase.ui b/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
index af4ca96..b13e794 100644
--- a/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
+++ b/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
@@ -29,7 +29,7 @@
<property name="sizeType">
<enum>Expanding</enum>
</property>
- <property name="tqsizeHint">
+ <property name="sizeHint">
What I can hardly show here in the excerpts but what I had seen in the git diff commit is lots of red. For those not familiar with colorful git diff output: red means introduced whitespace changes. So the script did not only convert nonsense in comments but also introduced trailing whitespaces and replaced either tabs by whitespaces or whitespaces by tabs.
Anyway it looks like they had a stupid script and reverted the changes. That would be in fact quite good to realize it was bad and to revert, unfortunately that is not the case. There is not one commit doing these changes there are four of the eight commits introducing these changes. E.g. "Rename old tq methods that no longer need a unique name". I don’t want to know how much broken code there is still around due to not being able to run a sed script properly and how many more issues got introduced by running such scripts again.
Well anyway there must be something useful in these remaining four commits, right? When I asked them to stop forking an application which they obviously do not understand and cannot develop I pointed out that they introduced possible ABI issues by reordering an enum. That’s now "fixed":
commit a65ae76df3276bf1925673dd6b6ec565448428ba
Author: Timothy Pearson <kb9vqf@pearsoncomputing.net>
Date: Mon Feb 13 13:30:41 2012 -0600
Clean up 9cc1e2c1 changes to enum
This corrects a potential ABI compat problem noted by Martin Gräßlin
(cherry picked from commit 77041d785dbbede734f8dc44aa454d07d14f0317)
diff --git a/kwin/lib/kdecoration.h b/kwin/lib/kdecoration.h
index 5f7e7fb..9d7fe39 100644
--- a/kwin/lib/kdecoration.h
+++ b/kwin/lib/kdecoration.h
@@ -97,10 +97,10 @@ public:
LowerOp,
FullScreenOp,
NoBorderOp,
- ShadowOp,
NoOp,
SetupWindowShortcutOp,
- ApplicationRulesOp ///< @since 3.5
+ ApplicationRulesOp, ///< @since 3.5
+ ShadowOp ///< @since 3.5.12
};
/**
* Basic color types that should be recognized by all decoration styles.
Sorry, you are doing it wrong. Now you fixed the ABI break prior to 3.5.13 by introducing another ABI break to 3.5.13.1. Lucky Trinity users that the ABI is so broken that loading a KWin 3 decoration will just crash KWin (Trinity) – hmm not sure whether that is better… Hint: reverting that change again will introduce another break.
So anything? Maybe one commit which is useful, any problem which is not already fixed in KWin? Well there would be one to workaround a problem with libre office:
commit 2482dd05e5b7806b4bad69ac8e07dbc4dd6714e0
Author: Timothy Pearson <kb9vqf@pearsoncomputing.net>
Date: Sat Mar 3 13:45:23 2012 -0600
Fix hostname display in titlebar with certain programs
This closes Bug 889
Thanks to Slávek Banko for the patch!
(cherry picked from commit 9e3f8a7f0c9f2ed1125c717f5374aaf8d4ec225e)
diff --git a/kwin/utils.cpp b/kwin/utils.cpp
index 34d29f9..a2e563d 100644
--- a/kwin/utils.cpp
+++ b/kwin/utils.cpp
@@ -18,6 +18,8 @@ License. See the file "COPYING" for the exact licensing terms.
#include "utils.h"
#include <unistd.h>
+#include <string.h>
+#include <netdb.h>
#ifndef KCMRULES
@@ -323,6 +325,27 @@ bool isLocalMachine( const TQCString& host )
if( host == hostnamebuf )
return true;
}
+ else
+ { // e.g. LibreOffice likes to give FQDN, even if gethostname() doesn't include domain
+ struct addrinfo hints, *res, *addr;
+ bool is_local = false;
+
+ memset (&hints, 0, sizeof (hints));
+ hints.ai_family = PF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_flags |= AI_CANONNAME;
+
+ if( getaddrinfo( host, NULL, &hints, &res ) != 0)
+ return false;
+ for(addr = res; !is_local && addr; addr = addr->ai_next)
+ {
+ if( res->ai_canonname &&
+ host == TQCString( res->ai_canonname ))
+ is_local = true;
+ }
+ freeaddrinfo(res);
+ return is_local;
+ }
}
return false;
}
What a pity that KWin already has a patch for that much longer:
commit c24ea2b4aac214ce29afc013cc037c110a24aa12
Author: Luboš Lu?ák <l.lunak@suse.cz>
Date: Fri Mar 4 16:22:23 2011 +0100
do not show hostname in titlebar if it's FQDN of localhost
diff --git a/kwin/utils.cpp b/kwin/utils.cpp
index 20d2ad0..92a89e5 100644
--- a/kwin/utils.cpp
+++ b/kwin/utils.cpp
@@ -421,6 +421,13 @@ bool isLocalMachine(const QByteArray& host)
*dot = '\0';
if (host == hostnamebuf)
return true;
+ } else { // e.g. LibreOffice likes to give FQDN, even if gethostname() doesn't include domain
+ QByteArray h = hostnamebuf;
+ if( getdomainname( hostnamebuf, sizeof hostnamebuf ) >= 0 ) {
+ hostnamebuf[sizeof(hostnamebuf)-1] = 0;
+ if( host == h + '.' + QByteArray( hostnamebuf ))
+ return true;
+ }
}
}
return false;
What strikes me as odd here is that the comment is exactly the same. Might it be that someone started of with the patch from KWin? If their patch is better why has it not been upstreamed?
Apart from that there is not much. One more commit fixing a warning in kcompmgr melded together with a completely unrelated change in a different application and one commit cleaning the CMakeLists.txt they introduced. Speaking of cmake: why would anyone change to cmake and not delete the Makefile.am files?
So overall none of the bugs fixed in KWin got backported to the fork, no issue from KDE 3.5 time got fixed. The majority of changes are some automated and rather stupid scripts which can nicely be shown by the diffstat without those commits:
4 files changed, 30 insertions(+), 17 deletions(-)
Given that analysis I find it an even more ridiculous joke to include the ohloh.net stats on the main home page. Yeah an impressive 14 developers having developed 14 million lines of code. From those 14 developers one is a KDE admin who created the repository and one automated system. I quite dislike someone who adorns himself with borrowed plumes like in the case of a fork. Even more if the developers still do not know who developed the code base they forked. Hint: KDE e.V. does not develop source code or release software. A nice example for taking credit for what one has not done is this change I run into:
diff --git a/doc/kdm/index.docbook b/doc/kdm/index.docbook index 730eb11..443a8c1 100644 --- a/doc/kdm/index.docbook +++ b/doc/kdm/index.docbook @@ -18,9 +18,9 @@ <title>The &kdm; Handbook</title> <authorgroup> -<author> -&Oswald.Buddenhagen; &Oswald.Buddenhagen.mail; -</author><!-- +<corpauthor> +The &kde; Documentation Team +</corpauthor><!-- <othercredit role="developer"> &Oswald.Buddenhagen; &Oswald.Buddenhagen.mail; <contrib>Developer</contrib>
I think it summarizes nicely what one should expect from this project. I can only recommend everybody to keep away from the junk this project is producing. I’m quite glad they try to cut off all connections to KDE because this project is seriously harming the reputation of KDE.
Today I have a very easy coding task. In fact writing this blog post is more work than fixing it myself 🙂 I thought this is a wonderful task for anyone who wants to start contributing to KWin as a developer.
The task is documented in Bug 308283. If you want to work on it, just assign the bug to yourself, once you are finished either create a review request or upload a git format-patch to the bug report (git format-patch so that we can easily include it).
Please work on top of the KDE/4.9 branch as that should go into the next bug fix release and master and branch have diverged.
Some days ago I prepared a patch which moves the decision which compositor to use inside the driver detection code. This allows us to remove hacks we currently have inside the compositor initialization code to move specific drivers (e.g. the software rasterizer) to a better suited compositor. The base idea is that we always give a user the compositor which is best suited for her system. It’s in my opinion not a good idea to push users on the OpenGL 2 compositor, just because the hardware supports the required extensions, if we know that the hardware is actually not capable of performing well. For such users the OpenGL 1 based compositor is better suited or maybe even the XRender based compositor.
As well for rather old hardware it’s a better idea to not provide any OpenGL based compositing even if theoretically the driver supports it.
But automatism is not always the best solution. Yes giving from experience the best suited compositor is a good idea, but still it makes sense to allow the user to overwrite it. In this case the “user” is mostly myself and other developers who have to be able to easily switch the compositor. For me this is most easily done using an environment variable as I am restarting KWin all the time anyway and is faster than going into a UI and changing the settings and afterward changing them back. Of course although this is controlled through an environment variable, there are also settings to control the chosen compositor. E.g. you can select XRender or disable the OpenGL 2 based compositor. But there is no UI option to enforce the OpenGL 2 compositor if our driver recommendation is to use OpenGL 1 or XRender (we don’t want to provide users the option to destroy their system).
One of the side-effects of this driver based recommendation is that the hack to switch to XRender for software based rasterizers has been removed in the patch. Instead these drivers now recommend to use the XRender based compositor. And in combination with the changes in the handling of the KWIN_COMPOSE environment variable this results in the possibility to run OpenGL based compositing with the llvmpipe driver.
But as you can see one has to manually enforce it through an environment variable and I would not recommend anybody (or any distribution) to use it. OpenGL based compositing over llvmpipe is considered as a fallback approach for other OpenGL based desktop environments like GNOME Shell and Unity. But I do not consider it as a solution for the KDE Plasma Workspaces. I think we have better solutions for fallback (XRender or no compositing).
Let’s have a look on the use cases for llvmpipe based compositing:
If your hardware is too old to provide the requirements for OpenGL based compositing, it is quite likely that your CPU is also rather old. We can assume a single-core CPU of either the Pentium era or an early Atom. You don’t want your CPU which is not suited for this task to spend all the time rendering the desktop. If I enable llvmpipe for KWin on my system (quad core) it puts about one core under full steam.
The case that there is new hardware without drivers available on Linux has luckily become a very rare case. Basic modesetting support for NVIDIA’s latest hardware (Kepler) was available on the same day as the announcement of the hardware. And the blobs do support also their latest hardware. So in most cases all that is needed is installing the latest driver or upgrading the distribution. If you spend lots of money for new hardware you probably want to use it and not have the CPU emulate what your expensive hardware is supposed to do.
In the case of embedded hardware it’s unfortunately still rather common that there are no drivers available. But ARM based systems are also not known for having extreme power. If you don’t want your high-end system to use llvmpipe based OpenGL compositing you even less want your low-end system to do it. You bought your Raspberry Pi hopefully for more useful things than running at full-steam to render the desktop.
If you run a virtual machine your resources are rather limited. It needs to share the resources with other virtual machines and your host system. If you run in a cloud you probably don’t want to pay for rendering the desktop through llvmpipe. You have a task to solve and the more CPU that task gets the less you have to pay. In case of a local system you also don’t want to have the virtual system run at full-steam just to render the desktop. There are really better things to do with a VM.
Last but not least there are the users who don’t want to run binary drivers. Sorry I cannot help you there. If you really think you want to spend lots of money for hardware that you don’t use, that’s fine with me. But I would suggest to only buy hardware which has free drivers available and there are nowadays options from all of the three big GPU providers.
Overall we see that llvmpipe as a backend for OpenGL based compositing is actually not needed in the case of the KDE Plasma Workspaces. We have working fallbacks like XRender or no compositing at all and those do not put the system under full-steam.
Given that I am not considering to turn llvmpipe into an option for KWin. I think that most users who would need llvmpipe are better suited with XRender based compositing even if a few effects are missing then. For me as a developer on the other hand llvmpipe is a very interesting target as it can help to optimize our rendering stack.
Of course what I considered in this blog post is only relevant for OpenGL based compositing of the KDE Plasma Workspaces. We do have proper fallbacks like XRender or no compositing which is not available in other environments which decided to use llvmpipe as a fallback. They have to do a different evaluation and I cannot provide it for them as my evaluation result would be: use KWin 😉
Very soon after joining the KWin development team almost five years ago, I realized that KWin would need at least one full time developer. It is one of the most important parts for the user experience of the KDE Plasma Workspaces and we have seen quite often that important changes for the user experience could not be implemented due to lack of manpower.
With the upcoming required changes like Qt 5 and Wayland the need for developers is increasing. I think it’s currently a wonderful time to join the KWin development. It’s a very interesting and challenging work and working on KWin means working on the future of the free desktop.
Lately I had more possibilities to work on KWin and starting from January I will join Blue Systems for working on KWin. I want to thank Blue Systems for this great opportunity and also for all the other sponsored work in the KDE community.
I’m really excited about this new possibility and are looking forward to it. I want to use this chance to work on bringing KWin to the world of Wayland. As explained in my blog post about the current state of development, I’m very satisfied with all the preparation work which went into KWin and I think it’s now in a state that we can start hacking on it 🙂 And I hope to see lots of involvement from the community. All the work will go directly into master, so it will be easy to test the new features but also easy to contribute to it. I intend to continue setting up simple tasks for the community and announce them through my blog.
Given the success of the two community involvements I recently tried with KConfigXT and UI files (both merged into master), I decided to set up regular tasks and announce them through my blog. I will mark those in the caption with [Help KWin].
And this weeks task is a no coding task, but a documentation task. It is a task which can be considered as part of the Extra Mile project.
Let me introduce to the idea: some days ago I sent a mail to the kde-artist mailing list to get help on having better animations, because somehow it doesn’t feel as smooth as other compositors, but performance is not a problem. So our animations have to be wrong (I assumed) and I wanted help from people who understand it.
Well we figured out quite fast that the actual issue is that our animations are not consistent, e.g. two fade animations don’t look the same. Now that is actually pretty easy to fix and would give a much better user experience.
But before we can do so we need to know our animations and to be honest we do not know. So I call for help! Help us document all the animations going on. This would allow us afterwards to define basic patterns for the animations.
I just created a wiki page to document the progress and to explain how one can find the animations even if one is not familiar with C++. While programming skills can be helpful it’s not required for this task, it’s basically just “reading text” in the browser.