headers
matt.price | 1 Jan 03:49
Picon
Picon
Favicon
Gravatar

Re: OLPC emulation


(on va cation w/out broadband, so quickly):

Quoting Bernardo Innocenti <bernie <at> codewiz.org>:

> Matt Price wrote:
>
>> i would definitely advise against trying to use the standard emulation
>> images, as they take some work to get running.
>
> I'm interested in helping fix such problems.  Please,
> file bugs for major problems you've experienced and
> assign them to me.  Even better, submit patches.
>
> I'll try to allocate a small portion of my time on making
> our emulation experience better.

the issues i had in ubuntu were more about qe3mu/kqemu aqnd vmware.   
each took some work to get running, and while qemu images probably rna  
pretty well, everything was just easier using jhbuild.  vmware iirc,  
had trouble reading the image file even after conversion to vmdk format.

when i get back i'll try to see whether a bug is worth filing.  thx  
for the goodwill.

matt

>
> --
>  \___/
(Continue reading)

Permalink | Reply | 0 comments |
headers
drew einhorn | 1 Jan 19:34
Picon

Sugar on conventional laptops and desktops

XO laptops are a scarce resource.  Probably I should have dug
deeper into my pocket for several hundred more dollars and
bought a few more G1G1 laptops when I had the chance.  But
it's too late now.

We have more folks who would like to participate in our learning
community than we have XOs.

There are several techniques for running sugar on desktops, but
they are based on the needs of developers.  They tend to result in
stale bleeding versions of sugar and the activities.  My guess is
that there are many other folks in the G1G1 community, like me
who need/want to run stable versions of sugar and the activities.
Ship.2 or soon Update.1.

This does match one use case for the LiveCD that is currently low
on the official OLPC agenda.

  It is also possible to use this type of LiveCD to create a "virtual
Sugar lab"
  for a school, where a traditional computer lab's computers are booted into
  a Sugar environment, storing their data on a networked or other storage
  device, without changing the lab's installed software.

What is the best approach for the short term?

Is there a Ship.2 LiveCD image.  So far, all I have found are bleeding
edge unstable images, or worse yet stale, bleeding edge images,
all the instablility, and out of date, too.
(Continue reading)

Permalink | Reply | 2 comments |
headers
dthornburg | 1 Jan 19:58
Picon
Favicon
Gravatar

Re: Sugar on conventional laptops and desktops

Dear Drew,

You are on the mark!  Sugar has rich potential independent of the OLPC.  As one of the first 25 people at Xerox PARC in the 1970's I was there when the "desktop" metaphor was developed.  Since Xerox is the "document" company, there is little surprise that the desktop metaphor is document centric.  Some of us who cared about kids also thought about other interfaces.  Alan Kay surely falls into this category and his lengthy devotion to Smalltalkish environments attests to his dedication.

What I like about Sugar is that it is (like many kids) verb-centric, not noun-centric.  I'm currently developing a conference presentation on this topic and want to give (good) live CD's to all attendants so they can experience Sugar themselves on whatever hardware they have.  I haven't experimented with the Xubuntu version yet, but will look at it in the next day or so.

The fact is that, at long last, Sugar provides an opportunity for Seymour Papert's visions to reach critical mass.  The hardware used should not be an issue.

Warm regards,

David Thornburg, PhD


-----Original Message-----
From: drew einhorn <drew.einhorn <at> gmail.com>
To: Sugar List <Sugar <at> laptop.org>
Sent: Tue, 1 Jan 2008 12:34 pm
Subject: [sugar] Sugar on conventional laptops and desktops

XO laptops are a scarce resource. Probably I should have dug
deeper into my pocket for several hundred more dollars and
bought a few more G1G1 laptops when I had the chance. But
it's too late now.

We have more folks who would like to participate in our learning
community than we have XOs.

There are several techniques for running sugar on desktops, but
they are based on the needs of developers. They tend to result in
stale bleeding versions of sugar and the activities. My guess is
that there are many other folks in the G1G1 community, like me
who need/want to run stable versions of sugar and the activities.
Ship.2 or soon Update.1.

This does match one use case for the LiveCD that is currently low
on the official OLPC agenda.

It is also possible to use this type of LiveCD to create a "virtual
Sugar lab"
for a school, where a traditional computer lab's computers are booted into
a Sugar environment, storing their data on a networked or other storage
device, without changing the lab's installed software.

What is the best approach for the short term?

Is there a Ship.2 LiveCD image. So far, all I have found are bleeding
edge unstable images, or worse yet stale, bleeding edge images,
all the instablility, and out of date, too.

A long time ago, not long after PyCon 2007 I built sugar once on a Fedora
Core N box using jbuild. I don't remember what N was. It was fragile and
the activities were not yet useful. When I tried again, git retrieved newer,
broken, bleeding edge versions of the dependencies from the head of the
development trees, and I never got it working again. I assume this has
gotten better since then, but I expect it will still be problematic getting a
good version (for most G1G1 participants) using jhbuild.

Stable Ship.2 or Update.1 images would be great. But as
Matt Price points out getting the working VMware/QEMU, etc.
infrastructure is a challenge that may be too much for most G1G1
participants.

Probably the best solution for G1G1 folks would be stable versions of
packages from jani's personal archive matching Ship.2, Update.1, etc.
It would be even better if there were .rpm versions of these
repositories for folks not on debian based distributions.

Before I put too much effort in finding my own solution to these problems,
I need to be sure I'm not heading off in the wrong direction.

--
Drew Einhorn
_______________________________________________
Sugar mailing list
Sugar <at> lists.laptop.org
http://lists.laptop.org/listinfo/sugar
More new features than ever. Check out the new AOL Mail!
_______________________________________________
Sugar mailing list
Sugar <at> lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Permalink | Reply | 0 comments |
headers
Eben Eliason | 2 Jan 17:25
Picon

Re: Sugar UI design and Tux Paint

> 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
Permalink | Reply | 1 comment |
headers
Jim Gettys | 2 Jan 17:27
Favicon
Gravatar

Last update of activities to pick up translations...

Per the http://dev.laptop.org/roadmap, today is the last day to update
activities in joyride to pick up translations.  You should not be making
other changes (other than blocker bug fixes and fixes we've reviewed and
approved) while doing these updates.

When you have tested your activities in joyride, please ask for approval
for update.1 to include them in the update.1 builds.
                         Thank you all for your hard work!
                                      - Jim Gettys

--

-- 
Jim Gettys
One Laptop Per Child
Permalink | Reply | 0 comments |
headers
Albert Cahalan | 2 Jan 20:54
Picon

Re: Sugar UI design and Tux Paint

On Jan 2, 2008 11:25 AM, Eben Eliason <eben.eliason <at> gmail.com> wrote:
> > 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.

Heh. If porting were that trivial...

Please try Tux Paint. Save a few drawings. Now load one.
Notice that Tux Paint always starts up with the last drawing.
That's the user experience I want to keep, because it's
wonderful for kids. Even if I didn't want to keep that, there
is a great big pile of code behind it.

BTW, so far nobody has even provided example code for
the raw D-BUS calls 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.

The metadata includes a thumbnail image and a text file
to associate the image with a "starter image". A starter
image provides an immutable background and foreground.
For example, there is a beach scene with palm trees in
the foreground. There is a coral reef scene that has a part
of the reef in the foreground; one can place fish that peek
out from behind it.

In any case, I have lots of existing code to deal with.
I can put the data in one file: tar, cpio, ar, or pax?

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

Being "lightweight" is being stripped bare. Tux Paint is meant
for low-end hardware like the XO, barely. Kids love the stamps,
the stereo sound, undo, etc. Put a kid in front of it and watch.

If I had more RAM, then I would try to use it for better quality.
Tux Paint isn't meant to be just another MS Paint clone.

Note that Sugar itself consumes much of the RAM. Less than
half of the RAM is available for activities, and this is shrinking.

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

Nice, but I need to make things better ASAP.

> > 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 can't see this ever working OK. It reminds me of my gmail
inbox, which is a 6094-message disaster despite my efforts
to delete the spam and other useless junk. The fundamental
problems are very journal-like: slow interaction, poor support
for directories, and lots of incoming junk.

Drawings really should be separate from camera pictures.
They are used in different contexts, in different ways, etc.

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

I know. It's rotten. The current behavior is terrible though.
My test subject was constantly invoking the frame, even
after switching to a real mouse. She ended up launching
lots of other activities by mistake. Eventually the system
would run out of memory and kill the program she'd started
with, making her lose all her work.

Maybe I'll do a "lock out the frame" button.

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

There is a frame key.

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

I can go for "high ceiling". At some point one needs to
switch to the gimp. Currently this means ditching Sugar
because the gimp is strongly multi-window. (eh, it looks
like Sugar itself has a low ceiling)

> If a
> class wants to make a webpage, it goes without saying that they might
> need images of various sizes.

For some values of "need"...

img src=foo.png height=55 width=40

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

Assuming automatic zoom-to-fit, then something similar to
the rectangle tool could work for getting a smaller canvas.
Kids will tend to do this by mistake though, then wonder why
the drawing is so coarse and ugly. This probably makes the
feature undesirable.

> 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

"type in specific dimensions" means knowing numbers.

I'm not sure where the "gray background" is supposed to go.
Tux Paint has no dead space on the screen for that. The canvas
is always a perfect fit, zoomed 100%, without scroll bars or
slack space.

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

Paste is also difficult for kids. It involves hidden state.
Permalink | Reply | 0 comments |
headers
Michael Stone | 2 Jan 21:06
Favicon
Gravatar

API Change Notification: Moving Rainbow's Spool - #5033

Dear Everyone,

This email is a notification that we would like to make an API change in
order to make activity data persist across updates (#5033). The API
change consists of moving '/activities' to '/security/1/activities'.

I will send a second email when the changes begin to be committed into
builds and a third email when we believe that they are working
correctly. 

I would like to begin commiting changes tomorrow on Jan. 4. Please
respond if you will be adversely impacted by this change.

Best,

Michael
Permalink | Reply | 1 comment |
headers
Mikus Grinbergs | 2 Jan 23:50
Favicon

Re: Sugar UI design and Tux Paint

Eben Eliason wrote:
> 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 be a problem.

Let me suggest this as a good candidate for the sugar-control-panel.

I'm a geek, not a child.  So far, on my G1G1 system, I've spent the 
majority of the time on text-mode things.  And just about the first 
customization I did to my system was editing eventarea.py to comment 
out frame invocation at the corners.

The problem is that some applications show significant information 
(e.g., the command line, or the "menu bar") very near the corner. 
If I am moving the cursor in the vicinity of those, and happen to 
"overshoot", part of my application is overlaid by the frame.  I 
must explicitly move the cursor back a ways, to get focus in my 
application again.  Very soon this becomes tiresome.

With a specifiable delay parameter (default can be zero, to keep the 
current behavior), I can defer the "interruption caused by invoking 
the frame" for those occasions when such interruption is wanted.

mikus
Permalink | Reply | 3 comments |
headers
Mikus Grinbergs | 3 Jan 01:32
Favicon

Sugar UI design - text copy/paste within Terminal

I am used to working on a different operating system (OS/2), where I 
have a hypervisor-like capability to copy text from many different 
kinds of fields, *without* requiring the participation of the 
application which is displaying that text.  I feel that if it were 
the Sugar UI (rather than the individual Activities themselves) 
which provided __universal__ 'copy' and 'paste' services, using the 
OLPC laptop would be easier to learn, and more predictable.

My reason for saying this is that so far, I have not figured out a 
way to 'copy' and 'paste' in Terminal.  In particular, though the 
wiki describes CTRL-C as the way to copy a current selection to the 
clipboard, all too often CTRL-C results instead in terminating 
whichever command is currently being run from the command line in 
Terminal.

I realize that the OLPC design philosophy is to simplify the UI 
(e.g., no double click).  So I do not know an acceptable way ('grab' 
key, perhaps) to activate a facility_above_the_Activity_level (OS/2 
uses a right_mouse_button_click).  But it sure would be nice if in 
Terminal, text output from 'find' could be copied, and subsequently 
pasted into the command line.  [Such a facility *is* available for a 
Linux console window.]

mikus
Permalink | Reply | 8 comments |
headers
Sameer Verma | 3 Jan 02:44

Re: Sugar UI design - text copy/paste within Terminal

Mikus Grinbergs wrote:
> I am used to working on a different operating system (OS/2), where I 
> have a hypervisor-like capability to copy text from many different 
> kinds of fields, *without* requiring the participation of the 
> application which is displaying that text.  I feel that if it were 
> the Sugar UI (rather than the individual Activities themselves) 
> which provided __universal__ 'copy' and 'paste' services, using the 
> OLPC laptop would be easier to learn, and more predictable.
>
> My reason for saying this is that so far, I have not figured out a 
> way to 'copy' and 'paste' in Terminal.  In particular, though the 
> wiki describes CTRL-C as the way to copy a current selection to the 
> clipboard, all too often CTRL-C results instead in terminating 
> whichever command is currently being run from the command line in 
> Terminal.
>
>
> I realize that the OLPC design philosophy is to simplify the UI 
> (e.g., no double click).  So I do not know an acceptable way ('grab' 
> key, perhaps) to activate a facility_above_the_Activity_level (OS/2 
> uses a right_mouse_button_click).  But it sure would be nice if in 
> Terminal, text output from 'find' could be copied, and subsequently 
> pasted into the command line.  [Such a facility *is* available for a 
> Linux console window.]
>
> mikus
>
> _______________________________________________
> Sugar mailing list
> Sugar <at> lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>   

Hi Mikus,
Copy + Paste doesn't work in Terminal. This is a known bug and has a
ticket for it. http://dev.laptop.org/ticket/5376

Sameer

--

-- 
Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA
http://verma.sfsu.edu/
http://opensource.sfsu.edu/
Permalink | Reply | 6 comments |

Gmane