Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts

[Jamie Strandboge]

On an up to date saucy/touch/mako image on package install, click packages create a desktop file in ~/.local/share/applications. After which, the user can tap 'Search' under the applications scope and find the new app. However, this does not work properly if ~/.local/share/applications does not exist at the time Unity started, which is the case on at least the mako saucy touch image.

Steps to reproduce:
 1. mv ~/.local/share/applications ~/.local/share/applications.bak
 2. reboot
 3. install a click package (or drop a properly formatted (see bug #1204595) desktop file in ~/.local/share/applications
 4. search the Dash for the package

The Dash won't find the package in step 4 until restarting Unity. After rebooting, installing click packages or adding desktop files works as expected (ie, you can find them in step 4). I don't know if this worked properly or not in Unity 7.

[James Henstridge (jamesh)]

We use libgnome-menu to build the applications index and watch for changes, so that is where the bug probably resides.

The configuration we use is in /etc/xdg/menus/unity-lens-applications.menu and uses the <DefaultAppDirs/> directive to pick applications directories rather than specify them manually.

Perhaps it only checks for these default directories once on startup, rather than watching the parents of missing default dirs?

[Sebastien Bacher (seb128)]

In Ubuntu Desktop, gnome-settings-daemon is creating that directory early at the session start:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=3bc9b5d4ca32a099f291be9c751358aa7efc78a4

We should probably do the same in Ubuntu Touch ... not sure what's the best component to do that though, maybe gnome-session.user-session.upstart (gnome-session) would be right?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.