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

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

[sirgazil]

Hi,

I installed the GNU system in a real machine using Guix 1.0 ISO installer (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).

Whenever I install a desktop application, the application icon does not show up immediately in the list of available applications. I have to log out and log in again to be able to see it.


## Steps to reproduce

1. Install a desktop application (I tried GIMP, Scribus, Inkscape, Audacity)
2. Click on "Activities".
3. Click on "Show Applications" (the button with nine dots).


## Unexpected result

The icon of the installed application is not in the list.


## Expected result.

The icon of the installed application is in the list.


---
https://sirgazil.bitbucket.io/

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

[Mark H Weaver]

Hi,

sirgazil <sirgazil@zoho.com> writes:

> I installed the GNU system in a real machine using Guix 1.0 ISO
> installer
> (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>
> Whenever I install a desktop application, the application icon does
> not show up immediately in the list of available applications. I have
> to log out and log in again to be able to see it.

Indeed, this has always been the case on Guix, and I agree it would be
good to fix it.  FWIW, another way to refresh the list of available
applications from GNOME Shell is to type: Alt-F2, and then enter the
single letter "r" as the command.  That should restart GNOME Shell
without affecting your other applications.  (Unfortunately for me, this
only works under Xorg, not Wayland.)

A related issue is that if you upgrade a program in Guix, and then
launch it using GNOME Shell, it will launch the old one.  That's because
our installed desktop files are specifically rewritten to launch the
program via an absolute path name /gnu/store/xxxxx/bin/* instead of
simply looking in PATH, and GNOME Shell continues to use the old desktop
files until it's restarted.  This was implemented back in 2016, here:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d31860b9de07810e114490db5cc160a8b078c58d

I remember thinking it was a bad idea at the time, but I didn't have
enough energy to speak up about it.

      Mark

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

[sirgazil]

---- On Sun, 05 May 2019 21:21:59 -0500 Mark H Weaver <mhw@netris.org> wrote ----

 > Hi, 
 >  
 > sirgazil <sirgazil@zoho.com> writes: 
 >  
 > > I installed the GNU system in a real machine using Guix 1.0 ISO 
 > > installer 
 > > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz). 
 > > 
 > > Whenever I install a desktop application, the application icon does 
 > > not show up immediately in the list of available applications. I have 
 > > to log out and log in again to be able to see it. 
 >  
 > Indeed, this has always been the case on Guix, and I agree it would be 
 > good to fix it.  FWIW, another way to refresh the list of available 
 > applications from GNOME Shell is to type: Alt-F2, and then enter the 
 > single letter "r" as the command.  That should restart GNOME Shell 
 > without affecting your other applications.  (Unfortunately for me, this 
 > only works under Xorg, not Wayland.) 
 >  
 > A related issue is that if you upgrade a program in Guix, and then 
 > launch it using GNOME Shell, it will launch the old one.  That's because 
 > our installed desktop files are specifically rewritten to launch the 
 > program via an absolute path name /gnu/store/xxxxx/bin/* instead of 
 > simply looking in PATH, and GNOME Shell continues to use the old desktop 
 > files until it's restarted.  This was implemented back in 2016, here: 
 >  
 >  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d31860b9de07810e114490db5cc160a8b078c58d 
 >  
 > I remember thinking it was a bad idea at the time, but I didn't have 
 > enough energy to speak up about it. 


I see... Thanks for the information, Mark.

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

[Maxim Cournoyer]

Hello,

sirgazil <sirgazil@zoho.com> writes:

> Hi,
>
> I installed the GNU system in a real machine using Guix 1.0 ISO
> installer
> (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>
> Whenever I install a desktop application, the application icon does
> not show up immediately in the list of available applications. I have
> to log out and log in again to be able to see it.
>
>
> ## Steps to reproduce
>
> 1. Install a desktop application (I tried GIMP, Scribus, Inkscape, Audacity)
> 2. Click on "Activities".
> 3. Click on "Show Applications" (the button with nine dots).
>
>
> ## Unexpected result
>
> The icon of the installed application is not in the list.
>
>
> ## Expected result.
>
> The icon of the installed application is in the list.

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:

--8<---------------cut here---------------start------------->8---
$ 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/
--8<---------------cut here---------------end--------------->8---

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.

Maxim

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

[Maxim Cournoyer]

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

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

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

[Ludovic Courtès]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> 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)

I think our messages crossed.  :-)  I agree with your conclusions.  I
posted a preliminary patch following our discussion:

  https://issues.guix.gnu.org/36376#2

It’s only taking care of ~/.guix-profile, not /run, because I think
that’s the most common case.  (Usually you’d only add applications to
/run when reconfiguring, and then you may reboot shortly after in a
laptop kind of setting.  Also, one typically doesn’t *add* applications
to /run.)

Thoughts?

Ludo’.