[Sugar-devel] Sugar-devel Digest, Vol 9, Issue 136

[Jim Simmons]

Albert,

It is possible to work with the Journal entries in the way you want
to.  I've only done this in Python, in the View Slides Activity, but
it could be done other ways too I'm sure.

In View Slides I open a table that lists out all of the image files in
the Journal (which includes the Journal proper as well as anything on
USB and SD cards).  I only list files by name but I certainly could
have created thumbnails for each one if I wanted to.  The GTK tree
view component supports this.  I could also have created a slide show
using Journal entries.  One of the python examples in Pippy does just
that.  You can create an entry in the Journal and open another entry
without closing the Activity and resuming too.  For instance, in one
Read Etexts session you can download ten books and each one gets its
own Journal entry with a meaningful name.

You should be able to do anything with a Journal entry that you can do
with a file.

James Simmons

> 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.