add support for an “Xclient” fallback session

[Yves-Alexis Perez]

Hey,

a Debian user reported a bug asking for support of a “Xclient” session similar to GDM. Basically it doesn't require a .desktop file specifying the session, but directly runs what's in .xsession.

Another way might be to add a “Default session” entry which would let the Xsession wrapper do the job. In Debian, we set it to /etc/X11/Xsession which will fall back to that file.

[Yves-Alexis Perez (corsac)]

When using the /etc/X11/Xsession wrapper, one can use the attached lightdm-xsession.desktop file, which will use the default Xsession (see Xsession(5)).

[Sebastien Bacher (seb128)]

Not sure if we want that entry in the default installation, that choice tends to confuse non technical users, those who are technical enough to edit their session can probably copy that .desktop from an example directory as well

[Yves-Alexis Perez (corsac)]

It's not only helpful for people technical enough to edit the session. For people installing only one session or window manager, that means it'll just work, since /etc/X11/Xsession script will default to x-session-manager then x-window-manager.

[Sebastien Bacher (seb128)]

the entry is still confusing and should not be necessary, if there is only one session available it should be listed under its real name then used by lightdm rather than having users confused by a Xclient session

[Yves-Alexis Perez (corsac)]

What if there's no session available? Not every window manager out there provides a desktop file, and some people are still used to put stuff in .xsession/.xinit/... (maybe more on Debian than Ubuntu though)

[Sebastien Bacher (seb128)]

still doesn't seem to be a reason to confuse normal users in 99% of the case, what about just fallbacking to that if there is no session (it could be displayed in this case) but not listing it if there are other valid sessions that can be used?

[Yves-Alexis Perez (corsac)]

That'd work too, but this solution had the advantage to not require any code change so it was a quick and dirty workaround for the Debian package :)

[Yves-Alexis Perez (corsac)]

But note that *preventing* people to chose what they're used to might not be the wisest. I don't really agree with the “confuse normal users in 99% of the case” (but again, it might depend which users we are considering).

[Andreas Rottmann (rotty)]

Yves-Alexis Perez <email address hidden> writes:

> But note that *preventing* people to chose what they're used to might
> not be the wisest.
>
Indeed. I don't really care if I have to tweak configs to enable my
~/.xsession script to be used, but with the Debian package, before this
issue had been fixed (assuming the .desktop file in question would have
been included as an example instead), I'd have had to:

# cp -a /usr/share/xsessions /etc
# cp /usr/share/doc/lightdm/examples/default.desktop /etc/xessions
# $EDITOR /etc/lightdm/lightdm.conf # to change the directory lightdm
                                    # looks for .desktop files in

Additionally, I would have had the burden to update my copy of the
desktop files in /etc/xessions, should they change in the package.
IMHO, for my usecase, that's quite more inconvinient than for some user
not caring about ~/.xsession just to ignore the corresponding dropdown
box entry.

> I don't really agree with the “confuse normal users in 99% of the
> case” (but again, it might depend which users we are considering).
>
If it's really decided, that for the Debian package, the default
Xsession should not be present in the menu, I'd at least expect
prominent documentation on how to enable this feature in
/usr/share/doc/lightdm/README.Debian (or somewhere similiar). Of
course, *I* prefer having that feature enabled by default (and thanks
for the fix, BTW).

Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>

[Yves-Alexis Perez (corsac)]

On mar., 2011-08-16 at 22:11 +0000, Andreas Rottmann wrote:
> Yves-Alexis Perez <email address hidden> writes:
>
> > But note that *preventing* people to chose what they're used to might
> > not be the wisest.
> >
> Indeed. I don't really care if I have to tweak configs to enable my
> ~/.xsession script to be used, but with the Debian package, before this
> issue had been fixed (assuming the .desktop file in question would have
> been included as an example instead), I'd have had to:
>
> # cp -a /usr/share/xsessions /etc
> # cp /usr/share/doc/lightdm/examples/default.desktop /etc/xessions
> # $EDITOR /etc/lightdm/lightdm.conf # to change the directory lightdm
> # looks for .desktop files in

Why copy stuff in /etc? You only need to put a .desktop file
in /usr/share/xsessions.
>
> Additionally, I would have had the burden to update my copy of the
> desktop files in /etc/xessions, should they change in the package.
> IMHO, for my usecase, that's quite more inconvinient than for some user
> not caring about ~/.xsession just to ignore the corresponding dropdown
> box entry.

Again, not necessary, you can still use the ones from /u/s/xsessions.
>
> > I don't really agree with the “confuse normal users in 99% of the
> > case” (but again, it might depend which users we are considering).
> >
> If it's really decided, that for the Debian package, the default
> Xsession should not be present in the menu, I'd at least expect
> prominent documentation on how to enable this feature in
> /usr/share/doc/lightdm/README.Debian (or somewhere similiar). Of
> course, *I* prefer having that feature enabled by default (and thanks
> for the fix, BTW).

For Debian package, it really depends on how the fix is done upstream,
but I might keep shipping the lightdm-xsession.desktop file even then,
because that's what Debian users are used to (at least that's what is
done in GDM 2).

Regards,
--
Yves-Alexis

[Andreas Rottmann (rotty)]

Yves-Alexis Perez <email address hidden> writes:

> On mar., 2011-08-16 at 22:11 +0000, Andreas Rottmann wrote:
>> Yves-Alexis Perez <email address hidden> writes:
>>
>> > But note that *preventing* people to chose what they're used to might
>> > not be the wisest.
>> >
>> Indeed. I don't really care if I have to tweak configs to enable my
>> ~/.xsession script to be used, but with the Debian package, before this
>> issue had been fixed (assuming the .desktop file in question would have
>> been included as an example instead), I'd have had to:
>>
>> # cp -a /usr/share/xsessions /etc
>> # cp /usr/share/doc/lightdm/examples/default.desktop /etc/xessions
>> # $EDITOR /etc/lightdm/lightdm.conf # to change the directory lightdm
>> # looks for .desktop files in
>
> Why copy stuff in /etc? You only need to put a .desktop file
> in /usr/share/xsessions.
>
You are technically correct, but this is bad practice, much for the same
reason as editing any file under /usr (save /usr/local, of course) is;
quoting FHS 2.3, Footnote 23[0]:

[0] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450

  Software placed in / or /usr may be overwritten by system upgrades
  (though we recommend that distributions do not overwrite data in /etc
  under these circumstances). For this reason, local software must not
  be placed outside of /usr/local without good reason.

I thought not mucking around in the areas reserved for the package
manager was common sense, and hence the reason for the copying to /etc
would be obvious, but it seems I was mistaken.

>> Additionally, I would have had the burden to update my copy of the
>> desktop files in /etc/xessions, should they change in the package.
>> IMHO, for my usecase, that's quite more inconvinient than for some user
>> not caring about ~/.xsession just to ignore the corresponding dropdown
>> box entry.
>
> Again, not necessary, you can still use the ones from /u/s/xsessions.
>>
See above.

>> > I don't really agree with the “confuse normal users in 99% of the
>> > case” (but again, it might depend which users we are considering).
>> >
>> If it's really decided, that for the Debian package, the default
>> Xsession should not be present in the menu, I'd at least expect
>> prominent documentation on how to enable this feature in
>> /usr/share/doc/lightdm/README.Debian (or somewhere similiar). Of
>> course, *I* prefer having that feature enabled by default (and thanks
>> for the fix, BTW).
>
> For Debian package, it really depends on how the fix is done upstream,
> but I might keep shipping the lightdm-xsession.desktop file even then,
> because that's what Debian users are used to (at least that's what is
> done in GDM 2).
>
I'd highly appreciate that (along with some documentation). In
addition, it would be really nice if lightdm (ideally upstream) provided
the capability of overriding (or extending) the .desktop files shipped
in /usr/share/xsessions with ones under the control of the system
administrator (instead of the package manager) in, say, /etc/xsessions.
I'm not sure how "hiding" menu entries could be facilitated, perhaps by
just creating an empty .desktop file in /etc/xessions, ...

[Robert Ancell (robert-ancell)]

I'm closing the LightDM component of this bug as "Wont Fix" as this is external to LightDM. The attached session file requires certain behaviour of the xsession-wrapper and I consider this a distribution setup choice. The method seems quite valid however and I don't see any problems with Debian doing it this way now or in the future.

In terms of Ubuntu using the same behaviour my vote is not too. We should probably put this session file into /usr/share/doc so it can be turned on if the user desires.

[Kjell L. (lkjell)]

This is so idiotic. First running ~/.xsession gets bork in lucid since .desktop files seems to be a better solution. Now you remove the .desktop file since 99% other people do not know what the special entry is. Perhaps revert back to how it was before like if you have ~/.xsession file then then run it? It is a very inconvenient if every time a user that uses xsession upgrade you have to recreate a file in /usr/share/xsession

[Selene ToyKeeper (toykeeper)]

The old .Xsession / .xinitrc feature is something that has worked
consistently for 15+ years on a variety of unixes, so I was
pretty surprised to find such an established behavior removed.

Each time I upgrade Ubuntu, I have to fix more and more things to
get my system working as well as it did before the upgrade. This
is one more item on my list of bugs to work around. However,
giving lightdm a desktop file for Xsession would reduce my
upgrade-fix list at least a little.

For me, the symptom was that when I tried to log in after
upgrade, lightdm authorized me, gave me a blank desktop for about
one second, then went back to the login screen. No files in my
home directory (such as .xsession-errors) were updated, and no
logs in /var/log/ contained any hint of what was wrong. I had to
guess what the problem was, test a few hypotheses, then research
it online for a fix. It's worth noting that choosing the login
option for my chosen window manager does *not* produce a suitable
session, and that this is not a bug in the window manager.

If this isn't going to be fixed, I suppose I can always go back
to putting 'exit 0' at the beginning of /etc/init.d/*dm and
running 'startx' manually from a VT. That would probably buy me
a few more years of not having to worry about the constant churn
in UI fads.