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

[Aaron J. Seigo]

On Saturday, August 21, 2010, Carsten Haitzler wrote:
> On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin
> (btw - e17 has had a gl and software compositor for a little while now :)
> if you include bling - a xrender one for many years, so i'm in the
> same/similar boat with you guys, but with a difference - same compositor
> works in both software fallback client-side mode, opengl, with and without
> texture-from-pixmap AND works in opengl-es2.0 so in some ways. just for

this isn't much different from kwin.
 
> 1. properties on root listing what is supported. fine - but big hole. no
> way to know if properties are valid. if cm crashes/exits and leaves them
> there, they will be stale and invalid. need a validity check mechanism
> much like netwm - or stick them on the validity check window (see netwm

good point..
 
> 2. i pretty much have to say no to most of the spec - it's HIGHLY specific.

probably because the apps that need these effects have highly specific needs 
knowable only from witin the app.
 
> 3. the "slide" interaction imho is way too basic and limiting. let's stand
> back and think. what you are asking is for the cm to become a generic
> effects engine with a bunch of apis for very specific effects that you
> control in pretty raw detail. the api is a property on a window as such.
> let's stand back here and turn this into something doable. let's combine
> this with the above visual hints atom. let's add another type atom to the
> visual hints list:
>   TRANSITION <- highly suggested you transition this window in (or out on
> hide) somehow (fade, zoom, flip, slide, whatever). in additionally an
> extra property will provide a suggested "source" for the transition.
> discussed next.

while i'm fine with making the animations more semantic ("transition in") 
rather than specific ("slide in"), we then end up with issues of 
configuration. "transition in" would have to be a one-size-fits-all-windows 
effect otherwise we end up with windows requesting what kind of transition, 
client-side configuration of these things ... not good.

this would give us a way to implement a requested feature: that panels fade in 
rather than slide in, without annoying the rest of the world who prefers 
sliding. i'm not sure it really matters all that much, though, to be honest. i 
suppose this is mostly for different window managers to do things differently 
from each other.

> 4. a transition source property on the client window. TRANSITION_SOURCE is
> a hint as to a "source window id + optional rectangle within that window
> that this one may come from. property format is CARD32 with the elements
> being: [SOURCE WINDOW ID] <- required. may be root window id or any other
> window id on screen. the geometry of this source window id is used as the
> source of the transition hint UNLESS another 4 members of the property (5
> CARD32's instead of 1 total) are provided.
>   [[X],[Y],[WIDTH],[HEIGHT]] <- optional extra 4 CARD32 members that define
> a rectangle (top-left at 0,0 in source window id, all CARD32's are signed
> 32bit integers and width and height must be greater or equal to 0 (values
> less than 0 are reserved for future meanings).

in which circumstances would a rectangular part of the window be a sensible 
thing to apply an effect to? in my experience, it's either the whole window or 
a shape, but rarely if ever an internal rectangle.

the only time we currently use such a target rect is for effects on other 
windows, such as to animate a window on minimize/restore to/from the relevent 
tasks widget.

> 5. EFFECT_NOW atom property. this is a property on a window that contains 0
> or more values of type ATOM (32bit) that request an effect to be applied
> on the given client window. highlight, unimportant, urgent etc. etc - yes
> i know this overlaps netwm. i'm not totally done thinking this over, but
> it's me trying to do your "highlight windows" thing in a more generic way
> where a client requests to be made visually prominent (or the opposite) at
> some point.

highlight windows is currently used by things like the window listing / tasks 
widgets / taskbar to show specific windows. it's not actually related to the 
netwm behaviours. perhaps the naming could be better, or documented clearer.

> 6. present windows... i think this just is better left to be entirely up to
> the cm+wm to do at its leisure. the only thing i'd suggest here is perhaps
> the cm being nice to external processes that want to do ushc "task
> manager" things - same with window preview etc. etc. - cm sets a property
> on the frame window with the current pixmap id of the
> composited/redirected pixmap. any client can pick up this property and the
> pixmap id, and follow the property as it changes to implement this
> themselves in whatever way they want using the pixmap id. (the window its
> on itself provides for visual id and thus argb vs traditional "solid"
> pixmaps).

and then we end up implementing placement and movement logic in multiple 
places. i'd rather see this remain completely inside the window manager where 
the logic already is so that it is consistent and code duplication is 
eliminated.
 
> 2. client-side pixmaps. instead of forcing a window to be redirected by
> xcomposite a client can already be composite-aware and just allocated and
> render its own pixmap. it can set this as a property on its window. this is

this would be really nice for toolkits that already do internal buffering of 
entire window surfaces.

> 4. the ability for cm to tell app "you are transitioning now" vs "you have
> now finished transitioning and are now visible/invisible". this is

this would also be useful in various cases as you note... i like it :)

> 5. cm provided window backgrounds. this one is controversial. this means
> that toolkit and wm and cm have to all agree. but the idea is so that you
> can have consistent frame + window backgrounds and transitions (ie smooth
> title+menubar etc. etc.). the client now always provides an argb window
> that has no background at all - always transparent where it used to have
> the base window background. it lets the cm provide this and the cm
> composits the client app window on top. problems here are: a) agreeing on
> background color and texture etc. so it doesn't interfere with widgets (eg
> text labels etc.). up for discussion but some kind of hint here with
> "light", "dark" or specific rgb colors that the cm or the app use to say
> "keep clear of these please if you want to be readable".

... a global color scheme, in other words. all the toolkits already have 
these, of course, but standardizing this would be a great step forward.

> not sure which
> way around it should go (ie should cm define the "keep clear" colors and
> toolkit obey, or vice-versa).

if the cm defined the color scheme, then the toolkits could use their existing 
color scheme support to read that, no? as long as things don't overly 
complicated (like a background texture that requires different color schemes 
in different parts of the window) then it shouldn't be a problem, afaics.

> this opens up a can of other worms - like cm
> and app agreeing on the cm providing things like resize handles on the
> bottom-right that the app "keeps clear of" when filling content or..
> vice-versa? maybe some kind of hints the app can provide as to the edges
> of its inner window and how much u'd like "frame" to stretch into the app
> by (to make sure the menubar or statusbar etc. are always nicely filled in

would it be enough to define a set of well-known "zones" in a window that can 
be used by the client to define where these things are in the window? it would 
be really nice if the client could provide sets of regions tagged with 
different semantics ("menus/controls", "status area", "toolbox", etc.) as this 
would prevent getting stuck with "menus are a rectangular region at the top; 
status bars a rectangular region at the bottom; etc." forever. perhaps this 
would be too complex, however.

> like the title would be) etc. etc. up for debate. this also opens up the
> can of worms that was canonicals "window indicators" - but providing a
> nice clean protocol for these in much the same vein as a proper systray
> spec, would be nice.

agreed, though i'm not really sure what the real world benefits of these 
"windicators" will be; for them to be really compelling, imho, a good amount 
of design work is still left un-done so that such add-ons to the title bar can 
gain access to "the document this window is showing" in ways that aren't full 
of assumption and limitation. we're working on these kinds of issues slowly, 
with a few groups working on things like "how to expose the relationship of a 
window and the document(s) it is presenting"; this is something we (KDE) are 
working on in combination with Nepomuk and Plasma's activities. there's a lot 
of cooperation between different processes required to really make these 
things compelling, and i don't think we fully understand all of what's 
involved in real-world practice yet to start building specs around such 
things.

eventually, though, yes :)

> though at this point i think we may have exited the
> cm spec and entered a netwm spec.

yep :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100823/07a686fc/attachment-0001.sig