mapping of minimized windows

[Sam Spilsbury]

2010/4/23 Michel Dänzer <michel at daenzer.net>:
> 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
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg



-- 
Sam Spilsbury