freememapplet_tray v2.8.6 and v2.8.6f - includes source

[gyro]

Edit 24 Sep 2015:
Added version 2.8.6f, an alternate that displays "free" instead of "avilable".

Edit 19 Sep 2015:
After much testing by a few, significant suggestions by 01micko, and many versions, here is the final release of this project, (except for bugs, of couse).
Attached is freememapplet-2.8.6.tar.gz.

What's changed:
1) Much of the code has been rewritten to use gtk libraries.
2) It now should be more robust against unforeseen environment changes.
3) It now exits with a message on stdout if it can't do anything sensible. So if it exits without showing in the tray, run it in a console window to see the message which will hopefully provide a clue.
4) It now clearly shows that it's sizes are in "MiB" and "GiB".
5) It now contains 01micko's recognition of savefiles, and adjusts it's message and menu.
6) It now contains 01micko' right click menu, which always provides a "Quit" option and a "Resize personal storage" option if it recognises the use of a savefile.

This code has been tested in pupmodes 2, 5, 12, and 13.

If it seems an odd format, i.e. not a .pet or a .sfs, it's because I'm handing it back in a format similar to the one I got in "freememapplet_tray-2.5.tar.bz2".
I guess it's more designed for puppy makers rather than users.

The binaries it contains are compiled in Tahrpup 6.0.3 and Tahrpup64 6.0.3.7.
For many other puppies the "compile" script will need to be run to produce a "freememapplet_tray" binary and a "freememapplet_tray.pot".
The binary usually resides in "/usr/bin/".
The .pot usually resides in "/usr/share/doc/nls/freememapplet_tray/".
The .svg files usually reside in "/usr/share/pixmaps/puppy/"

gyro

Original post follows:
I thought I might as well share this code.
It's a rewrite of freememapplet_tray-2.5.tar.bz2.
The gtk stuff has been left as is, but the rest of the code has been replaced.
It contains both 32bit and 64bit binaries.

Edit: Attached an updated version 2.7.1. Just a small change to tidy the code a little bit.

Edit2: Attached an updated version 2.7.2. A 1 line change to the "compile" script so that it works on tahrpup.

Edit3: Attached an updated version 2.7.3. Increased the size of the internal string buffers.

Edit4: Attached an updated version 2.7.4. This one uses gtk for string manipulation, instead of native C.

Edit5: Attached an updated version 2.7.5, no change in functionality.
Version 2.7.3 and version 2.7.4 have been withdrawn.
Attached a new version 2.8.0, this includes new functionality, i.e. 01micko's right click menu.

Edit6: Attached updated version 2.7.6 and version 2.8.1.
Version 2.7.6 has only some internal coding changes.
Version 2.8.1 includes 01micko's improved menu.

Edit7: Attached updated version 2.8.2, focuses on robustness in even unlikely cases, and 01micko's fix to the translatable messages.

Edit8: Minor fix to improve resilience against malformed "SAVE_LAYER" line in PUPSTATE.

Edit9: v2.8.4 Added a bit more validation of the input from PUPSTATE

gyro

[musher0]

I thought I might as well share this code.
It's a rewrite of freememapplet_tray.
The gtk stuff has been left as is, but the rest of the code has been replaced.
It contains both 32bit and 64bit binaries.

gyro

Hi, gyro.

Looks interesting. Can you explain a little more for us mere mortals? What
computer language did you use? What is 'statfs'? Is this one bigger, smaller, faster,
more efficient, etc., than the old one? Were you unhappy with the old one, or was
this for you only an "exercise" that turned out really well?

Thanks in advance.

musher0

[gyro]

What computer language did you use?
What is 'statfs'?
Is this one bigger, smaller, faster, more efficient, etc., than the old one?
Were you unhappy with the old one, or was this for you only an "exercise" that turned out really well?

C.
A system function callable from C.
Source smaller, my binary bigger, but might be more efficient, all done "entirely in C code...".
The old one had to be recompiled anyway for "savefolder using symbolic links", and the old one crashes if "df" returns nothing. I expect this version to be more robust, should the environment change again.
Started as "exercise" prompted by the following line in the original:

Code: Select all

    //would prefer to do this entirely in C code..

so, I did.

Note: Even a mere mortal could probably have gleaned much of the above information by downloading and reading the source provided.

gyro

[musher0]

Oops. Sorry if my interview-type questions offended you.
But this mere mortal thanks you anyway! Trying it now.

[gyro]

Warning, the "compile" script in the package produces compile errors on tahrpup. Haven't worked out why.
The good news is that a binary compiled on Dpup Squeeze or a binary compiled on Slacko 5.9.3, works fine on tahrpup. (May be able to sucessfully compile on other puppies but these are the 2 I have tried.)

Edit: Actually I think they are link errors on tahrpup.

Sorry about not including this information in the first post. I actually did this stuff a little while ago and had forgotten.

The binary in the package "freememapplet_tray32" was compiled on Dpup Squeeze, seems to run ok on many 32 bit puppies.
The binary in the package "freememapplet_tray64" was compiled on Slacko64, also runs ok on Tahr64.

gyro

[gyro]

This is a very small tidy of the C code.
Here is a diff:

Code: Select all

--- freememapplet_tray_prev.c	2015-01-19 05:41:13.627448296 +1000
+++ freememapplet_tray.c	2015-01-19 05:38:56.378659149 +1000
@@ -66,8 +66,8 @@
 gboolean Update(gpointer ptr) {
 	
     //read free personal storage...
-	sizetotal = sizefree = 0;
-	getFileSystemData(save_layer_dir);
+	if (getFileSystemData(save_layer_dir) != 0)
+		sizetotal = sizefree = 0;
 
     if (sizefreeprev == sizefree) return; //unchanged.
     sizefreeprev=sizefree;

It doesn't really change what happens, I just think it's a bit more obvious.

Both versions should work exactly the same. So if you just want something that works, the binaries in 2.7 should work just as well as the binaries in 2.7.1.
But if you intend to compile the C code then I would suggest you download version 2.7.1.

It is attached to the first post, download it from there.

gyro

[gyro]

Sorry if my interview-type questions offended you.
But this mere mortal thanks you anyway!

Thankyou.
But I think "offended" is too strong a word, more like "exasperated".
My initial reaction to your first question was: "If this person can't be bothered to even look at it, why should I be bothered to spend some of my 'hobby time' to provide an answer."
gyro

[musher0]

Sorry if my interview-type questions offended you.
But this mere mortal thanks you anyway!

Thankyou.
But I think "offended" is too strong a word, more like "exasperated".
My initial reaction to your first question was: "If this person can't be bothered to even look at it, why should I be bothered to spend some of my 'hobby time' to provide an answer."
gyro

Hello, gyro.

I just happen to be the type of person who needs a lot of convincing!

Speaking of which , I'm not convinced your implementation reacts as fast as the old
one. I'm not a C programmer, mind you, just a bash scripter. I did a major cleanup of
my pupsave yesterday with both freememtrays on, and the older one seemed to react
faster to my deletes than yours.

As well, the numbers in both old and new freememstrays did not seem to agree with
the results provided by the corresponding code in conky (I mean the following conky code).

Code: Select all

${fs_used /mnt/home} / ${fs_size /mnt/home}

freememtray says: 1.2G total minus 990M free. That equals to: 210M occupied in the
pupsave file.

conky says 270M occupied on 1.23G. Which leaves 960M free.

Somebody is off 60M! With so much free space in my poupsave, it's not that I need
an exact figure at the moment, but it's sure confusing!

BFN.

musher0

[gyro]

Hi musher0,

Thanks for testing.

I make no claims about the speed of this code. Though I do think from a C code point of view, it is more robust.

Regarding the perceived difference in responsiveness, that is a little unexpected. Neither version controls when it does something, they register a callback routine with gtk, which gtk calls when it decides they need to do something. Perhaps running both at once is clouding your result. (Either way I have no interest in trying to improve the speed of this code.)

Different numbers for the same partition, from different applications:
Some differences could be due to different rounding when converting from Kbytes to Mbytes or Gbytes. This freememapplet_tray does no rounding, so integer values are usually a bit lower than actual, e.g. 57.2 becomes 57, 57.9 becomes 57. This is based on the idea that it's safer to underestimate the amount of free space.
Other differences could be due to different interpretations of what a Mbyte or Gbyte is. For this freememapplet_tray a Kbyte is 1024, a Mbyte is 1024*1024, and a Gbyte is 1024*1024*1024.
The only way to get consistency is to use a standard source for the Kbytes and a standard interpretation of the size of Mbyte and Gbyte.

Note: I don't run freememapplet_tray any more. Since I use 'savefolder' on all my puppies, I'm not paranoid about the free space in "pup_rw" any more.

gyro

[musher0]

Many thanks for the clarifications. BFN.

[gyro]

Sorry about changing things so soon, but hopefully this is the last one.

It's just a 1 line change to the "compile" script:

Code: Select all

--- compile.orig	2012-05-19 20:06:11.000000000 +1000
+++ compile	2015-01-19 22:50:23.822671234 +1000
@@ -3,7 +3,7 @@
 rm -f freememapplet_tray
 rm -f freememapplet_tray.pot
 
-gcc `pkg-config --cflags --libs gtk+-2.0` freememapplet_tray.c -o freememapplet_tray
+gcc freememapplet_tray.c `pkg-config --cflags --libs gtk+-2.0` -o freememapplet_tray
 
 xgettext --keyword="_" freememapplet_tray.c  -o freememapplet_tray.pot
 

Now it works on tahrpup. I suspect the problem was simply a newer version of gcc.
"freememapplet-2.5.tar.bz2" might have a similar problem. If so, this patched "compile" could be used there.

File attached to first post, download from there.

gyro

[gyro]

The only change is to increase the size of the internal string buffers.

The file is attached to the first post.

gyro

[ASRI éducation]

Hello,

Note 1: I am surprised that the 2.7.3 version of gyro is not more downloaded, it still offers full compatibility with pupsave records.

Note 2: I tested the 2.7.3 version with a base Precise v5.7.1 + woof-ce-20150611. When I right-click on the icon in the taskbar, nothing happens (no popup menu), is it normal?

Regards,

[ASRI éducation]

Note 2: I tested the 2.7.3 version with a base Precise v5.7.1 + woof-ce-20150611. When I right-click on the icon in the taskbar, nothing happens (no popup menu), is it normal?

No answer...

[01micko]

When I right-click on the icon in the taskbar, nothing happens (no popup menu), is it normal?

Yes, normal; no right-click menu. Has been like that for some time.

[ASRI éducation]

When I right-click on the icon in the taskbar, nothing happens (no popup menu), is it normal?

Yes, normal; no right-click menu. Has been like that for some time.

Is it a choice, or a coding problem?

[01micko]

When I right-click on the icon in the taskbar, nothing happens (no popup menu), is it normal?

Yes, normal; no right-click menu. Has been like that for some time.

Is it a choice, or a coding problem?

It's a design choice. What goes into a right-click for that anyway? On left-click we get a pop-up with relevant drive usage and a bit of extra kernel and version information. I think that's enough.

[ASRI éducation]

It's a design choice. What goes into a right-click for that anyway? On left-click we get a pop-up with relevant drive usage and a bit of extra kernel and version information. I think that's enough.

OK.
Thanks for the answer.
Regards,

[gyro]

Slightly concerned that some of the native C string manipulation in v2.7.3 is a little hairy.
So changed it to use the richer functionality of "gchar" from gtk.
Like the previous versions it contains both 32 bit and 64 bit binaries.
The 32 bit, was compiled in Tahrpup 6.0.3.
The 64 bit was compiled in Tahrpup64 6.0.3.5.

I've no idea if it's faster or slower, I did it so I'm sharing it.

gyro

[musher0]

Nope. 32-bit version not working on this upupRaring-3.9.9.2...