I've added a working KDE window decorator (kwd) to head. It's pretty
much written from scratch however it borrows some trivial code from
aquamarine which I didn't feel re-implementing.
So why did I write a new one from scratch instead of improving
aquamarine?
I started out by trying to improve aquamarine but as I looked at the
code and figured out what had to change to make it work properly I
realized that a re-write was the best way to go. The two major changes
that needed to be made were:
1.
Aquamarine is using two pixmaps, both as large as the frame windows for
each client window. Both these pixmaps where being bound to textures,
which means the decorator is using more than twice as much texture
memory than all the client windows alone. Using as little texture memory
as possible is very important and the client windows alone already use a
large amount of texture memory.
Only one minimal pixmap should be created for each client window and
vertical borders should be rotated horizontally to make the size much
less. Shadow generation code is also affected by this and we want to
support that as well of course.
This functionality is also required by gtk window decorator (gwd) and
any other window decorator. The reason gwd has made it without it before
is because it always made the vertical borders 1 pixel height and
stretched them. That of course didn't produce correct vertical borders
for metacity themes.
As some of you might have seen, I've been working on a decoration
library that can now be found in the compiz tree. This library contains
code for generating shadows, creating decoration layouts for minimum
pixmaps, compositing decorations and applying opacity/opacity-shading.
It's a bit tricky to get all those things right but libdecoration seem
to be in a pretty good state now and gwd is already using it. My kde
decorator has been written to use it too, which means only minimal
pixmaps are created and shadows, opacity and all those standard options
that gwd has are also supported by kwd. kwd just uses dbus to fetch
those options values from compiz instead of gconf.
2.
To get kwin plugins to draw to pixmaps. Aquamarine was using QtPainter's
redirect functionality and was keeping track of all child widgets were
created and repainted so it could grab and blit the content to the
decoration pixmap. A pretty ugly hack that seemed unreliable and
inefficient.
A much better solution is to create a 1x1 top-level window and use the
composite extension to redirect decoration widget drawing to pixmaps and
use damage extension to detect any updates being made by the kwin
plugin. This is much less likely to confuse plugins and it doesn't
affect performance. I've implemented this in my kde decorator and it
seems to be working very well.
These two things pretty much makes up for the core in the decorator and
writing it from scratch was a lot quicker than trying to modify an
existing code base that was handling things very differently.
The current kde decorator code should be in pretty good shape but it
hasn't gone through any testing whatsoever so expect it to be a bit
unstable but with your help I'm sure we can make it rock stable very
soon. I'm aware of some issues with decorations not redrawing everything
when mapped and sometimes not being updated when a window changed size
but it seems to be working OK with most kwin plugins.
Remember that you need to have the compiz dbus plugin loaded for kwd to
be able to get your shadow options. It will use the decoration shape to
generate shadows and if windows have unique shapes they will also get
unique shadows but the convolution filter code in the server is
currently very slow so windows that change shape a lot will use a lot of
CPU.
Please let me know about any plugins that doesn't work, send me stack
traces if you can get it to crash and instructions for reproducing.
Thanks,
-David
