SarynPaint: a Java program packaged for the OLPC

[Ben Wiley Sittler]

Hi, and thanks for trying it out!

On 2009-08-29, Mikus Grinbergs <mikus at bga.com> wrote:
>> I haven't been able to test that .xo link on an actual OLPC yet, so
>> feel free to pass along bug reports, experiences, etc.
>
> These days I'm running F11-on-XO1 on my XO-1s -- SarynPaint launches
> and runs on both my smparrish build os6 and on my mtd build soasxo59.

Neat! I keep meaning to try that, and in fact this post just inspired
to me to buy a big SDHC card to dual-boot a "regular" Linux distro
from.

> It shows that "just checked in minimal support for launching it from
> Sugar" - when I call up Frame, and (while SarynPaint is in Move
> mode) navigate along the "screen edges" on which Frame shows its
> facilities, what continues to respond is SarynPaint itself.  For
> "Sugar usability", an .xo ought to disregard user inputs directed to
> Sugar.  Also, the log created by SarynPaint would currently be
> unhelpful in case of trying to debug the Activity's own actions.

When I tried it on my daughter's XO the frame was not visible (at
least not by mousing to the screen border.) Is that what you see too?

Obviously the program was originally not written for Sugar, and
purposefully goes full-screen and hopes the window manager respects
that and does not interfere. Use the ESC key to exit. I realize that
this is not at all proper Sugar UI, and would be better described as
"full-screen X11 app launched from Sugar". I think, though, that it
might be better for early hand-eye coordination to not have a
distracting Frame at all.

However, I can see the argument for consistency and if someone would
like to improve the Sugar integration I'm happy to take patches.

> Did not have my external speakers hooked up - the voices were kinda
> faint.  At the very beginning, the cursor had to be pre-positioned
> on the SarynPaint screen, in order to avoid the explanation text
> from vanishing before it could be read (in soasxo59 the explanation
> text vanished despite me trying to prevent that).

I noticed this bug (on other systems, too!) and plan to track it down
and fix it when I have a moment.

> On my systems, feedback to the user via voice is not always
> consistent.  Sometimes the control-press (e.g., <enter>) is not
> picked up [silence indicates I need to repeat the mode change].
> Other times the control-press does get picked up, but I hear no
> output [silence indicates I don't need to repeat the mode change].

Thanks! I also noticed this bug (on other systems, too!) and plan to
track it down and fix it when I have a moment; I'm not sure, though,
when I'll get to it. As usual, patches gladly accepted  :)

Thank you again for the bug reports and ideas, and thanks for trying it out!
-Ben