GNOME Bugzilla – Bug 333146
Diagram over charge level/power consumption
Last modified: 2006-03-23 17:01:28 UTC
OSX allows you to get a historical graph over battery charge: http://media.arstechnica.com/reviews/hardware/macbookpro.media/xcharge.gif This looks pretty nice. Maybe we want to support something like this?
Where would we log the data points to? Some local file? Also, got any examples of the canvas element being used to draw a graph? I've never used the widget in that way. Thanks.
I'm not sure exectly how to log things. Maybe it can just be saved in the gnome-power-manager daemon memory, its not gonna use a lot of memory anyway. I would strongly recommend against using the canvas to draw a graph. gnome-canvas is really not very nice, and not required to draw a graph either. Drawing a graph with cairo is pretty easy. You could look at e.g. the code in procman (gnome-system-monitor). Another option is to use the graph code in libgoffice (this is what gnumeric uses), but that strikes me as way overkill for something as simple as this.
>its not gonna use a lot of memory anyway. Ohh, I thought you meant to remember the state of the last discharge across reboots -- that makes the problem a whole lot easier. >Drawing a graph with cairo is pretty easy. You could look at e.g. the code in procman Will do, but pretty snowed in at the moment. Where would this enhancement fit in the current UI, i.e. how would you lauch this feature? Richard
No idea where to fit it in. I just thought it was a cool idea. I'm leaving such mundane details to you. :)
How about on the info dialog (bug 326741)?
Yes, good idea.
Comment 2: > I'm not sure exectly how to log things. Maybe it can just be saved in the > gnome-power-manager daemon memory, its not gonna use a lot of memory anyway. Agreed.. please just keep it in memory; don't save it to disk - it will only spin up the disks and use a lot of battery. Plus it will wear out the flash when you're running on flash media (like we will for OLPC).
Well, long term it'd be better if we do save it across reboots and such -- if we can normalize load at all (which is somewhat doable) then we can track which parts of the battery retain charge best, and that gives us much more meaningful data to predict how much charge you've got left.
Created attachment 60631 [details] how about this This is something that I've knocked up last night (and learned cairo in the process)... it's a simple widget, where 11 (at the moment) data points are plotted from a chunk of pre-computed data passed to the widget. It's written in a (simple) generic way, so we can change the axes on each side pretty easily. The question now, is what to plot? I think time against percentage charge value (showing the user what the battery has been doing for the last 2 hours...) is a good graph to plot, as is the time against time_remaining, which should show some very intersting plots for seemingly "random" batteries. A question that bugs me a little, is how to embed a custom widget into a glade file? I guess I do this at runtime, but how to place it? Comments appreciated.
glade has a "custom widget" item in the "GTK+ additional" tab. Then you use glade_set_custom_handler().
Also, a cairo detail. You should offset the grid lines by 0.5 pixels. If you draw a one pixel wide line at an integer coordinate it is centered between two pixels and draws 0.5 pixels on each of the two pixels it touches. This means it becomes "fuzzy" due to the antialiasing. Same thing for the border.
I'm sure I'm doing loads wrong with Cairo. If I put what I've done so far into CVS, can you just glance your eye over the code please?
Created attachment 60774 [details] sample code This is the code I'm working on at the moment. Thanks for any review or comments.
<fanboy> This is an awesome feature. I'm looking forward to using it </fanboy>
Crazy suggestions for enhancements 1. Multiple battery support - show as dotted lines etc. (also support UPS) 2. Show user idle time too 3. Put in small flags when g-p-m is doing an action such as suspend, setting low power mode, lid open/close, ac plugged / unplugged, set LCD brightness etc. 4. Legend to describe flags and details on each battery (serial number, make/model) 5. Export image to file (Maybe just PNG.. could use PDF too) Might serve as a very useful debugging tool too.
I've started the UI and backend code... 2006-03-06 Richard Hughes <richard@hughsie.com> * src/gpm-info.{c|h}, src/Makefile.am: Add the beginnings of a logging and statistics module. * src/gpm-manager.c: Initialise and finalise the info module. * data/gpm-info.glade, data/Makefile.am: Add the outline information UI, showing batteries status, UPS's status, and the various charging graphs. This does not work correctly yet. And you can only activate this new UI with the experimental compile option as it's buggy, and nothing really works how it should yet. >Might serve as a very useful debugging tool too. Agreed.
2006-03-07 Richard Hughes <richard@hughsie.com> * src/gpm-graph-widget.{c|h}, src/Makefile.am: Add a simple graph widget drawn using cairo. Disabled by default so we can build on FC4. This is for #333146 so we can draw cool graphs of power stuff. It's all very simple now, but the framework is very easy to expand. * src/gpm-info.c: Load the custom widget. * data/gpm-info.glade: Use the correct creation function name.
Created attachment 60826 [details] [review] Patch to make grid and outline one pixel wide and properly aligned This is what i mean with the 0.5 pixels.
Thanks, I've included that patch. This is what is now in CVS: 2006-03-07 Richard Hughes <richard@hughsie.com> * configure.in: Check for cairo. This is an optional dependency if you want to build the experimental graph support. * data/gpm-info.glade: Don't set the size of the graph in the glade file, instead use the source. * src/gpm-graph-widget.c: Add the patch from Alexander Larsson so we don't antialias the gridlines. Also do lots of misc fixes to make this grid-thing work as it should. * src/gpm-info.c: Make some more stuff generic, and make the graph update every hardware interval. Also free our dynamically allocated memory when the [x] is clicked. This means that is you compile with --enable-experimental-features then you will get the graph. Do not do this on production systems as it's crashed once or twice, probably has spelling errors, and certainly the glade file could do with some HIG love. But it looks way cool. Can you test please, and give me some comments, feedback and patches if you have time. There are loads of hacks and bodges, but it works for me. You'll need a system with cairo, although it will still compile on a system without it (except you won't see the graph...) Give the new CVS g-p-m a few minutes to start the data capture, and then goto the tray menu and select "Information" and click the second tab. The first is blank as I am busy and want to think about how to display the information. The graph will auto-update as the charge changes, but will "lag" significantly. Tell me what you think, and patches welcome :-) Richard.
Richard, this is really sweet! Seems like there is a little problem with expose handling. Try switching workspaces and back. It waits until the next update interval to refresh. It might be a little hard to see the green line at 100% against the white background and the black grid line.
Also probably shouldn't use mnemonics in the tab labels. And how about renaming the second tab to "Charge History" ?
Cheers Jon. Feel free to send me patches or commit directly (any of you guys) if I've made obvious mistakes that you spot, for instance I agree the glade file is crap. It's an experimental option, so we can play with this as much as we like. "charge history" is good for me, for example. Thanks, Richard.
OK, committed this: 2006-03-07 William Jon McCann <mccann@jhu.edu> * data/gpm-info.glade: Don't use mnemonics in notebook labels. Rename second tab to "Charge History". Use HIG border spacing.
Thanks Jon. What other graphs should we display? I was thinking rate against time (second order charge value) which would show how "fast" the battery charges. It's trivial to add in the current code.
I got bored: 2006-03-08 Richard Hughes <richard@hughsie.com> * data/gpm-info.glade: Add the rate and time remaining tabs that use the new graphs. These maybe too much in the UI, but seeing as we get them for free I guess they can't hurt. And they'll be usefull for debugging odd machines. * src/gpm-graph-widget.{c|h}: Allow the axes to be changed, and expose these as part of the public API. Also make sure that lines stay within the bounding box. * src/gpm-info.c: Add in infrastructure so we can monitor more than one data source, and display on multiple graphs. Loads of fixes, additional comments and cleanups. Also use the new window 16x16 icon. Richard.
This works really well and is enabled by default in HEAD. Closing. See http://www.hughsie.com/applications/Coppermine/displayimage.php?album=9&pos=0 for screenshots.