John Darrington <j...@darrington.wattle.id.au> skribis:
>
> > * 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.
Fortunately people don’t “want” to use Xt nowadays. ;-)
At any rate, I’m surprised this is so involved.
> > +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?
It’s ugly, there’s duplication, and hackers will not dare to touch it.
> 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.
Right, if we do both, that’s already much better.
> * Hack the hard coded defaults in the libXt source to use the profile
> settings instead of /usr
Maybe we should just do that, no? It’d be a local change, it would
achieve the same effect, and it would provide a good default.
WDYT?
I suppose there’s trickiness due to the fact that it’s C and we have to
concatenate strings…
> * 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.
Doesn’t sound great.
> 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.
OK. Thanks for the info and everything!
Ludo’.
