Re: Compositing managers spec

[Sanel Zukan <sanelz gmail com>]

Dana Jansens wrote:
> Currently a WM can ping a window to see if it is alive or not.  When
> it is no longer responding, it may want to provide different functions
> on that window, such as killing it.  I noticed the cairo-compmgr has a
> plugin to grey out windows which are not responding - similar to
> compiz.  However, without some coordination, the timing for the WM and
> CM changing their ideas about a window is going to be very awkward.
> 
> Therefore, I propose the _NET_WM_STATE_NOT_RESPONDING.  This would be
> a state that the WM should probably ignore requests to set it entirely

This sounds cool! :) Thinking about this... when wm set it to
_NET_WM_STATE_NOT_RESPONDING it will be much easier to write/add some
external monitoring apps to watch unresponsive windows/apps (at least a 
little bit ;)).

Denis Washington wrote:
> One thing I proposed before that I think would fit nicely into a CM spec
> would be a flag to tell the CM "don't mess with this window (e.g. don't
> do animations like fade-in on opening the window), just display it
> as-is".

+1

Nathaniel Smith wrote:
> Create a window with a RGBA visual and use the alpha channel; if a CM
> is running then this will just work, no need for any extra properties.
> (This kind of possibility is why gtk+ includes an api just to let apps
> find out if a CM is running, for instance.)

Aaa, cool; thanks for the tip!!! I never tried via this way...

Dennis Kasprzyk wrote:
> - Taskbar preview handling

For minized windows preview? How about keeping preview images on server
side so they can be picked up by single property, like
_NET_CM_MINIMIZED_LIST (or with better name)?

> - _NET_CM_SUPPORTED to inform apps about composite manager features

+1

> - Give applications control to some features of the composite manager

Isn't this cm specific? IMHO, this will limit cm's to implement exactly
some features, althought author's intent is not to do so.

> - Maybe a desktop background spec to define pixmaps (and their properties)
> for multiple viewports/desktops

For me, this looks like a candidate for EWMH :)

Carsten Haitzler wrote:
> * do not delay my output to try coalesce rendering updates (if the composite
> manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from
> xdamage events to try and wait for more updates to occur so it can update to
> screen in 1 go and not in lots of small updates, making window re-draw look

Hm... isn't the point of xdamage (and the family) to do a lot of small
but precise updates?

> "smoother" as it happens at once and not bit by bit, but some apps - like video
> players and games, will definitely not want this as they probably do whole
> updates in 1 go anyway).

So, you are proposing removing delay in updates or waiting for a larger number
of events and update everything in once or maybe signaling cm to do
update for the whole screen, e.g. when video player goes fullscreen?
(I didn't understaind this well)

> * please provide a solid background even if my window is ARGB because i am
> allowing the wm border/decoration to define the backing of my window and the
> contents should be composited over whatever backing the WM provides (the
> problem with window decorations is that they are separate from window
> background. it is impossible to reliably have a titlebar seamlessly continue
> into the app window with textures, patterns, shading etc. without fastidiously
> fixing up themes/widgets/whatever of every toolkit. if toolkits were to render
> to ARGB dest windows and simply NOT render a background color/pattern for the
> window, but leave it transparent with all buttons, other widgets, labels
> rendered onto a dest-alpha transparent ARGB window, then the window content is
> a composited overlay on top of a window frame "Decoration" that also defines
> the decorations UNDER the window contents, allowing for smooth transitions from
> titlebars and borders into the window contents).

But, this sound for me more like a toolkit issue. I'm not sure how gtk/qt/others 
will adopt this, but I'm sure this will not go easily in FLTK (except if I create 
my own branch).

Fredrik Höglund wrote:
> One comment though is that I think the application still needs to be
> able to specify an area (a rectangular one will probably suffice), where
> the window background really should be transparent. An application like
> ...
> Window managers will also have to advertise support for this feature so
> applications can know if they can use it. I imagine that support for this
> feature may also depend on the window manager theme being used.

Hm... why wm's have to do this? Like Nathaniel noted, window can use RGBA
visual. On other hand, supporting transparency in themes, at least for
me, looks like wm specific feature.


-- 
Sanel Zukan
http://equinox-project.org