[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35594: bug#36376: Application menu of desktop environment not automa
From: |
Maxim Cournoyer |
Subject: |
bug#35594: bug#36376: Application menu of desktop environment not automatically updated |
Date: |
Tue, 17 Nov 2020 23:34:42 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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
- bug#36376: Application menu of desktop environment not automatically updated, (continued)
- bug#36376: Application menu of desktop environment not automatically updated, Maxim Cournoyer, 2020/11/05
- bug#36376: Application menu of desktop environment not automatically updated, Ludovic Courtès, 2020/11/06
- bug#36376: Application menu of desktop environment not automatically updated, Ludovic Courtès, 2020/11/12
- bug#36376: bug#35594: bug#36376: Application menu of desktop environment not automatically updated, Ludovic Courtès, 2020/11/13
- bug#35594: bug#36376: Application menu of desktop environment not automatically updated, Maxim Cournoyer, 2020/11/16
- bug#36376: Application menu of desktop environment not automatically updated, Ludovic Courtès, 2020/11/17
- bug#35594: bug#36376: Application menu of desktop environment not automatically updated,
Maxim Cournoyer <=