GNU bug report logs - #35594
GNOME: Application icons are not displayed immediately after installation

Previous Next

Full log

Message #56 received at 35594 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, 35594 <at> debbugs.gnu.org,
 36376 <at> debbugs.gnu.org
Subject: Re: bug#36376: Application menu of desktop environment not
 automatically updated
Date: Tue, 17 Nov 2020 23:34:42 -0500

Hello Ludovic!

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.