On Tue, Jan 24, 2012 at 09:00:59AM +1100, Sridhar Dhanapalan wrote: > On 24 January 2012 04:09, Sascha Silbe <si...@activitycentral.com> wrote: > > Excerpts from James Cameron's message of 2012-01-20 05:35:21 +0100: > >> On Fri, Jan 20, 2012 at 09:42:34AM +0530, Anish Mangal wrote: > >> > Yes, you're correct in pointing out that ctrl+alt+erase won't work in > >> > OLPC builds (and in Dextrose-3 till now), but on request by > >> > OLPC-Australia, this key combination will be enabled in Dextrose builds. > >> > >> It might be handled by Sugar itself, in case the X server is configured > >> to allow it through. ?If Sugar project consider it important from a > >> documentation perspective, that's where it could be enabled. > > > > That's an interesting idea. It doesn't interfere with zapping in the X > > server if that is enabled, so no technical reason not to do it. We could > > alias it to <Alt>+<Shift>+Q (after fixing the latter to log out the user > > rather than shutting down the machine), so open activities get closed > > with a chance to save their state. The only downside is that it may > > teach users that <Ctrl>+<Alt>+<BS> is safe. > > > > Patch welcome. ;) > > The purpose of re-enabling this function was to provide a means to > restart Sugar if it became unresponsive, without having to wait for a > full reboot. This is useful in a classroom setting because children > always find new and interesting ways to mess things up :) > > The implemented solution would need to work even if Sugar appears to > be locked up.
That wasn't what I was suggesting. I was suggesting that Sugar should handle the keystroke if the X server does not. It should have no impact on your deployment's use of Sugar, since your deployment handles the keystroke in the X server. > The ideal solution would be for the OS to manage resources so as to > minimise the likelihood of lock-ups occurring, but that is a separate > debate. I don't think this is ever going to happen, because many lockups occur without any resource consumption. There are various ways in which Sugar may appear to be locked up, yet it is not Sugar that is locked up. Users will naturally conflate these ways and blame either Sugar, or the activity that triggered the condition. They will even blame their computer. The lockup recovery controls are: - the Stop button in the activity toolbar, for lockups of components of activities, requires the activity and the X server to be responding to controls, (scope: Activity), - the Stop button in the frame icon for the activity, requires the Sugar shell and the X server to be responding to controls, (scope: Sugar), - the Restart button in the menu that appears if the centre icon of the ring home view is right-clicked, requires the Sugar shell and the X server to be responding to controls, (scope: Sugar), - the X server zap, requires the X server to be responding to controls, (scope: OLPC, and other bootable Sugars), - the double power button push, requires powerd to be responding to controls, (scope: OLPC), - the extended power button push, requires the embedded controller to be responding to controls, (scope: OLPC), - the removal and restoration of all sources of power. Where a deployment has documented and already uses the X server Zap sequence (ctrl-alt-bs), it can continue to do so by making their own builds. Doing it that way is much more powerful, yet risks loss of unsaved information. If Sugar also handled the keystroke, when it is not handled by the X server, then the effect would be similar, though not as powerful. It is weaker because it requires that Sugar not be locked up. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
