compiz - Aug 2010 - [RFC] Draft for a compositing manager specification

Resending as kwin and plasma mailinglists think that 200k is too large for a 
mail. The "attachment" can be found in [2]

Hi,

Pleas note: crossposting to kwin, compiz and plasma development lists. Please 
keep all lists CCed.

Attached you can find a very first draft for a compositing manager 
specification. It is currently based upon the KWin/Plasma interaction 
specified in the windoweffects namespace[1]. I basically just renamed all _KDE 
prefixes to _NET_CM. 

I want that in the end this becomes a new freedesktop.org specification to be 
used in addition to the EWMH specification. As I am not sure if all composited 
window managers are interested in such a specification I decided to discuss 
this idea first with kwin, compiz (as they implement our proprietary hints) 
and plasma, our most important stakeholder. The result of the discussion 
should be proposed as a joint draft from both compiz and kwin to 
freedesktop.org. I consider each and every of those hints as optional. So a 
window manager implementing none of the hints would be fully compliant.

Even if the attached draft is tainted to the current KWin naming and hints, it 
does not mean that this has to become the standard. I am very open to do 
changes to our code and also implement hints specified by compiz or other 
window managers.

I am aware that normally specifications are written in docbook. Unfortunately 
I don't know docbook at all, but I know LaTeX therefore I wrote the draft in
LaTeX. Attached you find the tex document and a compiled pdf.

If someone has an idea how to collaborate on the document, please tell me. My 
only idea so far is to setup a special repository on gitorious.

Looking forward to your comments.

Regards
Martin Gr??lin


[1] 
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.cpp?view=markup 
and http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.h?view=markup
[2] http://blog.martin-graesslin.com/blog/wp-
content/uploads/2010/08/compositing.pdf.tar.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/compiz/attachments/20100815/2ae1737d/attachment.pgp>

Hi Martin, All.

On Sun, Aug 15, 2010 at 8:57 PM, Martin Gr??lin
<kde at martin-graesslin.com> wrote:
> I want that in the end this becomes a new freedesktop.org specification to
be
> used in addition to the EWMH specification. As I am not sure if all
composited
> window managers are interested in such a specification I decided to discuss
> this idea first with kwin, compiz (as they implement our proprietary hints)
> and plasma, our most important stakeholder. The result of the discussion
> should be proposed as a joint draft from both compiz and kwin to
> freedesktop.org. I consider each and every of those hints as optional. So a
> window manager implementing none of the hints would be fully compliant.
>
> Even if the attached draft is tainted to the current KWin naming and hints,
it
> does not mean that this has to become the standard. I am very open to do
> changes to our code and also implement hints specified by compiz or other
> window managers.
This is a good initiative to start off on. So far I think the list is
good, but it is very specific to KDE in general (considering that most
of these are just KDE hints renamed). I think what needs to be
discussed here is what we agree should be expected from a compositing
manager.

I think one of the major problems we are going to encounter is that
unlike EWMH, this document is focused more on effects and less on
behavior. Considering the current pace of most compositing managers,
the number of effects is likely to grow over the coming years and even
months.

One of the key areas where I think this might happen is in the
"animations" category. Applications could want a whole host of window
animations. It is a good idea to look to things like the Quartz
display system on Mac OS X as to what is possible with this.

In order to address this we need to either have a system of versioning
this specification, or a "base" specification, with a list of agreed
upon properties and client messages hosted on freedesktop.org, with no
versioning (instead using the list of properties stated as "supported"
on the root window.

Of course, the specification is nowhere near finalized now, and I
thought I'd kick off discussion by responding to a few points in the
list of items we have in the specification:

3.3: Present Windows

I think this can more easily be reworked to just set a
_NET_CM_PRESENT_WINDOWS property on the root window, or even as a
client message, with a list of windows that should be presented,
rather than having to support it on a desktop, window class or group
level.

3.4 Dashboard

Unless there is any particular effect that we have in mind for this,
is it possible that clients can just set the Above hint in WM_STATE
and then set one of the various "animation" properties?

3.6 Shadow

Rather than just overriding the shadow altogether, I think a better
approach here is to allow clients to specify here exactly what kind of
shadow or border should be drawn.

The compositor should set the _NET_CM_SHADOW_SUPPORTED hint and
clients should set the following information in the _NET_CM_SHADOW
property on the window.

0 | shadow color (32 bit depth)
1 | shadow radius
2 | shadow x offset
3 | shadow y offset
4 | Number of shadow rects ( > 1 if the window is nonrectangular )
5 | A list of rects specifying shadow extents for each rect.

In the case where there is more than one rect, the compositing manager
should automatically clip shadows  which are not "border" shadows.
>
> I am aware that normally specifications are written in docbook.
Unfortunately
> I don't know docbook at all, but I know LaTeX therefore I wrote the
draft in
> LaTeX. Attached you find the tex document and a compiled pdf.
>
> If someone has an idea how to collaborate on the document, please tell me.
My
> only idea so far is to setup a special repository on gitorious.
>
> Looking forward to your comments.
Thanks,

Sam
>
> Regards
> Martin Gr??lin
>
>
> [1]
>
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.cpp?view=markup
> and
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.h?view=markup
> [2] http://blog.martin-graesslin.com/blog/wp-
> content/uploads/2010/08/compositing.pdf.tar.gz
>
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>
>


-- 
Sam Spilsbury
Compiz Project.