Difference between revisions of "User:Sascha silbe"

From Sugar Labs
Jump to navigation Jump to search
(add some more "means")
(add section with reminders about design work)
 
(2 intermediate revisions by the same user not shown)
Line 9: Line 9:
  
 
== The goals ==
 
== The goals ==
* Make it hard to loose work accidentally
+
* Make it hard to lose work accidentally
* Make it safe to run potentially untrusted or buggy code
+
* 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
 
* Make Sugar easier and better to customise by users so they "feel at home" and work more efficiently
 
* Attract developers
 
* Attract developers
Line 28: Line 28:
 
*** let user "bless" an activity to provide the special services (switch to Details View, Object Chooser)
 
*** let user "bless" an activity to provide the special services (switch to Details View, Object Chooser)
 
** split out the Frame
 
** split out the Frame
** activity.info -> .desktop, activity and non-activity .desktop launcher on home screen
+
** [https://bugs.sugarlabs.org/ticket/2435 activity.info -> .desktop], activity and [https://patchwork.sugarlabs.org/patch/303/ non-activity .desktop launcher] on home screen
** use XDG start-up notification instead of custom protocol
+
** [https://bugs.sugarlabs.org/ticket/2434 use XDG start-up notification] instead of custom protocol
 
* Rainbow
 
* Rainbow
 
** run each activity / application in a separate session, identifiable and killable from the Frame
 
** run each activity / application in a separate session, identifiable and killable from the Frame
Line 41: Line 41:
 
*** replace GTK file chooser dialog with Object Chooser invocation
 
*** replace GTK file chooser dialog with Object Chooser invocation
 
*** set $HOME to temporary directory, save & restore the contents on Stop resp. resume
 
*** set $HOME to temporary directory, save & restore the contents on Stop resp. resume
*** kills off window manager and "standard" daemons (e.g. gconf) after application returned
+
*** 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 (add link to Gnome bugzilla ticket)
+
* 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
 
* Version support
 
** eventually integrated with in-activity Undo/Redo
 
** eventually integrated with in-activity Undo/Redo
* gpg-agent and/or gnome-keyring
+
* 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
 
** 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)
 
** 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)
Line 53: Line 53:
 
*** Salut account added by default, but deactivatable
 
*** 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)
 
*** 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 10: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.