Flit: an FLTK-native "tray" with clock, sound control, and battery monitor

[MikeLockmoore]

roberts: The "present rate:            0 mA" could lead to a divide-by-zero, messing up the math.  Boy, those Dell Mini 9's barely use power, huh?

Flit tries to average and smooth the battery discharging rate to make the remaining time estimates more steady.  However, if the ACPI driver is not populating the rate line with a real number, the average rate is also meaningless.  I think I'll enhance the Flit code to derive the rate from the change in remaining capacity over time, if the recent average of the reported rates is zero.
--
Mike

[MikeLockmoore]

OK, I think I have a fix for roberts' situation of an misleading 'present rate' field in the ACPI battery state pseudo-file.  As I hinted at in the previous comment, Version 0.9.3 of Flit can calculate an effective charging or discharging rate by looking at the overall change in stored charge over time. 

Also made minor changes in the help file and merged in roberts' changed location of the help file (/usr/share/doc/tc/flit_help.htm).

[roberts]

The hours remaining varies widely, so I don't know how useful it is.
Upon first bootiing, 90% battery displays 2,752 hours remaining!
Then after a short wait, 3hr + mins, a short wait then reports 5hr + min, much later
at 79% it is reporting 4 hours and 7 mins. I get about 4hr when at 100%.

The percentage seems accurate, the hours remaining varies too much to be useful and is too high.
I wonder, if when present rate is not supported,  the popup hours remaining should just be skipped?

On an ASUS S101 netbook, it works extremely well.

[jpeters]

The hours remaining varies widely, so I don't know how useful it is.
Upon first bootiing, 90% battery displays 2,752 hours remaining!
Then after a short wait, 3hr + mins, a short wait then reports 5hr + min, much later
at 79% it is reporting 4 hours and 7 mins. I get about 4hr when at 100%.

The percentage seems accurate, the hours remaining varies too much to be useful and is too high.

....must have been formulated by an economist

[bmarkus]

Just a side note regarding the accuracy of the remaing time. It is worth to read the 'Motivation' section at the Intelligent Battery Monitor page:

"Most battery monitors rely on the data provided by the underlying power management system, which in most cases is quite inaccurate for many reasons: Batteries are non-linear, the capacities are wearing off, and among others the actual power usage is highly individual. As rechargable batteries expose a steep voltage drop at low capacity remaining, it is quite common and very annoying, that the reported time remaining is far larger than the actual time that is left to save your data."

BTW, ibam.tce & ibam.tcz are in the 2.x repo.

[jemimah]

I'm currently tinkering with flwm on puppy linux and had the same problem with there being no clock or battery meter.  I compiled flit and it works well, except the sound control segfaults.

Anyway, I was thinking: flwm already supports a clock in the active title bar, it would be trivial to add a battery percent readout in the same place.  You can fix flwm not to display the title in the active window, so the title does write over your clock and battery status.  The cool about doing it that way is you can always see the clock and battery status, and it wastes no screen real-estate, which stays in line with the flwm philosophy. 

[MikeLockmoore]

roberts: you are right about the rate being wrong.  Due to a mental blunder, I put in the wrong scaling factor in the effective rate calculation.  There are 12 battery state samples per second, not 10 like I assumed last night (I blame "coding while tired"   ).  So the correct conversion factors for the discharging and charging rate should be 720 (samples per hour), not 600.  You can manually patch your code around lines 710 and 735 with the new factor or try the new version 0.9.4 attached here. 

This fix won't help the very unrealistic initial estimates (for the first two or three minutes) when you switch between charging and discharging, or vice-versa.  As bmarkus points out, simple kinds of estimates using the ACPI values are fairly bad.  I may move to more of a "learning" approach where a few observational parameters are stored in the .flit.conf file, so the accuracy should improve over time (multiple charge and discharge cycles), and we can avoid the initially unrealistic results.

jemimah: I'm a Puppy user too, but over the last few months, I'm mostly using TC, which is frugally installed in my Puppy partition.  Anyway, I'm not targeting JWM or Puppy specifically right now, so changes to better support such use are likely to be deferred, but if I can make a simple change to prevent a segfault, I'll try to do that.  Can you provide a few more details about your Puppy environment and what you did exactly in Flit that led to a segfault?  Doesn't Puppy use ALSA for sound?

ALSA should be able to be supported by using amixer (or whatever it is called) in the same way that my earlier Flit versions did with ossmix, but I have a bunch of other things I plan to work on first.  If you are a coder and want to try to add ALSA support, I would consider merging it into my releases.

As for the clock in flwm, I've never tried flwm configured with that option, so I don't know first-hand how that would work, but I strongly suspect that with the normal left-side title bars, there is not enough room for the title and a clock and a battery read-out.  Ususally, there is not enough room for the full title itself!  Maybe if I get the "topside titlebar" version of flwm working, it could be considered.

--
Mike L.

[roberts]

Mike, seems much more reasonable now. Thanks.

[roberts]

Regarding merging flit into Ttitle bar:
I personally do not like launching many daemons.
I still wear a wristwatch, which far more accurate than a PC clock.
For battery it is nice, especially laptops/netbooks.
Actually, I would rather see daemons lauched from the control panel, or /opt/bootlocal.sh.
That way, the user has the choice on how to use their CPU cycles and memory.

EDIT: Of course, flit could just be offered as an extension and then it can grow to be as fancy and as large as desired.

[robc]

I'm having problems with the show/hide sound option. When I try to hide the sound it doesn't go away, instead it covers half the clock. It will go away if I choose to hide the clock and the sound, but will reappear over the clock if I choose to show the clock.

Also the key bindings only work if the right click menu is up.

I don't have OSS or alsa loaded if that would matter.

This is on TC 2.3 with flwm.

[alu]

same here with evilwm as mentioned in my post on page 3; meanwhile i have understand that date shows up as popup, very nice.

[MikeLockmoore]

robc: Thanks for the report.  I'll have to test it with no OSS too and try to duplicate the show/hide bug.

As far as the keybindings, yes, the "Alt + (whatever)" key bindings only work if the menu is up.  I may try to automatically open the menu as soon as the alt key is pressed, or maybe I will just make the key combos work the same without the menu is popping up. 

I'm still learning good ways to make various things happen in FLTK. 
--
ML

[robc]

do you need to have the menu open to capture keys in FLTK? I'm not too familiar with FLTK but you should only need the focus in order to register keys... I just see it more useful to have the key bindings available without the need to right click, I would understand needing a focus though as to not interfere with other apps. Plus it would be nice to be able to use the bindings when a mouse isn't present.

It looks though, a great addition to TC 

[MikeLockmoore]

robc: FLTK's menu auto-magically makes key-bindings work if you initialize the menu structure with the right text strings.  But, as you have seen, this only works when the menus are open.  It is true that an FLTK app can react to all kinds of key events, so nothing in principle prevents it from having the same key bindings without the menu being open, it just takes some more code.  But perhaps there is an easier way in FLTK... like an "accelerator" resource in the Win32 API.  For the sound control, Flit already reacts to a few different keys.  I can add more of the key bindings at some point.
--
ML

[MikeLockmoore]

New version 0.9.5 offers three significant changes:
1) Sound applet cannot be "unhidden" if OSS is not present, so the bug reported by robc should be prevented.  If you try to unhide the sound applet, Flit will warn you if OSS is not found.

2) Battery charge/discharge time estimates are not shown for three minutes after a change in status, preventing unrealistic estimates appearing.

3) Either Alt key automatically pops up the menu, making keyboard use easier.  Maybe not as elegant as menu-less keybinding, but it is less code (keeping Flit a bit smaller).