Re: [compiz] [RFC] Draft for a compositing manager specification
On Mon, 23 Aug 2010 12:09:34 -0700 "Aaron J. Seigo" said:
> 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.
aaah ok. cool.
> > 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.
that's generally a problem for a general spec... generally... :)
> > 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.
well - i think that you CAN do this with a combo of both. use cm hints as a "do
an effect at all" and use netwm hints (eg netwm window type, combined with
name, class and a bunch of rules to "match stuff") to get all the specific
effects you want your your desktop env. what i'd like is to not have this spec
blow out from "well now we have slide in" then in 6 months "well add zoom in"
then a "flip and fade in" then a "rotate in" then a "explode in" and the list
goes on. i 'd like to stop going down the specific effect path and leave that
up to the cm decide precisely what effects they are, how they work etc. etc.
and have more of a coarse-grained switch to say "but noo dont do
any of your fancy goop on me!" for example. if it does do "fancy goop" there is
more than enough information in name+class+title+netm window type+wm role and
so on to do this there.
> > 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.
ooh i think you mis-understood me. the rect region within the source window is
optional.. and it is the "source" for the effect. eg IF you slide, or soom or
rotate + zoom in - the window as a WHOLE appears to transition "from" this rect
within the source window on screen to its final
Re: [compiz] [RFC] Draft for a compositing manager specification
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
Re: [compiz] [RFC] Draft for a compositing manager specification
On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin said: hmmm aaah ok! got it. read it. summary: "eeek". my simple view of this spec is that "almost all of it is highly kde/desktop specific and is not supportable in a general sense". now i hope you don't all hate me for this... but i'm going to have to do some ripping and tearing. :) flame me if you must, but this is in the name of "a spec others can actually use and follow". if you wish to keep a lot of thses kde specific - then fine, but they don't belong in a generic cross-cm/wm spec. (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 background as your document seems to not know about this). 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 for what i speak of but it's pretty much another unmapped window that has a root property point to this window, and this window has a property pointing to itself of the same atom/type - if this check passes then the cm is there and alive and you can rely on the properties it presents. if this window is destroyed or doesn't exist with a stale root property, then the cm died/vanished and any info you find floating about is not valid). 2. i pretty much have to say no to most of the spec - it's HIGHLY specific. the only thing i'd keep from it mostly intact is the shadow spec. and even then i'd morph this into a VISUAL_HINTS spec for a property set on a client window. this would be a property of type ATOM that would be a list of 32bit types (atoms) to indicate suggested visual properties for the cm to use. a list of these would possibly be: NO_SHADOW <- please don't provide any depth/shadowing/glow/other effect "outside the window frame" - use this window as-is and let the client just provide a set of raw (A)RGB pixels in a block. i dont think having clients control precise shadow size, color, blurriness etc. is viable. just a rough hint here is all that is needed. NO_TRANSITION <- please do not provide any transitioning effects (slide, fade, zoom, rotate, whatever) as the client probably does some effect of its own and simply is asking for a set of (A)RGB pixels within which to do its effect so doing your own effect will probably interfere badly with the client's rendering. NO_MODIFY <- never modify the pixel output of this client. sometimes the compositor may "gray out" inactive windows, or when in "alt-tab" or "select a client window" mode it may dim/fade etc. windows other than the selected one. the window with this hint would like not to have this dimming/fading applied. it may be a panel, or OSD window or maybe just some innocuous visual decoration on the screen. (we can add more...) these are hints - cm may choose to ignore them. as you suggested a list of what the cm will honor in a root property (with validity check) will be good. 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. 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). 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.
Re: [compiz] [RFC] Draft for a compositing manager specification
On Sunday, August 15, 2010, Martin Gräßlin wrote: > On Sunday 15 August 2010 16:19:04 Sam Spilsbury wrote: > > 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. Plasma Desktop isn't the only system out there with a dashboard; it could possibly be the only one on X11, but there is the MacOS dashboard as well. it's a generally useful concept and one that is, as you note, quite different from just "keep above". right now we do a nice appear transition, blur behind, etc. as part of the dashboard effect and then that window is placed full screen above all other windows; but that presentation is something that should be completely up to the window manager imho, so that it can easily be adjusted between window managers (or over time) without touching the application code. the app should just say "here is a dashboard window ..." > 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. it would be nice, though, so that plasma-desktop (and any other future app providing a similar facility) can work nicely in other window managers. -- 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 signature.asc Description: This is a digitally signed message part. ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
On Tue, 17 Aug 2010 08:49:28 +0800 Sam Spilsbury said: > On Tue, Aug 17, 2010 at 8:34 AM, Sam Spilsbury wrote: > > On Mon, Aug 16, 2010 at 8:37 AM, Samium Gromoff > > <[email protected]> wrote: > >> Good day! > >> > >>> 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. > >> > >> Please, forgive me if I'm making a mistake, but otherwise, I strongly > >> suspect that the Englightenment folks would be an important auditory to > >> factor in. What do you think? > > > > Yes, that is a good idea. Can they be CC'd in? > > The key enlightenment developer has been CC'd in. i'm in. :) just to be sure - this is about: 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? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[email protected] ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
Am Sunday 15 August 2010 schrieb Martin Gräßlin:
> On Sunday 15 August 2010 16:19:04 Sam Spilsbury wrote:
> > 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.
Do you really want to let clients control shadow color, dimensions & offsets?
Shadows resemble a light model, but with such setup they'd probably end up
like psychodelic ;-)
("I - that is /ME/ - is the most important client on the block and I - that is
*ME* - want the biggest and most colorful shadow!" :-)
Even if not, it would end up like Gtk+ an Qt look different - again :-(
What we do need are reliable hints on whether the window
- does not want a shadow at all ("OSD" type)
- can use "normal" (rectangular) shadows despite using an ARGB color table or
(slightly) shaped. If not it should be not a big deal to copy the alpha part
of the window texture and blur (and cache) it to form a shadow.
Cheers
___
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
On Sunday 15 August 2010 23:14:48 Thomas Lübking wrote:
> Am Sunday 15 August 2010 schrieb Martin Gräßlin:
> > On Sunday 15 August 2010 16:19:04 Sam Spilsbury wrote:
> > > 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.
>
> Do you really want to let clients control shadow color, dimensions &
> offsets? Shadows resemble a light model, but with such setup they'd
> probably end up like psychodelic ;-)
> ("I - that is /ME/ - is the most important client on the block and I - that
> is *ME* - want the biggest and most colorful shadow!" :-)
> Even if not, it would end up like Gtk+ an Qt look different - again :-(
Yeah that's a serious issue, I am afraid of the same thing and thought about
it before posting the idea with the pixmaps. I think the API above is too
simple and you can't really get the light model. If you have to specify the
pixmaps you will have to think about what you want and correctly implement the
light model. But that's probably also only wishfull thinking.
Nevertheless I think we need a way to let clients influence the shadows. The
CM can't know the light model of the client and just assuming "We have Oxygen"
does not work, as there is also GTK. So for undecorated clients it would make
sense to allow influence on shadows, while for decorated clients the WM should
have the control. I must say that I really like the way it's handled in KWin
with giving control of shadows to the decoration. So we could specify that the
decoration is responsible for the shadows. The drawback of this is, that if
some $STUPID_APP thinks to be important and wants to have red shadows, it's
going for doing stupid things like client side decorations (CSD). So thinking
about it: we have the chance to discourage usage of CSD and explicitly allow
the CM to ignore shadow change requests.
signature.asc
Description: This is a digitally signed message part.
___
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
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 Description: This is a digitally signed message part. ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
On Tue, Aug 17, 2010 at 8:34 AM, Sam Spilsbury wrote: > On Mon, Aug 16, 2010 at 8:37 AM, Samium Gromoff > <[email protected]> wrote: >> Good day! >> >>> 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. >> >> Please, forgive me if I'm making a mistake, but otherwise, I strongly >> suspect that the Englightenment folks would be an important auditory to >> factor in. What do you think? > > Yes, that is a good idea. Can they be CC'd in? The key enlightenment developer has been CC'd in. >> >> -- >> regards, >> Samium Gromoff >> -- >> "Actually I made up the term 'object-oriented', and I can tell you I >> did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote) >> ___ >> compiz mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/compiz >> > > > > -- > Sam Spilsbury > -- Sam Spilsbury ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
On Mon, Aug 16, 2010 at 8:37 AM, Samium Gromoff <[email protected]> wrote: > Good day! > >> 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. > > Please, forgive me if I'm making a mistake, but otherwise, I strongly > suspect that the Englightenment folks would be an important auditory to > factor in. What do you think? Yes, that is a good idea. Can they be CC'd in? > > -- > regards, > Samium Gromoff > -- > "Actually I made up the term 'object-oriented', and I can tell you I > did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote) > ___ > compiz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/compiz > -- Sam Spilsbury ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
Good day! > 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. Please, forgive me if I'm making a mistake, but otherwise, I strongly suspect that the Englightenment folks would be an important auditory to factor in. What do you think? -- regards, Samium Gromoff -- "Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote) ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [RFC] Draft for a compositing manager specification
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 > > 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
Re: [compiz] [RFC] Draft for a compositing manager specification
Hi Martin, All. On Sun, Aug 15, 2010 at 8:57 PM, Martin Gräßlin 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/compiz > > -- Sam Spilsbury Compiz Project. ___ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
