On 06.01.2010, at 11:54, Simon Schampijer wrote:
Hi,
Some thoughts that came up today - I will turn into bugs or discard after feedback.
Is there a reason the etoys save a copy (keep as) button is not colored like in other activities?
The toolbar is using bitmapped icons, so recoloring is harder. Not impossible though - like, when sharing, the joining buddy's XO icon gets colorized because it uses a vector renderer.
Is there a reason the stop button is not the most right one like in other activities?
The "toolbar toggle" button was added in the last version and it seemed to make most sense on the far right. Might be going to change though - there is a related ticket you could comment on:
http://tracker.squeakland.org/browse/SQ-470
The secondary options of the buttons in the toolbar have different ways of accessing.
- the load from server/save to server is accessed by holding the mouse
button pressed longer
- the share button opens the options after one click
- the store/lager opens other options after one click (the secondary
toolbar has a different layout than the share options)
There are no hover-palettes in Etoys. The long-click to reveal "hidden" save and load options predates Sugar. Same for the Supplies flap, which explains its look. The only new thing is the share button's menu, which was made to look similar to the regular Sugar palettes.
Now that you point it out it does indeed feel inconsistent compared to other activities. A ticket may be in order (though I have no real idea how to solve it).
- Bert -
At Wed, 6 Jan 2010 16:10:28 +0100, Bert Freudenberg wrote:
On 06.01.2010, at 11:54, Simon Schampijer wrote:
Hi,
Some thoughts that came up today - I will turn into bugs or discard after feedback.
Is there a reason the etoys save a copy (keep as) button is not colored like in other activities?
The toolbar is using bitmapped icons, so recoloring is harder. Not impossible though - like, when sharing, the joining buddy's XO icon gets colorized because it uses a vector renderer.
The method:
SugarLibrary>>imageFor:color:grayOutColor:
happily recolors these bitmap icons with alpha.
-- Yoshiki
On 06.01.2010, at 19:13, Yoshiki Ohshima wrote:
At Wed, 6 Jan 2010 16:10:28 +0100, Bert Freudenberg wrote:
On 06.01.2010, at 11:54, Simon Schampijer wrote:
Hi,
Some thoughts that came up today - I will turn into bugs or discard after feedback.
Is there a reason the etoys save a copy (keep as) button is not colored like in other activities?
The toolbar is using bitmapped icons, so recoloring is harder. Not impossible though - like, when sharing, the joining buddy's XO icon gets colorized because it uses a vector renderer.
The method:
SugarLibrary>>imageFor:color:grayOutColor:
happily recolors these bitmap icons with alpha.
I don't think so, because it simply tints the whole image. We'd need to change the outline color independent of the interior color, on a gray background, and with anti-aliasing preserved. Try
(SugarLibrary default imageFor: #keep color: Color red grayOutColor: nil) asMorph openInHand
which results in a reddish icon (using another color for nil seems to make the whole icon red).
- Bert -
At Wed, 6 Jan 2010 21:41:39 +0100, Bert Freudenberg wrote:
On 06.01.2010, at 19:13, Yoshiki Ohshima wrote:
At Wed, 6 Jan 2010 16:10:28 +0100, Bert Freudenberg wrote:
On 06.01.2010, at 11:54, Simon Schampijer wrote:
Hi,
Some thoughts that came up today - I will turn into bugs or discard after feedback.
Is there a reason the etoys save a copy (keep as) button is not colored like in other activities?
The toolbar is using bitmapped icons, so recoloring is harder. Not impossible though - like, when sharing, the joining buddy's XO icon gets colorized because it uses a vector renderer.
The method:
SugarLibrary>>imageFor:color:grayOutColor:
happily recolors these bitmap icons with alpha.
I don't think so, because it simply tints the whole image. We'd need to change the outline color independent of the interior color, on a gray background, and with anti-aliasing preserved. Try
(SugarLibrary default imageFor: #keep color: Color red grayOutColor: nil) asMorph openInHand
which results in a reddish icon (using another color for nil seems to make the whole icon red).
Well, I should have actually looked at the problem before writing random emails...
-- Yoshiki
Folks, I have encountered this problem before. There is a bitmap with an icon blended into it with anti-aliasing. I want to change the color of the icon. Just changing the color in place leaves an edge of the old color where the anti-aliased blending was before. The original bitmap was made from layers using an app like photoshop. We need to preserve the layers. I propose that somewhere on the web we keep the original layers as separate bitmaps. Perhaps the bitmap inside Squeak could have a good name. Using the name and Google, one could easily find the files for the layers. A programmer can go get the layers, and re-compose them into a new bitmap with different colors. We need a convention for naming the layers folder, so Google can find it. Something like (Squeak Etoys ToolBarSave icon layers).
--Ted.
On 06.01.2010, at 22:25, Ted Kaehler wrote:
Folks, I have encountered this problem before. There is a bitmap with an icon blended into it with anti-aliasing. I want to change the color of the icon. Just changing the color in place leaves an edge of the old color where the anti-aliased blending was before. The original bitmap was made from layers using an app like photoshop. We need to preserve the layers. I propose that somewhere on the web we keep the original layers as separate bitmaps. Perhaps the bitmap inside Squeak could have a good name. Using the name and Google, one could easily find the files for the layers. A programmer can go get the layers, and re-compose them into a new bitmap with different colors. We need a convention for naming the layers folder, so Google can find it. Something like (Squeak Etoys ToolBarSave icon layers).
--Ted.
Why not use the original vector art icons just like for the XO icon?
(OLPCSupport xoCharacterWithHeight: 40 insideColor: Color green outsideColor: Color red) asMorph openInHand
Sugar's icons are SVGs. I can't quite remember how we converted that to Flash for import in Etoys. Maybe some Adobe tool. But we did it before.
Either way is fine of course. And not having the "keep" icon colorized is certainly not a blocker ;)
- Bert -
On Wednesday 06 January 2010 08:40:28 pm Bert Freudenberg wrote:
There are no hover-palettes in Etoys. The long-click to reveal "hidden" save and load options predates Sugar. Same for the Supplies flap, which explains its look. The only new thing is the share button's menu, which was made to look similar to the regular Sugar palettes.
Now that you point it out it does indeed feel inconsistent compared to other activities. A ticket may be in order (though I have no real idea how to solve it).
Icon space along the top is precious and there is no need to waste two slots just for projects. A single Gallery icon should be sufficient. It should open out to a catalog into which a project label (or its name tile) could be dropped or dragged out.
One of the patterns I see frequently with school kids new to Etoys is the nesting of new projects. i.e. a new project would be started within the currently saved project and so on. They would skip pressing the "previous" button to close the current project before starting a new one. Why is a project not "closed" when it is "put back" into storage? A mismatch between cognitive models used by children and programmers.
Children understand the difference between a thing and its label very well. So we could have Labels and LabelMorphs for off-image stuff like projects, sound, pictures, video and have them store an URI. The tabs can show default folder, clipboard and knownServers and the labels can be created on the fly. When the label is dragged into the current world for viewing or editing, the URIs are resolved into physical locations and the object is loaded into the image. When the label (or a projects name tile) is dropped back into the catalog, updates (if any) are flushed to the physical store.
Yoshiki pointed out that generating labels on the fly is slow when a folder contains hundreds of objects. We can tackle this using paged views with each page containing only ten or so entries.
Subbu
etoys-dev@lists.squeakfoundation.org