After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 152003 - Proposal: make the stack of windows be tracked per-workspace
Proposal: make the stack of windows be tracked per-workspace
Status: RESOLVED DUPLICATE of bug 87531
Product: metacity
Classification: Other
Component: general
2.8.x
Other Linux
: Normal minor
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks: 155452
 
 
Reported: 2004-09-06 17:50 UTC by Elijah Newren
Modified: 2004-12-24 00:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Elijah Newren 2004-09-06 17:50:44 UTC
If a user raises or lowers an on-all-workspaces window (which could also be done
indirectly by clicking on it to focus it) and then moves to a workspace they had
previously used, they may be surprised to see that their desktop has been
modified (the stacking order has changed).  This is perhaps mitigated by the
fact that the pager immediately shows the reshuffling of stacking on all
workspaces, but it's kind of confusing to see all workspaces being modified just
because of something you do in the current one.

Note that bug 97635 was filed about sticky windows retaining focus on workspace
switch and was fixed by making mru lists be per-workspace.  I think making the
stack be per-workspace (in addition to continuing to be per-screen as well) is
consistent with that change.

See also bug 87531 (whether or not to show sticky windows in the pager, plus
some similar issues), which is partially related.
Comment 1 Elijah Newren 2004-12-24 00:06:52 UTC
Actually, I'm not so sure this is necessary anymore.  The previous user model was:
  1) I start on some workspace with some existing stacking of the windows
  2) I move to another workspace; some windows happen to also be on that
     workspace (the "on all workspace" windows that simultaneously exist on
     all desktops)
  3) I interact with the omnipresent windows, and am surprised to see the
     stacking change in the pager for the workspaces that aren't being used.
  4) When I return to the original workspace, the stacking indeed has changed
     just like as shown in the pager.
The surprise is "I'm not on that desktop--why did the windows on it move?"

Since the behavior in bug 87531 is going to be implemented (see bug 156182),
that means that the user model would now be:
  1) I start on some workspace with some existing stacking of the windows
  2) I move to other workspaces, and some windows come with me to whatever
     desktop I go to (the "on all workspace" windows that "migrate" with the
     user)
  3) I interact with the migratory windows, but that only affects the current
     workspace in the pager (since that is the only place those windows appear)
  4) When I return to the original desktop, all my windows have their original
     stacking, except for the ones that travelled with me from desktop to
     desktop.
Here, I don't think there's a surprise because the thought is "The windows that
moved with me had to get shuffled back into the desktop when I returned."

So, I'm going to close as a duplicate of bug 87531.

*** This bug has been marked as a duplicate of 87531 ***