[Sugar-devel] <Ctrl>+<Alt>+<BS> handling (was: Re: [PATCH 4/5] sl#3029: Localization fixes.)

[James Cameron]

On Tue, Jan 24, 2012 at 09:00:59AM +1100, Sridhar Dhanapalan wrote:
> On 24 January 2012 04:09, Sascha Silbe <silbe at 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/