GNOME Bugzilla – Bug 455654
change to window button menu
Last modified: 2020-11-07 12:36:00 UTC
In 2.19, the window button menu has two radio menu items for show on all/only on this workspace. In 2.18, there was only 1 menu item. IMHO this makes the menu unnecessarily longer without gain of clarity. A check menu item with "Always show on the active workspace" would be conciser and also more in line with the "Always on top" checkbox just above. The same applies for libwnck.
See bug 343108; rationale was HIG conformance, I believe. We can't simply toggle indefinitely. Personally, I don't have a preference as to the actual solution for this issue, but we either need to mark this as NOTABUG or else we need usability expert guidance and possibly HIG updates. Either way, we should probably add a special listing for either this bug or bug 343108 in our list of this-is-why-we-chose-what-we-did issues (stored in rationales.txt in SVN).
Please don't take HIG as a set of rules we can't bend. They are just guidelines, IMHO having two entries fills the menu needlesly and the effect of having a checkbox, two radio buttons and icons (the X and the _) is really untidy.
Calum, Matthew, Bryan: What say you?
The factors I know of for deciding between a checkbox or two radio buttons are: (1) Is this a choice with extremely high likely cost of error, such as in a backup utility, space station, or power plant? If so, use radio buttons. (2) Are you tight on space, and/or is this a place that deserves extreme elegance? If so, lean towards a checkbox. (3) Can a checkbox label make the meaning of both states obvious? If not, use radio buttons. Here, #1 isn't relevant. #2 is arguably relevant, because this is part of the window manager, which is omnipresent and therefore has higher standards of elegance. But by the same reasoning, I'd propose that this menu shouldn't exist at all -- it could be replaced with sufficiently memorable and bloody-minded keyboard equivalents, combined with a HUD of all workspaces (where, for example, you could drag a window from one workspace to another or onto an "Every Workspace" hotspot). I think the biggest issue here is #3 -- what label could you possibly give a checkbox item here to make the off value obvious? This is what Calum was saying in bug 343108 comment 4: "Always on Visible Workspace" won't do, because "Not Always on Visible Workspace" has all sorts of possible meanings.
(In reply to comment #4) > (3) Can a checkbox label make the meaning of both states obvious? If not, use > radio buttons. > I think the biggest issue here is #3 -- what label could you possibly give a > checkbox item here to make the off value obvious? This is what Calum was saying > in bug 343108 comment 4: "Always on Visible Workspace" won't do, because "Not > Always on Visible Workspace" has all sorts of possible meanings. "Make this window follow me when I change workspaces" (or rather a shorter phrase to that effect). That's what this function actually does (as you can see from the workspace applet, it's only present on the current workspace). Unchecking it will leave it where it is when you change workspaces.
(In reply to comment #5) > phrase to that effect). That's what this function actually does (as you can see > from the workspace applet, it's only present on the current workspace). > I'd actually suggest that that's a problem with the workspace applet (it's showing what X is thinking rather than the abstraction we're showing the user). I wonder whether we can't use the internal name for the attribute and call it "stick". :)
(In reply to comment #6) > I'd actually suggest that that's a problem with the workspace applet (it's > showing what X is thinking rather than the abstraction we're showing the user). I'm not following. Could you clarify? > I wonder whether we can't use the internal name for the attribute and call it > "stick". :) Uh, that wouldn't work. I thought of a few different things that could mean, then asked my wife what she would think a "stick" attribute on a window would mean and she added a couple more. Here's the possibilities of what a user may think of by a "stick" attribute (a non-exhaustive list, obviously): (1) Make it hard to move the window (it's stuck), (2) Make it hard to move the window offscreen (My wife was one of the early users of the edge resistance functionality I added to metacity a few years ago and may have been thinking of that), so that it's stuck onscreen, (3) Make the window viewport-sticky (which is how libwnck and the EWMH use the term "stick", libwnck uses "pin" for what metacity calls "stick") -- meaning, keep the window's position fixed on the screen een when the virtual desktop scrolls, (4) on-all-workspaces (how metacity previously implemented such functionality until we discovered corner cases that couldn't be fixed without ugly EWMH changes/additions), or (5) the current metacity definition of sticky--follows the user to whatever workspace they go to.
(In reply to comment #7) > I'm not following. Could you clarify? It's my fault: I wasn't thinking straight. (X qua X doesn't really know about any of this, iirc, because it's just done by us mapping and unmapping things; I was actually thinking about properties we set on the windows.) I mean that Metacity is presenting an interface to the user which shows that a window can be: 1) On one particular workspace, *or* 2) On every workspace. The workspace applet shows windows in the first case on their correct workspace, but it shows windows in the second case only on the workspace the user's currently looking at. chpe cited this as evidence that the window is "really" on the current workspace, and moves when the user moves. I was saying that it's actually evidence that the window applet is broken. The window isn't "really" anywhere, for reasons given in the first paragraph of this comment. Of course, I could be talking nonsense, so people should be free to correct me. It does happen quite often. :)
(In reply to comment #8) > I mean that Metacity is presenting an interface to the user which shows that a > window can be: > > 1) On one particular workspace, *or* > 2) On every workspace. This is not true. #2 is intentionally not implemented (anymore) and the wording was specifically modified to its current state to try to avoid such perceptions. Trying to implement that functionality led to ugly corner-case bugs that couldn't be fixed without some ugly changes to the EWMH that weren't worth it. I don't recall the details but I could look them up if you're interested. > The workspace applet shows windows in the first case on their correct > workspace, but it shows windows in the second case only on the workspace the > user's currently looking at. chpe cited this as evidence that the window is > "really" on the current workspace, and moves when the user moves. I was saying > that it's actually evidence that the window applet is broken. The window isn't > "really" anywhere, for reasons given in the first paragraph of this comment. The applet is not broken (at least in this case). Things did used to be broken, but I fixed them by not allowing windows to be on all workspaces (including modifying the pager to not show "sticky" windows on all workspaces).
Ah, okay, then I was confused, or very behind the times. Sorry about that. In that case, then, we should be making Metacity present the same abstraction as the applet does, and what chpe says in comment 5 seems to me to be the best way forwards.
> "Make this window follow me when I change workspaces" (or rather a shorter > phrase to that effect). And that shorter phrase would be ... what? I will be pleasantly surprised if such a phrase exists, one where both on and off states are understandable.
how about "Follow Me"? It's more in line with the other menu items such as Close, Move, Resize, which are worded as commands to the window. "Always On Top" is different because it's a description of what you want to window to be (hence the checkbox), but perhaps that should be "Stay on Top". By the way, why is "On" capitalized in "Always On Top" but not in the other menu items?
(In reply to comment #12) > By the way, why is "On" capitalized in "Always On Top" but not in the other > menu items? I'm pretty sure it shouldn't be.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.