I know the plugin (and especially the non-hal branch) isn't really maintained atm, but at least for the record… It'd be nice to adjust the conditions for showing “Charging”. There already is bug #3546 for when there is no battery, but another problem is when the user sets thresholds for start and stop. That means, for example, that an user with AC plugged in can have the battery at 50% and no charging nor discharging. A good place to look at for charging information can be at: /sys/class/power_supply/BAT0/status Here it says “Full” when the battery is considered charged wrt. thresholds. Cheers,
Created attachment 2185 query HAL if the battery is charging I suppose that the hal_based branch is the one that will be used in the future. Here is a patch for this branch that introduces a state "charging" to really separate between charging and idle states.
Duno about this, I guess the xfce4-power-manager package will be the future.
Yeah, but xfpm, as it runs in systray, can't display text, while a panel plugin can. I currently miss that functionnality. We talked about this with xfpm dev, and maybe the good solution would be to merge both, and have a panel plugin in xfpm, so one can chose between systray (xfce-indep) and panel plugin. What do you think?
(In reply to comment #3) > Yeah, but xfpm, as it runs in systray, can't display text, while a panel plugin > can. I currently miss that functionnality. We talked about this with xfpm dev, > and maybe the good solution would be to merge both, and have a panel plugin in > xfpm, so one can chose between systray (xfce-indep) and panel plugin. > > What do you think? As i understand from Jannis, the panel will provide a dbus method to add plugins in it for version 4.8, in this case it will be very easy to use plugins instead of systray icons, or both could exist as an to option choose for the xfpm, another thing i have in mind for the 0.9 version of xfpm, is to render the text on the display text.
The panel won't have that functionality, in a way that I do't have a clean solution to implement this: status icons != panel plugins. You can remote add plugins, but they will be permanently on the panel (until the user removes then, obviously). I think the best thing to do is a panel plugin that shows the battery status included with xfpm, I guess the most code is already available in the panel.
(In reply to comment #5) > I think the best thing to do is a panel plugin that shows the battery status > included with xfpm, I guess the most code is already available in the panel. Err. available in xfpm...
(In reply to comment #5) > The panel won't have that functionality, in a way that I do't have a clean > solution to implement this: status icons != panel plugins. You can remote add > plugins, but they will be permanently on the panel (until the user removes > then, obviously). > > I think the best thing to do is a panel plugin that shows the battery status > included with xfpm, I guess the most code is already available in the panel. This is a good idea, yes the user can add the battery panel plugin provided by xfpm then, so i agree with both of you, a merge should be done here.
Ok then, I'll take a look at xfpm then and come up with an initial panel plugin. The battery plugin is lately maintained by me (although i hard put any time in it), so it would be nice to move it to xfpm and being maintained there.
(In reply to comment #8) > Ok then, I'll take a look at xfpm then and come up with an initial panel > plugin. The battery plugin is lately maintained by me (although i hard put any > time in it), so it would be nice to move it to xfpm and being maintained there. Nick, i can do that if you agree, currently i'm writing a devicekit-power backend to be used in xfpm and also separating a common code to be used for the brightness plugin as well as the battery plugin.
Sure no problem, I just though I help you with this a bit since it will make my life a bit easier after the merge ;-). Where do you put the rewrite code? Git? Goodies branch?
(In reply to comment #10) > Sure no problem, I just though I help you with this a bit since it will make my > life a bit easier after the merge ;-). > > Where do you put the rewrite code? Git? Goodies branch? Currently the code is in my local svn server http://xfce.homelinux.org/svnweb/Projects (not always up, just to reduce my bill :) ), but i think i'll move the rewrite code to git.
Yes, please move it to git, then I can peek over your shoulder and maybe come up with some good (or bad) ideas.
(In reply to comment #12) > Yes, please move it to git, then I can peek over your shoulder and maybe come > up with some good (or bad) ideas. Sure, i will do that this evening.
Ok guys, let's get back on topic. If you want to discuss the panel API, please do it elsewhere. This is about fixing the battery plugin, which I think is useful regardless of whether or not xfpm does the same thing (I don't run xfpm since it doesn't give me anything I don't already have, so... I prefer the battery plugin). Let's get this patch in; looks worthwhile...
At least I would like to get a comment if the hal_based branch is worth to work with when sending in patches. If not, I'd like to know what branch to use for patches, as I plan to send other small patches, too, to fix other battery state related bugs.
@Brian: I haven't seen an api discussion? Anyway, we more or less agree the battery plugin will move into the xfpm package. I'll apply the patch in the hal_branch. @Tino: Not sure, up to Ali, if he wants to use the latest version of the hal_branch in xfpm I guess it useful if we fix bug in the hal branch until the panel plugin is moved.
What API discussion? No, I don't agree at all that the battery plugin should be moved into xfpm. I want a battery plugin but I don't want xfpm.
So you also going to maintain the battery plugin stuff? Both the hal branch and the legacy plugin? Like Ali said on the ml, it will be possible to use the panel plugin without power manager, just joining efforts and moving all the power/battery related stuff into 1 package.
Created attachment 2252 query HAL if the battery is charging How about this patch? It introduces the idea that a battery is either missing, idle, charging or discharging. One minor glitch remains: removing/adding a battery isn't that perfectly handled right now. However, without the patch, the plugin segfaults if a battery was removed while the plugin is running and the mouse if moved over the plugin, so at least it isn't worse than before.
I noticed that, if the plugin is started without a battery inserted, and the battery is inserted later, the user has to go to the properties dialog and configure the battery that has to be monitored. I will not be used automatically.
I am coming late to the conversation, but as I took over the maintenance of this pluigin, I guess my opinion is relevant. xfpm does a good job at what it does, so I don't see any need to make this plugin become closer to it, or merge with it (of course, xfpm is free to take piece of code from here if there is anything useful. I particular, I don't plan to port it to hal, devicekit, upower, or whatever fancy thing queries your hardware these days, because I think part of the point of maintaining this despite the existance of xfpm is to be able to run on systems where HAL, upower and friends don't exist. I might at some point add hal or upower support, but that will be in addition to, not in replacement of manual detection. For full disclosure, I haven't looked yet at how the code in either the upower or hal branch work, so I don't really know yet what I am missing.
(In reply to comment #21) > I particular, I don't plan to port it to hal, devicekit, upower, or whatever > fancy thing queries your hardware these days, because I think part of the point > of maintaining this despite the existance of xfpm is to be able to run on > systems where HAL, upower and friends don't exist. Remember that usually those systems don't have ACPI either. It's a bit of a mess, but directly querying the hardware means supporting a lot of exotic systems (APM, ACPI, PMU, whatever).
I understand that. But while I don't really know (yet) how this plugin works on all systems, I know that it currently does work on some where upower/hal don't (or didn't a while ago). So I think that adding upower as yet another way of fetching info, used only on systems that support it sounds like a good idea, replacing all current back ends with upower doesn't. Landry, can you comment on the status of upower on the various BSDs?
As of now, on *bsd, the plugin does the following: on netbsd & openbsd, ioctl() on /dev/apm. Legacy, but works, and will still work for a damn long time. The only change which could be done would be querying sysctls. on freebsd, it checks sysctl hw.acpi.battery.units (no idea if it works), and seems to fallback to /dev/apm ? regarding hal/upower.. upower is available on freebsd because someone wrote the compat layer for it in src/freebsd, and it is of course not portable as-is for other BSDs. I've had a look at it and gave up.
Ok, so this confirms my stance. This plugin may get support for upower as an additional backend for systems that support it, but it will be maintained with direct calls to system apis so that it can work on more exotic places.
(In reply to comment #25) > Ok, so this confirms my stance. This plugin may get support for upower as an > additional backend for systems that support it, but it will be maintained with > direct calls to system apis so that it can work on more exotic places. And do you plan to add support for those exotic places? (like PMU on Linux/ppc)
I'd be glad to have support for them. On the other hand, I don't personally own any such system, and I have limited bandwidth. So I'll accept patches for things like that, but I am not very likely to write support for them myself.
(In reply to comment #27) > I'd be glad to have support for them. On the other hand, I don't personally own > any such system, and I have limited bandwidth. So I'll accept patches for > things like that, but I am not very likely to write support for them myself. That's why using a more generic hardware layer might still be a good idea :) As far as I know, upower supports PMU on powerbooks, ACPI on the most common devices, APM on the oldest etc.
Of course it's a good idea! Replacing the handmade libapm/libacpi.c by upower makes sense, as long as support for systems where upower is not available is not broken on the way :)
Another vote for maintaining the battery plugin in its current state and *not* going upower. I'm using the battery plugin because it does its job in a simple way, reading the acpi interfaces directly. I'm not using xfpm for that reason: It would pull in about 20 dependencies (on Gentoo), among them polkit, consolekit, pmutils, udisks, parted, lvm2, ...
(In reply to comment #30) > Another vote for maintaining the battery plugin in its current state > and *not* going upower. > > I'm using the battery plugin because it does its job in a simple way, > reading the acpi interfaces directly. > > I'm not using xfpm for that reason: It would pull in about 20 dependencies > (on Gentoo), among them polkit, consolekit, pmutils, udisks, parted, lvm2, ... Then we do need a volunteer to track Linux kernel changes, port to the other various interfaces, stuff like that. Sometimes, dependencies are just a nice way to reduce maintainance work and code duplication.
But Xfce's main argument today is being light and offering choices (compared to Gnome), that's why I'm (and many others) are using it. I just switched from Gnome to Xfce, and it reduced the number of packages on my system by about 100 and improved startup time a lot, still offering more or less the same functionality I used before. If I wanted the full feature set of upower, it makes no sense duplicating it. But then, I would use xfpm+upower and not the battery plugin. But if I just want to have the batt status displayed (and shutdown issued if it is low), and no display backlight and DPMS setting and disk tuning for batt power, and no dbus application notification, I'm using < 10 % of upower and the other dependencies pulled in, and for using just < 10 % of it, pulling in all that mess makes no sense. And I'm always afraid that it pulls in some magic I don't want. For example, the gnome power manager insisted on switching to laptop mode, increasing disk commit interval to 10 minutes, and tuning some vfs and vm parameters. Not documented, not configurable, not even possible to turn off, absolutely silly on an SSD-only laptop (where it saves no noticeable power), and completely unacceptable to me w.r.t. data consistency. So let's keep the battery plugin as the light solution and xfpm+upower for those who need all the bells and whistles. Getting just AC and batt state requires only reading 2-6 files, and it already works (on linux). And that interface is most likely by far more stable than upower etc.. It's perhaps not worth porting the battery plugin to new interfaces (especially if xfpm + upower already support the new interface), but maintaining the existing functionality on existing plattforms should be easy and makes sense.
*** Bug 9068 has been marked as a duplicate of this bug. ***