[sugar] Developer Console
Marco Pesenti Gritti
Mon Oct 8 18:59:32 EDT 2007
do you have any idea or suggestion on how to handle this from the
security point of view?
Clearly the Terminal and the Memory activity would not work inside a
On 10/8/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> > 1) Terminal-Activity, included by default in sugar but hided from the
> > activities launcher menu. Can be activated with some key binding as
> > 'alt + 9'.
> This sounds really great. I don't think we have to hide it
> permanently. I think any kid that wants to should be able to place
> this activity in the frame. I personally have the Terminal in my
> Dock, and it's even in my startup items. If we don't include
> pre-installed activities in the Journal (there are mixed feelings on
> this), then I'm not sure how that could be accomplished, though.
> > 2) Create a simple Shell View with system information as: kernel
> > version, build version, Serial Number, Activities information (bundle
> > size, author, version...), CPU usage, presence service, etc
> I might suggest making an "About this XO" type section within the
> forthcoming control panel. It seems that information such as build
> number, serial number, and other hardware specs would be useful to
> make easily accessible. They relate directly to the XO itself, just
> as the system prefs do, so I think this is a logical place for them.
> (Relates to http://dev.laptop.org/ticket/900)
> > 3) Memory Analysis acivity: An activity based on developer console
> > where is possible to get different stats about the memory usage by: X
> > Server, Activities, System process, etc.
> This seems reasonable. It's akin to the "Activity Monitor" in OSX.
> > 4) Logviewer, an activity?, a shell view?, a separate gtk program ?
> Also reasonable. Akin to the "Console" in OSX. (I mention these
> similarities because it's nice to see that an OS has already broken
> down tasks in these ways. It could be useful to see what types of
> functionality these activities offer.
> Another important consideration, though, is how these actually
> function as activities. The Terminal can clearly be first class, and
> each session entry in the Journal can store the command stack and
> other bits of info (perhaps even environment settings?) which are
> recovered when that session is resumed. The session has meaning here.
> With the Activity Monitor and Console activities, it's much less clear
> to me that these have an associated state or create entries within the
> Journal. Maybe activities don't need artifacts (but this gets back to
> the difference between logging nouns (objects) and logging verbs
> (actions) in the Journal, which right now only does the former,
> - Eben
> Sugar mailing list
> Sugar at lists.laptop.org
More information about the Sugar-devel