bug#35594: GNOME: Application icons are not displayed immediately after installation

[Maxim Cournoyer]

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