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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
