[compiz] [RFC] Draft for a compositing manager specification

Sun Aug 15 22:21:22 CEST 2010

On Sunday 15 August 2010 16:19:04 Sam Spilsbury wrote:
> 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.
yes that's what I want to have and that's why I just wrote down the status quo 
in what KWin provides and Compiz implements in the kde-compat plugin.
> 
> 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.
versioning sounds like a good idea.
> 
> 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.
we currently use both desktop and group. Class is not supported, I just added 
it as our effect in general supports it (all windows of gimp). An idea would 
be to just use one hint with a type field indicating desktop, group or class.
> 
> 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?
In fact we would like to have a special window type for the dashboard as it's 
more special than just being fullscreen and keep above. But that's something 
either for NETWM or just for KDE as it's really Plasma specific. I just added 
the dashboard as it's mentioned in the WindowEffects namespace. It's propably 
one of the effects we don't need in a spec.
> 
> 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 thought about it and it might be a good idea to let the window influence the 
shadow. I guess our designers would love to have that for unmaged windows ;-)  
And I would also like KRunner to not have a clickable shadow.

What about allowing the window to pass handles to pixmaps to be used as 
shadows? Plasma's SVGs use eight elements to build up shadow/border:
* topleft
* top
* topright
* right
* bottomright
* bottom
* bottomleft
* left
Except the corner elements the elements could be tiled or strechted. I think 
that would fit very well for normal windows as well as for windows with a 
special shape. And that would fit very well into our rendering system for 
decoration shadows and I think also in Compiz's pixmap based deco plugin. It 
would be more flexible than just a color (e.g. some gradient, top light, 
etc.).

Of course we would need to write a new shadow effect, but it's completely 
broken in 4.5 anyway, unmaintained and I think nobody knows the code and cares 
about it due to the decoration 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=mar
> > kup and
> > http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.h?view=mark
> > up [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
-------------- 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://mail.kde.org/pipermail/plasma-devel/attachments/20100815/689db18b/attachment.sig 