User:Sascha silbe

Please see my homepage for contact information. You can also send emails to my sugarlabs.org and activitycentral.com accounts (silbe@). On FreeNode and OFTC my IRC nick is silbe.
 * Country:
 * Germany


 * Timezone:
 * CET (UTC+1) / CEST (UTC+2)

= Medium to long term Sugar plans =

The goals

 * Make it hard to lose work accidentally
 * Make it safer to run potentially untrusted or buggy code
 * Make Sugar easier and better to customise by users so they "feel at home" and work more efficiently
 * Attract developers
 * Increase interoperability with non-Sugar systems and parts thereof
 * Accessibility
 * real Single Sign On

The means

 * Modularise Sugar core so users / developers can mix-and-match
 * split the "zoom levels" into separate modules
 * on low memory systems (XO-1) a single executable handles all zoom levels by default
 * on all other systems there are separate executables
 * replacing a single (or multiple) zoom level(s) with alternative implementations possible
 * bugs in one zoom level don't affect the others
 * shared UI framework uses GTK instead of HippoCanvas, icon view allows Neighbourhood-like searching and list view allows Home View-like searching
 * split out the Journal
 * let user "bless" an activity to provide the special services (switch to Details View, Object Chooser)
 * split out the Frame
 * activity.info -> .desktop, activity and non-activity .desktop launcher on home screen
 * use XDG start-up notification instead of custom protocol
 * Rainbow
 * run each activity / application in a separate session, identifiable and killable from the Frame
 * show "activity start failed" screen if all processes finished (rainbow-run returns) before start-up notification has indicated the activity is running
 * if start-up notification times out, show "activity start failed" screen with option to wait a bit longer or abort
 * kill remaining processes on failure (timeout)
 * keep activities in Frame until all processes have exited
 * add option to kill session (i.e. all remaining processes) to Frame
 * "legacy sessions": start XDG applications in a session as describe above
 * full X session including window manager, using VNC
 * replace GTK file chooser dialog with Object Chooser invocation
 * set $HOME to temporary directory, save & restore the contents on Stop resp. resume
 * kill off window manager and "standard" daemons (e.g. gconf) after application returned
 * Replace copy of gnome-session with configuration files for and dependency on latest gnome-session
 * Version support
 * eventually integrated with in-activity Undo/Redo
 * gpg-agent and/or gnome-keyring (GPG, SSH, X.509, hardware token support)
 * in-Frame pinentry (allow/deny request, password optional) highlighting the activity (isolated session) that requested the operation
 * automatic "log-in" to (SL, XS) web sites using client "certificate" (server extracts public key and uses it for identification/authentication, supports multiple keys per account)
 * Telepathy client changes
 * interoperability with non-Sugar Telepathy clients
 * Account Manager (blessed activity or control panel section)
 * Salut account added by default, but deactivatable
 * not sure how exactly to handle it, but we should support registering to multiple XSs and require only a single UI interaction for doing so (add Jabber account automatically, but deactivatable like all others)

TODO

 * Add "The benefits" section
 * point out which goals have progress metrics that are cheap to measure

Potential future design work

 * Journal entries on external media: Indicate whether the data file was changed, so that the preview is stale now? (silbe)
 * Some previews might be (re)generated automatically. Because this might take considerable time, the details view would need to indicate (re)generation is happening, e.g., via a "loading" animation.