Bug#975631: debian-policy: window manager: remove reference to Debian menu

2022-09-21 Thread Simon McVittie
On Tue, 20 Sep 2022 at 21:45:28 -0700, Russ Allbery wrote:
> I just found https://bugs.debian.org/838777, which says packages that only
> provide a window manager without a mechanism for launching programs should
> not register as x-window-manager

See also https://bugs.debian.org/1004522 in which I proposed adding a
wayland-session virtual package, and in the process, ended up also proposing
x-session for /usr/share/xsessions/*.desktop.

In particular https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#30
has a brief survey of what display managers actually do, and
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#66 I tried to
document existing practice (which contradicts #838777).

> try to document what x-window-manager is really for in the new X world

This is part of what I tried to do in #1004522, but I was trying to
document what it is now (including literally-only-a-window-manager window
managers like mutter, not just tiny-desktop-environment window managers
like twm or openbox), rather than what it should be.

If we redefine x-window-manager to mean something that is more strict than
it is now, then we'll have a mixture of x-window-manager implementations
that meet the new requirement, and (perhaps essentially unmaintained)
x-window-manager implementations that don't; so I'm not sure that's such a
good idea. That's why I proposed adding a new virtual package instead.

I personally think the fully-integrated-system approach should be
that packages that want to be considered to be a session that you
can log into (potentially ranging from GNOME/KDE all the way down to
twm) should register themselves in /usr/share/xsessions/*.desktop
(or /usr/share/wayland-sessions/*.desktop), user-friendly display
managers like gdm/lightdm/sddm should list those and only those,
and people who want to construct their own tiny desktop environment
out of a window manager and some xterms should enable it by installing
something resembling
https://salsa.debian.org/gnome-team/gdm/-/blob/debian/master/debian/custom-x11-session.desktop
into /etc/X11/sessions. gdm3 installs that file into
/usr/share/doc/gdm3/examples for sysadmin convenience, but intentionally
does not install it in the search path.

Rationale: people who want to piece together their own desktop environment
programmatically are welcome to do so, but that setup inherently requires
configuration. Trying to list ~/.xsession in UIs is confusing to novice
users, because the display manager cannot know what it will result in,
so its user-facing name has to be either very technical ("Xsession")
or hopelessly vague (older gdm's "System X11 Default") or both; so we
should not inflict that UX on users who have not done the necessary
setup to get it to behave as they want it to. For a setup that already
requires configuration before it will be usable, adding one more piece
of configuration doesn't seem like an undue burden.

gdm3 (>= bookworm), sddm, slim and lxdm already follow what I'm advocating
here.

smcv



Bug#975631: debian-policy: window manager: remove reference to Debian menu

2022-09-20 Thread Russ Allbery
Russ Allbery  writes:

> I considered whether instead of starting with a priority of 40, we
> should instead bump the priority if the window manager supports the
> desktop specification, but I think this is a place where the structure
> of X environments has changed over the years.  It used to be that the
> window manager was what handled application menus, but now that's
> normally done by some other component of the desktop environment, or
> even just some toolbar app or other type of plugin that the user has
> chosen, and the window manager may be just a window manager.

> Given that, I don't think there's anything useful we can say here about
> menu management.  Old-school window managers that don't use a desktop
> environment (fvwm2, for instance) may implement support for desktop
> files, or for the Debian menu system for that matter; newer ones are
> likely to not handle menus at all and expect some other component to
> deal with that.

I just found https://bugs.debian.org/838777, which says packages that only
provide a window manager without a mechanism for launching programs should
not register as x-window-manager.  So I'm now not sure that just removing
the mention of the menu system is a complete fix and we may indeed need to
say something about handling *.desktop files, because x-window-manager may
really supposed to be a desktop environment.

I think we can keep this change in the next release because it doesn't
make anything worse, but we should probably also pursue #838777 and try to
document what x-window-manager is really for in the new X world.  (This is
almost certainly going to require advice from the folks who work on
desktop environments, since I have no idea how x-window-manager is used
today.)

-- 
Russ Allbery (r...@debian.org)  



Bug#975631: debian-policy: window manager: remove reference to Debian menu

2022-09-19 Thread Sean Whitton
control: tag -1 + pending

Hello,

On Sun 18 Sep 2022 at 07:53PM -07, Russ Allbery wrote:

> Ansgar  writes:
>
>> Section 11.8.4 "Packages providing a window manager" still references
>> the Debian menu.  But the Debian menu is deprecated.
>
>> I suggest to remove the reference, for example with the patch below.
>
>> --- a/policy/ch-customized-programs.rst
>> +++ b/policy/ch-customized-programs.rst
>> @@ -345,13 +345,7 @@ Packages that provide a window manager should declare 
>> in their
>>  alternative for ``/usr/bin/x-window-manager``, with a priority
>>  calculated as follows:
>>
>> --  Start with a priority of 20.
>> -
>> --  If the window manager supports the Debian menu system, add 20 points
>> -   if this support is available in the package's default configuration
>> -   (i.e., no configuration files belonging to the system or user have to
>> -   be edited to activate the feature); if configuration files must be
>> -   modified, add only 10 points.
>> +-  Start with a priority of 40.
>>
>>  -  If the window manager complies with `The Window Manager Specification
>> Project `_,
>
> Yes, this looks right to me.  Seconded.

Likewise seconded, and applied.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975631: debian-policy: window manager: remove reference to Debian menu

2022-09-18 Thread Russ Allbery
Ansgar  writes:

> Section 11.8.4 "Packages providing a window manager" still references
> the Debian menu.  But the Debian menu is deprecated.

> I suggest to remove the reference, for example with the patch below.

> --- a/policy/ch-customized-programs.rst
> +++ b/policy/ch-customized-programs.rst
> @@ -345,13 +345,7 @@ Packages that provide a window manager should declare in 
> their
>  alternative for ``/usr/bin/x-window-manager``, with a priority
>  calculated as follows:
>  
> --  Start with a priority of 20.
> -
> --  If the window manager supports the Debian menu system, add 20 points
> -   if this support is available in the package's default configuration
> -   (i.e., no configuration files belonging to the system or user have to
> -   be edited to activate the feature); if configuration files must be
> -   modified, add only 10 points.
> +-  Start with a priority of 40.
>  
>  -  If the window manager complies with `The Window Manager Specification
> Project `_,

Yes, this looks right to me.  Seconded.

I considered whether instead of starting with a priority of 40, we should
instead bump the priority if the window manager supports the desktop
specification, but I think this is a place where the structure of X
environments has changed over the years.  It used to be that the window
manager was what handled application menus, but now that's normally done
by some other component of the desktop environment, or even just some
toolbar app or other type of plugin that the user has chosen, and the
window manager may be just a window manager.

Given that, I don't think there's anything useful we can say here about
menu management.  Old-school window managers that don't use a desktop
environment (fvwm2, for instance) may implement support for desktop files,
or for the Debian menu system for that matter; newer ones are likely to
not handle menus at all and expect some other component to deal with that.

-- 
Russ Allbery (r...@debian.org)  



Bug#975631: debian-policy: window manager: remove reference to Debian menu

2020-11-24 Thread Ansgar
Package: debian-policy
Version: 4.5.1.0
Severity: normal
Tags: patch

Section 11.8.4 "Packages providing a window manager" still references
the Debian menu.  But the Debian menu is deprecated.

I suggest to remove the reference, for example with the patch below.

Ansgar

--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -345,13 +345,7 @@ Packages that provide a window manager should declare in 
their
 alternative for ``/usr/bin/x-window-manager``, with a priority
 calculated as follows:
 
--  Start with a priority of 20.
-
--  If the window manager supports the Debian menu system, add 20 points
-   if this support is available in the package's default configuration
-   (i.e., no configuration files belonging to the system or user have to
-   be edited to activate the feature); if configuration files must be
-   modified, add only 10 points.
+-  Start with a priority of 40.
 
 -  If the window manager complies with `The Window Manager Specification
Project `_,