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 153620 - Windows are moved to the users workspace, and not the other way around
Windows are moved to the users workspace, and not the other way around
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
2.8.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 148553 (view as bug list)
Depends on:
Blocks: 155460
 
 
Reported: 2004-09-24 08:46 UTC by Mattias Eriksson
Modified: 2020-11-06 20:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mattias Eriksson 2004-09-24 08:46:53 UTC
I don't know if this is realy the blame of metacity, but I don't know who else
to blame :-)

When I do a galeon -n http://www.gnome.org/ or just gedit --new-document (where
any of those apps are already open on another workspace), the apps are moved to
my current workspace. Well if I wanted the application on that workspace I would
have placed it there to begin with. I suggest to change the workspace to the
applications workspace instead (but I guess that might not be what some other
user expects to happen, like if they plan to do a lot of gedit --new-documents
and then go to the app). 

At least it might be configurable, I think the exisiting "restore on existing
workspace" setting for the window-list might be generalized to "keep the
application on its workspace", and apply to this case too.

I think that in most cases the user really wants to be transported to the
applications workspace, like when klicking on links in evolution. The current
behavour might be better when the user is typing in a terminal and wants to
continue doing that (but in that case I guess the user doen't want anything to
be moved anywhere...)
Comment 1 Elijah Newren 2004-10-19 23:01:08 UTC
*** Bug 148553 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2005-07-14 17:46:30 UTC
(The duplicate was incorrectly marked.)

Okay, so this is kind of a warped/involved issue given the stuff from bug 128380
and bug 166379.  But, basically there exists a way for apps to force the WM to
behave this way due to the changes in 128380 (I didn't realize that when we made
the change in 128380 that basically it was an "allow apps to decide policy"
change until now), the usability team decided that we should have
apps-come-to-the-user-behavior, and the changes in gtk+ made it is easiest for
apps to specify apps-come-to-the-user.

So, while this ought to be a WM issue (which we'd probably WONTFIX as it's to
micromanagerial) it isn't currently.
Comment 3 André Klapper 2020-11-06 20:07:11 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.