Discussion:
[Tuxpaint-devel] TuxPaint UI: Undo/Redo Icon. Tools icons.
Ivan Alekseev
2009-08-31 07:34:45 UTC
Permalink
Hi all!

Sorry if something wrong, this is my first post to TuxPaint Dev. list
I have some ideas for TuxPaint emprovement. Let me start from simple
things.

1. Undo/Redo icons.
I think that tools icons needs changes, let me present my version of Undo /
Redo icons. What do you think about it?
[image: Png_0001.png]

Also TuxPaint icons can be just little corrected (just repaint it). But
Undo/Redo icons must show direction of action (Backward / Forward).
[image: undo-redo.jpg]


2. Tools icon titles.
I think that text under most of tools is junk. Just for problems with
localisation and fonts.
Good icons are understandable (clear) without any text.
[image: Png_0009.png][image: Png_0010.png]



3. I think that icons should be able to be colorful.

-----
Ivan Alekseev
Albert Cahalan
2009-08-31 19:05:46 UTC
Permalink
Post by Ivan Alekseev
1. Undo/Redo icons.
I think that tools icons needs changes, let me present my version of Undo /
Redo icons. What do you think about it?
Also TuxPaint icons can be just little corrected (just repaint it). But
Undo/Redo icons must show direction of action (Backward / Forward).
You equate "backward" with undo, but not everybody does.

Really we should do gettext("someicon.png") for all of these.
Undo can then be the thumb, backwards arrow, forwards arrow,
clockwise arrow, counterclockwise arrow, X, etc.
Post by Ivan Alekseev
2. Tools icon titles.
I think that text under most of tools is junk. Just for problems with
localisation and fonts.
Good icons are understandable (clear) without any text.
The point is that kids need to learn the words.
Post by Ivan Alekseev
3. I think that icons should be able to be colorful.
This is trouble. It reduces consistency.
Ivan Alekseev
2009-08-31 19:31:33 UTC
Permalink
Post by Albert Cahalan
You equate "backward" with undo, but not everybody does.
I'll think about it.
Post by Albert Cahalan
Really we should do gettext("someicon.png") for all of these.
Undo can then be the thumb, backwards arrow, forwards arrow,
clockwise arrow, counterclockwise arrow, X, etc.
You mean themed (skined) icons?
So TuxPaint can be just a base code for any UI, so UI protocol needed.
Or TuxPaint will be just one product with just one UI? Or one product with
many skins?
There are three different ways. Which one is?
Post by Albert Cahalan
The point is that kids need to learn the words.
So font is too small for young kinds, and too junk for older kids. I think
so.
Bill Kendrick
2009-08-31 19:45:38 UTC
Permalink
Post by Albert Cahalan
You equate "backward" with undo, but not everybody does.
I'll think about it.
One of the problem with the thumbs-up and thumbs-down icons is that
some hand signs are offensive in some cultures. Also, while
thumbs-up (yes, good job, I agree, etc.) and thumbs-down (no, I don't want
that, failure) are common in MY culture, they aren't obvious in others.

So I agree with Albert that we need to make it easy to localize these.
(I don't think I had thought about using gettext() for that...)


<snip>
Post by Albert Cahalan
So TuxPaint can be just a base code for any UI, so UI protocol needed.
Or TuxPaint will be just one product with just one UI? Or one product with
many skins?
There are three different ways. Which one is?
In the end, I want to support themes, mostly for accessibility reasons
(larger buttons and text, high contrast themes, etc.)

-bill!
Albert Cahalan
2009-09-01 09:51:04 UTC
Permalink
Post by Bill Kendrick
Post by Albert Cahalan
You equate "backward" with undo, but not everybody does.
I'll think about it.
One of the problem with the thumbs-up and thumbs-down icons is that
some hand signs are offensive in some cultures. Also, while
thumbs-up (yes, good job, I agree, etc.) and thumbs-down (no, I don't want
that, failure) are common in MY culture, they aren't obvious in others.
Of course, there is something to be said for encouraging cultural
unification. Especially if other people adopt my culture. :-)
Post by Bill Kendrick
In the end, I want to support themes, mostly for accessibility reasons
(larger buttons and text, high contrast themes, etc.)
I think it's way more maintainable to make things adjustable in other
ways. Remember that the buttons are still sized for a 640x480 display.
They were huge until we cranked up the screen resolution.

I'd wanted to scale the buttons, but the rest was hard enough to do!

As a first step toward that, I suggest making the icons get scaled when
Tux Paint starts up. The second step is to scale up the *.png files.
(then, as desired, rework the ones that look pixelated at large sizes)
Finally we can add the code to scale the UI. Probably it should scale
like the default stamp sizes do.

Other things that may need scaling: stamp outline stiple, default and
minimum font sizes, the **saved** starter thumbnails (performance),
the mouse pointers, the brick sizes, various other magic tools, etc.
Albert Cahalan
2009-09-01 09:36:36 UTC
Permalink
Post by Ivan Alekseev
Post by Albert Cahalan
Really we should do gettext("someicon.png") for all of these.
Undo can then be the thumb, backwards arrow, forwards arrow,
clockwise arrow, counterclockwise arrow, X, etc.
You mean themed (skined) icons?
So TuxPaint can be just a base code for any UI, so UI protocol needed.
Or TuxPaint will be just one product with just one UI? Or one product with
many skins?
There are three different ways. Which one is?
I mean localized. It's theming according to country/language.
We adjust much more than just the text. For example, the
whole interface is left-right swapped for some languages.
Post by Ivan Alekseev
Post by Albert Cahalan
The point is that kids need to learn the words.
So font is too small for young kinds, and too junk for
older kids. I think so.
It's a bit blurry because it's rendered to an almost-correct
size and then crudely scaled to fit.

Ideally we'd render directly to to required size. Pixel-perfect
sizing can be had with a binary search or, better, a search
that uses an initial rendering to make a size estimate.

Next best would be rendering at least 4x to 5x taller than the
final result. Perhaps linear scaling should be used instead of
the box-filter scaling we currently use. (Note: cubic is awful
for text)
Loading...