Re: [gpm] Using HAL: reporting.low and reporting.warning

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:

Hi Richard,

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
the battery.

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 here.

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 minutes more.

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
the opposite.

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.

What about:

1 notice at 20 minutes
1 warning at 10 minutes
1 critical warning at 5 minutes, with a link that lets the user abort
the action?
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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]