On Sun, Aug 8, 2010 at 8:33 PM, Marco Pesenti Gritti <ma...@marcopg.org>wrote:
> On 8 Aug 2010, at 18:40, Tiago Marques <tiago...@gmail.com> wrote: > > The idea of killing activities with the content closed seems ok but it > would probably be a good idea to have a way to opt out of it for some apps. > I'm thinking a PDF that may be left open on purpose to serve as reference to > something, a browser window, etc. > > An opt out could be easily abused... In the PDF case the activity could be > closed and reopened under the hoods, without the user even noticing (well, > startup time aside). > > > Are you then proposing to use the LRU policy to do the killing? I'm > thinking that a popup with a cancel tied to a timeout may be a good idea. > Once it is not allowed to be killed, it should not try to again for the > session, or at least for a very large increase in query time. > > 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. > Good point. In my mind this was an opt out for a process LRU that wouldn't be filling up the whole memory needed by another one, in that case the confirmation would become a notification. I think it's better to notify than to keep the user clueless, thinking that the device is somehow broken. > > > 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. > Indeed. But this behaviour has to be properly explained to the user somehow, if previous state restore isn't possible at all. Best regards, Tiago > > Marco
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel