Unity

launcher/ApplicationLauncherIcon.cpp (+36/-37)
launcher/LauncherDragWindow.cpp (+1/-1)
launcher/SoftwareCenterLauncherIcon.cpp (+0/-1)
tests/mock-application.h (+1/-0)
tests/test_application_launcher_icon.cpp (+118/-39)
tests/test_launcher.cpp (+4/-4)
tests/test_software_center_launcher_icon.cpp (+1/-1)
unity-shared/ApplicationManager.h (+2/-0)
unity-shared/BamfApplicationManager.cpp (+11/-0)
unity-shared/BamfApplicationManager.h (+2/-0)
unity-shared/StandaloneAppManager.cpp (+19/-9)

To merge this branch:

bzr merge lp://staging/~3v1n0/unity/create-local-desktop-file

Related bugs:

Bug #704046: [launcher] can't add java programs as favorites	Medium	Fix Released
Bug #753305: Launcher - Apps launched from terminal or without a .desktop file cannot be launched after pinning to launcher	Medium	Fix Released
Bug #754334: unity launcher does not retain netbeans application	Low	Fix Released
Bug #765466: unity launcher does not handle apps launched from shell scripts correctly	Low	Fix Released
Bug #1209320: Sticking a desktop-less icon pops it to the top of the launcher	Medium	Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Christopher Townsend (community)		2013-08-07	Approve on 2013-08-09
PS Jenkins bot (community)	continuous-integration		Approve on 2013-08-09
Review via email: mp+179016@code.staging.launchpad.net

Commit message

ApplicationLauncherIcon: Create a local desktop file when sticking an app that has not

Also make icon sticky only if both the icon itself and the inner app is sticky as well.

Description of the change

When we try to stick an application that has no desktop file (and no URI, in fact) we use bamf to generate the .desktop file. If/When this happens the application get notified with a desktop-file-updated signal that makes unity to update the icon and save it on favorites.

I sometime noticed that a "default icon" is shown instead of the real one, this seems mostly related to something else or a race... There's one line in bamf that can avoid this, but before reverting that I'd like to see if we can find a better solution.

As always, added and updated new unit tests

Revision history for this message

Christopher Townsend (townsend) wrote on 2013-08-07:

I think this is almost working.

However, I ran into one problem where if I start a local app using ./name_of_exe, then the desktop file uses ./name_of_exe and when clicking the Launcher icon, it can't find ./name_of_exe. Is there any way to expand ./ to the full path?

Also, the .desktop file sticks around in .local/share/applications even after unpinning the icon from the Launcher. Is this intended behavior?

After I unpinned the icon, and then restarted the application using the full path, the already existing .desktop file did not get updated with the new full path. Not sure if the .desktop file is supposed to get updated or not.

Another behavior I noticed is that when I start the application using the Launcher icon (when the paths are correct), if I try quitting the application using Quit in the icon quicklist, the application won't quit.

review: Needs Information

Revision history for this message

PS Jenkins bot (ps-jenkins) wrote on 2013-08-07:

FAILED: Continuous integration, rev:3484
http://jenkins.qa.ubuntu.com/job/unity-ci/292/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-saucy-amd64-ci/181
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-ci/179/console
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-saucy-i386-ci/180

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/292/rebuild

review: Needs Fixing (continuous-integration)

Revision history for this message

Christopher Townsend (townsend) wrote on 2013-08-07:

The last behavior I noted about quiting from the Quicklist seems to only happen the first time I start the app and then try quitting. If I kill the app via the terminal and then open it again via Launcher icon, then Quit works.

Revision history for this message

Christopher Townsend (townsend) wrote on 2013-08-07:

Well, my comments about the Quicklist Quit may be invalid because for some reason, the new bamfdaemon crashed due to a "BadWindow (invalid Window parameter)" X error. Not really sure what caused this, but after starting the new bamfdaemon again, Quit now works as expected.

The other comments still seem valid.

Revision history for this message

Marco Trevisan (Treviño) (3v1n0) wrote on 2013-08-08:

> However, I ran into one problem where if I start a local app using
> ./name_of_exe, then the desktop file uses ./name_of_exe and when clicking the
> Launcher icon, it can't find ./name_of_exe. Is there any way to expand ./ to
> the full path?

So, good catch! This lp:~3v1n0/bamf/working-dir-support bamf branch should fix this case by including the working directory path on generated .desktop file.

> Also, the .desktop file sticks around in .local/share/applications even after
> unpinning the icon from the Launcher. Is this intended behavior?

Yes, I thought about removing these .desktop files, but I also think that this is a also a nice way to create .desktop files for applications we only want to show in dash and that don't have a valid launcher (i.e. you stick it and then you unstick it).

> After I unpinned the icon, and then restarted the application using the full
> path, the already existing .desktop file did not get updated with the new full
> path. Not sure if the .desktop file is supposed to get updated or not.

Yeah, that's the wanted behaviour as the .desktop should be generated once and never touched anymore by unity.

Revision history for this message

PS Jenkins bot (ps-jenkins) wrote on 2013-08-08:

FAILED: Continuous integration, rev:3484
http://jenkins.qa.ubuntu.com/job/unity-ci/293/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-saucy-amd64-ci/182
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-ci/180/console
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-saucy-i386-ci/181