Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On 10/01/14 03:14, Lisandro Damián Nicanor Pérez Meyer wrote:
> WRT the current FDO wording, I like it.
>
> All packages that provide applications that need not be passed any
> special command line arguments for normal operation should register
> a menu entry for those applications
There is a slightly subtle distinction here between "applications that
needn't be passed any special command-line arguments" and
"applications that are normally run from a GUI menu". One of the
complaints about the Debian menu that I've seen from GNOME team
members is that it's *too* comprehensive. My /usr/share/menu includes
an assortment of GUI applications and games - great. It also includes
TUI (readline/curses/etc.) apps that I would not normally expect to
run from a GUI menu, like gdb(1). Yes, you can start gdb interactively
with no command-line arguments, and attach it to a process or core
afterwards - but I for one have never used it like that.
Worse, it includes TUI apps that are normally pulled in by
dependencies, like interactive python and tk interpreters. If a
non-developer user installs an app that is useful to them and happens
to be written in Python (like reportbug, picard or gramps), I don't
think that should result in them getting a Python 2.7 menu entry.
Similarly, there seems little value in a GUI environment having menu
entries for bash, dash, zsh: if the user wants a command-line
environment with a shell, that's what the xterm (or equivalent) menu
entry is for, and anyone who understands the difference between bash,
dash and zsh is probably also happy with chsh(1). At the moment, every
GUI user has Debian menu entries for bash and dash, due to their
Essential:yes status. I don't think those should appear in desktop
environments' menus.
There is something of a grey area for TUI apps that aren't pulled in
by dependencies, like irssi, htop, and curses/etc. games like nethack.
Are they normally run from the GUI, or from a command-line? "Yes". I
think it's fine for these to have a menu entry if they are leaf or
"close-to-leaf" packages that the user would recognize as "an app"
rather than "some scary confusing hacker thing that's part of the system".
Similar to my reasoning about distinguishing "normally a dependency"
vs. "normally installed deliberately", I think the people responsible
for the *-desktop tasks (a mixture of d-i and desktop-environment
maintainers, AIUI) should be aware of the menu entries that result
from installing tasks, and avoid having superfluous menu entries in a
default installation. I believe Priority:standard pulls in mutt(1),
for instance, and I don't think mutt belongs in a default
installation's GUI menus. (It currently ships a Debian menu entry, but
no fd.o menu entry.)
S
Reply to: