On Mon, 22 Dec 2014 14:29:44 + Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
The traditional Debian menu system (mostly done by Bill Alombert) has
been providing menu entries for bc and dc and everything for years.
That is what its users expect. It is what users like Matthew Vernon
Keith Packard writes (Bug#741573: Two menu systems):
Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:
All packages that provide applications that need not be passed any
special
Dear TC,
I would like to react to Ian's message, that uses words like deliberate
dismantling that can be interpreted as if the misbehaviour is on my side, and
will add a remark on the fact that Policy maintainers have no veto in
contrary to what seemed implied in November's TC meeting on IRC.
Le Mon, Jun 30, 2014 at 10:25:41PM -0700, Keith Packard a écrit :
I think this does demonstrate that we could, with little effort, allow
applications to ship only .desktop files and have the menu package take
those and generate menu files for other systems.
Hi Keith,
your approach is
Keith Packard kei...@keithp.com writes:
Thanks for pointing that out. desktop2menu is a perl script which uses
the published perl bindings for .desktop files and has a start at a
mapping from .desktop Categories to menu sections. It also doesn't
correctly handle generating .xpm files for the
On Monday 30 June 2014 23:23:53 Russ Allbery wrote:
Isn't this the tool that Sune wrote and mentioned earlier in this bug as
being incomplete and primarily useful for generating a template that
requires subsequent work?
Correct.
The primary issue is that there isn't a 1:1 mapping between all
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ian Jackson writes (Re: Bug#741573: Two menu systems):
But I'd like to make some specific comments too. (I'm reading
24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
copy.)
...
Oh, and:
Fourthly: It makes no provision
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I see Keith has committed a draft to git. As discussed, I disagree
with this approach. This amounts to nonconsensually abolishing
someone's work when it is still being maintained, and the global cost
is minimal.
Right, as I said in the
Colin Watson cjwat...@debian.org writes:
* There's no reason that has a .desktop file should imply shows up
in modern desktop environments, and so I think that the question of
coverage is to some extent a red herring; the systems have different
coverage because they've always had
Hi,
Le lundi 30 juin 2014 à 13:59 -0700, Keith Packard a écrit :
One of the arguments that I had heard expressed against supporting
applications shipping .desktop files is that it would reduce the number
of applications offered in existing menu packages; I'm hoping that my
draft addresses
Russ Allbery r...@debian.org writes:
The counterpoint here, which I had missed earlier in this discussion, is
the file format for the menus themselves, not the *.desktop files. I
agree with you about the *.desktop file format, but the specification for
the menus is much more complicated.
Josselin Mouette j...@debian.org writes:
One of the problems I have with your proposal, compared to Charles’
original patch, is that it encourages maintainers of hundreds of (IMHO
useless) menu files to port them to the desktop format.
Yeah, there are a lot of inappropriate entries in my
Keith Packard kei...@keithp.com writes:
1. Implement .desktop parsing support in the existing 'menu' package so
that packages providing only .desktop files would be incorporated
into menu programs without further change.
FWIW, it seems there is at least partial support for that
Nikolaus Rath nikol...@rath.org writes:
Keith Packard kei...@keithp.com writes:
1. Implement .desktop parsing support in the existing 'menu' package so
that packages providing only .desktop files would be incorporated
into menu programs without further change.
FWIW, it seems there
Le Fri, Jun 27, 2014 at 04:59:50AM -0700, Cameron Norman a écrit :
I believe the major aspect of .desktop files that makes them harder is the
icon handling. Perhaps debian policy should instruct that a certain icon
size must always be available in a particular format (e.g. 32x32 png) so
that
On Thursday, June 26, 2014, Colin Watson cjwat...@debian.org wrote:
On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote:
I see Keith has committed a draft to git. As discussed, I disagree
with this approach. This amounts to nonconsensually abolishing
someone's work when it is
I see Keith has committed a draft to git. As discussed, I disagree
with this approach. This amounts to nonconsensually abolishing
someone's work when it is still being maintained, and the global cost
is minimal.
But I'd like to make some specific comments too. (I'm reading
On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote:
I see Keith has committed a draft to git. As discussed, I disagree
with this approach. This amounts to nonconsensually abolishing
someone's work when it is still being maintained, and the global cost
is minimal.
My feelings on
(Sorry I missed the meeting today. I'm away on vacation and my schedule
ended up not aligning properly.)
Colin Watson cjwat...@debian.org writes:
I think this is really overstated. .desktop files are in a
long-standing and popular basic file format for which plenty of parsing
libraries in
I looked through this thread and found that I hadn't proposed anything
resembling a concrete resolution. I would like to do that now:
Context
1. A dispute about the status of menu systems in Debian, and the
contents of policy, has been referred to the Committee.
2. There are
Anthony Towns a...@erisian.com.au writes:
I'd divide them up into:
- someone spends their time fixing the issue
- bad things happen to the unfixed package
- how likely someone is to notice
Obviously the most important/useful part of those is categories is
getting someone to fix the
Hi again,
Russ Allbery wrote:
So, I think the questions before the TC are:
1. Should programs that make sense in the context of a typical DE (I
realize there's some fuzziness around this) all have desktop files?
Ah, I completely misread this before as saying menu files instead of
desktop
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
So, I think the questions before the TC are:
1. Should programs that make sense in the context of a typical DE (I
realize there's some fuzziness around this) all have desktop files?
Ah, I completely misread this before as
On 12 April 2014 05:32, Russ Allbery r...@debian.org wrote:
So, to take a step back, I think Ian is arguing that, by declaring the
traditional menu system a should, he's not introducing a problem into
Policy that doesn't already exist, because our current use of should is
all over the map.
I
Hi,
Russ Allbery wrote:
Things that I don't think are TC issues:
* Whether desktop files should be documented in Policy at all.
For what it's worth:
* I was unhappy with the patch at http://bugs.debian.org/707851 and
said so. I didn't object when people seconded it and applied it
Russ Allbery writes (Bug#741573: Two menu systems):
So, I think the questions before the TC are:
1. Should programs that make sense in the context of a typical DE (I
realize there's some fuzziness around this) all have desktop files? If
so, what level of Policy requirement should
Steve Langasek writes (Bug#741573: Two menu systems):
...
- What *I* want is for the TC to take a principled stand on the point that
the policy manual exists to describe distribution-wide integration
policies, instead of taking a there's more than one way to do it easy
way out
Stuart Prescott writes (Bug#741573: Two menu systems):
Ian Jackson wrote:
I think you are perfectly entitled to let the people who care about
the Debian menu take care of that testing.
As others have pointed out, that's a level a lot lower in everyone's
current understanding of what
Steve == Steve Langasek vor...@debian.org writes:
Steve On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote:
Thanks for bringing this issue back to the question that was
brought to the TC.
The discussion so far on this bug has focused on discussing what
the right
Sam Hartman writes (Bug#741573: Two menu systems):
If, as Russ claimed, a consensus was reached in a properly conducted
policy process, then I strongly disagree with the approach the TC is
taking. I think it creates significant harm for the project as a whole
when the TC does not generally
On Fri, 11 Apr 2014 21:04:12 Ian Jackson wrote:
Stuart Prescott writes (Bug#741573: Two menu systems):
Ian Jackson wrote:
I think you are perfectly entitled to let the people who care about
the Debian menu take care of that testing.
As others have pointed out, that's a level a lot
Ian == Ian Jackson ijack...@chiark.greenend.org.uk writes:
So, if you've reviewed this enough to support Bill's claim that
there isn't a consensus because there are substantial objections
raised in the discussions and not addressed, then please say
that. If you have not
On Friday 11 April 2014 15:23:06 Ian Jackson wrote:
[snip]
The upshot is that we don't currently insist that maintainers provide
manpages. I have never been criticised by anyone for uploading or
sponsoring anything with missing manpages. I don't think anyone else
should be criticised for
Lisandro Damián Nicanor Pérez Meyer writes (Bug#741573: Two menu systems):
Then we have a double standard here. For some cases we (as in the
project) consider should as Stuart and I described it before, but
we do *also* consider it a may for some cases, as Ian has just
pointed it out.
Can you
On Friday 11 April 2014 16:10:01 you wrote:
Lisandro Damián Nicanor Pérez Meyer writes (Bug#741573: Two menu systems):
Then we have a double standard here. For some cases we (as in the
project) consider should as Stuart and I described it before, but
we do *also* consider it a may for some
Lisandro Damián Nicanor Pérez Meyer writes (Bug#741573: Two menu systems):
On Friday 11 April 2014 16:10:01 you wrote:
Can you come up with any examples where should is used in a way that
_does not_ permit a maintainer to disregard it if it appears to be a
more work than they care to put
On Friday 11 April 2014 18:25:01 you wrote:
Lisandro Damián Nicanor Pérez Meyer writes (Bug#741573: Two menu systems):
On Friday 11 April 2014 16:10:01 you wrote:
Can you come up with any examples where should is used in a way that
_does not_ permit a maintainer to disregard
So, to take a step back, I think Ian is arguing that, by declaring the
traditional menu system a should, he's not introducing a problem into
Policy that doesn't already exist, because our current use of should is
all over the map.
I agree with that statement as far as it goes, but I don't think
Charles Plessy writes (Bug#741573: Two menu systems):
The underlying question is: who should spend the time writing these files and
keeping them up to date ?
The answer is, whoever wants to. In the first instance the maintainer
may choose to do so; if they don't, then it falls to those
Josselin Mouette writes (Bug#741573: Two menu systems):
Le mercredi 09 avril 2014 à 15:04 +0100, Ian Jackson a écrit :
Matthias Klumpp writes (Bug#741573: Two menu systems):
Also think about HIDPI-screens in particular, where these small icons
don't make sense at all (in fact
Hi,
On 04/10/2014 13:48, Ian Jackson wrote:
That comes directly from its goal
of being easily consumable by a very wide range of window managers.
The number of consumers (window manager, menu applets, desktop
environments) is much smaller than the number of providers (in theory
every
Ansgar Burchardt writes (Bug#741573: Two menu systems):
[1] This might include maintainers having to convert icons at package
build time and so on.
I think this is something quite trivial that can be centralised and
automated (dh_...). Moving work from install time on the user's
computer
Ian Jackson ijack...@chiark.greenend.org.uk writes:
If you don't like the trad menu, you don't have to use it. Nor do you
have to do any significant amount of work to support it. All that is
being asked is that you take other people's patches to support it.
That's not should in the Policy
Charles Plessy ple...@debian.org writes:
The underlying question is: who should spend the time writing these
files and keeping them up to date ?
In the case of missing manual pages, the policy (§ 12.1) does not
require the package maintainer to write one.
Hm. I have never read that section
Russ Allbery writes (Bug#741573: Two menu systems):
Charles Plessy ple...@debian.org writes:
The underlying question is: who should spend the time writing these
files and keeping them up to date ?
...
In the case of missing manual pages, the policy (§ 12.1) does not
require the package
Russ Allbery writes (Bug#741573: Two menu systems):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ansgar Burchardt writes (Bug#741573: Two menu systems):
[1] This might include maintainers having to convert icons at package
build time and so on.
I think this is something quite
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I think you've misunderstood me. I felt Ansgar and I were discussing in
the abstract what would be the most optimal situation. Certainly I'm
not saying that policy should mandate the use of anything that doesn't
currently exist.
I think
Russ Allbery writes (Bug#741573: Two menu systems):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
IMO if those patches aren't unreasonable then maintainers should accept
them, even if they're slightly less automatic than would be ideal.
Sure. I don't think anyone anywhere
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I did find three which are arguably recalcitrant maintainers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
Sune Vuorela writes (Re: Bug#741573: Two menu systems):
if it takes 5 minutes to write a menu file and 5 minutes to switch to one of
those 'old style' window managers and test that it shows up as it should, it
is 3000 minutes. Or 1 hour per week in a year.
I don't think you need to test
On Thursday 10 April 2014 14:06:11 Ian Jackson wrote:
Has anyone described any actual difficulties with supporting the
traditional menu ?
I am in the uploaders field of packages that probably requires 300 menu files
to
be available and of one consumer of menus.
if it takes 5 minutes to write
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes (Bug#741573: Two menu systems):
I do think that should in Policy is stronger than that, and I don't
think just weakening should for all of Policy is the right solution
to this bug. I also don't know if Bill would
On Thursday 10 April 2014 09:38:28 Bdale Garbee wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I did find three which are arguably recalcitrant maintainers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
Hi Ian,
On Thu, Apr 10, 2014 at 04:15:18PM +0100, Ian Jackson wrote:
Of course the participants in the discussion were approaching the
discussion on the basis that they are arguing about what the assumed
single menu system should be like. But it seems to me that we can
give everyone what
Steve Langasek vor...@debian.org writes:
- What *I* want is for the TC to take a principled stand on the point that
the policy manual exists to describe distribution-wide integration
policies, instead of taking a there's more than one way to do it easy
way out.
This is what I'd
Ian Jackson wrote:
I think you are perfectly entitled to let the people who care about
the Debian menu take care of that testing.
As others have pointed out, that's a level a lot lower in everyone's
current understanding of what should means in the context of policy. This
may not be what was
On Friday 11 April 2014 12:43:48 Stuart Prescott wrote:
Ian Jackson wrote:
I think you are perfectly entitled to let the people who care about
the Debian menu take care of that testing.
As others have pointed out, that's a level a lot lower in everyone's
current understanding of what
On Thursday 10 April 2014 18:25:43 Ian Jackson wrote:
Sune Vuorela writes (Re: Bug#741573: Two menu systems):
if it takes 5 minutes to write a menu file and 5 minutes to switch to one
of those 'old style' window managers and test that it shows up as it
should, it is 3000 minutes. Or 1 hour
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems):
The 'trad' menu file or the 'desktop' xdg file are only the starting
point of their technical differences; one other technical difference
that matters is the support for icon formats.
You have missed my key point about differences
Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
You have missed my key point about differences of goals between the
two menu systems. The trad menu explicitly has the goal of providing
a menu item for every invokable thing; whereas the desktop menu
maintainers want it to provide
2014-04-09 15:13 GMT+02:00 Didier 'OdyX' Raboud o...@debian.org:
Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
You have missed my key point about differences of goals between the
two menu systems. The trad menu explicitly has the goal of providing
a menu item for every invokable
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems):
Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
This means that we need two systems.
I don't think I missed the point; I was bringing a orthogonal one. I
understand you think the 'trad' menu is a useful metadata
Matthias Klumpp writes (Bug#741573: Two menu systems):
Also think about HIDPI-screens in particular, where these small icons
don't make sense at all (in fact, they are so small that you often
can't even tell what they display).
In situations like this, presumably the icons would need
On Wednesday 09 April 2014 15:04:36 Ian Jackson wrote:
Matthias Klumpp writes (Bug#741573: Two menu systems):
Also think about HIDPI-screens in particular, where these small icons
don't make sense at all (in fact, they are so small that you often
can't even tell what they display
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems):
Le mercredi, 9 avril 2014, 15.00:44 Ian Jackson a écrit :
Right. I understand that some people don't think the comprehensive
menu is useful. However, there are a lot of things in Debian that
some people think aren't useful
Sam Hartman writes (Bug#741573: Two menu systems):
So, I'd like to request the TC to first consider whether a consensus was
reached in the process and if so whether there's a compelling reason not
to respect that consensus. If no consensus was reached or the TC finds
it has a compelling
I have a very different take on this to Russ.
We currently have two menu systems. I'm going to call them the trad
and desktop menus.
They have the following very important differences (some of these are
matters of opinion, but I will take what appear to me to be the
opinions of their
Hi
I think there is a couple of facts that aren't fully accurate. I'll try to
mention them here. I'll try to keep opinions out of this mail.
On Tuesday 08 April 2014 18:30:26 Ian Jackson wrote:
Consumers: The trad menu is already consumable by a very wide range of
window managers etc.; the
On Tue, Apr 08, 2014 at 10:23:50PM +0200, Sune Vuorela wrote:
Note that a very wide range of window managers neither supports the trad.
menu
nor the desktop menu, but has a series of scripts to modify one or the other
into their native format. In Debian, most of these window managers only
69 matches
Mail list logo
