Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Sat, 29 Aug 2015 20:00:55 -0700 Steve Langasek <vorlon@debian.org> wrote:
> On Fri, Aug 28, 2015 at 09:13:33AM -0400, Sam Hartman wrote:
> > If we adopt Keith's proposal without updating policy 9.6--we retainIs
> > the SHOULD have menu entries for all command line apps, but move the
> > metadata format to .desktop, we have a number of problems. We have no
> > way to express the category information and some of the other metadata
> > from the trad menu that's kind of important for its expanded scope.
>
> > So, it's not clear what should happen.
>
> > If we revise 9.6 and adopt Keith's proposal then we're basically
> > adopting the XDG menu's scope, but taking away the place where the
> > broader information could go.
>
> > In effect we leave menu entries that do belong on the trad menu but do
> > not belong on the XDG menu no where.
>
> > Depending on how we do things we may also significantly complicate the
> > runtime dependencies of light-weight windowmanagers if we force them to
> > parse .desktop files and do image conversion.
>
>
> > In effect by adopting Keith's proposal with an update to 9.6, we're
> > saying that as a matter of technical policy decided by the TC, there are
> > some menu entries on the trad menu that do not belong on any menu at
> > all.
>
> If this is the message that the ballot option is sending, then I agree that
> it's concerning. I'm aware there are some maintainers of desktop
> environments who view this as the goal; my support for Keith's proposal was
> predicated on the belief that this would /not/ be the outcome, but instead
> that we were describing a path forward by which existing menu system entries
> would be translated into .desktop files and the semantics would be
> preserved.
>
> The XDG .desktop format allows applications to specify that they should or
> should not be shown in particular environments using the
> OnlyShowIn/NotShowIn keywords. I assumed it would be straightforward to
> declare a new OnlyShowIn value that menu consumers could key on if they wish
> to show the traditional menu heirarchy, and that this could be implemented
> without causing any problems for the existing desktop environments.
OnlyShowIn/NotShowIn are certainly extensible; desktop environments (or
anything else deciding whether to use a .desktop file) only look for
their own name. (Algorithm: "If an OnlyShowIn exists without my name in
it, or a NotShowIn exists with my name in it, ignore the file.") So if
you want metadata saying "only show this in a console-based menu",
OnlyShowIn=console should work fine. Or if you want to hide a menu
entry from the console, NotShowIn=console works. .desktop files also
have a "Terminal" key to say whether an application needs a tty, and
desktop environments will automatically run such applications in the
user's preferred terminal emulator.
Looking at the various metadata in the menu file format:
- "title" becomes "Name".
- "longtitle" (with some editing) becomes "Comment". Some packages
include the title in the longtitle, while others don't, so the
translation needs manual review and editing here. Also, .desktop
files will want translated descriptions (and in some cases translated
names) too.
- "package" doesn't matter for any menu entry shipped *in* the package
in question.
- "needs" becomes a combination of OnlyShowIn/NotShowIn and Terminal.
For instance, needs=text becomes just Terminal=true, though some such
entries might want OnlyShowIn/NotShowIn. needs=vc should probably
become an OnlyShowIn=console or similar, if the application actually
needs a vc (for instance, something using svgalib or fb, or something
using Linux-console-specific mechanisms). needs=[xX]11 (case varies
in practice) should become "Terminal=false"; there's an
interesting special case for applications that have both console and
graphical versions in the same binary that would make life slightly
more difficult for console menu programs, but worst-case, a second
.desktop with an OnlyShowIn could help those menus out if anyone
cares.
- "section" needs semi-manual translation to Categories, though in
theory someone could create a mapping for all the menu sections shown
in /usr/share/doc/menu/menu.txt.gz . Also, for any section whose
corresponding categories don't include the same section names, I'd
suggest adding the verbatim menu section names to Keywords; some menu
systems (such as GNOME's) will use those as additional search terms
for a search-based menu, which may help users used to the menu
sections.
- "command" translates to "Exec", with some editing (e.g. removing
explicit use of "x-terminal-emulator" or similar in favor of
Terminal=true).
- "hints" works similarly to "section": it may inform the selection of
Categories, and some (though not all) of the hints should go into
"Keywords". The sample hints in menu.txt.gz (such as "Big" or
"Expert") shouldn't go into Keywords, but many of the hints used in
practice would make good Keywords.
- "icon" requires substitution of a better icon format; consumers of
.desktop files that can't handle current image formats could always
translate it back, though adding support for current image formats
provides more benefit for comparable effort.
Finally, as a last resort, while option D says you can't ship a menu
file if you also ship a .desktop file, you can still ship a menu file
*instead* of a .desktop file, if you really want to.
Based on the above analysis, I don't see a single instance of menu
metadata that wouldn't translate over to .desktop files.
- Josh Triplett
Reply to: