Re: Notes on the Metacity compositor

[Havoc Pennington <hp redhat com>]

Dan Winship wrote:
> Compiz could still display the window on both cube faces, but the EWMH
> doesn't provide any way of explaining that state to anyone else, so
> other EWMH-based tools like the pager would see the window as being on
> only one face at a time (and would show it as being truncated at the
> edge of that face). (Admittedly, this problem exists in the viewport
> model too, but only on the edge where the left and right sides of the
> virtual desktop meet, rather than at every edge.)

There's already a workspace geometry provided to the pager, so I bet all 
you'd need to convey to it is a single bool for whether windows overlap 
in this way, and then when drawing the mini-windows on the 
mini-workspaces change the clip region so it always includes all the 
mini-workspaces instead of just one. Or something like that.

Even if this isn't fixed, it seems a like a not-very-bad bug. It's not 
clear to me what I'd expect when a cube is mapped onto a 2D grid anyway ;-)

I don't know exactly how it would all play out, I just think it makes 
life simpler if everyone pretends EWMH didn't have the second gratuitous 
way to implement the same thing (workspaces). The only reason it exists 
AFAIK is that some WM authors wanted to implement 
workspaces-inside-workspaces, which I consider nuts.

I could flip a coin for whether windows should overlap workspaces (no 
strong view), but I do have a strong bias against having two 
slightly-different-but-almost-the-same concepts of workspace, one nested 
inside the other...

Assuming that bias, there's no real point having two ways to implement 
the one concept of workspace, instead you just want a flag for whether 
windows overlap...

GNOME right now basically just pretends EWMH doesn't have the viewport 
thing.

Anyway, not trying to push you around just offer historical context ;-)

Havoc