Icon theme specification: Standardizing icon names

[Kenneth Wimer]

* Owen Taylor <otaylor at redhat.com> [Oct 13. 2004 23:19]:
> On Mon, 2004-10-11 at 18:13 +0000, Frans Englich wrote:
> > On Monday 11 October 2004 15:10, Owen Taylor wrote:
> > > Some very quick comments. It's really great you are working on this.
> > >
> > > On Sat, 2004-10-09 at 21:50 +0000, Frans Englich wrote:
> > > > Hello everyone,
> > > >
> > > > Attached is a patch which standardizes 1048 icon names, compiled from the
> > > > ~2050 icons which KDE and GNOME in all houses. While that sounds like a
> > > > lot, and bizarre for that matter too, the important question is where
> > > > this is heading, what we want to achieve, and why.
> > >
> > > Does it make sense to standardize this many icons? Should we try to
> > > standardize a smaller subset that really obviously make sense ...
> > > creating an icon theme with 1048 icons is pretty prohibitive.
> > 
> > It is many, but it is what GNOME and KDE needs. It is gnome with the oo.o 
> > icons which pops the roof. The question is, since all these icons should be 
> > spec'ed at somepoint anyway, it's perhaps just as good to do it at once. In 
> > the GNOME case the icons already exists. The trouble of achieving conformance 
> > is organizational; to play diplomacy and contact projects, surf repositories, 
> > and get all these icons collected in one place -- and with the right 
> > names(that diagnosis tool is a must have). The problem is, if we go for 
> > something small, it won't work with GNOME, for example. I'm not convinced in 
> > this matter and I'll happily see someone clear my confusion.
> 
> My concerns about standardizing 1000+ icons come in several areas:
> 
>  - Simply having a big list of names for icons isn't useful; what does
>    'execute-terminal' look like? What does it do? In order to make the
>    spec useful for application developers, they have to be able to pick
>    an icon based on the icon theme spec.

I think that this is well founded. The idea of unifying things is not to
make a big list of everything until now and call it unified, but I don't
think that that is the idea behind the work until now.

>    There are two ways of doing this:
> 
>    1) Standardizing the image and requiring all icon themes to use the
>       same basic metaphor.

THe idea of defining a standard metaphor for as much as possible is
important although certain themes will always want to break away from
that metaphor (a "kids" theme for instance) although even here one can
argue as to how much things need to be changed.

>    2) Standardizing the usage with a sentence or two description of what
>       the icon is used for.

Because of the differennt needs of the different desktops and
applications therein I think that defining a standardized way of naming
the extras would at least be at least a start. In the end this might reveal many
that could be easily replaced by a standard metaphor.

>    Doing either of these for 1000+ icons is a huge job.

no doubt.

>  - If we are completely unselective about what goes into the icon theme
>    spec, maintaining stability going forward is going to be horrible,
>    because we won't have any reason for saying no to proposed additions.
> 
>  - I don't think the existence of icons in the default/hicolor theme 
>    reduces the load on theme creators that much. The current hicolor
>    theme icons are largely pretty *bad*, and will look considerably 
>    out of place in most icon themes.

This might change somewhat in the future as companies become interested
in Accesability and such...because these icons are bad now is not a
reason to argue against using them. The hicolor stuff could actually be
a good place to begin implenting the spec for several reasons.

Bye,
Kenneth

-- 
SUSE Linux - a Novell Company - Nuernberg, Germany
--------------------------------------------------
Scheinbare Rechtschreibfehler beruhen auf einer individuellen
Rechtschreibreform