Re: [PATCH 1/4] gnu: Add XFILESEARCH path to profiles' environment.

[John Darrington]

    > * gnu/system.scm (operating-system-etc-service): Add new environment
    variable:
    
    The guix.texi change is missing from the log.

Thanks for noticing.
    
    > diff --git a/doc/guix.texi b/doc/guix.texi
    > index e64c361..9d133bb 100644
    > --- a/doc/guix.texi
    > +++ b/doc/guix.texi
    > @@ -1209,6 +1209,36 @@ data in the right format.
    >  This is important because the locale data format used by different libc
    >  versions may be incompatible.
    >  
    > address@hidden X Window System
    > address@hidden XFILESEARCHPATH
    > address@hidden @code{Xt}
    > address@hidden X Toolkit Intrinsics
    > address@hidden @command{xterm}
    > +
    > +If you intend to use X Toolkit Intrinsics client applications such
    > +as @command{xterm} then you should define the @code{XFILESEARCHPATH}
    > +environment variable:
    > +
    > address@hidden
    > +$ export XFILESEARCHPATH="$HOME/.guix-profile/share/X11/%L/%T/%N%C%S:
    > +  $HOME/.guix-profile/share/X11/%l/%T/%N%C%S:
    > +  $HOME/.guix-profile/share/X11/%T/%N%C%S:
    > +  $HOME/.guix-profile/share/X11/%L/%T/%N%S:
    > +  $HOME/.guix-profile/share/X11/%l/%T/%N%S:
    > +  $HOME/.guix-profile/share/X11/%T/%N%S:
    > +  $HOME/.guix-profile/lib/X11/%L/%T/%N%C%S:
    > +  $HOME/.guix-profile/lib/X11/%l/%T/%N%C%S:
    > +  $HOME/.guix-profile/lib/X11/%T/%N%C%S:
    > +  $HOME/.guix-profile/lib/X11/%L/%T/%N%S:
    > +  $HOME/.guix-profile/lib/X11/%l/%T/%N%S:
    > +  $HOME/.guix-profile/lib/X11/%T/%N%S"
    > address@hidden example
    
    Seriously?!  I mean, we can reasonably ask people to do that, can we?
    Is there another way?

*shrug?* It's one more variable to set. Granted it's a long one.  But it's
not *us* that's asking them to do it.  We are merely passing along advice
from the Xt lib developers (see below).   If people want to use Xt then
that's what they're supposed to do.

We could do is to provide a script for the user to source or copy to her
.profile
    
    Naive approach to look for candidate variables:
    
    --8<---------------cut here---------------start------------->8---
    $ ltrace -e getenv xterm 2>&1 |grep '"X'|sort -u
    libX11.so.6->getenv("XCOMPOSECACHE")             = nil
    libX11.so.6->getenv("XCOMPOSEFILE")              = nil
    libX11.so.6->getenv("XKB_DEBUG")                 = nil
    libX11.so.6->getenv("XKB_DISABLE")               = nil
    libX11.so.6->getenv("XKEYSYMDB")                 = nil
    libX11.so.6->getenv("XLIBBUFFERSIZE")            = nil
    libX11.so.6->getenv("XLIB_SKIP_ARGB_VISUALS")    = nil
    libX11.so.6->getenv("XLOCALEDIR")                = nil
    libX11.so.6->getenv("XMODIFIERS")                = nil
    libXau.so.6->getenv("XAUTHORITY")                = "/home/ludo/.Xauthority"
    libXt.so.6->getenv("XAPPLRESDIR")                = nil
    libXt.so.6->getenv("XENVIRONMENT")               = nil
    libXt.so.6->getenv("XFILESEARCHPATH")            = nil
    libXt.so.6->getenv("XTAPPPEEKEVENT_SKIPTIMER")   = nil
    libXt.so.6->getenv("XUSERFILESEARCHPATH")        = nil
    --8<---------------cut here---------------end--------------->8---
    
    Would one of these work better?  :-)

No. See below.

    > +export XFILESEARCHPATH=\"$HOME/.guix-profile/share/X11/%L/%T/%N%C%S:\\
    > +$HOME/.guix-profile/share/X11/%l/%T/%N%C%S:\\
    > +$HOME/.guix-profile/share/X11/%T/%N%C%S:\\
    > +$HOME/.guix-profile/share/X11/%L/%T/%N%S:\\
    > +$HOME/.guix-profile/share/X11/%l/%T/%N%S:\\
    > +$HOME/.guix-profile/share/X11/%T/%N%S:\\
    > +$HOME/.guix-profile/lib/X11/%L/%T/%N%C%S:\\
    > +$HOME/.guix-profile/lib/X11/%l/%T/%N%C%S:\\
    > +$HOME/.guix-profile/lib/X11/%T/%N%C%S:\\
    > +$HOME/.guix-profile/lib/X11/%L/%T/%N%S:\\
    > +$HOME/.guix-profile/lib/X11/%l/%T/%N%S:\\
    > +$HOME/.guix-profile/lib/X11/%T/%N%S:\\
    > +/run/current-system/profile/share/X11/%L/%T/%N%C%S:\\
    > +/run/current-system/profile/share/X11/%l/%T/%N%C%S:\\
    > +/run/current-system/profile/share/X11/%T/%N%C%S:\\
    > +/run/current-system/profile/share/X11/%L/%T/%N%S:\\
    > +/run/current-system/profile/share/X11/%l/%T/%N%S:\\
    > +/run/current-system/profile/share/X11/%T/%N%S:\\
    > +/run/current-system/profile/lib/X11/%L/%T/%N%C%S:\\
    > +/run/current-system/profile/lib/X11/%l/%T/%N%C%S:\\
    > +/run/current-system/profile/lib/X11/%T/%N%C%S:\\
    > +/run/current-system/profile/lib/X11/%L/%T/%N%S:\\
    > +/run/current-system/profile/lib/X11/%l/%T/%N%S:\\
    > +/run/current-system/profile/lib/X11/%T/%N%S\"
    
    That???s unreasonable IMO.

This is merely the default value that the Xt library sets, but I
have simply substituted "/usr" with "$HOME/.guix-profile" and
repeated it substituting "/run/current-system/profile".
It is a large string, but why is that a problem?

We can cut down on the size of this string iff we can somehow
guarantee that no package ever ships a file in any of those locations.

Some "solutions" (in my order of preference) are:

* The size of the above list can be halved, by dropping either the
.../lib/... or the .../share/... items - we just have to then make
sure that no package ships resource files in the one we drop.  Historically,
resource files were always in .../lib (as still are all official
sources from x.org) but recently third party packages have started
putting them in .../share.

* I *think* we could also get away with further reducing the set to 
    "$HOME/.guix-profile/lib/X11/%T/%N%S:
    /run/current-system/profile/lib/X11/%T/%N%S"
because, all the Xt dependent packages I've seen so far, put their
resource files there.  However, we cannot know what might get added
in the future.

* Hack the hard coded defaults in the libXt source to use the profile
settings instead of /usr

* Do what we had before:  Wrap *every* program which uses libXt in
a script setting XAPPLRESDIR - This is sure to annoy users because
it would override any XUSERFILESEARCHPATH they had set themselves.

    
    Is this motivated by the broken ctrl-click in xterm?  That thing used to
    work, I wonder what happened.

Xterm has never worked properly for me under GuixSD.  It "worked" under
Guix on Debian, presumably because it found the resource files from
the native installation.

Xterm not working was what prompted me to find out the cause.
But it will affect all and every package which provides X resource
files as a shipped file.

Anyway my general opinion is, that I agree that the value of this variable
is rather long, but:
1. I don't see why that is a problem.
2. It is how the X Consortium intends and recommends it to be used.
3. A competent user will not be intimidated by it.
4. A naive user will never be aware of it anyway.


For background information, see:

* http://www.faqs.org/faqs/Xt-FAQ
* The man page for XtResolvePathname
* The file specs/CH11.xml in the libXt source.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature