[sugar] Sugar UI design and Tux Paint

[Eben Eliason]

> Journal integration is an interesting problem. Tux Paint keeps
> some extra per-image data in extra files. I'm thinking that an
> export-to-journal button might be most appropriate.

There is an explicit "keep" button in the activity toolbar to allow
kids to save an object in a particular state.  Other than this, there
shouldn't be any need for custom buttons to interact with the Journal.
 The activity should save implicitly anything it requires to maintain
it's state.  Ideally, this extra data should be kept as metadata on
the image file so that other activities can read the image itself.

> I could use a way to tell Sugar to not start up a second instance.
> I haven't verified that it is safe to run two copies of Tux Paint,
> but even if it is, the laptop is unlikely to have the RAM for it.

This isn't really an option.  The entire Sugar model is based on the
notion of objects as instances activities.  There will be a natural
limit (likely bounded by RAM) to the number of activities that can run
simultaneously on an XO, but this is not something that should be
avoided by making arbitrary special cases for particular activities.
Activities should strive to be as lightweight as possible, and beyond
that Sugar will have to handle the situation when "things fill up".

> Shutdown tends to have the usual trouble. Tux Paint makes this
> highly configurable. I had two dialog boxes. I got rid of one by
> configuring Tux Paint to save on exit, but I'm really not comfortable
> with saving random junk that the user will just have to delete.

This will improve with time in the Journal, as we add better support
for starred entries with filters on the Journal to show only those
which are starred, and once we introduce the notion of temporal
falloff and versions.  We'll re-examine how much of this type of
management is really required by the user once those features have
been integrated.

> The other asks if the user should overwrite or make a new file.
> Never minding the wisdom of such dialog boxes, Sugar is defective
> to not allow for it. (one sees the problem in SimCity too, etc.)

This is a non-issue once differential versions are part of the
Journal, which is the assumption that the entire model was designed
on.  While I understand the need for it, and the concern for the
current behavior, I think that Sugar is doing a reasonable job for now
until versions are integrated.  If I have a drawing (in real life) and
pour some paint on top of it, then I can't get my old drawing back.
To do that, I would first make a copy of the drawing and then paint on
one of them, which is how it can be handled in the UI for now.

> I'm strongly tempted to configure Tux Paint to grab the screen.
> That frame is horribly easy to invoke.

Here again you're discussing the possibility of overriding Sugar
behavior, eliminating consistency across the UI and activities.  These
kinds of problems are things that should be entered in tickets, or
discussed on lists so we can find a general solution.  When particular
activities try to "work around" Sugar no one really benefits.  I think
that a very slight delay on the corner activation might be an ok
decision to prevent accidental invocation of the frame if it proves to
be a problem.

> We're still searching for a mark-move, mark-copy, cut-paste, and/or
> copy-paste interface that little kids can deal with. One idea is to
> have something like the gimp's quickmask mode on one button, and a
> stamp on the button next to it. Another idea would be to select via
> flood-fill on non-background pixels. It's a really hard problem
> because Tux Paint tries to support a bright 2-year-old or regular
> 4-year-old.
>
> So far, we haven't really considered supporting canvas sizes other
> than the one that fills the screen. Do people think that matters?
> I don't know of any reasonable way for a tiny kid to deal with
> scrolling and zooming.

In the interest of "no ceiling" I think this will be important.  If a
class wants to make a webpage, it goes without saying that they might
need images of various sizes.  This doesn't mean, of course, that it
has to be a prominent feature.  A single button for changing the
canvas size could suffice.  You wouldn't even have to offer the
parameters when a new object  is made if you want to keep things
simple for the base case.  If people need and want the feature, it can
be found.

Alternatively, you could create a visual mechanism for creating the
starting canvas size.  Perhaps by showing the white canvas on a gray
background with transformation handles and editable "height" and
"width" labels the child could type in specific dimensions or drag the
edges of the canvas to set it up visually (always "zooming" so that
the entire canvas is visible, for visualizing proportion of height to
width).  With this approach, the use of any tool other than the canvas
transform handle would lock in the current canvas size for the
document.  This would make the decision about the size similar to
choosing a sheet of paper to draw on, eliminating the complications
that come with adjusting the canvas of an existing image. (A crop tool
may still be useful. This again is a natural metaphor for cutting the
edges of the paper off; the inverse can be accomplished by creating a
brand new canvas of a larger size and then pasting all or part of the
previous image into it, eliminating the need for a "change canvas
size" button.)

- Eben