On Sun, Oct 27, 2013 at 5:50 PM, Alberto Mardegan <[email protected]> wrote: > On 10/25/2013 08:48 PM, Thomas Voß wrote: >> One thing that strikes me: Instead of trying to solve the problem a >> lot of "won't work" statements are made in this thread, going along >> with a request for removing all of the lifecycle policies. And to be >> clear: With strict policies in place, it is always possible to find an >> example that breaks. So I think we can stop collecting breaking >> examples here. > > I think that Ubuntu should strive to do *better* than other platforms, > not equal or worse. So, given that we are at the early stages and we are > still in a position to correct the design and improve the > implementations, we should spend some time to think of use cases which > we don't support with the current design, and address them. >
Sure. > Especially given that it might not be easy to change this stuff in the > future. > That I fully agree with, and for that, we should be very careful about which features and capabilities we grant to applications. >>> Yes and no. As I wrote before in this thread, in some cases it's >>> possible to detect when an application will need to run or can be >>> killed. We don't have to allow all applications to run in the >>> background. But why not let a navigation application declare in its >>> manifest file that it wants to be left running if it's defocused while >>> the GPS is on? >> >> Because that is an open invite to any app developer to leverage that >> way out, too. We do not do install time application permission >> verification by the user for a good reason. > > I think we are misunderstanding; I'm not saying that the user should be > asked (at install time or at run time) for granting a permission. There > would be a policy groups "background_gps", "background_music" which the > app developer can declare in its manifest file. Then, if the application > is defocused while it's using the GPS or playing music, it wouldn't be > stopped. If it's not using the GPS or playing music, it will be stopped. > It seems much simpler to me, and I don't see what could go wrong here. > What prevents every app from just doing that? One example: When iOS had the policy of an app playing music not being suspended, a lot of applications just looped a whitenoise sound file to not be suspended. >>> As for GPU resources, Qt can release all of them when the window is not >>> exposed, if told to. >> >> Hmmm, people said that about cooperative multi-tasking, too: Sure, the >> app will happily give up its timeslice (tm). > > You are right that we cannot depend on this. But the display server can > know the amount of GPU resources that each application is using, and > kill those which use more of them; in this way, an application which > properly releases all the GPU resources would probably be saved. > Anyway, I now realize that this is actually not the issue we were > discussing (this is about killing, while the discussion is about > stopping), so we can forget about this second topic. :-) > Sure, we can be clever about graphics resources, but at some point, we would need to destroy the apps egl context and require toolkits/apps to be EGL context robust and being able to handle that case. Of course, this is not a blocker, just something we do not have right now and which would require effort to implement. Thomas > Ciao, > Alberto > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
