[Sugar-devel] GSoC proposal status

[Walter Bender]

Thanks Tony. I'll give this a careful read in the AM. I'm at the end of my
productive energy level at the moment.

-walter

On Sat, Feb 20, 2016 at 2:00 AM, Tony Anderson <tony_anderson at usa.net>
wrote:

> 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 listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160220/46efcb51/attachment-0001.html>