Hi Timothy,

On Thu, 25 Apr 2019 14:49:42 -0400
Timothy Sample <samplet@ngyro.com> wrote:

> exploding.  I did look at Danny’s patch (#35377), and it would work, but
> it seems a little arbitrary.  Nothing understands the “Exec=custom”
> line, and our “xinitrc” runs “~/.xsession” regardless of what desktop
> entry is selected in the DM.

gdm does know it.  It bundles gdm Xsession startup scripts and then runs
".xsession" (see data/Xsession.in) if available, otherwise ~/.Xclients.

> There are two workarounds.  The first is to keep Danny’s patch as-is,
> but add logic to “xinitrc” so that it only uses “~/.xsession” when

.xinitrc is not picked up by gdm.  Do you mean by startx?

> break other DMs that don’t install a “custom.desktop”.  Maybe we could
> integrate it into all DMs at the service level.

Well, the best way would be for gdm to support .xsession files like anyone
else (without desktop file)--but I'm not holding my breath.
 
> This way, GDM fails cleanly when there are no “.desktop” files.  It
> doesn’t show up in the list, either (“NoDisplay=true”), so everything
> just kinda works as expected without any visible changes.

I want it to show up in the list.  Maybe we are trying to reach different
goals here.  I have a ~/.xsession script for close to a decade now and I
want gdm to use it.  It's not only to keep gdm from crashing, it's so I
can get into my normal customized desktop.

Doesn't Exec=false make the login fail?  Or do you mean gdm will pick up
.xsession anyway and run it--and after the session is terminated, the
login will fail?  Why would it then fail?  Why not make it succeed?

> Danny, maybe you could adjust your patch to follow the second option and
> apply it for the sake of everyone else who’s system profile doesn’t have
> any “.desktop” files.  It might save people headaches in the short-term
> regardless of what we settle on as a final solution.

Sounds good in principle, as long as it actually allows me to log in to
my desktop.

FWIW, "Exec=custom" is the way gdm itself does it.

Still, ~/.xinitrc is not picked up either way--which is too bad.