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 de
Re: Soften the the wording recommending menu files: let's do it in Jessie.
Hi, Steve Langasek wrote: > I believe we are at the point that we should be recommending a preference > for the fdo MIME interfaces Yep, and menus, too. 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 ? Thanks, Jonathan -- 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/20140105223941.ga15...@google.com
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
Processed: Re: Bug#734248: qtxmlpatterns-opensource-src: Misleading Description of -doc packages
Processing commands for cont...@bugs.debian.org: > tag 734248 pending Bug #734248 [qtxmlpatterns-opensource-src] qtxmlpatterns-opensource-src: Misleading Description of -doc packages Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 734248: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734248 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.s.c.13889579288728.transcr...@bugs.debian.org
Bug#734248: qtxmlpatterns-opensource-src: Misleading Description of -doc packages
tag 734248 pending thanks -- 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jan 05, 2014 at 03:00:05PM +0900, Charles Plessy wrote: Hi Charles, > + > + 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. > + 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: > 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
Bug#734248: qtxmlpatterns-opensource-src: Misleading Description of -doc packages
Package: qtxmlpatterns-opensource-src
Version: 5.1.1-1
Severity: minor
Tags: patch
Dear Maintainer,
The description of the two packages qtxmlpatterns5-doc and
qtxmlpatterns5-doc-html are
Qt 5 declarative documentation
Qt 5 declarative HTML documentation
shouldn't they be:
Qt 5 XML patterns documentation
Qt 5 XML patterns HTML documentation
?
a proposed patch:
diff -ru qtxmlpatterns-opensource-src-5.1.1/debian/control
my-qtxmlpatterns-opensource-src-5.1.1/debian/control
--- qtxmlpatterns-opensource-src-5.1.1/debian/control 2013-07-10
01:00:58.0 +0200
+++ my-qtxmlpatterns-opensource-src-5.1.1/debian/control2014-01-05
09:29:59.183921572 +0100
@@ -103,7 +103,7 @@
Architecture: all
Section: doc
Depends: ${misc:Depends}
-Description: Qt 5 declarative documentation
+Description: Qt 5 XML patterns documentation
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
.
@@ -114,7 +114,7 @@
Architecture: all
Section: doc
Depends: ${misc:Depends}
-Description: Qt 5 declarative HTML documentation
+Description: Qt 5 XML patterns HTML documentation
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
.
Regards,
m
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
http://bodrato.it/
--
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/51182.151.33.26.111.1388911080.squir...@mail.dm.unipi.it
Bug#734134: kdebase-bin: Strange PolicyKit1-KDE message asks for root password
Hi, This authentication request actually comes from nepomuk's filewatch module, see http://quickgit.kde.org/?p=nepomuk-core.git&a=commit&h=b0a49dab7 Cheers, Daniel -- 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/19842716.2ealDFzdUp@danpc
