GNOME Bugzilla – Bug 609363
Custom menu entries don't launch application once added to favourites well.
Last modified: 2013-06-14 13:31:36 UTC
One example is that I run firefox from the tarball from mozilla. I have added a custom menu entry with alacarte, and it shows up in gnome-shell's menu. If I add this icon to the favourites well, then close the application, then try to launch application by cicking on the favourites entry; the application fails to launch. Also, the icon appears to be smaller on the favourites entries that don't work. Here is the contents of ~/.local/share/application/alacarte-made.desktop #!/usr/bin/env xdg-open [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Terminal=false Icon[en_AU]=/home/lexdeb/software/firefox36/chrome/icons/default/default48.png Name[en_AU]=firefox36 Exec=/home/lexdeb/bin/firefox36 Name=firefox36 Icon=gnome-panel-launcher Not sure if it is related, but I have a similar problem when adding dolphin (kde's filemanager, this is the system installed version, I'm running debian) to the favourites well. I will open a separate bug for this.
Not sure if this is relevant, but the following appears in terminal window from where gnome-shell --replace was run, when trying to launch favourite entry that doesnt' work. Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.
Though it is not exactly obvious, this is related to bug 605534. You commented on IRC that the favorite was added via right clock on the running-app indicator. When adding the favorite via drag-and-drop from the menu, the app launches, but has the launcher and running-indicator separate. That's what's happening in my opinion: For running applications (both the icon in the panel and the indicator in the app well), the shell tries to associate a window with a desktop file - which works reasonably well in many cases, but fails horribly in others (firefox more often than not being of the latter category). I'm a little oversimplifying here, but just assume that the window's WM_CLASS should match the name of the desktop file (e.g. WM_CLASS firefox36 => firefox36.desktop - unfortunately, mozilla has the tendency to set the WM_CLASS to something completely different, e.g. Minefield, Shiretoko, Namoroka, ...) Not sure about the KDE applications you mention, I suppose we have a similar case there (you can use a program like xprop to determine the WM_CLASS of a window).
*** Bug 609364 has been marked as a duplicate of this bug. ***
is this the sort of thing that's been fixed by g_desktop_app_info_launch_uris_as_manager()?
Don't know if this is related, but when I open xterm using Alt+F2, then add opened xterm to favorites in dash, then close xterm and try to open it again using just added item in dash, nothing happens, xterm does not shows up... xterm does not have associated .desktop file with it, so maybe this causes this behavior? If yes, then in this case gnome-shell should provide graphical and user-friendly .desktop files creator... Also if I have two or more xterm windows opened, they are not grouped in Alt+Tab switcher. If grouping is done by WM_CLASS, then xterm have this WM_CLASS: $ xprop | grep -i class WM_CLASS(STRING) = "xterm", "XTerm"
Apps *need* to have a .desktop file. If they don't, that's a bug in your distribution. Are you sure there's no /usr/share/application/xterm.desktop?
Yes, am sure: $ file /usr/share/applications/xterm.desktop /usr/share/applications/xterm.desktop: ERROR: cannot open `/usr/share/applications/xterm.desktop' (No such file or directory) My distribution is Ubuntu 11.04. If you say, that each distribution must provide .desktop file for each app, then I will report this to launchpad.net. But still there is a bug with several xterm windows grouping in Alt+Tab, they are not grouped.
(In reply to comment #7) > My distribution is Ubuntu 11.04. If you say, that each distribution must > provide .desktop file for each app, then I will report this to launchpad.net. I guess that's useful anyway to have a .desktop file, which ensures XTerm is available from the Shell or gnome-panel. How are you supposed to start it? By creating a .desktop file yourself? Please indeed file a bug. > But still there is a bug with several xterm windows grouping in Alt+Tab, they > are not grouped. That must be linked to the fact that the .desktop file is missing. Probably, even if WM_CLASS is correct, the Shell doesn't track the app because it couldn't find the file.
When I created ~/.local/share/applications/xterm.desktop file, all my mentioned issues disappeared, even that with Alt+Tab. I don't even thought, that .desktop files are so important. Also I requested in launchpad.net that removed xterm.desktop file would be returned back: https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/129041/comments/10
We no longer allow to favorite window-backed apps (e.g. those we can't find a desktop file for), so this particular issue is obsolete.