GNOME Bugzilla – Bug 568983
Windows created while the user is in Overlay mode are not shown in Overlay
Last modified: 2009-02-04 14:51:58 UTC
Windows created while the user is in Overlay mode are not shown in Overlay mode. I noticed this when I tried to take a screenshot of the Overlay mode. I pressed "Prt sc" but the screenshot window didn't show up in any of the workspaces (or Activities if you will). Instead the terminal reported: ** (gnome-screenshot:24897): WARNING **: Couldn't find window manager window The window is indeed created in the selected workspace but that is not seen in the Overlay mode. I guess the same would happen if someone sent an IM or an error dialog popped up, but I haven't tested those scenarios.
I just noticed that the search box doesn't take keyboard input anymore, wonder if that's related to this bug.
To Reproduce: ------------- 1) In gnome-sheel open a new terminal window 2) Type "sleep 10; xterm" 3) Before the "sleep 10" wait is over press "Activities" 4) The overlay will display. 5) Wait a full 10 seconds Result: ------- Even though the 10 seconds is up, the window will not display in the workspace-preview. Reason: ------- This occurs because the "Show Overlay" code (js/ui/overlay.js) generates a window list and attaches it to the workspaces. It then uses these window-lists to update the overlay workspace displays. As the new window was spawned before the window-list was created, it never actually belongs to a workspace/window-list and never gets drawn on the screen as a result. Solution: --------- There appear to be a few logical solutions to this problem however the simplest solution would be to periodically update each workspace.window-list to match the real window-list on the workspace. Whether this be inside the overlay display code or have mutter emit some form of "update" signal that tells the overlay that mutter has just come into control of a new window.
EDIT to the above: As the new window was spawned *AFTER* the window-list was created, it never actually belongs to a workspace/window-list and never gets drawn on the screen as a result.
*** Bug 568981 has been marked as a duplicate of this bug. ***
Created attachment 127601 [details] [review] patch to track window adds/removes So I was doing this to simplify the handling of moving windows between workspaces during drag and drop, and then made sure it also correctly handled the case of moving windows as needed if their workspace goes away. And then right before attaching the patch here I was like "oh yeah, I guess I should test the case mentioned in the bug too", and of course it doesn't work For a completely new window (as opposed to a window that has just been moved from one workspace to another), the MutterWindow hasn't been created yet at the point when the signal is emitted, so we can't set it up correctly. Fix is probably to wait for it to be mapped or something like that. Anyway, this is most of the patch, with an update to come later...
I wouldn't have thought that Bug #568981 was related, as that bug is primarily to do with the control and function of windows already in the window-lists for the overlay workspaces. This issue is the to do with the overlay/workspace not generating new window objects on creation after overlay.show() has run. I am still trying to understand the code, so I won't be able to patch it any time soon, but I still believe the code is somewhere in-between Metacity and the Overlay/Workspace. In the meantime, can we get this bug listed as CONFIRMED? -Timbobsteve
(In reply to comment #6) Hey, Timbobsteve, thanks for your interest in this bug. > I wouldn't have thought that Bug #568981 was related, as that bug is primarily > to do with the control and function of windows already in the window-lists for > the overlay workspaces. > > This issue is the to do with the overlay/workspace not generating new window > objects on creation after overlay.show() has run. Both this bug and the other have to do with: Update overlay state when windows are added and removed from a workspace They do involve different aspects of the state and different ways of adding and removing windows. Dan's patch tries to handle everything. (As he notes, it doesn't quite work for new windows yet due to an ordering issue.) > I am still trying to understand the code, so I won't be able to patch it any > time soon, but I still believe the code is somewhere in-between Metacity and > the Overlay/Workspace. > > In the meantime, can we get this bug listed as CONFIRMED? In general, I wouldn't worry to much about UNCONFIRMED vs. NEW. The distinction between the states is important for a project like Firefox, which has thousands of bug being filed by inexperienced users, but less useful for a lot of GNOME products, including gnome-shell. (If wasn't quickly closed, it's almost certainly a real bug!)
Created attachment 127785 [details] [review] don't try to animate *any* transitions while the overlay is up
Created attachment 127786 [details] [review] Use the new metacity window-added and window-removed signals to track windows
(In reply to comment #9) > Created an attachment (id=127786) [edit] + if (isNew) { + // For a new window, the MutterWindow's position won't + // be synched to the MetaWindow's position yet... + log('adding new window at ' + win.x + ', ' + win.y + ', ' + win.width + 'x' + win.height); + } oops, ignore that bit
Comment on attachment 127785 [details] [review] don't try to animate *any* transitions while the overlay is up Looks good
::window-added/::window-removed patch looks good. + let [stageX, stageY] = clone.actor.get_transformed_position(); + let [stageWidth, stageHeight] = clone.actor.get_transformed_size(); + win._overlayHint = { + x: stageX, + y: stageY, + scale: stageWidth / clone.actor.width + }; This could use a bit of commenting about why we set the hint on a window that i being removed (because it might be being removed as part of a DND) + Workspaces.buttonSize = Math.floor(bottomHeight * 3/5); Hmm, not sure how I feel about this, having lots of random non-static global scope variables could get confusing. The only real alternate suggestion would be to pass the Workspaces object to the Workspace constructor so you could do: this._workspaces.buttonSize; (I decided against adding this back-pointer when doing DND, I felt a signal would keep encapsulation better than having Workspace make method calls against Workspaces, but if the workspace needs to get some property of Workspaces, maybe the backpointer is appropriate?)
(In reply to comment #12) > This could use a bit of commenting about why we set the hint on a window that i > being removed (because it might be being removed as part of a DND) While writing the comment, I realized I hadn't tested just removing yet, so I had to fix that. There's a problem here though that we can't animate the window going away, because the X Window gets destroyed immediately afterward and that messes up the clone. If we wanted to be able to animate windows disappearing, we'd need to hook into the plugin signals (so we can animate the window and then call completed_destroy() when we're done to tell mutter it's ok to actually destroy the window). > + Workspaces.buttonSize = Math.floor(bottomHeight * 3/5); > > Hmm, not sure how I feel about this, having lots of random non-static global > scope variables could get confusing. The only real alternate suggestion would > be to pass the Workspaces object to the Workspace constructor so you could do: > > this._workspaces.buttonSize; That feels wrong to me. I think it would be better to have Workspaces just pass buttonSize to the Workspace constructor. Or have Workspaces manage the (-) button itself rather than having Workspace do it. I left it as Workspaces.buttonSize for now, but put a FIXME comment there so we don't forget about it.