Re: SVG icons for HighContrast theme

[Rodney Dawes <dobey novell com>]

On Mon, 2005-10-24 at 16:58 +0200, Luca Ferretti wrote:
> Well, we need to port apps and libs to icon theme spec before :-)
> 
>       * libgnomeui stock icons - bug #319475 

This bug is basically not a bug. You can theme these icons through the
icon theme. You just need to use the names for the icons in the theme,
that are the same as the stock names. See gnome-stock-icons.h for the
full list in libgnomeui.

>       * metacity/libwnkc - see my post on desktop-devel-list, no bug
>         still open, but Havoc reply could be useful. 

I've replied to this thread with my thoughts and suggestions on the
matter. Perhaps we should just remove those icons from the menus, for
lack of a more consistent solution?

>       * capplets ?? 

The wallpaper capplet already uses the icon theme. Of course, it will
still need to be updated to use the icon naming specification, as any
app that currently uses the theme, will need to be.

> Rodney wrote icon-name-mapping tool in icon naming utils; could be
> really useful to create replied icons.
> 
> Unfortunately by now this tool can read only the XML file in ${prefix}
> to know source and destination names. It could be useful add a "--custom
> <xmlfile>" option to invoke it using a custom XML file place in
> compilation dirs.

The tool is a temporary solution. The proper thing to do is fix whatever
is doing icon name lookups, to use the names for things, as per the
naming specification. I've already submitted a patch to support the new
naming convetions, for libgnomeui. See bug #319196

> Moreover this tool can't use, in exaple, gtk-network.EXT file to create
> gnome-fs-network.EXT, because those icons are under different contexts
> (Actions for gtk-network, FileSystems for gnome-dev-network), i.e. under
> different directories. :-(

You're basing this conclusion on the structure used by the old method of
naming icons. Also, the contexts basically have 0 meaning, other than to
provide a directory structure. Of course, you still can't have two icons
with the same name, in different contexts. There's no technical reason
why this could not be done.

> Rodney, do you think you can extend it? My blue sky is provide icons
> using fd.o naming spec, run "icon-name-mapping --legacy" to create
> default links, and run "icon-name-mapping --custom ./<xmlfile>" to
> create custom links, if any (in example to use the same icon for charmap
> application and charpalette applet or to provide icons not defined in
> fd.o standard), providing names in a custom XML file. 

If the icons are needed, they should be defined, or a structure for
naming those icons, defined, in the specification. That is the entire
purpose of having a specification. The symlinks stuff is a very
temporary solution. What we really need are aliases internal to the
theme implementation, so that it doesn't need to hit the filesystem for
all the symlinks, and the icon themes can specify aliases for old icons.

-- dobey