GNOME Bugzilla – Bug 475038
Application should open on workspace from which it is launched
Last modified: 2020-11-06 20:07:17 UTC
When I open Eclipse IDE on Workspace 4 and then switch to Workspace 3 so I can continue web browsing, I don't expect that the Eclipse IDE (10-15 seconds later) will suddenly appear on Workspace 3. Applications should open on the workspace from which they are launched. I think it's a super-common use case to click the launcher for an app, and then switch away expecting it to go about loading on that workspace. Unfortunately, this use case doesn't work. Other information:
It would work if the application launchers followed the spec (launchers can specify which workspace a new window should appear on). How are you launching eclipse?
Using a GNOME launcher; it works the same way from gnome-panel and from my Desktop. It sounds to me like you're saying a launcher file can specify the workspace an application starts on. That is, I can change the Eclipse launcher to say "Workspace=4" and it will always launch on workspace 4. However, that's not what I'm talking about. Whatever workspace I'm in when I double-click a launcher, _that's_ the workspace an application should start on. It's not good enough for it to be statically defined in launchers.
No, that's not what I meant. I meant that the launcher can determine which workspace is active at the time you perform a launch request and then tell the window manager to open the application on that workspace. However, it appears gnome-panel already does this; panel_ditem_launch runs: workspace = xstuff_get_current_workspace (screen); ... return gnome_desktop_item_launch_on_screen (item, file_list, 0, screen, workspace, error); So unless the app is doing something weird (e.g. setting _NET_WM_DESKTOP for the new workspace on the window), it ought to work when launched from the panel. It would be nice to have a verbose debugging log. Could you get one? To do so: 1. Reduce your desktop to as few windows as possible to reproduce the bug 2. Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace 3. On stdout metacity will print the name of the logfile 4. Reproduce the bug as quickly as possible 5. Kill the metacity you started above to stop the logfile from growing any longer 6. Attach the logfile here
Created attachment 104393 [details] The logfile
Ok, as I don't like nagging and not being helpful afterwards I tried to reproduce this "bug" on my machine. So I ran Eclipse Europa and Metacity 2.21.8. Behavious is exactly the same as described above. The loader show on Workspace 2, the actual program on Workspace 4, to which I switched in between. Logfile above...
The question from comment #3 has been answered and the provided. Thus reopening.
(In reply to comment #0) I'd like to confirm this behavior also for Firefox and VirtualBox OSE, but not for gedit. I'm using Ubuntu 8.10.
Original Ubuntu bug: https://bugs.launchpad.net/metacity/+bug/172687
Confirmed for GNOME 2.26.1, Debian Testing
I can confirm this behaviour for Firefox, galeon, even for gedit (you need only be quick enough to change the workspace). My system: Ubuntu 8.10, GNOME 2.24.1 All the .desktop-files for this programs have the entry "StartupNotify=true", as mentioned in [1]. The metacity-logfiles will follow for starting Firefox a) with launch (Alt+F2), b) click on symbol at the panel, c) click on programs > internet > firefox. Then switched from workspace 1 to 2 with key combination ctrl+2. After the Firefox-window has appeared, I killed metacity with launch "metacity --replace" (thx hggdh). The mouse cursor changed to a waiting symbol with starting method b) and c), as it should like mentioned in bug 75758, comment 6 [2]. [1] http://library.gnome.org/devel/integration-guide/stable/startup-notification.html.en [2] http://bugzilla.gnome.org/show_bug.cgi?id=75758#c6
Created attachment 140063 [details] a) metacity-log for launch (alt+f2) of firefox
Created attachment 140065 [details] b) metacity-log for click on panel symbol of firefox
Created attachment 140066 [details] c) metacity-log for click on programs > internet > firefox
*** Bug 590881 has been marked as a duplicate of this bug. ***
*** Bug 609105 has been marked as a duplicate of this bug. ***
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.