From Internet Tablet Talk forum:
http://maemo.org/pipermail/maemo-users/2007-January/002690.html

"Oh, you can, check /etc/systemui/systemui.xml and uncomment 'Soft 
poweroff'. There is also nice 'Reboot' option, useful if you regulary 
reboot to different rootfs with boot menu."

Comment 2 Neil MacLeod (reporter) 2007-01-13 15:40:12 UTC

Hi Laurent

The "Soft Poweroff" option is accessed via the Power button which is something
that doesn't work for me. Not only is it dependent on the Power button (which is
far too small and also recessed which only adds to the problem) but in addition,
"Soft Poweroff" is not a complete replacement for the cover-on functionality in
the 770 as WiFi and BT are not disabled.

My preferred solution would for putting the N800 into a 770 "cover-on" state
would *not* be dependent on the Power button because the Power button is too
small and fiddly to press on a regular basis. Depending on usage patterns,
putting the N800 into (and taking out of) the "cover-on" state may occur several
times a day, sometimes in a hurry and the last thing I want to do in such a
situation is fumble around with an button explicitly and intentionally designed
to be HARD TO PRESS! :)

(In reply to comment #2)
> Depending on usage patterns,
> putting the N800 into (and taking out of) the "cover-on" state may occur several
> times a day, sometimes in a hurry and the last thing I want to do in such a
> situation is fumble around with an button explicitly and intentionally designed
> to be HARD TO PRESS! :)

I couldn't agree more. The use case is something like "check mails while waiting
for train on platform, train arrives, tuck N800 away quickly". You wouldn't want
to press a small button, wait for a menu to pop up, select an entry, confirm,
put the stylus away. No, you want to press one single key (without a further
look) *while* the device slides into your pocket. It has to be one of the the
front buttons.

Actually, this bug asks for the software to replace a missing piece of hardware,
doesn't it?

Comment 4 Neil MacLeod (reporter) 2007-01-21 08:10:40 UTC

See bug #959 for further details on why it is currently impossible to put the
N800 into a form or standby. Even if bug #959 is resolved, there is still the
issue of suspending wireless activity. Perhaps the "Power" menu needs to be
enhanced with wireless related options (eg. "Lock and suspend wireless"), and
the order of options within the menu should be configurable to allow users to
quickly select the first option using Power + D-pad center.

However, the ability to put the device into a "standby" mode using one of the
large, front-facing buttons would still be preferable in the long term.

Comment 5 Andrew Flegg 2007-01-27 17:48:43 UTC

I've been enthusiastic about "soft poweroff" (even moving it to the top of my
power menu), but existing network connections remain up: the device can still be
pung and SSHed into whilst in "soft poweroff" mode.

That'd be *very* soft power "off", then...

Comment 6 Neil MacLeod (reporter) 2007-01-27 23:56:12 UTC

Agreed, *very* soft power off would do the job. :)

What's needed is (1) the 770's "case on" mode with immediate screen disablement,
and *optional* wireless disabling, (2) implemented using an easy to access front
facing button.

Depressing the Power button for a second by default switches the device OFF, so
this would at the very least need to become a configurable option (Control Panel
Applet) to toggle between Device Off, Case-on, Lock touchscreen etc. - this
should be incredibly easy to add.

Ideally though, another button should also be used to implement the case-on
functionality since the Power button is simply too small, and it's intentionally
designed to be hard to press so isn't suitable for regular daily usage as would
be required by the "case on" function.

It sounds like we need something like TealHacks or HackMaster for this device.

Back when I had a Palm Pilot I had a thirdparty app (TealHacks with TealLaunch
from TealPoint software) that allowed me to create all sorts of custom shortcuts
as combinations of pressing multiple buttons simultaneously, holding buttons for
extended periods, or making specific strokes on the silk screen. Since this
device doesn't have a permanent silk screen, that's not.

There could, perhaps, be a "Shortcuts" Personalization option in the Control
Panel. One could define, for example, that holding the D-pad center for 2
seconds sets the device to offline mode and then softoff. Pressing and holding
for 2 seconds again turns it back on and enables online mode.

Users could define other shortcuts to launch applications, etc, if they desired.

I suggest it like this because having something other than the Power Button
perform power tasks is not illogical and not obvious. It would be, however,
extremely handy as many pointed out. So long as we're going to do something
non-obvious and handy, we may as well give it the potential to be super-duper handy.

I filed the very similar bug 1077.

Comment 9 Neil MacLeod (reporter) 2007-02-19 02:38:07 UTC

*** Bug 1077 has been marked as a duplicate of this bug. ***

Adding my vote for this also.  Any button sequence would be better than none at 
all.  The suggested double click home would do just fine however.

Changed to Enhancement and Quim Gil added to CC-field.

Comment 12 Neil MacLeod (reporter) 2008-07-19 01:20:10 UTC

I've been using Autolock[1] on my N810 and this goes part way to achieving the
old "770 cover on" functionality. Autolock will automatically lock the screen
whenever the device goes into darkness (ie. into a pocket, or inside the N810
flexible slip on cover) and automatically unlocks the screen again when brought
back into the light. It actually works incredibly well and and is about the
only good use so far for the ambient light sensor on the N810! :)

If the "Autolock" functionality - which is frankly genius - could be
implemented as standard in the OS (remember Nokia: "It's OK to steal/copy other
peoples ideas if they're good") along with control panel options to specify
whether WiFi/Bluetooth should be disconnected when locked, then this bug could
be marked closed/fixed, at least for the N810 and any other future devices with
light sensors... unfortunately I seriously doubt we'll see any movement on this
bug for the N800. And even though it would be wonderful to see Autolock rolled
into the OS as standard, I doubt that will happen either (not invented here
perhaps?)

1. http://garage.maemo.org/projects/autolock/

Comment 13 David Weinehall 2008-07-23 16:28:24 UTC

@Neil: The Autolock behaviour would be really annoying for me, at least; I
quite often use the device at night, and I'd hate it if the device turned off
the screen automagically =)

Oh, and soft poweroff can be configured to be a complete replacement for the
cover on functionality of the 770; there are options in mce.ini to make it
change to offline mode (with or without offline mode saving).

Comment 14 Neil MacLeod (reporter) 2008-07-23 17:32:34 UTC

(In reply to comment #13)
> @Neil: The Autolock behaviour would be really annoying for me, at least; I
> quite often use the device at night, and I'd hate it if the device turned off
> the screen automagically =)

I would never suggest that it should be ON by default, but it could easily
become part of the OS and the user only has to enable it, just as they set the
backlight timeout or device lock or LED settings now. I consider Autolock to be
a very good use of the ambient light sensor and think Nokia would get kudos for
building it into the OS as standard, even though it wasn't their idea, and it
would be seen as a "neat" touch and a genuinely useful feature (and God knows
Maemo OS is desperately in need of those).

That said, the problem you raise is already addressed by Autolock as the
autolock function can be temporarily disabled and re-enabled by manually
sliding the lock switch.

As an aside, I don't know how others feel about Nokia copying good ideas from
the community to build into the base OS - as long as the Nokia code isn't
closed and Nokias intentions are discussed openly is this a problem? Probably
not a topic of discussion for this bug though...

Comment 15 Neil MacLeod (reporter) 2008-07-23 17:39:41 UTC

Also, sliding out the keyboard will also temporarily disable the autolock
functionality - to re-enable autolock either close the keyboard or activate the
lock function, usually with the hardware lock button.

Comment 16 David Weinehall 2008-07-25 15:28:03 UTC

I don't think Nokia has a problem with copying ideas from the community; nor
from anyone, as long as there's no patents covering the ideas.  However, since
upsetting the community would be a quite bad idea, I'm fairly certain we'd ask
first.

Guess I'll have to try that Autolock add-on to see how it behaves; I cannot
really grasp how it could possibly behave in a way that'd work with my normal
usage pattern.

Comment 17 Quim Gil 2008-12-15 09:21:44 UTC

Changing the subject to reflect the feature that is actually requested without
references to the 770 cover - since it's not in the current hardware.

Comment 18 Quim Gil 2008-12-23 16:21:56 UTC

Let's have a look at this from a Nokia Nseries perspective, including the N810. 

As for today:

- A short press to the Power button shows you a menu with separate options
"Lock keypad" and "Offline".
- Wlan or data connection goes on/off automatically when there is an
application or daemon on/off activating or inactivating them.
- Some devices (like the N810) have an additional Lock hard button.

In our opinion, this is good enough nowadays.

The request here is to provide "Lock keypad" + "Offline" at once, in a single
button click. 

But if the main use case is to put the device in your pocket and go somewhere
else... isn't enough to lock the device and just run away, out of the wlan's
reach? This is what I do every morning and no issues are found. While commuting
from home to office I leave the apps open so they connect automatically again
once I reach the office wlan. For longer trips closing the apps makes probably
more sense.

With the arrival of cellular data the devices with Maemo 5 will be in a same
situation that the S60 phones in terms of connectivity. People usually select
the "Offline" option when jumping on a plane. The rest of the time they have it
available just in case an app requires it.

Therefore, this report looks like a combination of FIXED (locking the device is
quick and we expect it to remain quick) and WONTFIX (we don't think it's worth
to add an additional option for "lock+offline" in a single click).

Said that, I still don't know whether there are significant changes in
Fremantle Harmattan in this direction and maybe making it a 100% FIXED. CCing
Roope since he might know better.

Comment 19 Eero Tamminen 2008-12-23 16:34:21 UTC

The reason for using "offline" mode (I use it daily) is that it saves
significantly battery because there are several processes in the device which
will do occasional network traffic unless the device is set to offline mode,
and the device will also do WLAN scanning when it's not in offline mode.

(Whether it needs separate shortcut is another matter.)

Comment 20 Quim Gil 2008-12-23 16:55:44 UTC

To put this in the Maemo 5 context: "Assume no less than always online"

http://www.slideshare.net/silpol/maemo-community-fremantle-support-september-2008-presentation/

In this context, I wouldn't be surprised if Maemo thinks that it's ok to have
extra click for setting Offline mode.

S60 devices have a prominent "WLAN scanning off", but now I don't know what are
the Maemo plans there.

Comment 21 Quim Gil 2009-01-06 18:06:41 UTC

I just noticed https://garage.maemo.org/projects/autolock/

What about adding a feature request for wlan-off?

Users really willing to have the functionality described here could install
that simple application and problem solved.

PS: I still need to ask about Harmattan plans and the opinion of the UI guys
about this.

Comment 22 Neil MacLeod (reporter) 2009-01-06 18:56:45 UTC

(In reply to comment #21)
> I just noticed https://garage.maemo.org/projects/autolock/
> What about adding a feature request for wlan-off?
> Users really willing to have the functionality described here could install
> that simple application and problem solved.
> PS: I still need to ask about Harmattan plans and the opinion of the UI guys
> about this. 

See comment 12 and later in this bug. :)

I agree that adding a wireless-off feature to Autolock would be very useful and
would go a long way to fixing this bug/enhancement for some users. I actually
think Autolock is such a good idea that it should become part of the OS as
standard, but for reasons mentioned below I would prefer to keep this
enhancement open.

Obviously Autolock only works on devices with ambient light sensors, and other
users may want to invoke "Quick Standy" using a button method/combination (eg.
sliding the Hold switch) rather than based on the level of ambient light.

I don't know what plans you have for different power profiles (bug 1046) but in
some ways this enhancement could benefit from those profiles or even invoke a
specific profile whenever "Quick Standby" is activated.

Of course if we wait a bit longer before agreeing anything we can just ignore
those N800s as they'll be obsolete/end of line/out of support etc before much
longer. ;)

Comment 23 Ryan Abel 2009-01-06 20:01:29 UTC

(In reply to comment #22)
> I agree that adding a wireless-off feature to Autolock would be very useful and
> would go a long way to fixing this bug/enhancement for some users. I actually
> think Autolock is such a good idea that it should become part of the OS as
> standard, but for reasons mentioned below I would prefer to keep this
> enhancement open.
> 

You do know you can configure soft poweroff to enable (and disable)
offline-mode upon activation? See /etc/mce/mce.ini.

Comment 24 Roope Rainisto 2009-01-07 13:16:01 UTC

For what the bug is requesting, a fix to the N800 SW, the answer is
unfortunately basically wontfix - pending of course what happens with Fremantle
SW compatibility with N800/N810 - this is no comment to that open issue. 

Fremantle + device will have good means for quick touchscreen standby, so we do
agree on the need for such a feature. 

As Quim for instance points out, with cellular data future SW:s basically
assume "always online" in one way or another, either though cellular data or
wlan (or other radios). So also having a quick access to all radios off is not
terribly high on the priority list. Access will be there, but it isn't assumed
that people would actually want to do that often. (It's not assumed that users
would have to care about setting anything related to connectivity in general,
it should just work...)

Now, there is lots of good discussion inside this bug, but this is as for the
original issue and request.

Comment 25 Neil MacLeod (reporter) 2009-01-07 14:25:30 UTC

(In reply to comment #24)
> For what the bug is requesting, a fix to the N800 SW, the answer is
> unfortunately basically wontfix - pending of course what happens with Fremantle
> SW compatibility with N800/N810 - this is no comment to that open issue. 

The bug/enhancement applies to existing and future Maemo software just as much
as any specific device from the past - just because I mentioned the N800 does
not mean the bug is now invalid simply because the N800 is
end-of-line/obsolete. If you take that approach you can WONTFIX pretty much
every enhancement ever raised in this bugzilla!

> Fremantle + device will have good means for quick touchscreen standby, so we do
> agree on the need for such a feature. 

Great...

> As Quim for instance points out, with cellular data future SW:s basically
> assume "always online" in one way or another, either though cellular data or
> wlan (or other radios).

The addition of cellular hardware in future devices is irrelevant - chances are
I won't be using said hardware particularly if it costs me extra each month for
another SIM. Instead I'll continue to use the SIM in my phone and Bluetooth to
access the internet, just as I would with an N800/N810. So even in Freemantle
on a new device this bug still applies, please REOPEN.

Whether I'm using Bluetooth, WLAN, WiMAX or 3G/GSM the problem remains that
there are times when I want/need to shut off the radios quickly and
efficiently. I want efficiency because I'll be doing it often - many times a
day, every day.

Leaving the Bluetooth link to my phone switched on all day is the quickest way
of killing the battery in my phone, and it doesn't do my Nxx0 much good either.
When I walk into the secure environment that is my office building - where WLAN
devices are banned - I want to be able to quickly turn off the radios. When I
come out again I want to just as easily re-enable them.

Frankly, there are use-cases you are not considering and trying to convince me
that I want always-on connectivity simply isn't going to work: your way isn't
the only way people live their lives. Adding cellular hardware to a future
device doesn't change that fact one way or the other, it just adds one more
radio that I need to kill.

> So also having a quick access to all radios off is not
> terribly high on the priority list. Access will be there, but it isn't assumed
> that people would actually want to do that often. (It's not assumed that users
> would have to care about setting anything related to connectivity in general,
> it should just work...)

I'd say this enhancement still applies to Freemantle - please reopen.

> Now, there is lots of good discussion inside this bug, but this is as for the
> original issue and request. 

I think you are mistaken to view this enhancement only in the context of a now
obsolete device - by your own admission the problem will still be present in
Freemantle, so this bug should not be closed just yet.

This bug exists because of the flawed assumption which came about when the N800
was designed/released, which is that all users want and are able to be online
all of the time. While I'd be happy to be online all the time, sadly I'm not
*allowed* to be online all the time, in fact even having active radios in some
environments is verboten (very secure environments). This flawed assumption
still exists within Nokia and until it is addressed this enhancement will
remain outstanding.

All we want is what we could do with our 770s. Just give us that option again
on a new device, please.

Comment 26 Roope Rainisto 2009-01-07 14:30:11 UTC

Reopen

Comment 27 Roope Rainisto 2009-01-07 14:32:06 UTC

ok, we can also mark it like this:

Fremantle + device will provide a way for getting fast standby, although it
won't then give fast wireless off at the same time.

Comment 28 Neil MacLeod (reporter) 2009-01-07 14:39:05 UTC

Thanks for re-opening.

(In reply to comment #27)
> ok, we can also mark it like this:
> Fremantle + device will provide a way for getting fast standby, although it
> won't then give fast wireless off at the same time. 

Is there any way we can improve on this? The title for this bug is
"touchscreen+wirless off"), so without the ability to enable/disable wireless
this bug is not fixed.

As things stand I'm not sure we've made much if any progress in the 2 years
this bug has been open.

Comment 29 David Weinehall 2009-01-07 14:44:40 UTC

"What you could do with your 770"?  Quick standby wasn't the default for the
770 either.  You can still achieve what you want by editing /etc/mce/mce.ini
though, and that feature won't go away (unless someone forces me to remove it);
you can for instance configure it to be the action for a double-tap of the
power button.

And as for the use-case where you enter the no-radio zone at work, wouldn't it
be better to enable the offline mode? That way you can still use your device
(sans radio) at the office.  Of course, an Internet Tablet is a bit hampered
offline, but there's always games ;-P

Comment 30 Roope Rainisto 2009-01-07 14:46:48 UTC

Well, that is why I marked it as wontfix, but you protested. 

Our aim is to provide an user experience where the vast majority of users do
not need to care about having to conserve their power by turning radios on and
off all the time. I personally think of solutions like that (having quick UI's
for turning radios on and off) being ultimately cop-outs: since we couldn't be
good enough, we just put the responsibility to save power for the user. The
device should work good enough on a daily basis without having to worry about
conserving power.

Fremantle will have a _fairly easy_ way of turning also radios on/off. Having
it as easy as locking touch screen (imho) would make it too easy and too
accessible and therefore send a wrong signal of the users having or supposing
to do this by themselves on a daily basis. That is ultimately why we don't want
to promote this too much in the UI.

Comment 31 David Weinehall 2009-01-07 15:05:34 UTC

@Roope: well, it must at least not be made *more* complicated than it already
is, since turning off radios is regulated in many environments (hospitals,
airplanes, etc.).

Comment 32 Roope Rainisto 2009-01-07 15:06:47 UTC

yes to comment #31: I think people will find it fairly easy to find.

Comment 33 Neil MacLeod (reporter) 2009-01-07 15:08:58 UTC

> "What you could do with your 770"?  Quick standby wasn't the default for the
> 770 either.

Correct - it wasn't the default but the 770 did have a standard UI option to
enable the hard-cover wireless-off functionality. That's all I'm asking for
here (albeit without the hard-cover) - an option to allow me to choose what
happens when I put the device into standby.

  You can still achieve what you want by editing /etc/mce/mce.ini
> though, and that feature won't go away (unless someone forces me to remove it);
> you can for instance configure it to be the action for a double-tap of the
> power button.

I'd rather not have to resort to hacking, but if you could add wireless off to
mce maybe that would suffice.

> And as for the use-case where you enter the no-radio zone at work, wouldn't it
> be better to enable the offline mode? That way you can still use your device
> (sans radio) at the office.  Of course, an Internet Tablet is a bit hampered
> offline, but there's always games ;-P

Offline would be fine - can I have quick access to it?

The issue addressed in this bug has been the method of access to these various
modes not the fact they don't exist - the tiny power button plus menu plus OK
is less optimal/efficient than the old 770 method (cover on), so the purpose of
this bug is simply to make Nokia designers think about adding an efficient UI
method in order that users can achieve something they had in the original
tablet device. This is why Autolock is such a good idea - no UI input required,
just put the device in your pocket, unfortunately it doesn't kill the radios.

Comment 34 David Weinehall 2009-01-07 15:15:12 UTC

The option to switch to offline when enabling soft poweroff *is* already
available in mce.ini.

Relevant entries are:

ConnectivityPolicyCharger
ConnectivityPolicyBattery
ConnectivityPolicyPowerOn

And to enable soft poweroff, I suggest you edit either

PowerKeyLongAction

or

PowerKeyDoubleAction


All this said, I agree that adding a UI option to enable soft poweroff would be
nice; if nothing else it's a smooth option when you want to sleep -- no led
blinking, no connectivity (so no chat requests/voip calls, etc.), all in one
go...

Comment 35 Neil MacLeod (reporter) 2009-01-07 15:20:00 UTC

(In reply to comment #30)
> Our aim is to provide an user experience where the vast majority of users do
> not need to care about having to conserve their power by turning radios on and
> off all the time. I personally think of solutions like that (having quick UI's
> for turning radios on and off) being ultimately cop-outs: since we couldn't be
> good enough, we just put the responsibility to save power for the user.

You're not considering that the user may want to frequently enable/disable
radios for other reasons - power consumption isn't the only reason, so some
users may actually be grateful if they can enable/disable radios quickly and
efficiently, don't consider adding such user convenient functionality to the UI
a crime! :)

> The
> device should work good enough on a daily basis without having to worry about
> conserving power.

I agree with you, but this enhancement is not about power consumption.

> Fremantle will have a _fairly easy_ way of turning also radios on/off. Having
> it as easy as locking touch screen (imho) would make it too easy and too
> accessible and therefore send a wrong signal of the users having or supposing
> to do this by themselves on a daily basis. That is ultimately why we don't want
> to promote this too much in the UI. 

Unfortunately, making it too easy and too accessible is *exactly* what this bug
is about! If implementation of this feature has been blocked because it "sends
the wrong signal" then surely the right signal should be sent by appropriate
wording of the feature (or addition of help text) in the UI. Maybe it's another
Nokia "assumption" that the wrong signal will be sent - I can't imagine why a
user would be confused when being give the option to choose regular standby or
standy+offline when locking the device.

Comment 36 Roope Rainisto 2009-01-07 15:24:52 UTC

> Unfortunately, making it too easy and too accessible is *exactly* what this bug
> is about! If implementation of this feature has been blocked because it "sends
> the wrong signal" then surely the right signal should be sent by appropriate
> wording of the feature (or addition of help text) in the UI. Maybe it's another
> Nokia "assumption" that the wrong signal will be sent - I can't imagine why a
> user would be confused when being give the option to choose regular standby or
> standy+offline when locking the device.
> 

Well, suppose that if there would be a hard key (or similar method) for having
regular standby. We would want this key to work instantly, not to display two
options over what kind of standby you were actually looking for. (In a strange
way it reminds me of a Jerry Seinfeld sketch: "When do I want to feel good? Now
or later...")

Anyways, as also David is pointing out, once Fremantle gets released, people
can hack other behaviours there if they want to do so.

Comment 37 Neil MacLeod (reporter) 2009-01-07 15:26:41 UTC

(In reply to comment #34)
> The option to switch to offline when enabling soft poweroff *is* already
> available in mce.ini.
> Relevant entries are:
> ConnectivityPolicyCharger
> ConnectivityPolicyBattery
> ConnectivityPolicyPowerOn
> And to enable soft poweroff, I suggest you edit either
> PowerKeyLongAction
> or
> PowerKeyDoubleAction

Thanks, will take a look however...

> All this said, I agree that adding a UI option to enable soft poweroff would be
> nice; if nothing else it's a smooth option when you want to sleep -- no led
> blinking, no connectivity (so no chat requests/voip calls, etc.), all in one
> go...

I'd really like to see integrated, official support for this feature which is
essentially what we had in the days of the 770.

I'd rather not rely on an unofficial hack, which is what mce.ini is - it may
suffice, but it could disappear at any point in future and is not an option for
users unwilling to obtain root and tinker with system files. Also, as you point
out, there are other advantages to adding a proper UI - the blinking LED is a
good example...

As things stand much of the infrastructure is in place to support the required
functionality, it's just the UI (and will of Nokia) that is lacking.

Comment 38 Neil MacLeod (reporter) 2009-01-07 15:32:09 UTC

(In reply to comment #36)
> Well, suppose that if there would be a hard key (or similar method) for having
> regular standby. We would want this key to work instantly, not to display two
> options over what kind of standby you were actually looking for. (In a strange
> way it reminds me of a Jerry Seinfeld sketch: "When do I want to feel good? Now
> or later...")
> Anyways, as also David is pointing out, once Fremantle gets released, people
> can hack other behaviours there if they want to do so. 

Wouldn't it be possible to give the user the choice (in Control Panel) of what
should happen when this hypothetical hard key is pressed?

    a) Go into Standby
    b) Go into Standby + Offline
    c) Ask each time

The 770 had an options dialog which allowed the user to choose (choice - a
wonderful thing!) what should happen when the hard-cover was added/removed.
Some users would disable wireless, others left it active.

What's wrong with giving the user the ability to choose here?

Comment 39 Roope Rainisto 2009-01-07 15:37:52 UTC

IF we would have infinite time and resources: i.e. persons to specify
(different behaviours for wlan/cellular data switching under different
settings, combinations of selecting offline mode separately, then playing with
this switch separately; playing with this switch while in progress of data
transfers, combinations with other radios), and implement and test (multiply
test cases for having different settings) and translate strings to tens of
different languages and do the pixel layouts for the UI and write help
specifications for the various cases, and to translate these, and so on and so
on), and if this change wouldn't make Fremantle come out any later, then there
wouldn't be much wrong with it.

Comment 40 Quim Gil 2009-01-07 15:44:16 UTC

Reopening and assigning to me. 

We are mixing several discussions supposed to be happening already in several
places. The soft poweroff discussion belongs to Bug 3461 (Note: we need to
share a unique definition of what "soft poweroff" means in that report in that
Bug 3461).

First of all, let's agree on what is exactly being requested in this report.

1 - "Lock touchscreen and keys" + "Offline mode" in a single action (all
radios, including BT, WiMAX, cellular...)
2 - "Lock touchscreen and keys" + Wlan off in a single action.
3 - "Lock touchscreen and keys" + all radios but not cellular.

The implications and use cases are different.

Comment 41 David Weinehall 2009-01-07 15:54:03 UTC

The current intention (currently with some caveats, se below) is for the device
to appear "off" when soft poweroff is enabled (hence the name of the feature).

This means: no radios at all (offline), no led blinking, touchscreen/keypad
interrupts disabled, display blanked.

The caveat is that at the moment, audio is not disabled, so any program that
plays music will ruin the illusion :)  I'll add support for muting in a later
version of mce (but make it possible to disable the muting for people who so
desires).

Comment 42 Neil MacLeod (reporter) 2009-01-07 15:56:40 UTC

(In reply to comment #39)
> IF we would have infinite time and resources: i.e. persons to specify
> (different behaviours for wlan/cellular data switching under different
> settings, combinations of selecting offline mode separately, then playing with...

No offence Roope, but the bug has been open 2 years already - just because the
discussion on killing this bug or actually implementing it has only kicked into
gear a few months before the next OS release is not justification to continue
doing nothing.

Maybe something can be slated for Harmattan, if we can get debate going early
enough.

Comment 43 Roope Rainisto 2009-01-07 16:06:00 UTC

> No offence Roope, but the bug has been open 2 years already - just because the
> discussion on killing this bug or actually implementing it has only kicked into
> gear a few months before the next OS release is not justification to continue
> doing nothing.
> Maybe something can be slated for Harmattan, if we can get debate going early
> enough.

I was trying to hint that the amount of enhancement requests (it isn't really a
bug) for features is larger than the amount of resources available, so even
though some have been discussed for a long time, it doesn't automatically mean
that they would be in the pipeline. Yes, you could add an option for this, just
like for nearly any behaviour imaginable, but no addition is free.

Comment 44 Quim Gil 2009-01-07 16:09:33 UTC

(In reply to comment #41)
> The current intention (currently with some caveats, se below) is for the device
> to appear "off" when soft poweroff is enabled (hence the name of the feature).
> This means: no radios at all (offline), no led blinking, touchscreen/keypad
> interrupts disabled, display blanked.
> The caveat is that at the moment, audio is not disabled, so any program that
> plays music will ruin the illusion :)  I'll add support for muting in a later
> version of mce (but make it possible to disable the muting for people who so
> desires).

Ok, all this sounds cool but it doesn't look like a feature users will want to
use on a regular basis, say every time you want to put a device with Maemo 5 in
your pocket. Hence any discussion about soft poweroff is out of scope here and
is welcome at Bug 3461 .

The "regulatory" Offline mode is well covered by "Offline mode".  :)

There are reasons to think that users won't find much reasons to shut off the
cellular radio, specially if applications are clever at activating it only when
it's needed.

Probably same for Bluetooth.

The Wlan is a case appart since it does have a clear impact on power
consumption and you might have several applications in the background ready to
activate it even if you don't want to.

No idea about WiMAX but at the moment is not a main case. Probably same
behavior as Wlan?

For these reasons I think we are talking here exclusively about 

2 - "Lock touchscreen and keys" + Wlan off in a single action.

Do we agree on this?

Comment 45 Neil MacLeod (reporter) 2009-01-07 16:12:11 UTC

(In reply to comment #40)
> Reopening and assigning to me. 
> We are mixing several discussions supposed to be happening already in several
> places. The soft poweroff discussion belongs to Bug 3461 (Note: we need to
> share a unique definition of what "soft poweroff" means in that report in that
> Bug 3461).
> First of all, let's agree on what is exactly being requested in this report.
> 1 - "Lock touchscreen and keys" + "Offline mode" in a single action (all
> radios, including BT, WiMAX, cellular...)
> 2 - "Lock touchscreen and keys" + Wlan off in a single action.
> 3 - "Lock touchscreen and keys" + all radios but not cellular.
> The implications and use cases are different.

I'd go with Davids interpretation in comment #41, that works for me (and the
option to leave audio enabled is also valid, as I guess the user may be
listening to music with the device in their pocket, with radios disabled).

This bug is really a request for a quick and efficient way to invoke
"soft-power off", with bug 3461 providing the GUI that allows the user to
configure precisely what "soft poweroff" actuallyy means as far as the device
is concerned.

Ultimately a UI could could allow the user to define what happens when the unit
enters and exists soft poweroff - radios on/off (with sub options to choose
which radios, just for ultimate flexibilty!); audio on/off; led on/off; etc. -
and this bug would provide the user with a quick and efficient method of
invoking "soft poweroff".

Comment 46 David Weinehall 2009-01-07 16:22:22 UTC

MCE has no means to decide what radios to disable and what radios to keep
alive; allowing for options that separate this would cause a big increase in
complexity.

Also, bluetooth is a potential powerdrain too, at least if bluetooth is to be
scanable.  All in all, while I can see some benefit to having the different
radios separately configurable, it's not feasible.

Also, I think that a configuration UI for this option should not be made a part
of the OS we ship on our devices, but rather a separate add-on easily
installable from extras.  That way there's no obligation for the UI-team to
provide tens of translations, pixel-precise specs and what-not Roope mentioned.

The only thing that is needed is either a soft poweroff option in the device
menu, or that the "double-click power button to soft poweroff" behaviour is
made configurable from the UI.

Comment 47 Quim Gil 2009-01-07 18:04:45 UTC

(In reply to comment #45)
> This bug is really a request for a quick and efficient way to invoke
> "soft-power off", with bug 3461 providing the GUI that allows the user to
> configure precisely what "soft poweroff" actuallyy means as far as the device
> is concerned.

Isn't there a way to combine "Lock screen & keys" + Wlan off + BT off, even if
it's not through MCE only? I believe this user case might be frequent. I find
myself doing this with Nokia devices with cellular connectivity (well, I leave
BT always on but I probably wouldn't mind aving it off too).

If soft poweroff means all the radios off then I really don't see Maemo 5 users
using this feature regularly and therefore needing to offer anything quicker
than the usual behavior on Nokia devices, having "Lock screen & keys" and
"Offline mode" separately.

Special users might have this special need for having "Lock screen & keys" +
"Offline mode" in one go, and even configure what exactly they want to shut
off. They might be willing to install special software from extras.

Comment 48 Neil MacLeod (reporter) 2009-01-07 18:47:45 UTC

(In reply to comment #46)
> MCE has no means to decide what radios to disable and what radios to keep
> alive; allowing for options that separate this would cause a big increase in
> complexity.
> Also, bluetooth is a potential powerdrain too, at least if bluetooth is to be
> scanable.  All in all, while I can see some benefit to having the different
> radios separately configurable, it's not feasible.

OK fair enough - all radios off suits me fine anyway!

> Also, I think that a configuration UI for this option should not be made a part
> of the OS we ship on our devices, but rather a separate add-on easily
> installable from extras.  That way there's no obligation for the UI-team to
> provide tens of translations, pixel-precise specs and what-not Roope mentioned.

I know where you're coming from, as official Nokia development clearly suffers
from a (necessary) burden that third-party apps do not.

> The only thing that is needed is either a soft poweroff option in the device
> menu, or that the "double-click power button to soft poweroff" behaviour is
> made configurable from the UI.

Personally I'm looking for a quick, efficient method of locking the device and
switching off the radios.

Where possible I want to avoid menus and additional clicks (either touchscreen
or hard buttons) - this is why Autolock-type functionality is quite compelling
(and really the closest thing to the 770 hard-cover, but without the
hard-cover!) as I only have to put the device in my pocket for it to lock,
unfortunately it doesn't disable the radios; being able to invoke soft-poweroff
from a double-click power button would also be preferable to a menu selection.

I'd really like to see Nokia add support for Autolock-type functionality, not
now as it's too late for Fremantle but at least consider it for Harmattan -
it's a very clever use of the ambient light sensor in my opinion.

Comment 49 Neil MacLeod (reporter) 2009-01-07 19:12:59 UTC

(In reply to comment #47)
> (In reply to comment #45)
> Isn't there a way to combine "Lock screen & keys" + Wlan off + BT off, even if
> it's not through MCE only? I believe this user case might be frequent. I find
> myself doing this with Nokia devices with cellular connectivity (well, I leave
> BT always on but I probably wouldn't mind aving it off too).

Seemingly not. Option is Soft Poweroff + Offline only, through MCE.

> If soft poweroff means all the radios off then I really don't see Maemo 5 users
> using this feature regularly and therefore needing to offer anything quicker
> than the usual behavior on Nokia devices, having "Lock screen & keys" and
> "Offline mode" separately.
> Special users might have this special need for having "Lock screen & keys" +
> "Offline mode" in one go, and even configure what exactly they want to shut
> off. They might be willing to install special software from extras. 

I understand what you're saying here, but in my case if I want to shut off the
radios I want them to stay shut off and not spark back into life unannounced
(not even to perform a scan, for example). Granted, other users may want the
option for them to connect as and when required.

Ultimately we now seem to discussing the same thing, which is a request for a
method to silence the device over and above the "normal" standby method. From
my perspective I want that method to be quick and efficient. 

Precisely what happens when the device is silenced - whether radios are left on
or switched off, either temporarily or permanently - can be left to a
third-party UI or, ideally, a Nokia supplied UI.

Comment 50 Neil MacLeod (reporter) 2009-01-07 19:21:46 UTC

(In reply to comment #48)
> being able to invoke soft-poweroff
> from a double-click power button would also be preferable to a menu selection.

I should have mentioned that on the N800 the power button is a tiny, stiff and
hard-to-press button (no doubt by design!) which is not ideal for
double-clicking or long-pressses, so if we were to consider adding double click
functionality to the power button in a future device the button should be made
easier to press, which adds obvious issues!

Personally I'd like to avoid the long-press method as I find this
annoying/frustrating, typically because I need to put the device into
standby/radios-off at short notice (as I'm entering a building etc.) and don't
want to hold the button even if it is for only a second or two - double-click
would a better option, with ambient-light sensor getting the gold-star! :)

Comment 51 Eero Tamminen 2009-01-07 19:29:09 UTC

> double-click would a better option, with ambient-light sensor getting the gold-star! :)

Your device locking up and loosing connections when you by accident cover the
ambient light sensor with your thumb (which happens very often for me) could be
pretty annoying (depending a bit how important that connection was).

Comment 52 Eero Tamminen 2009-01-07 19:34:36 UTC

Oh, and the action being on something else than the power button would probably
mean that button would be pretty useless e.g. in some games where you need to
press the buttons repeatedly.  Unless you're proposing that the programs would
have some way to disable it (like screen blanking), which I'm pretty sure would
be wontfix.

Comment 53 Neil MacLeod (reporter) 2009-01-07 20:03:45 UTC

(In reply to comment #51)
> > double-click would a better option, with ambient-light sensor getting the gold-star! :)
> Your device locking up and loosing connections when you by accident cover the
> ambient light sensor with your thumb (which happens very often for me) could be
> pretty annoying (depending a bit how important that connection was).

True, although I've learned to keep my fat thumb out of the way, and of course
a more sensibly located ambient light sensor on a future device wouldn't prove
to be so problematic!

Comment 54 Neil MacLeod (reporter) 2009-01-07 20:15:01 UTC

(In reply to comment #52)
> Oh, and the action being on something else than the power button would probably
> mean that button would be pretty useless e.g. in some games where you need to
> press the buttons repeatedly.  Unless you're proposing that the programs would
> have some way to disable it (like screen blanking), which I'm pretty sure would
> be wontfix.

I'm no longer suggesting the action should be on a button other than the power
button - true, that would have been my suggestion for the N800 but I accept
this device has come to the end of the road and I'm no longer going to waste my
time trying to get any improvements through for that device.

Instead I'm trying to focus on unannounced products here, where we might get
some traction implementing this enhancement. So on those future devices, if
we're going to have to double-click the power button please don't make the
power button so hard to press as is the case on the N800 (it's fair to say the
N810 has a power button that is easier to press than that on the N800).

Comment 55 David Weinehall 2009-01-08 02:35:57 UTC

I would like to suggest that people forget the idea to use the ALS for this
purpose; if the ALS is used as a trigger for locking (I'm taking it that you
all mean that it should lock when there's no surrounding light detected), the
device will be impossible to use in dark rooms...  Not exactly tempting, at
least not for me personally (I use my device in dark spaces very often, mainly
when travelling, but also when I'm awake in the middle of the night).

Also, when it comes to keys, the power button have a few advantages over other
keys:

1.) The power button is always located on the outside of the device (the select
button, for instance, moved from the front of the device on the 770 + n800 to
inside the slide in the n810) -- granted, it's not impossible to move the power
button inside a slide or behind a cover or what-not, but I have a hard time
envisioning a Nokia-device that would use such a solution.  Then again, who
knows...

2.) The power button is always guaranteed to be present (every device needs
some way to turn it on, while keyboards are product specific, as are various
other keys)

3.) The power button interrupt is not disabled with the rest of the keyboard
matrix (thus the the touchscreen and keypad interrupts can be disabled and thus
not causes unnecessary CPU-wakeups when the device is in your pocket, yet still
allow the device to wake from sleep when the power button is pressed)

4.) The power button has a natural, intuitive connection to powering off the
device; soft powering off the device with the same button seems reasonable


Personally, my take would be to simply default to soft poweroff being offline +
tklock + mute, and have a configuration option to disable/enable soft poweroff;
if enabled it will show up as an extra option in the device menu (the one that
shows up when the power button is pressed).

A separate configuration applet would provide the option to additionally map
soft poweroff to either long press or double press (optionally remapping the
normal shutdown in the process; while it might be considered as an unnecessary
mapping, it is good to have in cases where the UI freezes and the device needs
to be shut down), and to modify the various policies (offline vs not-offline,
mute vs non-mute).

But this is just my 2¢.  I don't make any calls when it comes to UI issues. 
The only thing I can do to at least simplify this somewhat is to turn the
configuration options for this in /etc/mce/mce.ini into GConf keys instead. 
That way any maemo developer will at least be able to hack up a nice
configuration applet (even if the functionality isn't provided by default, it
would at least be possible to achieve through a simple app install from
extras).

Comment 56 Neil MacLeod (reporter) 2009-01-08 02:51:50 UTC

(In reply to comment #55)
> I would like to suggest that people forget the idea to use the ALS for this
> purpose; if the ALS is used as a trigger for locking (I'm taking it that you
> all mean that it should lock when there's no surrounding light detected), the
> device will be impossible to use in dark rooms...  Not exactly tempting, at
> least not for me personally (I use my device in dark spaces very often, mainly
> when travelling, but also when I'm awake in the middle of the night).
> 

Autolock already has a solution for this - it doesn't activate when the
keyboard is open, and autolock can be temporarily disabled by flicking the
hold-switch. Your point is valid of course, but it could be "worked around" if
necessary.

Regarding your other points on the power button and how this bug could be
implemented, I entirely agree, 100%. Earlier today I was almost ready to chuck
the towel in on this bug - was having a of a mare of a day. Rather glad I
didn't! :)

Comment 57 Roope Rainisto 2009-01-08 08:33:42 UTC

as with comment #47. Having a setting of what a possible lock key would do
doesn't really make sense. Even those users that would occasionally want to
have touch screen lock + network off at the same time would still often want to
have only touch screen lock. Nobody would really use this setting and set this
key to do both, since then they would lose the capability to quickly lock only
the touch screen.

Comment 58 Neil MacLeod (reporter) 2009-01-08 10:17:12 UTC

(In reply to comment #57)
> as with comment #47. Having a setting of what a possible lock key would do
> doesn't really make sense. Even those users that would occasionally want to
> have touch screen lock + network off at the same time would still often want to
> have only touch screen lock. Nobody would really use this setting and set this
> key to do both, since then they would lose the capability to quickly lock only
> the touch screen. 
> 

Eh?

Are you talking about what might happen when the user presses double-click
power? As I understand it the device will do nothing - today - when
double-click power is pressed, as it's not a supported action. So in reality we
are asking for a new action, with the ability to bind a new (possible
configurable) function to that action. How is this going to cause a problem and
prevent the user from accessing existing functionality?

If the user wants to only lock their device they can press power button then
lock from the menu, or slide the lock key (if their device has a lock key). In
future if they want to enter a "soft poweroff" mode quickly, they can
double-click the power key (which may disable radios if the user has configured
that option).

Nobody is suggesting users would lose existing functionality.

Comment 59 Roope Rainisto 2009-01-08 10:21:14 UTC

to comment #58: no, I was talking about what a possible lock key would do.
Hence the sentence "Having a setting of what a possible lock key would do". 

Discussing behaviours for the power key is problematic, since the power key is
one aspect of Nokia UI's which is rather heavily influenced by the other
devices in the portfolio. (Read: "Even if we would want to do something for it,
getting these changes approved by other parts of the organization would be
hard.")

Comment 60 Eero Tamminen 2009-01-08 10:31:10 UTC

> (In reply to comment #52)
> that would have been my suggestion for the N800 but I accept this device
> has come to the end of the road and I'm no longer going to waste my
> time trying to get any improvements through for that device.

I think what still could be done for them is petitioning opening of some of the
old SW closed components for which Nokia doesn't have strong reasons not to
open, which aren't anymore in Fremantle and which weren't opened because nobody
had had time to do it (finding the sources & developer to still take the last
responsibility for the component, adding appropriate copyrights & licenses
everywhere + fixing other potential issues related to opening, pushing it
through the bureacracy).  This would require community finding somebody who
would be willing to maintain the given component (and wait until the sources
come out from Nokia, usually the publishing thing has taken couple of months)
and some kind of plan what community would (want) to do for it.

(Maybe FM-radio?)


(In reply to comment #55)
> A separate configuration applet would provide the option to additionally map
> soft poweroff to either long press or double press (optionally remapping the
> normal shutdown in the process; while it might be considered as an unnecessary
> mapping, it is good to have in cases where the UI freezes and the device needs
> to be shut down)

Indeed.  Real device power-off needs to be something that can be always done
through the power button without any user-interaction[1].  Any 3rd party X
client can grab (normal) keys or pointer or even the whole X server and then
"forget" to release the grab (easiest way: app goes to infinite loop when it
has a combobox popup or menu open because it does things that it shouldn't do
in that kind of a situation, that problem happens also Linux desktop).

[1] The thing that the power menu can be invoked even when app has grabbed user
input is a great way to debug "freeze" issues users/testers have.  -> If power
menu opens, "device freeze" is application bug.

Comment 61 Neil MacLeod (reporter) 2009-01-08 10:56:35 UTC

(In reply to comment #59)
> to comment #58: no, I was talking about what a possible lock key would do.
> Hence the sentence "Having a setting of what a possible lock key would do". 
> 

OK, well we seem to be zeroing in on the power button as the possible driver
for any future enhancement and not the lock key which will remain unchanged
mainly because it's not common on all devices, for a start. At least by using
the power button this functionality is broadly compatible with all devices,
past, present and even future.

> Discussing behaviours for the power key is problematic, since the power key is
> one aspect of Nokia UI's which is rather heavily influenced by the other
> devices in the portfolio. (Read: "Even if we would want to do something for it,
> getting these changes approved by other parts of the organization would be
> hard.")
> 

Why doesn't this surprise me? :(


So to recap, the power button might have three actions in future:

Single click: Show Power Menu
Double click [New]: Soft-poweroff (user configurable, via a Control Panel GUI
of some sort)
Long press: Power off

Other than organizational issues, is there anything else to add? Based on
various comments in this bug, there appears to be a valid requirement for
quick-access to a configurable soft-poweroff.

Comment 62 Quim Gil 2009-01-08 15:32:36 UTC

Ok, so you really mean "Quick softpoweroff mode", where softpoweroff defaults
to locked input + 100% offline. This is more strict than lock + wlan off, hence
changing summary.

This also helps focusing the discussion. I don't see users of devices with
Maemo 5 or higher versions seeing this feature as an extension of locking
(something to do when putting the device in your pocket) but as an interesting
implementation next to power off (something to do accasionally).

This was not the case of the 770 referred in this request and the N8*0 you base
your use cases upon. The arrival of a cellular radio changes the game though,
at least for the majority of users. Really, we don't expect those users willing
to disconnect all radios frequently. Maybe all but the cellular radio would be
a more popular use case, but according to David this would not be trivial to
implement.

But supporting softpoweroff as an alternative/complement to the real power-off?
Yes, that's interesting. We expect Maemo users to have their devices always
on,and if they go off we assume it's not for a long period: some hours, a
couple of days, something a device could resist without recharging. This would
offer a faster ON keeping sessions and what not. Something users would
appreciate.

The implementation could be:

- Offer softpoweroff as default mode for switching off. Could also be called
"Sleep mode", "Hibernation" or perhaps keep the "Switch off".

- Switch definitely off either when reaching the time limit defined by the user
(default 5 days or so?) or 20% of battery power (to make sure in the worst case
your device is always useful for some hours more).

- Activation of softpoweroff would be made through the current poweroffmethod
e.g. one long press to power button. Note that "2 clicks" or more in S60 lead
you to browse the options of the power menu, which makes sense from a usability
point of view. I have no idea about the Maemo UI plans but that makes sense
since the user only has to keep pressing the same button to select the desired
power menu option.

- Users could still go directly to total poweroff through the power menu.

- No matter if soft or hard poweroff, the way to activate the devices is a long
press tothe power button (David's resolution on Bug 2290 makes sense).

Comment 63 Neil MacLeod (reporter) 2009-01-08 17:38:39 UTC

(In reply to comment #62)
> (something to do when putting the device in your pocket) but as an interesting
> implementation next to power off (something to do accasionally).

I guess it depends on where you work - "occasionally" will typically be at
least once a day (and most likely more often) should you work in an environment
where WiFi devices are discouraged/unwelcome.

For the majority of users it *will* be occasional usage; for a minority of
users it will be frequent usage.

> This was not the case of the 770 referred in this request and the N8*0 you base
> your use cases upon.

Not sure exactly what you saying is now not the case, but as I recall once the
770 hard-cover was put in place the wireless/BT was automatically shut down,
and the 770 would not reactivate wireless/BT until the hard-cover had been
removed, thus the 770 was essentially "offline". This appearance of "offline"
state could have been because OS2005/OS2006 on the 770 wasn't so keen to
automatically reconnect to available wireless sources as OS2007/OS2008 now is,
so while it wasn't true offline mode on the 770 it certainly gave that
appearance.

I'd like the same now, on current and/or future hardware - when the device is
put into "soft poweroff" mode I want the ability to also disable WiFi/BT and
not have it automatically scan and re-establish connections until the device is
brought back out of "soft poweroff" mode. If simply terminating WiFi/BT
connections upon entering "soft poweroff" means these connections could
automatically reconnect later on then I would like full offline mode to be
implemented with "soft-poweroff" rather than simply terminating the WiFi/BT
connections.

Then again, David seems to suggest this all might be configurable (connection
termination or offline mode) in which case we could have both... :)

> The arrival of a cellular radio changes the game though,
> at least for the majority of users. Really, we don't expect those users willing
> to disconnect all radios frequently. Maybe all but the cellular radio would be
> a more popular use case, but according to David this would not be trivial to
> implement.

If I'm willing to disconnect WiFi or BT, chances are I'm willing to disconnect
cellular too. Not really sure that the addition of cellular changes the game at
all, to be honest (although I could, and probably am, missing the point!)

> - No matter if soft or hard poweroff, the way to activate the devices is a long
> press tothe power button (David's resolution on Bug 2290 makes sense).

That's a shame, it's not really what I would call "quick and efficient" - quite
the opposite in fact. Sure it gives access to "soft-poweroff" (of one sort or
another - with/without radios on/off etc.) which is better than we have now,
but I really had hoped we could avoid the long press as it's not what I
consider "quick".

As such, I'm out of this bug. Implement soft-poweroff however you like as I'm
sure it will be better than what we have now, but it won't satisfy me so I'll
say no more.

Comment 64 Neil MacLeod (reporter) 2009-01-08 17:53:24 UTC

(In reply to comment #62)
> - Activation of softpoweroff would be made through the current poweroffmethod
> e.g. one long press to power button. Note that "2 clicks" or more in S60 lead
> you to browse the options of the power menu, which makes sense from a usability
> point of view. I have no idea about the Maemo UI plans but that makes sense
> since the user only has to keep pressing the same button to select the desired
> power menu option.

Blast! The above statement is the part I intended to quote with my last two
paras in comment 63!

Bringing the device out of "soft-poweroff" with a long press isn't so bad, but
having to wait even 1-2 seconds to put it into "soft-poweroff" doesn't appeal.
At all.

Comment 65 David Weinehall 2009-01-08 18:15:55 UTC

I know that keeping on pressing the powerbutton steps down through the S60
menus, but we've never used that interface in our device, also our menu has by
tradition had non-wrapping menus, while the s60 menus wrap around when stepping
past the top/bottom (which I, btw, definitely prefer, especially for long
menus).

And since we deviate from S60 in so many other things anyway (such as actually
having menus that are easy to navigate, themes that look good, wifi setup that
works, etc), I don't see why we should copy them in this case...

Comment 66 Neil MacLeod (reporter) 2009-01-08 18:32:54 UTC

(In reply to comment #65)
> I know that keeping on pressing the powerbutton steps down through the S60
> menus, but we've never used that interface in our device, also our menu has by
> tradition had non-wrapping menus, while the s60 menus wrap around when stepping
> past the top/bottom (which I, btw, definitely prefer, especially for long
> menus).
> And since we deviate from S60 in so many other things anyway (such as actually
> having menus that are easy to navigate, themes that look good, wifi setup that
> works, etc), I don't see why we should copy them in this case...

Glad I'm not the only one thinking this is a silly idea, but the post from Quim
seemed to be so conclusive I'd given up! :)

S60 isn't touchscreen based (ignoring Tube/5800 phones etc.) so repeatedly
pressing the power button DOES make some sense, but the reality is it's not a
great advantage as the power button is often small and difficult to press on
S60 devices (which deters from repeated depressions) so it's actually easier to
switch to the d-pad once the power menu is visible (this is based on my
experience of S60 on N85).

Since the Nokia tablets are touchscreen devices, why would anyone want to keep
pressing a relatively small button to cycle through menu options when it should
be easier to select an option directly from a finger-friendly power menu
instead?

Blindly implementing S60 non-touchscreen features and practices on touchscreen
tablets seems a bad idea, particularly if pointless S60 functionality takes
precedence over user requested features.

Damn, and I was so out of this bug... :)

Comment 67 Quim Gil 2009-01-08 19:31:25 UTC

sure, double press then. 

No need to leave and come back. I'm just trying to figure out a sensible
proposal for the UI team and product management.

Comment 68 Andre Klapper 2009-09-25 14:46:09 UTC

(In reply to comment #1)
> From Internet Tablet Talk forum:
> http://maemo.org/pipermail/maemo-users/2007-January/002690.html
> 
> "Oh, you can, check /etc/systemui/systemui.xml and uncomment 'Soft 
> poweroff'. There is also nice 'Reboot' option, useful if you regulary 
> reboot to different rootfs with boot menu."

This is still exactly the case for Fremantle. Removing the comment lines will
provide options like "Soft poweroff" in the Fremantle UI.

Comment 69 David Weinehall 2009-11-18 18:39:20 UTC

Also, while the double click action is nowadays by default used to activate
tklock, it can still be reconfigured to activate soft poweroff instead.

The power button on the N900 protodes from the device (thus the argument about
how the old N800 button was hard to press is moot), there's support for
switching to offline when entering soft poweroff AND there's support for
enabling it on double click of the power button.

Is this enough to resolve this, or do we have to drag this bug on yet longer?

Comment 70 Neil MacLeod (reporter) 2009-11-18 19:00:05 UTC

(In reply to comment #69)
>
> Is this enough to resolve this, or do we have to drag this bug on yet longer?
> 

I think we'll need to drag it on a bit longer until I can confirm this with a
real device. ETA is a bit of a moving target, hopefully I'll have a more
positive reply sometime later this month. :)

Comment 71 Andre Klapper 2009-12-01 17:58:18 UTC

Also see bug 6415 about a "Reboot" option.

Comment 72 Neil MacLeod (reporter) 2009-12-30 16:27:12 UTC

(In reply to comment #69)
> 
> Is this enough to resolve this, or do we have to drag this bug on yet longer?
> 

Yep close it. I no longer work in a Wifi hostile environment so the
double-click to lock is good enough for me. Not sure why double click couldn't
have been used to unlock as well.

I also think Nokia missed a trick by not utilising the ambient light sensor to
assist with locking/unlocking - maybe the community can help resolve that. :)

Comment 73 Andre Klapper 2010-01-06 16:07:01 UTC

(In reply to comment #72)
> Yep close it.