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

Bug#707851: debian-policy: soften the wording recommending menu files



Le dimanche 12 mai 2013 à 08:03 -0700, Russ Allbery a écrit : 
> >               * If the application will only be used directly in rare
> >                 cases – mostly called from a terminal, or used solely as
> >                 handler for a given MIME type, for example – the desktop
> >                 entry should include the NoDisplay=true stanza, so that
> >                 it can be configured to be displayed only by those who
> >                 need it. 
> 
> This looks mostly right to me.  I always found the inclusion of some
> things (dc, for example, or every shell on the system) in the Debian menu
> to be rather dubious, and likely to eat up a lot of menu real estate on a
> system with a full set of user packages installed.
> 
> I'm not sure that "mostly called from the terminal" is quite the right way
> of phrasing the point, but I'm not sure what the right way of handling it
> is.  My feeling is that things that make sense as applications (irssi,
> top) should be included in the menu, but things that are really just
> command-line utilities (other shells, telnet these days) probably
> shouldn't.  I'm not sure where ncftp, for example, falls in that list, but
> I think both units and bc would ideally appear in the menu.

How about simply “not useful as a standalone application”?

> >               * Unless hidden by default, the desktop entry MUST point
> >                 to a PNG or SVG icon with a transparent background,
> >                 providing at least the 22×22 size, and preferably up to
> >                 64×64. The icon should be neutral enough to ingrate well
> >                 with the default icon themes.
> 
> This is a relatively high bar if the icon has to be custom for that
> application, since most maintainers aren't going to have the skills to
> make icons.  Is it okay to just pick some reasonable icon from, say, the
> highcolor set?

We should even encourage using them. Using an icon from an icon theme
ensures several sizes can be available, for example. And it ensures it
can be overriden by another theme.

> >               * The maintainer should coordinate with the maintainers of
> >                 the menu implementations, in order to avoid bad
> >                 interactions with other wrong categories or icon
> >                 duplication.
> 
> If we're going to make this a should, I think we need to provide some sort
> of means for the maintainer to do that.  I personally have no idea how I
> would go about doing that coordination.

We could use the debian-desktop mailing list. I think there is at least
one person from each of the interested teams who reads it.

> > 9.7 Multimedia handlers

> This looks great as an addition to that section.  I think we should keep
> the current background information (the definition of MIME and the
> discussion of what it's used for), though, and at least for right now we
> should probably also keep the mailcap instructions, since I'm fairly sure
> they're still used by very widely used programs like mutt and the Emacs
> mail clients.

The latest mime-support in unstable makes use of desktop files. So while
for menu it still makes sense to ship legacy menu files, for MIME it is
not necessary anymore.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-


Reply to: