User:Sascha silbe

From Sugar Labs
Revision as of 10:35, 6 March 2011 by Sascha silbe (talk | contribs) (add section with reminders about design work)
Jump to navigation Jump to search

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.