Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Sun, Jan 05, 2014 at 02:33:20PM -0800, Steve Langasek wrote: 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. This is backward: the Debian menu system is more expressive than the fdo menu system and easier to support by window manager by requiring much less software support (in particular XDG menu requires XML processing). Debian menu is supported by much more window managers than the XDG menu draft. I do not believe Debian should favor desktop environment over lightweight window managers, especially since Debian users are more likely than other to favor use lightweight environments. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225224014.GG20431@yellowpig
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Tuesday 25 February 2014 23:40:14 Bill Allombert wrote: [snip] I do not believe Debian should favor desktop environment over lightweight window managers, especially since Debian users are more likely than other to favor use lightweight environments. If you are going to do that statement, please add the supporting data for it. -- 6: Cual es el boton del mouse que permite acceder a las acciones mas comunes del manejo de archivos * Depende el tipo de accion mas comun Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Wed, Feb 26, 2014 at 6:40 AM, Bill Allombert ballo...@debian.org wrote: Debian menu is supported by much more window managers than the XDG menu draft. This issue is addressed by the xdg-menu system from Arch Linux. https://wiki.archlinux.org/index.php/Xdg-menu For the awesome window manager there is also a specific addon. https://github.com/terceiro/awesome-freedesktop -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6e3ru1zxhohu9pk7w79hrljexapsk7xdq+5itvof6k...@mail.gmail.com
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Thu, Jan 09, 2014 at 01:15:16PM -0800, Jonathan Nieder a écrit : Alas, now that completeness is eroding and I don't see much reason to recommend in policy to continue to add entries, unless we have clear advice about when packagers should include an entry in it and when they should add to the fdo menu instead. As far as I can tell, the de facto policy is just to add to the fdo menu when appropriate. The documented policy is failing to describe that actual practice. Is there some subtlety I'm missing? Hi Jonathan and everybody, please, I would like to decouple two issues. - Issue 1: the Debian menu is superseded in major destkotop environments, and the Policy should recognise that the Debian menu is not the lead mechanism for managing menus in Debian anymore. Unfortutately we have two parallel systems at the moment. - Issue 2: deciding whether the Debian menu is actually obsolete and should be removed from the Policy. I have not yet read complains from users of the Debian menu system that it not comprehensive enough anymore. And while I am not using it, I see in “/usr/share/menu” computer the entries for evince, rythmbox, gedit, and even nautilus, showing that programs that are not strictly specific to GNOME are still there. What I have read is complains from non-users that they would prefer that somebody else does the work of keeping the Debian menu viable, which I think is a totally reasonable request (and to be clear, is also my position as a maintainer of packages having menu entries). If we tie Issue 1 to Issue 2, my gut feeling (not my wish) is that there is currently no way to conclude without going in front of the TC or having a GR, and prehaps demotivate some DDs in the meantime. Please let's not do that, and work so that the the Debian menu is not on the way of the major desktop systems on one hand, and (importantly) vice-versa. Let's avoid that activities in Debian become mutually destructive. So, in order to move forward, I would appreciate if people having stakes in the issue, or having expressed objections earlier, would say whether the patch I proposed is acceptable in principle after correction, and if not, what they are asking for exactly regarding: - Softening the recommendation to use the Debian menu, - documenting the FreeDesktop entry system (menu plus media types), - and since it seems to be a popular request, removing the documentation of the Debian menu from the Policy. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140109232104.ga4...@falafel.plessy.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Wednesday 08 January 2014 11:31:07 Charles Plessy wrote: [snip] Hi Lisandro, thanks for your answer. Input from all the parties is critical. in my point of view, the Policy has been used to bully the maintainers of FreeDesktop-compliant applications and desktop environments, and the patch that I propose, which calls the Debian Menu superseded in these situations, should stop that problem. On the other hand, it is the spirit of Debian to accept low-maintenance patches (in that case, menu entries) when it can help other projects even if one does not care for it. In that sense, if the Debian Menu has an active user base, it would be counter-productive to kill it with a top-down decision. Note that if generalised, top-down termination of people's projects can make Debian very, very small. Regardless of what you think of the Debian Menu, what do you think about my patch ? I was hopping to get more time to review all the bug, but saddly this is not happening, so let me point you want I don't think it's OK (which is debatable, but at least what I think). I think most of the stuff has been pointed out by someone else already. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. * I don't really think an application belongs to one or the other system. * If I where new to this I wouldn't understand which one should I pick. WRT the current FDO wording, I like it. All packages that provide applications that need not be passed any special command line arguments for normal operation should register a menu entry for those applications So even if you already provide a desktop file you must provide a menu one? If we are trying to say that the FDO is superseding the Debian menu then this needs to be rephrased. Kinds regards, Lisandro. -- Without us [Free Software developers], people would study computer science and programming without ever having seen a real program in its entirety. That's like becoming writers without ever having read a complete book. Matthias Ettrich, founder of the KDE project. http://www.efytimes.com/efytimes/25412/news.htm Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Cheers, -- Charles Le Mon, Jan 06, 2014 at 08:40:33AM +0900, Charles Plessy a écrit : Hi Steve, Jonathan, and Josselin, thanks to the two first of you for your comments. Josselin, there is a question for you below. About the lack of guidance, I think that it is a weakness of my wording, where for instance I used applications in one case and programs in the other case, but did not underline what difference is meant. For the media types, section 9.7.2 basically says that mailcap should be used if desktop entries are not used, but indeed this information could come earlier. I am proposing corrections below. Le Sun, Jan 05, 2014 at 02:33:20PM -0800, Steve Langasek a écrit : 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. 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. How about: Two independant menu systems are used in Debian. The FreeDesktop menu covers graphical applications that comply with minimal requirements of integration described below. The Debian menu system covers all graphical applications and interactive text-based programs. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. I think that now this clearly shows that everything that is covered by the FreeDesktop menu system is also covered by the Debian menu system. Furthermore, I think the idea of an application belonging to one system or the other is misplaced. I welcome suggestions if belonging can be better replaced by something like relevant to, in the scope of, etc. * 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. Josselin, it would be tremendous to have your input here since you wrote that paragraph. Others are of course welcome to make suggestions. 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. How about, in replacement of the previous paragraph: There are two overlaping systems to associate media types to programs which can handle them. The mailcap system is found on a large number of Unix systems. The FreeDesktop system is aimed at Desktop environments. In Debian, FreeDesktop entries are automatically translated in mailcap entries, therefore packages should only use one system at a time. I expect that maintainers of packages with a FreeDesktop menu entry will spontaneously declare media types through it and that it is not necessary to explicitely tell them which one to chose. I welcome suggestions of wording if you think it can be improved. Le Sun, Jan 05, 2014 at 02:39:41PM -0800, Jonathan Nieder a écrit : Do we have clear advice about (1) how to write a menu entry for my console app (or niche graphical app) without cluttering the menus used by the standard desktops (2) when, roughly, it is appropriate to use that facility to hide my menu entries Hi Jonathan, I think that it is not recommended to
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Wednesday 08 January 2014 08:33:31 Charles Plessy wrote: No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Not to be taken as KDE team reply, but here's my opinion. On Sunday 05 January 2014 14:53:12 Charles Plessy wrote: First of all, about the core of Sune's request to “soften the the wording recommending menu files”, in the current policy, it is already a should. To make this one softer would be to turn it completely optional at the maintainer's discretion, which does not make sense for a menu that aims at being comprehensive. That's right. So in my opinion we should simply kill the Debian menu system and let other environments implement the FreeDesktop one. The Debian menu system did serve it's purpose, now there is a much wider standard, so let's avoid wasting our time patching the holes on those who did not yet implemented it. So yes, I'm taken here a more aggressive standpoint that Sune took in his first mail. Kinds regards, Lisandro. -- Vió, buteó y andó Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#707851: Info received (Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Policy List debian-pol...@lists.debian.org If you wish to submit further information on this problem, please send it to 707...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 707851: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.707851.b707851.138914701427944.acki...@bugs.debian.org
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Tuesday 07 January 2014 23:09:55 Lisandro Damián Nicanor Pérez Meyer wrote: On Wednesday 08 January 2014 08:33:31 Charles Plessy wrote: No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Not to be taken as KDE team reply, but here's my opinion. On Sunday 05 January 2014 14:53:12 Charles Plessy wrote: First of all, about the core of Sune's request to “soften the the wording recommending menu files”, in the current policy, it is already a should. To make this one softer would be to turn it completely optional at the maintainer's discretion, which does not make sense for a menu that aims at being comprehensive. That's right. So in my opinion we should simply kill the Debian menu system Please understand kill as: let it live if you want, but don't recommend it. Or as Charles already wrote: turn it completely optional at the maintainer's discretion. -- No pienses que estoy loco, es sólo una manera de actuar De mí - Charly García Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#707851: Info received (Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Policy List debian-pol...@lists.debian.org If you wish to submit further information on this problem, please send it to 707...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 707851: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.707851.b707851.13891479851266.acki...@bugs.debian.org
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Tue, Jan 07, 2014 at 11:09:55PM -0300, Lisandro Damián Nicanor Pérez Meyer a écrit : On Wednesday 08 January 2014 08:33:31 Charles Plessy wrote: No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Not to be taken as KDE team reply, but here's my opinion. On Sunday 05 January 2014 14:53:12 Charles Plessy wrote: First of all, about the core of Sune's request to “soften the the wording recommending menu files”, in the current policy, it is already a should. To make this one softer would be to turn it completely optional at the maintainer's discretion, which does not make sense for a menu that aims at being comprehensive. That's right. So in my opinion we should simply kill the Debian menu system and let other environments implement the FreeDesktop one. The Debian menu system did serve it's purpose, now there is a much wider standard, so let's avoid wasting our time patching the holes on those who did not yet implemented it. Hi Lisandro, thanks for your answer. Input from all the parties is critical. in my point of view, the Policy has been used to bully the maintainers of FreeDesktop-compliant applications and desktop environments, and the patch that I propose, which calls the Debian Menu superseded in these situations, should stop that problem. On the other hand, it is the spirit of Debian to accept low-maintenance patches (in that case, menu entries) when it can help other projects even if one does not care for it. In that sense, if the Debian Menu has an active user base, it would be counter-productive to kill it with a top-down decision. Note that if generalised, top-down termination of people's projects can make Debian very, very small. Regardless of what you think of the Debian Menu, what do you think about my patch ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140108023106.gc28...@falafel.plessy.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: Dear all, Based on Josselin's contribution and the comments of Russ, I have written a patch for the Debian Policy, that documents the use of the FreeDesktop standards for the use of Desktop menus and media types (MIME). Thanks, Charles, this reads really nicely. Disclaimer: I admit to having no particular expertise in this area, nor do I have any specific affiliations. I do not feel in a position to meaningfully second this proposal. One suggested rewording: 9.7. Multimedia handlers [...] 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. I suggest appending but not both to make it really explicit (I know it's mentioned later in one of the subsections, but there's no harm in repeating it): ... should register them using either the _FreeDesktop_ system or the _mailcap_ system, but not both. Julian -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140105084812.ga6...@d-and-j.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jan 05, 2014 at 03:00:05PM +0900, Charles Plessy wrote: Hi Charles, + sect1 id=debian-menu + headingThe Debian menu system/heading + + p + The Debian menu unifies the menu systems of window managers. In + some desktop environments such as emGNOME/em and emKDE/em, + it has been superseded by the FreeDesktop menu and is hidden by + default. + /p You can add Xfce to the list. Regards, - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJSyWQ6AAoJEG3bU/KmdcClu/QIAKdFcoQSPtswsotH4Je1TPGI phzOYs3sy/Cn0vHkAnYioY73wUsKEY2hS5VP0viL3FIxGSp6yjDMcJgssPfqkk42 1N7X6wh00hZGpHSvjEinG91y0f7U5v5EqqhBR3D7l1Ppy+soFz3Dhwr8Zl/s20st 7szhIC9D/zmNWUaUYtiLzth8GtaClMzR0FszGQcasEh+WzjLoKNop4fSpySjY7oW bgs73erLh7+1FPKuAGlywj+UhFHxqiyJ75QYzXzxnAk013QrvSQL+eduwQRbiNLp fKPxaXXgpuyAGeyTluXP3gQWeLg4UdxBT72UA8kQeaCUFQr75+gTmanxQhbn7Qo= =8qc+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140105135511.gd32...@scapa.corsac.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Hi Steve, Jonathan, and Josselin, thanks to the two first of you for your comments. Josselin, there is a question for you below. About the lack of guidance, I think that it is a weakness of my wording, where for instance I used applications in one case and programs in the other case, but did not underline what difference is meant. For the media types, section 9.7.2 basically says that mailcap should be used if desktop entries are not used, but indeed this information could come earlier. I am proposing corrections below. Le Sun, Jan 05, 2014 at 02:33:20PM -0800, Steve Langasek a écrit : 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. 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. How about: Two independant menu systems are used in Debian. The FreeDesktop menu covers graphical applications that comply with minimal requirements of integration described below. The Debian menu system covers all graphical applications and interactive text-based programs. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. I think that now this clearly shows that everything that is covered by the FreeDesktop menu system is also covered by the Debian menu system. Furthermore, I think the idea of an application belonging to one system or the other is misplaced. I welcome suggestions if belonging can be better replaced by something like relevant to, in the scope of, etc. * 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. Josselin, it would be tremendous to have your input here since you wrote that paragraph. Others are of course welcome to make suggestions. 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. How about, in replacement of the previous paragraph: There are two overlaping systems to associate media types to programs which can handle them. The mailcap system is found on a large number of Unix systems. The FreeDesktop system is aimed at Desktop environments. In Debian, FreeDesktop entries are automatically translated in mailcap entries, therefore packages should only use one system at a time. I expect that maintainers of packages with a FreeDesktop menu entry will spontaneously declare media types through it and that it is not necessary to explicitely tell them which one to chose. I welcome suggestions of wording if you think it can be improved. Le Sun, Jan 05, 2014 at 02:39:41PM -0800, Jonathan Nieder a écrit : Do we have clear advice about (1) how to write a menu entry for my console app (or niche graphical app) without cluttering the menus used by the standard desktops (2) when, roughly, it is appropriate to use that facility to hide my menu entries Hi Jonathan, I think that it is not recommended to declare FreeDesktop menu entries for non-graphical programs and that it is more obvious now with the clarifications that I proposed. For hiding entries, let's iron it out (see above), but the final way to determine when it is appropriate is to contact the debian-desktop mailing list. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa,
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Dear all, Based on Josselin's contribution and the comments of Russ, I have written a patch for the Debian Policy, that documents the use of the FreeDesktop standards for the use of Desktop menus and media types (MIME). First of all, about the core of Sune's request to “soften the the wording recommending menu files”, in the current policy, it is already a should. To make this one softer would be to turn it completely optional at the maintainer's discretion, which does not make sense for a menu that aims at being comprehensive. Therefore, I propose to another way to “soften” the situation by writing, in the section on the Debian menu system, that it is superseded by the FreeDesktop menu system in GNOME and KDE. Here is how the Policy looks after the patch is applied. I have indicated with comments signs the parts that do not change significantly, and added numbers in the margin for my comments that follow the text. 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. 9.6.1. The FreeDesktop menu --- The FreeDesktop menu is a cross-distribution standard menu that is available in a large number of desktop environment including _GNOME_, _KDE_ or _Xfce_. Applications are registered through text files called _desktop entries_. Their format is described in the _Desktop Entry Specification_ at http://standards.freedesktop.org/desktop-entry-spec/latest/ and complementary information can be found in the _Desktop Menu Specification_ at http://standards.freedesktop.org/menu-spec/latest/. The desktop entry files are installed by the packages in the directory `/usr/share/applications' and the FreeDesktop menus are refreshed using _dpkg triggers_. It is therefore not necessary to depend on packages providing FreeDesktop menu systems. Entries displayed in the FreeDesktop menu should conform to the following minima for relevance and visual integration. * 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 is encouraged to ship the icon in the default _hicolor_ icon theme directories, or to use an existing icon from the _hicolor_ theme. * If the menu entry is not useful in the general case as a standalone application, the desktop entry should set the `NoDisplay' key to true, so that it can be configured to be displayed only by those who need it. * 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. Since the FreeDesktop menu is a cross-distribution standard, the 2 desktop entries written for Debian should be forwarded upstream, where they will benefit to other users and are more likely to receive extra contributions such as translations. 9.6.2. The Debian menu system - The Debian menu unifies the menu systems of window managers. In some desktop environments such as _GNOME_ and _KDE_, it has been superseded by the FreeDesktop menu and is hidden by default. # The Debian `menu' package provides a standard interface between # packages providing applications and _menu programs_ (either X window # managers or text-based menu programs such as `pdmenu'). # All packages that provide applications that need not be passed any # special command line arguments for normal operation should register a # menu entry for those applications, so that users of the `menu' package # will automatically get menu entries in their window managers, as well # in shells like `pdmenu'. # Menu entries should follow the current menu policy. # The menu policy can be found in the `menu-policy' files in the # `debian-policy' package. It is also available from the Debian web # mirrors at `/doc/packaging-manuals/menu-policy/ # (http://www.debian.org/doc/packaging-manuals/menu-policy/)'. # Please also refer to the _Debian Menu System_ documentation that comes # with the `menu' package for information about how to register your # applications. 9.7. Multimedia handlers Media types
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy a écrit : patch attached. Oops, here it is attached for real. Sorry for the noise ! -- Charles diff --git a/policy.sgml b/policy.sgml index dad8d23..1f0a006 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8054,81 +8054,224 @@ Reloading vardescription/var configuration...done. headingMenus/heading p - The Debian ttmenu/tt package provides a standard - interface between packages providing applications and - emmenu programs/em (either X window managers or - text-based menu programs such as prgnpdmenu/prgn). + Two menu systems are used in Debian: the emFreeDesktop menu/em + and the emDebian menu system/em. Packages shipping applications + that belong to one or both menu systems should provide the necessary + entry files to integrate with them. /p - p - All packages that provide applications that need not be - passed any special command line arguments for normal - operation should register a menu entry for those - applications, so that users of the ttmenu/tt package - will automatically get menu entries in their window - managers, as well in shells like ttpdmenu/tt. - /p + sect1 id=freedesktop-menu + headingThe FreeDesktop menu/heading - p - Menu entries should follow the current menu policy. - /p + p + The FreeDesktop menu is a cross-distribution standard menu that + is available in a large number of desktop environment including + emGNOME/em, emKDE/em or emXfce/em. Applications are + registered through text files called emdesktop entries/em. + Their format is described in the emDesktop Entry Specification/em + at url id=http://standards.freedesktop.org/desktop-entry-spec/latest/; + and complementary information can be found in the + emDesktop Menu Specification/em at + url id=http://standards.freedesktop.org/menu-spec/latest/;. + /p - p - The menu policy can be found in the ttmenu-policy/tt - files in the ttdebian-policy/tt package. - It is also available from the Debian web mirrors at - tturl name=/doc/packaging-manuals/menu-policy/ - id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt. - /p + p + The desktop entry files are installed by the packages in the + directory file/usr/share/applications/file and the FreeDesktop + menus are refreshed using emdpkg triggers/em. It is therefore + not necessary to depend on packages providing FreeDesktop menu + systems. + /p - p - Please also refer to the emDebian Menu System/em - documentation that comes with the packagemenu/package - package for information about how to register your - applications. - /p + p + Entries displayed in the FreeDesktop menu should conform to the + following minima for relevance and visual integration. + + list + item + Unless hidden by default, the desktop entry must point to a PNG + or SVG icon with a transparent background, providing at least + the 22times;22 size, and preferably up to 64times;64. The icon + should be neutral enough to ingrate well with the default icon + themes. It is encouraged to ship the icon in the default + emhicolor/em icon theme directories, or to use an existing + icon from the emhicolor/em theme. + /item + + item + If the menu entry is not useful in the general case as a + standalone application, the desktop entry should set the + ttNoDisplay/tt key to vartrue/var, so that it can be + configured to be displayed only by those who need it. + /item + + item + In doubt, the package maintainer should coordinate with the + maintainers of menu implementations through the + emdebian-desktop/em 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 ttNotShowIn/tt/ttOnlyShowIn/tt keys should be + validated by the maintainers of the relevant environments. + /item + /list + /p + + p + Since the FreeDesktop menu is a cross-distribution standard, the + desktop entries written for Debian should be forwarded upstream, + where they will benefit to other users and are more likely to + receive extra contributions such as translations. + /p + /sect1 + + sect1 id=debian-menu + headingThe Debian menu system/heading + + p + The Debian menu unifies the menu systems of window managers. In + some desktop environments such as emGNOME/em and emKDE/em, + it has been superseded by the FreeDesktop menu and is hidden by + default. + /p + + p + The Debian ttmenu/tt package provides a standard interface + between packages providing applications and emmenu programs/em + (either X window managers or text-based menu programs such as + prgnpdmenu/prgn). + /p + + p + All packages that provide applications that need not be passed any + special command line
