Icon theme specification: Standardizing icon names
Owen Taylor
otaylor at redhat.com
Thu Oct 14 00:15:45 EEST 2004
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.
There are two ways of doing this:
1) Standardizing the image and requiring all icon themes to use the
same basic metaphor.
2) Standardizing the usage with a sentence or two description of what
the icon is used for.
Doing either of these for 1000+ icons is a huge job.
- 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.
One possibility would be to to divide the icon name list into two
pieces:
- Core: These icons are required in all icon themes and can be
relied upon
- Extra: If an application uses an icon for this purpose, it should
use the specified name.
That might reduce my concerns a bit. But in general, I think starting
small is good. And I think having a set rules for the criteria
for acceptance and the required definition of each icon beyond the
name is essential.
I can't speak for GNOME in general, but from my perspective, I'd much
rather have the icon name list be genuinely useful for application
developers rather than just being a superset of all GNOME, KDE,
and OpenOffice (*) icons.
Regards,
Owen
(*) Yes, I know the OpenOffice icons aren't in this currently, but they
would be a natural extension in the future.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041013/e7662f70/attachment.pgp
More information about the xdg
mailing list