GNOME Bugzilla – Bug 87531
"Sticky window" inconsistent with "exists on all workspaces"
Last modified: 2005-01-26 19:49:38 UTC
There are two slightly different user models for sticky windows: the sticky window, and the window that exists on all workspaces. A sticky window is a window that follows you, whichever workspace you switch to. A window that exists on all workspaces is a window that doesn't follow your current workspace, but rather pre-exists on all workspaces (magically) before you even switch to them. I think there should be a consistent model used in gnome, since these are different concepts. For instance, with the workspace switcher, one would to see sticky windows on all workspaces assuming the second model (since the windows exist on all workspaces); but only on the current workspace assuming the second model. Right now, these concepts are mixed. Sawfish has a "sticky" option, but the workspace switcher shows sticky windows on all workspaces. Personally, I prefer the "sticky" model to the "exists on all workspaces" model. I believe that "exists on all workspaces" makes for an easy-to-understand option when a newbie reads it on a menu item (where sticky doesn't mean anything unless one already understands the concept), but that the actual model of having a window exist in an infinite number of locations simultaneously is weird and hard to get a grip on (it has no equivalent in the real world) and that it is annoying, confusing, and distracting the see the same rectangle on every workspace. It feels intuitive to me that my sticky windows are following me around wherever I look (like a dirty spot on my sunglasses). So since I prefer the sticky concept, I'm filing this bug with the workspace switcher, because it conforms to the "exists on all workspaces" concept, and shows sticky windows on all workspaces instead of just the current workspace.
Easy enough to change, I want to be sure there's consensus though. Also right now the metacity menu says "On all workspaces" - I don't think "Sticky" is a very good thing to put in the menu - what should it say instead? And what do I replace "Only on workspace N" with - "stay on workspace N"? Anyway please advise on rewording metacity window menu terminology.
Hmm... admittedly I have absolutely no usability data to go on hee, but I'm not necessarily sure I agree... my gut reaction would be that the 'exists on all workspaces' concept might be easier for new users to understand. Say for example the user remembers the window layout of the workspace they want to switch to, and wants to use the Workspace Switcher to switch to it. If that workspace contained one or more sticky windows, then they're not going to see anything corresponding to what they remember in the workspace switcher, which could even lead them to think that the workspace they want has disappeared altogether. One thing that maybe doesn't help the current implementation is that when they're focused, 'on all workspaces' windows are shown as focused on all workspaces in the switcher, rather than just in the current workspace. That's maybe kind of confusing for a new user too. This is all pure conjecture on my part though, hopefully there's somebody out there who's done some sort of study on this stuff :)
Good points, Calum. One additional reason that "Put on all workspace" might be easier to understand for new users is that a "sticky" window has hidden state -- you can't tell what the sticky option does until you switch viewports and possibly notice that the window layout isn't what you expected. But when a user clicks "Put on all workspaces" in a window's context menu, the workspace switcher immediately displays N windows for N workspaces, which is pretty powerful immediate visual feedback. Of course, I have a personal distaste for the way it looks when a single window covers the workspace switcher. But it might be better if focusing an omnipresent window didn't focus all copies of the window, like you suggest. Can we agree that this is a bug? It might be good to fix it before evaluating the issue further. If gnome keeps the "on all workspace" model, though, I don't know how we could reconcile the weirdness of having a single window exist in multiple locations simultaneously. I don't think that this is a trivial problem, either; it seems realy weird. Looks like you're right about the necessity of a user study. This isn't a cut-and-dry question. Havoc, if this *is* a really easy thing to implement, would it be possible to have a temporary toggle key in gconf to change between the two options? (I expect the answer is "not worth it", but it seemed worthwhile to ask. It could aid an informal user study.) Terminology brainstorm for the "sticky" option: "Always on visible workspace" with a checkbox "Always on current workspace" but 'current' is ambiguous "Always on viewed workspace" "Follow current workspace" "Follow visible workspace" "Stick to current workspace" Or maybe "viewed workspace"... or "active workspace"... My favorite is "Always on visible workspace". As for the "Only on workspace N" items... I think we can just remove them. A user can achieve the same effect as "Only on workspace N" by toggling "Always on visible workspace" and then clicking "Move to workspace N". Furthermore, I don't see "Only on workspace N" as being a very frequent operation that needs to be optimized beyond 2 menu operations, since it isn't that common to make a window sticky and then move it to a window that you aren't currently on. I can't imagine any frequent task that might involve that operation. So gnome goes with "sticky" over "on all workspaces", I would suggest A) leaving the "Move to workspace N" options on the Metacity context menus for both sticky and non-sticky windows, but making them greyed out for sticky windows, and B) naming the sticky option "Always on visible workspace", as a checkbox.
Hmm.. "Only on window N" doesn't even work for me. It switches to workspace N, and leaves the window sticky. Is this a known bug?
"only on window" should work, except that it crashes pretty often (I have a fix in my local copy). Are you sure metacity doesn't "flicker" (crash/restart) when you choose it?
I can't reproduce the problem anymore... hmm... weird. It works now.
Should we close this then?
Closing based on comment #6.
The "problem" I was talking about in comment #6 was an unrelated bug. As far as I know, the issue this bug represents (sticky vs. on all workspaces) is still present.
Created attachment 31197 [details] [review] Patch to make an on-all-workspace-window that has focus only show as having focus on the current workspace As per Michael's suggestion in comment 3, this patch fixes the unintuitive behavior of having an on-all-workspace window which has focus showed as being focused on all workspaces; hopefully this will help further evaluation of the main issue. This patch works by changing the logic from "is_active" to "is_active && on_current_workspace" for deciding whether to draw the window as focused. Note that with this patch, libwnck behavior is still a little disconcerting because clicking on an on-all-workspace window in one workspace changes the stacking--on all workspaces. But that can be fixed with the patch in bug 100470 (well, it's close enough to a patch...) So, I suggest applying both to make things more intuitive before evaluation proceeds. (As an aside, my gut reaction is the same as Calum's, but I definitely haven't done any studies, hardly use sticky/on-all-workspace windows, and clearly haven't thought about this issue as much as Michael)
Actually, what I said above wasn't quite right. The correct statement is that the patch in bug 100470 would make it so that clicking on the small box icon for an all-workspace-window within the small square for the active workspace in the pager wouldn't cause a suprising restacking on all workspaces. However, clicking on the real on-all-workspace window (instead of clicking in the pager) would have this exact problem. I'm about to file a bug about that.
Putting this bug on the Gnome 2.8.x milestone because of the patch to fix the window-has-focus-on-all-workspaces issue.
*** Bug 132413 has been marked as a duplicate of this bug. ***
Comment on attachment 31197 [details] [review] Patch to make an on-all-workspace-window that has focus only show as having focus on the current workspace I just discovered that Michael filed bug 104486 about this side issue. So I'm marking this patch as "needs-work", because it should be filed under that bug.
It looks like we'll be implementing this soon. See bug 156182.
*** Bug 152003 has been marked as a duplicate of this bug. ***
Created attachment 35639 [details] [review] Implement new model This completes Havoc's request in bug 105665 (see bug 156182 for the summarized version), to enforce windows only being on one workspace at a time.
committed.
This new behaviour is really disconcerting, in that if you have a window that is "Put on all workspaces" the pager doesn't show this, you then click to another workspace (which is empty), and suddenly it's not empty. I've got so confused by this I had to revert the attachment 35639 [details] [review] to get something that felt sane.
Yeah, we need to make the wording changes that Michael suggested. I can summarize the basic issues: 1) We have allowed users to get used to something we don't want, and they believe that behavior is natural from their familiarity with it. 2) We now have switched models.... 3) ...but not completely. We persist in using wording that reinforces the old model (i.e. "Elijah is really lazy and ought to get off his butt and make the wording changes instead of trying to find someone like Crispin or Michael to do it") I don't think we should revert because (a) windows are thought of as objects and omnipresent objects aren't a good connection for users, (b) windows-on-multiple-workspaces is difficult to get right (see bug 165182) and isn't worth the effort (sticky windows are somewhat of a niche use case; but even among them there are lots of people who complained about the old behavior anyway--see bug 132413 in addition to this bug). I think we should just try to get our new model to "Just Work" (I agree that it doesn't quite do that yet because of the wording).
I don't think you mean bug 165182... There are lots of counter-arguments to those that are presented by Michael, and in fact, it it seems as though the consensus on this bug and bug 132413 was that this a WONTFIX. Even changing the wording won't help, as with this new behaviour the UI doesn't reflect reality, which surely is a very bad thing for the user, when I first say the empty workspace I thought I hadn't put my web browser on all workspaces, then went back to the menu, to do it again (on the assumption that something had broken) (sidenode: this is all at work, where I use gnome purely as a user, not a developer)
Right, I meant bug 156182. Yes, Michael pointed out some of them himself... I believe that changing the wording will help, because you are thinking "on all workspaces", which is just wrong. That's _not_ the reality. The reality is "travels with you" or "follows you". Like I said above, you got so used to the old behavior that you made assumptions from it in such a way that you didn't understand the new model. That was the problem with not switching over completely. :-) I'm really not set on keeping thing with Michael's model; I am aware it's not perfect--but neither is the old one. Both have inherent problems as pointed out in the first several comments of this bug. The fact is that getting the old model right is too difficult to be worth my while (especially since I don't use sticky windows). If it's worth yours, here is what you would have to do: 1) Get an EWMH addition approved on the wm-spec list to replace _NET_WM_STATE_HIDDEN with some quantity that is per-workspace (may be difficult--you have to get KWin, FVWM maintainers, etc. to buy that it's worth putting in the spec) 2) Patch both libwnck and metacity to handle the new state everywhere 3) Undo the patch here, and in bug 156182, and in bug 165259. 4) Convince Havoc that he wants these changes (he's the maintainer for both modules) For more details, see comment 10 of bug 105665.