Ian Jackson <ijackson@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 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 resolution needs to acknowledge (in the "whereas"
> section) that consuming a trad Debian menu entry is simpler and easier
> than consuming a .desktop file.
I would dispute this statement; there are C, perl and python library
bindings for the entire suite of freedesktop.org specifications which
make dealing with these file formats straightforward. As the standards are
cross-distribution systems, support and knowledge are far broader than
any Debian-specific system.
--
keith.packard@intel.com
Attachment:
pgpGQJqoOCKIi.pgp
Description: PGP signature