[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: [compiz] [RFC] Draft for a compositing manager specification
From:       Martin =?utf-8?q?Gr=C3=A4=C3=9Flin?= <kde () martin-graesslin ! com>
Date:       2010-08-18 19:16:04
Message-ID: 201008182116.14540.kde () martin-graesslin ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 17 August 2010 05:00:19 Carsten Haitzler wrote:
> wm+cm now provides both frame AND window background (or is able to via its
> own frame styles) and application + toolkit now provides ARGB windows with
> what used to be the "window background" be transparent "assuming" it is
> composited onto the wm+cm provided background. so this means that wm+cm
> and toolkit need to at least agree on some content matters - like
> "contrasting colors" of wm base and toolkit widgets (labels etc.) and of
> course agree on how toolkit/app is to know this feature exists and can be
> provided, and then how the app will request it for the purpose of getting
> a "seamless" frame+title+app+bg experience. (the rest is just mechanics on
> agreeing on atom names to use, where to stick properties and what they
> mean and which data to expose/fetch where in what way).
> 
> am i on the same page?
No :-) The idea is to get a standard on how clients and wm can activate 
effects, animations and so on.

I put a very first, very KDE-centric draft online: 
http://blog.martin-graesslin.com/blog/wp-
content/uploads/2010/08/compositing.pdf.tar.gz

["signature.asc" (application/pgp-signature)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]