On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: > 9.6. Menus > ---------- > Two menu systems are used in Debian: the _FreeDesktop menu_ and the > 1 _Debian menu system_. Packages shipping applications that belong to > one or both menu systems should provide the necessary entry files to > integrate with them. I don't think this is off to a particularly good start. The purpose of Policy is to provide maintainers with concrete guidance about how to integrate with the rest of the system. Telling maintainers "there are these two systems and you can integrate with either of them as appropriate" is not really providing much guidance. It doesn't tell maintainers how to determine which menu system their package belongs to, and it doesn't tell maintainers of packages that want to consume a menu which one they should use. Furthermore, I think the idea of an application "belonging" to one system or the other is misplaced. The purpose of both the original menu system and the freedesktop standard is to give users consistent, menu-driven access to the software installed on the computer. While a given desktop environment is going to give precedence to software that is integrated with that desktop environment, users should be able to expect that they can access all software installed on the system through the GUI, via the appropriate submenus. Telling maintainers to integrate with one of two different menu systems does not achieve this. So if the Debian menu system is insufficiently expressive to meet our needs, we should be giving clear advice for the use of the fdo menu system. > * Unless hidden by default, the desktop entry must point to a PNG > or SVG icon with a transparent background, providing at least the > 22x22 size, and preferably up to 64x64. The icon should be > neutral enough to ingrate well with the default icon themes. It integrate > * In doubt, the package maintainer should coordinate with the > maintainers of menu implementations through the _debian-desktop_ > mailing list in order to avoid problems with categories or bad > interactions with other icons. Especially for packages which are > part of installation tasks, the contents of the > `NotShowIn'/`OnlyShowIn' keys should be validated by the > maintainers of the relevant environments. As a first cut this seems ok, but I would prefer to see more concrete guidance recorded in policy about what values of NotShowIn/OnlyShowIn should be used and when. > 9.7. Multimedia handlers > ------------------------ > Media types (formerly known as MIME types, Multipurpose Internet Mail > 3 Extensions, RFCs 2045-2049) is a mechanism for encoding files and data > streams and providing meta-information about them, in particular their > type and format (e.g. `image/png', `text/html', `audio/ogg'). > # Registration of media type handlers allows programs like mail user > # agents and web browsers to invoke these handlers to view, edit or > # display media types they don't support directly. > Packages which provide programs to view/show/play, compose, edit or > print media types should register them using either the _FreeDesktop_ > system or the _mailcap_ system. Again, I do not believe an either/or recommendation is appropriate here. This is abdicating the responsibility of Policy to provide concrete advice to maintainers. I believe we are at the point that we should be recommending a preference for the fdo MIME interfaces, together with appropriate transition handling to ensure proper integration with mime-support. It's possible that the transition is already handled transparently by the mime-support package and its triggers, such that no additional dependencies need to be added anywhere (since /etc/mailcap is already owned by mime-support, clearly any package which is consuming it should already be depending on it). In that case, no additional policy language is needed, other than to make it clear which of these two interfaces we are recommending that maintainers use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature