[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
- "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
- "command" translates to "Exec", with some editing (e.g. removing
  explicit use of "x-terminal-emulator" or similar in favor of
- "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: