GNU bug report logs - #75523
Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load

Previous Next

Full log

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: bug-guix <at> gnu.org
Subject: Re: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native
 applications on foreign systems to load
Date: Wed, 15 Jan 2025 14:37:05 +0900

Hi Simon,

Simon Streit <simon <at> netpanic.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.