[Sugar-devel] Fwd: Activity startup idea

[Eben Eliason]

On Mon, Mar 9, 2009 at 1:10 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Mon, Mar 9, 2009 at 17:52, Wade Brainerd <wadetb at gmail.com> wrote:
>> On Mon, Mar 9, 2009 at 9:56 AM, Gary C Martin <gary at garycmartin.com> wrote:
>>>
>>> On 9 Mar 2009, at 13:28, Tomeu Vizoso wrote:
>>>
>>>> On Tue, Feb 24, 2009 at 03:38, Wade Brainerd <wadetb at gmail.com> wrote:
>>>>
>>>> What about watching system resources and refusing to start a new activity
>>>>>
>>>>> when there isn't enough RAM available to launch it?
>>>>> It should be pretty straightforward to add a required_memory field to
>>>>> activity.info - it would be a simple, approximate high water mark memory
>>>>> usage for a given activity.  The default could be determined by
>>>>> analyzing
>>>>> the basic activities - maybe 20mb would be good?
>>>>
>>>> Are we sure this is a good experience for our users? I remember that
>>>> in the old MacOS times, I found a bit tiring to have to go to the
>>>> applications' info panel to lower the memory limits so the app could
>>>> launch.
>>>
>>> Yea, that was rather a frequent support call back in my early Adobe days
>>> :-) Set it too low and they can't open some document, to high and they can't
>>> run the other couple of applications they needed open at the same time to
>>> work.
>>
>> Even a warning alert would be better than nothing.
>> Your computer is too low on memory to start this activity.
>> Are you sure you want to start Browse?
>
> This I like more than refusing to start the activity. And Ben's
> suggestion about being the shell to calculate it is interesting.

Alerts were a consideration behind the "new" fullscreen launcher
approach, actually. At the time, we wanted a nice way to indicate
failure of an activity to launch, and our answer to that was a message
beneath the icon in the launcher, buttons as necessary, and a
notification from the activity when the alert appeared.  For a launch
failure we could provide (Give up) (Show logs) (Try again) options,
for instance.

In the memory case, we can have a memory warning message with (Cancel)
and (Launch Anyway) options.

>> It happens to me at least once every couple of days on build 767...first the
>> UI freezes, then the trackpad stops responding, and if I'm lucky I can
>> manage to Ctrl-Alt-F1 and kill Browse before having to just hard power off.
>>  And that's just with GMail (in Browse), a Terminal, and Typing Turtle
>> (which is admittedly a memory hog due to all the cached key graphics).
>
> Wonder if compcache would help you there?
>
>> Also, I think we should really consider implementing that kernel OOM watch
>> feature.  Activities save their state when you tab away from them, so in a
>> lot of cases it's safe to just kill background activities.
>
> Yes, I like this scenario. If we can give a low kill priority to the
> shell, wm, X, etc and to the activity in the foreground and a high
> kill priority to the activities in the bg, I think that stability will
> get much better. But in that case we need to provide a good way to
> explain to the user that a background activity was killed and why.

This sounds like another good use for the launcher.  What if the
activity didn't just "go away completely"?  Instead, we could kill the
activity, but replace it with the launcher again, with a colored icon
representing the instance which was closed (instead of the pulsing one
at launch).  It could indicate that the activity was paused due to
memory concerns, and that clicking the icon will resume the activity.
We could also have (Stop) and (Resume) buttons, of course.

- Eben

> Thanks,
>
> Tomeu
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>