Merge lp:~albertomilone/gnome-control-center/randr-virtual into lp:~ubuntu-core-dev/gnome-control-center/ubuntu

With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has been defaulted to off.

At UDS it was decided for Ubuntu to accept this upstream change, but to provide GUI mechanisms for GNOME allowing the user to switch it on or off.

This branch implements this mechanism.

Alberto Milone wrote:
> Alberto Milone has proposed merging lp:~albertomilone/gnome-control-center/randr-virtual into lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
>
> Requested reviews:
> VCS imports (vcs-imports)
>
> With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has been defaulted to off.
>
> At UDS it was decided for Ubuntu to accept this upstream change, but to provide GUI mechanisms for GNOME allowing the user to switch it on or off.
>
> This branch implements this mechanism.
>
I very much appreciate Alberto's work in implementing this, but would
like to test the decision against our commitment to ease of use. I think
enabling or disabling this feature in X is an expert option. I think we
can choose to enable it, or disable it, and of course we can allow
experts to change that through a config file or through a rebuild, but
this capability *should not* be exposed to end-users as a GUI option. It
will create more confusion than it will solve.

Mark

On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
> Alberto Milone wrote:
> > Alberto Milone has proposed merging
> > lp:~albertomilone/gnome-control-center/randr-virtual into
> > lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
> >
> > Requested reviews:
> > VCS imports (vcs-imports)
> >
> > With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has been
> > defaulted to off.
> >
> > At UDS it was decided for Ubuntu to accept this upstream change, but to
> > provide GUI mechanisms for GNOME allowing the user to switch it on or
> > off.
> >
> > This branch implements this mechanism.
>
> I very much appreciate Alberto's work in implementing this, but would
> like to test the decision against our commitment to ease of use. I think
> enabling or disabling this feature in X is an expert option. I think we
> can choose to enable it, or disable it, and of course we can allow
> experts to change that through a config file or through a rebuild, but
> this capability *should not* be exposed to end-users as a GUI option. It
> will create more confusion than it will solve.
>
> Mark

Dear Mark,

I see your concern but the option which my patch adds is very simple, see the
following screenshot:
http://albertomilone.com/ubuntu/gnome/gnome3.png

It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even mention the
word "DontZap".

A lot of users (see what's happening on ubuntuforums.org) will upgrade to
Jaunty and will be a bit shocked by this change. Most of them have learnt to
deal with X freezes (which are by no means infrequent) by using
Ctrl+Alt+Backspace. This doesn't make them "experts" though and it's very
likely that they are not aware of the existence of the DontZap option.

For this reason (as requested at the UDS) I implemented the same change in
Kubuntu:
http://albertomilone.com/wordpress/?p=312

I deem it a good compromise.

What do you think?

Alberto

Alberto Milone wrote:
> On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
>> Alberto Milone wrote:
>>> Alberto Milone has proposed merging
>>> lp:~albertomilone/gnome-control-center/randr-virtual into
>>> lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
>>>
>>> Requested reviews:
>>> VCS imports (vcs-imports)
>>>
>>> With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has been
>>> defaulted to off.
>>>
>>> At UDS it was decided for Ubuntu to accept this upstream change, but to
>>> provide GUI mechanisms for GNOME allowing the user to switch it on or
>>> off.
>>>
>>> This branch implements this mechanism.
>> I very much appreciate Alberto's work in implementing this, but would
>> like to test the decision against our commitment to ease of use. I think
>> enabling or disabling this feature in X is an expert option. I think we
>> can choose to enable it, or disable it, and of course we can allow
>> experts to change that through a config file or through a rebuild, but
>> this capability *should not* be exposed to end-users as a GUI option. It
>> will create more confusion than it will solve.
>>
>> Mark
>
> Dear Mark,
>
> I see your concern but the option which my patch adds is very simple, see the
> following screenshot:
> http://albertomilone.com/ubuntu/gnome/gnome3.png
>
> It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even mention the
> word "DontZap".
Alberto,

While setting the option is simple:
  1. It does make it too easy for novice users to inadvertently set up
their machines to do something that is potentially undesirable.
  2. Every option that we add to Ubuntu diminishes the value of every
other option. I think this is an important point to consider. Is this
option important enough to add to the cognitive effort that Ubuntu users
must invest?

Users have to stop and consider if they should use the option. What is
it? Should I care? At that point they have already paid a price.

Therefore, we should be absolutely certain that the benefit to users is
worth it. In this case, I wonder if the option really gives us an out
with the vocal users who don't want to see the option changed, and there
fore is meant to benefit us, not the users.

Thoughts?

Cheers, rick

On Thursday 29 January 2009 18:16:09 you wrote:
> Alberto Milone wrote:
> > On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
> >> Alberto Milone wrote:
> >>> Alberto Milone has proposed merging
> >>> lp:~albertomilone/gnome-control-center/randr-virtual into
> >>> lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
> >>>
> >>> Requested reviews:
> >>> VCS imports (vcs-imports)
> >>>
> >>> With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has
> >>> been defaulted to off.
> >>>
> >>> At UDS it was decided for Ubuntu to accept this upstream change, but to
> >>> provide GUI mechanisms for GNOME allowing the user to switch it on or
> >>> off.
> >>>
> >>> This branch implements this mechanism.
> >>
> >> I very much appreciate Alberto's work in implementing this, but would
> >> like to test the decision against our commitment to ease of use. I think
> >> enabling or disabling this feature in X is an expert option. I think we
> >> can choose to enable it, or disable it, and of course we can allow
> >> experts to change that through a config file or through a rebuild, but
> >> this capability *should not* be exposed to end-users as a GUI option. It
> >> will create more confusion than it will solve.
> >>
> >> Mark
> >
> > Dear Mark,
> >
> > I see your concern but the option which my patch adds is very simple, see
> > the following screenshot:
> > http://albertomilone.com/ubuntu/gnome/gnome3.png
> >
> > It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even
> > mention the word "DontZap".
>
> Alberto,
>
> While setting the option is simple:
> 1. It does make it too easy for novice users to inadvertently set up
> their machines to do something that is potentially undesirable.

This change requires root privileges (through PolicyKit) and won't have any
side effect unless Ctrl+Alt+Backspace is pressed.

> 2. Every option that we add to Ubuntu diminishes the value of every
> other option. I think this is an important point to consider. Is this
> option important enough to add to the cognitive effort that Ubuntu users
> must invest?
>
> Users have to stop and consider if they should use the option. What is
> it? Should I care? At that point they have already paid a price.
>

True. This will make users think when they open the screen resolution panel
but I think that the description is clear enough. A word like "restarts"
should be clear enough (even if you don't know what the server is) .

I didn't study Ergonomics though and I can be wrong ;)

> Therefore, we should be absolutely certain that the benefit to users is
> worth it. In this case, I wonder if the option really gives us an out
> with the vocal users who don't want to see the option changed, and there
> fore is meant to benefit us, not the users.
>
> Thoughts?

It seems clear to me that this change in X will cause a lack of consistency
(after a dist-upgrade) in the behaviour of the system. New users will probably
benefit from the change in X but some old users will not be pleased, others
may even think that something is wrong with their system (as we're not
speaking about advanced users).

I think of this patch as a compromise between leaving users...

On Thu, Jan 29, 2009 at 9:18 AM, Rick Spencer
<email address hidden> wrote:
> Alberto Milone wrote:
>> On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
>>> Alberto Milone wrote:
>>>> Alberto Milone has proposed merging
>>>> lp:~albertomilone/gnome-control-center/randr-virtual into
>>>> lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
>>>>
>>>> Requested reviews:
>>>> VCS imports (vcs-imports)
>>>>
>>>> With xserver 1.6, the ctrl-alt-backspace shortcut for killing X has been
>>>> defaulted to off.
>>>>
>>>> At UDS it was decided for Ubuntu to accept this upstream change, but to
>>>> provide GUI mechanisms for GNOME allowing the user to switch it on or
>>>> off.
>>>>
>>>> This branch implements this mechanism.
>>> I very much appreciate Alberto's work in implementing this, but would
>>> like to test the decision against our commitment to ease of use. I think
>>> enabling or disabling this feature in X is an expert option. I think we
>>> can choose to enable it, or disable it, and of course we can allow
>>> experts to change that through a config file or through a rebuild, but
>>> this capability *should not* be exposed to end-users as a GUI option. It
>>> will create more confusion than it will solve.
>>>
>>> Mark
>>
>> Dear Mark,
>>
>> I see your concern but the option which my patch adds is very simple, see the
>> following screenshot:
>> http://albertomilone.com/ubuntu/gnome/gnome3.png
>>
>> It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even mention the
>> word "DontZap".
> Alberto,
>
> While setting the option is simple:
> 1. It does make it too easy for novice users to inadvertently set up
> their machines to do something that is potentially undesirable.

This doesn't make any sense at all. What is unclear about
"Ctrl+Alt+Backspace restarts the xserver" ? What is undesirable is for
users to have a frozen X and have to hard reboot their machine.

> 2. Every option that we add to Ubuntu diminishes the value of every
> other option. I think this is an important point to consider. Is this
> option important enough to add to the cognitive effort that Ubuntu users
> must invest?

That's a nice platitude but I don't see how allowing an option for a
frequently used feature that has been removed is going to make the
100s of other options in the user desktop any less valuable.

> Users have to stop and consider if they should use the option. What is
> it? Should I care? At that point they have already paid a price.

Good grief, it's a checkbox, not an entrance exam or something.
According to Alberto's screenshot there is all of 3 checkboxes. If
we're going to be that strict on UI choices then how about I trade you
a checkbox for the refresh rate drop-down? Users have to think about
what the heck a refresh rate is, what numerical value works for them.
There's no indication of what a refresh rate is, etc.

> Therefore, we should be absolutely certain that the benefit to users is
> worth it. In this case, I wonder if the option really gives us an out
> with the vocal users who don't want to see the option changed, and there
> fore is meant to benefit us, not the users.

More often than not, what benefits users b...

Alberto Milone wrote:
> Of course I'm fine with either solution (i.e. rejecting or accepting this
> patch).
>
> Alberto
Albert,

Thanks again for all your work on this, including the options editor and
the KDE work as well.

It sounds like we are in agreement that we won't merge this GUI option
into Ubuntu.

Cheers, Rick

Alberto Milone wrote:
> On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
> > Alberto Milone wrote:
> > > Alberto Milone has proposed merging
> > > lp:~albertomilone/gnome-control-center/randr-virtual into
> > > lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
> > >
> > > Requested reviews:
> > > VCS imports (vcs-imports)
> > >
> > > With xserver 1.6, the ctrl-alt-backspace shortcut for killing X
> has been
> > > defaulted to off.
> > >
> > > At UDS it was decided for Ubuntu to accept this upstream change,
> but to
> > > provide GUI mechanisms for GNOME allowing the user to switch it on or
> > > off.
> > >
> > > This branch implements this mechanism.
> >
> > I very much appreciate Alberto's work in implementing this, but would
> > like to test the decision against our commitment to ease of use. I think
> > enabling or disabling this feature in X is an expert option. I think we
> > can choose to enable it, or disable it, and of course we can allow
> > experts to change that through a config file or through a rebuild, but
> > this capability *should not* be exposed to end-users as a GUI option. It
> > will create more confusion than it will solve.
> >
> > Mark
>
>
> Dear Mark,
>
>
> I see your concern but the option which my patch adds is very simple,
> see the following screenshot:
> http://albertomilone.com/ubuntu/gnome/gnome3.png
>
>
> It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even
> mention the word "DontZap".
>
>
> A lot of users (see what's happening on ubuntuforums.org) will upgrade
> to Jaunty and will be a bit shocked by this change. Most of them have
> learnt to deal with X freezes (which are by no means infrequent) by
> using Ctrl+Alt+Backspace. This doesn't make them "experts" though and
> it's very likely that they are not aware of the existence of the
> DontZap option.
In that case, if we want this to be the behaviour of X in Ubuntu, we
should leave the option ON.

There is a fantastic commentary by MPT about the forces that create bad
usability in free software:
http://mpt.net.nz/archive/2008/08/01/free-software-usability

Check out #10: placating people with options.

In essence, what we are saying here is "we can't make a decision about
whether it should be ON or OFF, so we're going to force YOU to make that
decision. Every time you look at this dialog box, which is a useful
dialog box and which lots of people will look at, you are going to have
to decide if you want the Ctrl-Alt-Backspace to kill X and all your
running clients.

I know this work was done out of pure intent, but I would rather that we
take the time to agree on the principles by which we will ask users to
make choices before we add more choices for users to make.

Alberto, please take a look at MPT's work, and then I'm happy to discuss
further if this is a choice that we want our users to make.

> For this reason (as requested at the UDS) I implemented the same
> change in Kubuntu:
> http://albertomilone.com/wordpress/?p=312
>
>
> I deem it a good compromise.
I don't believe this to be something on which we need to compromise. I'm
happy to keep discussing it, and would like to use MPT's commentary as
the usability framework for th...

On Thu, Jan 29, 2009 at 07:03:18PM +0100, Alberto Milone wrote:
> > > On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
> > >> I very much appreciate Alberto's work in implementing this, but would
> > >> like to test the decision against our commitment to ease of use. I think
> > >> enabling or disabling this feature in X is an expert option. I think we
> > >> can choose to enable it, or disable it, and of course we can allow
> > >> experts to change that through a config file or through a rebuild, but
> > >> this capability *should not* be exposed to end-users as a GUI option. It
> > >> will create more confusion than it will solve.
>
> In any case this change is definitely something worth mentioning in
> the release notes together with some easy steps to re-enable this
> functionality.

Yes, mentioning it in the release notes is a good idea.

I think this emphasizes that our original plan of putting this in the
(expert user oriented) xorg.conf options editor was a better
approach.

You know, perhaps the 'dontzap' command line tool alone may be
sufficient to appease users upset by this change. It will at least be
relatively easy to document and a lot easier to maintain long term than
a gnome-control-center patch.

Bryce

Would it perhaps be better if this were masked by an advanced options
button? I'm sure there are other "useful" things that could be placed
on this page, but the same argument will get raised about presenting
them to the user every time the dialog is opened.

On 01/29/2009, Mark Shuttleworth <email address hidden> wrote:
> Alberto Milone wrote:
>> On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
>> > Alberto Milone wrote:
>> > > Alberto Milone has proposed merging
>> > > lp:~albertomilone/gnome-control-center/randr-virtual into
>> > > lp:~ubuntu-core-dev/gnome-control-center/ubuntu.
>> > >
>> > > Requested reviews:
>> > > VCS imports (vcs-imports)
>> > >
>> > > With xserver 1.6, the ctrl-alt-backspace shortcut for killing X
>> has been
>> > > defaulted to off.
>> > >
>> > > At UDS it was decided for Ubuntu to accept this upstream change,
>> but to
>> > > provide GUI mechanisms for GNOME allowing the user to switch it on or
>> > > off.
>> > >
>> > > This branch implements this mechanism.
>> >
>> > I very much appreciate Alberto's work in implementing this, but would
>> > like to test the decision against our commitment to ease of use. I think
>> > enabling or disabling this feature in X is an expert option. I think we
>> > can choose to enable it, or disable it, and of course we can allow
>> > experts to change that through a config file or through a rebuild, but
>> > this capability *should not* be exposed to end-users as a GUI option. It
>> > will create more confusion than it will solve.
>> >
>> > Mark
>>
>>
>> Dear Mark,
>>
>>
>> I see your concern but the option which my patch adds is very simple,
>> see the following screenshot:
>> http://albertomilone.com/ubuntu/gnome/gnome3.png
>>
>>
>> It says "Ctrl+Alt+Backspace restarts the xserver" and doesn't even
>> mention the word "DontZap".
>>
>>
>> A lot of users (see what's happening on ubuntuforums.org) will upgrade
>> to Jaunty and will be a bit shocked by this change. Most of them have
>> learnt to deal with X freezes (which are by no means infrequent) by
>> using Ctrl+Alt+Backspace. This doesn't make them "experts" though and
>> it's very likely that they are not aware of the existence of the
>> DontZap option.
> In that case, if we want this to be the behaviour of X in Ubuntu, we
> should leave the option ON.
>
> There is a fantastic commentary by MPT about the forces that create bad
> usability in free software:
> http://mpt.net.nz/archive/2008/08/01/free-software-usability
>
> Check out #10: placating people with options.
>
> In essence, what we are saying here is "we can't make a decision about
> whether it should be ON or OFF, so we're going to force YOU to make that
> decision. Every time you look at this dialog box, which is a useful
> dialog box and which lots of people will look at, you are going to have
> to decide if you want the Ctrl-Alt-Backspace to kill X and all your
> running clients.
>
> I know this work was done out of pure intent, but I would rather that we
> take the time to agree on the principles by which we will ask users to
> make choices before we add more choices for users to make.
>
> Alberto, please take a look at MPT's work, and then I'm happy to d...

On Thu, Jan 29, 2009 at 06:26:26PM +0000, Mark Shuttleworth wrote:
> Alberto Milone wrote:
> > On Thursday 29 January 2009 17:48:37 Mark Shuttleworth wrote:
> > > Alberto Milone wrote:
> > A lot of users (see what's happening on ubuntuforums.org) will upgrade
> > to Jaunty and will be a bit shocked by this change. Most of them have
> > learnt to deal with X freezes (which are by no means infrequent) by
> > using Ctrl+Alt+Backspace. This doesn't make them "experts" though and
> > it's very likely that they are not aware of the existence of the
> > DontZap option.
>
> In that case, if we want this to be the behaviour of X in Ubuntu, we
> should leave the option ON.
>
> http://mpt.net.nz/archive/2008/08/01/free-software-usability
>
> Check out #10: placating people with options.

Heh, spot on, yes 'placating people with options' would be a pretty fair
description.

Basically the situation we face is a 'bikeshed painting debate'. It is
an easy thing to have a very strong opinion on, in proportion to its
actual importance.

The 'Ctrl-Alt-Backspace shortcut' is one of those old-timer things that
really does need to go in order to make Linux more palatable to newbie
users. Unfortunately, it's a case where it may benefit over half of our
future users to have it disabled by default, but some 10% will be quite
vocal in its defense.

In the UDS session on this, there were a couple people vocal in their
defense of the option. The compromise of providing a GUI tool of some
sort for controlling it allowed us to reach a consensus on the topic.
Admittedly though, this is definitely a case of placating the vocal
minority by providing an option.

Bryce

Alberto Milone wrote:
> It seems clear to me that this change in X will cause a lack of consistency
> (after a dist-upgrade) in the behaviour of the system. New users will probably
> benefit from the change in X but some old users will not be pleased, others
> may even think that something is wrong with their system (as we're not
> speaking about advanced users).
>
Yes, I think this is a valid concern. We should debate this seriously,
and come to a decision. I could live with either keeping the
Ctrl-Alt-Backspace behaviour, or stopping it, as long as we intend to
stick with that indefinitely and also as long as we keep a config file
option to change it.

But I strongly believe that the ability to change this for most users is
an option that will cause more confusion and harm than it will solve.

> I think of this patch as a compromise between leaving users confused after an
> upgrade and keeping DontZap disabled by default in X (despite upstream's
> decision). In any case this change is definitely something worth mentioning in
> the release notes together with some easy steps to re-enable this
> functionality.
>
> Of course I'm fine with either solution (i.e. rejecting or accepting this
> patch).
>

I appreciate your flexibility! But let's use this opportunity first to
evaluate MPT's commentary, and take the temperature of the team to see
if they are comfortable with us using that as a guiding set of
principles. And second, to see if we can get all the developers on this
thread excited about the idea of helping users by producing really
usable software. For that, I think we have to be willing to resist the
normal urge to create options.

Mark

Mario Limonciello wrote:
> Would it perhaps be better if this were masked by an advanced options
> button? I'm sure there are other "useful" things that could be placed
> on this page, but the same argument will get raised about presenting
> them to the user every time the dialog is opened.
>

"Advanced options" buttons are quite a common solution, but they are not
considered very usable. They hide options, so people have to keep
digging in there to see if they can find what they are looking for.
Worse, when the things in the advanced options change, people don't
notice, because they think "I went in there before and didn't see
anything that I understood".

There are definitely some cases where it's the best option, but the
situation has to be pretty bad for that to be the case :-).

So, in this case, I don't this it's warranted.

Mark

Bryce Harrington wrote:
> In the UDS session on this, there were a couple people vocal in their
> defense of the option. The compromise of providing a GUI tool of some
> sort for controlling it allowed us to reach a consensus on the topic.
> Admittedly though, this is definitely a case of placating the vocal
> minority by providing an option.
>

It's understandable the passions this would inspire in those who use the
option frequently. That's why I think we should either preserve the
option, or remove it, but definitely leave an expert way to set it. But
that is not the same as a GUI option. If ctrl-alt-backspace is something
that upstream believes was a mistake, or results in less usable
software, then we would need to have a VERY strong belief in it to
preserve it. That's ok if people want to preserve it, but not OK to
force a new choice on otherwise-oblivious users.

Mark

On Thu, Jan 29, 2009 at 05:09:40PM -0000, Alberto Milone wrote:
> A lot of users (see what's happening on ubuntuforums.org) will upgrade to
> Jaunty and will be a bit shocked by this change. Most of them have learnt to
> deal with X freezes (which are by no means infrequent) by using
> Ctrl+Alt+Backspace. This doesn't make them "experts" though and it's very
> likely that they are not aware of the existence of the DontZap option.

> For this reason (as requested at the UDS) I implemented the same change in
> Kubuntu:
> http://albertomilone.com/wordpress/?p=312

> I deem it a good compromise.

These are all reasons why I'm of the opinion that changing the DontZap
default was the wrong solution to the problem people were trying to solve,
namely that you could hit Ctrl+Alt+Bksp by accident and toast your session.
The right way to compromise on this would be to have a Zap implementation in
the server that *doesn't* carry a significant risk of users (experienced or
inexperienced) triggering it by accident; e.g., by requiring you to hold
down Ctrl+Alt+Bksp for 5 seconds before it triggers, turning Zap on my
default, and prominently documenting the behavior change.

On Thu, 29 Jan 2009, Steve Langasek wrote:

> These are all reasons why I'm of the opinion that changing the DontZap
> default was the wrong solution to the problem people were trying to solve,
> namely that you could hit Ctrl+Alt+Bksp by accident and toast your session.
> The right way to compromise on this would be to have a Zap implementation in
> the server that *doesn't* carry a significant risk of users (experienced or
> inexperienced) triggering it by accident; e.g., by requiring you to hold
> down Ctrl+Alt+Bksp for 5 seconds before it triggers, turning Zap on my
> default, and prominently documenting the behavior change.

People can still use what the kernel provides;

alt + SysRq + k (t for DVORAK addicts)

kills everything on the current VT, which is basically what zapping does.
Also, there are situations where zapping doesn't work, but this one
might..

The combo *is* harder to discover (also on purpose), but should please
the vocal minority who can't live without "Zap OOTB"..

--
Timo Aaltonen
Systems Specialist
IT Services, Helsinki University of Technology
tel. +358-9-4514317, mobile: +358-50-5918781
http://users.tkk.fi/~tjaalton

On Thu, Jan 29, 2009 at 06:16:12PM -0000, Jordan Mantha wrote:

> One more point. This is *so* not the place nor time to have a
> conversation like this. This change was already discussed at UDS and
> is ready for prime time. If you have a problem with it, use the
> ubuntu-devel mailing list.

You're right that this is not the best place to have this conversation. But
that does not mean that this change should be merged citing a consensus
among the people who were in the room at the time at UDS, ignoring the lack
of consensus among the larger Ubuntu developer community.

hi,
Am Donnerstag, den 29.01.2009, 21:46 +0000 schrieb Steve Langasek:
> On Thu, Jan 29, 2009 at 06:16:12PM -0000, Jordan Mantha wrote:
>
> > One more point. This is *so* not the place nor time to have a
> > conversation like this. This change was already discussed at UDS and
> > is ready for prime time. If you have a problem with it, use the
> > ubuntu-devel mailing list.
>
> You're right that this is not the best place to have this conversation. But
> that does not mean that this change should be merged citing a consensus
> among the people who were in the room at the time at UDS, ignoring the lack
> of consensus among the larger Ubuntu developer community.
but thats exactly what happens here, instead of discussing this issue in
the mailing list it is dicussed in a merge request ... i highly propose
to move it to ubuntu-devel and *not* exclude the community (i also doubt
it was the intention of merge notifications to be abused as a place for
design discussions)

ciao
 oli

On Thu, 2009-01-29 at 20:46 +0000, Mark Shuttleworth wrote:
> Mario Limonciello wrote:
> > Would it perhaps be better if this were masked by an advanced options
> > button? I'm sure there are other "useful" things that could be placed
> > on this page, but the same argument will get raised about presenting
> > them to the user every time the dialog is opened.
> >
>
> "Advanced options" buttons are quite a common solution, but they are not
> considered very usable. They hide options, so people have to keep
> digging in there to see if they can find what they are looking for.
> Worse, when the things in the advanced options change, people don't
> notice, because they think "I went in there before and didn't see
> anything that I understood".
>
> There are definitely some cases where it's the best option, but the
> situation has to be pretty bad for that to be the case :-).
>
> So, in this case, I don't this it's warranted.

The general way this is done in Gnome is to hide the option in gconf
where you can go to gconf-editor and change the option. Such as the
feature of focus strictly under mouse.

Chris

Mark Shuttleworth [2009-01-29 20:48 -0000]:
> It's understandable the passions this would inspire in those who use the
> option frequently. That's why I think we should either preserve the
> option, or remove it, but definitely leave an expert way to set it.

We have that, with the "dontzap" command line tool.

> If ctrl-alt-backspace is something that upstream believes was a
> mistake, or results in less usable software, then we would need to
> have a VERY strong belief in it to preserve it.

Full ack, and I don't think we should. Also, my feeling is that nobody
seriously asks for this, just about how to enable it again if they
want it.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hello all,

I originally had the impression that this should become a part of the
X.org options editor, not the screen resolution settings. Is it still
planned to put that into the options editor? (Which is an advanced
tool all over the place, thus it fits well there.)

The option doesn't really fit into the purpose of screen resolution
IMHO, and I doubt that people would even look there if they wanted to
get back Ctrl+Alt+Backspace.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Jordan Mantha [2009-01-29 18:16 -0000]:
> This doesn't make any sense at all. What is unclear about
> "Ctrl+Alt+Backspace restarts the xserver" ?

It's bad for exactly the same reasons as why we disabled it in the
first place: Apparently it is hit inadvertently all too often, and it
mercilessly kills everything you just worked on.

> What is undesirable is for users to have a frozen X and have to hard
> reboot their machine.

What is undesirable is for users to have a frozen X. Once they have,
and their work is gone *anyway*, it doesn't make a lot of difference
whether they reboot the machine, use Ctrl+Alt+Backspace, or use
Alt+SysRq+K. I don't think we should keep this hole open for the very
small minority of people who object to the extra effort of
Sysrq/rebooting, and don't know/want to use the dontzap command line
tool.

> > 2. Every option that we add to Ubuntu diminishes the value of every
> > other option. I think this is an important point to consider. Is this
> > option important enough to add to the cognitive effort that Ubuntu users
> > must invest?
>
> That's a nice platitude but I don't see how allowing an option for a
> frequently used feature that has been removed is going to make the
> 100s of other options in the user desktop any less valuable.

More specifically, the option is (1) at an unexpected place ("screen
resolution"), and a (2) "shoot yourself in the foot" one.

> Good grief, it's a checkbox, not an entrance exam or something.
> According to Alberto's screenshot there is all of 3 checkboxes. If
> we're going to be that strict on UI choices then how about I trade you
> a checkbox for the refresh rate drop-down? Users have to think about
> what the heck a refresh rate is, what numerical value works for them.
> There's no indication of what a refresh rate is, etc.

That might very well be true. Nobody said that the current desktop
was perfect, just that we shouldn't make it worse. :-)

> More often than not, what benefits users benefits us. We're already
> turning off the option by default, why is it so hard to think that
> giving users an option to return a behavior that has been around for
> years is good for the users? Why is it hard to think that users just
> might want to be able to get out of a sticky situation without playing
> CLI tricks.

We actually discussed this a lot. I asked my wife and sister what they
would do if their computer would freeze completely, and moving the
mouse/typing keys wouldn't do anything any more; they said "I'd press
the power button". Which works, if you press it long enough.

> One more point. This is *so* not the place nor time to have a
> conversation like this. This change was already discussed at UDS and
> is ready for prime time. If you have a problem with it, use the
> ubuntu-devel mailing list.

To be completely fair, the spec [1] says

  "3. As part of the Xorg.conf Options Editor specification, GUI tools
  will be implemented that permit re-enabling this. Tools must be
  available for both GNOME and KDE."

and I approved it like that. It does *not* talk about changing the
screen resolution capplet. Thus I actually think that this merge
request isn't the worst place, but ...

On Thu, 29 Jan 2009, Steve Langasek wrote:
> On Thu, Jan 29, 2009 at 05:09:40PM -0000, Alberto Milone wrote:
> > have learnt to deal with X freezes by using Ctrl+Alt+Backspace.

Ctrl-Alt-Backspace is widely offered in help guidance:

  http://www.google.com/search?q=site:help.ubuntu.com+ctrl-alt-backspace (271 results)

> e.g., by requiring you to hold down Ctrl+Alt+Bksp for 5 seconds before

This is the most sensible suggestion I've heard.

Alberto: would you will to offer up a patch that forces a hold-for-5-seconds
requirement with no other keys being pressed in the meantime?

This would:
 * fix the root problem
 * without breaking the currently defined behaviour
 * without needing a configuration option

Nota Bene: we should probably do this for Ctrl-Alt-Del too.

 -Paul
--
Why do one side of a triangle when you can do all three. Somewhere, GB.

On Friday 30 January 2009 15:18:26 Paul Sladen wrote:
> On Thu, 29 Jan 2009, Steve Langasek wrote:
> > On Thu, Jan 29, 2009 at 05:09:40PM -0000, Alberto Milone wrote:
> > > have learnt to deal with X freezes by using Ctrl+Alt+Backspace.
>
> Ctrl-Alt-Backspace is widely offered in help guidance:
>
> http://www.google.com/search?q=site:help.ubuntu.com+ctrl-alt-backspace
> (271 results)
>
> > e.g., by requiring you to hold down Ctrl+Alt+Bksp for 5 seconds before
>
> This is the most sensible suggestion I've heard.
>
> Alberto: would you will to offer up a patch that forces a
> hold-for-5-seconds requirement with no other keys being pressed in the
> meantime?
>
> This would:
> * fix the root problem
> * without breaking the currently defined behaviour
> * without needing a configuration option
>
> Nota Bene: we should probably do this for Ctrl-Alt-Del too.
>
> -Paul

If Mark and other developers agree, I'm available to hack on X.org to
implement this solution.

I'm fine with either having to hold down Ctrl+Alt+Bksp for 5 seconds or having
to press Ctrl+Alt+Bksp twice (as implemented in OpenSuse).

Either way these settings could be changed in the xorg.conf.

Regards,

Alberto

Hi,

Alberto Milone:
> I'm fine with either having to hold down Ctrl+Alt+Bksp for 5 seconds
> or having to press Ctrl+Alt+Bksp twice (as implemented in OpenSuse).
>
Pressing twice is a much better solution IMHO. Somebody like me, who
doesn't know about this safety feature, might just press Ctrl+Alt+Bksp
again if it doesn't work the first time ;-) but the very idea to hold
that key combo down for multiple seconds wouldn't even enter my head.

After all, keyboard keys are not power buttons.

Besides, a patch already exists, so that'd be easier to implement. :-P

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
 - -
Erhebliche Gefahr durch herumwirbelnde Verkehrszeichen.
  -- Verkehrsfunk am 3.12.99, Orkan

On Fri, 30 Jan 2009, Paul Sladen wrote:

> On Thu, 29 Jan 2009, Steve Langasek wrote:
>> On Thu, Jan 29, 2009 at 05:09:40PM -0000, Alberto Milone wrote:
>>> have learnt to deal with X freezes by using Ctrl+Alt+Backspace.
>
> Ctrl-Alt-Backspace is widely offered in help guidance:
>
> http://www.google.com/search?q=site:help.ubuntu.com+ctrl-alt-backspace (271 results)

And it's still available for those that need it.

>> e.g., by requiring you to hold down Ctrl+Alt+Bksp for 5 seconds before
>
> This is the most sensible suggestion I've heard.
>
> Alberto: would you will to offer up a patch that forces a hold-for-5-seconds
> requirement with no other keys being pressed in the meantime?
>
> This would:
> * fix the root problem
> * without breaking the currently defined behaviour
> * without needing a configuration option

But it _does_ break the currently defined behaviour, depending on the
implemention.. (hold it down or keep hitting it N times). So the
documentation would have to be fixed anyway..

Remember that we'd need to keep the patch "forever".

t

Thanks everyone for the ideas and discussions.

Like Timo mentioned above, alt-sysrq-k is still available, less likely
to get hit accidentally, and should work more reliably since it's
implemented in the kernel. There are definitely some kinds of lockups
where X can't do ctrl-alt-backspace.

If we didn't have alt-sysrq-k, then the OpenSuSE patch would be a good
alternative since it's already been tested. If upstream were to adopt
it, I think we'd take it, but as it currently stands, it seems
extraneous and probably unnecessary.

Regarding the help documentation, yes that will all need to be changed
to s/ctrl-alt-backspace/alt-sysrq-k/. That is done easily enough and
need not be a reason for retaining the shortcut.

Bryce

Alberto Milone wrote:
> If Mark and other developers agree, I'm available to hack on X.org to
> implement this solution.
>
This sounds like a better solution, but it would be most useful if the
upstream Xorg guys buy into it too. Has anyone submitted the patch
upstream, or opened a thread to discuss it there?

In general, having to press a key twice makes me nervous. Is there any
feedback on the first keypress (I guess not).

I'm more inclined to go with Martin Pitt's assessment (and what I hear
is upstream's view).

Regardless, Alberto, a patch there (without a GUI option, except in the
Xorg config options editor) would be more acceptable.

Mark

Bryce Harrington [2009-01-30 18:57 -0000]:
> Regarding the help documentation, yes that will all need to be changed
> to s/ctrl-alt-backspace/alt-sysrq-k/. That is done easily enough and
> need not be a reason for retaining the shortcut.

Full ack from me.
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt wrote:
> Bryce Harrington [2009-01-30 18:57 -0000]:
>
>> Regarding the help documentation, yes that will all need to be changed
>> to s/ctrl-alt-backspace/alt-sysrq-k/. That is done easily enough and
>> need not be a reason for retaining the shortcut.
>>
>
> Full ack from me.
>
+1

Mark

From the thread on this on ubuntu-devel and IRC discussions, it seems
alt-sysrq-k is not working well or at all in a non-trivial number of
installations. I don't think it's a suitable alternative.

Scott K

On Sat, 2009-01-31 at 23:21 +0000, Scott Kitterman wrote:

> >From the thread on this on ubuntu-devel and IRC discussions, it seems
> alt-sysrq-k is not working well or at all in a non-trivial number of
> installations. I don't think it's a suitable alternative.
>
Can you give examples?

The only situations I can think of where SysRq doesn't work is in the
case of kernel panic -- and C-A-Backspace isn't going to help you then
either!

Scott
--
Scott James Remnant
<email address hidden>