[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: gnome-menus (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in “gnome-menus” package in Ubuntu: Confirmed Status in “qtubuntu” package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: qtubuntu (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in “gnome-menus” package in Ubuntu: Confirmed Status in “qtubuntu” package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
** Tags added: appstore -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in “gnome-menus” package in Ubuntu: New Status in “qtubuntu” package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
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? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in “gnome-menus” package in Ubuntu: New Status in “qtubuntu” package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
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? ** Also affects: gnome-menus (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in Unity Mir: New Status in “gnome-menus” package in Ubuntu: New Status in “qtubuntu” package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1204599] Re: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts
** No longer affects: unity-mir -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-menus in Ubuntu. https://bugs.launchpad.net/bugs/1204599 Title: Unity does not pick up changes to ~/.local/share/applications if it doesn't exist when Unity starts Status in Unity Applications Lens: New Status in “gnome-menus” package in Ubuntu: New Status in “qtubuntu” package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/unity-lens-applications/+bug/1204599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
