ctwm is not available in login screen

[biophysics]

Binary package hint: ctwm

apt-cache policy ctwm
ctwm:
  Installed: 3.7-3
  Candidate: 3.7-3
  Version table:
 *** 3.7-3 0
        500 http://mirror.ox.ac.uk intrepid/universe Packages
        100 /var/lib/dpkg/status

There is no file /usr/share/xsessions/ctwm.desktop to select it from KDM.

Anyone wanting to run ctwm has to create a .Xsession in home directory with
exec /usr/bin/ctwm

Since debian also does not contain this file the problem is due to "syncing" from debian.

[Bernhard R. Link (brlink)]

Sorry for the long CC:-line. But as this mass bug filing was not
announced on debian-devel before, there was no chance to counter-speak
there, so I CCed all to keep the negative effects small.

* Christopher Martin <email address hidden> [050925 18:03]:
> To make [your wm] a selectable option in gdm and kdm (though for the moment kdm
> provides its own file), wm2 should ship /usr/share/xsessions/wm2.desktop.
> These .desktop files take 2 minutes to create. Examples of the contents of
> such files can be found in the blackbox, afterstep, and wmaker packages.

I want to ask all ivolved partied to *not* add .desktop files.
(At least not without further discussion).

First I claim this is nothing window manager should need to do, but
this is gdm's and kdm's task. Every window manager should register
itself as 'needs="wm"' to the Debian menu system, and when gdm and
kdm want to show a menu of all installed window managers, they should
add a menu-method to get one automatically.

Secondly I claim that the work-around to have window managers not
yet involved with .desktop files including such a file for this purpose
is hazardous:

* It adds additional burden for Debian. Maintainers have to make sure
  another path is correct, another descriptions fits to another format.
  Maintainers or translators supplying patches have another place and
  another format to get translations for those descriptions. ...

* It adds another burder for those administrating Debian machines,
  as there is another format for those to learn when they want to
  add another window manager, or change the description of some
  windowmanager, or hide away a window manager from the users.

* It makes it harder to add a proper solution:
  Unless there is a common way to tell in the menu registry, that
  there is already a .desktop files, display managers supporting
  those files and also supporting the Debian menu will either have
  to disable the .desktop files or will have multiple entries, unless
  they do some inteligent matching. (And as we all know,
  inteligent means it might fail).
  For window managers also having or wanting a .desktop file for some
  reason, there are solutions like the 'kderemove="1"' KDE programs
  use to avoid multiple showings thinkable. But for that there needs
  to be such a agreed on token first and adding .desktop files before
  that only makes the situation worse in my eyes.

Thus I want to ask all involved parties to not ship .desktop files,
at least unless your window manager copes with .desktop files anyway.

Hochachtungsvoll,
 Bernhard R. Link

[Christopher Martin (christopher-martin)]

Hello,

The issue of how best to provide support for the freedesktop.org display
managers (kdm and gdm at the moment) has been discussed on debian-devel [1]
and in bug report #330064 [2]. Nothing approaching consensus was reached. I
outlined a number of issues that would have to be resolved before a system
of .desktop file auto-generation, as envisioned by Bernhard R. Link, would
be satisfactory, and no one volunteered to implement such a system.
Furthermore, it is my personal opinion (obviously not shared by everyone)
that such a system would provide little benefit. Anyone who did wish to
undertake such a task would be well advised to ask for help from the
menu-xdg and menu maintainers, Chris Cheney and Bill Allombert,
respectively.

This leaves maintainers with three choices:
1) Wait for someone to step forward and implement such a system, and solve
the problems it would raise.
2) Step forward themselves to implement such a system.
3) Add support to their own package, by creating a .desktop file and
shipping it in /usr/share/xsessions, as my original bug report suggested,
if they feel that their users would benefit. Obviously, this is my personal
recommendation.

I hope that this clarifies the situation, and will allow maintainers to make
informed judgments on how to proceed.

Cheers,
Christopher Martin

[1] http://lists.debian.org/debian-devel/2005/09/msg01188.html and
thereafter
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330064

[biophysics (molecularbiophysics)]

Binary package hint: ctwm

apt-cache policy ctwm
ctwm:
  Installed: 3.7-3
  Candidate: 3.7-3
  Version table:
 *** 3.7-3 0
        500 http://mirror.ox.ac.uk intrepid/universe Packages
        100 /var/lib/dpkg/status

There is no file /usr/share/xsessions/ctwm.desktop to select it from KDM.

Anyone wanting to run ctwm has to create a .Xsession in home directory with
exec /usr/bin/ctwm

Since debian also does not contain this file the problem is due to "syncing" from debian.

[biophysics (molecularbiophysics)]

Related to this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330045

(may be I have wasted your time - sorry)

[Launchpad Janitor (janitor)]

This bug was fixed in the package ctwm - 4.0.3-1

---------------
ctwm (4.0.3-1) unstable; urgency=medium

  * QA upload.
  * New upstream release. (Closes: #417526)
    + Switch to new upstream location.
  * Bump Standards-Version to 4.6.0.
  * debian/control:
    + Apply "wrap-and-sort -abst".
    + Switch to cmake buildsystem.
    + Update Vcs-* fields.
    + Use Rules-Requires-Root: no.
  * debian/rules: Rewrite with dh sequencer.
  * debian/patches: Drop all previous patches for a clean packaging.
  * debian/copyright: Rewrite with machine-readable copyright.
  * debian/ctwm.desktop: Add desktop file for usr/share/xsessions/.
    (Closes: #330045) (LP: #395575)
  * debian/ctwm.alternatives: Use declarative alternatives system.

 -- Boyuan Yang <email address hidden> Sun, 13 Mar 2022 11:01:49 -0400