Ivan, Michael, 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 container...
Marco On 10/8/07, Eben Eliason <[EMAIL PROTECTED]> 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, > technically. > > - Eben > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
