GNOME Bugzilla – Bug 738672
Unable to favorite some applications in gnome-shell dock
Last modified: 2018-05-22 17:44:31 UTC
There are few application that can't be favorited once running. These are the applications that don't have a registered .desktop file. Steps to reproduce: - download an application from the developper website. Don't choose a distribution package, but rather a cross-distro built executable. - uncompress the archive, go to the directory, and start the executable - the application appears on the desktop and on the dock - right-clicking on the icon on the dock doesn't have the option to favourite the application. It is thus impossible to have an easy access to it. Expected behaviour: - The menu should have a "Add to favorites" entry - This should create a .desktop entry file with the application icon and pointing to the application executable. The .desktop entry should be added to favorites. Use cases: my distribution can't package all applications out there, I should be able to download some from the developper website and have a seamless user experience. Example of such applications: - Firefox: https://www.mozilla.org/en-US/firefox/new/ - Tox IM: https://wiki.tox.im/Binaries#Other_Linux Currently, developpers don't create much of those packages because of the less than optimal integration with desktop environments. If desktop environments start to allow integration of those apps, developpers would be encouraged to provide easy access to their applications by providing cross-distro precompiled binaries.
The same problem with Krusader. Gnome 3.26.2 in Ubuntu 17.10 (the one that re-introduced gnome). Filed a bug report in Krusader, but they say it should be resolved in gnome: https://bugs.kde.org/show_bug.cgi?id=390732 > I wasn't able to add Krusader to favorites in dock (usually it can be done via right click on dock icon). I manage to do it via results in gnome overview, but didn't work as expected (hitting shortcut always creates new Krusader instance instead going to already opened one). > Changing org.kde.krusader.desktop to krusader.desktop solves all these issues. > Probably (I didn't check it) instead of renaming .desktop file you could rename krusader's binary. Find it here: https://unix.stackexchange.com/questions/58824/how-do-i-add-eclipse-to-my-gnome-shell-favorites/59654#59654 Their answer: > That is not an appropriate change. The desktop file *should* match the AppStream ID. The AppStream ID is org.kde.krusader.desktop (https://cgit.kde.org/krusader.git/tree/krusader/org.kde.krusader.appdata.xml#n3), so the Desktop file needs the same filename. If GNOME or the Dock extension you're using can't handle the binary bding named something different from the AppStream ID, that's a problem there (though I doubt it, since GNOME programs tend to be good citizens and all use the same naming conventions that we do, e.g. Nautilus is org.gnome.nautilus). > Please report this to GNOME.
fixed the formatting of previous comment: The same problem with Krusader. Gnome 3.26.2 in Ubuntu 17.10 (the one that re-introduced gnome). Filed a bug report in Krusader, but they say it should be resolved in gnome: https://bugs.kde.org/show_bug.cgi?id=390732 > I wasn't able to add Krusader to favorites in dock (usually it can be done via right click on dock icon). I manage to do it via results in gnome overview, but didn't work as expected (hitting shortcut always creates new Krusader instance instead going to already opened one). > Changing org.kde.krusader.desktop to krusader.desktop solves all these issues. > Probably (I didn't check it) instead of renaming .desktop file you could rename krusader's binary. Find it here: https://unix.stackexchange.com/questions/58824/how-do-i-add-eclipse-to-my-gnome-shell-favorites/59654#59654 Their answer: > That is not an appropriate change. The desktop file *should* match the AppStream ID. The AppStream ID is org.kde.krusader.desktop (https://cgit.kde.org/krusader.git/tree/krusader/org.kde.krusader.appdata.xml#n3), so the Desktop file needs the same filename. If GNOME or the Dock extension you're using can't handle the binary bding named something different from the AppStream ID, that's a problem there (though I doubt it, since GNOME programs tend to be good citizens and all use the same naming conventions that we do, e.g. Nautilus is org.gnome.nautilus). > Please report this to GNOME.
It's not that the desktop file cannot be called 'org.kde.krusader.desktop', it's that we need a way to associate a window with the file. Considering that it is strongly recommended that .desktop files follow the reverse-DNS patter (that is, 'org.kde.krusader.desktop' is *better* than 'krusader.desktop'), these are better alternatives: - set the window's WM_CLASS to 'org.kde.krusader' - add 'StartupWMClass=krusader' to the .desktop file Or if the KDE developers give us some other way to match windows to .desktop files, we can consider adding it. But as it is, the ball is in their court ...
Thanks, Florian. Consequently, today a change was made in Krusader (and Florian and Jakkubu appear in the credits :-) , thank you all): https://phabricator.kde.org/R167:0e0f4ae6dd349a14d48e6ae1b80d03dfc8ec72ca
I added myself to the buglist. I can't favorite the BOINC Manager to the dock. I have always been able to do so on Ubuntu 16.04 Unity Desktop Manager so this issue cropped up just now with Ubuntu 18.04 and Gnome Desktop Manager.
As in the previous case, the issue is that the application doesn't provide us with enough information to link its windows to its .desktop file.
I successfully made a desktop file for boincmgr and could then dock it. But the application does not launch the client, only an empty Manager window. This all work just fine in Unity and 16.04. So something has changed in how desktop files work.
(In reply to Keith Myers from comment #7) > This all work just fine in Unity and 16.04. So something has changed in how > desktop files work. First, "how desktop files work" hasn't changed, *your desktop* changed from a produce called "Unity" to a product called "GNOME". And yes, the heuristics for matching windows to the corresponding .desktop files are different in gnome-shell and libbamf (used by Unity). For instance, the latter also matches the launching process against the Exec field in .desktop files. We decided early on that we would *not* adopt that in GNOME, because it's a fairly messy heuristic (just take a look at the black- and whitelist options in https://bazaar.launchpad.net/~unity-team/bamf/trunk/view/head:/src/bamf-matcher.c#L56 (and how "newer" stuff like "pkexec" and "flatpak" are missing)).
So how do I get the ability to Dock my most often used application?
Ask the developers of your most used application to provide an appropriate .desktop file that can be correctly associated with the app's open windows.
Well you are no help. Both you and the BOINC developers say the problem lies with the other. BOINC has not changed any code. It works fine in all previous distributions. It works fine in 18.04 with Unity desktop manager.
(In reply to Keith Myers from comment #11) > Well you are no help. To be fair, you haven't provided much information that would allow me to help you. (In reply to Keith Myers from comment #11) > It works fine in all previous distributions. Oh, do you mean it worked with older GNOME versions? Which versions/distributions? > It works fine in 18.04 with Unity desktop manager. Sigh - again, I'm not disputing this, but it is completely irrelevant. It is like answering "I cannot pin BOINC to the dash" with "Oh, but I can pin Firefox just fine". It's true, but it's also comparing apples and oranges ...
I can't vouch personally whether earlier distributions with Gnome desktop manager worked. I have only ever used Unity. However the developer of the Linux/MAC BOINC application HAS checked BOINC on every distribution back to 12.04 through 17.10 and KDE/Gnome/Unity desktop managers and said BOINC has worked normally always. He is only just recently fighting with the most recent MAC release which is causing troubles.
Florian - can you provide link to the discussion with Linux/MAC BOINC developer? (In reply to Keith Myers from comment #7) > I successfully made a desktop file for boincmgr and could then dock it. But > the application does not launch the client, only an empty Manager window. It may be connected to other bug - https://groups.google.com/a/ssl.berkeley.edu/forum/#!topic/boinc_alpha/17XrXDk71XE So the .desktop file may work well, but then you hit another bug.
(In reply to jakkubu from comment #14) > Florian - can you provide link to the discussion with Linux/MAC BOINC > developer? Which discussion? There's some general advice about application requirements in the wiki[0], for most apps it boils down to either - having windows' WM_CLASS property match the .desktop file name (without the file extension) - setting the StartupWMClass field in the .desktop file to the WM_CLASS windows will use (Although I'm surprised that this supposedly used to work in GNOME, as there haven't been any fundamental changes in years) For less abstract advice, I'd need more information, like the .desktop file that we fail to match (both filename and contents, ideally with translations stripped for legibility) and the output of `xprop | grep WM_CLASS` for a window cannot be pinned. [0] https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased
Sorry Florian - actually I wanted to ask Keith about this link. So: Keith - can you provide link to the discussion with Linux/MAC BOINC developer?
I am not in contact with the repository BOINC Linux developer,Gianfranco Costamagna. I am in contact with TBar who compiles the BOINC source code from the Github source tree for MAC and the special application versions. My discussions have been through PM messages on the Seti forum so I can't provide a link.