Bug#741573: Two menu systems
On Thursday, June 26, 2014, Colin Watson <cjwatson@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 still being maintained, and the global cost
> is minimal.
My feelings on this draft are mixed.
On the one hand, I happen to agree with the position that the
categorisation system in .desktop files (and X-Show-In etc.) should be
able to cover the bulk of the practical requirements of the trad menu
system:
* 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.
* We might have to look into the presentation of menu item names,
although Name / GenericName offers some support for the different
names that people are likely to want, and if all else fails the
.desktop file format does have extension mechanisms.
I would be very happy to see additional .desktop files being added to
packages with suitable categorisation such that they don't need to
interfere with how the maintainers of modern DEs want to present their
desktops, so that menu-xdg (or similar) can supplant the current menu
system with negligible loss of functionality for users of trad menus. I
think this would make a great project for people interested in unifying
the two worlds a bit more, which doesn't even have to step on anyone's
toes. Perhaps for instance it would be a good project for Debian's
Google Summer of Code efforts.
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.
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 disagree with its argument that it follows directly from the
two sets of competing requirements that we must have these two file
formats. 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.
> 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 think this is really overstated. .desktop files are in a
long-standing and popular basic file format for which plenty of parsing
libraries in various languages exist, so you can get to the point of
having a parsed data structure trivially. In contrast the menu entry
format is a bespoke thing. While the .desktop file format has more
bells and whistles, many of them can be ignored if you don't support
whatever it is. I don't think it's worth emphasising ease of
consumption either way.
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.
Best,
--
Cameron Norman
Reply to: