[sugar] icon assistance/validation

[Eben Eliason]

On Tue, Mar 18, 2008 at 4:50 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Mar 17, 2008, at 21:01 , Eben Eliason wrote:
>  > - adds stroke_opacity and fill_opacity entities, for potential
>  > future use in sugar
>
>
>  I'd prefer to not introduce these entities before they are needed.
>  They only complicate matters for icon authors.

Well, my hope is that the entire icon construction process becomes as
simple as running this script; I don't want the authors to have to
worry about the internals of the SVG spec in order to be able to
produce icons.  Making this script robust enough to handle all the
edge cases, and some advanced use cases like multiple export, are my
goals in creating it.  It should make things easier for developers,
not harder.

In any case, I felt that introducing these entities now would make
things easier later if we chose to require them, since any icons made
from this point forward would already have them, thus relieving
developers from needing to re-export theirs.

>  Besides, I am pretty sure these will not have the effect you envision.
>  If you make a stroke translucent, half of it will visibly overlap the
>  fill, which looks odd. So even making both the stroke and the fill
>  translucent changes the appearance of the icon. What you actually want
>  is to make the whole icon translucent, and for that you do not have to
>  adjust the opacity of each individual element, so you do not need
>  entities.

Actually, the stroke entity is just there for good measure, as a pure
"just in case".  And you're right, a partial opacity on the stroke
makes very little sense on the stroke (unless, for instance, the
stroke is fully transparent for some reason). The primary intent of
this addition is to allow simple (gradated) transitions of the fill
between opaque and transparent, such as the effect that we're trying
to use when pulsing icons at startup. This will allow the effect,
which is currently a hack, to work cleanly against all backgrounds,
including backgrounds that change dynamically (such  as the background
of a pulsing icon in the Frame, on rollover), which is needed for the
new design.

Do you think that making sugar-iconify a standard (and strongly
recommended) step in creating proper sugar icons is a bad idea?  What
are your experiences actually using it so far?

- Eben