Bug#741573: Two menu systems
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> I think you've misunderstood me. I felt Ansgar and I were discussing in
> the abstract what would be the most optimal situation. Certainly I'm
> not saying that policy should mandate the use of anything that doesn't
> currently exist.
> I think that whether the general machinery for converting icons etc. for
> the menu is sufficiently automatic/sophisticated is a matter for the
> submitters of trad menu integration patches.
Oh, okay.
> IMO if those patches aren't unreasonable then maintainers should accept
> them, even if they're slightly less automatic than would be ideal.
Sure. I don't think anyone anywhere in this discussion was advocating
rejecting contributed traditional menu entries in packages.
I do think that "should" in Policy is stronger than that, and I don't
think just weakening "should" for all of Policy is the right solution to
this bug. I also don't know if Bill would be happy with a weaker version
of "should" that's akin to how we handle man pages in practice.
> Has anyone described any actual difficulties with supporting the
> traditional menu ?
Not that I'm personally aware of apart from there being yet one more piece
of documentation to read and one more thing to have to pay attention to
when packaging something new. The Policy bug started with a request for
formally documenting and supporting desktop entries, and the question of
what level of requirement was appropriate for menu came out of that, not
out of a separate complaint.
One other side note: Policy has a very clear and broad mandate for what
should provide menu items, but I'm not sure that's widely known except to
the DE packagers (who, because of that mandate, generally *don't* want to
steer users towards the traditional menu). I don't think anyone
previously has laid out the two systems the way that you did as having far
different content *by design* instead of just by accident. I certainly
hadn't been thinking of it that way.
That may be an interesting way forward and remove a lot of tension. The
traditional menu would be for absolutely everything and the kitchen sink,
and desktop files would only be for programs that have reasonable
integration into a more typical GUI environment.
I think drawing that distinction clearly in Policy (which it does not
currently, since it doesn't mention desktop files at all, and which I
don't think the proposed patch does either) would provide a lot more
guidance about what people should do in practice and also provide more
explicit blessing for window manager packagers who aren't interested in
the all-encompassing menu to drop it (at least by default). That might be
a useful way to resolve this conflict and put to rest the periodic
arguments about whether, say, shells should have menu entries. They would
have traditional menu entries but not desktop files, and we could say that
explicitly.
That leaves Policy requesting, at the level of should, that people provide
integration for something that may not be that widely used, so I'd still
like to see us develop some sort of standard wording for things that are
more "would be nice" than "this is something you need to do for your
package to be considered a good package." Assuming, that is, Bill is okay
with putting traditional menu entries at that level. If not, then that's
still an open question.
I think doc-base integration is a fairly similar case, BTW. In that case,
Policy says that it is "recommended practice," which policy defines as
equivalent to "should." If anything, doc-base is probably less used by
end users than the traditional menu. (Personally, I think man pages are
more important than either, but man pages are also more work, and that's
to some extent personal preference.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: