After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703048 - Create ~/.local/share/applications to get notified of new desktop files
Create ~/.local/share/applications to get notified of new desktop files
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: housekeeping
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: Richard Hughes
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2013-06-25 11:22 UTC by Emilio Pozuelo Monfort
Modified: 2013-06-27 14:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
appSystem: make sure XDG_DATA_HOME/applications exists (1.91 KB, patch)
2013-06-25 11:23 UTC, Emilio Pozuelo Monfort
none Details | Review
housekeeping: create ~/.local/share/applications (1.40 KB, patch)
2013-06-25 14:22 UTC, Emilio Pozuelo Monfort
committed Details | Review

Description Emilio Pozuelo Monfort 2013-06-25 11:22:38 UTC
As explained on bug #702991, a newly created user doesn't have ~/.local/share/applications which means gnome-menus doesn't add a file monitor for it. This means gnome-shell doesn't get notified about changes to that dir, and so new desktop files don't appear in gnome-shell until the shell is restarted, which can be quite confusing.

Fixing this in gnome-menus is a bit tricky partly because of bug #522314. A workaround for this is creating the directory from gnome-shell before getting the GMenuTree. The patch is very simple and does its job.
Comment 1 Emilio Pozuelo Monfort 2013-06-25 11:23:09 UTC
Created attachment 247720 [details] [review]
appSystem: make sure XDG_DATA_HOME/applications exists

So that we get notified if desktop files are added there.
Comment 2 Ray Strode [halfline] 2013-06-25 11:35:07 UTC
Last time this kind of thing happened we fixed it in g-s-d.  See bug 694134
Comment 3 Ray Strode [halfline] 2013-06-25 11:35:58 UTC
Also see the mkdir (~/.local) commit that happened following that bug:

https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/housekeeping/gsd-housekeeping-manager.c?id=7f4af9ab7824c0479e3f4e77742042949b6d32da
Comment 4 Emilio Pozuelo Monfort 2013-06-25 12:01:53 UTC
(In reply to comment #2)
> Last time this kind of thing happened we fixed it in g-s-d.  See bug 694134

That seems a bit different as it was g-s-d who was adding the monitor, so it made sense for g-s-d to create the dir.

In this case it's libgnome-menus who adds the watch in a call from gnome-shell. Since creating a dir from a shared library doesn't sound so right to me, I thought gnome-shell would be the right place.

The housekeeping g-s-d plugin sounds like it would also be a good fit... I don't mind it too much who creates the dir as long as we fix this issue. Bastien, would you accept a patch to create ~/.local/share/applications from the housekeeping plugin?
Comment 5 Bastien Nocera 2013-06-25 12:43:19 UTC
Sure, until we switch to a notification system that doesn't have those sort of architectural problems :/
Comment 6 Emilio Pozuelo Monfort 2013-06-25 14:22:49 UTC
Created attachment 247738 [details] [review]
housekeeping: create ~/.local/share/applications

So that gnome-shell/gnome-menus adds a monitor and the shell notices
newly added desktop files.
Comment 7 Emilio Pozuelo Monfort 2013-06-25 14:24:23 UTC
(In reply to comment #5)
> Sure, until we switch to a notification system that doesn't have those sort of
> architectural problems :/

I look forward to that day!

In the meantime, the attached patch should solve this. Tested with latest 3.8.x packages.

Reassigning to g-s-d.
Comment 8 Ray Strode [halfline] 2013-06-25 14:35:56 UTC
Review of attachment 247738 [details] [review]:

::: plugins/housekeeping/gsd-housekeeping-manager.c
@@ +383,3 @@
+        /* Create ~/.local/share/applications/, see #703048 */
+        dir = g_build_filename (g_get_user_data_dir (), "applications", NULL);
+        g_mkdir (dir, 0700);

why not consolidate this g_mkdir with the g_mkdir_with_parents call above it?
Comment 9 Emilio Pozuelo Monfort 2013-06-25 16:18:54 UTC
(In reply to comment #8)
> Review of attachment 247738 [details] [review]:
> 
> ::: plugins/housekeeping/gsd-housekeeping-manager.c
> @@ +383,3 @@
> +        /* Create ~/.local/share/applications/, see #703048 */
> +        dir = g_build_filename (g_get_user_data_dir (), "applications", NULL);
> +        g_mkdir (dir, 0700);
> 
> why not consolidate this g_mkdir with the g_mkdir_with_parents call above it?

I made a separate call because they address different issues. Say creating the applications folder isn't needed anymore at some point in the future [e.g. because gnome-menus is fixed to monitor non-existing folders (bug #702991) when glib is fixed to not poll non-existing dirs every few seconds (bug #522314)]. Then this call may be removed without noticing that we still need to create ~/.local/share/.

I can merge them and make the comment mention both issues it would address. I have no strong opinion on it really.
Comment 10 Ray Strode [halfline] 2013-06-25 16:43:03 UTC
I guess I don't have that strong of opinion either, in retrospect.
Comment 11 Bastien Nocera 2013-06-27 12:05:01 UTC
Review of attachment 247738 [details] [review]:

Looks good.

::: plugins/housekeeping/gsd-housekeeping-manager.c
@@ +381,3 @@
         g_mkdir_with_parents(g_get_user_data_dir (), 0700);
 
+        /* Create ~/.local/share/applications/, see #703048 */

Put the full link to bugzilla here.
Comment 12 Emilio Pozuelo Monfort 2013-06-27 14:13:17 UTC
(In reply to comment #11)
> Put the full link to bugzilla here.

Done. Pushed to master and gnome-3-8.