Disk usage pie-chart?

[Frankenpod]

Just a suggestion for anyone who could write a plug-in - a way of displaying disk usage akin to how it works on windows (and on Macs I assume!), with a little coloured pie-chart - perhaps with different pie segments for different types of media (video/music/podcasts/free space/etc). 

Or if it's not that easy to differentiate between different types of media for this purpose, it could just show the sizes of the first level of folders (so 'podcasts' folder vs 'music' folder vs 'rockbox' folder, etc).

[__builtin]

This is totally doable. The 'stats' plugin gets all the data that's needed. Just add in a fancy drawing function and... *BOOM*

[Frankenpod]

Though, looking at it, the 'stats' plugin only reports number of files, rather than the disk space they use, so presumably it would need a slightly modified version of that plugin?  Can't be hard to collect size information while counting files though, surely?

Also, file-type I guess wouldn't distinguish between music and podcasts or audiobooks, which is why I was thinking maybe there could be an option of reporting the sizes of the top-level folders - though I don't know how common it is for poeple to organise their media files in 'music' 'podcast' 'audiobooks' folders.

[Frankenpod]

Am very vaguely thinking I might try and implement this myself.  Though I might be being over-ambitious, as am not very skilled at c programming.  But, on the plus side, I don't think its a very demanding project.

Not sure if this is the right forum for the rest of this post, but...

Having installed the rockbox package, and looked at the code for the stats plug-in, it seems as if all it would take is making a modified version to total up the sizes of the files instead of just counting them.  And then another bit of code to draw a pie-chart.

But (and this is how out-of-my-depth I am), I don't know how to get the size of a file. 

Can one call linux system functions from within Rockbox (as I know that's one way to do it), or is that a silly question given the platforms it runs on?  I don't even understand this much - does Rockbox sit on a kind of linux 'layer' when its installed on a DAP or is it a totally stand-alone?

Otherwise does one have to open files and read to the end of them to find out their size?

This is a dumb question, I know, but to be fair, I think that's the only problematic bit of this idea, the rest seems pretty straightforward.

[saratoga]

But (and this is how out-of-my-depth I am), I don't know how to get the size of a file. 

The plugin API struct has a filesize function. 

Can one call linux system functions from within Rockbox (as I know that's one way to do it), or is that a silly question given the platforms it runs on?  I don't even understand this much - does Rockbox sit on a kind of linux 'layer' when its installed on a DAP or is it a totally stand-alone?

No theres no linux system in rockbox, but rockbox does have its own APIs.  Plugins are stricted to the functions exported by the plugin API:

http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/plugin.h;h=f781f60350d79f6438296900f525aa1dda61596c;hb=HEAD#l445

[Frankenpod]

Thanks - I'll give it a go (but don't hold your breath!).  Testing will be the tricky bit - there's an emulator, yes?  Will need to figure out how to get that working.

[saratoga]

Simulator, it doesn't emulate the hardware. Its compiled the same way as a device build except you choose simulator instead of normal build in the configure script.

[__builtin]

Thanks - I'll give it a go (but don't hold your breath!).  Testing will be the tricky bit - there's an emulator, yes?  Will need to figure out how to get that working.

HINT: You'll probably need some trig functions to do the drawing. Look in

Code: [Select]

lib/fixedpoint/fixedpoint.h

for some fixed-point ones.

[saratoga]

Or use a bar chart if you want easy math

[Frankenpod]

Thanks - I'll give it a go (but don't hold your breath!).  Testing will be the tricky bit - there's an emulator, yes?  Will need to figure out how to get that working.

HINT: You'll probably need some trig functions to do the drawing. Look in

Code: [Select]

lib/fixedpoint/fixedpoint.h

for some fixed-point ones.

Cheers!  Probably will indeed need that.  I expect this will take me a while.

[__builtin]

If you need any help, feel free to ask on IRC.
Good luck!

[Frankenpod]

Not on IRC yet, so asking here!

To my surprise, first-draft (text output only) works in the simulator without trouble..despite not quite knowing what I'm doing.

But, have two stumbling blocks...

1/ Is there a rockbox API call to get the total size of the DAP's disk/flash storage?
2/ I'm struggling to understand the rockbox graphics functions - in particular, why is there an _array_ of screen objects, rather than just the one?  Which one do I use to draw graphics on?

Thanks.

Edit - hmm, have gotten a bar chart working, but only by hard-coding the total disk size, as I still can't work out where to get that information from.  Also still haven't quite worked out how to use IRC (never used it before, believe it or not).
Other issue is am not sure about type conversions - adding up disk usage in bytes leads to numbers too large for int or even long int.  Not sure whether to use floats instead or just to round to kb or Mb.

[gevaerts]

1/ Is there a rockbox API call to get the total size of the DAP's disk/flash storage?

No. I suspect you'd have to add this to fat.c and then export it in the plugin api.

2/ I'm struggling to understand the rockbox graphics functions - in particular, why is there an _array_ of screen objects, rather than just the one?

Because there can be more than one screen. Think remotes.

Which one do I use to draw graphics on?

SCREEN_MAIN, usually (unless you want to draw on the remote's screem)

Other issue is am not sure about type conversions - adding up disk usage in bytes leads to numbers too large for int or even long int.  Not sure whether to use floats instead or just to round to kb or Mb.

Going with 512-byte sectors isn't wrong, or you could try to get the FAT cluster size and use that as a unit. It depends on what you want disk usage to mean, actual bytes or used disk blocks.

[__builtin]

Other issue is am not sure about type conversions - adding up disk usage in bytes leads to numbers too large for int or even long int.  Not sure whether to use floats instead or just to round to kb or Mb.

You /could/ try using 64-bit integers (unsigned long long or uint64_t with <stdint.h>).

[Frankenpod]

Other issue is am not sure about type conversions - adding up disk usage in bytes leads to numbers too large for int or even long int.  Not sure whether to use floats instead or just to round to kb or Mb.

You /could/ try using 64-bit integers (unsigned long long or uint64_t with <stdint.h>).

I did consider doing that - nut just, not being at all experienced at this, I wondered what the 'normal' way of dealing with such things would be.  At the moment I just round everything to kb.  Maybe I'll use long long, dunno!