After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128644 - Request: independent monitoring of dual battery systems
Request: independent monitoring of dual battery systems
Status: RESOLVED OBSOLETE
Product: gnome-applets
Classification: Other
Component: battery
git master
Other All
: Normal enhancement
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
: 147877 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-06 04:10 UTC by Dominic Hilsbos
Modified: 2020-11-07 12:25 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Dominic Hilsbos 2003-12-06 04:10:40 UTC
I am running Mandrake Linux 9.2 on a Dell Inspiron
3800.  This is a dual battery system (with one
battery sharing space with a removable drive). 
I'd like to see the battery monitor tracking each
battery seperately.

Thank you for your time.
Comment 1 Danielle Madeley 2004-05-23 17:08:05 UTC
This is in the design goals for when I rewrite the battery applet.

See http://www.livejournal.com/users/davyd/98869.html for some thoughts I
scribbled down.
I am still not sure how APM represents multiple batteries (and unfortunately we
still have to deal with APM).
Comment 2 Danielle Madeley 2004-07-22 13:17:50 UTC
*** Bug 147877 has been marked as a duplicate of this bug. ***
Comment 3 Danielle Madeley 2004-10-30 10:57:41 UTC
The rewrite is waiting for HAL to support batteries.
Comment 4 Allison Karlitskaya (desrt) 2005-07-08 20:26:08 UTC
OK.  This is now within grasp.

I suggest a (gasp) preference that only appears if battstat detects 2 or more
battery bays:

 [X] Display the status of each battery separately

In the case where it's not checked, it will just sum up the totals for both
battery in the same way that the current ACPI code does.

In the case where it is checked, the toplevel of the widget will become a box
(or a table?) that contains two sub-applets.

Alternatively:

In the event that more than one battery is detected a preference appears:

Show status of which battery:
   [ All batteries combined  V ]
   | Battery #1 Only           |
   | Battery #2 Only           |

and you leave it up to the user to add multiple applets and set one of them to
"#1" and the other to "#2".


This might be premature.  We also need to talk about how battstat will behave
within the new hardware-based-applets framework that's -- supposed to be ;) --
coming soon.
Comment 5 Danielle Madeley 2005-07-09 02:13:44 UTC
Ryan, I don't really like what you're suggesting. I would like to keep one
singular battery on the panel. Instead, have a dropdown that looks something
like this: http://davyd.ucc.asn.au/images/battstat_status.png (ignore the
GtkNoteNook, I was originally considering something similar to GNOME-Netstatus).
When you click on it, you get a dropdown similar to how the mixer-applet gives
you a dropdown, this dropdown contains the status of each of your batteries
separately.

This would still happen on single battery systems. No obscure preferences,
easily discoverable. We could also display lots of potentially interesting
information that HAL tells us. The panel applet will continue to display the
union of the information, which is in itself, the most useful thing to know.
Comment 6 Martin Ling 2009-11-02 01:36:47 UTC
This has been implemented years ago and can be closed.
Comment 7 André Klapper 2020-11-07 12:25:45 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use gnome-applets and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-applets/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.