Hi Simon, Simon Streit <[email protected]> writes:
> Hello, > > if Guix is installed on a foreign system (Debian Bookworm), sourcing > GDK_PIXBUF_MODULE_FILE will prevent native applications on foreign > systems from loading their icons: [...] > If GDK_PIXBUF_MODULE_FILE is explicitly sourced, then Guix based > applications show their icons. If not, no icons are displayed and the > host has the ability restored to show icons. > > This leaves Guix on foreign systems currently at: Either the foreign > system knows how to load icons, or Guix, if sourcing > GDK_PIXBUF_MODULE_FILE. Not simultaneously. That's annoying, but kind of inherit to the design of that single entry GDK_PIXBUF_MODULE_FILE. If we had a GDK_PIXBUF_MODULE_FILES instead, allowing multiple entries, we could, in the guix-install.sh script arrange so that the that environment variable would always have a default value to that of the system, like we currently do for a bunch of XDG_* variable already. > This behaviour is somewhat similar in Guix Systems too and has had a > similar discussion before: [1]. There it was proposed to wrap the > applications to provide GDK_PIXBUF_MODULE_FILE directly. That's not a bad way, though again because of the design of GDK_PIXBUF_MODULE_FILE, it would make it impossible for the user to add extra loaders to their profile. This pixbuf module thing is akin to plugins; it's ideally meant to be extendable by the user post-installation. If we had GDK_PIXBUF_MODULE_FILES, we could opt to wrap the binaries with it in a 'prefix' fashion, leaving open the door for the user to augment its value (say by installing some loaders in their user profile). > > But, there was a time where this was not a problem that lasted up to at > least commit 6da03fcc459f4475553f394354ef37c628f39f97. I tried to > bisect my way into the past and find the offending change. > Unfortunately, I had to give up as trying to pull into commits around > August 2024 is close to impossible now. Many commits failed on me and I > never got anywhere close to where that change happened. > > > Therefor I am opening this bug report hoping that someone will help me > figure out what is going on here? I'm sorry, I do not know why this has recently become a problem for you. This GDK_PIXBUF_MODULE_FILE thing has been in Guix for at least 2 years. I think the best course of action would be to open an issue upstream against gdk-pixbuf, detailing our use case and how the current single entry GDK_PIXBUF_MODULE_FILE variable is a problematic, and throw the idea of having an actual search path of modules, such as GDK_PIXBUF_MODULE_FILES. If you get around to do that, please post the link so we can follow the conversation there, and perhaps participate. -- Thanks, Maxim
