[sugar] icon assistance/validation

[Eben Eliason]

On Tue, Mar 18, 2008 at 10:23 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>  On Mar 18, 2008, at 14:51 , Eben Eliason wrote:
>
>  > On Tue, Mar 18, 2008 at 4:50 AM, Bert Freudenberg <bert at freudenbergs.de
>  > > wrote:
>  >>
>
> >> 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.
>
>  But then you would also have to animate strokes that are drawn in the
>  fill color. Which again may look odd.

As well as retain from pulsing fills that are rendered in the stroke
color. I see your point here, with the strange appearance of
translucent strokes.  I suspect, actually, that fills in the stroke
color will be far more common and useful in creating legible icons.
Perhaps we could even remove "strokes in the fill color" from the
ruleset, as I don't believe I myself nor anyone else thus far has used
them.

>  And what if your background accidentally matches your icon fill color
>  (at least in brightness in b/w mode)? You won't see any pulsing.
>  Rather, I'd think fading the stroke color to black and the fill to
>  white or some such scheme would work better.

Well, the stroke will likewise pulse from it's color to a particular
gray.  Chances that the fill matches the background color in
luminosity and the stroke matches that particular gray are slim,
especially considering we specifically picked colors sufficiently
distant on the Munsell color scale so as to always appear with
distinguishable contrast against both light and dark backgrounds (such
as the zoom-levels and the Frame)

>
>  > Do you think that making sugar-iconify a standard (and strongly
>  > recommended) step in creating proper sugar icons is a bad idea?
>
>  Recommended sure. But strongly? It should remain simple to author
>  these by hand, and currently it is rather simple (provided you know
>  the rules, which should be documented).

I'm all for hacking things up by hand myself, but I don't see the need
to cater to that approach over simply running a script.  It seems like
the script should make things far simpler for many, while those that
care to hack them up by hand should be perfectly comfortable with the
addition of a couple more entities.

>  > What are your experiences actually using it so far?
>
>  Mine? None.

In that case, would you mind testing it out a bit (even should you
remain one who wants to create them by hand in the future), just so I
can get some practical feedback on the performance, robustness, and
usability of the tool?  Thanks!

- Eben