GNOME Bugzilla – Bug 710610
Cannot move application to another workspace when mirroring desktop
Last modified: 2014-02-02 14:14:59 UTC
When I mirror desktop over two monitors (built-in and external one) I can't move applications to another workspace (in overview). When I drag and drop application to another workspace it appears on the current one. This happens also when I drag&drop window from another workspace, it appears on the active workspace too. Also when I drag window between two workspaces no new workspace appears. See video attached. Version: gnome-shell-3.10.1-1.fc20.x86_64 Fedora 20
(In reply to comment #0) > When I mirror desktop over two monitors (built-in and external one) I can't > move applications to another workspace (in overview). > > When I drag and drop application to another workspace it appears on the current > one. This happens also when I drag&drop window from another workspace, it > appears on the active workspace too. > > Also when I drag window between two workspaces no new workspace appears. > > See video attached. There is no video.
Oh, I'm sorry. It hadn't upload1ed due to the size of the video. You can find it here: http://pschindl.fedorapeople.org/Screencast%20from%2022.10.2013%2009:58:28.webm
*** Bug 712178 has been marked as a duplicate of this bug. ***
Something I found out: When moving the window to another workspace works (2nd monitor off), the function ThumbnailsBox.acceptDrop() is called When using monitor clone (or "mirror" as it is called here) setup, moving windows to another workspace doesn't work and instead Workspace.acceptDrop() is called. Also, the Workspace Thumbnails don't rearrange to allow dropping the window to create a new workspace.
Another observation: I added in /usr/share/gnome-shell/js/ui/dnd.js: _dragActorDropped: function(event) { let [dropX, dropY] = event.get_coords(); let target = this._dragActor.get_stage().get_actor_at_pos(Clutter.PickMode.ALL, dropX, dropY); //added log('target: ' + target); .... When dragging works (single monitor), the output is: target: [0x94fbc00 MetaBackgroundActor] When dragging doesn't work (dual monitor clone), the output is: target: [0x9979770 ClutterActor] which is the same output as if it would be dropped outside of the workspace thumbnails.
And yet another observation: In monitor clone/mirror mode, when you start the looking glass inspect-tool, the whole workspace-thumbnail view is only ONE "ClutterActor". In single monitor mode, the looking glass-inspector even identifies the window clones on the workspace-thumbnails. And, equal worse: The same goes for the DASH! In monitor clone/mirror mode, the whole Dash is ONE ClutterActor for the looking glass inspector, in single monitor mode, every icon is different. And that leads to the logical consequence: You can't drag app-icons on the Dash in dual-monitor clone/mirror mode! So I suppose, there should be an equivalent bug about the dash in dual--monitor clone/mirror mode, I try to search it and link it here. Also, I propose to increase priority, as both drag window-to-workspace and drag app-icon-to-dash are important core-functions.
So it seems that in the mirror mode, we have an erroneous actor covering large parts of the overview. Is this git master or 3.10? Can you see if: https://git.gnome.org/browse/gnome-shell/commit/js/ui/workspacesView.js?id=d5cd534320b1ca86f2986191c2336eb8ab6b6cac or similar commits in git master fix it?
For me, it's gnome-shell 3.10.2.1-1 in Arch Linux. (+ nvidia driver, if that matters.) The version of workspacesView.js in the link doesn't fix it (yes, I did alt+F2 "r" after replacing the original in /usr/share/gnome-shell/js/ui/ ;-) ), it's the same behaviour as before, with the same large ClutterActor in the Looking-Glass-Inspector. I searched all bugs about the dash, couldn't find a report about this before, so I filed a new one: https://bugzilla.gnome.org/show_bug.cgi?id=712615 (don't know whether tis is an duplicate then, you decide...)
There have been lots of changes, so in order to test, you need to have a full jhbuild from git master. Simply copying the workspacesView.js isn't adequate enough to test.
OK, thanks for the information, when I got time, I try to learn how to make such build.
FWIW, I can reproduce the issue here. For whatever reason, workspaces are stacked above dash/workspace switcher, but only in mirror mode.
(In reply to comment #11) > FWIW, I can reproduce the issue here. For whatever reason, workspaces are > stacked above dash/workspace switcher, but only in mirror mode. Hmm ... we is mirror mode even causing any changes? We should simply ignore mirrored monitors.
> Hmm ... we is mirror mode even causing any changes? We should simply ignore > mirrored monitors. Sounds reasonable. Has anybody a quick fix / workaround to achieve that? I'm using mirror mode very often and would be happy to avoid that problem.
This bug is quite annoying! Why it remain in an unconfirmed state? Please help.
Good question. This is a real show stopper, as it mainly happens, when you present something to others. (clone-mode --> presentation!) Meanwhile a workaround I didn't realize before, so maybe this is useful for someone: Rightclick on titlebar, move to workspace.... works. Also on clone/mirror-mode.
(In reply to comment #14) > This bug is quite annoying! Why it remain in an unconfirmed state? We don't differentiate between UNCONFIRMED and NEW. There's currently a request in to remove UNCOMFIRMED from the states in the gnome-shell product. As for the bug, I don't have an extra monitor to test with right now. Other people might be able to debug better.
It's possible to emulate the presence of an external monitor with a kernel parameter: video=conn:res[M][R][-bpp][@refresh][i][m][eDd] where conn must match xrandr name e.g. video=VGA-1:1024x768e for more info: http://distro.ibiblio.org/fatdog/web/faqs/boot-options.html Hope this help.
*** Bug 721785 has been marked as a duplicate of this bug. ***
Created attachment 265993 [details] [review] layout: Keep track of cloned monitors If a two (or more) monitors overlap completely threat the one with the heigher index as a clone of the other.
Created attachment 265994 [details] [review] workspacesView: Don't show views for cloned monitors They are overlapped by the clone anyway, and cause all sort of issues like broken dnd.
Review of attachment 265993 [details] [review]: I'd rather keep track of this in mutter's monitor manager. It seems like it would be useful to mutter as well, and XRandR might be able to tell us more than heuristics.
*** Bug 646649 has been marked as a duplicate of this bug. ***
Created attachment 267833 [details] [review] monitor_manger: Don't create MonitorInfos for clones The comment above MetaMonitorInfo reads: "Clones are only reported once, irrespective of the way they're implemented" But that's not what the code does, so fix the code to match to comment. The double reporting of clones confuses gnome-shell and let it think that there are multiple monitors while clones are effectivly one monitor. --- Ok seems like mutter was not supposed to report clones as separate monitors via MetaScreen at all, but the code wasn't really working, this fixes it.
Created attachment 267834 [details] [review] monitor_manger: Don't create MonitorInfos for clones The comment above MetaMonitorInfo reads: "Clones are only reported once, irrespective of the way they're implemented" But that's not what the code does, so fix the code to match the comment. The double reporting of clones confuses gnome-shell and let it think that there are multiple monitors while clones are effectivly one monitor.
Review of attachment 267834 [details] [review]: Huh? We do this loop immediately above. We first go through all existing monitors and check if they have the same rectangle. Why isn't this working?
Created attachment 267848 [details] [review] monitorManager: Fix logic bug in make_logical_config The code that prevents the creation of multiple MonitorInfos for clones wasn't working due to using the wrong index when getting the already created info so fix that to use the correct one. --- OK this fixes the logic instead of reimplementing it.
Review of attachment 267848 [details] [review]: Good eye.
Attachment 267848 [details] pushed as abebb47 - monitorManager: Fix logic bug in make_logical_config