Re: wrap-program

[Federico Beffa <beffa@ieee.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Federico Beffa <beffa@ieee.org> skribis:
>
>> 1. GSettings schemas: More than schemas compilation, the problem is that
>> the schemas are by default expected to be in $datadir/glib-2.0/schemas
>> (with $datadir usually being /usr/share).  In spite of this, other
>> directories can be specified with the help of the environment variable
>> $XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
>> of future application installations, we may want to define
>
> Right, that’s one of the reasons why the ‘glib’ package defines it as
> its search path (see glib.scm.)
>

I'm not sure I understand. Take emacs: the package does not have glib as
an input. However, it does have gtk+, which defines schemas in its own
tree ".../gtk+-3.10.1/share/glib-2.0/schemas" (and gtk+ is not an input
to glib). Therefore, having $XDG_DATA_DIRS in the glib package does not
help emacs. The emacs packge needs its own $XDG_DATA_DIRS pointing to
the gtk+ schemas.

>>
>> GTK_EXE_PREFIX="$HOME/.guix-profile"
>
> That would be easy and could be defined in /etc/profile on the
> standalone system.
>
> However that would force users to install GTK+ in their profile so that
> the modules it comes with are found, right?  This would be inconvenient.
>

Yes, so we should probably define $GTK_EXE_PREFIX in the emacs package
with the full path (/gnu/store/...) and not $HOME/.... And given that
the gtk+ module is provided by libcanberra, the latter should be an
input to emacs as well.

> Yes, this is the preferred solution, I think (and I think it’s this case
> it’s OK to have these two variables leak in sub-processes, as discussed
> with Mark.)  However, we’d like to factorize the extra phase that does
> the wrapping, so we don’t repeat it for each and every program.
>

Since I'm new to glib schemas and gtk modules, I'm trying to
understand the correct broadest approach before doing anything.

> I think these are mostly GUIs, unlikely to be launched by a service.
>

I was thinking about windows managers and desktops. Not sure they really
need this.

>> This could also serve the second purpose of providing initial default
>> applications (like guix itself!) to all users on "guix on distro"
>> systems.
>
> Hmm what do you mean?
>

I was thinking about a convenient mechanism for providing packages
visible to all users of a system.

Regards,
Fede