Bug 287228 - onMeeGo: while the device is plugedIn, the battery symbol vanishes, so that options like sleep cannot be activated
Summary: onMeeGo: while the device is plugedIn, the battery symbol vanishes, so that o...
Status: RESOLVED INTENTIONAL
Alias: None
Product: Active
Classification: Plasma
Component: Top Bar (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: unscheduled
Assignee: active
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-22 08:57 UTC by Fania Bremmer
Modified: 2011-12-14 23:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fania Bremmer 2011-11-22 08:57:41 UTC
Version:           unspecified (using Devel) 
OS:                Linux

onMeeGo: 
- while the device  (weTab) is plugedIn, the battery symbol in the top bar vanishes, so that options like sleep/hibernate/performance etc cannot be activated

Reproducible: Always

Steps to Reproduce:
- deplug your wetab from electricity, see the battery symbol
- touch on the battery symbol, see other options like hibernate/Sleep
- plug it to electricity, see the battery icon and therefore its options vanish

Actual Results:  
- no options anymore

Expected Results:  
- have the options like sleep and low performance every time

- as we currently are working on optimizing the whole sleep, hibernate mode etc on MeeGo, we can keep this bug until we decided for a final solution
Comment 1 Javier Llorente 2011-11-22 10:00:51 UTC
AFAIK, this is the default behaviour of KDE starting with 4.7.0. If the battery is fully charged and the charger is connected, no battery icon is shown on the system tray.
Comment 2 Aaron J. Seigo 2011-11-22 10:18:52 UTC
that is correct; only when it is 100% and plugged into main power. the idea is to limit the amount of information that is shown to the user, and in this case "you're plugged in, you're fully charged, you may as well be using a desktop computer at this point ;)" is implied. on the desktop, however, you can show hidden icons, something plasma-device doesn't provide for, so there you can still get to it.

the easy thing is to just unpug the power cord and it will reappear. we can discuss if this behaviour should remain, but i would like it to be consistent across all plasma workspaces.
Comment 3 Thomas Pfeiffer 2011-11-22 10:33:34 UTC
In my opinion, the problem is not that the icon is hidden, as it does not show relevant information. The problem is that this is currently the only visible way for the user to put the device to sleep or hibernate it in plasma-device. This is inconsistent with plasma-desktop, where you still have the leave-button.
So we should either be fully consistent and add some way to manually go to hibernate or sleep (and I'd even say all other leave options, even if only advanced users use them), or be fully inconsistent and always show the icon.
I'd clearly vote for consistency, since I'm not sure if users actually expect sleep and hibernate on the battery icon (which looks more like an information than an interaction icon).
Comment 4 Fania Bremmer 2011-11-22 10:46:13 UTC
Thanks for your feedback.

For MeeGo we are currently thinking about other ways to activate the sleep, lock screen etc., as I think as well that the battery icon is not the best approach.
My first ideas are scribbled in those two wireframes:
http://share.basyskom.com/contour/UIDesign/Locking_Hibernate_V2.jpg
http://share.basyskom.com/contour/UIDesign/Locking_Hibernate.jpg

Interactions would be:
- short press on hw power button: automatic locked screen, every app still running, no energy saving
- long press on hw power button: hard shut down (we have that currently), maybe data loss
- short tab on power icon in Plasma Active GUI (see wireframe Locking_Hibernate.jpg, icon on the left upper corner) brings up an overlay with the following options:
    - Lock: Brings Lock Screen up, system doesnt react on touch anymore, apps are still running (so user can still listen to music for example)
    - Sleep: Aggressive powermode, minimal energy consumption, short wake up time (under 3s)
    - Turn off: shuts the device down, but asks for open dialogs, save dialogs etc, without data loss

- I was also thinking about other options, see Locking_Hibernate_V2.jpg with sleep, restart and turnoff; but in my opinion restart is only a needed option for testers and developers, not for endusers

Whats your feedback?
Comment 5 Fania Bremmer 2011-11-22 10:52:41 UTC
Another comment on this:
>>the idea is to limit the amount of information that is shown to the user

In my opinion its not a benefit to dynamically show and vanish important icons in the top bar. The battery status is an important information, and even if I am plugedIn I still want to know and be safe: yep, its on 100%.

I can understand for icons like "devices or usb plugedIn" to vanish, if the state changed. But battery is a quite important information, no? But I am more the "play it safe kind of user", so might be that...
Comment 6 Lamarque V. Souza 2011-11-22 11:19:38 UTC
I am also of the oppinion that the battery icon should always be visible if there is a battery present. Usually when things disappear it means it has disappeared :-) The user may think there is problem in the battery icon or in the battery itself if the icon comes and goes. At least until he/she realises the icon disappears only when the battery is fully charged.

At least KDE users expect the Sleep and Hibernate options on the battery plasmoid, it has been there for years. Ok, newcomers do not know that.
Comment 7 Thomas Pfeiffer 2011-11-22 11:29:00 UTC
(In reply to comment #6)
> I am also of the oppinion that the battery icon should always be visible if
> there is a battery present. Usually when things disappear it means it has
> disappeared :-) The user may think there is problem in the battery icon or in
> the battery itself if the icon comes and goes. At least until he/she realises
> the icon disappears only when the battery is fully charged.

Hm... on the other hand, many icons only appear if something _happens_. So one could say "The icon is displayed as long as the battery charges or dischagres", which it does not do when it's full.
But you and Fania do have a point I guess, and most if not all OSes - desktop an mobile - I know keep the icon displayed even when the battery is full.


> At least KDE users expect the Sleep and Hibernate options on the battery
> plasmoid, it has been there for years. Ok, newcomers do not know that.

They might expect it, but do they _look_ for it there? I for example have never hibernated my laptop or put it so sleep from the battery icon, as I have a dedicated button for that. So okay, long time KDE users will eventually remember that possibility after unsuccessfully looking for a leave button, but I don't think it's the first place even they will look for it.
Comment 8 Thomas Pfeiffer 2011-11-22 11:41:20 UTC
> My first ideas are scribbled in those two wireframes:
> http://share.basyskom.com/contour/UIDesign/Locking_Hibernate_V2.jpg
> http://share.basyskom.com/contour/UIDesign/Locking_Hibernate.jpg

Well that's pretty much like the traditional shutdown plasmoid with PA look & feel, isn't it?
( http://ubuntu.paslah.com/wp-content/uploads/2011/08/The-desktop-menu-Leave.png )
 
> Interactions would be:
> - short press on hw power button: automatic locked screen, every app still
> running, no energy saving

Makes sense to me, as you often want to quickly lock the screen because you need to carry the device around for a few meters.

> - long press on hw power button: hard shut down (we have that currently), maybe
> data loss

That's a hardware function anyway, correct?

> - short tab on power icon in Plasma Active GUI (see wireframe
> Locking_Hibernate.jpg, icon on the left upper corner) brings up an overlay with
> the following options:
>     - Lock: Brings Lock Screen up, system doesnt react on touch anymore, apps
> are still running (so user can still listen to music for example)
>     - Sleep: Aggressive powermode, minimal energy consumption, short wake up
> time (under 3s)
>     - Turn off: shuts the device down, but asks for open dialogs, save dialogs
> etc, without data loss

What about hibernate? It has the advantage of no data loss and faster boot-up time. The advantage of shutdown though is that if allows for a "clean start".

> - I was also thinking about other options, see Locking_Hibernate_V2.jpg with
> sleep, restart and turnoff; but in my opinion restart is only a needed option
> for testers and developers, not for endusers

In a perfect world, that's true. But I don't think we can expect there won't be bugs that affect the system so badly that even end users will want to reboot their device. This may be a little more hidden than the other options since it is only for cases of "emergency", but I'm not convinced that no end user will ever need it.
Comment 9 Lamarque V. Souza 2011-11-22 12:21:06 UTC
(In reply to comment #7)
> Hm... on the other hand, many icons only appear if something _happens_. So one
> could say "The icon is displayed as long as the battery charges or
> dischagres", which it does not do when it's full.

I think we could change the icon to indicate the battery is fully charged. Some OS even write
the word "Charged" beside the battery icon.

> But you and Fania do have a point I guess, and most if not all OSes - desktop
> an mobile - I know keep the icon displayed even when the battery is full.

That is what I had thought.

> They might expect it, but do they _look_ for it there? I for example have never
> hibernated my laptop or put it so sleep from the battery icon, as I have a
> dedicated button for that. So okay, long time KDE users will eventually
> remember that possibility after unsuccessfully looking for a leave button, but
> I don't think it's the first place even they will look for it.

Fania and me are working with tablet devices. They usually do not have
dedicated sleep/hibernate buttons. The only button we have is the power button
and as Fania wrote we plan to use it for "screen lock"/"hard shutdown", we need
an alternative for sleep/hibernate/shutdown.

Plasma-device (in plasma-mobile) does not have a main menu button like plasma-desktop. If it had
we could add the "sleep/hibernate/shutdown" there like Kickoff and Lancelot do. But I have the feeling that
whoever decided not to add a menu button has reasons for that.

(In reply to comment #8)
> > My first ideas are scribbled in those two wireframes:
> > http://share.basyskom.com/contour/UIDesign/Locking_Hibernate_V2.jpg
> > http://share.basyskom.com/contour/UIDesign/Locking_Hibernate.jpg
> 
> Well that's pretty much like the traditional shutdown plasmoid with PA look &
> feel, isn't it?
> (
> http://ubuntu.paslah.com/wp-content/uploads/2011/08/The-desktop-menu-Leave.png
> )

	Not exactly a plasmoid, it is a plasmified menu. They are similar and share the same porpose.
We would need to remove the shutdown context menu and increase the menu item's
height to use it in tablets though.
Some days ago Marco Martin also mentioned making the menu themable using QML.
That can take some time though.
 
> > Interactions would be:
> > - short press on hw power button: automatic locked screen, every app still
> > running, no energy saving
> 
> Makes sense to me, as you often want to quickly lock the screen because you
> need to carry the device around for a few meters.

	Although suspending to ram (sleep) is more recomended  in that situation than simply locking the
screen if your device uses rotational media (traditional hard disk, DVD
reader). The lock screen is usefull when you want to leave the computer turned
on and go somewhere without it.
 
> > - long press on hw power button: hard shut down (we have that currently), maybe
> > data loss
> 
> That's a hardware function anyway, correct?

	Yes.
 
> What about hibernate? It has the advantage of no data loss and faster boot-up
> time. The advantage of shutdown though is that if allows for a "clean start".

	It can be added easily. I implementated the first version of that dialog.
 
> In a perfect world, that's true. But I don't think we can expect there won't be
> bugs that affect the system so badly that even end users will want to reboot
> their device. This may be a little more hidden than the other options since it
> is only for cases of "emergency", but I'm not convinced that no end user will
> ever need it.

There is always the "shutdown and then turn on" alternative. If the system is
so badly affected then the only alternative is the hard shutdown anyway (long power
button press). Most users are used
to do that with devices such as TV sets, DVD players, even phones usually do not
have a restart option.
Comment 10 Sebastian Kügler 2011-11-22 15:29:35 UTC
Hey,

On Tuesday, November 22, 2011 13:21:06 Lamarque V. Souza wrote:
> https://bugs.kde.org/show_bug.cgi?id=287228
> 
> 
> 
> 
> 
> --- Comment #9 from Lamarque V. Souza <lamarque kde org>  2011-11-22
> 12:21:06 --- (In reply to comment #7)
> 
> > Hm... on the other hand, many icons only appear if something _happens_.
> > So one could say "The icon is displayed as long as the battery charges
> > or dischagres", which it does not do when it's full.
> 
> I think we could change the icon to indicate the battery is fully charged.
> Some OS even write
> the word "Charged" beside the battery icon.
> 
> > But you and Fania do have a point I guess, and most if not all OSes -
> > desktop an mobile - I know keep the icon displayed even when the battery
> > is full.
> 
> That is what I had thought.
> 
> > They might expect it, but do they _look_ for it there? I for example have
> > never hibernated my laptop or put it so sleep from the battery icon, as
> > I have a dedicated button for that. So okay, long time KDE users will
> > eventually remember that possibility after unsuccessfully looking for a
> > leave button, but I don't think it's the first place even they will look
> > for it.
> 
> Fania and me are working with tablet devices. They usually do not have
> dedicated sleep/hibernate buttons. The only button we have is the power
> button and as Fania wrote we plan to use it for "screen lock"/"hard
> shutdown", we need an alternative for sleep/hibernate/shutdown.
> 
> Plasma-device (in plasma-mobile) does not have a main menu button like
> plasma-desktop. If it had
> we could add the "sleep/hibernate/shutdown" there like Kickoff and Lancelot
> do. But I have the feeling that
> whoever decided not to add a menu button has reasons for that.
> 
> (In reply to comment #8)
> 
> > > My first ideas are scribbled in those two wireframes:
> > > http://share.basyskom.com/contour/UIDesign/Locking_Hibernate_V2.jpg
> > > http://share.basyskom.com/contour/UIDesign/Locking_Hibernate.jpg

Looks pretty sensible.

I wonder if it's justified to add powerbutton chrome to the panel though. 
Right now we combine that with the battery display and cross fingers that the 
user either finds the battery (if it's there at all), or find the physical 
powerbutton, which I've wired to suspend (doesn't seem to work for everybody).

The problem of course with hiding the battery when fully charged (which I 
think makes sense at least on a desktop, but feels a bit uncommon on a mobile 
device) is that we bastardize it to not be just informational, but also 
provide access to settings and suspend actions.

On the desktop, the battery icon can still be shown even if hidden, but that 
option isn't available in PA's system tray (neither by settings UI, nor by 
this little arrow that makes it show).

> > Well that's pretty much like the traditional shutdown plasmoid with PA
> > look & feel, isn't it?
> > (
> > http://ubuntu.paslah.com/wp-content/uploads/2011/08/The-desktop-menu-Leav
> > e.png )

Similar, but the feel should really be different, the lock/logout dialog just 
doesn't feel very touch-friendly.

>     Not exactly a plasmoid, it is a plasmified menu. They are similar and
> share the same porpose.
> We would need to remove the shutdown context menu and increase the menu
> item's height to use it in tablets though.
> Some days ago Marco Martin also mentioned making the menu themable using
> QML. That can take some time though.

Should actually be really easy, the powerbutton plasmoid already does this, in 
order to make it harder to tamper with it, it would be enough if it's just a 
very thin wrapper about a QDeclarativeView which loads a QML package and makes 
available some methods to the scriptengine's context.

> > What about hibernate? It has the advantage of no data loss and faster
> > boot-up time. The advantage of shutdown though is that if allows for a
> > "clean start".
> 
>     It can be added easily. I implementated the first version of that
> dialog.

Hibernate requires swap, which mobile devices usually don't have.

Nice work, overall.

Cheers,
Comment 11 Thomas Pfeiffer 2011-11-22 16:19:33 UTC
> I wonder if it's justified to add powerbutton chrome to the panel though. 
> Right now we combine that with the battery display and cross fingers that the 
> user either finds the battery (if it's there at all), or find the physical 
> powerbutton, which I've wired to suspend (doesn't seem to work for everybody).
> 
> The problem of course with hiding the battery when fully charged (which I 
> think makes sense at least on a desktop, but feels a bit uncommon on a mobile 
> device) is that we bastardize it to not be just informational, but also 
> provide access to settings and suspend actions.
> 
> On the desktop, the battery icon can still be shown even if hidden, but that 
> option isn't available in PA's system tray (neither by settings UI, nor by 
> this little arrow that makes it show).

+1, that's why I'd vote for a separate button (different icon than the big red power button, of course ;)

> > > Well that's pretty much like the traditional shutdown plasmoid with PA
> > > look & feel, isn't it?
> > > (
> > > http://ubuntu.paslah.com/wp-content/uploads/2011/08/The-desktop-menu-Leav
> > > e.png )
> 
> Similar, but the feel should really be different, the lock/logout dialog just 
> doesn't feel very touch-friendly.

Yes, sure. These mockups look touch-friendly enough for me, though. Big buttons with enough space between them, no combo buttons, nice.
 
> Hibernate requires swap, which mobile devices usually don't have.

Oh, I didn't know that. What does the hibernate button currently in the battery icon menu do, then?

> Nice work, overall.

Agreed. Much better suited for a tablet than the menu dropping form the battery icon
Comment 12 Aaron J. Seigo 2011-11-22 16:27:54 UTC
this is becoming quite the laundry list of topics :)

power button panel -> it still feels just so completely wrong up there. a hardware button is really what should be used here. there should no need for more chrome on the screen.

lock vs sleep -> the tablet should come out of sleep in 1-2 secons maximum; which makes always sleeping just fine. that resolves one more set of choices the user needs to make and also eliminates the "i thought it was sleeping, but it was just locked, and my battery drained" possibility

battery hiding -> yes, the "it's doing something, so it's shown" concept is exactly what i had in mind. if it isn't charging or discharging, it's not necessary information. on the desktop, there's a lot of competing visuals to grapple with otherwise. 

battery consistency -> and i'd like to see us keep this consistent across plasma targets. keeping behaviour the same means less special coding in widgets for specific use cases and allows people to become familiar with the plasma ways across their devices.

battery UI -> the popup UI from the battery that lets one get to hibernate/sleep is superfluous. what concerns me more is the screen brightness adjustment, though that probably isn't often an issue when plugged in.

honestly, i find the whole concept of using the battery to sleep to be highly broken.

as for the mockups on the exit screens, they look reasonable and could be implemented in ksmserver. what is there right now isn't amazing, even on the desktop, and a referesh of that would be nice to see. something more modern and that isn't the size of a postage stamp ;)
Comment 13 Lamarque V. Souza 2011-11-22 18:21:14 UTC
(In reply to comment #11)
> > Hibernate requires swap, which mobile devices usually don't have.
> 
> Oh, I didn't know that. What does the hibernate button currently in the battery
> icon menu do, then?

	ksmserver queries org.freedesktop.PowerManagement to detect if the device
is capable of hibernating, sleeping, etc. Teoretically if the menu is there
is because the device is capable of hibernating. However, I am not sure if
org.freedesktop.PowerManagement is trustworthy since in my MeeGo image running
inside VirtualBox upower says the device is not capable of sleeping but
org.freedesktop.PowerManagement says it is. Sleep does not work, so upower is
right here. But hibernating works if I add the kernel parameter
resume=<swap partition> yet upower says it should not. So it is little fuzzy here :-/
 
(In reply to comment #12)
> lock vs sleep -> the tablet should come out of sleep in 1-2 secons maximum;
> which makes always sleeping just fine. that resolves one more set of choices
> the user needs to make and also eliminates the "i thought it was sleeping, but
> it was just locked, and my battery drained" possibility

	The main reason for locking the screen is to prevent taps on it when
carrying the device inside a pocket or bag. In some cases the user would like to
have the device running when carrying it, that is the cell phone case for instance.

> battery hiding -> yes, the "it's doing something, so it's shown" concept is
> exactly what i had in mind. if it isn't charging or discharging, it's not
> necessary information. on the desktop, there's a lot of competing visuals to
> grapple with otherwise. 

	Be prepared for people complaining about hiding the battery icon, specially
 on mobile devices. People are not used to that and all other devices do not do
it. What bothers me about hiding it is the fact that we will have to change icon's
positions to accomodate it and I do not like icons coming and going, it draws
attention. Think of you doing something (typing an e-mail), you are
concentrated and then the battery gets fully charged and the icon
disppears. You will notice something changed in the system tray and will look
at it to figure out what changed.

> battery consistency -> and i'd like to see us keep this consistent across
> plasma targets. keeping behaviour the same means less special coding in widgets
> for specific use cases and allows people to become familiar with the plasma
> ways across their devices.

	Agreed.
 
> as for the mockups on the exit screens, they look reasonable and could be
> implemented in ksmserver. what is there right now isn't amazing, even on the
> desktop, and a referesh of that would be nice to see. something more modern and
> that isn't the size of a postage stamp ;)

I will try to come up with something before the weekend. I am still learning
QML, so I cannot guarantee it will be in QML.
Comment 14 Lamarque V. Souza 2011-12-01 13:19:48 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > as for the mockups on the exit screens, they look reasonable and could be
> > implemented in ksmserver. what is there right now isn't amazing, even on the
> > desktop, and a referesh of that would be nice to see. something more modern and
> > that isn't the size of a postage stamp ;)
> 
> I will try to come up with something before the weekend. I am still learning
> QML, so I cannot guarantee it will be in QML.

For those interested I pushed the new QML shutdowndlg to branch ksmserver/qml-shutdowndlg in kde-workspace repository. There are two themes, one called contour.qml for Plasma Active and another called plasma_desktop.qml to replace the current shutdowndlg.

I tried to mimic current shutdowndlg's look and feel in plasma_desktop.qml, with no complete success. Some features still missing: shutdown button's popup menu, icon on button's right side instead of left side, glowing background effect and text aligned to the right on buttons, SVG borders from dialog/shutdowndialog.svgz not appearing and some resizing issues.

For the buttons's popup menu I replaced it with a context menu, which is the most similar I could find. The Button component does not support the icon property, so no icon on buttons for now. For the other missing features from the Button component we will need to implement them or just drop them.

PS: Ksmserver implements its own KSMPushButton class to support those features.
Comment 15 Lamarque V. Souza 2011-12-14 23:33:39 UTC
We can close this bug since we agree in using the hardware power button to show the shutdown dialog in PA 3. In PA 2 we will use PowerButton plasmoid on the panel for that.