Re: External dependency: icontool

[Frederic Peters <fpeters gnome org>]

Rodney Dawes wrote:

> Currently, we are using icon-naming-utils in gnome-icon-theme to create
> the backwards-compatible symlinks for icons. However, I've created the
> icontool [1] project to subsume this task, as well as provide useful
> tools for managing other aspects of themes and icons in applications. As
> part of that, there is also now the icontool-render script, which takes
> a single-canvas SVG [2], and generates individual PNG images of the
> icons contained within it. This single-canvas workflow makes it much
> easier to maintain icons in themes and different projects.
> 
> As such, I would like to have icontool be a blessed external dependency
> in GNOME 2.27+, so that we can switch to using it in gnome-icon-theme,
> for maintaining the compatibility symlinks, and rendering icons from the
> single canvas SVGs, which we intend to migrate to in the relatively near
> future, for all the icons in gnome-icon-theme.

Will it be developed very close to gnome-icon-theme (i.e. will it gain
new options that will immediately be required by gnome-icon-theme,
just like new features in ptlib/opal are directly required by ekiga) ?
I am asking this as being external dependencies comes with a few
rules, that may not be appropriate in that case.

Just like intltool was initially part of the GNOME platform before
moving only recently to the external deps, after it gained a stability
and users outside of the GNOME modules, I wonder how different is the
situation with icontool ?


My other point is about the icontool-render script, is it expected for
modules to ship single-canvas files, and create icons during 'make' ?
If that's the case, how far are inkscape and librsvg ?, as depending
on inkscape to render icons would make our dependency tree fall down.



Cheers,

        Frederic