[sugar] icon assistance/validation

[Eben Eliason]

On Tue, Mar 18, 2008 at 11:37 AM, Gary C Martin <gary at garycmartin.com> wrote:
> On 18 Mar 2008, at 14:40, Eben Eliason wrote:
>
>  > 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.
>
>  If I understand your description here, I'm pretty sure I'm using them
>  to get crisp icon detail within the current design constraints – the
>  effect in the home ring was particularly poor without, if I remember
>  correctly (no doubt some other hack to get a strobe** working there):
>
>         http://dev.laptop.org/git?p=activities/moon;a=tree;f=activity

Thanks for this example.  It's a really nicely designed
sugar-compatible icon, and it does provide a good example use of
"stroke in fill color".

>  And I must admit I have the same concerns as Bert about using alpha on
>  the vector artwork, I've seen a bunch folks do this in Flash UI's and
>  effects, and they usually look like s#@t on a stick.

Agreed.  Again, this is usually the fault of the stroke translucency,
since the stroke overlaps the fill by half its width, causing a
layered effect.  Our only potential uses for this are (opaque stroke,
translucent fill) and (translucent stroke, transparent fill).  That
is, at no time will we ever use a translucent stroke in conjunction
with any fill at all, which is where you run into odd looking results.

>  ** Much as I like a SMOOTH strobe effect, the XO as I understand it is
>  really poor at transparency processing (HW can support it, but like so
>  many things, the SW support isn't there yet). So it's slow to the
>  point that the strobe effect had to be dialled down to the current
>  jerky flick book effect, making the machine look even slower (though
>  activities do launch slightly faster for the change). Is there perhaps
>  a more efficient, less hacky way to provide a 'launching' visual
>  metaphor (at least until sugar gets HW transparency and a compositing
>  API). Is a simple blinking effect at 1 or 2Htz between un-launched and
>  launched colours a possibility? Or is that too much like a potential
>  activity attention/notification type effect (say a person joins a non-
>  front chat session, or someone takes a new photo in a non-front shared
>  record session)?

Valid concerns.  This is mostly a subjective decision.  Mostly, we
designers refuse to believe that we can't find an efficient way to
pulse a 55px square...and so we haven't given up hope there yet.

>  I'll also take a look at some point, though so far I prefer hand
>  coding these simple shapes given the design spec. I used to be a fan
>  of Illustrator but it's just too expensive to justify unless you're a
>  heavy user, and Inkscape is feature rich but is borderline too clunky
>  and lumbering to work with.

It should be noted that you could still hand craft your SVGs, and then
run the script to do the entity conversion anyway.  Or, you could hand
craft the SVGs, including the stroke/fill entities, and then run the
script to add the opacity ones.  Again, I suspect that those willing
to craft SVGs by hand won't have trouble adding a few more entities.
If it's just a nuisance to do so, then the script can take it from
wherever you leave off.

>  I'm sure I spotted, in some dusty part of the wiki, someone writing a
>  simple SVG drawing activity – at the time I thought it was to aid
>  drawing shapes for activity icons, but I may have misread. Any one
>  know the status of it?

I hadn't heard of this, but I'm interested in knowing more.  We are
aware that we ultimately need a vector based creation activity (The
initial design intent was to add "Draw" in addition to "Paint").
Without one, kids won't be able to create icons for their own
activities, which runs counter to our goals.


OK, on to new things.  I've attached an updated version of the script
which attempts to address all of the concerns previously mentioned in
this thread.  The new options to the script are:

-i  This will modify the input file in place, overwriting it.  When
this flag is omitted, the script will export a new file in the output
directory specified with -o, having the name oldfilename.sugar.svg

-g  There is now a simple guess algorithm built-in, which attempts to
determine the stroke and fill values used in the icon.  By default,
the script will print out the guesses and ask for confirmation.  When
this flag is passed, it accepts the guess automatically.

I also added a warning when no entities are replaced within the icon.
Do you feel that I should actually increase the granularity, instead
providing warnings separately for strokes and fills?

The only remaining "oddity" in the script right now is that,
regardless of the colors that are used for stroke/fill entities, the
script will set the stroke and fill colors in the output to (#666666,
#ffffff) when a guess is made.  On the other hand, when you explicitly
pass them with -s and -f, the converted icon will retain the
explicitly set colors.  What do people think correct behavior is here?
 Always resort to the default color pair, even when the colors are
passed? (You can just edit the entity declarations at the top to set
it to anything after running the script...) Always use the passed or
guessed values?  (I didn't do it this way because, due to some
restrictions in the way the SVG DOM can be edited, I have to insert
the entities into the raw text before parsing the DOM, which means I
have to do it before I can make a guess as to the correct entity
colors...

I'd appreciate feedback on the changes.  Thanks!

- Eben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sugar-iconify
Type: application/octet-stream
Size: 11204 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/sugar/attachments/20080318/1594b7a2/attachment-0001.obj