Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On 2011-04-19, Bernhard R. Link <firstname.lastname@example.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
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
> 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
> 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.