Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#707851: debian-policy: soften the wording recommending menu files
1 view
Skip to first unread message
Sune Vuorela
May 11, 2013, 4:10:03 PM5/11/13
to
Package: debian-policy
Severity: normal
Dear Maintainer,
In the default desktop installation of Debian, the Debian menu is
actively hidden (On GNOME by a patch to gnome-menus).
In the - I think - most common alternate used desktop setup (KDE Plasma
Desktop), the Debian menu looks like a weird icon-less graft-on mostly
duplicating what is already in the menu structure elsewhere. And there
is people around KDE in Debian considering the same approach as Gnome.
And it is probably similar for many other window managers and desktop
environments.
Also, many popular packages have stopped providing menu-files for the
Debian menu.
So let's soften the wording a little around debian menu files in policy
so that people don't feel like they *have* to create menu files that
aren't much used.
So, I would suggest the following:
--- a/policy.sgml
+++ b/policy.sgml
@@ -7984,20 +7984,8 @@ Reloading <var>description</var> configuration...done.
<sect id="menus">
<heading>Menus</heading>
- <p>
- The Debian <tt>menu</tt> package provides a standard
- interface between packages providing applications and
- <em>menu programs</em> (either X window managers or
- text-based menu programs such as <prgn>pdmenu</prgn>).
- </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 <tt>menu</tt> package
- will automatically get menu entries in their window
- managers, as well in shells like <tt>pdmenu</tt>.
+ <p>Packages can, to be compatible with legacy debian additions
+ to some legacy window managers, provide a menu file.
</p>
<p>
Thank you for considering
/Sune
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Severity: normal
Dear Maintainer,
In the default desktop installation of Debian, the Debian menu is
actively hidden (On GNOME by a patch to gnome-menus).
In the - I think - most common alternate used desktop setup (KDE Plasma
Desktop), the Debian menu looks like a weird icon-less graft-on mostly
duplicating what is already in the menu structure elsewhere. And there
is people around KDE in Debian considering the same approach as Gnome.
And it is probably similar for many other window managers and desktop
environments.
Also, many popular packages have stopped providing menu-files for the
Debian menu.
So let's soften the wording a little around debian menu files in policy
so that people don't feel like they *have* to create menu files that
aren't much used.
So, I would suggest the following:
--- a/policy.sgml
+++ b/policy.sgml
@@ -7984,20 +7984,8 @@ Reloading <var>description</var> configuration...done.
<sect id="menus">
<heading>Menus</heading>
- <p>
- The Debian <tt>menu</tt> package provides a standard
- interface between packages providing applications and
- <em>menu programs</em> (either X window managers or
- text-based menu programs such as <prgn>pdmenu</prgn>).
- </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 <tt>menu</tt> package
- will automatically get menu entries in their window
- managers, as well in shells like <tt>pdmenu</tt>.
+ <p>Packages can, to be compatible with legacy debian additions
+ to some legacy window managers, provide a menu file.
</p>
<p>
Thank you for considering
/Sune
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
May 11, 2013, 4:40:02 PM5/11/13
to
Sune Vuorela <su...@debian.org> writes:
> So let's soften the wording a little around debian menu files in policy
> so that people don't feel like they *have* to create menu files that
> aren't much used.
I think I agree with this move, but I'd really like it to come in
> So let's soften the wording a little around debian menu files in policy
> so that people don't feel like they *have* to create menu files that
> aren't much used.
conjunction with adding a recommendation to include a desktop file, since
that's what most of the desktop environments actually use. That way, we
don't lose functionality.
Would you be willing to take a first stab at writing something like that?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Sune Vuorela
May 11, 2013, 5:00:01 PM5/11/13
to
On Saturday 11 May 2013 13:36:36 Russ Allbery wrote:
> I think I agree with this move, but I'd really like it to come in
> conjunction with adding a recommendation to include a desktop file, since
> that's what most of the desktop environments actually use. That way, we
> don't lose functionality.
>
> Would you be willing to take a first stab at writing something like that?
Something like:
> I think I agree with this move, but I'd really like it to come in
> conjunction with adding a recommendation to include a desktop file, since
> that's what most of the desktop environments actually use. That way, we
> don't lose functionality.
>
> Would you be willing to take a first stab at writing something like that?
--- a/policy.sgml
+++ b/policy.sgml
@@ -7984,20 +7984,18 @@ Reloading <var>description</var> configuration...done.
<sect id="menus">
<heading>Menus</heading>
- <p>
- The Debian <tt>menu</tt> package provides a standard
- interface between packages providing applications and
- <em>menu programs</em> (either X window managers or
- text-based menu programs such as <prgn>pdmenu</prgn>).
+ <p>Applications that belongs in the menu of a desktop environment
<heading>Menus</heading>
- <p>
- The Debian <tt>menu</tt> package provides a standard
- interface between packages providing applications and
- <em>menu programs</em> (either X window managers or
- text-based menu programs such as <prgn>pdmenu</prgn>).
+ or a window manager should provide desktop files for integrating
+ with the menus.
</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 <tt>menu</tt> package
- will automatically get menu entries in their window
- managers, as well in shells like <tt>pdmenu</tt>.
+ <tt><url name="http://standards.freedesktop.org/menu-spec/latest/"
+ id="http://standards.freedesktop.org/menu-spec/latest/"/></tt>
+ </p>
+
+ <p>Packages can, to be compatible with legacy debian additions
+ to some legacy window managers, provide a menu file.
</p>
<p>
/Sune
+ to some legacy window managers, provide a menu file.
</p>
<p>
--
Man, how to telnet from the tool?
You cannot receive the hardware, so that from Word you neither must send to a
9-inch SCSI terminale to a graphic connection, nor need to load from the BIOS
jumper for pinging a RW SMTP BIOS over a LCD processor of a IP hard disk of
the bus on the sendmail.
Charles Plessy
May 11, 2013, 9:20:01 PM5/11/13
to
Le Sat, May 11, 2013 at 10:48:47PM +0200, Sune Vuorela a �crit :
Dear Sune,
thank you for raising the issue.
I would like to clarify one point with you and Michael.
If we were to recommend FreeDesktop menu entries instead of Debian menu
entires, and if this recommendation were followed carefully, this would
increase the number of entries in the Gnome and KDE menus on some sytems where
the user has installed extra packages. In particular, some entries will
be redundant with the default applications, and provide only an XPM icon or
no icon at all.
One way to avoid this is to use HideIn keys, but this requires coordination
between the maintainers of the package providing menu entries, and the teams
maintaining Desktop environments. If there is already an unwritten norm about
this, then it would be the good time to add it to the Policy: regardless in
which package the menu entry file is, who has the final word on which menu
actually displays the entry.
It looks to me that the scope of the Debian menu system is broader than
the FreeDesktop system, so in line with the previous discussions about
the overlap between both, I think that the best way forward would be to
recommend to declare an entry in one system, but not both. For the
Debian menu system, this would require to add the capacity to read the
FreeDesktop entries in addition to the Debian menu entries. As noted
by Sune, some package maintainers have anyway decided already to stop
shipping Debian menu entries.
http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
About the current patch, I think that the mention of "legacy debian additions
to some legacy window managers" is not informative as it does not provide
guidance. For the both menu systems, I would like to have explanations about
1) what is the scope of this menu, 2) what is the standard syntax for the
entries, and 3) how packages should implement this.
For the FreeDesktop entries, can you summarise the expectations, in particular
about the scope and whether it is better to have a FreeDestkop entry with an
awful or missing icon or no entry at all ? This could be the basis for a
section 9.6.1, while the current part about the Debian menu would be 9.6.2.
Lastly, the FreeDesktop entry files have also associate programs with media
types, and as you probably noticed, this is in the scope of section 9.7
(Multimedia handlers), so please let us know your thougts or suggestions (maye
in a separate bug ?).
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
thank you for raising the issue.
I would like to clarify one point with you and Michael.
If we were to recommend FreeDesktop menu entries instead of Debian menu
entires, and if this recommendation were followed carefully, this would
increase the number of entries in the Gnome and KDE menus on some sytems where
the user has installed extra packages. In particular, some entries will
be redundant with the default applications, and provide only an XPM icon or
no icon at all.
One way to avoid this is to use HideIn keys, but this requires coordination
between the maintainers of the package providing menu entries, and the teams
maintaining Desktop environments. If there is already an unwritten norm about
this, then it would be the good time to add it to the Policy: regardless in
which package the menu entry file is, who has the final word on which menu
actually displays the entry.
It looks to me that the scope of the Debian menu system is broader than
the FreeDesktop system, so in line with the previous discussions about
the overlap between both, I think that the best way forward would be to
recommend to declare an entry in one system, but not both. For the
Debian menu system, this would require to add the capacity to read the
FreeDesktop entries in addition to the Debian menu entries. As noted
by Sune, some package maintainers have anyway decided already to stop
shipping Debian menu entries.
http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
About the current patch, I think that the mention of "legacy debian additions
to some legacy window managers" is not informative as it does not provide
guidance. For the both menu systems, I would like to have explanations about
1) what is the scope of this menu, 2) what is the standard syntax for the
entries, and 3) how packages should implement this.
For the FreeDesktop entries, can you summarise the expectations, in particular
about the scope and whether it is better to have a FreeDestkop entry with an
awful or missing icon or no entry at all ? This could be the basis for a
section 9.6.1, while the current part about the Debian menu would be 9.6.2.
Lastly, the FreeDesktop entry files have also associate programs with media
types, and as you probably noticed, this is in the scope of section 9.7
(Multimedia handlers), so please let us know your thougts or suggestions (maye
in a separate bug ?).
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Sune Vuorela
May 11, 2013, 10:30:01 PM5/11/13
to
Hi Charles
Thank you for your questions
On Sunday 12 May 2013 10:08:52 Charles Plessy wrote:
> If we were to recommend FreeDesktop menu entries instead of Debian menu
> entires, and if this recommendation were followed carefully, this would
> increase the number of entries in the Gnome and KDE menus on some sytems
> where the user has installed extra packages. In particular, some entries
> will be redundant with the default applications, and provide only an XPM
> icon or no icon at all.
Currently Plasma Desktop shows both the Debian menu and the 'real' menu - with
loads of overlaps between them. All these overlaps comes with one with a 'good
icon' and nice descriptions and everything. The other comes with a poor xpm
icon or no icon at all, and not always good descriptions of the program. I
think that if we stopped using the Debian menu and just used the Desktop Menu
Spec, it would result in *fewer* items in the menu, and best of all no
duplicates.
> It looks to me that the scope of the Debian menu system is broader than
> the FreeDesktop system.
It looks to me that the scopes are very similar, and the XDG system is
supported outside debian in most users systems without any extra effort. And in
many cases the XDG files are even translated by upstream.
> http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
I think this proposal is entirely orthogonal to what I'm suggesting.
> About the current patch, I think that the mention of "legacy debian
> additions to some legacy window managers" is not informative as it does not
> provide guidance. For the both menu systems, I would like to have
> explanations about 1) what is the scope of this menu, 2) what is the
> standard syntax for the entries, and 3) how packages should implement this.
I think that for 2) and 3) pointing to the existing specs is the right thing
to do, not trying to summarize the specs.
I'm not sure what you mean by 1)
> For the FreeDesktop entries, can you summarise the expectations, in
> particular about the scope and whether it is better to have a FreeDestkop
> entry with an awful or missing icon or no entry at all ?
I'm not sure what you mean by scope.
If the app is useful to have in the menu, then I have no opinion on bad
artistry. And luckily the artistry can actualy be overridden by regular icon
themes if the entries here are named matching the XDG icon spec, which I think
the desktop file spec references.
> Lastly, the FreeDesktop entry files have also associate programs with media
> types, and as you probably noticed, this is in the scope of section 9.7
> (Multimedia handlers), so please let us know your thougts or suggestions
It hasn't been within what I have been looking at so far, but I think that we
could gain a lot by consolidating on desktop files also for this type of
information.
/Sune
--
Do you know how may I explore with the SCSI space bar?
From Flash you either should mount a AGP software, or never have to telnet
from the connector for unmounting the hardware.
Thank you for your questions
On Sunday 12 May 2013 10:08:52 Charles Plessy wrote:
> If we were to recommend FreeDesktop menu entries instead of Debian menu
> entires, and if this recommendation were followed carefully, this would
> increase the number of entries in the Gnome and KDE menus on some sytems
> where the user has installed extra packages. In particular, some entries
> will be redundant with the default applications, and provide only an XPM
> icon or no icon at all.
loads of overlaps between them. All these overlaps comes with one with a 'good
icon' and nice descriptions and everything. The other comes with a poor xpm
icon or no icon at all, and not always good descriptions of the program. I
think that if we stopped using the Debian menu and just used the Desktop Menu
Spec, it would result in *fewer* items in the menu, and best of all no
duplicates.
> It looks to me that the scope of the Debian menu system is broader than
It looks to me that the scopes are very similar, and the XDG system is
supported outside debian in most users systems without any extra effort. And in
many cases the XDG files are even translated by upstream.
> http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
I think this proposal is entirely orthogonal to what I'm suggesting.
> About the current patch, I think that the mention of "legacy debian
> additions to some legacy window managers" is not informative as it does not
> provide guidance. For the both menu systems, I would like to have
> explanations about 1) what is the scope of this menu, 2) what is the
> standard syntax for the entries, and 3) how packages should implement this.
to do, not trying to summarize the specs.
I'm not sure what you mean by 1)
> For the FreeDesktop entries, can you summarise the expectations, in
> particular about the scope and whether it is better to have a FreeDestkop
> entry with an awful or missing icon or no entry at all ?
If the app is useful to have in the menu, then I have no opinion on bad
artistry. And luckily the artistry can actualy be overridden by regular icon
themes if the entries here are named matching the XDG icon spec, which I think
the desktop file spec references.
> Lastly, the FreeDesktop entry files have also associate programs with media
> types, and as you probably noticed, this is in the scope of section 9.7
> (Multimedia handlers), so please let us know your thougts or suggestions
could gain a lot by consolidating on desktop files also for this type of
information.
/Sune
--
Do you know how may I explore with the SCSI space bar?
From Flash you either should mount a AGP software, or never have to telnet
from the connector for unmounting the hardware.
Russ Allbery
May 11, 2013, 10:50:02 PM5/11/13
to
Sune Vuorela <su...@debian.org> writes:
> On Sunday 12 May 2013 10:08:52 Charles Plessy wrote:
>> If we were to recommend FreeDesktop menu entries instead of Debian menu
>> entires, and if this recommendation were followed carefully, this would
>> increase the number of entries in the Gnome and KDE menus on some
>> sytems where the user has installed extra packages. In particular,
>> some entries will be redundant with the default applications, and
>> provide only an XPM icon or no icon at all.
> Currently Plasma Desktop shows both the Debian menu and the 'real' menu
> - with loads of overlaps between them. All these overlaps comes with one
> with a 'good icon' and nice descriptions and everything. The other comes
> with a poor xpm icon or no icon at all, and not always good descriptions
> of the program. I think that if we stopped using the Debian menu and
> just used the Desktop Menu Spec, it would result in *fewer* items in the
> menu, and best of all no duplicates.
Charles's point, which has come up in a few other discussions, is that
> On Sunday 12 May 2013 10:08:52 Charles Plessy wrote:
>> If we were to recommend FreeDesktop menu entries instead of Debian menu
>> entires, and if this recommendation were followed carefully, this would
>> increase the number of entries in the Gnome and KDE menus on some
>> sytems where the user has installed extra packages. In particular,
>> some entries will be redundant with the default applications, and
>> provide only an XPM icon or no icon at all.
> Currently Plasma Desktop shows both the Debian menu and the 'real' menu
> - with loads of overlaps between them. All these overlaps comes with one
> with a 'good icon' and nice descriptions and everything. The other comes
> with a poor xpm icon or no icon at all, and not always good descriptions
> of the program. I think that if we stopped using the Debian menu and
> just used the Desktop Menu Spec, it would result in *fewer* items in the
> menu, and best of all no duplicates.
quite a few packages ship with Debian menu files but do not include
desktop files. One of the open questions (which I think Charles has tried
to pursue in the past) is whether every program with a Debian menu file
should have a desktop file. The answer to that question has obvious
implications for any migration strategy. I think that's what he's trying
to get at here, not the question of whether the Debian menu should be
enabled in a desktop environment.
I'd be very curious as to your opinion on that.
For example, on my system, there are Debian menu entries for bash, bc,
bsh, dash, dc, info, irssi, lynx-cur, ncftp, procps (top), psmisc
(pstree), tcsh, telnet, texlive-base (TeXconfig), units, w3m, and zsh. I
suspect that most, if not all, of those programs do not have desktop
files currently.
Do you want them to? A straightforward reading of this modification to
Policy, were I the bc and dc maintainer, would indicate that I should add
a desktop file to the package.
Charles Plessy
May 11, 2013, 11:20:01 PM5/11/13
to
Le Sun, May 12, 2013 at 04:22:56AM +0200, Sune Vuorela a �crit :
here are a few clarification in addition to the answer from Russ. I assume
that, as for Gnome, it is possible for KDE to hide the whole Debian menu if
wanted, so the question is about possible proliferation of FreeDestkop entries.
For 1) it could be any directive such as:
- packages should not include FreeDesktop entries for applications with no icon.
(or if the icon is not transparent, scalable, etc.)
- packages should include FreeDesktop entries for applications even if there
is no icon.
- packages should not use the HideIn key without sending an email to debian-devel
(or any other list).
- packages maintainer should accept patches adding HideIn keys to the FreeDesktop
entries.
For 2), in the case of FreeDesktop, it is the link to the spec.
For 3), it is a brief explanation that the entries should be deposited
in /usr/share/applications, and that the packages should not depend
or recommend desktop-file-utils, nor call its functions in their postinst,
because there are Dpkg triggers for this.
If there are other or similar recommendations, for instance regarding the icon
files, etc., please let us know.
Cheers,
--
Charles
>
> > About the current patch, I think that the mention of "legacy debian
> > additions to some legacy window managers" is not informative as it does not
> > provide guidance. For the both menu systems, I would like to have
> > explanations about 1) what is the scope of this menu, 2) what is the
> > standard syntax for the entries, and 3) how packages should implement this.
>
> I think that for 2) and 3) pointing to the existing specs is the right thing
> to do, not trying to summarize the specs.
>
> I'm not sure what you mean by 1)
Hi again,
> > About the current patch, I think that the mention of "legacy debian
> > additions to some legacy window managers" is not informative as it does not
> > provide guidance. For the both menu systems, I would like to have
> > explanations about 1) what is the scope of this menu, 2) what is the
> > standard syntax for the entries, and 3) how packages should implement this.
>
> I think that for 2) and 3) pointing to the existing specs is the right thing
> to do, not trying to summarize the specs.
>
> I'm not sure what you mean by 1)
here are a few clarification in addition to the answer from Russ. I assume
that, as for Gnome, it is possible for KDE to hide the whole Debian menu if
wanted, so the question is about possible proliferation of FreeDestkop entries.
For 1) it could be any directive such as:
- packages should not include FreeDesktop entries for applications with no icon.
(or if the icon is not transparent, scalable, etc.)
- packages should include FreeDesktop entries for applications even if there
is no icon.
- packages should not use the HideIn key without sending an email to debian-devel
(or any other list).
- packages maintainer should accept patches adding HideIn keys to the FreeDesktop
entries.
For 2), in the case of FreeDesktop, it is the link to the spec.
For 3), it is a brief explanation that the entries should be deposited
in /usr/share/applications, and that the packages should not depend
or recommend desktop-file-utils, nor call its functions in their postinst,
because there are Dpkg triggers for this.
If there are other or similar recommendations, for instance regarding the icon
files, etc., please let us know.
Cheers,
--
Charles
Sune Vuorela
May 11, 2013, 11:30:01 PM5/11/13
to
On Saturday 11 May 2013 19:44:13 Russ Allbery wrote:
<console apps>
wether or not a app runs in a terminal window.
if they are categorized properly, I don't see a issue with having them around,
but I personally might not want to encourage them.
/Sune
--
How might I do for disabling the submenu?
You neither should ever reinstall on the jumper, nor need to ping to the line
of a processor over a graphic directory but from Netscape and from the control
folder menu inside MS-DOS you either must remove from the fan, or can never
telnet on a MIDI ADSL case.
<console apps>
> Do you want them to? A straightforward reading of this modification to
> Policy, were I the bc and dc maintainer, would indicate that I should add
> a desktop file to the package.
There is as such nothing wrong with it, and the spec even supports defining
> Policy, were I the bc and dc maintainer, would indicate that I should add
> a desktop file to the package.
wether or not a app runs in a terminal window.
if they are categorized properly, I don't see a issue with having them around,
but I personally might not want to encourage them.
/Sune
--
How might I do for disabling the submenu?
You neither should ever reinstall on the jumper, nor need to ping to the line
of a processor over a graphic directory but from Netscape and from the control
folder menu inside MS-DOS you either must remove from the fan, or can never
telnet on a MIDI ADSL case.
Sune Vuorela
May 11, 2013, 11:50:01 PM5/11/13
to
On Sunday 12 May 2013 12:09:28 Charles Plessy wrote:
> Hi again,
>
> here are a few clarification in addition to the answer from Russ. I assume
> that, as for Gnome, it is possible for KDE to hide the whole Debian menu if
> wanted, so the question is about possible proliferation of FreeDestkop
> entries.
Thank you for the clarification. for Gnome, the disabling is very hardcoded in
> Hi again,
>
> here are a few clarification in addition to the answer from Russ. I assume
> that, as for Gnome, it is possible for KDE to hide the whole Debian menu if
> wanted, so the question is about possible proliferation of FreeDestkop
> entries.
the sources. "nothing coming from menu-xdg will ever be shown". I have been
considering something similar in KDE-land.
> For 1) it could be any directive such as:
>
> For 2), in the case of FreeDesktop, it is the link to the spec.
>
> For 3), it is a brief explanation that the entries should be deposited
> in /usr/share/applications, and that the packages should not depend
> or recommend desktop-file-utils, nor call its functions in their postinst,
> because there are Dpkg triggers for this.
> If there are other or similar recommendations, for instance regarding the
> icon files, etc., please let us know.
more explicit than that. Maybe mentioning a basedir.
/Sune
--
I cannot get access over the hard disk from the drawer menu within Explorer,
how does it work?
You have to enable a board for renaming the desktop of the pointer.
Josselin Mouette
May 12, 2013, 4:30:02 AM5/12/13
to
Hi,
Le dimanche 12 mai 2013 à 10:08 +0900, Charles Plessy a écrit :
> If we were to recommend FreeDesktop menu entries instead of Debian menu
> entires, and if this recommendation were followed carefully, this would
> increase the number of entries in the Gnome and KDE menus on some sytems where
> the user has installed extra packages. In particular, some entries will
> be redundant with the default applications, and provide only an XPM icon or
> no icon at all.
>
> One way to avoid this is to use HideIn keys, but this requires coordination
> between the maintainers of the package providing menu entries, and the teams
> maintaining Desktop environments. If there is already an unwritten norm about
> this, then it would be the good time to add it to the Policy: regardless in
> which package the menu entry file is, who has the final word on which menu
> actually displays the entry.
Currently, the final word on the menus layout is in the hands of the
menu implementations’ maintainers. However, some maintainers being
uncooperative about menu categories or OnlyShowIn/NotShowIn lead us to
implement a blacklist mechanism in gnome-menus.
Maybe the wording should encourage maintainers to be careful before
providing menu entries that don’t serve any purpose at all. There is
nothing wrong per se with menu entries for text programs, for example,
but if practically speaking, users won’t use them outside already
launched terminals, it doesn’t make any sense to ship them.
> It looks to me that the scope of the Debian menu system is broader than
> the FreeDesktop system, so in line with the previous discussions about
> the overlap between both, I think that the best way forward would be to
> recommend to declare an entry in one system, but not both.
I don’t think the basic purpose is different. It’s just that so far, the
Debian menu maintainers have put menu completeness before usability. We
should use the opportunity of a policy change to take care of that.
You are also right about MIME handling; now that you have updated
mime-support in unstable (thanks!). As such, let me propose an alternate
wording.
9.6 Menus
Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/
However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
* 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.
* 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.
* The maintainer should coordinate with the maintainers of
the menu implementations, in order to avoid bad
interactions with other wrong categories or icon
duplication. Especially for packages installed by
default, the contents of the NotShowIn/OnlyShowIn
stanzas should be validated by the maintainers of the
relevant environments.
Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file.
9.7 Multimedia handlers
Packages shipping applications able to view, edit or point to
files of a given MIME type (e.g. audio/x-mp3 or text/plain),
and/or open links with a given URI scheme, should provide
desktop files as described in §9.6, and using the MimeType
stanza. For URI schemes, the relevant MIME types are
x-scheme-handler/* (e.g. x-scheme-handler/https).
The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.
Until its addition to “shared-mime-info”, the package can ship a
MIME file as described in the Shared MIME-info specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Le dimanche 12 mai 2013 à 10:08 +0900, Charles Plessy a écrit :
> If we were to recommend FreeDesktop menu entries instead of Debian menu
> entires, and if this recommendation were followed carefully, this would
> increase the number of entries in the Gnome and KDE menus on some sytems where
> the user has installed extra packages. In particular, some entries will
> be redundant with the default applications, and provide only an XPM icon or
> no icon at all.
>
> One way to avoid this is to use HideIn keys, but this requires coordination
> between the maintainers of the package providing menu entries, and the teams
> maintaining Desktop environments. If there is already an unwritten norm about
> this, then it would be the good time to add it to the Policy: regardless in
> which package the menu entry file is, who has the final word on which menu
> actually displays the entry.
menu implementations’ maintainers. However, some maintainers being
uncooperative about menu categories or OnlyShowIn/NotShowIn lead us to
implement a blacklist mechanism in gnome-menus.
Maybe the wording should encourage maintainers to be careful before
providing menu entries that don’t serve any purpose at all. There is
nothing wrong per se with menu entries for text programs, for example,
but if practically speaking, users won’t use them outside already
launched terminals, it doesn’t make any sense to ship them.
> It looks to me that the scope of the Debian menu system is broader than
> the FreeDesktop system, so in line with the previous discussions about
> the overlap between both, I think that the best way forward would be to
> recommend to declare an entry in one system, but not both.
Debian menu maintainers have put menu completeness before usability. We
should use the opportunity of a policy change to take care of that.
You are also right about MIME handling; now that you have updated
mime-support in unstable (thanks!). As such, let me propose an alternate
wording.
9.6 Menus
Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/
However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
* 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.
* 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.
* The maintainer should coordinate with the maintainers of
the menu implementations, in order to avoid bad
interactions with other wrong categories or icon
duplication. Especially for packages installed by
default, the contents of the NotShowIn/OnlyShowIn
stanzas should be validated by the maintainers of the
relevant environments.
Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file.
9.7 Multimedia handlers
Packages shipping applications able to view, edit or point to
files of a given MIME type (e.g. audio/x-mp3 or text/plain),
and/or open links with a given URI scheme, should provide
desktop files as described in §9.6, and using the MimeType
stanza. For URI schemes, the relevant MIME types are
x-scheme-handler/* (e.g. x-scheme-handler/https).
The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.
Until its addition to “shared-mime-info”, the package can ship a
MIME file as described in the Shared MIME-info specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Bill Allombert
May 12, 2013, 6:10:02 AM5/12/13
to
On Sat, May 11, 2013 at 10:07:08PM +0200, Sune Vuorela wrote:
> Package: debian-policy
> Severity: normal
>
> Dear Maintainer,
>
> In the default desktop installation of Debian, the Debian menu is
> actively hidden (On GNOME by a patch to gnome-menus).
>
> In the - I think - most common alternate used desktop setup (KDE Plasma
> Desktop), the Debian menu looks like a weird icon-less graft-on mostly
> duplicating what is already in the menu structure elsewhere. And there
> is people around KDE in Debian considering the same approach as Gnome.
What happened to the notion of letting user enable Debian menu fi they liked it
> Package: debian-policy
> Severity: normal
>
> Dear Maintainer,
>
> In the default desktop installation of Debian, the Debian menu is
> actively hidden (On GNOME by a patch to gnome-menus).
>
> In the - I think - most common alternate used desktop setup (KDE Plasma
> Desktop), the Debian menu looks like a weird icon-less graft-on mostly
> duplicating what is already in the menu structure elsewhere. And there
> is people around KDE in Debian considering the same approach as Gnome.
?
> And it is probably similar for many other window managers and desktop
> environments.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Sune Vuorela
May 12, 2013, 7:00:01 AM5/12/13
to
On Sunday 12 May 2013 12:07:30 Bill Allombert wrote:
> > And it is probably similar for many other window managers and desktop
> > environments.
>
> How many window managers support the XDG menu specification ?
Most[tm]
> > And it is probably similar for many other window managers and desktop
> > environments.
>
> How many window managers support the XDG menu specification ?
It is *the* menu in Gnome, in KDE's workspaces, in XFCE, in LXDE, in razor-qt,
in trinity, mate, cinnamon.
For fluxbox, openbox, blackbox, fvwm, icewm, windowmaker, gnustep and probably
others, there exists scripts that convert a XDG menu structure into their own
formats, not unlike currently where scripts is used to convert the debian menu
structure into their own formats.
/Sune
--
Do you know how can I overclock the connector?
From the tools inside Outlook you must install a firewall in order to unlink a
window of a virus.
Russ Allbery
May 12, 2013, 11:10:02 AM5/12/13
to
Josselin Mouette <jo...@debian.org> writes:
> You are also right about MIME handling; now that you have updated
> mime-support in unstable (thanks!). As such, let me propose an alternate
> wording.
This looks like the right idea to me.
> You are also right about MIME handling; now that you have updated
> mime-support in unstable (thanks!). As such, let me propose an alternate
> wording.
> 9.6 Menus
>
> Packages shipping applications that belong in the menu of a
> desktop environment should provide desktop files for integrating
> with the menus, following the Desktop Menu Specification
> available at
> http://standards.freedesktop.org/desktop-entry-spec/latest/
>
> However, the maintainer should remind that the menu is often the
> primary interface for the user, and as such it should be filled
> with what is most useful to her. Therefore :
> * 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.
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.
> * 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.
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?
> * The maintainer should coordinate with the maintainers of
> the menu implementations, in order to avoid bad
> interactions with other wrong categories or icon
> duplication.
of means for the maintainer to do that. I personally have no idea how I
would go about doing that coordination. (It's not immediately apparent,
from outside the desktop world, that by "maintainers of menu
implementations" you mean "maintainers of software that use desktop files
to present menus.")
> Especially for packages installed by default, the contents
> of the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
> Packages can, to be compatible with Debian additions to some
> legacy window managers, also provide a menu file.
including the pointer to the current menu specification. (It's still
required, so far as I know, for menu support in fvwm, which is still
fairly widely used among old-school folks like myself.)
> 9.7 Multimedia handlers
> Packages shipping applications able to view, edit or point to
> files of a given MIME type (e.g. audio/x-mp3 or text/plain),
> and/or open links with a given URI scheme, should provide
> desktop files as described in §9.6, and using the MimeType
> stanza. For URI schemes, the relevant MIME types are
> x-scheme-handler/* (e.g. x-scheme-handler/https).
>
> The list of supported MIME types, as well as the corresponding
> file magic and filename extensions, is provided by the
> “shared-mime-info” package. If an application needs to support a
> new MIME type, the maintainer should request its addition to
> shared-mime-info first, to the Debian or upstream freedesktop
> maintainers.
>
> Until its addition to “shared-mime-info”, the package can ship a
> MIME file as described in the Shared MIME-info specification:
> http://standards.freedesktop.org/shared-mime-info-spec/latest/
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.
Josselin Mouette
May 12, 2013, 5:50:02 PM5/12/13
to
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”?
> > * 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.
> > * 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?
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.
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.
for menu it still makes sense to ship legacy menu files, for MIME it is
not necessary anymore.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Russ Allbery
May 12, 2013, 7:10:01 PM5/12/13
to
Josselin Mouette <jo...@debian.org> writes:
> Le dimanche 12 mai 2013 à 08:03 -0700, Russ Allbery a écrit :
>> 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”?
That sounds great to me.
> Le dimanche 12 mai 2013 à 08:03 -0700, Russ Allbery a écrit :
>> 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”?
>> 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.
things much easier when adding more desktop files.
> 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.
>> 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.
migration. Indeed, that means there's probably no need to say anything at
all, unless we still need to mention it in passing in case someone has a
need for the type of mailcap file that can't be represented by desktop
files (if there even are any these days).
Charles Plessy
May 12, 2013, 7:40:01 PM5/12/13
to
Le Sun, May 12, 2013 at 04:06:48PM -0700, Russ Allbery a �crit :
there may be some confusion as for media types, the Debian menu is not
involved. Currently, the Policy �9.7 details how to place files in mailcap
format in /usr/lib/mime/packages/. I would like to keep this as a possibility
until we are sure that we can rely solely on FreeDesktop menu entries.
I will test (later... but others are welcome to try and report) how far the
mime-support package can do the transition for the default mailcap entries that
it ships, and I will add a section in the next Developers News to suggest to
others to try the migration.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
>
> > 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.
>
> Oh! Right, I remember that now; sorry about forgetting the status of that
> migration. Indeed, that means there's probably no need to say anything at
> all, unless we still need to mention it in passing in case someone has a
> need for the type of mailcap file that can't be represented by desktop
> files (if there even are any these days).
Hi,
> > 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.
>
> Oh! Right, I remember that now; sorry about forgetting the status of that
> migration. Indeed, that means there's probably no need to say anything at
> all, unless we still need to mention it in passing in case someone has a
> need for the type of mailcap file that can't be represented by desktop
> files (if there even are any these days).
there may be some confusion as for media types, the Debian menu is not
involved. Currently, the Policy �9.7 details how to place files in mailcap
format in /usr/lib/mime/packages/. I would like to keep this as a possibility
until we are sure that we can rely solely on FreeDesktop menu entries.
I will test (later... but others are welcome to try and report) how far the
mime-support package can do the transition for the default mailcap entries that
it ships, and I will add a section in the next Developers News to suggest to
others to try the migration.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Josselin Mouette
May 13, 2013, 4:10:01 AM5/13/13
to
Le dimanche 12 mai 2013 à 16:06 -0700, Russ Allbery a écrit :
9.6 Menus
Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/
However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
* If the menu entry is not useful in the general case as a
standalone application, the desktop entry should include
the icon in the default “hicolor” icon theme
directories, or to use an existing icon from the default
theme.
* The maintainer should use the “debian-desktop” mailing
list too coordinate with maintainers of menu
which are part of installation tasks, the contents of
entries should follow the Debian menu policy, which 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/.
9.7 Multimedia handlers
MIME (Multipurpose Internet Mail 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/x-mp3).
Registration of MIME type handlers allows programs like mail
user agents, file managers and web browsers to invoke these
handlers to view, edit or display MIME types they don't support
directly.
Packages shipping applications able to view, edit or point to
files of a given MIME type, and/or open links with a given URI
specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
> Josselin Mouette <jo...@debian.org> writes:
> > How about simply “not useful as a standalone application”?
>
> That sounds great to me.
Here is a new proposed wording with all your suggestions.
> > How about simply “not useful as a standalone application”?
>
> That sounds great to me.
9.6 Menus
Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/
However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
standalone application, the desktop entry should include
the NoDisplay=true stanza, so that it can be configured
to be displayed only by those who need it.
to be displayed only by those who need it.
* 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. It is encouraged to ship
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
the icon in the default “hicolor” icon theme
directories, or to use an existing icon from the default
theme.
* The maintainer should use the “debian-desktop” mailing
list too coordinate with maintainers of menu
implementations, in order to avoid bad interactions with
other icons or wrong categories. Especially for packages
which are part of installation tasks, the contents of
the NotShowIn/OnlyShowIn stanzas should be validated by
the maintainers of the relevant environments.
the maintainers of the relevant environments.
Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file. Such menu
entries should follow the Debian menu policy, which 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/.
9.7 Multimedia handlers
MIME (Multipurpose Internet Mail 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/x-mp3).
Registration of MIME type handlers allows programs like mail
user agents, file managers and web browsers to invoke these
handlers to view, edit or display MIME types they don't support
directly.
Packages shipping applications able to view, edit or point to
scheme, should provide desktop files as described in §9.6, and
using the MimeType stanza. For URI schemes, the relevant MIME
types are x-scheme-handler/* (e.g. x-scheme-handler/https).
The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.
Until its addition to “shared-mime-info”, the package can ship a
MIME file in XML format as described in the Shared MIME-info
using the MimeType stanza. For URI schemes, the relevant MIME
types are x-scheme-handler/* (e.g. x-scheme-handler/https).
The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.
Until its addition to “shared-mime-info”, the package can ship a
specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Bill Allombert
May 13, 2013, 4:20:02 PM5/13/13
to
On Sun, May 12, 2013 at 10:22:18AM +0200, Josselin Mouette wrote:
> I don’t think the basic purpose is different. It’s just that so far, the
> Debian menu maintainers have put menu completeness before usability. We
> should use the opportunity of a policy change to take care of that.
It is unfair to blame the menu maintainers for the Debian menu subpolicy and
> I don’t think the basic purpose is different. It’s just that so far, the
> Debian menu maintainers have put menu completeness before usability. We
> should use the opportunity of a policy change to take care of that.
the menu section of policy.
Russ Allbery
May 13, 2013, 8:40:01 PM5/13/13
to
In general, seconded. Thank you for writing this up! The following are
mostly editing notes intended for whoever (possibly myself if I can find
time) might turn this into SGML.
Josselin Mouette <jo...@debian.org> writes:
> 9.6 Menus
> Packages shipping applications that belong in the menu of a
> desktop environment should provide desktop files for integrating
> with the menus, following the Desktop Menu Specification
> available at
> http://standards.freedesktop.org/desktop-entry-spec/latest/
>
> However, the maintainer should remind that the menu is often the
s/remind/remember/
> primary interface for the user, and as such it should be filled
> with what is most useful to her. Therefore :
I'm not sure if we have a consistent style on gendered pronouns. I
personally always use singular they, and I vaguely recall that reaching
some degree of consensus in a previous discussion.
> * If the menu entry is not useful in the general case as a
> standalone application, the desktop entry should include
> the NoDisplay=true stanza, so that it can be configured
> to be displayed only by those who need it.
> * 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. It is encouraged to ship
> the icon in the default “hicolor” icon theme
> directories, or to use an existing icon from the default
> theme.
s/default/"hicolor" right at the end of the sentence, just to be clear
that hicolor is the one to use, rather than sending people down the path
of trying to figure out how to have the icon change if the default ever
changes. (People who don't do this a lot, like myself, tend to get
trapped in unnecessary investigations like that. :))
> * The maintainer should use the “debian-desktop” mailing
> list too coordinate with maintainers of menu
s/too/to/
> implementations, in order to avoid bad interactions with
no comma, "in order to avoid problems with categories or bad interactions
with other icons."
> other icons or wrong categories. Especially for packages
> which are part of installation tasks, the contents of
> the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
> Packages can, to be compatible with Debian additions to some
> legacy window managers, also provide a menu file. Such menu
> entries should follow the Debian menu policy, which 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/.
> 9.7 Multimedia handlers
> MIME (Multipurpose Internet Mail 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/x-mp3).
>
> Registration of MIME type handlers allows programs like mail
> user agents, file managers and web browsers to invoke these
> handlers to view, edit or display MIME types they don't support
> directly.
>
> Packages shipping applications able to view, edit or point to
> files of a given MIME type, and/or open links with a given URI
> scheme, should provide desktop files as described in §9.6, and
> using the MimeType stanza. For URI schemes, the relevant MIME
s/, and using the/ that include a/. s/stanza/entry/ (following the
terminology of the desktop standard).
> types are x-scheme-handler/* (e.g. x-scheme-handler/https).
>
> The list of supported MIME types, as well as the corresponding
> file magic and filename extensions, is provided by the
> “shared-mime-info” package. If an application needs to support a
> new MIME type, the maintainer should request its addition to
> shared-mime-info first, to the Debian or upstream freedesktop
> maintainers.
>
> Until its addition to “shared-mime-info”, the package can ship a
> MIME file in XML format as described in the Shared MIME-info
> specification:
> http://standards.freedesktop.org/shared-mime-info-spec/latest/
I'll leave it to Charles to make the call on whether to keep the old
language about mailcap entries for right now.
mostly editing notes intended for whoever (possibly myself if I can find
time) might turn this into SGML.
Josselin Mouette <jo...@debian.org> writes:
> 9.6 Menus
> Packages shipping applications that belong in the menu of a
> desktop environment should provide desktop files for integrating
> with the menus, following the Desktop Menu Specification
> available at
> http://standards.freedesktop.org/desktop-entry-spec/latest/
>
> However, the maintainer should remind that the menu is often the
> primary interface for the user, and as such it should be filled
> with what is most useful to her. Therefore :
personally always use singular they, and I vaguely recall that reaching
some degree of consensus in a previous discussion.
> * If the menu entry is not useful in the general case as a
> standalone application, the desktop entry should include
> the NoDisplay=true stanza, so that it can be configured
> to be displayed only by those who need it.
> * 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. It is encouraged to ship
> the icon in the default “hicolor” icon theme
> directories, or to use an existing icon from the default
> theme.
that hicolor is the one to use, rather than sending people down the path
of trying to figure out how to have the icon change if the default ever
changes. (People who don't do this a lot, like myself, tend to get
trapped in unnecessary investigations like that. :))
> * The maintainer should use the “debian-desktop” mailing
> list too coordinate with maintainers of menu
> implementations, in order to avoid bad interactions with
with other icons."
> other icons or wrong categories. Especially for packages
> which are part of installation tasks, the contents of
> the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
> Packages can, to be compatible with Debian additions to some
> legacy window managers, also provide a menu file. Such menu
> entries should follow the Debian menu policy, which 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/.
> 9.7 Multimedia handlers
> MIME (Multipurpose Internet Mail 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/x-mp3).
>
> Registration of MIME type handlers allows programs like mail
> user agents, file managers and web browsers to invoke these
> handlers to view, edit or display MIME types they don't support
> directly.
>
> Packages shipping applications able to view, edit or point to
> files of a given MIME type, and/or open links with a given URI
> scheme, should provide desktop files as described in §9.6, and
> using the MimeType stanza. For URI schemes, the relevant MIME
terminology of the desktop standard).
> types are x-scheme-handler/* (e.g. x-scheme-handler/https).
>
> The list of supported MIME types, as well as the corresponding
> file magic and filename extensions, is provided by the
> “shared-mime-info” package. If an application needs to support a
> new MIME type, the maintainer should request its addition to
> shared-mime-info first, to the Debian or upstream freedesktop
> maintainers.
>
> Until its addition to “shared-mime-info”, the package can ship a
> MIME file in XML format as described in the Shared MIME-info
> specification:
> http://standards.freedesktop.org/shared-mime-info-spec/latest/
language about mailcap entries for right now.
Russ Allbery
May 14, 2013, 2:50:02 PM5/14/13
to
Wouter Verhelst <wou...@debian.org> writes:
> It refers to some (unspecified) window manager implementations as
> "legacy", which I think is a no-go (if they're supported in Debian, by
> definition they're not legacy).
I think it's fair to say that not supporting desktop files for the menu
infrastructure makes a window manager legacy at this point. I use one of
those window managers personally, but the fact remains that this is the
direction in which the whole desktop world has gone, and most new window
managers, even those that aren't really trying to provide a desktop
environment, support them to the degree that they do things related to
desktop files.
> Apart from that, I would like to see rough feature parity, i.e.,
> - support for applications which start from a terminal, using the
> x-terminal-emulator alternative), without hardcoding the terminal
> emulator (for pdmenu or similar things) (possibly desktop files
> already support this; if so, feel free to just point that out ;)
I'm fairly sure they do. This is the Terminal=true setting.
> - per-user desktop entries (~/.menu, and update-menus run as user) that
> are not specific to the used user interface. (same note as on the
> previous item)
Already supported, although where you have to put the desktop file varies
depending on the environment. There is slow convergence (I think) on the
XDG paths, but we're not there yet.
> - an easy way for window managers that don't use the desktop format
> directly to be told when there are new entries and they need to
> rebuild their menu. With the Debian menu system, we have
> update-menus which is called at postinst time (possibly by a
> trigger, I'm not sure); there should be something similar for
> desktop entries. This might simply be implemented by a dpkg trigger
> that all interested window managers listen to and that
> desktop-installing packages should emit; but we should document such a
> procedure before making this switch.
It would be ideal if we had something like this in place, but the reality
of the situation is that we're already making this switch, and no one is
stepping forward to do this work. At some point, I think it becomes the
obligation of the fvwm (etc.) maintainers to do this work if they want to
see it done, rather than asking the GNOME and KDE and Xfce maintainers to
write code for window managers they don't use and don't support in order
to move forward with their upstream direction.
So I don't see this as a valid prerequisite.
> Moreover, we should have clear policies on what the contents of a
> .desktop file should look like, that goes way beyond just a vage URL
> over at freedesktop.org. Specifically, we need:
The URL is really not that vague, speaking as someone who wrote the
Lintian validation code based on the specification.
> - a replacement for our current menu policy which explains which types
> of applications will go where. Consistency across user interfaces is a
> *good* thing, and to get that we'll need to make some decisions
> ourselves, sometimes overriding upstreams. That should obviously be
> the exception rather than the rule (i.e., we should construct
> something that would allow us to keep "most" upstream desktop files,
> for whatever definition of "most" makes sense). Consistency across
> choice is one of Debian's strengths; we should strive to keep that
> feature.
> - A decision/clarification on what will happen when a desktop file
> contains the "only show this in GNOME" feature (with which they
> *actually* mean "don't show this in KDE") and the user interface in
> use is neither of those two.
I don't think either of these are related to this bug. We already have
tons and tons of packages with desktop files, so to the extent that these
are issues, they're already issues. Trying to hold up further
encouragement of desktop files at this point in order to fix these
problems feels counter-productive to me.
There is an existing fdo standard for what categories to use in what
situations, and while it's not as detailed as one might like, it's
workable. It might be worthwhile linking to it directly, although I think
the desktop file spec already does.
I do agree that both of these are desireable, though, and would strongly
encourage the various parties involved in menu implementations to get
together and find consensus on these sorts of issues. The result of that
consensus would be appropriate for inclusion in Policy (probably as a
desktop file sub-policy).
> It refers to some (unspecified) window manager implementations as
> "legacy", which I think is a no-go (if they're supported in Debian, by
> definition they're not legacy).
I think it's fair to say that not supporting desktop files for the menu
infrastructure makes a window manager legacy at this point. I use one of
those window managers personally, but the fact remains that this is the
direction in which the whole desktop world has gone, and most new window
managers, even those that aren't really trying to provide a desktop
environment, support them to the degree that they do things related to
desktop files.
> Apart from that, I would like to see rough feature parity, i.e.,
> - support for applications which start from a terminal, using the
> x-terminal-emulator alternative), without hardcoding the terminal
> emulator (for pdmenu or similar things) (possibly desktop files
> already support this; if so, feel free to just point that out ;)
I'm fairly sure they do. This is the Terminal=true setting.
> - per-user desktop entries (~/.menu, and update-menus run as user) that
> are not specific to the used user interface. (same note as on the
> previous item)
Already supported, although where you have to put the desktop file varies
depending on the environment. There is slow convergence (I think) on the
XDG paths, but we're not there yet.
> - an easy way for window managers that don't use the desktop format
> directly to be told when there are new entries and they need to
> rebuild their menu. With the Debian menu system, we have
> update-menus which is called at postinst time (possibly by a
> trigger, I'm not sure); there should be something similar for
> desktop entries. This might simply be implemented by a dpkg trigger
> that all interested window managers listen to and that
> desktop-installing packages should emit; but we should document such a
> procedure before making this switch.
It would be ideal if we had something like this in place, but the reality
of the situation is that we're already making this switch, and no one is
stepping forward to do this work. At some point, I think it becomes the
obligation of the fvwm (etc.) maintainers to do this work if they want to
see it done, rather than asking the GNOME and KDE and Xfce maintainers to
write code for window managers they don't use and don't support in order
to move forward with their upstream direction.
So I don't see this as a valid prerequisite.
> Moreover, we should have clear policies on what the contents of a
> .desktop file should look like, that goes way beyond just a vage URL
> over at freedesktop.org. Specifically, we need:
The URL is really not that vague, speaking as someone who wrote the
Lintian validation code based on the specification.
> - a replacement for our current menu policy which explains which types
> of applications will go where. Consistency across user interfaces is a
> *good* thing, and to get that we'll need to make some decisions
> ourselves, sometimes overriding upstreams. That should obviously be
> the exception rather than the rule (i.e., we should construct
> something that would allow us to keep "most" upstream desktop files,
> for whatever definition of "most" makes sense). Consistency across
> choice is one of Debian's strengths; we should strive to keep that
> feature.
> - A decision/clarification on what will happen when a desktop file
> contains the "only show this in GNOME" feature (with which they
> *actually* mean "don't show this in KDE") and the user interface in
> use is neither of those two.
I don't think either of these are related to this bug. We already have
tons and tons of packages with desktop files, so to the extent that these
are issues, they're already issues. Trying to hold up further
encouragement of desktop files at this point in order to fix these
problems feels counter-productive to me.
There is an existing fdo standard for what categories to use in what
situations, and while it's not as detailed as one might like, it's
workable. It might be worthwhile linking to it directly, although I think
the desktop file spec already does.
I do agree that both of these are desireable, though, and would strongly
encourage the various parties involved in menu implementations to get
together and find consensus on these sorts of issues. The result of that
consensus would be appropriate for inclusion in Policy (probably as a
desktop file sub-policy).
Wouter Verhelst
May 14, 2013, 3:00:01 PM5/14/13
to
On 13-05-13 10:02, Josselin Mouette wrote:
> * The maintainer should use the “debian-desktop” mailing
> list too coordinate with maintainers of menu
> implementations, in order to avoid bad interactions with
> other icons or wrong categories. Especially for packages
> which are part of installation tasks, the contents of
> the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
I would prefer that we have an enumeration of possible categories, in
> * The maintainer should use the “debian-desktop” mailing
> list too coordinate with maintainers of menu
> implementations, in order to avoid bad interactions with
> other icons or wrong categories. Especially for packages
> which are part of installation tasks, the contents of
> the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
policy, with an explanation of which kind of applications should go
where. That enumeration can then still end with "in case of doubt,
contact the debian-desktop mailinglist."
> Packages can, to be compatible with Debian additions to some
> legacy window managers, also provide a menu file. Such menu
> entries should follow the Debian menu policy, which 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/.
that we change window managers to read desktop files instead of menu
files, and remove this suggestion altogether. Having two ways to specify
menu entries means you'll get two half menus rather than one whole,
which isn't a good idea.
[...]
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Russ Allbery
May 14, 2013, 4:00:02 PM5/14/13
to
Wouter Verhelst <wou...@debian.org> writes:
> On 13-05-13 10:02, Josselin Mouette wrote:
>> Packages can, to be compatible with Debian additions to some
>> legacy window managers, also provide a menu file. Such menu
>> entries should follow the Debian menu policy, which 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/.
> If we're going to suggest desktop files in policy, I would rather prefer
> that we change window managers to read desktop files instead of menu
> files, and remove this suggestion altogether. Having two ways to specify
> menu entries means you'll get two half menus rather than one whole,
> which isn't a good idea.
So would everyone else, but no one has done the work. I think enough
> On 13-05-13 10:02, Josselin Mouette wrote:
>> Packages can, to be compatible with Debian additions to some
>> legacy window managers, also provide a menu file. Such menu
>> entries should follow the Debian menu policy, which 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/.
> If we're going to suggest desktop files in policy, I would rather prefer
> that we change window managers to read desktop files instead of menu
> files, and remove this suggestion altogether. Having two ways to specify
> menu entries means you'll get two half menus rather than one whole,
> which isn't a good idea.
years have gone by that it doesn't make sense to keep waiting for someone
to volunteer to do this work for the less common window managers like
fvwm.
Bill Allombert
May 14, 2013, 5:40:02 PM5/14/13
to
On Sun, May 12, 2013 at 12:51:13PM +0200, Sune Vuorela wrote:
> On Sunday 12 May 2013 12:07:30 Bill Allombert wrote:
>
> > > And it is probably similar for many other window managers and desktop
> > > environments.
> >
> > How many window managers support the XDG menu specification ?
>
> Most[tm]
For Most[tm] = 15% I assume.
> On Sunday 12 May 2013 12:07:30 Bill Allombert wrote:
>
> > > And it is probably similar for many other window managers and desktop
> > > environments.
> >
> > How many window managers support the XDG menu specification ?
>
> Most[tm]
> It is *the* menu in Gnome, in KDE's workspaces, in XFCE, in LXDE, in razor-qt,
> in trinity, mate, cinnamon.
Which of them are compliant with the XDG menu specification ?
> For fluxbox, openbox, blackbox, fvwm, icewm, windowmaker, gnustep and probably
> others, there exists scripts that convert a XDG menu structure into their own
> formats, not unlike currently where scripts is used to convert the debian menu
> structure into their own formats.
By constrast, Debian menu supports at least 36 window managers.
I do not see any benefit to dismantle Debian menu at this stage.
Bill Allombert
May 14, 2013, 5:40:02 PM5/14/13
to
On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
> Wouter Verhelst <wou...@debian.org> writes:
> > On 13-05-13 10:02, Josselin Mouette wrote:
>
> >> Packages can, to be compatible with Debian additions to some
> >> legacy window managers, also provide a menu file. Such menu
> >> entries should follow the Debian menu policy, which 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/.
>
> > If we're going to suggest desktop files in policy, I would rather prefer
> > that we change window managers to read desktop files instead of menu
> > files, and remove this suggestion altogether. Having two ways to specify
> > menu entries means you'll get two half menus rather than one whole,
> > which isn't a good idea.
>
> So would everyone else, but no one has done the work. I think enough
> years have gone by that it doesn't make sense to keep waiting for someone
> to volunteer to do this work for the less common window managers like
> fvwm.
Because this is not possible. The XDG menu specification requires funky stuff like
> Wouter Verhelst <wou...@debian.org> writes:
> > On 13-05-13 10:02, Josselin Mouette wrote:
>
> >> Packages can, to be compatible with Debian additions to some
> >> legacy window managers, also provide a menu file. Such menu
> >> entries should follow the Debian menu policy, which 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/.
>
> > If we're going to suggest desktop files in policy, I would rather prefer
> > that we change window managers to read desktop files instead of menu
> > files, and remove this suggestion altogether. Having two ways to specify
> > menu entries means you'll get two half menus rather than one whole,
> > which isn't a good idea.
>
> So would everyone else, but no one has done the work. I think enough
> years have gone by that it doesn't make sense to keep waiting for someone
> to volunteer to do this work for the less common window managers like
> fvwm.
XSLT processing which are not compatible with the spirit of a lightweight window
manager.
Charles Plessy
May 14, 2013, 7:40:01 PM5/14/13
to
Le Mon, May 13, 2013 at 10:02:50AM +0200, Josselin Mouette a écrit :
> Le dimanche 12 mai 2013 à 16:06 -0700, Russ Allbery a écrit :
> > Josselin Mouette <jo...@debian.org> writes:
> > > How about simply “not useful as a standalone application”?
> >
> > That sounds great to me.
>
> Here is a new proposed wording with all your suggestions.
Thanks Josselin for your suggestions !
> Le dimanche 12 mai 2013 à 16:06 -0700, Russ Allbery a écrit :
> > Josselin Mouette <jo...@debian.org> writes:
> > > How about simply “not useful as a standalone application”?
> >
> > That sounds great to me.
>
> Here is a new proposed wording with all your suggestions.
I would like to integrate it while keeping the instructions about the
Debian menu and the mailcap entries. Here is my proposition.
9.6 : Packages should support at least one of the FreeDesktop and the Debian
menu system.
9.6.1: The FreeDesktop menu system. Mostly the suggestion from Sune and
Josselin. I would like to add a brief word or a footnote on forwarding the
entries upstream whenever possible. For the layout, I think that
the Desktop Menu Specification is clear enough, and the current practice
is to let each Desktop system implement it freely, rather than aiming
at a unified structure like with the Debian menu system.
9.6.2: The Debian menu system. I do not agree with the use of "legacy", because
it does not give guidance on what to do (support or not), and because
in the current context, it has a negative connotation. I would like
to keep most of the current text, and clarify with Bill about triggers
(#707888), as for the moment I do not understand what the problem is.
9.7 : Packages should use destop files unless their entry can only be expressed
in the mailcap format. This proposition is not the current practice.
I intend to give the example (and possibly find corner cases) with the
mime-support package. I propose to patch the policy in Git with a "should",
and review before publishing how packages are evolving in that direction
(a Lintian warning would probably help, if we can detect which mailcap
entries can certainly be translated to FreeDesktop entries).
9.7.1: The FreeDesktop menu system: Josselin's text. I would like to add
a recommendation to declare media types to the IANA, which is upstream
of shared-mime-info. I would also prefer to give an example where
the media type does not start witn "x-".
9.7.2: The mailcap entries, for when something can not be expressed in a
Desktop entry.
For media types, there is at least one more provider: the 'file' package. I
wonder if there is something to mention there, or if it is more relevant for
other guides.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Russ Allbery
May 14, 2013, 7:50:01 PM5/14/13
to
Charles Plessy <ple...@debian.org> writes:
> I would like to integrate it while keeping the instructions about the
> Debian menu and the mailcap entries. Here is my proposition.
> 9.6 : Packages should support at least one of the FreeDesktop and the Debian
> menu system.
I'm not sure "at least one" does anything useful for us.
> I would like to integrate it while keeping the instructions about the
> Debian menu and the mailcap entries. Here is my proposition.
> 9.6 : Packages should support at least one of the FreeDesktop and the Debian
> menu system.
The situation we're currently in is that if a package does not ship a
desktop file, it won't appear in the menus of most of the desktop
environments, since they generally hide the Debian menu. If a package
does not ship a menu file, it won't appear in the menus for window
managers like fvwm.
Right now, I think the best advice we can give to a packager is to support
both. However, increasingly, our users are using systems where only the
desktop file menu items will appear, so I think the desktop file will
become more and more important over time.
> 9.6.1: The FreeDesktop menu system. Mostly the suggestion from Sune and
> Josselin. I would like to add a brief word or a footnote on forwarding
> the entries upstream whenever possible. For the layout, I think that
> the Desktop Menu Specification is clear enough, and the current practice
> is to let each Desktop system implement it freely, rather than aiming at
> a unified structure like with the Debian menu system.
spec, though, so that people know what categories to use.
> 9.6.2: The Debian menu system. I do not agree with the use of "legacy",
> because it does not give guidance on what to do (support or not), and
> because in the current context, it has a negative connotation. I would
> like to keep most of the current text, and clarify with Bill about
> triggers (#707888), as for the moment I do not understand what the
> problem is.
agree that it doesn't provide much useful guidance, and I don't really
care. Since others do object to it, it's probably better to avoid the
term.
> 9.7 : Packages should use destop files unless their entry can only be
> expressed in the mailcap format. This proposition is not the current
> practice. I intend to give the example (and possibly find corner cases)
> with the mime-support package. I propose to patch the policy in Git
> with a "should", and review before publishing how packages are evolving
> in that direction (a Lintian warning would probably help, if we can
> detect which mailcap entries can certainly be translated to FreeDesktop
> entries).
> 9.7.1: The FreeDesktop menu system: Josselin's text. I would like to
> add a recommendation to declare media types to the IANA, which is
> upstream of shared-mime-info. I would also prefer to give an example
> where the media type does not start witn "x-".
> 9.7.2: The mailcap entries, for when something can not be expressed in a
> Desktop entry.
> For media types, there is at least one more provider: the 'file'
> package. I wonder if there is something to mention there, or if it is
> more relevant for other guides.
to the file package? I was assuming that file upstream would take care of
adding new entries.
Raphael Hertzog
May 15, 2013, 2:40:02 AM5/15/13
to
(Your last mail was not sent to the BTS but to the ML directly)
On Tue, 14 May 2013, Wouter Verhelst wrote:
> I didn't mean to imply someone other than the relevant UI maintainers
> would need to write code for this to happen; we could simply add some
> wording along the lines of
>
> packages that install desktop files must emit the
> ``desktop-files-installed'' trigger from their postinst (e.g., by
> running ``dpkg-trigger desktop-files-installed''), so that user
> interfaces which don't support desktop files directly can listen to
> this trigger and update their menus.
A file trigger on /usr/share/applications does exactly that. There's no
need to formalize anything more IMO.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
On Tue, 14 May 2013, Wouter Verhelst wrote:
> I didn't mean to imply someone other than the relevant UI maintainers
> would need to write code for this to happen; we could simply add some
> wording along the lines of
>
> packages that install desktop files must emit the
> ``desktop-files-installed'' trigger from their postinst (e.g., by
> running ``dpkg-trigger desktop-files-installed''), so that user
> interfaces which don't support desktop files directly can listen to
> this trigger and update their menus.
A file trigger on /usr/share/applications does exactly that. There's no
need to formalize anything more IMO.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Wouter Verhelst
May 15, 2013, 6:10:02 AM5/15/13
to
On 14-05-13 23:31, Bill Allombert wrote:
> On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
>> Wouter Verhelst <wou...@debian.org> writes:
>>> On 13-05-13 10:02, Josselin Mouette wrote:
>>
>>>> Packages can, to be compatible with Debian additions to some
>>>> legacy window managers, also provide a menu file. Such menu
>>>> entries should follow the Debian menu policy, which 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/.
>>
>>> If we're going to suggest desktop files in policy, I would rather prefer
>>> that we change window managers to read desktop files instead of menu
>>> files, and remove this suggestion altogether. Having two ways to specify
>>> menu entries means you'll get two half menus rather than one whole,
>>> which isn't a good idea.
>>
>> So would everyone else, but no one has done the work. I think enough
>> years have gone by that it doesn't make sense to keep waiting for someone
>> to volunteer to do this work for the less common window managers like
>> fvwm.
>
> Because this is not possible. The XDG menu specification requires funky stuff like
> XSLT processing which are not compatible with the spirit of a lightweight window
> manager.
Do you have any reference to that?
> On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
>> Wouter Verhelst <wou...@debian.org> writes:
>>> On 13-05-13 10:02, Josselin Mouette wrote:
>>
>>>> Packages can, to be compatible with Debian additions to some
>>>> legacy window managers, also provide a menu file. Such menu
>>>> entries should follow the Debian menu policy, which 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/.
>>
>>> If we're going to suggest desktop files in policy, I would rather prefer
>>> that we change window managers to read desktop files instead of menu
>>> files, and remove this suggestion altogether. Having two ways to specify
>>> menu entries means you'll get two half menus rather than one whole,
>>> which isn't a good idea.
>>
>> So would everyone else, but no one has done the work. I think enough
>> years have gone by that it doesn't make sense to keep waiting for someone
>> to volunteer to do this work for the less common window managers like
>> fvwm.
>
> Because this is not possible. The XDG menu specification requires funky stuff like
> XSLT processing which are not compatible with the spirit of a lightweight window
> manager.
Also, I don't think the requirement should be anything like "you must
implement the desktop format to the letter"; more like "you should
distill a usable menu from things in /usr/share/applications". Sometimes
this may mean losing information, but that's probably fine.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Wouter Verhelst
May 15, 2013, 6:10:03 AM5/15/13
to
On 15-05-13 08:23, Raphael Hertzog wrote:
> (Your last mail was not sent to the BTS but to the ML directly)
>
> On Tue, 14 May 2013, Wouter Verhelst wrote:
>> I didn't mean to imply someone other than the relevant UI maintainers
>> would need to write code for this to happen; we could simply add some
>> wording along the lines of
>>
>> packages that install desktop files must emit the
>> ``desktop-files-installed'' trigger from their postinst (e.g., by
>> running ``dpkg-trigger desktop-files-installed''), so that user
>> interfaces which don't support desktop files directly can listen to
>> this trigger and update their menus.
>
> A file trigger on /usr/share/applications does exactly that. There's no
> need to formalize anything more IMO.
Ah, yes, hadn't thought of that.
> (Your last mail was not sent to the BTS but to the ML directly)
>
> On Tue, 14 May 2013, Wouter Verhelst wrote:
>> I didn't mean to imply someone other than the relevant UI maintainers
>> would need to write code for this to happen; we could simply add some
>> wording along the lines of
>>
>> packages that install desktop files must emit the
>> ``desktop-files-installed'' trigger from their postinst (e.g., by
>> running ``dpkg-trigger desktop-files-installed''), so that user
>> interfaces which don't support desktop files directly can listen to
>> this trigger and update their menus.
>
> A file trigger on /usr/share/applications does exactly that. There's no
> need to formalize anything more IMO.
How about this then:
Packages providing a menu system should preferably support the desktop
format (see section <xref>). When such support is absent, as an
alternative the package should preferably register a file trigger on
/usr/share/applications and use the desktop files there as a basis to
be converted to their native menu format.
Should, so as to not make such packages insta-buggy, but still strong
enough that it is clearly something these packages should look into. I
think we should encourage shared menu systems; whether they are menu
files are desktop files does not matter as much.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Bill Allombert
May 15, 2013, 7:00:01 AM5/15/13
to
On Wed, May 15, 2013 at 12:05:11PM +0200, Wouter Verhelst wrote:
> On 14-05-13 23:31, Bill Allombert wrote:
> > On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
> >> Wouter Verhelst <wou...@debian.org> writes:
> >>> On 13-05-13 10:02, Josselin Mouette wrote:
> >>
> >>>> Packages can, to be compatible with Debian additions to some
> >>>> legacy window managers, also provide a menu file. Such menu
> >>>> entries should follow the Debian menu policy, which 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/.
> >>
> >>> If we're going to suggest desktop files in policy, I would rather prefer
> >>> that we change window managers to read desktop files instead of menu
> >>> files, and remove this suggestion altogether. Having two ways to specify
> >>> menu entries means you'll get two half menus rather than one whole,
> >>> which isn't a good idea.
> >>
> >> So would everyone else, but no one has done the work. I think enough
> >> years have gone by that it doesn't make sense to keep waiting for someone
> >> to volunteer to do this work for the less common window managers like
> >> fvwm.
> >
> > Because this is not possible. The XDG menu specification requires funky stuff like
> > XSLT processing which are not compatible with the spirit of a lightweight window
> > manager.
>
> Do you have any reference to that?
<http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#menu-file-format>
> On 14-05-13 23:31, Bill Allombert wrote:
> > On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
> >> Wouter Verhelst <wou...@debian.org> writes:
> >>> On 13-05-13 10:02, Josselin Mouette wrote:
> >>
> >>>> Packages can, to be compatible with Debian additions to some
> >>>> legacy window managers, also provide a menu file. Such menu
> >>>> entries should follow the Debian menu policy, which 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/.
> >>
> >>> If we're going to suggest desktop files in policy, I would rather prefer
> >>> that we change window managers to read desktop files instead of menu
> >>> files, and remove this suggestion altogether. Having two ways to specify
> >>> menu entries means you'll get two half menus rather than one whole,
> >>> which isn't a good idea.
> >>
> >> So would everyone else, but no one has done the work. I think enough
> >> years have gone by that it doesn't make sense to keep waiting for someone
> >> to volunteer to do this work for the less common window managers like
> >> fvwm.
> >
> > Because this is not possible. The XDG menu specification requires funky stuff like
> > XSLT processing which are not compatible with the spirit of a lightweight window
> > manager.
>
> Do you have any reference to that?
<http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#merge-algorithm>
<http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#query-algorithm>
The menu layout files are XML. While the standard does not mandate the use of
XSLT, it requires manipulation of XML files which are equivalent to XSLT
processing.
> implement the desktop format to the letter"; more like "you should
> distill a usable menu from things in /usr/share/applications". Sometimes
> this may mean losing information, but that's probably fine.
menu bring. This would also be an admittance that the XDG menu specification is
overblown.
I see that none of the issues with the specification have been fixed in the
last ten years, and that GNOME have been drifting away without any update to
the specification.
0 new messages