User:Sj/thoughts

Things to address --

provide interrupts to inspect a halted system

• memory and disk thrashing: we should have a process and allocation of disk and memory that is never touched by normal activities or processes, and is only available to a low-level disaster-recovery process that kicks in when reflection indicates some sort of deadlock or race condition... or that is always triggered by entering some key combination (similar to the interrupt of ctrl-alt-del or the power key on some systems).
  • todo: define a key combination that will always stop all other activity when processed, and give you a "view system state" experience. This alone is a valuable version of showing source.
  • short-term : have sugar / x / the things they talk to all in one group of memory usage, to ensure that this in particular doesn't cause total lockup.

show source

• we should bind a key on the keyboard, not a key combo, to "view source" -- and make this always work to some degree. If there is no explicit affordance for viewing source in an activity, make this feature show you metadata about the application, the language it is written in, where its source code is available online, what licenses it is using, what system resources it is using, when it was started... whatever info is already available through the system.
  • there should be a standard set of 'display' libraries for providing a uniform source-viewing look and feel for devs who dont' want to have to create their own; part of sugar, though it can be skinnable like all parts of the interface

show more information in core views

• per activity : show how much space each activity is taking in memory in the frame. refresh every few minutes based on a system poll of some sort?
  • focus on providing enough information to assess relative consumption of different activities, to see which ones are getting bloated / are weighty
  • focus on information we can definitely monitor, such as the # of unmapped pages in the system, which give a view of how the system as a whole is developing / being used

• per neighborhood : show how reliably connected each XO and access point is, how 'strong' their connectino is in some sense. find metrics that are meaningful and display the results simply
  • remember some of this information and show it in the view about a given friend or access point. wait -- this means we need such a view!

interface skinning

• every part of sugar should be skinnable. this is one of the most enjoyable and addictive forms of system hacking, and easy to get started with -- just copying a set of files from a friend, and being told where to put them, with immediate and powerful results. Within activities, this applies as well -- activity devs shouldb e encouraged to use shared libraries and skint hem, building a thriving and strong core, ratehr than being encouraged to develop their own everything simply to be visually unique.
  • todo: determine a set of interface components