Re: [gpm] Using HAL: reporting.low and reporting.warning
- From: Jaap Haitsma <jaap haitsma org>
- To: Richard Hughes <hughsient gmail com>
- Cc: gnome-power-manager-list gnome org
- Subject: Re: [gpm] Using HAL: reporting.low and reporting.warning
- Date: Tue, 10 Jan 2006 20:54:06 +0100
Richard Hughes wrote:
On Tue, 2006-01-10 at 04:38 +0100, Jaap Haitsma wrote:
Richard Hughes wrote:
On Sat, 2006-01-07 at 05:11 +0100, Jaap Haitsma wrote:
My batteries have as properties in HAL a reporting.low and
reporting.warning (also charge_level.low and charge_level.warning and
these have the same number so I guess they are the same thing)
Yes, defined by ACPI, and exported by HAL. I'm not sure if these are set
at manufacture time, or change with the battery lifetime.
These settings are fixed. Low or critical battery capacity remains low
no matter how old your batteries are.
The thing that changes is the last_full capacity. These decrease due to
aging of the battery.
Hmm, it's a shame low and critical are not updated for the lifetime of
Probably I wasn't clear
But they should not be updated. With for example 1000mWh left and a
latop taking about 10000mWh you'll have always 6 minutes of battery life
left. The thing that's going down is the full charge which might have
been 50000mWh when you buy them (so you 5 hours of battery time). The
full capacity might go down to 30000mWh after a year of heavy use which
gives you 3 hours of battery time. The critical threshold in that case
will still be 1000mWh which still gives you 6 minutes.
Can't we use these properties instead of the sliders? Or are these
properties not present for all type of batteries?
I think maybe these values could set the default for the sliders, but I
think the sliders should remain -- as people have different preferences
Let me try to convince you that people do not have different preferences
When batteries are getting low people just want a warning which says
that their batteries are low and that they have let's say 10, 20 or 30
The thing is, I'm pretty good at ignoring the first few warnings, rather
than scrambling to find the ac_adapter. I'm sure other people are just
If batteries are critical there should be a warning dialog
and the laptop should hibernate within 10 seconds if the user does not
cancel it. (We should still add this option that a user can cancel
hibernation, a user might want to hit the send button of his mail
program before hibernating )
We need to use the libnotify callbacks for this I think.
The sliders with percentages do not work well if you for example now and
then use 2 batteries now or use batteries with different capacities.
Yes, this is a valid point. What about we just throw these sliders away,
and define a per-time warning, like a lot of people want.
As long as we have a sufficiently long warning time, compared to the
resolution of the updates and the changing of the cpu load, the aliasing
and inaccuracy shouldn't be a problem.
1 notice at 20 minutes
1 warning at 10 minutes
1 critical warning at 5 minutes, with a link that lets the user abort
2 minutes later, the action is performed regardless
I'm all for it with some minor changes
I'd say to make you notice things we should use modal dialogs when thing
s are getting critical.
1 notification warning at 20 minutes
1 modal dialog at 10 minutes ( to make sure the user notices this)
1 critical warning at 5 minutes in modal dialog (will hibernate within
10 seconds) with a button that lets the user abort the action
2 minutes later a dialog pops up with a message that the system will
hibernate in 10 seconds. This gives the user a change to still do this
last minute thing.
Does this have to be configurable?
] [Thread Prev