2010/4/23 Michel Dänzer <[email protected]>: > On Fre, 2010-04-23 at 11:22 +0200, Florian Martys wrote: >> >> Why I am here: >> I'm new to the mailing list, so please excuse potential naivety. I >> filed a bugreport against xorg package in Ubuntu on Launchpad* and >> have been told that the problem is upstream and I have to ask the xorg >> team in their mailing list, here I am. >> >> What I am here for: >> I am using standard Ubuntu desktop (10.04) with Desktop effects >> (Compiz Fusion). First, when using ALT-TAB to switch between windows I >> can only see an icons instead of window previews when toggling over >> minimized windows (bugreport**). Second, when using the Scale >> plugin*** (WIN-key aka SUPER+A or W; extra desktop effects have to be >> enabled), which is similar to the Exposé effect on Mac OS X, I can >> only see windows that are avitve (i.e. not minimized), there is not >> even an icon replacing the missing running application that are >> minimized, minimized applications/windows don't even show up. >> >> As I understand this is not a bug, but more or less by design, because >> minimized windows are not mapped anymore. However it is a usability >> bug when using ALT-TAB or the Scale Plugin with the Desktop Effects. > > It's up to compiz. It could (optionally) either not unmap minimized > windows or just keep the last pixmap for them. I think it would have to > be optional because in both cases minimized windows would use up more > resources than before.
Actually, it's not up to compiz. I think this would be a better thing to standardize on EWMH. The problem with "minimize" is that it is both an input AND output "unmap" of the window as it currently stands. I'm aware that minimization is a window-manager concept strictly speaking, but it isn't possible to properly implement a system where by we minimize the window such that it doesn't expect input but keep it's output around. It is perfectly possible at the moment to use a combination of removing a window's shape rects, not drawing it in the main paint loop and then drawing it when we want it for minimized thumbnails. The problem with this is that you have to trick the window into thinking it is visible to the user. While this will work in 99% of cases (since most windows are not input-demanding), it does break some games, which will not pause or continue to expect input (the user loses) if they are minimized but not unmapped. We also have the option of sending windows the unmap event but not freeing their pixmap data. Windows don't expect input this way, but they do stop drawing, which isn't what we want for videos, say. Also, this usually just leads to corrupted pixmap data one way or another. A better thing to do would be to add some kind of window property standardized by EWMH that says "this window cannot receive input events but is still visible". I assume that most toolkits could latch on to that fairly quickly and any applications that don't follow this standard would be broken. Adding this through EWMH has the added benefit of working seamlessly across mutter, kwin, enlightenment, compiz etc etc etc and it also means that it will work across all applications that implement it correctly. As a side, EWMH should probably take on addressing more of these issues that come up with compositing window manager and application interoperability. > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > _______________________________________________ > [email protected]: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg -- Sam Spilsbury _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
