On Mon, 2007-06-18 at 17:35 +0200, Oswald Buddenhagen wrote: > On Sun, Jun 17, 2007 at 05:56:52PM -0700, James Richard Tyrer wrote: > > Aaron J. Seigo wrote: > > > On Sunday 03 June 2007, James Richard Tyrer wrote: > > >> As you said, HiColor needs to inherit KDEClassic, but in GNOME, > > >> HiColor probably needs to inherit Gnome. > > > > > > it doesn't. > > > > What doesn't do what? > > > oh, c'mon, it's clear that this referred to the last sentence. you are > unable to state a problem in a few words and aaron is unable to > split/cut quotes - so what? ;) > > this is my summary of the topic. there are three categories of icons > that need to be considered separately: > - generic icons
[snip] > - application menu icons > - consensus seems to be that every application *has* to ship a hicolor > icon. yes, even if it is part of a desktop's core module. an > application that does not provide an icon here does not deserve > better than being shown as a question mark When did that consensus come about? Any application that just uses an icon from Table 2: Standard Application Icons in http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html should not be required to ship its own icon. In fact, they should not ship their own version. Otherwise, Yelp and khelpcenter will both try to install /usr/share/icons/hicolor/apps/32x32/help-browser.png And that would be bad. > - if you have a clash here, you probably have bigger problems > elsewhere anyway > - themes providing overrides is possible, but sort of rude > branding-wise I suppose it sort of depends on the application. I certainly don't mind Yelp being rebranded by an icon theme. But then, Yelp shouldn't have a strong independent identity. If you don't want your application icon overridden by themes, then IIRC you can give an absolute path for the Icon key in your application's .desktop file. > - private application icons > - where the app installs its native private icons is completely > irrelevant > - if it does not provide private icons it requires it does not deserve > better than question marks > - to be able to theme the app's private icons, the app needs to look > for icons from the configured theme(s) in some standard locations, > like share/icons/<theme>/apps/<app> or whatever - some ideas were > brought up in the discussion a year ago. My recollection is that developers should not install these anywhere under share/themes. The recommended place for them is under share/<app>/icons/<theme>. Since these icons only ever need to be loaded inside your application, it's sufficient to add this directory to the icon search path within your code. In GTK+, this is done with gtk_icon_theme_append_search_path. I'm sure KDE/QT has something equivalent. > - theming the app's private icons may be rude, too, but otoh the app > will probably mix standard icons with own icons, so precluding > theming the private icons makes no sense - unless the app completely > ignores theming preferences and requires a particular theme. And if applications really do not want their private icons overridden by themes, then they shouldn't load those icons through the icon theme. Developers have the choice here. > imo, the complete search order of icons should be configurable through > the theme choice xsetting. the algorithm to calculate this setting from > the themes explicitly chosen by the user could be the "forward/reverse > inheritance" i suggested in this thread originally. that way tango (or > any other theme that claims to be neutral and complete) could simply > plug the holes in an older desktop's default theme by simply being > installed/upgraded. Can't we just get it right? I don't want to see this in our desktop preferences dialogs: Icon lookup search order: (*) Forward ( ) Reverse ( ) WTF?! -- Shaun _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
