Paul Wise <[EMAIL PROTECTED]> writes: > On Sun, 2008-03-02 at 21:18 -0800, Russ Allbery wrote:
>> [snipped tons of directories] >> This looks rather unmaintainable from a lintian perspective unless >> there's some (rarely-changing) standard that specifies those >> directories. If I'm reading the implications of your message >> correctly, that list could change arbitrarily with each release of the >> hicolor theme package. I don't see any clean way that we could >> maintain this. > > See the Context table at the top if this: > > http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html That only lists some of the subdirectories of your list (it's missing all the stock/* ones) and doesn't use the same names (international instead of intl, applications instead of apps). All of those seem like things that could change on us, no? I wonder if desktop-file-validate would understand all of this. It's on the list to look at whether we can replace the desktop checks in lintian with it. > The hicolor standard theme is specified in this: > > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Interesting, thanks. It would be really good if some of this information could be written up from the perspective of a Debian package maintainer, since right now there's approximately zero information anywhere for how to deal with desktop files if one doesn't personally use Gnome or KDE and isn't familiar with this whole system. I tried to figure this out for gnubg and didn't have a lot of luck. > Yah, which is most of them since it gives the icon system theme-ability. > On my system, 32 desktop files out of 321 use an absolute icon path. IMO > the ones that do are buggy since users cannot override the icons. Ones > that use an extension like .png, .svg or .xpm in the Icon field are also > buggy because users may want to provide their own versions in a > different format. I expect that a lot of the people (like me) who are doing that had no idea what else to do, or that it was even kosher to install files into the hicolor directory. There's a lot of Debian communication missing in this area, I think. lintian can help somewhat, but right now people are working in a void, and adding a few lintian checks probably wouldn't be nearly as useful as writing a comprehensive guide to how a Debian maintainer should tackle these issues. (And then lintian checks can reference the guide.) > Isn't this the standard for desktop files? > > http://standards.freedesktop.org/desktop-entry-spec/latest/ It claims to be, but it's actually the standard for Gnome desktop files. *wry grin*. As I discovered when writing lintian checks against that standard, KDE does something different and uses various fields that aren't listed there. Let alone GnuSTEP, which is even weirder. lintian is currently trying to check sort of a subset of that specification, only desktop files of a particular type, and with additional workarounds for KDE-specific stuff that can't be checked. > I'd also like to see a lintian info/warning when a menu file is > installed in the package, but a .desktop file is not. The reason for > this is that in that case, GNOME users will not have the application in > their menu unless they turned the Debian menu on, since it is off by > default. The last time someone proposed this, it sparked a huge flamewar on debian-devel. I'm not sure I want to wade back into that. Apparently the GNOME maintainers disabled the Debian menu because they think it's largely worthless, and just blindly reintroducing .desktop files for every .menu file would restore the previous situation. Logically, if every .menu file should correspond to a .desktop file, the GNOME maintainers could just include the Debian menu. Since they don't, that indicates to me that some logic (not yet documented) should be applied by Debian maintainers to decide whether or not to include a desktop file. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
