powerapplet_tray 2.3

There have been a couple of reports of my battery tray applet 'powerapplet_tray' not working.

I had expected that the path to examine would be /proc/acpi/battery/BAT0/ or /proc/acpi/battery/BAT1, however the base directory can have other names. Forum member 'peebee' has reported this:

/proc/acpi/battery/C23B/

I have fixed this and bumped the version number to 2.3. Testers are welcome.

Note that it uses the new yaf-splash (gtkdialog-splash) to put up an info box when clicked on. If you want it to work with the old yaf-splash, you will need to modify the source.

PET here (compiled in Wary, with GTK 2.20.1):
http://distro.ibiblio.org/pub/linux/distributions/quirky/pet_packages-wary5/powerapplet_tray-2.3.pet

Source here:
http://bkhome.org/sources/alphabetical/p/
Us#er: pu#p#p#y Pas#swo#rd: li#n#u#x


Posted on 7 Oct 2010, 7:33


Comments:

Posted on 7 Oct 2010, 5:22 by TazOC
network_tray acc rx/tx
Thanks for the updated powerapplet_tray. Can't test myself, because I don't have a notebook/laptop.

I changed the following type definitions in the source of network_tray-2.4.2 from long int to long long int to support >2.1 GiB accumulated rx/tx:
rxacc rxaccprev rxmonth rxaccmonth_updated
txacc txaccprev txmonth txaccmonth_updated.

This is due to the limits of 32-bit data types; (probably OK as is for compiling in 64-bit.)
http://en.wikipedia.org/wiki/Limits.h#Member_constants
Not sure if anyone needs to track such large amounts of bandwidth, but just in case...


Posted on 7 Oct 2010, 6:07 by peebee
Success report
Thanks Barry
Can confirm that I have installed into wary070, lupu511 and dpup009 and all seem to work AOK on my HP550 laptop.
Many thanks
Peter
(peebee)


Posted on 7 Oct 2010, 7:29 by BarryK
Re long int
TazOC,
I thought that int would be 32-bit and long int 64-bit in Gnu C on a 32-bit x86 CPU.

Oh, I just ran a little test program, size in bytes, using sizeof() function:

int 4
long int 4
long long int 8

...C sure is weird!



Posted on 7 Oct 2010, 12:05 by lwill
K&R int definition
According to my K&R (ANSI) C book:
"char - a single byte, capable of holding one character in the local character set
int - an integer, typically reflecting the natural size of integers on the host machine."
"..int will normally be the natural size for a particular machine. short is often 16 bits, long 32 bits and int either 16 or 32 bits. Each compiler is free to choose appropriate sizes for its own hardware, subject only to the restriction that shorts and ints are at least 16 bits, long are at least 32 bits and short is no longer than int, which is no longer than long."

So it is conceivable that on a 64 bit machine, int, long int, and long long int could all be the same.(64 bits?)

As a side note on speed, I was taught (on an 8-bit system) to use char when possible since it took the fewest machine cycles to fetch one memory location (byte) and took the least space. I found out a while back this is not true on 16+ bit systems, that it is better to use int, especially when accessing memory locations directly (like an array). Since char is always 8 bits, and modern memory is 16+ bits wide, either the compiler has to place multiple chars in one memory "physical location" (not necessarily address) shifting them in and out, or one char will take up a full physical location. The latter will actually place the chars more than a byte apart in memory so when stepping through it takes more machine cycles to find each byte. (I had this problem when mixing assembler and C in an interrupt, the C compiler automatically adjusted, but my assembler code kept getting zeroes every other read) It turned out that it is generally faster (and safer) to use int since it is natural to the memory size of the hardware and should always take the fewest cycles. (I read this in an article about optimization)
Hope this helps clarify and is useful in the future.
(forgive me if my use of terms is not accurate, I only play a programmer on TV )


Posted on 7 Oct 2010, 12:11 by lwill
K&R int definition (note cont.)
One note about what I said on using int, it does not apply if you are relying on type checking and do not want to mix chars with ints.


Posted on 7 Oct 2010, 12:39 by TazOC
long int
int 4
long int 4
long long int 8

...C sure is weird!

Yes, that is weird, Barry. I'm just a C newbie, experimenting a bit with the source I come across. Never even compiled anything myself until I got into Puppy.

So I was trying to figure out why the value in my /var/local/sns/rx_bytes_month was much larger (after converting to MiB) than the tooltip of network_tray, stumbled on the Wikipedia page and kinda put 2 and 2 together...


Posted on 7 Oct 2010, 22:11 by lwill
int, long int again
This AM I had a "DUH" moment.
Doesn't matter what type of machine. The types describe the greatest number or precision the variable can hold.
char 0-255
int 0-65535
long 0-2^32
long long 0-2^64

Hope this is clearer.