GNOME Bugzilla – Bug 642684
Some apps don't start on the requested workspace
Last modified: 2021-07-05 14:25:29 UTC
With the new workspaces layout, you can drag and drop apps to another workspace, and they start on it instead of on the current workspace. This doesn't work for Qt applications. I've tried with Okular (KDE app), qjackctl (Qt only), Rosegarden, Rkward...
*** Bug 643501 has been marked as a duplicate of this bug. ***
Bug 643501 also reports problems with Firefox and gwibber, though it's less clear why those applications would have problems, since they are using GTK+. Presumably, the overall here is applications that either don't attempt to implement the right specification for launching on a desktop using startup notification or do it badly. One thing we can consider is doing a fallback implementation of start-on-workspace using PID tracking we already do.
*** Bug 604514 has been marked as a duplicate of this bug. ***
*** Bug 610010 has been marked as a duplicate of this bug. ***
FWIW, KDE has a special class to handle startup notification: http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStartupInfo.html The docs say: > You usually don't need to use this class for sending the notification > information, as KDE libraries should do this when an application is > started (e.g. KRun class). But KRun is actually the equivalent of GDesktopAppInfo and g_app_info_launch(), so not on the started app's side. The README.startupinfo file [1] explains all the details, but it may be outdated. 1: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/doc/README.kstartupinfo
*** Bug 653222 has been marked as a duplicate of this bug. ***
*** Bug 654811 has been marked as a duplicate of this bug. ***
Bug 654811 says the problem can be seen with Nautilus too, so it doesn't seem to be linked with KDE libraries. Test case: - No Nautilus instance is launched, - Go to the Activities overview and pick the Nautilus icon. Drop it on an empty workspace. It opens there. Great. - Now pick the icon again and drop it again on an empty workspace. It doesn't open there. It opens on the active workspace. I don't really know if it is a GNOME Shell bug or a Nautilus one (in conjonction with GNOME Shell). In fact, I've tested it with terminals instead of Nautilus instances. It works fine with terminals: they always open in the workspace they've been dropped on. Spec: Fedora 15, GNOME 3.0.1, Nautilus 3.0.2-1.fc15 (x86_64, given from the 'Add/Remove Software' tool).
No, the problem with Nautilus is slightly different, since it works when no window is opened, and only fails otherwise. So that's a specific bug in Nautilus - would you open a new report for this?
Ok. Thanks for the explanation. I've reassigned my initial bug 654811 to the nautilus project (with the correct version) and reopened it.
*** Bug 665201 has been marked as a duplicate of this bug. ***
This also happens with JDownloader(Java) and Audacious(GTK3).
On 3.34 it works with Clocks, but not with Terminal, Weather, Music… It's also worth noting that for this to work, the app must be favorited to appear in the dash first. Otherwise you have no way of drag-n-dropping them from an icon to a workspace, as the workspaces are not displayed in the grid or the search results.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.