Bug#741573: Two menu systems

[Russ Allbery]

Keith Packard  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 icons.

> 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.

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?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#45

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egy5bnra@windlord.stanford.edu

Bug#741573: Two menu systems

[Keith Packard]

Nikolaus Rath  writes:

> Keith Packard  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 already. At
> least on my testing system, there is:
>
> NAME
>desktop2menu - create a menu file skeleton from a desktop file

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 icons.

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.

-- 
keith.pack...@intel.com


pgpp8TjiS5W0L.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Nikolaus Rath]

Keith Packard  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 already. At
least on my testing system, there is:

NAME
   desktop2menu - create a menu file skeleton from a desktop file

SYNOPSIS
   desktop2menu --help|--version

   desktop2menu desktop file [package name]

DESCRIPTION
   desktop2menu generates a skeleton menu file from the supplied
   freedesktop.org desktop file.

   The package name to be used in the menu file may be passed as an
   additional argument. If it is not supplied then desktop2menu will
   attempt to derive the package name from the data in the desktop file.

LICENSE
   This program is Copyright (C) 2007 by Sune Vuorela
   . It was modified by Adam D. Barratt
for the devscripts package.  This program
   comes with ABSOLUTELY NO WARRANTY.  You are free to redistribute this
   code under the terms of the GNU General Public License, version 2 or
   later.

AUTHOR
   Sune Vuorela  with modifications by Adam D. Barratt
   

   
Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a98t1zej@vostro.rath.org

Bug#741573: Two menu systems

[Keith Packard]

Josselin Mouette  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 /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 command line arguments for normal operations should
  register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

> We don’t need menu entries for bc or python, unless they are
> NoDisplay=true. This should be obvious, but currently we have trad menu
> entries for them. The proposed wording for the policy (which is the
> result of a compromise work between desktop maintainers and policy
> editors) handles this by stating maintainers must set appropriate
> NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
> are not cooperative in this matter (hence gross hacks such as
> gnome-menus-blacklist).

I think it's a lack of clarity in the spec which encourages
over-production of menu entries.

> Experience shows it doesn’t work. You can have ad-hoc selection after
> time (either automatic or manual), but you need something that works out
> of the box. Three-level nested menus with hundreds of entries are not
> something to present a new user, regardless of her proficiency.

I completely agree, but I don't think we can mandate good UI design in
Policy, all we can do is provide the tools necessary to construct a good
UI.

> There is a sensible way: not present the useless ones. Use
> NoDisplay=true everywhere appropriate.
>
> I don’t think presenting the whole contents of /usr/bin in a menu is
> helpful in any way to anyone.

As you say, we can't expect package developers to always make the
choices we'd like. I don't have any good solutions here, but I don't
think how the underlying menu information is transmitted in the package
is affected by that problem.

-- 
keith.pack...@intel.com


pgpmwHwIldT7h.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Russ Allbery  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.  See:
>
> http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I didn't actually review that spec before putting together my
draft. I think it's slightly orthogonal to the question of how
applications publish information about themselves to a menu program
though.

> I'm not positive that the syntax of /etc/menu-methods is any less complex,
> but it's at least arguable, and it's certainly way different and already
> designed for generating menus for other applications that don't inherently
> support the XDG menu system.

It seems to me that the freedesktop .menu file format is that can be
mechanically constructed from the set of installed .desktop files, at
least by default. To some degree, that makes it something of an
implementation detail for a particular menu program. I think it is
documented so that external menu editing tools can be written to
rearrange things from the default configuration.

-- 
keith.pack...@intel.com


pgpLYZ7LgSb_i.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Cameron Norman  writes:

> 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 WMs do not have to handle so many corner cases in that area.

A window manager will need to handle resizing of icons in any case, and
it's pretty darn hard to pin down which sizes to require when so many
screen sizes and resolutions are in common use these days. Ideally, the
icon artwork is presumably coming from upstream and not constructed for
packaging purposes; that will naturally limit the icons to what is
provided, making mandating specific sizes somewhat impractical.

Of course, I would encourage application developers to provide .svg
icons instead of fixed sizes. That gives the window manager the
ability to present something good looking at any size.

-- 
keith.pack...@intel.com


pgp1SfIWElwy7.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Josselin Mouette]

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 this question by demonstrating that the .desktop format
> offers a proper superset of the information found in menu files, and
> that package maintainers could mechanically convert their existing menu
> files into .desktop files without loss of information.

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.

We don’t need menu entries for bc or python, unless they are
NoDisplay=true. This should be obvious, but currently we have trad menu
entries for them. The proposed wording for the policy (which is the
result of a compromise work between desktop maintainers and policy
editors) handles this by stating maintainers must set appropriate
NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
are not cooperative in this matter (hence gross hacks such as
gnome-menus-blacklist).

> I'm afraid that my notion of a transition plan was expressed implicitly
> in the proposal rather than explicitly. In any case, the transition plan
> I had in mind was pretty simple:
> 
>  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.

That part of the plan is obvious: replace the current “menu” package by
https://wiki.archlinux.org/index.php/Xdg-menu

>  2. Transition packages from providing menu files to providing .desktop
> files, deprecating support for the menu file format within the
> archive over time.
[snip] 
> I'd love to see so many programs in my menu that menu program developers
> are encouraged to figure out how to reasonably select entries in menus
> so that we can get to some kind of intentional preferential listing
> mechanism, rather than the ad-hoc selection that we have today.

Experience shows it doesn’t work. You can have ad-hoc selection after
time (either automatic or manual), but you need something that works out
of the box. Three-level nested menus with hundreds of entries are not
something to present a new user, regardless of her proficiency.

> However, I don't think that Policy is a sound place to make user
> interface design decisions, and that we should naturally defer how to
> present the provided application set to the menu program developers. I
> believe this part of Policy should focus on stating what application
> developers are expected to provide for the menu system, and then let the
> menu program do 'something sensible' with the provided data.

Agreed.

[snip] 
> I think this distinction is entirely an artifact of the current split
> between packages, some of which install only a menu file, and some of
> which install both menu and .desktop files. I would hope that by
> encouraging all packages to deliver only .desktop files, we'll see
> developers thinking about sensible ways to present hundreds of
> applications to their users.

There is a sensible way: not present the useless ones. Use
NoDisplay=true everywhere appropriate.

I don’t think presenting the whole contents of /usr/bin in a menu is
helpful in any way to anyone.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404164217.14436.476.camel@dsp0698014

Bug#741573: Two menu systems

[Keith Packard]

Colin Watson  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 different coverage, not because
>the .desktop format is inherently unable to meet the needs of trad
>menu consumers.

That's my view -- the two systems are split because they use a different
file format, and not through any carefully considered reason.

> On the other hand, Keith's draft seems highly aspirational to me.  While
> it seems to me to be broadly the right kind of long-term technical
> direction, there is an awful lot of work in there for people who want
> something like trad menus which is being glossed over.

I think the only piece of work necessary is to add support for .desktop
files to the 'menu' package. With that, other packages are free to
transition from menu files to .desktop files and any existing menu
programs will continue to work as before, while .desktop file consuming
menu programs will slowly see more and more applications to present.

> So, I prefer Ian's position in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
> purposes of how the policy text should remain for the time being, and in
> terms of the philosophy of not ripping out work from under people's
> feet.

I guess I'm not sure what work we're ripping out from under people's
feet here. The only significant change proposed is to require support
for .desktop files in the 'menu' package. I would imagine that the
simplest way to add .desktop file support to the 'menu' package would be
to translate .desktop files into menu files and process those through
the existing code base.

> I prefer Keith's position as a long-term direction, but agree
> with Ian that it is lacking an awful lot of transitional thought, and
> feel that it has a lot of things-should-be-done without it being clear
> who will do them.

I feel like there's a mis-characterization of what it would mean to
switch to .desktop files, and whether the change would need to be
all-at-once or could be done incrementally. Here's the transition that I
imagine would occur:

 1) Support for .desktop files is added to the 'menu' package. This
ensures that applications providing only a .desktop file would
continue to appear in menu programs using the existing menu package
infrastructure.

 2) Packages would be encouraged to transition to shipping only .desktop
files. Over time, more and more would start to appear in menu
programs with native .desktop support.

 3) .desktop-based menu program users would start exploring the broader
range of applications shown to them and enjoy the benefits of this
broader selection of tools.

None of these steps places any specific burden on developers, although
skipping step 1) would regress menu programs using menu package support,
dropping any programs which choose to not ship a menu file. I would
expect that to be sufficient incentive for the 'menu' package to add
.desktop file support though.

-- 
keith.pack...@intel.com


pgpfkt8fo4aqZ.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson  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 May TC meeting, I would draft a proposal that
provided an option which was .desktop-focused. It's not complete yet;
several people have graciously pointed out some fairly obvious bugs.

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 this question by demonstrating that the .desktop format
offers a proper superset of the information found in menu files, and
that package maintainers could mechanically convert their existing menu
files into .desktop files without loss of information.

> Firstly, there is no talk of a transition plan.  There is AIUI
> currently a mixture of programs which provide both kinds of entry and
> programs which provide only one or only the other.  A resolution
> saying that these things should be unified needs to either contain the
> transition plan, or say that someone (who?) should write it.  If the
> transition plan is to be written later, the resolution should also say
> what should happen in the meantime.

I'm afraid that my notion of a transition plan was expressed implicitly
in the proposal rather than explicitly. In any case, the transition plan
I had in mind was pretty simple:

 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.

 2. Transition packages from providing menu files to providing .desktop
files, deprecating support for the menu file format within the
archive over time.

These goals were both expressed in terms of 'should' statements in the
proposal, all of which were to be read in standard terms indicating that
failing to follow these policies would be considered a bug.

It sounds like you'd like to see this transition written in a clearer
and more concrete fashion though.

> Secondly, it doesn't discuss how these menus will be organised or
> displayed.  In particular, it doesn't discuss how to manage the
> distinction between:
>   - Menu consumers who want to display a comprehensive menu along
> the lines of the traditional Debian menu;
>   - Menu consumers who want to display a curated or filtered menu
> along the lines of the desktop system menus.
> And, of course, the corresponding distinction between the different
> kinds of program.

Right now, the problem we have is that many common menu programs display
only applications which install .desktop files. I don't think that's a
result of careful curating by the menu programs, but rather that the
menu programs end up choosing between the two menu systems, and are often
selecting the one preferred by the upstream menu program developers.

I'd love to see so many programs in my menu that menu program developers
are encouraged to figure out how to reasonably select entries in menus
so that we can get to some kind of intentional preferential listing
mechanism, rather than the ad-hoc selection that we have today.

However, I don't think that Policy is a sound place to make user
interface design decisions, and that we should naturally defer how to
present the provided application set to the menu program developers. I
believe this part of Policy should focus on stating what application
developers are expected to provide for the menu system, and then let the
menu program do 'something sensible' with the provided data.

The freedesktop.org specifications offer some guidance in this area, but
the wide range of potential user interface implementations for
application selection leaves them without a lot of explicit detail.

> At the very least the resolution needs to acknowledge that these
> distinctions exist and say that they are not being abolished.  Or, if
> they are, say which of the two uses is being abolished.

I think this distinction is entirely an artifact of the current split
between packages, some of which install only a menu file, and some of
which install both menu and .desktop files. I would hope that by
encouraging all packages to deliver only .desktop files, we'll see
developers thinking about sensible ways to present hundreds of
applications to their users.

What I'm hearing you say is that you'd like to ensure that users
continue to have an option of seeing all of the programs they've
installed available in a menu system. I'm emphatically agreeing with you
here, to the point where I'm proposing that we make it normal for *all*
menu programs to present all of the installed programs in their menus,
and then encouraging them to figure out how to display them in a
sensible and efficient manner.

> Thirdly, IMO the resolu

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson  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 for the translation into the new
> regime of the carefully curated organisational structure of the
> existing Debian menus.  Without such a translation it amounts to
> throwing away a lot of work.

I tried to cover this here:

4. Discussion of the precise relationship between menu file
   section/hints values and .desktop file Categories values may be
   defined within the Debian Menu sub-policy and Debian Menu
   System.

I could include a strawman translation between these two sets as a part
of this proposal if you think that would help.

-- 
keith.pack...@intel.com


pgpgA31zu9kfp.pgp
Description: PGP signature