Some applications cannot be favorited

I’ve tracked down the cause to unity failing to associate a desktop file to applications like system-config-printer and ibus-setup, even though such desktop files do exist in /usr/share/applications/.

I suspect (to be confirmed) that this is due to the way those applications are launched: their executables in /usr/bin/ are shell scripts that set up environment variables and then launch another script, typically a python script. That seems to confuse whatever mechanism there is to associate a desktop file to a running application (bamf, isn’t it?).

I can confirm that the issue is with bamf failing to identify the desktop file for some applications.
Tested with bamf’s dbus service, for system-config-printer and ibus-setup, the DesktopFile() method of the org.ayatana.bamf.application interface returns an empty string.

@jassmith: confirmed to be a bamf issue: is there a simple way around that? or else it becomes a natty topic.

natty topic. Fixing this issue requires either creating .desktop files for applications which dont have them, or bamf passing an exec string to unity that it can use to relaunch an application. Either way it is modestly dangerous.

Jason, the applications that bamf fails to recognize (system-config-printer and ibus-setup) *do* have desktop files in /usr/share/applications/, it’s just not finding them for some reason.

@Jason: this should be a relatively easy fix I think. Docky has no problem matching those windows.

I believe our strategy was to a) strip off a prefix of 'python' and b) strip off suffixes of '.py' because typically you get the pattern where you have a launcher script 'foo' which runs 'python foo.py'.

Hi,

another example of this and failed matching, are XBMC and MythTVFrontend.
Both apps have a desktop file, that runs a shell script, which executes the real binary.
After launching them, in the laucher you have entries without icons and names xbmc.bin and Mythfrontend.real respectively, which cannot be pinned.