Battery Improvements in KDE Plasma 4.4

The battery applet in KDE Plasma 4.4 has gotten some nice improvements. First of all, I wasn’t really happy with the layout of its popup dialog. It looked messy and didn’t scale well with bigger fonts. During Tokamak3 in September, I started improving this. To make it look calmer, I reduced the amount of edges widgets are aligned to. The previous version used nested layouts, which lead to widgets not properly aligned with each other. This creates a rather messy look. For 4.4, I’ve reworked the layout and reduced everything to only one layout and attached the battery in the popup off-layout in the top-right corner. I thought about using an AnchorLayout for this, but a simple setGeometry() to position the battery top-right would work as well, so I went for KISS. I also replaced the text on the "Configure Power Management" button with a tooltip, reducing visual clutter but keeping this handy in-context shortcut to easily get at the more advanced power managment settings.

The battery popup now resembles a FormLayout more closely, which should make it more consistent with how other dialogs in KDE are designed, so that’s a bonus in consistency. The two screenshots show the old and the new version of the applet side-by-side.

One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup.
Lately, the same discussion came up again, hopefully for the last time, since I submitted a patch yesterday night that brings the remaining time back (still as hidden config option, and that’s about as far as we will go). No, there won’t be a checkbox since I don’t want to confront users with information that’s most likely bogus and highly depends on what you’re doing at this very moment. As the option needs a power user to understand what this info really means (i.e. an estimation that’s completely off or not, depending on what your BIOS or ACPI subsystem reports), I think we can reasonable expect that adding a line to a config file is easy enough for those who really, really, really want it.

So, for reference, here’s how you get the remaining time display in the battery applet.

  • Install KDE Plasma 4.4, at least trunk from today
  • kquitapp plasma-desktop (to stop your plasma shell, as long as it’s running, it can’t pick up config changes, if you stop it after you changed the config file, it will happily overwrite your hand-made changes on quit)
  • Open your plasma-desktop config file, (mine is ~/.kde4/share/config/plasma-desktop-appletsrc, YMMV)
  • Locate the section for the battery applet, in the below example, you’ll find the plugin=battery line, choose the section that adds [Configuration] to the identifier. This section might not exist if you’re using default settings, in that case, it’s easiest to check the “show charge information” checkbox in the battery’s config (you might need to restart plasma-desktop for that, don’t kill it afterwards but use kquitapp). Then locate the showBatteryString= line and add another line in the same section:
    showRemainingTime=true
  • Save the edited config file, restart plasma-desktop
[Containments][3][Applets][7][Configuration][Applets][30]
geometry=140,2.5,30,24
immutability=1
plugin=battery
zvalue=0

[Containments][3][Applets][7][Configuration][Applets][30][Configuration]
Share=false
showBatteryString=false
showRemainingTime=true

The remaining time will now be shown if it’s non-zero (obviously bogus since the machine would be off then) and the battery is discharging. If in doubt, use “plasmaengineexplorer –engine powermanagement” to check wether Solid reports the remaining time at all, and that it’s non-zero. The remaining time could also be shown while charging, but this apparently isn’t supported by my setup, so I can’t test it.

Also during Tokamak3, Dario fixed a bug that would switch the display’s brightness back to 100% after it was dimmed because the machine had been idle. So if you’d set it to 50%, and it would then dim after some minutes of idle time, you’d move the mouse and it pops back to 100%, while it should go back to 50%. That’s fixed as well, and the patch has also been backported to KDE 4.3. You probably are already running with this fix.

Update: I’ve just committed a couple of changes to the battery applet and explained them in a follow-up blog

61 thoughts on “Battery Improvements in KDE Plasma 4.4

    1. Tried that, it will look cramped, especially with larger fonts (mine are usually on the small side of the spectrum). I think the way it’s now is actually OK, since the configure button is quite different from the sleep and hibernate ones. What’s the problem you’re seeking to fix with this change?

          1. Let’s read the other way round: less empty useless space. Take a look, you really have a lot of wasted space.
            Also take a look at how “Screen brightness” and the slider and how “Power Profile” and “Battery” vertically align. The text “Power profile” should be at the same height as “Battery”, but they’re not.

  1. I find the power management in KDE really cumbersome. All I really want is to adjust brightness and the rest should be handled by the apps I happen to run. When I watch a video in full screen or a presentation I don’t any power management.

    All these profiles and settings are just geek heaven, aren’t they?

    1. The profiles should be set up so that you don’t have to change anything. Changing brightness is one of the top use cases for the popup, and I think that works pretty well already.

      If you could be more specific what you think is cumbersome, we can probably do something about it.

      1. Thanks for the replay. Idk really, I guess when I tried to adjust the various profiles to my liking I felt a strong “paradox of choice”. Maybe hide the whole profile thing from non-advanced users. There was a GCDS talk that suggested something similar.

  2. GNOME power manager has some code that profiles the battery to get (allegedly) very accurate timings[1]. It’s apparently been moved into DeviceKit-power[2]. Perhaps it’s worth looking into putting a DeviceKit-based backend into Solid and using that? Especially seeing as people are planning to get rid of HAL at some point.

    [1] http://blogs.gnome.org/hughsie/2007/03/09/gnome-power-manager-time-remaining-profile-code/
    [2] http://blogs.gnome.org/hughsie/2008/11/09/gnome-power-manager-and-devicekit-power/

    1. That sounds useful, but again only works if you keep doing the same thing (or at least something with about the same amount of system activity in terms of power drain). So it’s partly a solution, and I’d be happy to use that code as well. It helps, but doesn’t ultimately fix the problem.

      1. I confess to being truly stunned by your reluctance to include the time remaining feature. Would you use a word processor if it didn’t allow you to save or print a document because the document contains words the spell checker does not recognize? Likewise, why do you want to deny potentially very valuable information to your users because you think you know more due to your superior knowledge? Consider the example of a user who is experienced with notebooks, and who borrows an unfamiliar notebook from a colleague or friend to do some time sensitive work. They simply want an estimate of how much work they can reasonably expect before the battery runs out. They are not stupid. Their experience tells them that the time remaining depends on usage. They just want an estimate. Will it be more like 2 hours, or 5 hours? You think you know their needs better than they do. I think not.

        1. Read above blog how you get this setting. I think we made a fine compromise there (allowing power users to enable it, not confuse “non-power users”). The issue has been discussed to death, and while you’re entitled to your opinion, it doesn’t add anything to the discussion. In fact it makes me wonder why a compromise at all, people like you just will never be happy. You’ve just proven this point.

          As to your analogy, the whole point is that the information is unreliable. So even if it tells you “5 hours left”, it might as well be 5 minutes. (And yes, I’m not making this up, I can see this on actual hardware I own myself.)

          Really, this option only makes sense for hardware that is proven reliable (and even then the battery deteriorates at *some* point, making the information worth nothing), and for people that understand it. I expect that in this case, adding one line to a config file is not too hard.

          1. I did read your blog post, carefully. I concluded some of your design principles alienate users. Where you experience painful compromises and people who will never be happy, I see users who want to get on with their work and be able to make reasonably informed decisions about how they can go about doing that. I think good design enables that inasmuch as possible.

            You’ve indicated you don’t want to discuss it anymore. You’re the developer — it’s up to you. Just don’t expect this issue to go away, and fully expect to lose users to other platforms and systems.

        2. “Their experience tells them that the time remaining depends on usage. ”

          In that case, they can look at the % charge and figure it out from there. kind of like a gas gage in a car or pretty well every singe mobile phone on the planet.

          “Will it be more like 2 hours, or 5 hours?”

          And yet with today’s hardware (netbooks being a great example here, glad you picked that, esp ARM based ones), what you’re doing can swing those numbers RADICALLY in the span of minutes or even seconds. The % charge is accurate, however.

          “You think you know their needs better than they do. I think not.”

          It’s not about knowing people’s needs, it’s about not lieing to them and teaching people that the computer is untrustworthy.

          1. “In that case, they can look at the % charge and figure it out from there. kind of like a gas gage in a car or pretty well every singe mobile phone on the planet.”

            New cars usually have a digital board showing the estimation how much you can drive with that current speed. It is nice that you get “Estimation 164km” And it is always counted downwards, so you can actually get over it. But main point just is that it tells more than just a normal meter. Like example, on my car, I can drive with full tank about 600km. But with my friend old Saab, he can drive 1200km with one tank… It is 2x more than mine. And one time he borrowed my car for a day and he fas scared because he needed to check the gas meter all day with his ~350km trip.

            The % and time are stuff what just is wanted by many. The information is just something what you can notice easily yourself. Example, you sit on train and type letter. You see that meter tells you a 2 hours left. After a 30min, it says you have 1h 30min. You shoot up a HD movie and after a 15min, you notice you have anymore a 30 min batterytime. You learn how the computer actually works on the battery. The % time does not grow up anymore. But you can notice that what is the usage. Same way as any new car after 90’s includes a estimation usage of gasoline. So when you drive, you know are you using 3.7 or 6.4 liters per 100km. It is just a information what helps the driver to understand how the gasoline will last when they drag a wagon after them and they have whole family in car, when compared to situation that you have mostly drived by alone.

            Even somekind graph would be awesome like on Gnome battery monitor. Now you need to check the clock and make quesses by remembering the battery % what it had then and what it has now and do estimation yourself.

          2. “It’s not about knowing people’s needs, it’s about not lieing to them and teaching people that the computer is untrustworthy.”

            Following your logic, apparently you never bother with the ‘time remaining’ feature in your web browser file downloader component, or from a DVD ripper, or your backup program, or any other application that tries to give a meaningful guess as to how long something will take. From your argument, these features should also be removed.

            Of course, if you have ever looked at this information, and consequently made a decision such as “I think I’ve got the time to go and make myself a cup of tea”, then your own habits indicate your argument ought to be revised.

            And it goes without saying that the developers of these applications include these features not because they think their users are stupid or that their application is lying, but because they respect the intelligence and experience of their users.

    2. The profiling code doesn’t run when it thinks the usage patterns are “not normal”, i.e. average usage. Sure, if I leave my machine idle vs spinning 100% CPU, there is a huge difference, but people don’t let their machines spin CPU for hours.

      Not saying you should make the option user-visible just yet, but I think the issue should be revisited when Solid moves to DeviceKit-power or the battery applet otherwise gains this profiling feature. I’m not convinced the data will still be as inaccurate as it is now.

  3. To be honest the new one (if new is the latter one) looks like random collection of widgets :)
    I mean layout-wise. IMHO you need to align widgets better. The bottom ones stand out, they look unnatural and unattached to the rest of the widgets, creating a kind of a mess.
    In this regard the first screenshot looks much more lovely and eye-pleasing.

    At least this is a way I see it :)

    1. I’ve played around with both options and found the “both buttons align left” much cleaner, visually, than putting them next to each other.

      Also keep in mind that any number of buttons between 0 and 3 could show up there, depending on the system’s capabilities. In that sense, the current layout certainly scales best.

      1. What about just using icons (no text) on the buttons and then centering all of them (including the settings one) at the bottom? The tooltip can provide the full name.

        1. Could play around with it, but we’re solid frozen now, and will be for another two months…

          Maybe we can revisit this for 4.5.

  4. Great overall look, some thoughts that come to mind:

    Can you vertically align the “Screen Brightness” and “Power Profile” text with their respective items on the right. Seems a bit lopsided to me right now.

    Also, the background of the “4%” blends too much with the plasmoid background and makes it look like a piece of the battery is missing/cut out. Maybe better alignment on that or a different sort of background?

    And one final thing was the display of battery charge. Currently the battery uses 4 giant blocks with two colors to show various levels of charge state. This means that many charge levels (like 10%) are not represented at all when they could easily be seen in larger battery displays. I had a patch for a “continuous” battery icon a while back, but I think it would be useful to provide the option. Then the user can better see battery charging progress visually.

    1. The vertical alignment of the labels with the input widgets is something we’re looking to fix in libplasma right now, so yes, this one could be improved.

      As to the battery’s artwork (the contrast issue you’re pointing out), I also agree. At the same time, I’m tired of asking for improved artwork, there’s about three persons who promised to help with better artwork for this (after pointing out similar flaws), none of them has gotten back to me with anything. In fact, the artwork that’s currently used has been done by me (took the battery icon from Oxygen, modified it so I could work with it programmatically and popped it in). It’s way-pre-4.0 stuff and done by someone who touched Inkscape for the first time. I’m happy if someone sends me better artwork for the battery, but so far there are only empty promises.

  5. Honestly, when I just looked at two screens, I thought the first was the new one and the last the previous one. Then I’ve read the description and was shocked. You really made a step backwards here.

    1. Sorry, even when trying, I find it hard to please everyone. People’s opinions and tastes are just too different.

  6. Hi

    To my eyes from the screen brightness label down it looks like a two column table with a mixture of labels and actions on each side. It also looks odd to me that the power profile label does not vertically align with the dropdown.

    I’m a developer so I know how hard it is to get the UI elements looking good. Thanks for all the work you put into KDE by the way

  7. Why not something simpler? See http://imagebin.ca/view/73LJ6Df.html
    There are already sleep and hibernate actions on the main menu, why have two places to do the same action?

    Also, the separation line has the same look that the slider and it’s confusing, and screen brightness and power profile should be vertically aligned with the slider and the combo.

    Thanks for keeping remaining time option, you’re great!

  8. I dont know yet but what now I few minutes stared those two screenshots, I like more the current 4.3 version.

  9. Did you really say and think, the new dialog looks less messy and is more consistent than the old one?

    I don’t think so. Take a look at how the parts (labels, buttons) of the widget are aligned: at the old one they are consistently aligned left, except ‘hibernate’ and ‘more’, but they nevertheless fit well into the design. Additionally important labels are bold (Battery, and AC Adapter).

    At the new widget design, the upper part is aligned in the middle, ‘Screen Brightness’ and ‘Power Profile’ right, and ‘Sleep’ and ‘Hibernate’ leftside. And in contrast to the old version the labels on top are in the same font-weight as the information they point to, which make them harder to distinguish.
    All in all the new one looks very chaotic and confusing to me, as it lacks completely any order.

    I only can beg you to rethink the new GUI.

    1. I can not do more than agree about begging to rethink the UI or then keep the current (old) one.

      I spend now about about half hour to think what is wrong about this and planned to come to say it. You just said what I was about to say.

      The new dialog might be following the HIG accurated, but it is not a ruleset what should be followed blindly everywhere. Like this one, the whole UI looks unbalanced and scattered around big area.
      I do not know does KDE HIG have any meanings by visual persons (artits etc) who have studied different way the numan attention to UI’s than usability experts. The new UI has something on it what makes me think more about it’s features and what it offers. where options are located etc than the old one. Mayby the Sleep and Hibernation buttons are just too small, the screen brightness slider too short and so on.

  10. this point is very important and annoying to me (i.e. i always fear thet polling for the time from the bios, from hal, etc, it’s been more expensive than “featurous”): but what about the use of ibam? it is a small app i use here on debian, that make some calculations i don’t study about and archive statistics on the battery usage (on per user basis i think), producing some affordable guess of remaining time, at least in my experience.

    So: 1) why don’t rely on IBAM for the battery monitor plasma-w?
    2) what about keep away power manager stuff from the battery monitor (i.e. brightness, power-scheme)

    (note that, actually, i disable the battery plasma widget on my desktop… Maybe i’m not too representative…)

    1. Pretty simple, out of those few that have been very vocal in complaining about the lack of remaining time, nobody actually stepped up to implement it. My own time isn’t unlimited, there you go…

    2. I would like to have a power manager without batter monitor for my desktop computer. So I could set it to place CPU to 800Mhz level instead running all the time over 2100Mhz. Configure the screen brightness from panel and hibernate/sleep from same place. Now if I add power devil widget, I get error “No battery” and it’s icon to panel.

      1. Powerdevil runs fine without the widget, thing is that you don’t even notice it. So you’re already running one. Ah, the powerdevil widget is the battery applet Sebas is talking about, whatever else you tried to add is bogus

  11. To be honest i too thought the top screen shot was the new one until i thought to myself “hmm this looks strangely familiar” and checked.

    My world is SWT at the moment not QT, but when i read your description i can’t help but wonder why you didn’t use a grid layout or the QT equivalent? form layouts scare me…

    From an aesthetics POV i’d suggest re-aligning the battery info lines along the left of the form, making the separator line extend under the battery image so it spans the entire form, aligning the brightness and power profile strings to the left in line with the sleep, hibernate buttons and finally i’d suggest arranging the sleep, hibernate buttons horizontally instead of vertically in order to cut down on the empty space.

    I’ve spent the last 2 days at work trying to beautify some preference pages that contain around 30 radio buttons and maybe a dozen check boxes in various categories and it’s a complete pain to get it looking perfect. I feel for you :P

    1. WIthin the KDE HIG, we’ve decided to right align labels on the left and left align widgets on the right. This makes it easier to see that they belong together, and I personally also find it visually more pleasing and easier to read.

      But yes, layouts are hardly ever perfect, as you note.

      1. Looking at it again, the brightness and profile labels look fine the way they are, except the profile label looks like its vertical alignment with the actual widget is off.

        The battery info, adapter info etc.. don’t look to be aligned with anything as it is now imho. Are the text/label widgets a fixed width or something? if they are and your going for right aligned you should also set the text within the Text/Label widget to be right-aligned.

      2. Actually, I think the idea “to right align labels on the left and left align widgets on the right” is great but the problem is that “4% discharging” does not look like a widget but as another label. Two lables next to each other look like one centered label to me. I think if you put either the left or the right label as bold, it gets much clearer and the alignment starts making sense.

        1. I see………. you are correct, they are aligned after all……..

          The problem is though that it took someone else to explain the alignment to me before it became clear, its simply not obvious enough imo for it to look correct to the casual observer, which i’d guess is going to be 95% of the user base.

          Does the HIG make allowances for instances such as this? where the two items being aligned look like one contiguous object? because i don’t think many people would look at that and go “Yes… this is a shining example of how UI design should be done”

          Whilst i agree with the people suggesting that the label part of the widget should be made bold, as it would surely help differentiate between the label and attribute parts, i still don’t think its the best solution.

          I say this mainly because people in general are used to seeing plain text (which is what the top attributes look like) aligned to either the left of the screen or the right depending on country of origin. Anything else just tends to look wrong.

  12. The seperator looks the same like the slider. This is just confusing and should be removed.

    At the moment the old layout is much more straight forward and optically pleasing than the new one.

  13. I’ve looked at both screenshots, and I think I know what people are trying to articulate as the source of their dissatisfaction.

    Starting form the top of the widget, with the text and the battery image:

    Could you possibly bold the words ‘battery’, and ‘AC Adapter’, such that they’re more visually distinct. BTW, I think right aligning them against the left aligned information is pretty nice.

    You dropped in a dividing line, which I think is a good idea, it separates the two logical pieces. The only improvement there is that it should not only cross the text but also the battery, right now it’s awkward how it only crosses one.

    Easy touch ups in the second half would be to vertically centre the ‘screen brightness’ and ‘power profile’ labels, and/or do whatever to align them with their respective controls. Currently, the brightness slider is aligned with the bottom, and the profile drop down’s top seems aligned with the bottom of the text label.

    This one is a toughy, and I’m having a hard time providing any suggestions. The problem is that in the second half, the text labels have their contents right aligned, but the buttons for obvious reasons have their icon and text left aligned. I realise that the labels and buttons are are aligned together, but it’s making it really weird. It *might* be workable to separate out the sleep and hibernate buttons with their own alignment, perhaps centered in the widget.

    I know some of these have been addressed, and I very much appreciate the work going into this. I too am a dev and am merely providing suggestions based on the HCI course I’ve done, and some books I’ve read, purely about simple layout. Thanks for all your work!

  14. What about the words “sleep” and “hibernate”? While I like these more, everywhere else in KDE SC 4.x the technical names “suspend to RAM” and “suspend the disk” are used.

    After staring at both for a while, I like the 4.3 version more.

    1. Are you running Kubuntu? As far as I know, the names have been changed there. That’s actually another small thing we found out during tokamak, and we’ve streamlined it between Kickoff and Powerdevil?

      1. I’m running from trunk and I can still see “Suspend to RAM” and “Suspend to Disk” in the logout dialog in KSMServer.
        However this probably can’t be changed because of the string freeze…

  15. Thank you for your work to improve the battery applet!
    But like some other users that left a comment I also thought that the top screenshot is the new one, it looks way better.
    What especially disturbs me with the (real) new one and what I find much nicer with the old one are the strings “Screen Brightness” and “Power Profile” and the according slider/selectbox. For me it looks better if they are left-aligned and one under the other like it was in the old layout. And the dividing slash is imho not needed.
    But I think the center-aligning of “Battery: X%” and “AC Adapter: something” is very nice!

  16. Awesome that we’re trying to improve the visual consistency across apps.

    I think the left-right/top-bottom balance may be part of what is “off” with the new dialog. The top is heavy and appears to be “toppling” off to the right. Because both buttons are stacked on the left, the base of the dialog appears unstable – there’s nothing “holding up” the now top-right heavy part of the dialog. Moving the buttons to the right (side-by-side or stacked… hmm… not sure…) or letting them span the bottom might provide a better base for the rest of the dialog.

    I know you were aiming for less vertical lines, but you may have inadvertently created more. Because the buttons are both left-aligned and themselves have hard left edges, it de-emphasizes the “middling” line between the labels on the left and info/widgets on the right – which should be the prominent, anchoring vertical line of a form layout. This de-emphasis in-turn causes the left side of the text labels to take on more meaning and create vertical lines of their own. In the previous dialog, while there may well have been more vertical lines, two really dominated – the two outer edges. Absent these to lines, the “middling” line has to be really strong to encourage similar or better vertical scanning than the previous dialog. As it is, the “middling” line is a little weak because of:
    1. Inconsistent “:” usage in the labels
    2. Broken eye-tracking down the line caused by the slightly left-of-center horizontal line between the upper and lower portions of the dialog. It looks like the intent was to center-align it on the “middling” line, but without an obvious reference point on the horizontal line itself, the intent may be getting lost. Unfortunately this also compounds the left-right imbalance of the the dialog. This line is, perhaps trying to do too much. It might worth just letting it do one thing – provide separation of the upper and lower portions. Let other elements establish the “middling” line.
    3. The slider widget that doesn’t have a concrete enough visual reference point on its left edge to rely on it to help define this “middling” line. Not much you can do about that, but consistent use of the “:” on all labels might help.

    Anchoring the buttons to the middling line might also help.

    Also don’t forget the vertical alignment of the label text and the widget text.

    This feedback was meant only to be helpful and constructive. As always, I remain grateful for all your efforts.

    peace and respect.

    1. Thanks for the interesting and imo good analysis. :)

      I’ve just changed a couple of things, I think they address most of your points.

  17. 1. Remove the top line what separates the time and brighness.
    2. Bold the text of important info about AC and battery.
    3. Move the “Sleep” and “hibernate” to same level. (so it would look like [Sleep] [Hibernate])
    4. Move the wrench to right side of the profile droplist. So you know right away that clickin it you can edit it.
    5. Do not even allow by manually configured time to be shown with seconds. None other battery tool does not show seconds. That is very inaccurate. They just show “Estimated 44 minutes” or similar. With “44 minutes 38 seconds” it tries to be very accurate but it is irelevant to have seconds there.

    I am not sure about the renaming “Sleep” to “Suspend to RAM” and “Hibernate” as “Suspend to disk”. The sleep is always for me much accurate information about computer just sleeping and waking up fast. While hibernate is total jargon for me usually because it is many times used for sleep function. Dont know why!
    The “Suspend to” is nicer even that the user need to understand RAM and Disk differences. But that should be at least same for everyplace, from Powerdevil to KickOff and to KRunner.

  18. What I would like is a display of something like “You have been running on battery for XX hours XX minutes.”

    Might satisfy the “time remainig” crowd a bit?

    But still, OS X have this feature and I find it useful. Hm… I think I’ll wote for both options!

  19. I think what looks weird about the new layout is just how the Sleep and Hibernate buttons stick way out to the left for no apparent reason. If their left edge were aligned with the combobox or one of the text labels (and the whole dialog got accordingly a bit thinner), I think it might look better. At present you sort of get the impression that the top third, middle third, and bottom third of the dialog are centered on different points along the horizontal axis (which might be a separate issue).

  20. Hi,
    Frankly, I think the *new* dialog is a mess to look at. It has become way too wide, which you try to compensate by leaving the text in the top centered, which just adds to the confusion. The unnessecary width seems to be a result of putting the labels of the screen brightness slider and the profile menu in the same line as the controls. All that space makes it much harder to overview the dialog, so it was much better before.
    In my opinion, that is.

  21. There should be an easy way to view current technical battery information such as capacity left, current charge in Wh and constantly updated current power consumption in W.

    I have several suggestions for the new widget design:

    “Sleep” and “Hibernate” buttons could be displayed alongside at the bottom.
    The “Power Profile” label could be aligned vertically centered.
    The horizontal separator could be exchanged for a simple space.
    The light bulb of “Screen Brightness” could be placed to the left of the slider as it is a very good visual aid.

  22. New style is horrible. It is so unbalanced.
    First three labels form the top are centered and do not look good at all.
    So much empty space, and tiny wrench in the corner.
    Profile chooser is not in line with label.
    Really only improvement i see here is that it displays remaining time.

    And i know you hate hearing this, and it is not easy to listen to bad critics, but i really think you should reconsider new layout.

  23. Hm, I have a few suggestions to make:
    the separator looks the same as the slider, maybe it should be removed. The lamp icon next to the slider was cute imo (and added a bit of colour). The wrench icon should indeed be next to the profile droplist, to make it clear what it refers to. Also, if you are going to display time, make it “44 minutes remaining” instead of “44 minutes and 38 seconds” or maybe even “about 45minutes remaining”. I think people kind of expect the inaccuracy, since it is the same on most battery powered devices (mobile phones, ipods etc). At least you see it continuously going down, unless the battery is going dead were it jumps to 0% (so the percentage is also inaccurate).
    Finally, I think the hibernate & sleep buttons look nicer in the same row (and reduces the empty space).
    Thanks!

  24. I would suggest getting rid of the horizontal separator, and adding colons at the end of “Screen Brightness” and “Power Profile”. The vertical alignment of the labels seems to be fixed, so won’t comment on that.

    The buttons should be on a single line IMO, and right aligned. Maybe you can use a separator on top of them. This would make it look even closer to a KDE dialog layout.

    I also find it strange that the battery percent is duplicated.

  25. I am relieved, that I seem not to be the only one, who thinks the original layout looks better and more structured.

    And a second critics: battery-applet is most important for laptop users with touchpads. select-combos are not nice to handle with touchpads, better would be the most 3 important options with radio buttons (like powersave, medium, speed), and others in advanced dialog. I really like the windows vista dialog.

  26. one thing I forgot: estimated time can be of much value. If hal/.. values are really that bad, then it might be good, to improve this by doing this another way. I find the estimated(!) time values in other OS really usefull, although I know/see, that these times change on usage.

    And I really do not want to find a line in a hidden config file to activate this.

  27. Would it be possible to have current power consumption also displayed? I would like to glance to power manager applet and immediately see if something is draining the battery faster than usual, and power consumption is probably more useful than remaining time estimate.

Comments are closed.