Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#707851: Please do not remove menu before .desktop is fixed (if it ever will be)
1 view
Skip to first unread message
Bernhard R. Link
May 12, 2013, 6:40:02 AM5/12/13
to
Some points for a having menu files:
- it is supposed to include all programs, and does
not do choices like "you don't want that program"
- it is properly documented (like how do I as administrator
override and change a menu setting globally).
- it is properly documented for maintainers
- there is still no policy for .desktop entries (a standard
describing the format is no policy)
- it can express features modern DEs lack (like switching
between different environment without closing programs).
As I think it is unlikely that there will be a policy to fit all of this
together (especially the "what to show in which program"), I'd suggest
to just have menu and .desktop entries in Debian packages that way:
- we can keep the Debian menu with all programs in it
- the newfangled DEs can have .desktop as their playfield where
usefull but to ancient looking programs are not exposed to their
users by not having a .desktop entry, Gnome programs can have their
OnlyShowIn=Gnome so no other newfangled DEs sees them but with
a menu entry users of classical window managers could still start
them and so on.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
- it is supposed to include all programs, and does
not do choices like "you don't want that program"
- it is properly documented (like how do I as administrator
override and change a menu setting globally).
- it is properly documented for maintainers
- there is still no policy for .desktop entries (a standard
describing the format is no policy)
- it can express features modern DEs lack (like switching
between different environment without closing programs).
As I think it is unlikely that there will be a policy to fit all of this
together (especially the "what to show in which program"), I'd suggest
to just have menu and .desktop entries in Debian packages that way:
- we can keep the Debian menu with all programs in it
- the newfangled DEs can have .desktop as their playfield where
usefull but to ancient looking programs are not exposed to their
users by not having a .desktop entry, Gnome programs can have their
OnlyShowIn=Gnome so no other newfangled DEs sees them but with
a menu entry users of classical window managers could still start
them and so on.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
May 12, 2013, 7:00:02 AM5/12/13
to
Le dimanche 12 mai 2013 à 12:36 +0200, Bernhard R. Link a écrit :
> Some points for a having menu files:
>
> - it is supposed to include all programs, and does
> not do choices like "you don't want that program"
In my opinion, this is an anti-feature. A menu is not some random place
> Some points for a having menu files:
>
> - it is supposed to include all programs, and does
> not do choices like "you don't want that program"
to shove all your programs. It is a key part of the user interface, and
needs to be thought as such.
> - it is properly documented (like how do I as administrator
> override and change a menu setting globally).
> - it is properly documented for maintainers
> - there is still no policy for .desktop entries (a standard
> describing the format is no policy)
previous proposal.
> - it can express features modern DEs lack (like switching
> between different environment without closing programs).
the use case? Selection should be done once from the login manager, in
the real world no one needs to dynamically switch WMs.
All in all I don’t see why we couldn’t just drop menu altogether or
replace it by a XDG menu implementation. In all cases, it doesn’t have a
place in the policy anymore.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Charles Plessy
May 12, 2013, 7:20:02 AM5/12/13
to
Le Sun, May 12, 2013 at 12:36:27PM +0200, Bernhard R. Link a �crit :
I think that the point is that the current Policy, that packages should have
Debian menu entries, is neglected enough that it questions whether the Policy
can stay a "should" without at the same time failing at documenting current
practice. So two things can change:
- The Policy can switch from "should" to "may", or
- menu files can be added to pakcages so that their prevalence match the Policy.
On the PTS, there is an interface to suggest watch files to the package
maintainers. If you would do something similar for menu entries, maybe the
coverage would increase.
But this does not solve the problem that maintainers (me included) are not willing
to maintain an entry for two systems in parallel. Another solution would be to
convert FreeDesktop entries to menu entries, either at build or at install time.
Currently, my proposition would be that packages should have a menu entry for
at least one of the FreeDesktop or Debian menu systems. This would relax the
Policy on Debian menu entries as proposed by Sune, while keeping the Debian
menu system section in the Policy.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
>
> As I think it is unlikely that there will be a policy to fit all of this
> together (especially the "what to show in which program"), I'd suggest
> to just have menu and .desktop entries in Debian packages that way:
Hi Bernhard,
> As I think it is unlikely that there will be a policy to fit all of this
> together (especially the "what to show in which program"), I'd suggest
> to just have menu and .desktop entries in Debian packages that way:
I think that the point is that the current Policy, that packages should have
Debian menu entries, is neglected enough that it questions whether the Policy
can stay a "should" without at the same time failing at documenting current
practice. So two things can change:
- The Policy can switch from "should" to "may", or
- menu files can be added to pakcages so that their prevalence match the Policy.
On the PTS, there is an interface to suggest watch files to the package
maintainers. If you would do something similar for menu entries, maybe the
coverage would increase.
But this does not solve the problem that maintainers (me included) are not willing
to maintain an entry for two systems in parallel. Another solution would be to
convert FreeDesktop entries to menu entries, either at build or at install time.
Currently, my proposition would be that packages should have a menu entry for
at least one of the FreeDesktop or Debian menu systems. This would relax the
Policy on Debian menu entries as proposed by Sune, while keeping the Debian
menu system section in the Policy.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Bill Allombert
May 12, 2013, 8:00:02 AM5/12/13
to
On Sun, May 12, 2013 at 08:14:22PM +0900, Charles Plessy wrote:
> Le Sun, May 12, 2013 at 12:36:27PM +0200, Bernhard R. Link a �crit :
> >
> > As I think it is unlikely that there will be a policy to fit all of this
> > together (especially the "what to show in which program"), I'd suggest
> > to just have menu and .desktop entries in Debian packages that way:
>
> Hi Bernhard,
>
> I think that the point is that the current Policy, that packages should have
> Debian menu entries, is neglected enough that it questions whether the Policy
> can stay a "should" without at the same time failing at documenting current
> practice. So two things can change:
>
> - The Policy can switch from "should" to "may", or
> - menu files can be added to pakcages so that their prevalence match the Policy.
For the record, this policy is not neglected. I regularly do mass bug reporting for packages
> Le Sun, May 12, 2013 at 12:36:27PM +0200, Bernhard R. Link a �crit :
> >
> > As I think it is unlikely that there will be a policy to fit all of this
> > together (especially the "what to show in which program"), I'd suggest
> > to just have menu and .desktop entries in Debian packages that way:
>
> Hi Bernhard,
>
> I think that the point is that the current Policy, that packages should have
> Debian menu entries, is neglected enough that it questions whether the Policy
> can stay a "should" without at the same time failing at documenting current
> practice. So two things can change:
>
> - The Policy can switch from "should" to "may", or
> - menu files can be added to pakcages so that their prevalence match the Policy.
with broken/missing menu files. I even maintain a git repository of all menu files for that
purpose.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Bernhard R. Link
May 12, 2013, 9:10:02 AM5/12/13
to
* Josselin Mouette <jo...@debian.org> [130512 12:55]:
both features. Both have their pros and cons. If one of them has to be
named "anti-feature" then I'd nominate anything that hides stuff from me
or makes the menu different with the different Environments.
I really love how with the Debian menu the menu simply looks the same
with every environment. I can just point people where to find a program.
Everything is in there and everything looks the same everywhere. That's
really nice if you admin some university computer lab where people use
two dozen different environments.
> > - it can express features modern DEs lack (like switching
> > between different environment without closing programs).
>
> This is the perfect example of an anti-feature. Who needs that? What is
> the use case?
I think you use a different definition of "anti-feature" than everyone
else. "Anti-feature" does not mean "I do no like it".
> Selection should be done once from the login manager, in
> the real world no one needs to dynamically switch WMs.
I do so regulary. Different systems have their ups and downs and
switching them on the fly if some program has problems with one of
them really makes you get the best of all worlds.
> All in all I don’t see why we couldn’t just drop menu altogether or
> replace it by a XDG menu implementation. In all cases, it doesn’t have a
> place in the policy anymore.
I'm not opposed to dropping menu and using XDG menu implementation. But
then we should have a policy that XDG menus only do ShowOnlyIn= if there
is a technical reason something does not work and not only because the
maintainer thought "not interesting for others". Then everything that
can be started via a menu should have a menu entry.
As I doubt we can get that easily, it might be just best if everything
has their debian menu entry so .desktop does not need to be pestered
with all the "anti-features" you do not like.
Bernhard R. Link
> Le dimanche 12 mai 2013 à 12:36 +0200, Bernhard R. Link a écrit :
> > Some points for a having menu files:
> >
> > - it is supposed to include all programs, and does
> > not do choices like "you don't want that program"
>
> In my opinion, this is an anti-feature. A menu is not some random place
> to shove all your programs. It is a key part of the user interface, and
> needs to be thought as such.
Both "show everything" and "show only what we think you would want" are
> > Some points for a having menu files:
> >
> > - it is supposed to include all programs, and does
> > not do choices like "you don't want that program"
>
> In my opinion, this is an anti-feature. A menu is not some random place
> to shove all your programs. It is a key part of the user interface, and
> needs to be thought as such.
both features. Both have their pros and cons. If one of them has to be
named "anti-feature" then I'd nominate anything that hides stuff from me
or makes the menu different with the different Environments.
I really love how with the Debian menu the menu simply looks the same
with every environment. I can just point people where to find a program.
Everything is in there and everything looks the same everywhere. That's
really nice if you admin some university computer lab where people use
two dozen different environments.
> > - it can express features modern DEs lack (like switching
> > between different environment without closing programs).
>
> This is the perfect example of an anti-feature. Who needs that? What is
> the use case?
else. "Anti-feature" does not mean "I do no like it".
> Selection should be done once from the login manager, in
> the real world no one needs to dynamically switch WMs.
switching them on the fly if some program has problems with one of
them really makes you get the best of all worlds.
> All in all I don’t see why we couldn’t just drop menu altogether or
> replace it by a XDG menu implementation. In all cases, it doesn’t have a
> place in the policy anymore.
then we should have a policy that XDG menus only do ShowOnlyIn= if there
is a technical reason something does not work and not only because the
maintainer thought "not interesting for others". Then everything that
can be started via a menu should have a menu entry.
As I doubt we can get that easily, it might be just best if everything
has their debian menu entry so .desktop does not need to be pestered
with all the "anti-features" you do not like.
Bernhard R. Link
0 new messages