[Tango-artists] Icon naming theme and installers

[Richard Hughes]

On Fri, 2008-08-29 at 05:24 -0400, Rodney Dawes wrote:
> On Fri, 2008-08-29 at 09:27 +0100, Richard Hughes wrote:
> > I'm developing PackageKit, and I'm trying to make it work well with
> > other package managers in the system. I'm having real problems with
> > icons.
> > 
> > At the moment I've got:
> > 
> > #define GPK_ICON_SOFTWARE_UPDATE		"system-software-update"
> > #define GPK_ICON_SOFTWARE_SOURCES		"x-system-software-sources"
> > #define GPK_ICON_SOFTWARE_INSTALLER		"system-software-install"
> > #define GPK_ICON_SOFTWARE_UPDATE_PREFS		"x-system-software-update-preferences"
> > #define GPK_ICON_SOFTWARE_UPDATE_AVAILABLE	"software-update-available"
> 
> Please don't just prepend x- to icons which aren't in the spec, which
> you think you need. The correct way to name app icons is to have them
> match the app's binary name, if they aren't in the spec. We have to
> avoid having apps install generically named icons into hicolor, as if
> one app does it, then it sets precedent for other apps to do the same,
> creating a mess of possible file conflicts.

Ohh, the x- prefix icons are not installed in hicolor, I just wanted to
signify that I thought they were worth standardising in the future.

> > Just for the installer, it appears we have a few names:
> > 
> > Tango: system-installer
> > gnome: system-software-install (old name?: system-software-installer)
> > Bluecurve: icon-install-software
> 
> The only one of these which is following the spec, is gnome. The icon in
> Tango was from before an "install" icon was added to the spec (we only
> had the update icon previously). And I don't know what the hell
> Bluecurve was thinking.

Right, can we rename the icon in tango then please, and add something in
legacy-icon-mapping.xml to cover system-installer,
system-software-installer and icon-install-software please?

> > I've attached a patch to fix this in the legacy mapping, but the issue
> > of the other icons is still valid. The other icons I'm sure need
> > standardising is:
> > 
> > * system-software-sources
> > * system-software-update-preferences
> 
> I'm not sure these really merit the need for standardization.

Pretty much every modern distro ships a repo management tool, and an
auto-update prefs tool. Surely if there is just a few consumers (say
zen-updater, update-manager and PackageKit) then that's worth adding to
the spec?

> Why is
> "sources" configuration separate from "preferences"? If the latter were
> to be put in the spec, the correct name would be
> "preferences-system-software-update" I think, as per the system
> preferences categories already in the spec.

preferences-system-software-update is fine for me too.

> What would the metaphor for such an icon be?

It's for the configuration of what is automatically updated, and when.
Such a metaphor could involve the packaging icon and the updates arrow.

> Is a separate "preferences" program really necessary?

Yes.

> I know having it is traditional, but is it really needed? Can't you
> simply manage the preferences in the updater/installer UI? Or if I open
> the updater, and choose Edit->Preferences, do I get different UI than if
> I run "Software Update Preferences" from the control center? If so, why?

We've discussed the usability of this way of doing it, and it's just not
discoverable enough. Putting an icon in System / Administration or
Preferences / System is the best way.

> > I'm also not sure why system-installer isn't present in
> >
> http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html -- and I'm not sure where the latest cvs of icon-naming-spec is located.
> 
> Because system-installer is not a spec icon. The spec icon is
> system-software-install (as it is in gnome-icon-theme). The Naming Spec
> is in CVS at freedesktop.org in the default-icon-theme module for the
> icon-theme project, which is the same place the Icon Theme Spec lives.

I couldn't find it here:
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

> > On further investigation it appears that lots of the "Standard
> > Application Icons" are missing from the spec. If this is due to lack of
> > time, I can russle up some patches to remedy that if you wish.
> 
> Please define "Standard Application Icons" in depth. What one person
> might consider "standard" may be unconventional to others. The goal with
> the icon naming spec is to provide a basic set of names that every theme
> should provide, based on what the majority of desktops ship. 

Right, then it's not really an icon naming spec, it's a base-set for
icon themes. If two projects like pidgin and empathy agree on some
common names, then shouldn't they be standardised in the
icon-naming-spec (and old icons added to legacy-mapping) rather then on
some random wiki?

I think it's okay to have incomplete themes, as missing icons will fall
back to another theme. I sure not all icon themes will have drawn
weather-showers-scattered, so I don't think it's useful to use the
argument that it's another icon we're forcing an theme designed to draw.

> > The page at http://tango-project.org/Tango_Icon_Library#Download also
> > redirects to a domain parking website -- probably not what is wanted.
> 
> tango.freedesktop.org is the proper domain to use.

Right, you guys need to setup redirects, as it's very confusing for
users.

> > Anyway, please tell me what I need to do. At the moment I'm thinking of
> > just copying the icons and shipping them in the gnome-packagekit
> > tarball, but that is probably the wrong thing to do now we have the icon
> > naming spec.
> 
> Copying what icons? There are no icons to copy. There are either icons
> in the spec, or not in the spec.

Well, at the moment, I'm going to get someone to draw me some icons,
stick them in the tarball, install them to /usr/share/gnome-packagekit
and not worry about sharing with other projects or making it easily
themable. Sharing icon names should not be this hard.

> The ones in the spec, you obviously
> need not copy to install yourself. The ones not in the spec, if they
> are application icons, should be named to match the application's binary
> name, and installed to hicolor's apps context, as per the spec.

The binary name is not important. They are abstract tools used by many
different distros.

<rant>
Being brutally honest, I didn't expect to have to write such long
defence just suggesting that we should add a couple of icons to the
spec. If someone (me) writing domain specific software comes to you
asking for common icon names, then that's win-win for all involved. If
you come to the same author a few months later and ask him to change to
new named icons not yet in any theme, then it's much harder.
</rant>

Richard.