[Sugar-devel] journal concerns (was Re: Planning for Weds - Tux Paint, Conozco Uruguay, Memorize with Speak)

[Albert Cahalan]

On Tue, Jul 21, 2009 at 4:32 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> On Tue, Jul 21, 2009 at 09:07, Albert Cahalan<acahalan at gmail.com> wrote:

>> Last I checked, the Journal interface...
>>
>> a. required piles of custom D-BUS code (very painful to do)
>
> This hasn't been a problem for other developers.

Yes it has been. A few (?) developers succeeded.
Everything else is a Python script.

I'm only aware of Etoys in fact. Any others?

Really, I don't see why there isn't a *.so file supplied
in /usr/lib that could be used via dlopen().

>> c. would make the kid-friendly picture browser impossible
>
> How so?

OK, here is what I need:

Tux Paint gets a list of all Tux Paint images. For each one,
it opens the thumbnail. It displays **all** thumbnails for the
user, as large buttons in a scrollable grid. If a thumbnail does
not exist, Tux Paint will open the main file and create a
new thumbnail.

The user may choose to delete an image. Tux Paint does so.

The user may load an image. Tux Paint then must deal with
the previously loaded image. It may be saved over an old copy,
saved as a new copy, or thrown away. After doing so, the
requested image gets loaded.

(BTW, that choice is also offered elsewhere in the UI. It's given
when the user hits the "New" button to get a fresh start. It's
given when Tux Paint exits.)

There is also a slideshow feature. The kid selects images
from the visual selector, then hits the "Play" button. This isn't
going to work at all with selection via the journal.

Not that this works now, but on the laptops with both Sugar
and GNOME there should be exactly one Tux Paint sandbox.
Images shouldn't be held hostage in one environment.

>> d. would cause performance-sucking data copies
>
> Doesn't seem to be a problem for Paint, in which way is TuxPaint more
> exigent performance-wise?

There is a visual file selector, so numerous images may need
to be loaded. Giving this up would have a usability impact.

Stopping and restarting Tux Paint in order to load a new file
would be painful. Despite optimization effort, Tux Paint will
never be fast-starting. (OK, it beats many Python things, but
we still get bothered by the start-up delay) The built-in file
selector can be somewhat fast; it does not need to load up
all the fonts and sounds again.

> If you are able to name drawings in the TuxPaint's sandbox,
> then you are also able to do so in the journal entries.

In the normal sandbox, there is little need for names. One of
the nice things about a paint program is that large thumbnails
do a pretty good job. We use 232x152 for a normal 1200x900;
perhaps we'd like to increase that for the XO. Is there some
way for the journal to deliver this? 320x240 could be nice.