Bug#741573: On menu systems.
Matthew Vernon <matthew@debian.org> writes:
> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've got
> installed. Its comprehensive coverage means that if I'm not quite sure
> what application I want, I can have a bit of a browse and try things
> out. Any proposal that reduces the coverage of the Debian Menu seems a
> bad idea for me...
(Speaking with my Policy hat on, per my previous message to this bug.)
There are two different issues here, which unfortunately are currently
linked.
The first issue is the file format and, more generally, the data model.
While there are some features in the Debian menu file format that are not
present in desktop files, I don't believe any of them are particularly
vital. There are more features in desktop files that are not currently
representable in the Debian menu file format. And, more importantly, the
desktop file format is a general standard, the files are often shipped by
upstream, and the format is being actively developed and improved by other
people whose work we can take advantage of.
While there are some transition headaches, I think the file format and
data model of desktop files is generally better, and that aligning with it
will reduce our maintenance and integration burden going forward. I think
we should be working towards a long-term goal of adopting desktop files
and phasing out menu files. (Note that, by this, I mean the files in
/usr/share/menu that are shipped by individual packages, not the files in
/etc/menu-methods that provide integration with window managers.)
The second issue is integration of the menu into Debian packages. Right
now, the Debian native menu system has better integration, particularly
into the non-DE window managers. (Putting aside for the moment that the
DEs largely disable the Debian native menu because it mostly duplicates
the menu generated from desktop files and they believe it to be less
useful.) If we abandon menu files right now and switch entirely to
desktop files, we lose several integrations that we currently have.
I think the ideal long-term outcome would be for someone to do the work
that Charles did for the MIME registry and either convert from desktop
files to menu files for the benefit of our existing integrations or redo
those integrations to support desktop files, whichever makes the most
sense in any particular case. That would let us switch to a more
broadly-used and widely-developed format and data model without losing any
features.
The problem at the moment is that no one has stepped forward to do that
work, and the desktop environment packaging teams are voting with their
feet towards using the desktop files instead of the Debian menu system for
a variety of reasons, mostly related to the additional features and better
integration in desktop environments offered by desktop files. So, right
now, if you want complete integration of your package into all of the menu
systems, you have to provide configuration for both systems.
This is obviously rather annoying for packagers, and it would be nice to
avoid the duplicate work.
For most, but definitely not all, of our users, providing the desktop file
is more important than providing the menu configuration. If we do
nothing, the likely outcome is that more and more packagers who are using,
e.g., GNOME or KDE will install or provide desktop files, find that their
program appears in the menus, assume they're done, and move on, and the
menu quality in other integrations like fvwm will keep declining. I
believe this has been happening for the past couple of years, although
that's based on a gut feeling and I've not tried to acquire actual data.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: