On Tue, Mar 18, 2008 at 11:37 AM, Gary C Martin <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
sugar-iconify
Description: Binary data
_______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar