Multiple DeskTops, HiColor theme, standardized icon names, & menu icons

[Rodney Dawes]

On Fri, 2006-06-30 at 07:59 -0700, Bastian, Waldo wrote:
> >This probably doesn't make much difference (at least for now) for KDE
> >apps and GNOME apps because they will continue to use their respective
> >icon loaders to load the icons.  But, what about third party apps?
> >There needs to be standard so that they can have the DeskTop (probably
> >through Portland) load the themed icons.  Third party apps need ONE
> >standard to follow for menus, icons, MIME types, widget themes, color
> >schemes, etc.
> 
> It is undesirable to impose requirements on third party apps wrt where
> they should install application private icons. It's ok to have standard
> locations where themed versions of such icons can be provided by other
> parties (fourth parties?) and to ask applications to take these
> locations into account when looking up icons if theming of said icons is
> supposed to be possible (which may not always be the case).

So as a third party developer, I should NOT install my app icon to
hicolor, or my MIME type XML description file to
$datadir/mime/packages, or my .desktop file to $datadir/applications?
We're already "imposing requirements" on third party apps wrt where they
should install things. Why should enabling the ability for a standard
method of fallback for icons that those apps want to have themed, be
any less appropriate?

Every time a developer asks me where the hell they are supposed to put
icons that may conflict with other applications, that they want to have
themeable, and want to fall back to in the event that themes don't
provide these icons, I'll gladly refer them to you. And you can explain
how we're half-assedly writing specifications that are confusing, and
aren't actually useful for anything beyond the theming of a single icon.
Because I'm quite tired of doing it myself.

-- dobey