View source for Feature roadmap/Archive/pre-9.1.0

{{dated}}
This archive page holds the Feature roadmap as of 2008-12-11, before it was split into subpages in [[:Category:Software features]].

= Roadmap =

It uses {{tl|Feature request}}; in case that template breaks, here's how it was used.

The elements of such a request are described below. The text for these elements may be listed on the same line as the parameter, just after the equals (=) sign, or on the following line(s).  Where appropriate, please use numbered or bulleted lists to identify individual requirements or specification ideas.

; Name : A brief, one-line summary of the feature, used as the title on the page
; Requesters : Deployments, engineers, or both who support the request
; Requirements : User level requirement definition; Links to detailed wiki pages, mailing list threads, or other resources are welcome
; Specification : Design and technical implementation ideas; Links to detailed wiki pages, mailing list threads, or other resources are welcome
; Owners : Names of developers and/or champions of the request who will ensure that progress is made

See also: [[Feature_roadmap#Suggestions for providing input|general suggestions for providing input]].

== Activity-related work ==

{{Feature_request
|Name=New activities
|Requesters=Birmingham, Juliano
|Requirements=
From Birmingham:
*Firefox, Flash, mplayer
*A spreadsheet (I'm going to use gnumeric until Socialcalc is ready for production)
*A more full featured pdf reader (yes, I know there's the Read activity, but I'm planning on installing the full evince and making sure Firefox can open PDFs with it)
*A document editor the user can insert images into (the full Abiword would be great for this, but the current workaround [after editing a file] is to open write, then hit ctrl+n)
From Juliano:
*More development environments.
*Better Flash support. Minimum on par with FF on XP. From test report by Emiliano and thread on sur list.
|Specification=
|Owners=
}}

{{Feature_request
|Name=Browse update and multi-media
|Requesters=[[User:Skierpage]] 
|Requirements=
* Wikipedia articles and thus [[Wikislices]] can take advantage of this, and richer multimedia in Browse becomes practical.

|Specification=
* [[XULRunner]] 1.9.1, the Mozilla code powering [http://developer.mozilla.org/en/Firefox_3.1_for_developers Firefox 3.1], should be released in the 9.1.0 timeframe.

* Activities and content can use its new features, at the risk of incompatibility with earlier Sugar releases.

* XULRunner 1.9.1 supports the HTML5 <audio> and <video> tags, providing the ability to play [[OGG]] audio and video files natively in the browser.
This will probably improve performance and reduce memory footprint compared with embedding the [[Totem plugin]], the trade-off needs to be tested and Browse configured accordingly.

|Owners=
}}

{{Feature_request
|Name=Single sign-on from Browse
|Requesters=Reuben
|Requirements=
Overview - The primary driver for this requirement is that the XO be able to recover its backed up files from the XS HTTP restore interafce without needing to enter a user name or serial number.

* Must allow XOs to pass their identity to the XS so that the XS recognizes them without the need for them to login.
* Must allow passing the identity to the XS with which the XO is registered. Should allow passing it to any XS. Should allow passing it to any Web server with the right server side code implemented. 
* Does not require passing XO identity to more than one server at a time (not taking in to consideration and "load balancing like downstream replicating of data which is transparent to the XO).
* Does not require passing the XO identity to other XOs.
* Must pass that info in Browse in such a way that the XS HTTP server can recognize and extract the info for use in CGI scripting.
* Must work with the back and restore feature so an XO and only the relevant XO "automatically" see and restore their own backed up files.
* Does not need to support passing identity via any activities aside from Browse.
* May allow passing of XO identity to other web server or services aside from the XS but the XS is the primary must have server. If identity is passed to other non-XS server the XO identity must be encrypted and unique so that other browsers or devices can't "spoof" and appear to be the XO.
* Must allow the user to turn off or turn on this feature. When off the XO will not pass its identity.
* Must maintain its identity after upgrade or downgrade.

Server side requirements: <br>
* Must allow an override on the XS which allows it to see a new XO and associate it with a previously seen XO (covers the case where an XO breaks and the user wants to restore the data to a new XO).
* Must allow the XS to move the identity DB and any associations (e.g. which files where back up from which XOs) to a new XS or to share it with another secure XS.

|Specification=
|Owners=Greg
}}


{{Feature_request
|Name=Better eBook reader
|Requesters=Birmingham, Haiti, Devel thread
|Requirements=
* Description of challenges here: http://lists.laptop.org/pipermail/devel/2008-October/020662.html See the rest of the thread too.
*A more full featured pdf reader (yes, I know there's the Read activity, but I'm planning on installing the full evince and making sure Firefox can open PDFs with it) (comment from Birmingham)
* Must not copy the PDF or other book format so that it takes up twice the NAND space.
* Must support PDF, plain text and .cbr files (any other must have formats?)
* Must open book directly from Journal
* Must "remember" the page you are on when restarting.
* Must allow opening the reader then browsing available books (can do this in web browser but needs the ability to look at the NAND to see what is available).

Desired improvements
* ability to do page mode as well as continuous mode (move an entire page at a time)
* ability to specify columns and move through a document down the columns
* ability to specify the amount of overlap when paging in continuous mode
* ability to zoom to 'fit text on screen' as opposed to 'fit page on screen' to eliminate borders from pages.

|Specification=
Possible support eVince: 
http://live.gnome.org/Evince/SupportedDocumentFormats per Jim e-mail: http://lists.laptop.org/pipermail/devel/2008-October/020719.html
?
|Owners=
Greg
}}


{{Feature_request
|Name=Sugarized color picker
|Requesters=Juliano
|Requirements=
A better color picker in Paint & Write. Current one "...is made for professionals to get the HTML code of the color, but it also leads to error since people need to select the color in the circle and then in the triangle. It is giving bad time to people around here [Rwanda]". ''From Juliano in e-mail 9/1''
|Specification=
|Owners=
}}

{{Feature_request
|Name=Easy "Sugarization"
|Requesters=Wanda, David
|Requirements=
* Support for standard desktop applications in Sugar.
* Better "legacy app" compatibility; this should allow us to run existing apps like firefox, pidgin, and gimp in a reasonable manner (CScott version).
* Make it easy to sugarize third party applications. It should be trivial to take an existing application which runs on Fedora (or other Linux too?) and install and run it on the XO. The basic sugarization interface for that should be usable by a non-programmer. Not all sugar features need to be enabled (will define exact list if this gets to requirements definition stage). Additional sugar capability may require programming (e.g. collaboration). The goal is to allow deployments to use any state of the art application available in Linux/Fedora. 
* Secondarily, make it easy to do the same for web based applications (Google Gears, Picasa, etc.). tbd if this needs to include client side Java support.
* Allow easy creation of content bundles out of PDFs and HTML (other?). Should be as easy for a non-programmer as that described above.
* Must "work well" in Sugar. There may be some applications that work but don't use the journal (e.g. Scratch) and that may be acceptable. A definition of how well an activity works or a definition of "well sugarized" is needed. First comments on this are at: http://wiki.laptop.org/go/Educational_activity_guidelines
* Product management and Learning teams must come up with 5 - 10 applications which will be the first targets.

|Specification=
* See related X-windows threads on devel (links and references appreciated). This may also impact datastore and other areas.
* Replace matchbox window manager with [[XMonad]], [http://en.wikipedia.org/wiki/Metacity Metacity], [http://awesome.naquadah.org/ awesome], etc.  Should provide both 'full screen' mode and traditional 'tiled' mode.
* Switch to standard freedesktop.org [http://www.freedesktop.org/wiki/Specifications/startup-notification-spec startup notification] mechanism: <trac>5271</trac>
* Implement freedesktop.org [http://www.galago-project.org/specs/notification/index.php notifications mechanism] for alerts (low battery, low disk space, available software update)
* Refactor home/friends/mesh view as operations on root window, so they make sense in a multiwindow setup. (It's been suggested that looking at the xpenguins code is instructive for understanding how nautilus,etc arrange their root window.)
* App launching & mimetypes via XDG mechanisms (thanks, erikg)
* Support for .desktop files in the launcher list
* Support startup-notification
* Support standard application icons on the frame
* See also thread by Scott: http://lists.laptop.org/pipermail/devel/2008-October/020387.html

|Owners=Greg^
}}


{{Feature_request
|Name=Concept maps
|Requesters=Panama, OLPC Sur
|Requirements=
* Support a concept maps making application. Can be on XS or Internet or XO only
* First choice is CMap Tools, but other Concept Map options are welcome too if CMap can't be easily implemented.

|Specification=
* See some of the options and available tools at: http://lists.laptop.org/pipermail/devel/2008-September/018811.html

|Owners=
Greg
}}


{{Feature_request
|Name=Activity updater improvements
|Requesters=Scott
|Requirements=
* Support a concept maps making application. Can be on XS or Internet or XO only
* First choice is CMap Tools, but other Concept Map options are welcome too if CMap can't be easily implemented.

|Specification=
* Real COW for pristine versions, allowing... <trac>3581</trac>
* ...binary-diff updates over http (avoiding rsync in many cases) <trac>4259</trac>, etc
* Integration of core OS updates with software update control panel: <trac>7618</trac> (See also GUI OS Updater feature)
* Integration of software updates with notification system
* Incremental updates of activity bundles (only changed files)
* Send back statistical data when checking for updates (batmon, etc) <trac>4594</trac>, <trac>6447</trac>

|Owners=
Scott
}}


{{Feature_request
|Name=Terminal improvements
|Requesters=Sayamindu
|Requirements=
* Copy paste and drag and drop support enhancements
* Pippyfication (ticket #5543)
* Better handling of "Run as root in the UI" 

|Specification=

|Owners=
Sayamindu
}}

{{Feature_request
|Name=Spell checker in Write
|Requesters=Yifan, Genessee
|Requirements=
See thread here: http://lists.laptop.org/pipermail/devel/2008-December/021477.html

|Specification=

|Owners=
Yifan
}}

== Power management ==

{{Feature_request
|Name=Improved battery life
|Requesters=Kim, Carla, Gnu, Ethiopia, Juliano
|Requirements=
Background information: a list of UI actions which may affect power usage: [[Requirements#Power Management Requirements]] Our job is to increase battery life in as many modes as possible.

<br>
# Power save (here after called idle suspend) should default on but the user also the option to not use it.
# When you turn the radio off the in the network control panel it must cut off all power to the wireless chip.
# Must rewrite the documentation on power and explain it to Frances so that she understands how to use it. (add link to existing documentation).
# Should offer a full featured set of power options in GUI. Not critical but nice to have.
# Idle suspend must dim the screen after 1 minute of the user not touching the keyboard or touchpad. Then after an additional 2 minutes it must change the screen completely off. Must allow setting of those values in the control panel. The only exceptions are that when the audio device is playing, when olpc-update is running.
# Must turn the screen back on in less than 1 second after the user touches the keyboard or touchpad.
# Idle suspend must turn the CPU off.
# Must allow activities to override the idle suspend mode above. That is to not suspend even if the time has passed.
# Must not lose your network connection, activity state, sugar GUI elements and collaboration (e.g. start a chat, let the XO suspsend then otehr chat person chats, that new chat text should show on the suspended XO without turning on the screen) after waking from idle suspend. Must not crash. Multicast, ARP, mDNS, the Presence Service, and collaboration must all work in the presence of autosuspend.
# Should not turn the screen on unless the user interacts with the keyboard.
# Wireless chip must respond to ARP requests when in Idle Suspend mode.
# Screen must not flicker on resume.
# Should allow users to disable the mesh:  reduces power consumption of the WiFi chip, allows the WiFi chip to enter power-save mode, and most importantly, allows lid-closed suspend to totally power off the WiFi chip. <trac>6955</trac>
# Should put the EC into deep sleep when in a lid-closed suspend.  This will cut its power from about 60ma to about 20ma (check with rsmith), which would further increase the duration of a lid-closed suspend before the battery drains.
# (* not likely to make 9.1 with current resources *) Should improve cpu idle detection.  Currently we can't auto-suspend very often (only after >1 minute of no user interaction) because suspend is so heavy-handed.  The cpuidle infrastructure in the kernel should be able to tell us when it's safe to suspend because no process wants access to the CPU for the next few seconds.  Most of the pieces are there.

|Specification=
Requirement 4 addressed by: <br>
<trac>2765</trac> -- Need to turn off DCON after some time in idle suspend <br>
<trac>4606</trac>  <br>

Requirement 5 addressed by: <br>
<trac>9054</trac> -- Speed up USB resume (kernel)
<trac>7981</trac> -- EC mask setting is inefficient
<trac>8916</trac> -- Extreme Power Management doesn't unload USB for fast resumes
<trac>7384</trac> -- Manually enabled USB-disabling Power Management

Requirement 9 addressed by: <br>
<trac>6818</trac> -- Make the multicast wakeup filter work with collaboration (Ricardo Carrano?)
<trac>7458</trac> -- Intermittent lockup on WOL

Requirement 11 addressed by: <br>
<trac>3732</trac> -- ARP broadcasts don't wake auto-suspended laptops

Requirement 12 addressed by: <br>
<trac>7958</trac> DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) <br>

Other: <br>
* <trac>9055</trac> -- Create 9.1 test plans for automatic power management

* There's still a major Python bug that causes multi-threaded pyGTK2 programs to poll uselessly once a second (<trac>4680</trac>, <trac>4677</trac>).  Much work was done to close it, but there is still a small sprint required to get it done.  This not only reduces power use directly, but also allows the system to suspend because it doesn't appear that activities need to do some work soon.

Background on power draw including a break down watts used in different modes: 
* [[XO Power Draw#The Numbers]]
* [[Per-Activity Power Usage]]

Significant technical actions (as suggested by John/Gnu) that could reduce the laptop's power draw:

* not to Greg - move to collaboration.
* Reduce packet traffic during sharing -- particularly multicast traffic, which loads many machines (and wakes them up from autosuspend).  This will require diagnosis and improvement of the presence and collaboration protocols.  Some work was done on this, after the high packet traffic melted the WiFi bandwidth in early deployments (e.g. turn on 30 laptops in the mesh, none of them can usefully get anything done), but our main response was to tell later deployments "Don't use the mesh, use access points" -- a significant reversal that we should keep working to fix.

|Owners= Requirements 1 - 5, 7, 8, 10, owned by CJB. 6 by CJB, 9 and 11 networking team (Ricardo?), 12 Mitch and Deepak Product manger Greg, QA Joe.
}}

{{Feature_request
|Name=Shutdown menu
|Requesters=Haiti, Rwanda
|Requirements= <br>
* The power button is currently underutilized. It should allow either shutdown or suspend of the laptop, with the help of an on-screen dialog or menu. 
* Make sure that the clean power button shutdown in 9.1 works from the Sugar nickname

|Specification= See thread at: http://lists.laptop.org/pipermail/devel/2008-October/020530.html

|Owners=PGF, Greg^ 
}}


{{Feature_request
|Name=No power regressions
|Requesters=Greg, Ethiopia, Rwanda, Haiti. Also make sure that EC draws the minimum possible power when XO is actually shutdown.
|Requirements=Make sure power usage is not worse (needs more careful description) in next release.
|Specification= Tinderbox testing?

|Owners=Richard
}}

== Hardware support ==

{{Feature_request
|Name=Accurate touchpad
|Requesters=Carla, Rwanda, Ethiopia, Haiti
|Requirements=[[User talk:Gregorio#Priorities from Carla]]. 
* Must not move the cursor when the user is not interacting with the touchpad. 
* Must move the cursor the same distance for each drag across the pad.
* Must not recalibrate too often.
* Must enable a debug mode which shows when the touchpad is recalibrating and allows identification of XOs which are recalibrating too often.
|Specification=
* Some relevant trac tickets: #7341, #7788, #8222.
|Owners=Wad, PGF, Greg^
}}

{{Feature_request
|Name= Grab-scroll keys
|Requesters= [[User:Garycmartin|Garycmartin]]
|Requirements=Provide view scrolling functionality with the grab/scroll hardware keys as documented in [[OLPC_Human Interface Guidelines/The Sugar Interface/Input Systems#Description of Keys|Human interface guidelines]].
|Specification= See <trac>447</trac> for a likely solution and patch. 
|Owners=ericg?
}}

== Collaboration ==

{{Feature_request
|Name=Synchronous collaboration
|Requesters= Carla and David, Teachers on OLPC-Sur, Peru technical leaders
|Requirements=See detailed collaboration requirements here: [[9.1.0 Collaboration Requirements]] 
*Allow for intuitive mesh connection and activity-sharing.
*Must support first two use cases defined at: [[Use Cases#Collaboration Examples]]
*[[Requirements#Mesh / Connectivity_Requirements]]
*[[Requirements#AbiWord Sharing Requirements]]
* http://lists.laptop.org/pipermail/sugar/2008-July/007407.html
* May need to include that link in developer section below, tbd
|Specification=
* Ensure Gadget is correctly integrated and deployed in Sugar so we can avoid the troublesome shared roster haxks on the XMPP server
* Fix tubes so that peer to peer data is sent with peer to peer connections on the network where possible
* Fix the way JIDs are allocated to be more coherent and based on the child's nickname (also would benefit a lot from having hierachical DNS naming on the school server so each JID is globally unique)
* Expose JIDs in the UI and allow them to be typed in and approved by normal subscription requests, allowing collaboration with anyone whose JID you know
* Implement the Telepathy file transfer spec to enable that feature in Sugar
* Enable avatars in Sugar (although maybe not if we're doing link-local multicast on an XO mesh network) and maybe some UI for taking a photo and setting that as your avatar

See also: http://sugarlabs.org/go/DevelopmentTeam/0.84/Ideas#Glucose
|Owners= ^Greg
}}

{{Feature_request
|Name=Asynchronous collaboration
|Requesters= Juliano, Cynthia
|Requirements=

* Must allow students to post and work on projects together. One student can create something and share it with other students who edit it and save etc.
* Must allow development of projects using multiple applications (e.g. write documents, pictures, HTML, etc. needs full list). Juliano - "There is no way for group work for a couple of months in the same project using different activities."
* Must allow creation of project groups with edit and view privileges based on group membership. 
* Must allow viewing of all projects and of projects filtered by various (needs definition) views. e.g. Juliano - "Even if the Neighborhood View show the currently shared projects, it will just show a subset of them, and just the ones that are currently being used" 
* Must keep a history of who did what and when. Must include which groups worked on each project at different times.
* Must allow posting for viewing end result in school and publicly on the internet.
* Must allow "submitting" completed projects to teacher or otherwise setting a "completed" milestone.
* Must include out of band communication mechanisms. e.g. leave a message for other students saying "I updated frog project with new picture".  This could be Chat, e-mail or other synchronous and asynchronous tools.
* Must allow working at home on XO and then synching up work with the latest shared version.
* Should included server based and non-server based solutions. That is, should not require a server in all cases.
* Provide a way to publish material to the world.  related slightly to how edublog works now?  see also robson's and juliano's interests here (from SJ).

* See related thread at: http://lists.laptop.org/pipermail/devel/2008-October/020588.html

* See also Activities as building blocks thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020732.html

|Specification=
|Owners= Greg^, Martin
}}

{{Feature_request
|Name=Scalable server-based presence
|Requesters=
|Requirements=Improve scalability of (ejabberd) server-based presence
* Complete [[Gadget]] implementation, which should hopefully fix our current scalabity issues and offer new features as activity and buddies search. '''(cassidy)'''
* Integrate Gadget in glucose. It will require work on several modules, including sugar-presence-service, sugar-toolkit and sugar. '''(cassidy, morgs)'''
* Integrate gadget in the Sugar UI. <trac>7711</trac> '''(erikos, eben)'''
|Specification=See [[Gadget integration TODO]] for more details.
|Owners=Guillaume Desmottes, Dafydd Harries, Eben Eliason, Morgan Collett
}}

{{Feature_request
|Name=Scalable link-local presence
|Requesters=
|Requirements=Improve scalability of non server based presence
* Integrate Cerebro into Telepathy framework (Collabora)
* Extend Cerebro API to fit activity sharing requirements better (ypod)
* Drop into stack in place of Salut
|Specification=
|Owners=Morgan Collett, Sjoerd Simons, Elliott Fairweather, Polychronis Ypodimatopoulos
}}

{{Feature_request
|Name=Collaboration groups
|Requesters=Peru
|Requirements={{trac|4043|Group support in gabble and salut}}
|Specification=
|Owners=Eben
}}

{{Feature_request
|Name=File sharing
|Requesters=Peru blog http://blog.stone-head.org/olpc-peru-a-silent-revolution/ 
|Requirements=A way to send objects from one XO to another without a USB key, and without sharing the activity. <br>
See also: http://wiki.laptop.org/go/Network_principles#Direct_XO-to-XO_serverless_communication. <br>
Greg's requirements definition: <br>
* Must allow moving an "object" (usually thought of as a file) from one XO to another.
* Must support all available network environments (e.g. Mesh, AP only, XS eJabberd)
* Should allow transferring files using the existing Sugar Neighborhood tools (e.g. put a file on the journal of any other user visible in the network neighborhood).
* Should allow moving an object to any XO visible over the network (AKA pingable) regardless of whether they are visible in the Neighborhood (due to bugs in collaboration or someone not collaborating or any other barrier which does not prevent ping).
* May support queuing a file for transfer later. That is, add support for asynchronous sharing over time : the sharing of an effort should not require everyone to be online at once.
* Should provide resumable downloads, so that intermittent or low quality connectivity doesn't cause transfers to fail permanently.
* Using file transfer must work in both Salut and Gabble,
* Allow Journal objects to be shared between buddies over link-local or Jabber
* May enable automatic activity downloading for shared activities that aren't installed on the joining machine 
* Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network. 
* Should allow access to your Journal so that any other use can see it and retrieve a file from it.
* Should allow control of access to the XO at the file level. That is, don't expose the whole Journal, only make certain Journal entries visible.

|Specification=
* [[Specifications/Object_Transfers|XO to XO object transfer system]]. [[User:Eben|Eben]] 19:40, 19 September 2008 (UTC)
* http://wiki.laptop.org/go/Specifications/Object_Transfers#Information_to_show (* Eben or whomever this concerns, please state exactly which parts of this will be available in 9.1.0 [[User:Gregorio|Gregorio]] 14:03, 5 December 2008 (UTC))
* Demo script for this available at: http://git.collabora.co.uk/?p=telepathy-python.git;a=blob;f=examples/file-transfer.py;h=d3636fa42eb6f822db9f7a3cc5cac9b08c538bce;hb=HEAD


Ideas for specifications below, when one is confirmed for implementation, please move it above this line
----
* Noted by SJ, possibly related to [[bundle (activity)]].
* A number of technical proof-of-concept programs have been written for distributing files, using methods like HTTP over stream tubes and Cerebro's Teleport.  There is an excellent set of [[Specifications/Object_Transfers|UI mockups for this]] functionality.
* Additional links from Ben S. 
** [[Read]]
** [http://lists.laptop.org/pipermail/sugar/2008-March/004499.html Distribute]
** [[Summer_of_Code/Ideas#Publication_and_Journal_sharing|A Summer of Code application]]

|Owners=Simon, Eben, Guillaume
}}

{{Feature_request
|Name="Candy Bag" or "Bulletin Board" activity
|Requesters=
|Requirements=Idea for a new activity: Candy Bag.  You open a bag (i.e. you launch the CandyBag activity), then you put journal entries in it, then sharing this activity means that your friends can grab a candy in your bag. From: http://lists.laptop.org/pipermail/devel/2008-July/017459.html
|Specification=I'd be curious to see if there is a benefit to having a task like this manifested as an activity. It might work well. In fact, this might be the "Bulletin board" activity we've been wanting all along. There's also a design for a more embedded [[Specifications/Object_Transfers|XO to XO object transfer system]]. [[User:Eben|Eben]] 19:40, 19 September 2008 (UTC)
|Owners=
}}

== Performance ==

{{Feature_request
|Name=Faster activity launch and save
|Requesters=Peru, Uruguay
|Requirements= 
* Must show glowing splash image which is seen after a click on an activity and before it launches in less than 300ms. This will increase performance and help prevent people from accidentally launching two instances of an activity.
* Must start all G1G1 activities (http://wiki.laptop.org/go/Activities/G1G1) from Home or the Journal in less than 5 seconds. Start means the the activity Menu bar is show and the cursor or other input device is active. May allow an additional 3 seconds if the activity is launched with a document (e.g. from the Journal).

|Specification=<trac>6472</trac>
|Owners=
}}

{{Feature_request
|Name=Faster task switching
|Requesters=Peru, Uruguay
|Requirements=
* Must change from one activity to another via keyboard (e.g. alt-tab) or via the Frame in less than 2 seconds.

|Specification=
|Owners=Erik
}}

{{Feature_request
|Name=General UI sluggishness
|Requesters=Uruguay, Peru
|Requirements=
* For all of the following, the times measured should apply when the XO is connected to a wireless AP and running Write with a file of less than 1 MB. This is used as a sample "state of the machine" definition. Other definitions of state of the machine are welcome and the performance when the XO is doing more (e.g. more activities open or moving data over the Wireless) should not degrade precipitously.
* The time between when the user interacts (e.g. clicks or enters a key stroke) when the result is visible on the screen should be less than 100ms. Specific cases are listed below and when the absolute number above is not achievable, a target percentage improvement is listed.

* The following are examples where think release 8.2 does not meet this requirement.
* Must be 80% faster than in 8.2 to show or hide the Frame.
* Must begin showing scroll operation results in the Journal 50% faster than we do now. That is from the time I click on the scroll bar until the image on the screen starts to move.
* Must copy and paste to the clipboard and show the clipboard icon in the Frame with the right type (text or image) of object 75% faster.  
* Must open a Journal detail page 50% faster.
* Must show all icons when switching from one view to another (e.g. from Home to Neighborhood etc) 75% faster.
 
|Specification=From: http://lists.laptop.org/pipermail/sugar/2008-July/007471.html
|Owners=Marco, Erik
}}

== Reliability ==

{{Feature_request
|Name=Memory pressure
|Requesters=Elana, Peru, Carla
|Requirements=
* http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Memory_bloat
* Should show the user how much memory is being used in the GUI.
|Specification=
* Stability suggestion from Albert C (and his children) re. protecting against out of RAM conditions.
http://lists.laptop.org/pipermail/devel/2008-September/019575.html
* We provide no end user feedback on memory usage, either.  We should investigate whether revisiting our previous attempt to give such feedback, now that Linux can provide much better information than it could when we abandoned our previous donut attempt.  The users could really help, if only we let them know a bit about what was going on... From Jim e-mail to devel: http://lists.laptop.org/pipermail/devel/2008-September/018944.html
|Owners=Jim
}}

{{Feature_request
|Name=Journal never loses work
|Requesters=Everyone
|Requirements=
* Sugar must never lose data. Activities must save on exit and leave an item in the journal. Once an item is ion the journal it must remain there until the user removes it.
* http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Datastore_rework
|Specification= http://sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.83.1#sugar-datastore
|Owners= Tomeu, Greg^
}}

{{Feature_request
|Name=Clipboard
|Requesters=Eben
|Requirements=
* http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Solid_clipboard
* [[Specifications/Clipboard|specification]] 
|Specification=
|Owners=Eben, Tomeu, Marco
}}



== Localization ==
[http://lists.laptop.org/pipermail/devel/2008-June/015838.html Translation Technology] (See an earlier post, [http://lists.laptop.org/pipermail/devel/2006-March/000000.html Scaling and localization in package management], for background.)

See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020406.html

{{Feature_request
|Name=Language pack version 3
|Requesters=Sayamindu
|Requirements=

|Specification= <br>
* Packs should be as RPMs
* Utilize patches from Ubuntu for Python and Glibc to define a separate install location/search path for PO files installed via the packs

|Owners=Sayamindu
}}


{{Feature_request
|Name=Spell checking
|Requesters=Sayamindu, Sur list
|Requirements=
|Specification=
|Owners=Sayamindu
}}

{{Feature_request
|Name=Enhanced i18n
|Requesters=Sayamindu

|Requirements=
* Better support for translation of content
* See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020417.html

|Specification=
* Investigation of the possibility of using native digits for translations <trac>7857</trac>

|Owners=Sayamindu
}}


{{Feature_request
|Name=Language customization
|Requesters=Sayamindu, Sur list
|Requirements=An ability customize language (and related settings) without OLPC intervention
|Specification=
|Owners=
}}


{{Feature_request
|Name=RTL support
|Requesters=Lebanon
|Requirements=
* Must support Arabic in Sugar, Write and all activities.
* Must start the cursor on the right and move to the left as characters are typed in Sugar, write and other activities.
|Specification=
|Owners=
}}

{{Feature_request
|Name=SCIM
|Requesters=Sayamindu
|Requirements=
* We need to migrate to SCIM for our input method needs. Our current input method (XKB with XIM) does not work with languages like Chinese, and there are enhancement requests from existing deployments (eg: <trac>8494</trac>) which can only be handled via SCIM.
* Must completely support Simplified Chinese, Nepali and Amharic.

|Specification=
* Conversion of all existing layouts to [http://www.m17n.org/common/m17n-docs-en/m17nDBFormat.html m17n db format ], along with refinements and better support for modifiers whenever possible (<trac>6280</trac>
* Modification of relevant startup and configuration scripts for SCIM support
* User experience for keyboard layout switching should not change
* Proper handling of Amharic characters (<trac>8494</trac>)
* Implementation of [[OLPC_Nepal_Keyboard]]
|Owners=Sayamindu
}} 

{{Feature_request
|Name=Multilanguage support
|Requesters=Sayamindu, Bolivia, Peru, Rwanda, others?
|Requirements=An ability choose multiple languages in order of preference (eg: an Aymara speaker would choose Aymara followed by Spanish)
|Specification=Mockup for the Sugar control Panel has been created by Eben at http://interdimensionmedia.com/scratch/settings-10.jpg . The feature is <trac>8875</trac>
|Owners=Sayamindu
}}

== Security, activation and deployability ==

{{Feature_request
|Name=GUI OS updates
|Requesters=Eben, Scott
|Requirements=Easy GUI update of OS over net or from USB; Mostly for G1G1 but useful for all.
|Specification=
(I believe this needs to be divided into 'customization key' and initial install. The install has to do with the logistics, USB keys and wireless downloads. Customization has to do with how the image is created before the logistics of how to get it on laptops. [[User:Kimquirk|Kimquirk]] 17:25, 9 October 2008 (UTC))

Many deployments have noted how hard it is to install or upgrade, especially on thousands of XOs. One issue is that inevitably, the Xos ship from the factory with an older build and countries need to upgrade them before deploying. I call that "upgrade in a warehouse". In other cases the XOs get deployed but there is little or no WAN available to upgrade.
|Owners=
}}

{{Feature_request
|Name=Faster imaging
|Requesters=Ethiopia, Rwanda, Haiti
|Requirements=
This feature request is needed to minimize the time to install a custom image over a wireless or wired network. It will be used when an XO comes from the factory with an older release. The deployment then needs to upgrade to the latest release and possibly install some customizations (e.g. content, language pack, activities, see also separate customization requirement below). The solution must be faster than imaging via USB sticks for imaging more than 1,000 XOs. Must allow install of new image via wireless or wired network. Possibly sub-variants of in school case for Mesh, Wireless AP, XS.

Workflow example for the network case above: <br>
# XOs leave the factory with an older image (e.g. 8.2.1) which includes this OFW code.
# A custom image based on the same or a later release including activities, content, language and maybe other customizations is prepared and loaded on the XS.
# An AP is setup and wired to the server.
# The XOs are turned on, as many as they have power jacks for. On boot up we can require that they hold down some special keys (game keys).
# Release the keys and the XOs find the AP and start listening on preconfigured multicast broadcast address.
# The XS broadcasts on the preconfigured address and each XO starts receiving.
# In case of errors which are more than what can be recovered by error correction the XOs, pick up again on the second broadcast or third or up to ... n (where is configurable or they just turn t he server off).
# When the XO has a complete image it notifies by putting a special image on the screen.
# On next reboot of the XO its running the new image. Subsequent boots do not do this multicast listening unless configured specifically by the user.
|Specification=
See also: [[Multicast NAND FLASH Update]]<br>

Some open issues to be addressed by the design proposal:
* Do we pre-configure an ESSID and multicast addresses and hard code those in the factory?
* Can we get it down to no intervention of hold down games keys only?
* What happens if you turn on "too many" XOs? Can we just let them turn on as many as they want and we'll fill them in some order or should we 
limit it to set # of XOs at a time? Can we scale it by using more "channels" or more APs?
* Any other security points?

|Owners=Greg, Reuben, Mitch
}}

{{Feature_request
|Name=Image customization
|Requesters=Uruguay, Ethiopia, Colombia,Peru, Mexico (the last two especially for startup image customization). See source thread from Colombia at: http://lists.laptop.org/pipermail/devel/2008-July/017299.html
|Requirements=
When imaging a new laptop or upgrading a laptop we must allow the deployment to create a custom image. This special image will allow XOs to be re-imaged via USB or over a network (via olpc-update to internet, via olpc-update to XS, via Quicker Imaging feature above). The customized image must allow configuration of the following items. These should be settable when creating a new image or when upgrading unless otherwise noted.

Cuando haciendo un imagen nuevo para el XO o haciendo una actualizacion del Software debe permitir que el despliegue cree una imagen de encargo. Esta imagen especial permitirá que XOs sea puesto vía el USB o sobre una red (vía la olpc-update del Internet, vía la olpc-update de un XS, o via Quicker Imaging definido arriba). La imagen modificada para requisitos particulares debe permitir la configuración de los puntos siguientes. Éstos deben ser configurable al crear una nueva imagen o al aumentar a menos que se indicare en forma diferente. 

* When installing a custom image, must not require any user interaction with the keyboard. Can require holding down a game key on startup.
* Al instalar una imagen de encargo, no debe requerir cualquier interacción del usuario con el teclado. Puede requerir el mantenimiento de una llave del juego en arranque.

* Must allow setting the language
* Debe permitir el fijar de la lengua

* Must allow inclusion of the activities and content bundles chosen by the deployment.
* Debe permitir la inclusión de las actividades y el contenido lía elegido por el despliegue.

* Must allow installing a language pack
* Debe permitir el instalar de un paquete de la lengua

* Must allow configuring the keyboard for a language
* Debe permitir el configurar del teclado para una lengua 

* Must allow installing an RPM (Ethiopia)
* Debe permitir el instalar de una RPM (Etiopía) 

* Must allow setting Time, Date Timezone
* Debe permitir deinicion del tiempo y Timezone

* Must allow setting of all elements of the sugar-control panel, CLI and GUI versions.
* Debe permitir el ajuste de todos los elementos del panel del azúcar-control, de las versiones del CLI y del GUI.

* Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done.
* Debe trabajar con XOs activado y XOs no activado. En el caso no activado debe activarlos así que el XO es pronto para usar en la escuela cuando está hecho. 

* Must no require more than one reboot.
* No debe requirer mas que on "reboot"

* Should turn off when its done or show "success" screen then one key stroke and shutdown.

* Must allow changing startup picture by copying an image to the XO. 
* Debe permitir el cambiar del cuadro de lanzamiento copiando una imagen al XO.

* Must not require that deployments request a new signed build from OLPC. This can be addressed by allowing them to sign their own builds or by allowing all the customizations listed to be made on a signed build without requiring that it be re-signed. We can require that this feature is only available to specially designated users.
* Necesidad no requerir que los despliegues pidan una nueva estructura firmada de OLPC. Esto puede ser tratada permitiendo que firmen sus propias estructuras o permitiendo todos los arreglos para requisitos particulares enumerados para ser hecho en una estructura firmada sin requerir que re-signed. Podemos requerir que esta característica esté solamente disponible para los usuarios especialmente señalados. 

See also:
* <trac>7878</trac>
* <trac>6689</trac>
* <trac>6432</trac>

The following two points need redefinition and clarification:
* Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done. (rewrite to cover pre-activated and lease feature disabled cases).
* When imaging in a warehouse must activate the laptop

* Note, follow up on issues with open firmware.

|Specification=
* http://lists.laptop.org/pipermail/devel/2008-March/011553.html
* http://lists.laptop.org/pipermail/devel/2008-July/016417.html

|Owners=
}}

{{Feature_request
|Name=School server push of XO images
|Requesters=Peru
|Requirements=
* The XO should be able to get the latest build from the school server
* The administrator makes the desired build available in the designated directory. When ready, the administrator requests to 'push' the build to all laptops as they come on line. Both of these activities should be an easy-to-use UI at the school server.
* A test requirement is the ability to create a white list of serial numbers that should be upgraded with the push.
|Specification=
|Owners=Martin
}}

{{Feature_request
|Name=Image signing key delegation
|Requesters=Uruguay
|Requirements=
* Must all a deployment to generate an image with their own key. See Trac ID: 9045
* After a key has been generated for a country, must not require them to contact OLPC for any further information to make the signed image. 
* Can allow deployments to sign with their own key or with a key delegated from us.
|Specification=
|Owners=Scott
}}

{{Feature_request
|Name=Activation lease security
|Requesters=Peru, Ethiopia (especially last point), Uruguay?
|Requirements=

'''Overview''' <br>
The controlling idea is that when an XO is stolen it will stop working after a time (activation lease time) unless it contacts a re-leasing server (usually a School Server). For example, if an XO is stolen and taken away from its school server, after the expiration of the lease time it will no longer boot up. If the XO is stolen but still comes within range of its school server, it can still be prevented from booting if the XO information (probably serial number) has been added to a black list on the XS.

* If the laptop is stolen, and doesn't contact its local school server within some period time (activation lease time) the XO will no longer boot (I call this "deactivated"). 
* Si se roba el XO y el XO no se contacta a su servidor (XS) local de la escuela dentro de una cierta hora del período (tiempo del arriendo) el XO va a encender (boot) (llamo este " deactivated").


* When the XO boots up and contacts the XS, its lease time is extended. e.g. if the activation lease time is 30 days and it starts on November 1, then the XO boots up on November 20 and contacts the XS, it will continue functioning without contacting the XS until December 20.
* Cuando el XO arranca y entra en contacto con el XS, su tiempo del arriendo es extendido. e.g. si el tiempo del arriendo de la activación es 30 días y comienza el 1 de noviembre, después el XO arranca el 20 de noviembre y entra en contacto con el XS, él continuará funcionando sin entrar en contacto con el XS hasta el 20 de diciembre.


* Optionally as set by the administrator, if an XO is deactivated and tries to boot up when in the vicinity of its controlling school server, then it will boot unless it has been added to a blacklist. The blacklist is a list of XOs (by serial number?) which has been entered in to the school server by its administrator. That is, the activation lease time will be automatically extended whenever the XO contacts its controlling XS, unless it has been entered in the black list.
* Opcionalmente como fija por el administrador, si un XO se desactiva e intenta boot cuando esta en la vecindad de su servidor de la escuela que controla, después boot a menos que se haya agregado a una lista negra. La lista negra es una lista de XOs (por número de serie?) cuál ha sido entrado adentro al servidor de la escuela por su administrador. Es decir, el tiempo del arriendo de la activación será automáticamente cuando el XO entra en contacto con su XS que controla, a menos que no se haya inscrito en la lista negra.


* Must allow setting of the activation lease time by the deployment lead (user interface required). That is, they can set it for 90 days or whatever they want. The granularity should be at 24 hours and be from 1 day to never expire. Must allow setting this once for a recurring interval (e.g. XO leases expire every 60 days).
* Debe permitir el ajuste del tiempo del arriendo de la activación por del despliegue (interfaz utilizador requerido). Es decir, pueden fijarlo por 90 días o lo que quieren. La granulosidad debe ser en 24 horas y ser a partir de 1 día nunca a expirar. Debe permitir el fijar de esto una vez para un intervalo el repetirse (e.g. los arriendos de XO expiran cada 60 días).


* Must not be possible for the user to set the date on the laptop to keep it within the lease period or to force it to outside the lease management. This might mean you cannot change the date or there is no root access, or it might mean an alternate time source is used.
* Necesidad no ser posible para que el usuario fije la fecha en el ordenador portátil para guardarlo dentro del período del arriendo o para forzarlo fuera de la gerencia del arriendo. Esto pudo significar usted no puede cambiar la fecha o no hay acceso a root, o puede ser que signifique que una fuente alterna del tiempo está utilizada.


* Must support the same as described above but allow the server which determines the activation to be across the Internet. The lease management server can be in a data center managed by the deployment or on a server managed by OLPC.
* Apoye iguales como se describe anteriormente pero permita el servidor que determina la activación para estar a través del Internet. El servidor de la gerencia del arriendo puede estar en un centro de datos manejado por el despliegue o en un servidor manejado por OLPC.


* Must support the same requirement as described above but allow the reset of the activation to be done via USB key. That is, when an XO's lease expires, it must be booted with the USB key containing a special code. This can be done before it expires to extend the lease.
* Apoye el mismo requisito como se describe anteriormente pero permita que el reajuste de la activación sea hecho vía llave del USB. Es decir, cuando el arriendo de un XO se expira, él se debe boot con la llave del USB que contiene un código especial. Esto puede ser hecha antes de que expire para extender el arriendo.


* Should support the ability for an XS to continuously generate new leases every nnn time as set by the user (e.g. every 2 weeks). This will allow an XS to be placed in a school and then it does not need Internet access or anyone from outside the school to continuously update the lease times. 


* Should support a GUI accessible from the XO which is password protected and encrypted (aka no passwords in the clear across the network/wireless). This GUI will allow a user in the school to enter an XO by serial number or better by name and have that XO added to the blacklist (see above, essentially its lease is not renewed). 


See also write up on "Actual security requirements": [[User:Mstone/Commentaries/Security_1]] and <br>
Server side "Blueprint" at: http://wiki.laptop.org/go/XS_Blueprints:Lease_and_update_server

|Specification=
* <trac>4043</trac>
* [[Firmware Key and Signature Formats#Version 2]]
* http://dev.laptop.org/~cscott/joyride-api/bitfrost.leases.crypto-module.html
* http://lists.laptop.org/pipermail/security/2008-June/000441.html
|Owners=
}}

{{Feature_request
|Name=Theft reporting
|Requesters=Peru?
|Requirements=
Sometimes known as 'active kill'. If the laptop is stolen, the serial number can be added to a 'stolen laptop' list so the laptop's activation can be turned off the next time it finds either a local school server or a global tracking server. 

* A trusted administrator can log into a central system (either regionally controlled or OLPC controlled) and add a serial number to the 'Stolen' list. 

* Any laptop that connects to a local or global server that finds a match on the 'Stolen' list, and it was originally activated with an activation key, will be de-activated.

* The security must ensure that the person adding the stolen laptop is a person who has been given that access; and that the server causing the de-activation is a server that has been given that right. 

* Re-activating the laptop again requires the same procedure as initial activation or lease management.
|Specification=
|Owners=
}}

{{Feature_request
|Name=XO monitoring
|Requesters=Peru
|Requirements=Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs such as:
* Version of code
* Which laptops are being seen each day
* Total number of laptops being seen per day
* Number of laptops accessing the internet
* List of URLs being accessed
* List of URLs per laptop
* Which activities are being used per laptop
* Number of minutes in each activity per laptop; can we determine (and subtract) idle time?
* Number of minutes in each activity within and outside of school hours (perhaps this means we capture the 'start' time of each activity and allow the reporting to decide if this is during or outside of school hours).

This is not as high priority for their deployment as the passive lease management, but I believe this feature will be important for any deployment. We should try to get feedback from other deployments as to the information we want to collect.
|Specification=
I (Kim) think there might be some work in the XO to make the information available; and a database and API spec from the school server.
|Owners=Kim
}}


{{Feature_request
|Name=Improved antitheft mechanisms
|Requesters=Scott
|Requirements=
* ECO fix and EC improvements
* Security control panel, with "am I stolen" and lease renewal buttons: <trac>1502</trac>, <trac>6428</trac>
* olpcrd work: <trac>7397</trac>
* Revoke root capabilities when booted with security enabled: <trac>7562</trac>
* See also thread started by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020388.html
|Specification=
|Owners=Scott
}}


{{Feature_request
|Name=Security and isolation work
|Requesters=Scott
|Requirements=
* Implementation of P_SF_CORE, P_SF_RUN
* Mechanism to validate updates to loopholed activities & allow user to manage exceptions
* Persistent activity storage
* NSS modules for rainbow users and for olpc/root users
* Rainbow
* See also: http://lists.laptop.org/pipermail/devel/2008-October/020403.html
|Specification=
|Owners=Scott
}}

== Network ==

{{Feature_request
|Name=802.1x support
|Requesters=Uruguay
|Requirements=
* Must allow association with APs running 802.1x
|Specification=http://en.wikipedia.org/wiki/IEEE_802.11#Standard_and_amendments
|Owners= Chris
}}

{{Feature_request
|Name=Reliable access to encrypted APs
|Requesters=G1G1
|Requirements=Must reliably (better definition needed) associate with APs running WEP, WPA and WPAv2
|Specification=
|Owners=
}}

{{Feature_request
|Name=Network Manager GUI
|Requesters=
|Requirements=
* What needs to be done, is a way (via the control panel), to be able to select which interface Salut is going to use. That can be accomplished by 
only enabling multicast on the interface selected and turn it of on the other. This is always needed for XOs that have internet sharing enabled b.t.w.

* Without a control panel, a good default choice would be to disable multicast on the mesh interface (ifconfig msh0 -multicast) if eth0 is associated.

* Enable Internet sharing (with pull down menus from which interface to what interface - eth0 to msh0 being the default)

* disabling the mesh interface completely (for backwards AP compatibility)

|Specification=
|Owners=
}}

{{Feature_request
|Name=Document and Improve default network connection
|Requesters=?
|Requirements=
Better default network connection choice algorithm (e.g. if USB - Ethernet is connected, use it first source: A Callahan).
: This already happens, but perhaps there are bugs. -[[User:DanielDrake|DanielDrake]] 16:37, 3 October 2008 (UTC)
This algorithm should be "smart" in its first choice but should also be adjustable in the GUI.
* Must include choosing wired over wireless, choosing one AP vs. another and choosing Mesh vs. AP.
* Must minimize time trying to connect to an AP not desired (e.g. must not try to connect to mesh when user expected AP).

Needs further definition.
|Specification=
|Owners=
}}


{{Feature_request
|Name=XO as internet gateway (formerly called MPP)
|Requesters= Uruguay, Kim, Michailis
|Requirements=
|Specification=
|Owners=
}}


{{Feature_request
|Name=Full IPv6 support
|Requesters= Marc Blanchet
|Requirements=
Verify, test and add whatever needed to support IPv6 on OS, apps, etc...
|Specification=
|Owners=Marc Blanchet
}}

{{Feature_request
|Name="Asynchronous internet"
|Requesters= Scott
|Requirements=
|Specification=
* Integration of wwwoffle with small local cache
* Content bundles to seed that cache
* Mechanism to request downloads later
* See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020409.html
|Owners=Scott
}}

== GUI and usability ==

{{Feature_request
|Name=Remove the "frame" feature
|Requesters=Joe
|Requirements=Remove the "frame" feature.
|Specification=Remove the "frame" feature altogether. Concentrate all icons either in the bottom or the top of the screen, make them much smaller, also reassign the related to "frame" keyboard's key to do something more useful. Benefits: more useful screen's real estate, no delay currently experienced while switching the frame, especially by using a cursor. Simpler is better, isn't it?
|Owners=
}}


{{Feature_request
|Name=Hardware alerts
|Requesters=Uruguay
|Requirements=http://lists.laptop.org/pipermail/sugar/2008-July/007086.html
|Specification=Designs ideas from Scott and Eben in thread. e.g. I hope our alert system will use the freedesktop.org standard: http://www.galago-project.org/specs/notification/index.php There is a visual design for the [[Designs/Activity_Management|notification system]] as well.
|Owners=
}}

{{Feature_request
|Name=Contextual help
|Requesters=Brianne
|Requirements=
One idea from Eben. From: http://lists.laptop.org/pipermail/sugar/2008-August/007547.html <br>
All of our initial discussions on help focused around a contextual help system, and I still hope that this is where we'll be taking this in the future.  By embedding (?) icons within the secondary palette menus for various devices, objects, activities, and even individual buttons and controls, we can provide a way to launch into the help activity and dive directly to the relevant info for the activity, control, etc. selected.  In addition, I'd like to support a community driven help system by which, in addition to the activity/olpc provided help, it's possible for kids to add tips, tricks, images, tutorials, and other info to these sections for later consumption by peers.

This is a noble, but ambitious goal, which is why a simple and static help activity is the present solution, and why it's only integrated into the system at a single point - the activity itself.
|Specification=
|Owners=
}}

{{Feature_request
|Name=Trash can
|Requesters=Bastien
|Requirements=http://lists.laptop.org/pipermail/sugar/2008-August/007889.html
|Specification=
|Owners=
}}

{{Feature_request
|Name=Scalable zoom levels
|Requesters=UI Team, Collabora
|Requirements=We need to support a mechanism for auto-filtering the view to a "reasonable" set of activities and XOs, and provide rich mechanisms (search and filters) for adjusting one's perspective on the view to find items of interest.
|Specification=Gadget is the core of this effort.  We need some additional UI work to hook it up.  One aspect of the solution is the addition of list views to all zoom levels, making it possible to list the entire set of people, activities, access points etc, see their icon and name at a glance, sort alphabetically or by type, and also filter as desired.
|Owners=Eben, Collabora
}}


{{Feature_request
|Name=Keyboard navigability
|Requesters=Homunq
|Requirements=All options in the menu and frame should be accessible from the keyboard (ctrl-xxx). There should be some way to see what key is associated with a given option, both when using it and when "looking for the key". This should require a minimum (ideally, zero) programming from activity developers. This is a key part of the strategy for improving the situation of bad trackpads; it is unrealistic to expect the trackpad problem to be 100% resolved.
|Specification=Holding the control (or frame) key should show semitransparent letters/numbers over any menu (or frame) gadget visible. These letters should also appear for ~150 ms when an option is chosen. Default letters should be chosen by the relevant python classes if not specified by developer. Any specification should be localizable. Ideally, contextual menu options should be accessible with multiple keystrokes.
|Owners=Homunq, ??
}}

{{Feature_request
|Name=GUI suggestion from SJ
|Requesters=Homunq
|Requirements=Adding basic interface pieces that we want to support in the long term, and making them do something familiar, reliably, every time they are at hand.  "escape", "stop/start", "share", "view source", "keep", "cut" and "paste" should all do fairly reliable things across activities.  Make them do something recognizable even when the activity developer hasn't provided an app-specific hook for same.
|Specification=
|Owners=SJ
}}

{{Feature_request
|Name=Journal improvements
|Requesters=Scott
|Requirements=
|Specification=
* Proper display of 'new versions' of activities
* Tagging system to allow folder-like management for advanced users
* Datastore rework
* Direct execution of activities from datastore (avoid installation step) <trac>7713</trac>
* Ability to have multiple versions of an activity installed concurrently. (API work necessary: <trac>7713</trac>)
* See also http://lists.laptop.org/pipermail/devel/2008-October/020385.html
* Upgrade journal per: [[OLPC Human Interface Guidelines/The Laptop Experience/The Journal]]
|Owners=Scott, Eben
}}

== Server ==
Full list of Trac IDs for server roadmap is here: <br>
https://dev.laptop.org/query?status=assigned&status=new&status=reopened&group=milestone&component=school+server&order=priority&col=id&col=summary&col=status&col=priority&type=enhancement

{{Feature_request
|Name= Automatically recognize XO on restore page
|Requesters= Reuben
|Requirements=
* Must allow XO to see their own files when going to the URL representing the backed up files from that XO.
* Must not require the user to type in the name or serial number of their XO.
* See related single sign on feature.

|Specification=
|Owners= Greg 
}}

== Linux and OS ==
{{Feature_request
|Name= Rebase on Fedora 10
|Requesters= Ed
|Requirements= <br>
* XO release 8.2 contains a list of packages (some forked and some not). For must 9.1.0 we must update all packages to their Fedora 10 versions and re-apply XO specific changes, as needed, to the new Fedora 10 package.
* Every package should also be included upstream. If that has not been completed in time for this release, every package must at a minimum have a plan for how it will get included upstream. This must include at a minimum an e-mail exchange with the package.
* Must measure the NAND and memory usage vs 8.2. Any significant (not precisely defined as >1%) change in memory or NAND space in comparison to 8.2, must be reviewed.
* Must not include any Fedora 9 or earlier packages (unless they haven't changed).
* Should create tools to manage forked packages better.  To start with: a notification tool to let us know if a new upstream release has occurred for a package we have forked. (Scott suggestion). See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020411.html

|Specification= 

|Owners=None yet.
}}

{{Feature_request
|Name= Run Fedora applications on XO
|Requesters= Ed
|Requirements= <br>
Overview. This feature is designed to address the persistent requests to run more applications. An alternative approach would be the "easy sugarization" feature above. This implementation is currently preferred because it also helps us get all the XO software "upstream". That would bring in more developers and add flexibility for XO users.

* Only needs to run Fedora applications which fit in the available NAND space, memory and CPU.
* Must run as well on the XO as they would on any other computer 433Mhz 256 MB RAM.
* Must allow switching between a Fedora 10 based spin with a conventional desktop manager and XO running Sugar, and back.
* Must fit on the XO NAND along with the Sugar based XO image with enough space left (exact amount tbd) for user data.
* Must/should? allow this on all XOs shipping with XO release 9.1.0. That is, an XO which ships with Sugar
* Must support camera, microphone, speakers, wifi 802.11 A/B/G, touchpad, Keyboard, USB interfaces, and SD interface.
* Does not need to make it easy to share files between Fedora and Sugar.
* Must not need a developer key to switch to Fedora implementation.
* Must fully support Yum.
* Must come with nnnn applications on default install (will be chosen and will be a very minimal set).
* Must boot as fast as Sugar.
* Must support upgrading the Fedora version and the Sugar version in 9.2.0 and future releases.
* Must not keep two copies of any files or libraries. Any file which is exactly the same on both Sugar and Fedora images should be used by both and should not take twice the space.

* Open issue about Security. How do we protect security and still make Fedora + "standard" window manager available? GS

|Specification= 

|Owners=None yet.
}}


{{Feature_request
|Name= NAND full should not crash XO
|Requesters= Uruguay
|Requirements=
* Must allow access to the journal and other parts of the file system to delete items, even when the NAND is full
* Must allow the user to choose which items get deleted to clear space.

|Specification= 
{{ticket|7590}} Must allow deleting files when the NAND is full.

|Owners=Greg
}}


{{Feature_request
|Name= Replace JFFS file system with better one
|Requesters= Deepak
|Requirements=
* End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up.

|Specification= 
The current file system used on the XO ([[http://en.wikipedia.org/wiki/JFFS2 JFFS2]]) was developed in the days of 32/64MiB NOR flash devices and does not scale well to the 1GiB NAND devices we are using today and certainly will not deal well with larger devices in gen 1.5 and gen 2 systems. The main issues are that JFFS2 needs to scan all blocks at mount time and that the garbage collection algorithm increasingly consumes CPU cycles as the system fills up. The first issue manifests itself as large delays at boot up to mount the file system as it is full (need to quantify this), and the second issue simply means less CPU cycles can be dedicated to user task processing. In the last few years, there has been much activity in the embedded Linux world on alternatives to JFFS2 and we need to investigate these to determine which one best fits our needs:

* [http://www.yaffs.net/ YAFFS2] : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files.

* [http://www.linux-mtd.infradead.org/doc/ubifs.html UBIFS]: A new file system recently merged into the kernel designed for use on large flash devices. Supports compression out of the box and supports disabling compression on a per-inode basis, which is something we desire.

* [http://logfs.org/logfs/ LogFS] : Another JFFS2 replacement designed for fast operation and scalability. Still fairly new and not in very active use AFAIK.

* [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs] : A very new file system that is primarily targeted for large storage systems with features such as snapshotting, RAID support, and online fsck. David Woodhouse has expressed that he will look into getting this to work on NAND, but it is too new of a code base to consider for 9.1

* Managed NAND : (Not an option for existing XO machines, but might be a direction for future hardware)  The industry seems to be moving away from raw NAND in favor of a NAND-chip plus microcontroller solution.  The microcontroller implements a Flash Translation Layer that hides the low level NAND details, presenting a higher level interface that looks like an ordinary hard disk, so an ordinary filesystem layout like ext3 could be used. The driving force behind managed NAND is rapid hardware evolution toward multi-level-cell NAND chips and smaller process geometries, which change important NAND parameters like page sizes and ECC.  The situation is similar to what happened with hard disks in the 80's, where raw-disk interfaces gave way to SCSI and IDE, which hide the ugly low-level details that changed every technology generation.  Managed NAND options include LBA-NAND from Toshiba (pin-compatible with NAND chips), eMMC from multiple vendors (with an SD/MMC-compatible hardware interface), and various "disk on chip" products (IDE-compatible interface).

'''Development process''' <br>

* Analyze and quantify the use patterns that trigger issues with JFFS2.
* Gather requirements for a new file system that go beyond solving above issues.
* Develop/integrate a set of tests for FS performance and reliability that take into account our use patterns, the above issues, and any other features we wish to validate.
* Study the three main alternatives (YAFFS, UbiFS, LogFS) to determine what requirements they meet
* Run our FS test suite on above alternatives
* Analyze test results and requirements study and make a decision on which alternative to use.

'''Deployment process''' <br>
Once a file system is chosen from the above process, we will have to: <br>
* Integrate the file system into our kernel if it is not upstream (YAFFS2 or Logfs)
* Integrate the file system support packages into our build system and file system images
* Update our build scripts to generate the proper image type for

'''Activity impact''' <br>
This change should not have any impact on activity developers as it is at a very low level of the stack.

'''End-user impact''' <br>
End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up.

|Owners=Deepak
}}


{{Feature_request
|Name=Copying files between Journal and USB
|Requesters=Bastien, Uruguay
|Requirements=As close to one click to copy files from Journal to USB.
|Specification=

* Possible solution outside Sugar underway here: http://code.google.com/p/ceibal-sysox/ 

|Owners=Greg
}}

{{Feature_request
|Name=File name and directory access
|Requesters=Gnu, Ben, Erik, Greg, Marvin
|Requirements=Allow listing, copying and finding files with standard Unix commands in the terminal view. See also point #1 at: [[9.1.0#e-mail from Ben S]]
|Specification=
|Owners=
}}

== Other ==
{{Feature_request
|Name=Printing support
|Requesters=Scott and others
|Requirements= 
* Print postscript (or pdf, or whatever, just pick *one*) to school server via CUP (IPP?), and install a "decent selection" of printer drivers on the school server.  Control panel for 'default printer name', fixed to 'XS' by default.
* Add basic printing support to Write, Read, and Browse; set PRINTER env variable.
* for future, add support to Paint, Record, etc.
* See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020414.html
|Specification=
|Owners=Greg
}}


{{Feature_request
|Name=System clock
|Requesters=Birmingham and seen on devel list (anyone have time to search for the threads?)
|Requirements= 
* Must have a clock on the XO. Can be visible in the frame or built as an activity. If built in to the frame, must be configurable in graphical control panel to show it or not.
* Must allow analog (aka hands) or digital time.
* Must allow setting the time. (also sets the XO's time Linux? if so allow configuring NTP?).
* Should include an alarm clock and a stop watch mode.
|Specification=
|Owners=Greg
}}


{{Feature_request
|Name=Library and bundle updates
|Requesters=SJ
|Requirements=
* '''thought experiment''' : how does one present an activity (has its own isolation-friendly code) that includes a library bundle (its own browser-browsable static content, help and supplemental materials) and a generic resource bundle (a repository of sounds and images) look like?  How do other parts of the system (the Journal, Browse, other activities) see and interact with these three collections of material (to browse and copy the code, to view the static content, to aggregate the resource collections with other collections)?
* a [[Dynamic library]] implementation
* coordination of a unified help interface building on top of the library bundles defined for each activity on the system. 
** integration of some way to update and share this.  related to how to leave a comment on/about an activity or file/resource
* coordination of local library bundles, and regional caches of viewed material, school server caches of bundles, and web caches.
* cleaner display of available bundles via a bundle updater; relatd to but not the same as the current software upgrade function, which has a strong emphasis on olpc-stamped/signed materials

|Specification=
* API and .info unification across content and activity bundles.  Making both and a general [[generic bundle]] clearly described within an overarching bundle format.  
<br>
Suggestions from Scott below <br>
* The current API is a mess, doesn't match the documentation on the wiki, is inconsistent with the activity.info format, etc.
* Merging content and activities -- a bundle ought to be able to have *both* a library.info *and* an activity.info
* Using a content format which is consistent with "offline internet" content -- more or less consider installing content files as pushing stuff into an offline cache
* Dynamic generation of the top-level "home" page so we don't need to run the indexer after installing content bundles.

|Owners=SJ
}}

{{Feature_request
|Name=Screen zoom
|Requesters=Greg
|Requirements=
This idea came from watching kids and grownups gathering around an XO and trying to see what someone else is doing. <br>
* Must allow zooming the screen in so that a portion of the screen is "magnified"
* Must allow centering the zoom on different parts of the screen. Possibly chosen by centering where the cursor is or possibly selecting a box with drag or keyboard input.
* Must allow several zoom (magnification not sugar zoom levels) levels, preferably a smooth range from 1x to 10x
* Must allow scrolling to move the magnified image to see things otherwise off screen. Preferably a smooth scroll but can be discrete steps if needed. Must allow scrolling via cursor or keyboard input (keyboard needed in case XO has a gimpy cursor). Must allow user choice of scroll input by user configuration (cursor or keyboard).
* Should allow one touch snap back to 1:1.
* Should have as clean interpolation as possible.

|Specification=
Ben said that the Geode has HW scaling with interpolation. This feature should come at no/bare minimum cost to CPU cycles and performance.

|Owners=Greg
}}

{{Feature_request
|Name=Universal view-source
|Requesters=Tomeu
|Requirements=One more step towards implementing the original vision of the [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/View_Source|"View source" key]]. <br/>
* Must work on all activities deployed in well-formed [[Activity_bundle|activity bundles]].
* Must display all files inside the activity bundle and provide a means to show the source code that there may be.
* Must open in a window local to the activity displayed, so doesn't interfere with other activities not the Sugar Shell.
* Must allow for activities to override this default behaviour and implement their own, specific source viewers.
|Specification=See [http://lists.laptop.org/pipermail/sugar/2008-October/009495.html this thread] for an implementation proposal.
|Owners=Tomeu
}}

{{Feature_request
|Name= Developers Center web site
|Requesters=[[User:Mchua|Mel]]
|Requirements=
Strictly speaking, this is not a technical feature; however, like technical features, this would require developer time in exchange for enhancing our capabilities to implement and (commercially) support technical features, so I am including it here.

* A separate, non-community-maintained, website for formal user and developer documentation (Precedents: [http://www.redhat.com/developers/ Fedora/Red Hat], [https://help.ubuntu.com/ Ubuntu]), posted in a publicly viewable but edit-protected place. (i.e. not publicwiki as it now stands.)
* On this site, a canonical list of all the technical subcomponents that make up the OLPC system that the organization supports.
* For each subcomponent, a howto/code-tour for the kind of developers we want to have working on that portion of the project.
** Note that this could be "Code is available for download, but community development is not officially supported by the OLPC organization," and a link to the all-community wiki (or appropriate pages as on SugarLabs).
* Intended audience: developers with code experience but no OLPC-specific project background
* Put a link in the library on the XO which links to GIT or other relevant source. (added by Gnu)


|Specification= If this were implemented mainly by developers, it would be a large task for the developer responsible for each subcomponent to take responsibility for creating this section. So instead, I would suggest putting the load on a single editor who would be in charge of talking with developers, asking them questions, and formatting their (objective: minimize the workload on developers as much as possible). I could see this being half-time contract work, maybe for 2-3 months during 9.1 development, to create and release a first version of a "developers' center" with an infrastructure that can be easily updated for future releases.

|Owners=None yet.
}}

{{Feature_request
|Name= Caps lock option
|Requesters= Jim
|Requirements=
#2447 make it easier to set caps lock to on
|Specification= 

|Owners=None yet.
}}

{{Feature_request
|Name=Fully comply with GPLv3
|Requesters=FSF and Gnu
|Requirements=
* Must audit and confirm GPL compliance before release
* Many possible Trac IDs. One example: http://dev.laptop.org/ticket/6892

|Specification=
|Owners=Greg
}}


{{Feature_request
|Name=Debug tool
|Requesters=Uruguay
|Requirements=
* Debug tool that easily allows plug of diagnostic USB stick which analyzes and reports back detailed status.

|Specification=
|Owners=ErikG
}}