Ian Jackson <ijackson@chiark.greenend.org.uk> writes: > * Overall, this would make it possible, therefore, to maintain the > menu information primarily in the more sophisticated .desktop > format, so that source packages with .desktop files would not need > to contain trad menu files too. Yes, the wording that Sam and I worked out this morning for the final ballot option advises this kind of solution, where users of the debian menu system gain access to applications through a combination of menu and .desktop files. You can see that draft ballot here: http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/odyx_draft.txt > The only remaining questions are then : > > Q1. Whether it is better to convert from .desktop files to trad > Debian menu files at package build time, or to change the > existing trad menu consumers to be able to convert .desktop > files to the required format ? I believe that having the debian menu package capable of parsing both formats will reduce the maintenance burden for packages providing .desktop files. Someone needs to write a conversion script; adding that to only the menu package and not all application packages seems like less work overall. > There is an easy answer to this: this conversion may involve > image conversion libraries including even perhaps an SVG > renderer, and other conversion software, which is > disproportionately heavyweight for many trad menu consumers. > (Trad menu consumers tend to be non-desktop `lightweight' window > managers.) librsvg2-bin and netpbm are what I use for this work; the dependency list for these is fairly small, and shares almost everything with requirements to run a fairly basic X desktop. I do not see this as an excessive burden to run when installing a new package. > Q2. Whether packages (bc, many command line games, ...) which only > want to provide a trad Debian menu entry should do so by > including a .desktop file in the source code, or a trad menu > entry. > > I see no need for policy to mandate any particular answer to > this. The maintainer should do what they prefer. The biggest policy change I've proposed is to remove the requirement for menu files for any package in the archive, and to replace that with a fairly soft requirement that "desktop applications" have an associated .desktop file. Otherwise, maintainers are free to do as they like. > I think this would involve: > > - defining new field names for .desktop files to contain > the trad menu metadata, as necessary. I think we can safely > call these fields X-Debian-* or X-Debian-Menu-* or something. I'd like to suggest that all of this additional menu-package specific information could be delivered with the menu package itself, and not spread across all of the application packages. As you note, the bulk of the information loss in translating .desktop to menu files is in the hierarchy of the debian menu, and not in information tightly tied to the specific package version, so the information is unlikely to go stale as things change. By providing some reasonable defaults for Freedesktop Desktop Menu categories, the need for per-package definitions would be greatly reduced. Yes, this seems a bit backwards, but consider the benefits to menu system users -- it's probably far easier to convince the menu package maintainers to release a new version that adjusts the location of a new application within the debian menu system than to get that application maintainer to package changes which they are reasonably unlikely to be dependent on. And, as the hierarchy is defined by the menu system maintainers, it will likely be more consistent and correct than having the menu constructed in distributed fashion by a collection of menu system users and random desktop application maintainers. -- -keith
Attachment:
signature.asc
Description: PGP signature