On 8 August 2010 20:51, Marco Pesenti Gritti <ma...@marcopg.org> wrote: > On 8 Aug 2010, at 20:38, Lucian Branescu <lucian.brane...@gmail.com> wrote: >>> >>> Imo a confirmation popup would become annoying very quickly. Also if the >>> user refuses, the kernel will have soon to kill an activity, which is worst. >> >> Activities already write_file when they lose focus, they could >> write_file periodically or at least when warned of low memory. > > Yes, that's how I think it should work. Of course activities will need to do > a better work to save all the possible state, because we are closing without > user intervention. > >> >>> >>>> Apps like instant messaging(though I don't recall one for Sugar), would >>>> definitely need a definitive opt out, no? >>> >>> Yeah, that's where things get tricky :/ Same issue with a background music >>> player for example. Ideally we would just keep the connection open somehow >>> and close the whole UI, but that's going to get complex. >>> >>> As long as this causes just minor annoyances to the user (like being >>> disconnected or music stopping), I think it's probably something we don't >>> need to solve in the first iteration. >> >> Separating the activity from the service would help here. In the case >> of music, MPD would use a lot less memory than one of its GUIs. > > Right, I was thinking to something along these lines too. I'm not sure how > the shell would enforce this policy though. Maybe we could allow the activity > processes to use a minimum amount of memory when it has been asked to close. > As I said, it gets complicated :)
An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
