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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
