GNOME Bugzilla – Bug 581209
Sticky windows in the overview
Last modified: 2012-10-30 23:42:21 UTC
A sticky window will appear in every workspace preventing the minus button to show on that workspace in the overlay mode.
Created attachment 142082 [details] [review] Proposed patch This patch fixes issue with minus button with sticky windows. It also dim the opacity of sticky windows in order to make them visually separable from the actual windows.
*** Bug 581211 has been marked as a duplicate of this bug. ***
We need an overall design for overview sticky window handling. Currently we show sticky windows in each workspace in the overview, causing both this problem (workspaces are never empty and hence never removable) and 581211 (workspaces are not empty when they're created, which the code is not expecting and doesn't handle correctly). Another possibility would be show the sticky window in the active workspace, but not any other workspaces. Another possibility would be to not show sticky windows at all in the overview.
Not showing sticky windows can not be an option. That would confuse user since she would not be able to grasp what's wrong with a specific window. Sometimes you set sticky status to window and forget that in a long session. Showing sticky windows on every workspace is not a good practice in my opinion as well. Though a sticky window on active workspace should be notified to user some how. Because she would like to move that windows, and upon failure she could think it's a *bug* or misbehaviour. An icon set for sticky windows would prevent this. And if possible a visual feedback about a window is sticky on overview on drag would also be helpful. Current patch has this feedback on sticky windows shown on other workspaces as a decreased opacity. After a second thought, showing sticky windows with decreased opacity (since they are kind of ghost) on active workspace and not showing those windows on other workspaces can be an optimal solution.
*** Bug 602978 has been marked as a duplicate of this bug. ***
*** Bug 606148 has been marked as a duplicate of this bug. ***
Review of attachment 142082 [details] [review]: Marking an old patch as needs-work to get it off my patch queries. (in this case, it's design work that was needed. How do we want stick windows to behave?)
Honestly, it doesn't really matter that much. But Ok let's see. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505530 says, "A window manager which implements a large desktop typically offers a way for the user to make certain windows 'stick to the glass', i.e. these windows will stay at the same position on the screen when the viewport is moved." Metacity and Mutter currently use the following text in the interface: "Always on visible workspace" Which unfortunately slightly disagrees with http://library.gnome.org/devel/gtk/2.18/GtkWindow.html#gtk-window-stick "Asks to stick window, which means that it will appear on all user desktops." The implied API contract is more like request that this window show up regardless of where the user is working currently. This is typically used today by a) popup windows b) dashboard like windows. Especially in the latter case it is often used in combination with "Always keep on top" (For the future, I think we probably want to discourage applications from expecting this kind of behavior and encourage them to use the messaging tray when they aren't already visible.) The user goal, when setting the option explicitly, seems to relate to either "keep this visible" or "keep this handy". The difference between the two being mostly if keep-above is set along with it. So, both for apps and users there doesn't really seem to be a strong reason for why the window should appear on all workspaces. Only that is appear where I am now. Doing so will also result in less duplicate information in the grid view of workspaces. Since we don't really support moving between workspaces while in the overview grid there isn't an interaction issue while in the overview. But we will need to animate moving the window over to the new workspace. I guess something like sliding it in while we animate into the workspace could work. In the proposed linear view it would be a little bit more complicated. We'd need to reserve space for that window as we slide between the workspaces or something.
Created attachment 201258 [details] Implementation suggestion #1 using text Since activity on this bug is fairly old I thought it would be a good idea to make sure that this was still relevant and to have some kind of blueprint before taking up this task. What do you think?
Created attachment 201259 [details] Implementation suggestion #2 using icon
Ofcourse when nothing is pinned (Always on visible workspace), the interface should look just like it does now. No text, sperators, icons or anything - just the small previews.
(In reply to comment #8) > So, both for apps and users there doesn't really seem to be a strong reason for > why the window should appear on all workspaces. Only that is appear where I am > now. > > [...] > > In the proposed linear view it would be a little bit more complicated. We'd > need to reserve space for that window as we slide between the workspaces or > something. This makes a lot more sense to me than the proposed mockups.
Could this bug be close and the problem it relates to is already non-existent? I propose a new one is opened, as a feature-request.
This seems obsolete. The current workspace implementation seems to handle sticky windows OK, unless I'm missing something.