Some applications cannot be favorited

Bug #641337 reported by Olivier Tilloy on 2010-09-17
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
BAMF
Wishlist
Jason Smith
Unity
Fix Released
Undecided
Jason Smith
bamf (Ubuntu)
Undecided
Unassigned
unity (Ubuntu)
Undecided
Unassigned

Bug Description

Observed in unity 0.2.22-0ubuntu1~lucid1 from ppa:canonical-dx-team/une.

Summary: Some applications cannot be marked as favorite so as to keep them permanently in the launcher.

Steps to reproduce (in a unity session):
1) execute gnome-terminal, right click on its icon in the launcher to bring up the contextual menu
2) execute gedit, right click on its icon in the launcher to bring up the contextual menu
3) execute system-config-printer, right click on its icon in the launcher to bring up the contextual menu
4) execute ibus-setup, right click on its icon in the launcher to bring up the contextual menu

Expected result: after all 4 steps, the contextual menu contains a togglable "Keep In Launcher" entry.

Current result: the "Keep In Launcher" entry is present in the menu at steps 1 and 2, but not at steps 3 and 4.

Olivier Tilloy (osomon) wrote :

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?).

Olivier Tilloy (osomon) wrote :

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.

David Barth (dbarth) wrote :

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

Changed in unity:
assignee: nobody → Jason Smith (jassmith)
status: New → Triaged
Jason Smith (jassmith) wrote :

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.

Changed in bamf:
assignee: nobody → Jason Smith (jassmith)
importance: Undecided → Wishlist
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

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.

Robert Dyer (psybers) wrote :

@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'.

Panagiotis Skintzos (ph7) wrote :

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.

Didier Roche (didrocks) on 2011-02-21
Changed in bamf:
status: Confirmed → Triaged
Changed in bamf (Ubuntu):
status: New → Triaged
Neil J. Patel (njpatel) on 2011-03-06
Changed in bamf:
status: Triaged → Fix Released
Changed in bamf (Ubuntu):
status: Triaged → Fix Released
Changed in unity:
status: Triaged → Fix Released
Changed in unity (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers