Wouter Verhelst <[email protected]> writes: > 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).
I think it's fair to say that not supporting desktop files for the menu infrastructure makes a window manager legacy at this point. I use one of those window managers personally, but the fact remains that this is the direction in which the whole desktop world has gone, and most new window managers, even those that aren't really trying to provide a desktop environment, support them to the degree that they do things related to desktop files. > 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 ;) I'm fairly sure they do. This is the Terminal=true setting. > - 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) Already supported, although where you have to put the desktop file varies depending on the environment. There is slow convergence (I think) on the XDG paths, but we're not there yet. > - 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. It would be ideal if we had something like this in place, but the reality of the situation is that we're already making this switch, and no one is stepping forward to do this work. At some point, I think it becomes the obligation of the fvwm (etc.) maintainers to do this work if they want to see it done, rather than asking the GNOME and KDE and Xfce maintainers to write code for window managers they don't use and don't support in order to move forward with their upstream direction. So I don't see this as a valid prerequisite. > 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: The URL is really not that vague, speaking as someone who wrote the Lintian validation code based on the specification. > - 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. I don't think either of these are related to this bug. We already have tons and tons of packages with desktop files, so to the extent that these are issues, they're already issues. Trying to hold up further encouragement of desktop files at this point in order to fix these problems feels counter-productive to me. There is an existing fdo standard for what categories to use in what situations, and while it's not as detailed as one might like, it's workable. It might be worthwhile linking to it directly, although I think the desktop file spec already does. I do agree that both of these are desireable, though, and would strongly encourage the various parties involved in menu implementations to get together and find consensus on these sorts of issues. The result of that consensus would be appropriate for inclusion in Policy (probably as a desktop file sub-policy). -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
