[Sugar-devel] Fwd: Activity startup idea

[Wade Brainerd]

On Mon, Mar 9, 2009 at 1:19 PM, Eben Eliason <eben at laptop.org> wrote:

> 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.
>
> >> 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.


Excellent ideas.

I like how in this proposal the frame icon won't just disappear when the
activity is killed.  It's also great that the information about what
happened is available immediately when you next try to switch back to the
activity.

Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090309/78242a71/attachment.htm