Bug#707851: debian-policy: soften the wording recommending menu files
Wouter Verhelst <wouter@debian.org> writes:
> It refers to some (unspecified) window manager implementations as
> "legacy", which I think is a no-go (if they're supported in Debian, by
> definition they're not legacy).
I think it's fair to say that not supporting desktop files for the menu
infrastructure makes a window manager legacy at this point. I use one of
those window managers personally, but the fact remains that this is the
direction in which the whole desktop world has gone, and most new window
managers, even those that aren't really trying to provide a desktop
environment, support them to the degree that they do things related to
desktop files.
> Apart from that, I would like to see rough feature parity, i.e.,
> - support for applications which start from a terminal, using the
> x-terminal-emulator alternative), without hardcoding the terminal
> emulator (for pdmenu or similar things) (possibly desktop files
> already support this; if so, feel free to just point that out ;)
I'm fairly sure they do. This is the Terminal=true setting.
> - per-user desktop entries (~/.menu, and update-menus run as user) that
> are not specific to the used user interface. (same note as on the
> previous item)
Already supported, although where you have to put the desktop file varies
depending on the environment. There is slow convergence (I think) on the
XDG paths, but we're not there yet.
> - an easy way for window managers that don't use the desktop format
> directly to be told when there are new entries and they need to
> rebuild their menu. With the Debian menu system, we have
> update-menus which is called at postinst time (possibly by a
> trigger, I'm not sure); there should be something similar for
> desktop entries. This might simply be implemented by a dpkg trigger
> that all interested window managers listen to and that
> desktop-installing packages should emit; but we should document such a
> procedure before making this switch.
It would be ideal if we had something like this in place, but the reality
of the situation is that we're already making this switch, and no one is
stepping forward to do this work. At some point, I think it becomes the
obligation of the fvwm (etc.) maintainers to do this work if they want to
see it done, rather than asking the GNOME and KDE and Xfce maintainers to
write code for window managers they don't use and don't support in order
to move forward with their upstream direction.
So I don't see this as a valid prerequisite.
> Moreover, we should have clear policies on what the contents of a
> .desktop file should look like, that goes way beyond just a vage URL
> over at freedesktop.org. Specifically, we need:
The URL is really not that vague, speaking as someone who wrote the
Lintian validation code based on the specification.
> - a replacement for our current menu policy which explains which types
> of applications will go where. Consistency across user interfaces is a
> *good* thing, and to get that we'll need to make some decisions
> ourselves, sometimes overriding upstreams. That should obviously be
> the exception rather than the rule (i.e., we should construct
> something that would allow us to keep "most" upstream desktop files,
> for whatever definition of "most" makes sense). Consistency across
> choice is one of Debian's strengths; we should strive to keep that
> feature.
> - A decision/clarification on what will happen when a desktop file
> contains the "only show this in GNOME" feature (with which they
> *actually* mean "don't show this in KDE") and the user interface in
> use is neither of those two.
I don't think either of these are related to this bug. We already have
tons and tons of packages with desktop files, so to the extent that these
are issues, they're already issues. Trying to hold up further
encouragement of desktop files at this point in order to fix these
problems feels counter-productive to me.
There is an existing fdo standard for what categories to use in what
situations, and while it's not as detailed as one might like, it's
workable. It might be worthwhile linking to it directly, although I think
the desktop file spec already does.
I do agree that both of these are desireable, though, and would strongly
encourage the various parties involved in menu implementations to get
together and find consensus on these sorts of issues. The result of that
consensus would be appropriate for inclusion in Policy (probably as a
desktop file sub-policy).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: