On 2011-04-19, Bernhard R. Link <brl...@debian.org> wrote: > What about nautilus.desktop's (at least in squeeze): > > Name=File Manager > and no GenericName. Would that be a policy violation?
I would consider that a bug. At least my default Plasma Desktop menu shows the menu as GenericName (in black on white) Name (in gray on white, only when hovered) >> The OnlyShowIn/NotShowIn items should normally not be used, unless there >> is a tight integration between a DE and the app itself. e.g. a tool to >> configure the appearance of Plasma should probably have OnlyShowIn=KDE > > What exceptions are there? Should there be a lintian warning about > those? A lintian warning doesn't make sense. it can't be automatically determined what a application do or does not, and what it works with. > What about NotShownIn? Is e.g. squeeze's gnome-screenshot.desktop's > NotShowIn=KDE; > a bug and should it have been OnlyShowIn=GNOME; or nothing at all? I don't know what gnome-screenshot does, but there are many cases where NotShowIn=KDE is a better choice than OSI=GNOME, because xfce and lxde also uses gnome specific stuff. And the Gnome people seems to prefer adding OSI=Gnome, where others have a equivalent, no what, just like there is implemented a blacklist in the gnome menu that blacklists apps that could be usable from the gnome menu. (kwrite, digikam, ...). > >> > "http://www.debian.org/doc/packaging-manuals/menu.html/ch6.html". >> >> I guess one can write something similar. >> >> but basically it is syntax changes and >> 's,.menu,.local/share/applications,' > > Well, I hope there is something similar, but getting this documentation > for users is very hard to get out of the xdg specs. There might be something similar written. I haven't looked for it. But there is various graphical applications for editing your menu, which is probably the preferred form for most our users. >> > And in terms of policy I miss a better description of the Categories, >> > better rules how Name/GenericName/Comment should be written and when >> > OnlyShowIn/NotShownIn are to be used. >> >> Does my comments here clear it up for you? (then we can talk about >> making docs out of it) > > Unless there are many bugs around currently, I think this rather needs > a policy for those fields rather then simply docs. There are most likely many bugs around. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqr369.p7v.nos...@sshway.ssh.pusling.com