bug#36376: Application menu of desktop environment not automatically updated

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>> +@@ -249,11 +258,11 @@ desktop_file_dir_changed (GFileMonitor      *monitor,
>>> +    *
>>> +    * If this is a notification for a parent directory (because the
>>> +    * desktop directory didn't exist) then we shouldn't fire the signal
>>> +-   * unless something actually changed.
>>> ++   * unless something actually changed or it's in /var/guix/profiles.
>>> +    */
>>> +   g_mutex_lock (&desktop_file_dir_lock);
>>> +
>>> +-  if (dir->alternatively_watching)
>>> ++  if (dir->alternatively_watching && dir->guix_profile_watch_dir == NULL)
>>                                       ^^^^^^
>>                                       Why is this needed/desirable?
>
> As the comment above states it, the ‘if’ is here so that the “changed”
> signal is not fired when we’re just watching a parent directory.
>
> However, in our case, ‘dir->alternatively_watching != NULL’ possibly
> means that we’re watching a Guix profile, in which case we do want to
> fire the “changed” signal.
>
> This “&&” allows us to disambiguate between “watching a parent
> directory” and “watching a Guix profile”.

Yes, this makes sense.  I got confused by the wording of the (existing)
comment that mentions "unless something actually changed".  I used to
think this meant the contents of whatever directory is being watched,
but looking more closely, it's really just about if the parent directory
of a non-existing data directory changed...  Makes senses, we don't want
that.

>>> +@@ -1555,6 +1564,32 @@ desktop_file_dirs_lock (void)
>>> +       for (i = 0; dirs[i]; i++)
>>> +         g_ptr_array_add (desktop_file_dirs, desktop_file_dir_new (dirs[i]));
>>> +
>>> ++      {
>>> ++        /* Monitor the system and user profile under /var/guix/profiles and
>>> ++         * treat modifications to them as if they were modifications to their
>>> ++         * /share sub-directory.  */
>>> ++        const gchar *user;
>>> ++        DesktopFileDir *system_profile_dir, *user_profile_dir;
>>> ++
>>> ++        system_profile_dir =
>>> ++          desktop_file_dir_new ("/var/guix/profiles/system/profile/share");
>>> ++        system_profile_dir->guix_profile_watch_dir = g_strdup ("/var/guix/profiles");
>>> ++        g_ptr_array_add (desktop_file_dirs, desktop_file_dir_ref (system_profile_dir));
>>> ++
>>> ++        user = g_get_user_name ();
>>
>> This seems to get the user of the running glib application; e.g. for
>> GNOME Shell it returns 'gdm'...
>>
>>> ++        if (user != NULL)
>>> ++          {
>>> ++            gchar *profile_dir, *user_data_dir;
>>> ++
>>> ++            profile_dir = g_build_filename ("/var/guix/profiles/per-user", user, NULL);
>>> ++            user_data_dir = g_build_filename (profile_dir, "guix-profile", "share", NULL);
>>> ++            user_profile_dir = desktop_file_dir_new (user_data_dir);
>>> ++            user_profile_dir->guix_profile_watch_dir = profile_dir;
>>> ++            g_ptr_array_add (desktop_file_dirs, desktop_file_dir_ref (user_profile_dir));
>>> ++            g_free (user_data_dir);
>>> ++          }
>>> ++      }
>>> ++
>>
>> ...which means the above puts the watch on the
>> "/var/guix/profiles/per-user/gdm" directory, which doesn't exist.
>
> Yes, that profile is typically never populated.

Ah, I now understand the source of my confusion; there are multiple
gnome-shell instances (components?) running, one apparently started by
the greeter (GDM), which doesn't have a profile, and others started by
the users which logged in.

Thanks again for the fix and explanations!

Maxim