<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I haven't used the ds_backup.py as released, but AFIK rsync uses the
-d flag which deletes objects from the backup if they have been
deleted in the Journal.<br>
While it does make multiple snapshots, AFIK, the restore mechanism
does not support using them for versioning. I don't believe there
are any changes in the XSCE implementation form XS-6.<br>
<br>
Tony <br>
<br>
<div class="moz-cite-prefix">On 02/22/2016 07:56 AM, Samuel
Greenfeld wrote:<br>
</div>
<blockquote
cite="mid:CA+cAqjO5AHDX8HQYMnR5dSfoUhZCLoSXm5zbJL0WRs67zmRYmw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Just for the record:<br>
<br>
</div>
The XO laptop backup mechanism for Sugar creates separate
"datastore-YYYY-MM-DD_HH:MM" directories for each backup.<br>
<br>
</div>
<div>If I recall correctly, the schoolserver also periodically
looks through these backups, hardlinks identical items to
save space, and prunes backups beyond a set age.<br>
</div>
<div><br>
</div>
I wouldn't be against fixing and/or redesigning XO backup
& restore, but at least on an XS schoolserver these
already are versioned.<br>
<br>
</div>
I have not tried XSCE to see how it handles things.<br>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Feb 20, 2016 at 9:40 PM, Tony
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi, Sam <br>
<br>
Thanks for your comments. These issues need review and
comment within the community.<span class=""><br>
<br>
<div>"Just my 2c, but this complicates the experience a
lot. Do we show this temp journal entry to the user?
If so, wouldn't that be confusing? But it we hide it,
it becomes more complex. Eg, a user is adding the
finishing touches to a diagram in Paint, and adds it
to Write activity, however since only the old version
is visible they don't see the image they expected, and
become confused. Maybe this could be better served by
basic git features in the journal, one of Martin's
project ideas I believe."<br>
</div>
</span>
<div> <br>
What I suggest does not change the user's experience of
the Journal. <br>
<br>
When an activity is launched, it runs as activity.py. If
an activity is resumed (associated with a data file in
the Journal), activity.py loads that Journal object.
This is the object that is saved when the activity
terminates. What I am suggesting is that <br>
activity.py should load a copy of the Journal object
(which naturally does not exist in the Journal until
saved). This enables the activity to make a decision to
<br>
overwrite the original object or to save a new object. <br>
<br>
You may have noticed this in the Journal. When you
resume and then save, that object is now the most recent
and no longer appears in its original chronological
position. This reflects that the original journal object
is saved back to the Journal (normally, by write_file)<br>
<br>
The scenario you describe: using Paint and then saving
to Write is intermediated by the Journal. Paint saves
the modified image to the Journal. The Write activity
then adds it to its document. There should be no
confusion. Assuming the user gave the image a new name,
causing a new object to be saved or the user saved in
the same name, replacing the object in the Journal. If
the user has doubt, as at present, he/she should run
Image Viewer to see the image.<br>
<br>
I really don't see git as relevant to the Journal. The
proven technique of using file names to distinguish
objects is easier to implement and familiar to
experienced computer users. There is nothing to prevent
a user from using classproject.1, classproject.2, ....
to distinguish versions.<span class=""><br>
<br>
"Browse save files work fine cross network
connections. I made one at home, and opening it at
school I was able to show people all of my tabs."<br>
<br>
</span> This worked because in both cases you are
connected to the internet. Browse is saving urls. Had
you opened Browse without a connection, you would have
received an error. In last year's GSOC, Richa Sehgal
added a capability to save an html page explicitly but
this capability has not yet been integrated with Browse.<br>
</div>
<span class=""> <br>
"Using the metadata is also much harder, it is so easy
to just chuck the json in there. Even if we use
metadata for eg, saving memorize, the metadata will be
so activity specific that it is hard to use in a
reflection tool. I'm not sure what you want by this."<br>
<br>
</span> I am trying to distinguish saving documents from
saving state. Memorize needs to save state so that a user
can resume a game. Naturally, state information is
specific to the activity. However, it can be saved in the
metadata record (saved in the Journal as a file). When
resumed, Memorize can restore its state. Saving the state
information as a document requires that it have a
mime_type. This type would need to be unique to Memorize
since no other activity would know how to process it (e.g.
if it were saved as application/plain-text).<br>
<br>
As I understand reflection, the goal is to enable a user
to look back at documents they created or worked on
collaboratively. The Journal offers two impediments to
that - clutter from non document-creating activities and
the necessity to erase documents due to limited storage
capacity. I think we need to distinguish between
statistical analysis of a user's activities (the NSA use
of metadata) and using the Journal to show the user a
record of their own educational journey.<span class=""><br>
<br>
<div><br>
</div>
"I have to agree with you here. Having a kind of
seamless journal that exists partially locally and fully
on the school server would be nice. But can a person
designing this amuse that the user will have school
server access most of the time?"<br>
<br>
</span> The design is to invoke a backup service when the
XO connects to the school server. This service recognizes
objects which have been modified or which are new and
saves the associated documents to the server-based store.
Currently, I use a modified ds_backup.py to save to the
/users directory on the school server (by serial number of
the XO). This program operates using datastore as the
input. The suggestion of using OwnCloud would make the
files on the school server visible to the student. <br>
<span class=""> <br>
"How do you it fulfilling that need? Are we exposing
the owncloud web interface to children? I pictured a
seemless journal interface that merged the online
storage and the local into one and provided means for
pinning things locally. I however picture the group
task creating a new type of voulme (or web service) that
allows for seemless sharing, not aiming to provide
backup."<br>
<br>
</span> These are exactly the issues we should tackle as a
community in the Sugar-devel design process. OwnCloud is a
part of current releases of XSCE. Its interface is
controlled by administrator configuration. TK has used
OwnCloud with children in Malaysia. From the user's
perspective, the OwnCloud interface is a link (login) on
the school server.<br>
<br>
Currently, I am using the 'keep' circle for this purpose.
When it is filled, it means a copy of the file is stored
locally. The user can 'fill' the keep icon to request that
a local copy be made (the next time the backup is
executed). The user can clear the keep icon to show that
the backup process can delete the local copy. <br>
If the user 'erases' the Journal object, the backup
process will delete the school server side copy. <br>
<br>
I don't know how sharing can be done seamlessly. The user
needs to 'share' an object. Another user has to perform
some action to add the object to his/her Journal. The user
needs positive control over this process to manage limited
storage. <br>
<span class=""> <br>
"Ah, hating on the home view ux is fun. I was actually
thinking about this a while ago, and wrote a blog post.
I'd like to hear your thoughts as it addresses the same
issue: <a moz-do-not-send="true"
href="https://www.sam.today/blog/sugar-nohomeview-design.html"
target="_blank">https://www.sam.today/blog/sugar-nohomeview-design.html</a>"<br>
<br>
</span> I hate unity on Ubuntu with an abiding passion.
The home view is the face of Sugar. The problem with the
home view is exactly what you point out in your <br>
design document - it now confuses the functions of the
Journal with the function of the Home View (and List
View). This happened when an effort to make more use of
the Journal resulted in making the default of the Home
View to restart the latest execution of an activity. This
confuses the activity with the task. When I launch the
Write activity, I may want to continue editing an existing
document or I may want to create a new one. <br>
<br>
I don't know of any desktop implementation that merges
these two functions. If I own Word, I get a new document
with the option to open an existing document. If I launch
from a file explorer, Word opens that document for
editing. This was the case with Sugar. If an activity was
launched from the Home View, a new document was created.
If the user launched from the Journal (Sugar's file
explorer), that file was opened. <br>
<br>
I am only proposing that the default in the Home View
return to starting new by default. The alt key can then be
used by those who want to resume from the Home View (most
of whom will click on the Journal button and resume from
there).<br>
<br>
We should require documents to be stored under a user
supplied name but much as in most other desktops, this
decision should be required when the document is saved,
not when the activity is opened. In some releases, there
was an 'alert' when an activity was closed. Unfortunately
this alert did not solicit a name, but a description of
the file. It's implementation was a bit aggressive and so
it was subsequently deleted. In the original Sugar, the
user was expected to change the name in the Journal by
changing the entry in the standard toolbar. In the new
toolbar design this field is invisible to the user unless
they click on the activity icon. Changing the name here
should change the name in the Journal. However, with the
current implementation, this is too late. The name change
applies to the object that was opened so that it does not
have the 'save as' ability to create a new document. <br>
<span class=""> <br>
"I will actually be persuing that feature, and the steps
defined on that page as a feature for 0.110. Eventually
it will have a feature page, but it is the "onboard"
branch of <a moz-do-not-send="true"
href="https://github.com/samdroid-apps/%7Bsugar,sugar-artwork,sugar-toolkit-gtk3"
target="_blank">https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3</a>}.
I invite you to test the patches and provide feedback."<br>
<br>
</span> Your idea here is brilliant and addresses a
continuing problem in the OLPC concept. One of the most
insistent and persistent criticisms of OLPC has been <br>
the inadequate training of the teachers in a deployment
and their inability to use the XO effectively. Much of
this results from the practice of having knowledgeable
people from the the gifted side of the digital divide go
to the challenged side to give an introductory workshop
(onboarding). Often the <br>
participants have no 'hard-copy' of the training materials
and so soon forget details of the training or run into
situations not covered. <br>
<br>
I would like the implementation to be 'interpretive' in
nature so specific deployments and members of the
community can devise their own scripts. As you have
pointed out, you are assuming a user who is experienced
with standard computers and their conventions. This is not
the situation in our deployments in the challenged
environments. <br>
<br>
Your scripts indicate a limited set of actions (define a
'hotspot', display a window based on cursor position, take
a subsequent action based on an event). While it will be
extra work, if you analyze the actions in your design
document, you may find that they could be defined by a
small number of parameters (and links to popups). These
could then be documented in a script and executed by a
'onboarding' engine. <br>
<span class=""> <br>
"Sugarizer has a different collab model (some js thing)
to the rest of Sugar. However, SoaS and XO are both
running the same Sugar, with the same collab model
powered by Telepathy. I have use their collaboration
before."<br>
<br>
</span> Sadly, I don't know enough about the technical
issues. In Walter's context, we need a collaboration model
for javascript activities (Sugar-web-activity). This
collaboration model should work also for Sugarizer (As I
understand it, Walter and Lionel have a goal that any
Sugar-web-activity also works in Sugarizer).<br>
Since collab-wrapper is a layer between the underlying
technologies and the user, it would be very valuable if
that same 'api' would work in both the Python and the
Javascript environments. <br>
<span class="HOEnZb"><font color="#888888"> <br>
Tony</font></span>
<div>
<div class="h5"><br>
<br>
<div>On 02/21/2016 05:00 AM, Sam P. wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat, Feb 20, 2016 at 6:00 PM
Tony Anderson <<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net"
target="_blank">tony_anderson@usa.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi,
Walter<br>
<br>
I have some concerns about the proposed GSOC
tasks as well as some ideas for new tasks.<br>
<br>
I agree that the Journal needs rethinking.
Below are my thoughts (re-thoughts?).<br>
<br>
Specifically,<br>
<br>
The Journal is the file system for Sugar. It
does not use directories but instead was
intended to collect objects by tag (a la
Picasa). Currently, the user sees <br>
a scrolled list of objects in chronological
order. However, selection is by activity or
media type, not by a user defined criteria
(as represented in other systems by the
directory). <br>
<br>
The Journal acts as an activity with awkward
consequences for the user. On the keyboard,
the icon for the Journal (a magnifying glass
or search icon - not the icon shown in the
frame) is to the left of the zoom group on
the keyboard and to the right on the frame.
If the Journal is selected, it replaces the
current activity when the activity key is
pressed. It also appears as an activity when
using alt-tab. The first makes using
screenshots awkward. Screenshots are given a
title by the system of 'Screenshot of ....'.
The user needs to switch to the Journal to
provide a meaningful name. However, the user
must open the frame and click on the
activity icon to return to it. If the
Journal were viewed as a Sugar service, the
activity key would return the user to make
another screen shot or continue whatever the
task is. Similarly, it is convenient to
present the user with instructions to
perform a task using a Sugar activity (e.g.
Write). The instructions can be given by a
web page or by a document in a different
activity. For example, a user could show a
flag as an image in Image Viewer and try to
duplicate the flag with TurtleBlocks.
However, using alt-tab to switch between the
activities requires cycling through the
irrelevant Journal activity or open the
frame to click on the activity icon.<br>
<br>
More importantly, when a Journal object is
launched from the Journal activity, it is
immediately loaded into activity.py.
Therefore, any subsequent action by the user
will be saved and the previous object will
be overwritten. Suppose I resume the Paint
Activity to continue making a picture.
However, I decide that after some strokes,
the original picture was better. There is
nothing as a user I can do to revert to the
original. I suspect the reference to git may
be intended to address this problem. When an
object is launched, activity.py should make
a clone. The user should then have the
option to revert to the original or to
overwrite it or to change it's name so that
a new object is created alongside the
original. I believe an implementation of the
'save/save as' logic of virtually all other
systems should be provided.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Just my 2c, but this complicates the
experience a lot. Do we show this temp
journal entry to the user? If so, wouldn't
that be confusing? But it we hide it, it
becomes more complex. Eg, a user is adding
the finishing touches to a diagram in Paint,
and adds it to Write activity, however since
only the old version is visible they don't see
the image they expected, and become confused.
Maybe this could be better served by basic git
features in the journal, one of Martin's
project ideas I believe.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Probably, in the interests of 'reflection'
or possibly statistical data, the Journal
saves every activity instance - by default
with the name of the activity. Further, <br>
most activities now implement write_file to
create a data file associated with the
object. This creates clutter in the Journal
and takes storage for meaningless data
files. For example, the Browse activity
saves a data file containing URLs of open
tabs. Aside from the fact that this creates
spurious error messages if Browse is opened
in a different network environment, it
creates the unnecessary need to save a data
file. I believe that activities should only
save a data file if the user supplies a name
for it and that activities should save state
in the metadata, not in a data file.
Naturally, it may be desirable for Memorize
to save its state so the user can resume the
game - this can be done by a field in the
metadata. However, when the Paint Activity
saves a file, it is reasonable to assume it
contains an image (usable, for example, by
the Image Viewer).<br>
</div>
</blockquote>
<div><br>
</div>
<div>Browse save files work fine cross network
connections. I made one at home, and opening
it at school I was able to show people all of
my tabs.<br>
<br>
</div>
<div>Using the metadata is also much harder, it
is so easy to just chuck the json in there.
Even if we use metadata for eg, saving
memorize, the metadata will be so activity
specific that it is hard to use in a
reflection tool. I'm not sure what you want
by this.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The XO has limited storage capacity. A
freshly installed XO-1 image leaves about
300MB free space. A freshly installed image
on other models with 4GB capacity leaves
1.9GB free space. Today, it is almost
impossible to buy a USB stick with 2GB
storage or less. When the available storage
is less than 50MB, the user sees a modal
dialog saying the Journal is full with the
only option to look at the Journal. The
Journal activity shows the amount of
available storage which could help a user
avoid going below the 50MB limit but is no
help to correct the problem. Currently Sugar
provides no help to the user in dealing with
this problem. Most deployments I am familiar
with reflash the laptop when this happens.
So much for reflection. Essentially this
step erases the user's prior work.<br>
<br>
Journal backup, according to James Cameron,
is beyond the scope of Sugar. The present
Sugar-independent (?!?) scheme was developed
by Martin Langhoff using rsync to create
snapshots on the school server. This was a
bad decision. If a user deletes an object
from the Joural on the XO to create space,
that object is deleted from the backup. The
backup should be considered the actual
repository of Journal entries with
effectively unlimited space and the backup
on the XO should upload new and modified
objects to that repository. Further the user
should have a way to recall data files from
the repository as needed. In general, the
limited storage on the XO should be viewed
as a cache of the users' data kept on the
school server. Consider that OLPC
recommends a minimum of 2GB storage on the
school server (/library/users) per
registered laptop. However, at most, the
user has 1.9GB on the XO (which includes
optional Sugar activities and optional media
and e-book downloads).<br>
</div>
</blockquote>
<div><br>
</div>
<div>I have to agree with you here. Having a
kind of seamless journal that exists partially
locally and fully on the school server would
be nice. But can a person designing this
amuse that the user will have school server
access most of the time?<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The proposed GSOC tasks include statements
such as: "This idea needs more thought and
coding." I believe SugarLabs is responsible
for doing the thought and proposing the
guidelines for implementation. This is not
an appropriate task for a GSOC participant.
One of the obvious problems as a Mentor in
last years GSOC is that the participants had
no experience with or understanding of Sugar
or how it works on an XO. The development
environment gives the developer many
capabilities not available on an XO (fast
gpu, large memory, effectively unlimited
storage, 24/7 high speed (> 1MB/s) access
to the internet, 1080p screen resolution and
aspect ratio). Further, Sugar on the
development environment is not available on
the XO (and vice versa). Asking participants
from this environment to design ui for users
on the other side of the digital divide
requires an unreasonable expectation of
their ability to empathize.<br>
<br>
I would propose these tasks more as follows:<br>
<br>
<dl>
<dt>1. Brief explanation</dt>
</dl>
<dl>
<dd> The Sugar Journal should provide a
'save/save as' interface which should
enable a user to choose whether to save
the current document when an activity is
closed. The interface should require a
name change from 'current.activity' to a
user supplied name. If the document is
derived from one currently saved in the
Journal, the user should be allowed to
save (overwrite) or save as (create new
document) by giving a new name to the
document. This could be accomplished by
showing a modal dialog at close time
requesting the user to supply a name or
not save the document. If the document
has a user supplied name, the dialog
could request the user to save or to
provide a new name to create a new
document. <br>
</dd>
<dd>Note: this approach satisfies the
needs referenced in the git task. Git is
a little like a hammer looking for a
nail. Using git for this function will
likely double the size of the data
stored in the Journal (based on normal
experience using git). Unfortunately, we
don't have this space on the XOs. The
standard <br>
</dd>
<dt>save/save as gives the user the
ability to manage versions by using
unique names.<br>
</dt>
</dl>
<p>2. Brief explanation<br>
The Journal activity is currently
implemented as an activity. It should be
changed to a 'service'. This means the
Journal icon on the frame should be to the
left of the zoom group icons to match the
sequence on the keyboard. The Journal is
always running as a service when the Sugar
is running. It is accessible by the
Journal key on the keyboard and also by
the Journal button in the frame. When the
view is switched to the Journal, clicking
on the activity view (right most key of
the zoom group) should switch the screen
back to the current activity.<br>
</p>
<p>3. Brief explanation<br>
Sugar provides a method to backup
and restore the Journal (one method to a
USB key and one method to the school
server). The Journal also provides a
select box to enable an action to be taken
for all selected objects. This mechanism
should be sufficient for the USB key case.
However, the school server backup
currently is based on taking a snapshot of
the current Journal state. This means the
size of the objects in a user's Journal
cannot exceed the available local store on
an XO (300MB for an XO-1, 1.9GB for other
models). A mechanism is needed to save on
the school server all documents created by
the user and to restore a selected object
to the Journal from the school server.
Since many documents may represent library
objects (e-books, audio, image or video
media), the mechanism should recognize
these and not save them as user documents.
However, the metadata saved should enable
the system to download the library items
again as needed (and, as available). <br>
For example, the mechanism may be to
upload Journal documents to an OwnCloud
repository. The user could then select an
item in the OwnCloud repository to be
downloaded to the Journal. The user could
also share any item in OwnCloud with other
user groups or individuals. <br>
</p>
<p>Note: This would essentially accomplish
the intent of the group/buddy task.
Further, OwnCloud could be provided on a
school server or on the internet. as
appropriate.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>How do you it fulfilling that need? Are we
exposing the owncloud web interface to
children? I pictured a seemless journal
interface that merged the online storage and
the local into one and provided means for
pinning things locally. I however picture the
group task creating a new type of voulme (or
web service) that allows for seemless sharing,
not aiming to provide backup. <br>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p> </p>
<p>4. Brief explanation<br>
One goal of Sugar is to record
information about user sessions. This is
currently accomplished by creating
statistics from the metadata stored in the
Journal.<br>
Unfortunately, a consequence is that the
Journal view fills with essentially
meaningless links to this metadata (mine
fills with Terminal Activity and Log
entries).<br>
This makes it much harder for the user to
identify meaningful Journal objects
(documents, images, items from the
library, ...). A mechanism is needed to
that session data can be logged
independently of the Journal view (i.e not
shown on the screen). This logged
information should be transferred to a
backup repository (e.g. school server or
usb drive) as soon as possible and deleted
from the local store to free up space. The
available reporting activities should be
modified to use this new mechanism.</p>
<p>5. Brief explanation<br>
The Journal icon provides information
the amount of free space in the user's
store. if this amount is less than 50MB, a
dialog is shown requiring the user to
switch to the Journal view and claiming
that the 'Journal is Full'. This message
is, at best, misleading. The available
storage can arise from several causes -
the fact that an activities 'instance'
store was not deleted, the space required
by installed activities, or space required
by data files in /home/olpc/Library, or
data stored by activities in 'data',
'instance' or 'temp'. Currently, Sugar
provides no guidance or help to enable a
user to deal with this problem short of
reflashing the image. The goal of this
task is to provide a quota management
system on storage with a way for the user
(e.g. by a special Sugar activity) to
analyze the usage of storage and to save
by usb key or school server or cloud
storage large or currently unneeded items
and then delete them. The system should
show the user the size of items and
provide updates on how much storage has
been made free by his/her actions.<br>
</p>
<p>6. Brief explanation<br>
In Sugar's Home View, a click on an
activity icon by default resumes the most
recent instance of the activity. This
capability is designed into the Journal
and is redundant in the Home View. A Sugar
activity is a tool to enable the user to
accomplish some task. If that task is not
completed, the user can resume it via the
Journal. If the tool is to be used on a
new task, the user can launch it from the
Home View. The current Home View assumes
that the intent of the user is to continue
the most recent task with that tool. </p>
<p>This task should set the Home View
default to launch a new instance of the
activity. The Alt key should be set to
enable resuming a selected instance of the
activity. By serendipity, this also shows
the Home View with black and white icons.
Icons with color signifying a resumable
instance use the colors associated with
the laptop. Unfortunately many of these
color combinations make the icon much more
difficult to distinguish than the black
and white version. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Ah, hating on the home view ux is fun. I
was actually thinking about this a while ago,
and wrote a blog post. I'd like to hear your
thoughts as it addresses the same issue: <a
moz-do-not-send="true"
href="https://www.sam.today/blog/sugar-nohomeview-design.html"
target="_blank"><a class="moz-txt-link-freetext" href="https://www.sam.today/blog/sugar-nohomeview-design.html">https://www.sam.today/blog/sugar-nohomeview-design.html</a></a><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p> </p>
<p>7. Brief explanation.<br>
Sugar provides a 'web services'
capability. However, these services are
only available to an XO which has
connection to the internet. This is not
useful to a large number of users who do
not have internet access. The school
server (e.g. XSCE) provides an alternative
to the internet for many deployments. This
task is to provide a capability on the
school server to support some or all of
the Sugar web services (e.g. by OwnCloud
or ELGG). <br>
</p>
<p>8. Brief explanation<br>
There are a number of Sugar activities
which currently require access to the
internet (InfoSlicer, GetBooks). These
activities should have an option to
function with the school server. For
example, GetBooks could access books on
the school server and InfoSlicer could
create slices from Wikipedia on the school
server as Journal objects.<br>
</p>
<p>9. Brief explanation<br>
Sugar users are often new to computers
and not familiar with other operating
systems. We need a mechanism to allow
users to more quickly develop skills in
using the capabilities of the XO
('onboarding'). One proposal is to develop
scripts which lead the user through a
series of interactive steps illustrating
common usage of the XO with Sugar (<a
moz-do-not-send="true"
href="https://www.sam.today/blog/sugar-onboard-design.html"
target="_blank"><a class="moz-txt-link-freetext" href="https://www.sam.today/blog/sugar-onboard-design.html">https://www.sam.today/blog/sugar-onboard-design.html</a></a>).
This task is to implement an interpretive
system that allows <br>
deployments or experienced users to create
an 'onboard' script that guides the user
to carry out a task. The referenced
proposal suggests some user tasks where
this mechanism could be employed. Since
there is no finite list of these tasks, an
interpretive approach enables the scripts
to be created as necessary. <br>
For example, how does a user switch to the
Gnome desktop? A script could be created
guiding the user through the necessary
steps. How does the user make a screen
shot, use Gimp in the gnome desktop to
crop and resize, and then insert it as an
image in a Write document? How does the
user initiate or join a chat?<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>I will actually be persuing that feature,
and the steps defined on that page as a
feature for 0.110. Eventually it will have a
feature page, but it is the "onboard" branch
of <a moz-do-not-send="true"
href="https://github.com/samdroid-apps/%7Bsugar,sugar-artwork,sugar-toolkit-gtk3"
target="_blank">https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3</a>}.
I invite you to test the patches and provide
feedback.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p> </p>
<p>10. Brief explanation<br>
Sugar is available on the XO and some
other platforms. In particular, Sugar is
available for 64-bit systems with Ubuntu
14.04 LTS installed (<a
moz-do-not-send="true"
href="http://wiki.sugarlabs.org/go/Ubuntu"
target="_blank"><a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/Ubuntu">http://wiki.sugarlabs.org/go/Ubuntu</a></a>).
Unfortunately, this procedure does not
work with 32-bit systems. There exists an
opportunity to deploy Sugar <br>
with relatively inexpensive or refurbished
laptops which do not provide 64-bit
support. This task is to create a
comparable version of Sugar which can <br>
be installed on 32-bit systems as an
alternate Ubuntu desktop.<br>
</p>
<p>11. Brief explanation<br>
Many deployments want to protect their
XOs against theft. OLPC provides an
'activation lease' mechanism in firmware
which makes it impossible to <br>
boot an XO once the activation lease has
expired, unless the XO has access to the
key via a removable device. This task is
to provide a similar mechanism which is
not dependent on OLPC. A USB key or
network device (school server) should have
an inventory of XOs identified by
serial_number (and, perhaps, uuid). if
this key is readable by the firmware, the
XO should boot. If the key is not readable
(e.g. reflash), then the XO should boot if
the key is readable on a removable device
or on the connected school server. [this
suggests the XO can connect to the
schoolserver by firmware alone - might be
difficult]. <br>
Whenever an XO connects with the
network device, the network device should
confirm the activation lease and extend it
by a time specified by the deployment
(administrative owner of the network
device). A report should be available to
the deployment on the XO inventory and
when each was last connected to enable
detection of 'missing' XOs. Perhaps, the
mechanism should have a 'blacklist' of
serial_numbers of 'missing' laptops. If
such a laptop is connected, it could be
allowed to proceed with a warning to the
administrator that the 'missing' laptop is
in the house. This mechanism should be
available for optional implementation by a
deployment without reference to a central
organization such as OLPC.<br>
</p>
<p>12. Brief explanation<br>
OLPC firmware in the XO-1 supported a
feature called 'nandblaster'. This
mechanism allowed a 'master' XO to
broadcast its image in a loop to the XO
Lan. Other XOs could then be flashed by
the firmware by making a copy of each
sector as it was broadcast to their local
store. Once a cycle in the loop was
finished, the XO could detach and was
ready for reboot with the newly installed
image. This task is to re-create this
capability where the 'master' XO image
could be on a network device such as a
school server or another XO. This
mechanism should store a new version of
firmware (as done currently) so that the
firmware upgrade can be automatically
installed on the next boot when connected
to an AC adapter. <br>
</p>
<p>13. Brief explanation<br>
The OLPC model is that each user has
full possession and is the only user of an
XO laptop. Therefore, Sugar assumes a 1-1
correspondence between users and XO serial
numbers. However, Sugar is being used on
other platforms (e.g. SOAS), where there
is no obvious equivalent to a serial
number. SOAS and James Cameron have
created versions of Sugar which do not
assume the user is 'olpc', but implement a
standard username/password login system.
The users storage is allocated to his/her
home directory. <br>
This task is to create a Sugar image
for the XO which allows for user's to
login by username and password. The basic
task is to move the Activities folder <br>
to a common space so that only one copy is
needed per system. This will support
deployments where one set of laptops are
shared across multiple classes (and users)
or where there one laptop is shared
between two students - one in a morning
shift and the other in an afternoon shift.
<br>
</p>
<p>14. Brief explanation<br>
The TuxMath activity is popular with
deployments. However, the upstream version
appears to be abandoned. This task would
be to implement a sugar-web-activity math
game comparable to TuxMath.<br>
<br>
</p>
<p> <br>
I have some comments on the other tasks:<br>
</p>
<p>"The newer Sugar builds have performance
issues on <i>some old hardware</i> with
limited memory. This is keeping some Sugar
deployments from upgrading. This project
is to look into the performance issues and
tune Sugar for low-memory devices."<br>
</p>
<p>I think this task should be unambiguously
focused on the XO-1 (1GB store). The
majority of deployed XOs are XO-1s with a
1GB store. These deployments generally do
not have the funds to purchase and deploy
an SDHC card for these devices (ask Adam
about this possibility in Haiti, I was not
able to get a firm number from Rwanda but
I believe they may have deployed more than
several thousand XO-1s. The cost is not so
much the card itself, but the logistics
cost to prepare the cards with an XO-1
image and to deliver the cards to the
deployment locations). <br>
</p>
<p>The performance problem is not limited to
low-memory (250GB). It is also related to
no gpu, low persistent store, slower and
more limited processor and so on.). It is
also likely that their are specific
limitations on executing newer software
releases on this hardware. As a minimum,
someone who takes on this task needs an
XO-1 (and possibly access to an XO-1.5 for
performance comparisons - a task for the
mentor?).<br>
</p>
<p>One task could be to identify some
significant performance measures (a form
of benchmark which could be applied to all
models and releases to obtain <br>
relative performance measures). The task
also requires some analysis to determine
the bottlenecks limiting performance
(processor speed, graphics speed, memory
usage, storage access times, etc.). This,
in turn, requires defining important
workloads (boot, launch activity, switch
activities, shut down activity, shut down
system, connect to network, effective
network speed, and so on). I think the
community should be able to help with this
(what are the most significant tasks in
Haiti which have unacceptable response
times on the XO-1?). <br>
</p>
<p>It is likely that one result of this task
may be to limit the capabilities of Sugar
on the XO-1.<br>
</p>
<p>"Now that JavaScript has become a first
class citizen in the Sugar ecosystem, we
must re-design our collaboration model to
allow collaboration between web activities
regardless of the platform."</p>
<p>I am not sure what is meant here by
platform. Except for development
environments, I am only aware of
Sugarizer, SOAS, and Sugar on XO in the
wild (i.e in use by deployments without
any developers or computer professionals
on site). As I understood it, Sugar has
adopted the collab-wrapper model for Sugar
activities. Is this collab-wrapper usable
in a Javascript environment? Is is
possible for XO users to collaborate in
this model with users of SOAS or
Sugarizer?<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Sugarizer has a different collab model
(some js thing) to the rest of Sugar.
However, SoaS and XO are both running the same
Sugar, with the same collab model powered by
Telepathy. I have use their collaboration
before.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p> </p>
<p>Nutritional Microworld<br>
</p>
<p>relevant tool—one that invites learners
to explore fundamental concepts of
nutrition that are both intrinsic to music
yet transcendent of a specific discipline.
</p>
I assume the reference to music is a typo. <br>
<br>
At Eurovision 2014, a speaker demonstrated
nsound - an alternative to csound. The claim
is a simpler and more understandable api.<br>
<br>
Turtle Confusion and Turtle Flags. <br>
These activities reproduce the Turtle
Blocks engine. I think a simpler solution is
to provide the confusion images and the flag
images via html and have the user create
them using the existing javascript Turtle
implementation. The user can easily switch
screens via alt-tab or the frame. For
example, the confusion challenges and the
flags could be presented by an .xol content.<br>
<p> </p>
<p>I'll try to send you some additional task
proposals as soon as I can.<br>
</p>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<p>Tony<br>
</p>
</div>
<div bgcolor="#FFFFFF" text="#000000"> <br>
<br>
<div>On 02/19/2016 05:30 PM, Walter Bender
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">FYI, as per the discussion
at this month's SLOB meeting, I
submitted an application to Google
Summer of Code on behalf of Sugar Lbs.
Lionel has agreed to be the co-admin
this summer. We should hear by the end
of the month as to whether or not we are
accepted and how many slots we get.
<div><br>
</div>
<div>It is important that we add some
more potential projects to the list in
the wiki over the next few days as a
show of interest from the community.
Please add your ideas to: </div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016"
target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016</a></div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>-walter</div>
<div>
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a
moz-do-not-send="true"
href="http://www.sugarlabs.org"
target="_blank"><font><a class="moz-txt-link-freetext" href="http://www.sugarlabs.org">http://www.sugarlabs.org</a></font></a></font><br>
<br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org"
target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>