Yes, this is a good idea and one I have been pondering for a while. The only stipulation I have is that the warning should have a "Do not notify me again" type link (use libnotify callbacks?) so that it doesn't display every time the user starts GNOME :-)

Do you want to impliment this or me? I'm somewhat busy atm, so it may take a few days/weeks if I was to do this.

Richard.

I agree that it should be shown only once. I was thinking of storing full_capacity div design capacity in gconf and only when it passes 50% to do a notification So it will autmatically not appear again.

I can look into this, but it will also take me probably a few days or maybe a week to do this. Don't have that much time either. I'll leave a comment here if I start on this. I'd appreciate if somebody else who works on this also does. That way we won't have 2 people working on the same thing

Instead of storing full_capacity design capacity in gconf, why not just a bool saying "don't display the warning" -- seems simpler to me.

Richard.

Duuh, that's indeed a lot simpler

Jaap, I can have a stab at this if you like: I was thinking of doing the checks in gpm-power.c (battery_device_cache_add_device), and then throwing the signal battery-capacity-warning so that gpm-manager can do the libnotify dialogue.
That sound okay?

Might be better to use add_battery() instead of battery_device_cache_add_device().

If you are going to store a flag in gconf it would have to be per-machine/per-device.  If I disable the warning on one machine with one battery it should still warn with other batteries, right?

On the other hand, this aging doesn't happen over night and I'm sure the user will learn that the charge time has been decreasing.  So, maybe pestering the user about this isn't necessary?  It does sound like useful information though.

Maybe this could be added to a battery summary information page available in the right click menu on the tray icon.

add_battery() is better, agreed.

As for the warning, I don't think we need to get that complicated. The common case is a user with one or two batteries in a laptop, one of which is old and broken.

g-p-m notifies the user, user goes "ohh right, that's why the tooltip sometimes lies!", and very quickly the user gets bored of the warning, and disables the notification. I don't think it has to be any clever than this for essentially little used functionality.

I also think having the notification on the tooltip is overkill. I use an old broken battery every now and then, and sure don't want the notification everytime I check the battery remaining time.
But then, saying that, on broken batteries the remaining time is usually really broken too, so maybe it does need a "1 hour 6 minutes remaining (worn out battery)" in the tooltip.

I think Jaap's idea in #326741 is where all the detailed information belongs.

Richard.

My point about setting a gconf key is that you'd have to have a separate one for every battery device any system you used ever has.

Oh, and make sure to the flag is reset when you replace the battery.

Why a seporate gconf key for each battery? Surely it's an show-notification or no-show-notification type thing?

I think the scenario goes like this:

start:
1. New laptop, keyboard, mouse, UPS
2. time goes by
3. if gconf key isn't set, g-p-m pops up a notification that battery capacity has been reduced by %50
4. user says: "yeah, yeah, I know.  Yesterday my battery only lasted one hour."
5. user clicks "Don't notify me again"
6. set gconf key
7. user get's around to replacing the battery
8. goto start

OR instead of #7 the user logs into another machine using same $HOME or moves files onto another computer.

Either way there is a problem.  So, this means that the feature is super annoying because it warns every time you login until you fix the problem or it only works the first time ever.

Okay, I understand what you are saying, but I don't think we have a choice about showing it if the user logs in from another user account as gconf is not per-system (yet).

I think if we include this as a g_warning, then the advanced users (the sort that sent bugreports) will understand why the battery time remaining is so erratic and maybe not file a bug.

Maybe something like this:

/*
 * We should notify the user if the battery has a low capacity,
 * where capacity is the ratio of the last_full capacity with that of
 * the design capacity. (#326740)
 */
if (strcmp (entry->kind, "primary") == 0) {
	gint design, lastfull;
	gpm_hal_device_get_int (udi, "battery.charge_level.design", &design);
	gpm_hal_device_get_int (udi, "battery.charge_level.last_full", &lastfull);
	if (design > 0 && lastfull > 0) {
		float capacity;
		capacity = design / lastfull;
		g_error ("Primary battery capacity: %f", capacity);
		if (capacity < 0.5f) {
			g_warning ("Your battery has a very low capacity, "
				   "meaning that it may be old or broken."
				   "Battery life will be sub-optimal, "
				   "and the time remaining may be incorrect.");
		}
	}
}

Gconf databases are shared between systems in a few cases: shared NFS home directories, LDAP backend.

As I recall the monitor resolution capplet does some per system type gconf stuff.

An idea to implement this without having the annoyances Jon is mentioning:

We just show a notification once (no cancel option necessary) at 50%, 40%, 30%, 10%. Battery last_full change is slow process so it won't be annoying. Since we display it four times the user will probably at least notice it once)

In gconf we store of two batteries the last_full_capacity (I don't know of laptops with more then 2 batteries). When gpm starts we try to figure out which battery matches which gconf key. I could have switched or changed the batteries. If there is no match we just overwrite one of the two.

If I'm correct last full capacity only changes when charging ends (i.e. batteries fully loaded). If the charge ends we obtain last_full of the battery (last_full) and  previous last_full from the corresponding gconf_entry (prev_last_full)

Some sample code


bat_percentage = last_full_bat / design_bat;
prev_bat_percentage = prev_last_full / design;

if (prev_bat_percentage > 50.0) & (bat_percentage <= 50.0) {
     notify_battery_percentage (50)
     update_gconf_key_last_full (last_full_bat)
}

>We just show a notification once (no cancel option necessary) at 50%, 40%, 30%,
>10%. Battery last_full change is slow process so it won't be annoying. Since we
>display it four times the user will probably at least notice it once)

Yes, this would work too.

>In gconf we store of two batteries the last_full_capacity (I don't know of
>laptops with more then 2 batteries). When gpm starts we try to figure out which
>battery matches which gconf key. I could have switched or changed the
>batteries. If there is no match we just overwrite one of the two.

Use battery.serial as the key?

>If I'm correct last full capacity only changes when charging ends (i.e.
>batteries fully loaded). If the charge ends we obtain last_full of the battery
>(last_full) and  previous last_full from the corresponding gconf_entry
>(prev_last_full)

>Some sample code

Looks good. What about the following gconf keys:

/apps/gnome-power-manager/notify/capacity_battery0_serial (string)
/apps/gnome-power-manager/notify/capacity_battery0_lastwarning (int)
/apps/gnome-power-manager/notify/capacity_battery1_serial (string)
/apps/gnome-power-manager/notify/capacity_battery1_lastwarning (int)

Richard.

I've applied a little bit of warning code (g_warning) to add_battery that we can work on.

I have four batteries any two of which may be attached to the laptop at any one time. It'd be nice if g-p-m remembered by the serial numbers of the batteries it had told you about so that changing them around between slots wouldn't confuse things.

But at the moment you only get a g_warning, rather than a libnotify event, so it's not really an important problem.

Say we enable the libnotify event....

How should we store in gconf the serials of batteries that we have warned of before?

/apps/gnome-power-manager/capacity_warning_done = "1400008981,1500008980"

or is there an easier way?

Richard.

That would work, I'm not sure how gconf stores lists, does it even have a string-list concept which we could use here?

I wouldn't worry about rubbing the user's face in it when their battery stops working so well. It'll be clear to most people this is happening already, we don't need to nag them about it. We can make information available in a battery info dialog (see bug 326741) that gives them info about how good their battery is compared to its original condition, but we probably don't need to really tell them explicitly about it.

I think I agree with Seth here... Considering the amount of effort it's going to take for a dialogue the user is going to see only once per re-install!

OK, I'll make a wontfix of this