[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35594: GNOME: Application icons are not displayed immediately after
From: |
Maxim Cournoyer |
Subject: |
bug#35594: GNOME: Application icons are not displayed immediately after installation |
Date: |
Tue, 03 Nov 2020 17:33:18 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi again,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> After asking in the #gnome channel on freenode, the problem is likely
>> caused by GNOME Shell using inotify to watch the $XDG_DATA_DIRS
>> referenced $HOME/.guix-profile/share/applications directory. The
>> problem is that the inode of such directory will never change, as it
>> points to the current profile under /gnu/store:
>>
>> $ ls -id $HOME/.guix-profile/share/applications
>> 72653730 /home/maxim/.guix-profile/share/applications/
>> maxim@hurd ~/src/guix$ realpath $HOME/.guix-profile/share/applications
>> /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications
>> maxim@hurd ~/src/guix$ ls -id
>> /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications
>> 72653730
>> /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications/
>>
>> Any applications making use of inotify to discover changes (to plugins,
>> for example) is at risk of having the same problem in Guix.
>>
>> I don't currently have an idea of how we can fix this.
>
> Watching of the directory is done via Glib's GAppInfoMonitor
> (gpio/gdesktopappinfo.c). A suggested idea from #gnome-shell would be
> to patch its desktop_file_dir_init() procedure with Guix-specifics; I
> don't know *how* yet. The folks in #gtk may provide some clues.
>
> Maxim
I've analyzed the situation a bit; I'll explain the big lines of what I
think might be a solution.
The idea would be to patch desktop_file_dir_init() as mentioned earlier
with a procedure similar to desktop_file_dir_get_alternative_dir in that
same gdesktopappinfo.c file. This new procedure would search for a
parent symlink of the dir argument (dir being one of the entries
constructed via XDG_DATA_DIRS, such as
$HOME/.guix-profile/share/applications.).
The algorithm for this new procedure would be like:
1. Check if a parent of DIR is a symlink. When there are none, return
NULL.
2. Resolve the symlink parent until the last symlink, e.g. for symlink1
-> symlink2 -> directory, it saves symlink2.
3. Return the parent directory of the symlink resulting from 2 (i.e. dirname
symlink2).
In most cases (guix environment, build environment, extra user
profiles), the entries in XDG_DATA_DIRS are not symlinks but directly
store entries so there's nothing we can do about it.
The case of interest here is the default user profile or
$HOME/.guix-profile, which gets added to XDG_DATA_DIRS via /etc/profile
(on Guix System). Because of the indirect links to the store, and the
mutable /var/guix/profiles/per-user/$USER directory used to store the
profile links, it is possible to have inotify work correctly. The
algorithm described above would resolve $HOME/.guix-profile into
/var/guix/profiles/per-user/$USER, and /run/current-system into /run.
While adding a watch to /run is not optimal, it's not dramatic either
given the watch is not recursive and only watch for specific actions:
#define IP_INOTIFY_DIR_MASK
(IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_DELETE|IN_CREATE|IN_DELETE_SELF|IN_UNMOUNT|IN_MOVE_SELF|IN_CLOSE_WRITE)
(from gio/inotify/inotify-path.c)
Thoughts?
Thanks,
Maxim