GNOME: Application icons are not displayed immediately after installation

DoneSubmitted by sirgazil.
Details
5 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • sirgazil
  • zimoun
Owner
unassigned
Severity
important
Merged with
S
S
sirgazil wrote on 6 May 2019 01:19
(name . bug-guix)(address . bug-guix@gnu.org)
16a8a4b4c07.ad1f7a9a40480.985002149086753257@zoho.com
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/
M
M
Mark H Weaver wrote on 6 May 2019 04:21
(name . sirgazil)(address . sirgazil@zoho.com)(address . 35594@debbugs.gnu.org)
87pnowqq3h.fsf@netris.org
Hi,
sirgazil <sirgazil@zoho.com> writes:
Toggle quote (8 lines)> 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 begood to fix it. FWIW, another way to refresh the list of availableapplications from GNOME Shell is to type: Alt-F2, and then enter thesingle letter "r" as the command. That should restart GNOME Shellwithout affecting your other applications. (Unfortunately for me, thisonly works under Xorg, not Wayland.)
A related issue is that if you upgrade a program in Guix, and thenlaunch it using GNOME Shell, it will launch the old one. That's becauseour installed desktop files are specifically rewritten to launch theprogram via an absolute path name /gnu/store/xxxxx/bin/* instead ofsimply looking in PATH, and GNOME Shell continues to use the old desktopfiles 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 haveenough energy to speak up about it.
Mark
S
S
sirgazil wrote on 6 May 2019 13:34
(name . Mark H Weaver)(address . mhw@netris.org)(name . 35594)(address . 35594@debbugs.gnu.org)
16a8ceca4cb.feaa0c4945447.2719212968817627071@zoho.com
---- 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.
M
M
Maxim Cournoyer wrote on 3 Nov 2020 18:44
(name . sirgazil)(address . sirgazil@zoho.com)
87eelaz65h.fsf@gmail.com
Hello,
sirgazil <sirgazil@zoho.com> writes:
Toggle quote (27 lines)> 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 likelycaused by GNOME Shell using inotify to watch the $XDG_DATA_DIRSreferenced $HOME/.guix-profile/share/applications directory. Theproblem is that the inode of such directory will never change, as itpoints to the current profile under /gnu/store:
Toggle snippet (8 lines)$ ls -id $HOME/.guix-profile/share/applications72653730 /home/maxim/.guix-profile/share/applications/maxim@hurd ~/src/guix$ realpath $HOME/.guix-profile/share/applications/gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applicationsmaxim@hurd ~/src/guix$ ls -id /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications72653730 /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.
Maxim
M
M
Maxim Cournoyer wrote on 3 Nov 2020 20:14
(name . sirgazil)(address . sirgazil@zoho.com)
87a6vyz20u.fsf@gmail.com
Hello,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (18 lines)> 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 beto patch its desktop_file_dir_init() procedure with Guix-specifics; Idon't know *how* yet. The folks in #gtk may provide some clues.
Maxim
M
M
Maxim Cournoyer wrote on 3 Nov 2020 23:33
(name . sirgazil)(address . sirgazil@zoho.com)
875z6myssx.fsf@gmail.com
Hi again,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (29 lines)> 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 Ithink might be a solution.
The idea would be to patch desktop_file_dir_init() as mentioned earlierwith a procedure similar to desktop_file_dir_get_alternative_dir in thatsame gdesktopappinfo.c file. This new procedure would search for aparent symlink of the dir argument (dir being one of the entriesconstructed 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, returnNULL.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. dirnamesymlink2).
In most cases (guix environment, build environment, extra userprofiles), the entries in XDG_DATA_DIRS are not symlinks but directlystore 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 themutable /var/guix/profiles/per-user/$USER directory used to store theprofile links, it is possible to have inotify work correctly. Thealgorithm 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 eithergiven 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
L
L
Ludovic Courtès wrote on 4 Nov 2020 17:54
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
875z6l83kv.fsf@gnu.org
Hello!
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (16 lines)> 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. Iposted 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 thinkthat’s the most common case. (Usually you’d only add applications to/run when reconfiguring, and then you may reboot shortly after in alaptop kind of setting. Also, one typically doesn’t *add* applicationsto /run.)
Thoughts?
Ludo’.
L
L
Ludovic Courtès wrote on 4 Nov 2020 21:54
control message for bug #35594
(address . control@debbugs.gnu.org)
87mtzw7sh7.fsf@gnu.org
severity 35594 importantquit
L
L
Ludovic Courtès wrote on 4 Nov 2020 21:55
control message for bug #36376
(address . control@debbugs.gnu.org)
87lffg7sg5.fsf@gnu.org
merge 36376 35594quit
M
M
Maxim Cournoyer wrote on 4 Nov 2020 22:41
Re: bug#36376: Application menu of desktop environment not automatically updated
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87v9ekyf2x.fsf@gmail.com
Hello Ludovic and Leo,
Leo Prikler <leo.prikler@student.tugraz.at> writes:
Toggle quote (26 lines)> Hi Ludo,>> Am Dienstag, den 03.11.2020, 23:46 +0100 schrieb Ludovic Courtès:>> Ludovic Courtès <ludo@gnu.org> skribis:>> >> > This is not news to us, but as>> > <https://distrowatch.com/weekly.php?issue=20190624#guixsd> notes,>> > the>> > application menu of desktop environments is not automatically>> > updated>> > when a package is installed or removed. It’d be great if we could>> > somehow notify the desktop environment.>> >> We’ve investigated today on IRC with Maxim and Leo P. and here’s the>> summary of our findings:> Seeing my name thrown around more and more lately makes me blush a> little.>> [...]>> >> The GLib patch below is an attempt to monitor ~/.guix-profile and to>> treat changes to that symlink as if they were changes to>> ~/.guix-profile/share/applications (which contains ‘.desktop’ files.)>> It actually builds but I haven’t tested it yet. :-)>> >> WDYT?
Pretty cool! It'd keep on working even if we even clean up /etc/profilefrom the hardcoded defauts environment variables (say, if we merge oneof the proposed solution of https://issues.guix.gnu.org/22138).
Toggle quote (5 lines)> Not having tested it either, I think that we should also listen on> /run/current-system/ (if it exists), so that changes to the system as> done by `reconfigure` are picked up. This includes most importantly> changes to the GNOME ecosystem itself.
I agree that it seems useful and important to add a monitor on the/run/current-system as well.
Thank you!
Maxim
M
M
Maxim Cournoyer wrote on 4 Nov 2020 23:28
control message for bug #41298
(address . control@debbugs.gnu.org)
87r1p8ycxh.fsf@gmail.com
merge 41298 35594quit
L
L
Ludovic Courtès wrote on 10 Nov 2020 16:23
Re: bug#36376: Application menu of desktop environment not automatically updated
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87lff9nsl0.fsf@gnu.org
Hi Maxim,
So I went further to test the initial GLib patch I posted in “realconditions”.
‘guix system vm-image’ takes an awful lot of time for big images; Ipatiently waited for completion for an image of ‘desktop.tmpl’, but thenits root file system turned out to be too small for me to run ‘guixinstall’.
So instead I tried this:
1. ‘guix system vm desktop.tmpl’;
2. ‘guix install inkscape -p /tmp/test’ on my actual machine;
3. Start the GNOME VM created above;
4. Inside the VM, search for Inkscape, notice it’s not there;
5. Inside the VM, have ~/.guix-profile point to the profile created on the host above, and notice that Inkscape becomes available.
Video!
mpv http://web.fdn.fr/~lcourtes/tmp/gnome-desktop-app-detection.webm
So I think we should include this fix in 1.2. What do people think?
The main downside is extra grafting, which means extra disk and CPUusage for our users. However, libx11 (11K dependents) is also grafted,so it shouldn’t make things worse (GLib has 6K dependents).
Maxim, did you have a variant of the GLib patch that also checks/run/current-system?
Thanks,Ludo’.
Z
Z
zimoun wrote on 10 Nov 2020 18:48
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ216jq9Q=ML-yFN-CW-P95sHV5KDAQcw_7O7YJ6Uc-Gvg@mail.gmail.com
On Tue, 10 Nov 2020 at 16:25, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (2 lines)> Video!
Héhé! Nice :-)
Toggle quote (2 lines)> So I think we should include this fix in 1.2. What do people think?
You mean only the initial patch. If it works in "real conditions" forbob on 'antelope' (desktop.tmpl), then it would nice to have for 1.2,

Toggle quote (4 lines)> The main downside is extra grafting, which means extra disk and CPU> usage for our users. However, libx11 (11K dependents) is also grafted,> so it shouldn’t make things worse (GLib has 6K dependents).
No free lunch. :-)Is it really slow or acceptable?

All the best,simon
L
L
Ludovic Courtès wrote on 10 Nov 2020 22:23
(name . zimoun)(address . zimon.toutoune@gmail.com)
871rh0oqie.fsf@gnu.org
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
Toggle quote (2 lines)> On Tue, 10 Nov 2020 at 16:25, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
Toggle quote (7 lines)>> The main downside is extra grafting, which means extra disk and CPU>> usage for our users. However, libx11 (11K dependents) is also grafted,>> so it shouldn’t make things worse (GLib has 6K dependents).>> No free lunch. :-)> Is it really slow or acceptable?
If you’re installing a graphical applications, it’s already beinggrafted, so the extra graft doesn’t make a difference.
Non-graphical applications that depend on GLib will now need to begrafted, but I think there aren’t many of them, and they too might alsobe grafted for other reasons.
Ludo’.
L
L
Ludovic Courtès wrote on 12 Nov 2020 16:56
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87d00iin6w.fsf@gnu.org
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (3 lines)> So I went further to test the initial GLib patch I posted in “real> conditions”.
I did some more testing using a similar workflow: this time I repeatedlychanged the profile (installing/removing packages), which showed thatthe first patch was buggy (it would only notice the creation of~/.guix-profile and nothing beyond that).
This is in part due to the fact that ‘GFileMonitor’ follows symlinks (itdoesn’t pass the ‘IN_DONT_FOLLOW’ inotify flag). Thus, when it monitors~/.guix-profile, it’s really monitoring /gnu/store/…-profile, whichnever changes.
So with this new patch it’s monitoring /var/guix/profiles/per-user/USERand /var/guix/profiles instead, which correctly detects changes. Itdetects a bit “too much” (for instance, running ‘guix pull’ triggers theinotify hook because it changes/var/guix/profiles/per-user/USER/current-guix) but that’s probably OK.
If you’re using GNOME, Xfce, or another GLib-based desktop environment,I’d welcome tests on the bare metal! Just apply the patch on a checkoutof ‘master’ and run:
sudo -E ./pre-inst-env guix system reconfigure …
If there are no objections, I’d like to apply this patch shortly so wecan go ahead with a last round of pre-release tests.
Ludo’.
From 7d03b2b823951219ece46c7f34e25ae36a8ba12c Mon Sep 17 00:00:00 2001From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>Date: Thu, 12 Nov 2020 16:35:24 +0100Subject: [PATCH] gnu: glib: Graft patch to detect changes to the installed applications.
Fixes https://bugs.gnu.org/35594.Reported by sirgazil <sirgazil@zoho.com> and others.
* gnu/packages/patches/glib-appinfo-watch.patch: New file.* gnu/local.mk (dist_patch_DATA): Add it.* gnu/packages/glib.scm (glib)[replacement]: New field.(glib-with-gio-patch): New variable.(glib-with-documentation): Use 'package/inherit'.--- gnu/local.mk | 1 + gnu/packages/glib.scm | 14 ++- gnu/packages/patches/glib-appinfo-watch.patch | 92 +++++++++++++++++++ 3 files changed, 105 insertions(+), 2 deletions(-) create mode 100644 gnu/packages/patches/glib-appinfo-watch.patch
Toggle diff (147 lines)diff --git a/gnu/local.mk b/gnu/local.mkindex d5a13cbdbd..2301a04d2f 100644--- a/gnu/local.mk+++ b/gnu/local.mk@@ -1050,6 +1050,7 @@ dist_patch_DATA = \ %D%/packages/patches/ghostscript-no-header-id.patch \ %D%/packages/patches/ghostscript-no-header-uuid.patch \ %D%/packages/patches/ghostscript-no-header-creationdate.patch \+ %D%/packages/patches/glib-appinfo-watch.patch \ %D%/packages/patches/glib-tests-timer.patch \ %D%/packages/patches/glibc-CVE-2018-11236.patch \ %D%/packages/patches/glibc-CVE-2018-11237.patch \diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scmindex 901222476a..43523e516d 100644--- a/gnu/packages/glib.scm+++ b/gnu/packages/glib.scm@@ -181,6 +181,7 @@ shared NFS home directories.") (package (name "glib") (version "2.62.6")+ (replacement glib-with-gio-patch) (source (origin (method url-fetch) (uri (string-append "mirror://gnome/sources/"@@ -387,11 +388,20 @@ dynamic loading, and an object system.") (home-page "https://developer.gnome.org/glib/") (license license:lgpl2.1+))) +(define glib-with-gio-patch+ ;; GLib with a fix for <https://bugs.gnu.org/35594>.+ ;; TODO: Fold into 'glib' above in the next rebuild cycle.+ (package+ (inherit glib)+ (source (origin+ (inherit (package-source glib))+ (patches (cons (search-patch "glib-appinfo-watch.patch")+ (origin-patches (package-source glib))))))))+ (define-public glib-with-documentation ;; glib's doc must be built in a separate package since it requires gtk-doc, ;; which in turn depends on glib.- (package- (inherit glib)+ (package/inherit glib (properties (alist-delete 'hidden? (package-properties glib))) (outputs (cons "doc" (package-outputs glib))) ; 20 MiB of GTK-Doc reference (native-inputsdiff --git a/gnu/packages/patches/glib-appinfo-watch.patch b/gnu/packages/patches/glib-appinfo-watch.patchnew file mode 100644index 0000000000..638a5e0949--- /dev/null+++ b/gnu/packages/patches/glib-appinfo-watch.patch@@ -0,0 +1,92 @@+This patch lets GLib's GDesktopAppInfo API watch and notice changes+to the Guix user and system profiles. That way, the list of available+applications shown by the desktop environment is immediately updated+when the user runs "guix install", "guix remove", or "guix system+reconfigure" (see <https://issues.guix.gnu.org/35594>).++It does so by monitoring /var/guix/profiles (for changes to the system+profile) and /var/guix/profiles/per-user/USER (for changes to the user+profile) and crawling their share/applications sub-directory when+changes happen.++diff --git a/gio/gdesktopappinfo.c b/gio/gdesktopappinfo.c+index f1e2fdd..095c110 100644+--- a/gio/gdesktopappinfo.c++++ b/gio/gdesktopappinfo.c+@@ -148,6 +148,7 @@ typedef struct+ gchar *alternatively_watching;+ gboolean is_config;+ gboolean is_setup;++ gchar *guix_profile_watch_dir;+ GFileMonitor *monitor;+ GHashTable *app_names;+ GHashTable *mime_tweaks;+@@ -180,6 +181,7 @@ desktop_file_dir_unref (DesktopFileDir *dir)+ {+ desktop_file_dir_reset (dir);+ g_free (dir->path);++ g_free (dir->guix_profile_watch_dir);+ g_free (dir);+ }+ }+@@ -204,6 +206,13 @@ desktop_file_dir_get_alternative_dir (DesktopFileDir *dir)+ {+ gchar *parent;+ ++ /* If DIR is a profile, watch the specified directory--e.g.,++ * /var/guix/profiles/per-user/$USER/ for the user profile. Do not watch++ * ~/.guix-profile or /run/current-system/profile because GFileMonitor does++ * not pass IN_DONT_FOLLOW and thus cannot notice any change. */++ if (dir->guix_profile_watch_dir != NULL)++ return g_strdup (dir->guix_profile_watch_dir);+++ /* If the directory itself exists then we need no alternative. */+ if (g_access (dir->path, R_OK | X_OK) == 0)+ return NULL;+@@ -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)+ {+ gchar *alternative_dir;+ +@@ -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 ();++ 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);++ }++ }+++ /* The list of directories will never change after this, unless+ * g_get_user_config_dir() changes due to %G_TEST_OPTION_ISOLATE_DIRS. */+ desktop_file_dirs_config_dir = user_config_dir;-- 2.29.2
L
L
Ludovic Courtès wrote on 13 Nov 2020 21:38
Re: bug#35594: bug#36376: Application menu of desktop environment not automatically updated
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87a6vlat66.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (15 lines)>>From 7d03b2b823951219ece46c7f34e25ae36a8ba12c Mon Sep 17 00:00:00 2001> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>> Date: Thu, 12 Nov 2020 16:35:24 +0100> Subject: [PATCH] gnu: glib: Graft patch to detect changes to the installed> applications.>> Fixes <https://bugs.gnu.org/35594>.> Reported by sirgazil <sirgazil@zoho.com> and others.>> * gnu/packages/patches/glib-appinfo-watch.patch: New file.> * gnu/local.mk (dist_patch_DATA): Add it.> * gnu/packages/glib.scm (glib)[replacement]: New field.> (glib-with-gio-patch): New variable.> (glib-with-documentation): Use 'package/inherit'.
Pushed as ae10ec441aa524bf267f9cefd4a319b44d0b8b44 (version-1.2.0).
Ludo’.
Closed
M
M
Maxim Cournoyer wrote on 17 Nov 2020 05:57
Re: bug#36376: Application menu of desktop environment not automatically updated
(name . Ludovic Courtès)(address . ludo@gnu.org)
875z64d1hr.fsf@gmail.com
Hello Ludovic!
Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (10 lines)> So with this new patch it’s monitoring /var/guix/profiles/per-user/USER> and /var/guix/profiles instead, which correctly detects changes. It> detects a bit “too much” (for instance, running ‘guix pull’ triggers the> inotify hook because it changes> /var/guix/profiles/per-user/USER/current-guix) but that’s probably OK.>> If you’re using GNOME, Xfce, or another GLib-based desktop environment,> I’d welcome tests on the bare metal! Just apply the patch on a checkout> of ‘master’ and run:
I've now done so! It works :-)! I do have noticed something a bit off,see the comments below.
[...]
Toggle quote (62 lines)> diff --git a/gnu/packages/patches/glib-appinfo-watch.patch b/gnu/packages/patches/glib-appinfo-watch.patch> new file mode 100644> index 0000000000..638a5e0949> --- /dev/null> +++ b/gnu/packages/patches/glib-appinfo-watch.patch> @@ -0,0 +1,92 @@> +This patch lets GLib's GDesktopAppInfo API watch and notice changes> +to the Guix user and system profiles. That way, the list of available> +applications shown by the desktop environment is immediately updated> +when the user runs "guix install", "guix remove", or "guix system> +reconfigure" (see <https://issues.guix.gnu.org/35594>).> +> +It does so by monitoring /var/guix/profiles (for changes to the system> +profile) and /var/guix/profiles/per-user/USER (for changes to the user> +profile) and crawling their share/applications sub-directory when> +changes happen.> +> +diff --git a/gio/gdesktopappinfo.c b/gio/gdesktopappinfo.c> +index f1e2fdd..095c110 100644> +--- a/gio/gdesktopappinfo.c> ++++ b/gio/gdesktopappinfo.c> +@@ -148,6 +148,7 @@ typedef struct> + gchar *alternatively_watching;> + gboolean is_config;> + gboolean is_setup;> ++ gchar *guix_profile_watch_dir;> + GFileMonitor *monitor;> + GHashTable *app_names;> + GHashTable *mime_tweaks;> +@@ -180,6 +181,7 @@ desktop_file_dir_unref (DesktopFileDir *dir)> + {> + desktop_file_dir_reset (dir);> + g_free (dir->path);> ++ g_free (dir->guix_profile_watch_dir);> + g_free (dir);> + }> + }> +@@ -204,6 +206,13 @@ desktop_file_dir_get_alternative_dir (DesktopFileDir *dir)> + {> + gchar *parent;> +> ++ /* If DIR is a profile, watch the specified directory--e.g.,> ++ * /var/guix/profiles/per-user/$USER/ for the user profile. Do not watch> ++ * ~/.guix-profile or /run/current-system/profile because GFileMonitor does> ++ * not pass IN_DONT_FOLLOW and thus cannot notice any change. */> ++ if (dir->guix_profile_watch_dir != NULL)> ++ return g_strdup (dir->guix_profile_watch_dir);> ++> + /* If the directory itself exists then we need no alternative. */> + if (g_access (dir->path, R_OK | X_OK) == 0)> + return NULL;> +@@ -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?
OK, I think I get it. The API seems to imply that users (such asgnome-shell) need to keep asking about a desktop directory entry as theyare otherwise "forgotten". Since we are inserting entries at the levelof glib ourselves, these will never be asked for by gnome-shell, so mustnot be cleared. Is that correct?
Toggle quote (21 lines)> + {> + gchar *alternative_dir;> +> +@@ -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. forGNOME Shell it returns 'gdm'...
Toggle quote (14 lines)> ++ 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.
sudo strace -f -s200 -p$(pgrep gnome-shell | head -n1) reports entriessuch as:
Toggle snippet (9 lines)92 00:48:47 poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=19, events=POLLIN}, {fd=28, events=POLLIN}], 5, -1 <unfinished ...>390 00:48:47 <... poll resumed>) = 0 (Timeout)390 00:48:47 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)390 00:48:47 poll([{fd=3, events=POLLIN}, {fd=17, events=POLLIN}], 2, 3996) = 0 (Timeout)390 00:48:51 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)390 00:48:51 poll([{fd=3, events=POLLIN}, {fd=17, events=POLLIN}], 2, 3998) = 0 (Timeout)390 00:48:55 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)
The fallback mechanism should have been disabled indesktop_file_dir_changed (dir->guix-profile_watch_dir != NULL sodesktop_file_dir_get_alternative_dir doesn't get called), so it seemsthis shouldn't work.
Could it be that the watches used by glib implement a recursiveinotify-based watch and that it works because any changes under the/var/guix/profiles directory get picked up, including those of userprofiles. The sources seem to suggest so, for example ingio/inotify/inotify-path.c. If that is the case, it could lead to a newinteresting problems: applications from other users could end up beingshown inadvertently.
I'll try to validate the above hypothesis, but this takes time.
In any case, the current situation is already an improvement, so thankyou for your efforts!
Maxim
L
L
Ludovic Courtès wrote on 17 Nov 2020 10:08
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87eekstkny.fsf@gnu.org
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (17 lines)> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>> So with this new patch it’s monitoring /var/guix/profiles/per-user/USER>> and /var/guix/profiles instead, which correctly detects changes. It>> detects a bit “too much” (for instance, running ‘guix pull’ triggers the>> inotify hook because it changes>> /var/guix/profiles/per-user/USER/current-guix) but that’s probably OK.>>>> If you’re using GNOME, Xfce, or another GLib-based desktop environment,>> I’d welcome tests on the bare metal! Just apply the patch on a checkout>> of ‘master’ and run:>> I've now done so! It works :-)! I do have noticed something a bit off,> see the comments below.
Thanks for testing!
Toggle quote (14 lines)>> +@@ -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’ possiblymeans that we’re watching a Guix profile, in which case we do want tofire the “changed” signal.
This “&&” allows us to disambiguate between “watching a parentdirectory” and “watching a Guix profile”.
Toggle quote (38 lines)>> +@@ -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.
Toggle quote (16 lines)> sudo strace -f -s200 -p$(pgrep gnome-shell | head -n1) reports entries> such as:>> 92 00:48:47 poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=19, events=POLLIN}, {fd=28, events=POLLIN}], 5, -1 <unfinished ...>> 390 00:48:47 <... poll resumed>) = 0 (Timeout)> 390 00:48:47 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)> 390 00:48:47 poll([{fd=3, events=POLLIN}, {fd=17, events=POLLIN}], 2, 3996) = 0 (Timeout)> 390 00:48:51 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)> 390 00:48:51 poll([{fd=3, events=POLLIN}, {fd=17, events=POLLIN}], 2, 3998) = 0 (Timeout)> 390 00:48:55 inotify_add_watch(17, "/var/guix/profiles/per-user/gdm", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)>> The fallback mechanism should have been disabled in> desktop_file_dir_changed (dir->guix-profile_watch_dir != NULL so> desktop_file_dir_get_alternative_dir doesn't get called), so it seems> this shouldn't work.
What shouldn’t work?
We keep adding a watch on a non-existent directory, but I think that’sfine.
Toggle quote (8 lines)> Could it be that the watches used by glib implement a recursive> inotify-based watch and that it works because any changes under the> /var/guix/profiles directory get picked up, including those of user> profiles. The sources seem to suggest so, for example in> gio/inotify/inotify-path.c. If that is the case, it could lead to a new> interesting problems: applications from other users could end up being> shown inadvertently.
We’re watching /var/guix/profiles (for the system profile) and/var/guix/profiles/per-user/USER, but .desktop files are loaded from theuser’s own profile, so that should be fine.
Thanks a lot for looking into this!
Ludo’.
M
M
Maxim Cournoyer wrote on 18 Nov 2020 05:34
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d00b8eql.fsf@gmail.com
Hello Ludovic!
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (6 lines)> Hi Maxim,>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:>>> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (24 lines)>>> +@@ -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 tothink this meant the contents of whatever directory is being watched,but looking more closely, it's really just about if the parent directoryof a non-existing data directory changed... Makes senses, we don't wantthat.
Toggle quote (40 lines)>>> +@@ -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 multiplegnome-shell instances (components?) running, one apparently started bythe greeter (GDM), which doesn't have a profile, and others started bythe users which logged in.
Thanks again for the fix and explanations!
Maxim
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 35594@debbugs.gnu.org