Richard Hughes’s post about GNOME 3 power settings seems to have generated a good deal of interest and, dare I say it, a good deal of opinion too. I’ve been fairly involved in some of the design process behind these settings, and I’ve even had a go at designing the power panel, so I think I’m in a pretty good position to attempt (be forgiving!) to give a bit of commentary on the action-on-lid-close-settings debate.
To see how we got to this point, we need to take a step back. gnome-control-center has been almost completely redesigned for GNOME 3. That includes the so-called ‘shell’ (the settings window and navigation and search mechanisms), the categorisation and grouping of the settings, and the contents of each settings ‘panel’ itself. A great deal of work has gone into this, and we’ve been really stretched getting GNOME 3’s system settings designed. We could have definitely done with more designers on the team.
Nevertheless, thanks to the hard work and dedication of a small number of individuals, we are going to have vastly improved system settings for GNOME 3. They’ve been rationalised, reorganised and reconceptualised. They’re going to be easier to use and be more relevant to today’s users. They’ll work with touch screen devices (this is why we’re including status information in the panels) and with netbooks. You can see the details of this work on the wiki (this is the current design page and this is an older one); virtually all the discussion about this has been happening on #gnome-design, and there have been mockups bouncing around the GNOME design git repository for months.
Before and After (Click to view full-size)
Which brings us to the matter at hand: how do we handle power settings for when someone shuts their laptop lid? The issue has already been discussed many times on #gnome-design, and we obviously we want a solution that works for everybody. Yesterday, Richard wrote about what I’d describe as the most popular position amongst those doing design work on this particular issue: default to suspend on lid closing, and don’t provide an option to change that setting. I could write at length about why suspend-on-lid-close is A Good Thing but won’t for sake of brevity. It seems to be the second part of that proposal that people are most concerned about, so that’s what I’m going to focus on.
To some people, removing a preference might seem like a cruel or irrational thing to do. There are some pretty good reasons for this approach, however. First, it increases integration between software and hardware. GNOME becomes identified with the behaviour of the device in question, not just the software that runs on it. It’s about designing the behaviour of the whole product. Second, for many users, a setting isn’t that helpful: if you are a user who likes their laptop to suspend-on-lid-close some of the time, but don’t want it to suspend-on-lid-close at other times, a preference is decidedly suboptimal. What we don’t want is for our users to be constantly fiddling with their settings. For the most part, they should be able to go there once, configure the system, and forget about it. Having a setting there could entice users into that constant fiddling behaviour, and that would degrade the user experience.
The other reason not to include this setting is, of course, that it is another setting and, as we all know, settings kill kittens. The vast majority of people do not like lots of settings: they find them difficult to use, and it makes them think that GNOME isn’t intended for them. (We do want GNOME to have mass appeal, don’t we?!) ‘It’s just one setting!’, you might say, and that is a fair comment. The question is: when is one more setting a setting too far? Where do we draw the line?
What makes this issue so difficult is that many applications and services simply do not do the right thing when it comes to suspend/resume, and some of those services are used particularly heavily by the user communities that are close to GNOME. IRC is a particular issue here, but there are others that have been rightly identified by those who are concerned about this issue. We want GNOME to do The Right Thing, but that is difficult when so many other pieces of software are doing The Wrong Thing. It’s a question of responsibility as much as it is proper behaviour, and it’s a question of what we want to aim for in the future.
So where does this leave us? The power settings are still being worked on, and we are yet to see a final design for the power panel. The people that are working on it are acutely aware of the difficulties users face with suspend on lid close. They also (believe it or not) really care about GNOME users, and are trying to do the best thing for GNOME. If you want to follow this issue, you can watch the wiki, design repositories and IRC channels. I’m sure it will be discussed again soon, and everyone is welcome to participate in those discussions, provided that their contribution is a constructive one.
Edit: thanks for all the responses. It’s been a great discussion and a lot of useful points have been raised. As of now, I’m effectively closing the comments on this post, however. I simply don’t have the time to properly moderate them. Don’t worry though, we’re not ignoring what has been said here, and we’re working on this issue. And if your post is still in the queue, I will make an effort to get to it soon.
As far as I know 
Pingback: On laptop lids and power settingsafaik | 9nd.pl
I agree with suspend when the lid gets closed, but only when no external display is connected! I use my laptop for watching movies on TV (because it is bigger than laptop’s screen) and I want to watch them without laptop disturbing me from watching it – so I close the lid. What I would expect to happen would be – turn off internal display and don’t suspend the laptop. Currently, this is behaving very strange. When (in gnome 2) I change lid close option to “Do nothing” it behaves randomly – once the internal display is turned off, external kept on, on open, internal is turned on, external off, second lid close – internal ON, external off, open – external on, internal off, close – both on, open – internal on, external off. This is unacceptable for normal user, make some logic to this!
Jaroslav: not sure I follow all your description, but this sounds like a bug to me. The correct behaviour is for suspend on lid close to be inhibited if you have an external display connected.
OK, but this should have been mentioned in the first place.
I can think of 3 situations:
* on battery – laptop lid close -> suspend
* on power AC – laptop lid close -> nothing
* external monitor connected – laptop lid close -> nothing
From the article it was not clear to me what happens when I have external monitor attached. How do they handle this on OSX, Win7? I mean if people are expecting this feature to be there?
The other reason not to include this setting is, of course, that it is another setting and, as we all know, settings kill kittens.
This seems to be at the heart of the matter. You have decided to change the functional requirements to meet your UI design due to a belief that all settings are evil. This is not how good software is designed. If a requirement is bad, it should be re-evaluated on its own merits. It should never be stripped out because you can’t immediately think of a perfect way to implement the UI.
This is quite clearly a functional requirement that is an important part of many people’s workflows. Explaining your rationale will not change the fact that it is a bad idea.
Hi Jer,
‘You have decided to change the functional requirements to meet your UI design’. Have we? Honestly, as someone who’s helped design this, I can tell you that that simply isn’t the case.
If you’d like to contribute to a discussion about why this ‘is an important part of many people’s workflows’, you’re more than welcome. Well reasoned arguments are new use-cases are always welcome.
There’s quite a few good use cases in the comments on Richard’s post. A few examples:
1. Moving laptops from room to room. For example, I frequently start a task (running reports, etc), throw my laptop in my bag, and walk home from the office. Same applies to going to meetings, etc.
2. Playing music through your stereo – why have the screen open and on?
3. Doing things overnight (downloading, compiling, etc).
The first is a particular problem. Some pieces in the Gnome stack (from the kernel on up to the UI) don’t reinitialize quickly on resume. When I come out of suspend, it is a good 60 seconds before I have a fully functioning and connected desktop (sure, mostly Broadcom’s fault, but it’s the Gnome experience that forces it on me by requiring a suspend), and when I do I’ve lost all my SSH sessions, etc. If I’m hauling my laptop over to a co-worker’s desk or meeting room to show them something, I don’t want to sit there twiddling my thumbs for a minute while everything wakes up correctly, and then spend another few minute getting back to where I left off. Unless the default behavior is universally a good experience, there needs to be an easy way to change it.
And this comment from Hughes is what I base my “changing requirements” remark on:
I’ve been told a thousand times i suck at UI design, so I’ve left the designers to provide me with mockups. If the mockup changes, then the software changes. Talk to the guys in #gnome-design. Sorry.
That points to the the UI mockups being the driving factor behind the functionality, which is backwards. As an outsider, that’s a bit disconcerting, and smells like Apple-esque form-over-function, do-it-our-way-it’s-better type of thinking.
Jer,
Those are all good use cases which we’re well aware of (and have been for some time). Useful to have them as a part of the discussion though.
‘UI mockups being the driving factor behind the functionality’ – just because Richard mentioned mockups doesn’t mean that is the sole focus of our design discussions. We frequently talk about behaviour and functionality. How could we not? A UI design cannot stand in isolation from the design of functionality and behaviour – it wouldn’t make any sense if it did. It feels a little bit like you’re looking for things to criticise here.
My laptop has discernible electromagnetic static noise on the audio jack as long as the display is on. When I want to listen to soothing, sublime music on my stereo I close the lid to eliminate these few dBA of noise floor. That is a probably unfixable hardware limitation.
Why do you think you have the capacity to decide the scope and circumstances of using Gnome?
Perhaps there are circumstances outside of «we want to make a desktop for Starbucks visitors with netbooks».
‘You have decided to change the functional requirements to meet your UI design’. Have we? Honestly, as someone who’s helped design this, I can tell you that that simply isn’t the case.
You might not intend it that way, but that’s the way people are seeing it, and it seems clear that you’re badly misreading what existing Gnome users want.
Richard’s post, for example, implies that the suspend setting is being changed because it’s only there as a workaround, a way for people to turn off suspend on machines where it’s broken. And as literally hundreds of users have subsequently made clear, that’s not actually the case – real people actually have genuine reasons for wanting to control these things. Reasons like wanting to shut the lid while moving the laptop around, without dropping network connections, or to hide the screen while playing audio. Genuine reasons.
Now, I’ll be the first to agree that overcomplicated settings are bad from both code and UI perspectives. But you guys need to be careful about what you judge unnecessary – simple is good, but only if it does what the users need it to do. And not all users need the same thing.
Hey Simon,
“real people actually have genuine reasons for wanting to control these things”. Nicely summed up. I don’t doubt that people have real cause to want their machines to work in a particular way. What my post was asking is whether a setting (‘control’, as you put it) is actually the best way to address those needs. Of course we want GNOME to work for our users though – that goes without saying.
As far as I am concerned this will not be an issue providing that it works properly. As of now when my laptop suspends, half the time it crashes the system other half it will wake up. Either way it seems to take about 5 minutes. This is more of a kernel issue than a Gnome issue.
Arthur,
Totally agreed – we need to work across the stack to make sure this works.
That across the stack work SHOULD to be done BEFORE taking away (findable) ways to workaround it. That feels like another core issue here.
Mart,
Personally, I would like to see more effort put into that kind of proactive collaboration. The difficulty, of course, is resources. To do what you’re describing, we would have needed a whole extra team of people working this. Forward planning and collaboration all take a lot of work. Maybe in this case we need to give it a bit more time to let these issues settle? I’m not sure.
Thanks for all your, Richard, and everyone else’s great work on GNOME 3! But…
While I like a lot of the things that are being done, there is an attitude among some folks doing design work that bothers me as a current GNOME user. For instance, the claim that this design decision was “the hard route that is ultimately a better experience.” It comes across as incredibly arrogant. The designer, with their superior sense of aesthetics, knows what is “ultimately better” for all of us. It often feels that the actual users of GNOME are being ignored in favor of some idealized normal user. If only we had the same understanding of form and function as the designers we wouldn’t be using our computers wrong.
Sorry for the rant. Thanks for being open for input.
Hi asomething,
Thanks! We have put a lot of work into it…
I’m sorry if you thought that comment was arrogant, and I’m sure Jimmac didn’t mean it that way. I think he was just trying to be supportive of Richard – the man’s been getting a lot of flack over this issue, and that isn’t fun.
I agree that we need to make GNOME work for everyone. As for designers being arrogant… well, I can certainly say that that hasn’t been my experience of them. Sure, they have strong opinions sometimes, but that doesn’t make them any different from other people involved in FOSS. There is a big issue around how we communicate design process which is happening in the open though – it’s extremely difficult to communicate all the thought and experience that goes into design work. That is certainly something we need to work on.
Inhibiting a behavior that usually is desired (i.e. in this case suspend) should best be done by starting an application that inhibits it… Ideally, applications that might require inhibiting suspend, should do just that!
The devs of certain applications should add the option to inhibit suspending. That’s the correct way to go about it; the user should not have to alter GNOME settings every time he/she runs an application that requires.
A temporary way out of this would be to write a dummy-application that has the sole purpose of inhibiting a suspend on closing a laptop’s lid.
Chris,
Yes, that could definitely be a good approach. It’s something that we were discussing on #gnome-design only earlier today, in fact.
Sounds like a job for something like the Screensaver inhibitor applet (or whatever it’s called). 😉
It doesn’t cover *every* use case though. There are a lot of comments from people who simply want to be able to close the lid temporarily (e.g when moving from one room to another) without the machine going to sleep on them.
Having an inhibitor doesn’t really work for that case – those people simply want to turn off suspend-on-close permanently, and use the sleep button if they actually want to suspend. But by working from the assumption that this is “inhibiting a behavior that’s usually desired”, you’re disregarding the possibility that for some people, that behavior is *never* required.
Allan, thanks for this detailed explanation. I do understand the rationale, but I take issue with this: “We want GNOME to do The Right Thing, but that is difficult when so many other pieces of software are doing The Wrong Thing.”
This “Wrong Thing” these applications are doing is actively running. Suspend stops that. How can an IRC client continue to receive network traffic on suspend? How can a compiler continue to parse source code on suspend? How can an audio player continue to play on suspend? There is no Right Way for these applications to work on suspend. The only Right Thing they could do is inhibit suspend.
But if an IRC client magically inhibited suspend, unless we provide some visual notification, I think a lot of users would be confused. “Sometimes my computer doesn’t sleep when I close the lid, but sometimes it does. I don’t know why.”
Is a buried preference the right way to deal with this? Probably not. I asked my wife about this, because I like getting input from somebody who (unlike me) isn’t always running a compiler or something. She said she often carries her (Windows) laptop from meeting to meeting with the lid partly open, to prevent it from sleeping. She finds it annoying. But she wasn’t aware you could change that behavior. (And, TBH, I don’t know if you can on Windows either.)
There’s a real user problem here. The preference solves the problem poorly, but it at least addresses it. There are all sorts of other ways we could address the problem. An inhibit switch on the panel, for example, although that’s even worse visual noise than the preference. If there were a plan in place to address the problem better, that would be awesome. But that hasn’t been mentioned in the blog posts. Instead, the 50% solution is just being dropped without an alternative. And it’s giving users the impression that the designers are more concerned with pretty layouts than with helping users.
Hey Shaun 🙂
Part of the tension here, I think, is the focus on the core desktop for 3.0. Once we get the application development side up-to-speed, things should hopefully become far more integrated. (In an ideal world, all that would happen simultaneously, of course, but there are only so many GNOMEys.) It might well be that we need to put a provisional design in place until some of these integration issues are resolved. Either way, you’re right – we need to communicate these kinds of plans in a way that addresses our users’ concerns. It’s always a matter of resources, unfortunately.
‘And it’s giving users the impression that the designers are more concerned with pretty layouts than with helping users.’ I’m really sad if that’s the impression our users have got, because it’s really not the case. Nice layouts are a good thing to have, but the behaviour is paramount, and I don’t think you’d find a designer-type who disagreed with that.
P.S. I do the whole keeping-your-laptop-lid-slightly-open-thing too. It’s a bit annoying, but so is not being able to remember whether you’ve left your laptop set to suspend-on-lid-close or not. Not a complete answer, I know…
One of the best proposals I’ve seen so far (in a comment on one of the related blog posts) was to suspend after a timeout after the lid was closed. This is a “Just Works” solution for people who just have to carry their laptop to another room for a meeting. This is similar to how the screensaver works: During the dimming effect, the screen isn’t locked yet. It gives you a chance to wiggle your mouse without having to type your password.
In a heterogeneous software environment like ours you will never get every program to play along with your vision.
The right thing to do after witnessing the wide-spread resistance is to put that option back.
“The ‘wrong thing’ these applications are doing is actively running.”
What you are doing there is really a bit unfair; I think you know that the designers didn’t mean that. If there is a ‘wrong’ behaviour of applications it is only that they do not as of yet tell the system that it shouldn’t go to sleep.
Certainly you must understand that an application that needs the system to stay awake should tell it so; that is what (good) video- and audio players already do. They tell the system: do not go to sleep, I need you awake.
You can’t want to go to GNOME’s settings and turn off suspend every time you watch a video or play music, or do you?
And an IRC program, or any other application that waits for incoming connections should do the same thing; if you don’t want the application to inhibit suspend, that would be best configured within the application’s preferences; where else?
As for your objection that a hypothetical user would be wondering why his computer doesn’t go to sleep, the solution is that a notification should tell him/her which application stopped the computer from going to sleep. With GNOME’s new notifications would be a very non-distracting thing.
IMHO, not being a developer, this should be the default behavior.
“the solution is that a notification should tell him/her which application stopped the computer from going to sleep. ”
From what I understand, this discussion is about what to do when the user closes the laptop lid. How is the user supposed to see a notification on screen if the lid is closed?
The problem is I’m not seeing a proposal to get applications to inhibit suspend when necessary. To his credit, Allan has commented here about the necessity of working across the stack. But the order of things is backwards. You have to give developers a chance to make things right before you can call them wrong.
We have a history of making changes (long-term improvements, to be sure), then being very quick to judge applications as “broken” or “doing the Wrong Thing”. This isn’t the first time I’ve seen it. It isn’t fair, and it doesn’t help our image with third-party developers.
How the user would see the notification if the laptop is closed and the application prevented the sleep?
I am not saying anything in favor or against, just point it out the argument does not seem to sound. However, a solution like the delayed suspend sounds like “It just works”.
Hey Germán!
There are a few options: we can display something on screen prior to the lid being closed (a notification dialogue, or even an icon in the system status area). The other thing we could possibly think about is an audio notification when the lid is closed (could be tricky – these are just ideas). And, of course, we can use external power lights to some effect if they are present (though we can’t rely on those, of course).
First of all, I am glad that you don’t remove the option completely, just hide it.
That way I don’t really care, because I can change a configuration key once (if it isn’t copied from my previous settings anyway), and get my preferred behavior.
A funny note though: Closing your lid suspends, but a closed lid is no indication, that the system is suspended. I have this “issue” with my Windows 7 and GNOME 2 laptops, that if I close the lid just while the system is waking up, it doesn’t suspend right away again. So this is some little trick I use nearly daily in order to keep the dust of my keyboard while still having it run (sadly, Windows doesn’t care about the external display being active and suspends anyway, so the suggested GNOME 3 behavior is a plus.).
Besides, that changing this would be a one-time-thing and therefore not worth all this fuss IMHO, I think there a many options one could spare, to make space for this one. (or even just remove more options and still not include this one).
Hmmm… I remember GNOME 2 getting a massive black eye in the press and amongst a vocal set of users when first released for removing so many settings and preferences.
Likewise KDE4 got beat up for dropping features and settings.
I would have thought that the GNOME project would have learned from that.
All it takes is one disturbance to a users work flow like this issue and the will be sour and scream it from the blogtops.
I predict this line about all settings killing kittens will be widely quoted after after GNOME 3 release as an example of how arrogant and out of touch with reality the GNOME designers are to the needs of real users. It’s pure idealistic dogma.
It’s inevitable that some of this happens otherwise it wouldn’t be a major upgrade. But I would have though we should pick our battles carefully.
It’s a simple enough setting that people understand.
Zizzle,
Change in the open is hard. Design in the open is hard. I’m not sure how GNOME could do anything different without greater design/community management resources and/or reducing our commitment to the quality of our product. I don’t think sticking our heads in the sand is an option here, though.
One of the reasons I wrote my blog post is that I don’t think it is a simple setting at all – it stands at the intersection of a number of tricky design problems that we’re trying to figure out.
I am once more astounded how much less receptive some GNOME users are of change than, for example, Mac users. Without change, there is no evolution.
Better have a radically different GNOME 3 that some people will not pick up than having another lame instantiation of the same old thing and pretend it’s revolutionary because it’s now all a bit shinier (think KDE 4)…
Different is good! Even if some changes should not be successful and be dropped, or changed to something else again, without being different, GNOME 3 could not represent a progress at all. In that sense, even the ‘Unity’ (which should in all honesty have better been called ‘Discord’) fork is a good thing because it presents an alternative. I predict that either Unity or GNOME 3 is going to die; or both are going to die because people stick with GNOME 2 (or ‘the fallback mode’). Either way, this is a progress over stagnation.
Given all the big changes being made in Gnome 3, having users disagree about removing an option that would be a pain in the butt for them (and providing valid use case examples of that) is not being “unreceptive to change.” Let’s not trot out the tired old “change is good” horse when people disagree with the rationale for a very specific change. Change isn’t good if it doesn’t solve a problem.
Hi again, Jer,
I completely agree that all change is not necessarily good, and change for the sake of it obviously isn’t good either. One thing I tried to explain in my post, though, is that GNOME’s settings really did have to change for GNOME 3. They’d become bloated, they were overly complex, they didn’t work with touch screens, and they weren’t well-suited to netbooks. They needed an overhaul and every setting needed to be assessed and reconsidered within that. People have latched on to this particular issue, but the bottom line is that GNOME is going to be in better shape as a result of these changes. There is no question about that.
What about “not suspend” when lid is closed while on AC power (presentations, for example) and “suspend” when on battery (close the laptop and rush to the plane)?
Hey Francisco,
Yep, that’s a good idea. I think we’ve already implemented some of that (not entirely sure… a developer could certainly give you a better idea).
Suspend-on-lid-close by default is a great idea. Making users go through gconf/dconf to change that is odd. There is a prevailing common wisdom among Gnome developers that “this is what most users want”, but no data has been shown to validate this. What HAS been shown is that the CURRENT Gnome users, the ones who care so much about Gnome that they follow the planet and comment on developer blogs, are very vocal in demanding this option in the settings GUI.
Gnome depends on these users as ambassadors to bring in those fabled “regular people users”, since the marketing push won’t reach them. This isn’t about feature creep anymore. This is about undermining the community as a whole because some designers fell in love with their own designs.
People are not in agreement about what The Right Thing is, so the only correct course of action is to leave that as an option to the user. Anything else would alienate many, many people.
Actually I don’t think many people have any objections with their laptop suspending when they close the lid; quite the opposite, they tend to be delighted if it suspend works…
You’re proving his point here. Where is your quantification of »I think what users want«?
Hi Jimmy,
I can tell you for certain that no one is prioritising their own designs over the needs of our users. That isn’t how GNOME works.
What I tried to explain in my blog post is that including a setting for this isn’t actually a neutral option – it does have potential negative consequences. I’m not saying it’s definitely the right way to go – just that it’s not straightforward either.
Your point about how we provide evidence points to one of the really tricky things about how we communicate design work. Fact is, we don’t have massive of resources to do tonnes of user testing, and quantitative evidence bases aren’t always the best basis for design. When we do design, however, we do draw on a lot of evidence. Thing is, it tends to be diverse – what other people are doing in the field, stock usability principles, papers we’ve read or studies we’ve participated in, casual observation plays a role too. So it’s difficult to point to a single bit of evidence, but that doesn’t mean to say there isn’t a lot of evidence in the mix, as well as quite a lot of nuanced work involved in making sense of it all.
Removing this option fromt he control center and placing it in the hands of applications will just lead to more inconsistency. Then my laptop will suspend when i close the lid depending on what programs I have open. We also can’t reasonably expect all applications to behave correctly. I run quite a few KDE apps (for instance).
All the effort put into the design for Gnome3 is appreciated, and most of us are liking what we see. However, this is a decision that is ultimately not a good one to make on behalf of the user.
You can make the default be to suspend, no problem with that. But removing the GUI option to change this behaviour and hiding it in dconf is not a good move. It is not only experienced Linux users who would want to be able to disable this, and requiring a drop to the command line to do something as basic as this scores less for usability, regardless of how much more sexy the resulting dialog box becomes.
We want Linux for Human Beings, even if some of us are gods. Human beings do not want to touch the command line, ever. If it can be helped.
(As you may have guessed, I run Ubuntu, a large part of my decision to use Ubuntu was made in the fact that getting my proprietary hardware to work was only one click away as opposed to Debian, even though I knew and know how to hunt down the correct repository, add it, and then install, or in the worst case, compile my own drivers).
Hey fanen,
Nobody is prioritising the sexiness of the preferences interface. Of course we care about functionality (that is our main priority, in fact). And nobody is imaging that users will be using dconf to change the preference.
As for the point about inconsistency: I think that can be solved with a combination of UI guidelines and proper API.
“What makes this issue so difficult is that many applications and services simply do not do the right thing when it comes to suspend/resume, and some of those services are used particularly heavily by the user communities that are close to GNOME.”
No, that’s not the problem. Suspend/resume works utterly fine on my laptop; it’s perfect. I use it all the time. The issue is simply that _I do not want to suspend the laptop when it’s plugged in and I close the lid_. Not ‘suspend does something bad otherwise it would be fine’; that’s simply absolutely not what I want the system to do. You can expound at length about how it’s a good thing if you like; you’re not going to convince me I’m wrong. I know how I use my system and I know it makes absolutely no sense for it to suspend when I close the lid and it’s plugged in. You do not know as well as I do how I use my computer. I think you’re working from a fundamentally broken assumption here – that everyone who wants to not suspend their laptop when they close the lid is doing something wrong, or attempting to work around broken behaviour somewhere else, or something along those lines. It’s simply not the case. It’s not true that, if you fix the kernel and everything so that your ‘ideal behaviour’ is implemented completely perfectly every time, people who currently set their systems not to suspend when they close will be happy. A suspended system is still suspended, and that’s not what some people want.
Hi Adam,
I honestly wasn’t trying to tell you that you’re ‘wrong’. I’m sorry if you got that impression . And, of course I don’t know how you use your computer better than you do. I hope I didn’t give the impression that I did. Can you describe or explain how it is that you use your machine(s) in relation to this particular issue? I’d like to hear about it.
[Edit: what my post describes as ‘wrong’ is applications or services which do not play well with suspend/resume. In an ideal world, you wouldn’t miss IRC messages if you suspend, for instance – they’d be logged on the server. I wasn’t saying that not using suspend/resume is wrong.]
As this is a continuation and you asked me some direct questions, hope you’ll let this comment through.
What triggered my comment was this paragraph:
“What makes this issue so difficult is that many applications and services simply do not do the right thing when it comes to suspend/resume, and some of those services are used particularly heavily by the user communities that are close to GNOME. IRC is a particular issue here, but there are others that have been rightly identified by those who are concerned about this issue. We want GNOME to do The Right Thing, but that is difficult when so many other pieces of software are doing The Wrong Thing. It’s a question of responsibility as much as it is proper behaviour, and it’s a question of what we want to aim for in the future.”
That’s where you seem to be working from the thesis ‘well, all these people are pissed off because right now all these apps are stopping us Doing The Right Thing, but once all the apps are fixed, we can Do The Right Thing [which seems to be, always suspend on lid close], and all these people won’t be pissed off any more’. I just don’t think you’re right. No matter how much app behaviour you tweak, I don’t think you’re going to change the fact that I simply didn’t want the machine to suspend.
How do I use it? It’s simple. I have my system set to suspend on lid close when on battery power, and blank the screen on lid close when on AC power. On battery power my usual use case is simply to close the lid in order to put the system in a bag or pick it up and take it away; obviously I want to suspend in this case.
When the laptop’s on AC power I usually don’t want to suspend it much. There’s no real need to; it doesn’t use a lot of power to run, it doesn’t melt when it’s closed (because it’s not a Mac, koff koff). Often, however, I *do* want to close it and leave it doing something – downloading a file, building some code, composing a live image. I don’t need it open while it’s doing this stuff; I’m not interacting with it, it’s just gathering dust on the keys and screen and blocking my view of whatever’s behind it. If I actually do want to suspend the system while it’s on AC power, I do it manually.
This configuration exactly matches my needs and it is indeed a config I set just once and forget about; I’ve never changed it. I get irritated every time I use a Windows laptop and remember you can’t set it up that way.
I don’t care for my personal case about this change, because I understand I’ll still be able to set my preferred behaviour in dconf. So, fine. I just don’t think you can reduce the options here as far as you seem to think you can.
BTW, I don’t miss IRC messages if I suspend. I use bitlbee. =) I still don’t want to suspend, though. See what I mean? The behaviour’s fixed, it didn’t change my use case.
I fully agree with Allan and the Gnome guys. Keep it simple is the way to go (but provide a gsetting/gconf setting for power users). I’m happy with reasonable default settings and that’s the main reason for me to use Gnome and not KDE or… And if I really want to alter a certain behavior: gconf-editor is enough for me.
Most important: average and unexperienced users (e.g. my girlfriend). For these every single setting is a additional hurdle.
Thanks to Gnome.
Suspend on default sounds fine to me. But I rely on the option of disabling that (keeping the screen on) with my netbook as it doesn’t properly suspend and I end up having to reboot it and losing anything I was working on.
Hi Allan, thanks for your work.
Reading your post and comments, it seems like you think people keep changing their settings to suspend or not suspend when the lid is closed. That would be a bad thing and a setting is really not adequate for that. But that’s not how I use this settings at all. Since I not always want my laptop to suspend when I close the lid, what I do is to disable it in settings only once, and when I do want to suspend my computer I just press a button before closing the the lid.
The fact is, for my use, a setting is all I need. I’m sure there might be a better solution that fits more uses, but if you don’t find it, consider adding the setting back in for the people that use it.
Thanks for all the comments, everyone! I’m going to the pub now. Moderation will recommence tomorrow. 🙂
Hi Allan, it seems somewhat unfortunate that someone who works in the open and for the public benefit opens themselves up to so much criticism from people who want easy free software that does exactly what they want… I do appreciate the work people like you do, but I also feel compelled to put forth my take on the whole “settings” issue:
You say “many applications and services simply do not do the right thing”, but you neglect all the hardware that doesn’t do the right thing, and the consumers (your target audience) who don’t buy the right hardware, and you just can’t fix either of those. Further, you buy into the quixotic notion that computer programs should know what to do absent direction from the user, instead of the reality that computers and programs are tools (often ill used due to this misunderstanding).
So clearly I’m not the target audience here… an embedded system developer who started with gentoo in highschool 8 years ago… but people like me who struggle every day to make buggy hardware and software work nonetheless very much value settings everywhere.
I to have done the ‘lid not fully closed’ thing too. On my Linux notebook suspend does not work. For 3 yeas now I’m hoping for improvement (me not a programmer). But as it is a ACPI implementation issue there’s not much I can do. But this kind of understanding and investigating should not be required by the average user.
I’d say the UI should cover for the majority – but what happens when 50% want suspend on close and 50% want a blank screen?
“default to suspend on lid closing, and don’t provide an option to change that setting. I could write at length about why suspend-on-lid-close is A Good Thing but won’t for sake of brevity.”
Please do, I’m really interested in the background for this decision that isn’t “We are just copying MacOSX without reason”. Since MacOSX made this design decision for a specific hw reason in that their hw will physcially melt if left on in a lot of cases. We don’t have specific hw reasons in GNOME since we don’t have a hardware reference platform.
I don’t see how you come to that conclusion. To what I read people really are concerned about the laptop going to sleep when closing the lid. The provided serious
and valid uses cases why they don’t want their laptops to shutdown. All the options mumbling only exists because this people proposing it acutally are empathic people trying to offer a compromise.
As you obviously failed to extract the valid use case I want to help you:
* Don’t loose network connection when moving to a different room. This scenario is very common for every notebook ever leaving the flat. It happens in school, it happens at work, it happens at conferences. Everyone does it. Permantently.
* Don’t get annoyed by bright screen and leds when letting the computer perform long running operation: Compiling, media encoding, SETI@home, …
* Don’t let the cat walk over the keyboard when playing music, doing VoIP.
This are fairly common usecases and I really wonder how a good UI designer could have missed them.
Idea to reduce options really is good. Options kill kitten. Still there always is a limit for simplification. At some point you cannot go further without making a system useless. Unless you come up with a solution realistically permitting the use cases listed above you’ll have to keep the option I fear.
Actually for the third use case there is a simple solution. Media players already tell the screensaver to not kick in when a video is played. Same approach should work for preventing suspend. Still it might not work for chat sessions (how shall Empathy, XChat decide when they can permit suspend?). Even less it will work for tools like gcc.
Seriously, this discussion seems like a huge waste of developer+designer time. 🙂
What is the issue over? The time spent to try to explain/argue which issue is sane, this time would probably wisely spent on solving other real design issues. 😉
The question for me becomes this. How do we adequately expose, document, communicate, and use the ability to on-demand inhibit for use-case that currently rely on a user adjustable setting.
Perhaps a convenience wrapper can be developed for long running applications so you can call something like gnome-inhibit-suspend my-application and the gnome-inhibit-suspend wrapper will do the magic necessary to set the suspend inhibit state.
-jef
Different people have different ways of working with their computers. There are some things that just don’t work the same for everyone. The behavior on lid-close is one of these things. You absolutely need a setting here or you are forcing a good percentage of users into changing the way they work with their computer or into switching to a different desktop.
And no, this is not about fiddling with the setting. You set this once the way you prefer it and leave it there. I wouldn’t consider to enable suspend-on-lid-close, not even temporarily, but I agree that it is probably a good default choice. Just give me (and others) a chance to turn it off.
Oh and making the behavior dependent on whether the computer is on AC power or on battery is really the worst thing you could do. Then it becomes totally confusing and unpredictable.
Another thought to throw into the discussion, there are actually multiple breeds of laptops and multiple types of laptops in use. Specifically, apart from a “laptop”, “notebook”.. there is also the desktop-replacement style of laptop (i.e., has 1 7″ or 19″ screen and weighs a ton). I wonder if these desktop replacement ones are more likely to have the suspend on screen close behaviour? My non-techie wife is a big hater of suspend-on-close (she uses her laptop as a desktop replacement).
I wonder if there is a such thing as a setting that is too contentious to be worth the effort? This one would easily fall within the realm, requiring very careful consideration AND significant data proof before changes. I, for one, have never had my laptop overheat because I walked around with the lid closed… so that main argument is not particularly true for me. The other suggestion that by default I actually want it to suspend when I close the lid, has no more justification as a generalised assertion than me saying that everyone wants just a blank the screen when they close the lid. I think this is definitely a situation where I have seen insufficient proof for the rationale being used to hide the property, as this proof needs to counter my own personal experience, that most of the users I support (family, friends etc.) do not like their laptop suspending or hibernating whenever they shut their lid (as seen by the excessive swearing that happens when they open it back up and wait!).
Another question is that I know a reasonable portion of computer users that are not terribly technical, that do know the difference between suspend & don’t suspend (hibernate vs suspend they couldn’t tell you though). This implies that the concept isn’t as advanced a topic as this decision convey, hence the requirement for dconf knowledge to change the default behaviour is a little extreme.
All in all, my only complaint is that the setting for what to do by default when I close the lid shouldn’t be hidden, without equivalent behaviour being implemented. This post, and the linked one, both suffer from the same short coming which that functionality removing what I and some others used regularly (not efficiently I agree, but regularly all the same), while offering absolutely no alternatives other than the windows equivalent of a registry hack.
Positive notes though
* The idea of apps inhibiting this function is a good idea, and definitely something that I would like to see (though I do agree with a prior comment that we can’t throw away the ability for the “normal user” to configure their computer default when most of these apps will take months/years to Do The Right Thing)
* I think a large portion of the complaints would be addressed with a timeout between shutting the lid and suspending (e.g., 5-10mins)
* The external monitor detection is cool
I’ll vote for default Suspend-on-Lid-Close. It’s what I want.
The problem with that setting is that too many laptops are broken somewhere. Most netbooks always mark lid=closed for example. Therefore boot=suspend. The problem is most likely in either the netbook motherboards, or the BIOS. However, until the Linux power stack caters for that forcing Suspend-on-Lid-Close is likely to cause an outcry.
Don’t get me wrong: I want Suspend-on-Lid-Close. It just doesn’t work at the moment, and it’s not Gnome’s fault.
eg. https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/481312; https://bugzilla.gnome.org/show_bug.cgi?id=622026
(to add to the test cases?)
If you really think that settings kill kittens, why on hell does gnome-shell FORCE you to have accessibility settings on your panel??? I think disabling suspend when closing lid is by order of magnitude much more useful than switching to high-contrast.
Hi Xavier,
Erm, I didn’t design GNOME Shell? (Please don’t take the ‘kills kittens’ remark out of context. It was part of a paragraph, and it was part of a link to an article…)
As far as I can tell, two entirely independent issues exist here.
First, some systems have broken behavior on suspend, or broken behavior if you don’t suspend. I don’t see any problem moving those issues to a better location, such as an in-kernel blacklist of broken hardware together with better handling of thermal problems; GNOME3 seems like a fine time to make that transition. That use case doesn’t justify anything more than a hidden preference as a workaround, and if the kernel puts in a way to add to the blacklist dynamically then you don’t even need that.
Second, “suspend” means stopping various types of ongoing program activity, and not necessarily waking up if those programs need to run more. Among many other use cases, people have mentioned playing audio, long-running compiles, and active network connections. Unlike the previous case, this doesn’t have an immediate fix. A preference doesn’t necessarily fix this problem either, but it does provide the current best-known workaround.
If suspend states acted like processor C-states, which save power when you don’t use the processor but wake up when you do, then “suspend”-on-lid-close would not require a workaround preference. For instance, suppose that your hard disk used ~0 power when not accessed for a while (SSDs come close), your screen blanked when closed, your video card’s CPU turned off when the screen blanks, your RAM and video RAM went into auto-refresh mode, your chipset had sleep states like your CPU, your Ethernet card used ~0 power when not connected, and your Wifi card used ~0 power when not transmitting or receiving. In other words, suppose your laptop acted like many existing mobile devices which can last days or weeks on batteries, and which need no ventilation even in a pocket or bag. Under those circumstances, you wouldn’t just suspend on lid close, you’d stay “suspended” most of the time you used your system, even between keystrokes, and you wouldn’t even notice.
We keep moving closer to that goal, and I love seeing Linux and GNOME working in that direction. When we get close to that point, and systems that don’t have that behavior become the exception rather than the rule, then we won’t need workarounds or preferences anymore for suspend. However, until then, we do need some kind of workaround for the various use-cases of ongoing program activity; whether that means a preference or some other mechanism remains an open question. Either way, please don’t jump the gun and assume the perfect systems we eventually want while breaking the systems we have. Feel free to remove the preference (I’d love to see it go), but only after you’ve determined a suitable replacement workaround, not before.
For measuring temperatures (tools development) I have to keep my laptop running for weeks. Closing the lid to suspend is just not going to work.
Keeping the lid open a bit to protect the keyboard does not help much either-
‘ I just closed the laptop – looked so awful – Mom’
The one-button-guys, who need the software to do everything with the push of a button, as well as some of the “majority of users who prefer it this (or that) way” are no real help in a GUI – design.
A developer should really listen and make cautious decisions. Arguing never helped.
“Convincing” the user of the “right solution” surely back fires.
And there is the fun – take the pride if you decided right – take the fire, if not 🙂
As long as one needs to know how to handle a traffic situations if the traffic light turns red, it can be expected that one can handle option changes.
The ultimate simplification would be the computer does it w/o human intervention.
Then the meaning of “There is no options left.” might become a totally(tarian) new twist.
We are not there yet.
Incidentally, I’m one of the people that do change this fairly often: I keep normally it at “suspend on lid close”, but disable it if I’m e.g. at work, since I’ll probably be moving the laptop around (and would prefer if it didn’t suspend while doing so).
Thinking about it, I’d be quite happy with a “don’t suspend on next lid close” one-shot setting somewhere easily reachable, ideally not preserved through logouts or reboots. How about the dropdown menu from the battery icon in the status bar; indicated by some form of overlay (or by temporarily growing another icon beside it – after all, this would be something that’s only visible in the seconds from clicking to closing the lid, and if it stays around longer than that, it’s probably worth the extra space/noise to remind the user that they’ve left it on).
It’d even be a nice party trick … “Tired of carrying your laptop around open? Just do *click->click* this, and it’ll ignore the next time you close lid.” I can actually imagine that being useful to more people than those who are currently aware that you can turn off suspend-on-close in the first place. Then again, I do admittedly have a vivid imagination.
I love that GNOME’s designers are removing preferences. This is a a Good Thing™. Every time you leave the design up to your users, you’ve failed them. I wholeheartedly believe that.
The question now is: was this the right default for the designers to choose? I believe not. I can think of several use cases where you definitely don’t want your laptop to suspend immediately as you shut the lid. Use Case 1: You use your laptop as your desktop, and its default location is on the keyboard tray. You prefer it to be on all day because you like to connect to it remotely, or you have a downloader running in the background that needs to be on at all times. You leave the house, but you want to shut the lid and slide the keyboard tray in. Use Case 2: You use you netbook as a portable music player. Carrying an netbook that is open with you on a crowded subway is not a viable option, so you plug in your earphones and put the netbook in your backpack.
I’m sure there are other use cases, but these are the ones that are very real to me, as I experience both of them regularly. Which brings me to my point: perhaps the default should have been different. In my use cases, there are certain applications running that need the computer to remain on. I think it would make more sense to suspend when the lid is closed only if there are no such applications active. So, I’m left with a few questions: With the current settings, will these types of applications be able to prevent suspend in these situations? Will the laptop suspend when these applications have decided they are done doing what they need to do? If the laptop is suspended, will it wake up if I try to access its shared files over the network?
Ultimately, the worry about overheating is really a bug in the kernel’s power management. The kernel should know what do to in order to prevent this. Suspending immediately when all laptop lids are closed seems more like a workaround for this behaviour than a real fix. I would prefer a real fix—all without extra settings for the users to “choose”.
Just to set things straight from the beginning: I’m writing this because I really like gnome and I think you guys are doing a great job. But I’m very much against removing the option.
Judging from your (Allans) replies to the comments it seems that the problems caused by removing the option will greatly overshadow the benefits that you think will come from removing it.
Should a system of rules for when and when not to suspend on lid-close replace a simple setting?
Should all applications that a user might want running when the lid is closed have a feature built to navigate this set of rules?
Should the user be notified with a sound if suspend is inhibited? (Many people find system sounds annoying and perhaps even embarrassing at meetings)
From what I have understand the main arguments for removing the option is that the dialog has to fit on low-resolution displays, and that the possibility to choose confuses the user.
I completely agree that the dialog has to fit. But isn’t there another solution than removing basic options?
Perhaps it would even confuse users more if the option is removed. “Where the hell did they put it then? It must be possible to choose! It’s possible in [insert-any-other-DM-or-OS-here]” – that’s what I would be thinking if I hadn’t read this post and the post on Richards blog.
Great work on GNOME3. Don’t let the feedback get you down.
I agree that the override for this shouldn’t be in preferences. We should encourage applications developer to “do the right thing”, but provide a simple applet to override the preferences when required. You could even include a toogle button in these preferences to show/hide the applet. That way if users want to manage this regularly they can do so without changing preferences. Or add the applet from a hyperlink in the preferences dialogue, but hide the link once the user has followed it once – that way users new to this can discover it, but ordinarily it doesn’t foul up the preferences screen.
The “after” panels look infinitely better if just for having only one close button – the one in the frame. Has the decision to add an extra close button finally been reversed? Also, why is “Help” next to “Close” in one panel and opposite it in the other panel?
Make everything as simple as possible, but not simpler. (Einstein)