Hi, On 12-05-13 02:04, Michael Biebl wrote: > Hi Russ, hi Sune, > > I'd like to second this request to reword the current section in the > policy regarding menu files, suggesting fdo .desktop files as the > recommended mechanism and make it clear that .menu files are only really > relevant for legacy or more exotic window managers. I am not opposed, in principle, to switching to desktop files and away from .menu file -- at least not anymore. But if we're going to do that, we should do it right. > Sune's patch looks fine to me. It refers to some (unspecified) window manager implementations as "legacy", which I think is a no-go (if they're supported in Debian, by definition they're not legacy). Apart from that, I would like to see rough feature parity, i.e., - support for applications which start from a terminal, using the x-terminal-emulator alternative), without hardcoding the terminal emulator (for pdmenu or similar things) (possibly desktop files already support this; if so, feel free to just point that out ;) - per-user desktop entries (~/.menu, and update-menus run as user) that are not specific to the used user interface. (same note as on the previous item) - an easy way for window managers that don't use the desktop format directly to be told when there are new entries and they need to rebuild their menu. With the Debian menu system, we have update-menus which is called at postinst time (possibly by a trigger, I'm not sure); there should be something similar for desktop entries. This might simply be implemented by a dpkg trigger that all interested window managers listen to and that desktop-installing packages should emit; but we should document such a procedure before making this switch. Moreover, we should have clear policies on what the contents of a .desktop file should look like, that goes way beyond just a vage URL over at freedesktop.org. Specifically, we need: - a replacement for our current menu policy which explains which types of applications will go where. Consistency across user interfaces is a *good* thing, and to get that we'll need to make some decisions ourselves, sometimes overriding upstreams. That should obviously be the exception rather than the rule (i.e., we should construct something that would allow us to keep "most" upstream desktop files, for whatever definition of "most" makes sense). Consistency across choice is one of Debian's strengths; we should strive to keep that feature. - A decision/clarification on what will happen when a desktop file contains the "only show this in GNOME" feature (with which they *actually* mean "don't show this in KDE") and the user interface in use is neither of those two. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/
Attachment:
signature.asc
Description: OpenPGP digital signature