GNOME Bugzilla – Bug 576412
ordinary windows in the activities overview (panel menus, screensaver)
Last modified: 2013-08-18 16:00:59 UTC
There are currently two situations where we want X windows to be able to draw over the overlay: 1. menus from the panel stuff (the user menu, and eventually the clock) 2. the screensaver, if it kicks in while the user is in overlay mode For #2, we could hack around it by having the overlay watch for the "screensaver activated" d-bus signal, and then dropping out of overlay when the screensaver comes on. (Or, even better, by having the screensaver be wayland-based rather than X-based, but that's way in the future.) For #1, we can make those menus unavailable from in the overlay (by shrinking the stage input area to not cover them), but there might be use cases where you'd want access to them? (Eg, you notice a certain recent document, and remember that you need to finish working on it before a meeting, and want to check your calendar to see what time that meeting is. Maybe this is a silly use case?) One possibility for fixing the panel menus would be to make them all be exclusively clutter-based rather than gtk-based. But this would require lots of rewriting/code duplication. Another possibility would be to figure out when a window is mapped if it's a child of a panel object, and if so, display its overlay clone normally rather than in one of the workspaces. (Might require some additional hacks if the window is tagged as appearing-in-all-workspaces.) Another possibility I'd thought of was to make the overlay actually be a workspace of its own; this might make it easier to avoid having mutter and gnome-shell step on each others' toes. But I think this would work badly. If the overlay workspace was workspace #1, then we'd have to move all of your windows up one workspace at startup, and then if gnome-shell crashed, they'd all be left in what would look like the wrong workspaces from normal-metacity's POV. But if the overlay workspace was the last workspace, then we'd have to jump through lots of hoops every time you added/removed a workspace.
this is pretty much a dup of 561067 *** This bug has been marked as a duplicate of 571067 ***
I'm going to undup this and make it a tracker. Bug 597085 - can't use status icons or user menu from overview User menu could be fixed by using a clutter-based menu instead of GtkMenu. Status icons could be fixed by using something libappindicator-esque where we draw the menus ourselves. (Note that status icons current have two problems; their ShellEmbeddedWindows get hidden so they can't be activated, and even if they could be, they can't display their menus.) Bug 601731 - Drag and Drop from Workspace to Overlay Oh boy. Bug 609959 - gnome-screensaver and activities overview Possibly wants to be a special-case anyway. We don't want the overview to accidentally subvert the screensaver. Bug 613543 - OSD's don't work when in overview mode Generally an easier case since it's "output only" (No bug) - Input method windows I don't know a lot about this (No bug) - A11y tools (eg, onscreen keyboard) I think this may involve non-override-redirect windows If we want menus and things to be able to work when the overview is up, then we can't grab the keyboard and pointer. However, if we just set input focus on the stage window, and then react accordingly if we lose that focus at unexpected times, we might be able to make things work.
On screen keyboard: Bug 612662
Seems like this is an old tracker bug that isn't being used any more. Just reopen if I've got it wrong.