After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 133337 - support moving windows from one screen to another in non-xinerama multihead
support moving windows from one screen to another in non-xinerama multihead
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: EWMH specification
2.6.x
Other Linux
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 170828 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-02-03 20:27 UTC by Dennis Smit
Modified: 2014-10-10 14:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Dennis Smit 2004-02-03 20:27:19 UTC
I personally dislike xinerama, the way it spreads the desktop
but i really like dualhead without using xinerama. Because
that way the context of the different monitors get separated.

However the only thing i miss is being able to move a window over to a
different screen. This is possible using gdk and it would be a great
feature that when you edge on the display while draging a window
that it'll move it over to the different screen.
Comment 1 Rob Adams 2004-02-03 20:39:53 UTC
this is certainly non-trivial.  What do you dislike about Xinerama,
exactly?  At this point I see no reason to use true multi-head at all...
Comment 2 Dennis Smit 2004-02-03 20:54:19 UTC
I dislike xinerama because it makes all the screens one big desktop
while i really like the separated context for the different
screens. The only thing i miss in this setup is the inability to
move a window to a different screen, using metacity atleast.

This is not very trivial although a lot can be discovered using
gdk. But i am not sure if such a feature would be welcome, i
would like to investigate the possibilities tho.
Comment 3 Elijah Newren 2005-03-18 18:48:34 UTC
*** Bug 170828 has been marked as a duplicate of this bug. ***
Comment 4 Havoc Pennington 2005-03-19 21:19:48 UTC
This is going to involve first a spec for how to tell an app to move one of its
windows, second GTK+ supporting said spec, and third metacity supporting said spec.

There have been proposals for this spec on xdg/wm-spec-list already, not sure of
the status. This bug does raise perhaps an additional issue, which is that we
want to tell gtk which workspace the window should come back on in addition to
which screen.
Comment 5 Dennis Smit 2005-03-20 10:21:35 UTC
I would think that the target workspace should be the active workspace.
Comment 6 Loïc Minier 2005-07-29 14:26:11 UTC
*** Bug 171751 has been marked as a duplicate of this bug. ***
Comment 7 Loïc Minier 2005-07-29 14:29:49 UTC
I confirm I'm experiencing this too.  It seems the focus switches screen when
switching workspaces, unless there's a window on the workspace which gets the focus.

When switching screens, the focus doesn't follow either, unless there's a window
which get the focus.

Additionally, when switching workspaces to a workspace with no window, when
releasing "Ctrl-Alt", the workspace switcher does not disappear on the second
head.  Everything is fine on the first head.
Comment 8 Elijah Newren 2005-07-29 15:01:51 UTC
Loïc: those things are unrelated to this bug report (though you probably marked
it as such due to the very general title this bug has)
Comment 9 Loïc Minier 2005-07-29 17:30:57 UTC
(Sorry, I meant to update bug 171751 instead of this one.)
Comment 10 Miek Gieben 2007-08-18 21:19:38 UTC
Can someone give a status update on this feature req.? I would love to see this kind of support for dual head setups in metacity/gnome.
Is some of the work of comment #4 already done?
Comment 11 Havoc Pennington 2007-08-28 23:31:48 UTC
I don't know of any significant work in progress here. It's a ton of work relative to the benefit, really, which is why no window manager or toolkit has ever supported this. I would be surprised if it ever happens. But, sometimes for something like this someone who really wants the feature decides to put in the work, so that's why the bug is open I guess.