Difference between revisions of "User:Sascha silbe"

From Sugar Labs
Jump to: navigation, search
(mention sl.o email address)
(add section with reminders about design work)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
Please see [http://sascha.silbe.org my homepage] for contact information. You can also send me emails to my sugarlabs.org account (silbe@).
+
Please see [http://sascha.silbe.org 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:
 
;Country:
 
:Germany
 
:Germany
 
;Timezone:
 
;Timezone:
 
:CET (UTC+1) / CEST (UTC+2)
 
: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
 +
** [https://bugs.sugarlabs.org/ticket/2435 activity.info -> .desktop], activity and [https://patchwork.sugarlabs.org/patch/303/ non-activity .desktop launcher] on home screen
 +
** [https://bugs.sugarlabs.org/ticket/2434 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 [https://bugzilla.gnome.org/show_bug.cgi?id=633276 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.

Latest revision as of 11:35, 6 March 2011

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.