[Sugar-devel] GSoC proposal status
Tony Anderson
tony_anderson at usa.net
Sat Feb 20 02:00:13 EST 2016
Hi, Walter
I have some concerns about the proposed GSOC tasks as well as some ideas
for new tasks.
I agree that the Journal needs rethinking. Below are my thoughts
(re-thoughts?).
Specifically,
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
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).
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.
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.
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,
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).
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.
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).
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.
I would propose these tasks more as follows:
1. Brief explanation
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.
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
save/save as gives the user the ability to manage versions by using
unique names.
2. Brief explanation
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.
3. Brief explanation
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).
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.
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.
4. Brief explanation
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.
Unfortunately, a consequence is that the Journal view fills with
essentially meaningless links to this metadata (mine fills with Terminal
Activity and Log entries).
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.
5. Brief explanation
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.
6. Brief explanation
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.
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.
7. Brief explanation.
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).
8. Brief explanation
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.
9. Brief explanation
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
(https://www.sam.today/blog/sugar-onboard-design.html). This task is to
implement an interpretive system that allows
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.
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?
10. Brief explanation
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 (http://wiki.sugarlabs.org/go/Ubuntu). Unfortunately, this
procedure does not work with 32-bit systems. There exists an opportunity
to deploy Sugar
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
be installed on 32-bit systems as an alternate Ubuntu desktop.
11. Brief explanation
Many deployments want to protect their XOs against theft. OLPC
provides an 'activation lease' mechanism in firmware which makes it
impossible to
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].
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.
12. Brief explanation
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.
13. Brief explanation
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.
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
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.
14. Brief explanation
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.
I have some comments on the other tasks:
"The newer Sugar builds have performance issues on /some old hardware/
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."
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).
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?).
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
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?).
It is likely that one result of this task may be to limit the
capabilities of Sugar on the XO-1.
"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."
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?
Nutritional Microworld
relevant tool—one that invites learners to explore fundamental concepts
of nutrition that are both intrinsic to music yet transcendent of a
specific discipline.
I assume the reference to music is a typo.
At Eurovision 2014, a speaker demonstrated nsound - an alternative to
csound. The claim is a simpler and more understandable api.
Turtle Confusion and Turtle Flags.
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.
I'll try to send you some additional task proposals as soon as I can.
Tony
On 02/19/2016 05:30 PM, Walter Bender wrote:
> 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.
>
> 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:
>
> https://wiki.sugarlabs.org/go/Summer_of_Code/2016
>
> Thanks.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160220/398507d4/attachment-0001.html>
More information about the Sugar-devel
mailing list