File: TODO

package info (click to toggle)
gmemusage 0.2-10
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, lenny, sarge
  • size: 116 kB
  • ctags: 126
  • sloc: ansic: 1,340; perl: 67; makefile: 63
file content (47 lines) | stat: -rw-r--r-- 2,050 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Here's the wish list:

- Make the stack clickable so that clicing on a process will display
  some details about the process.

- Allow user to switch between core and (core + swap) views. Shouldn't
  be too difficult -- the infrastructure is already in place as far as
  I can make out. Make a command-line option for the same.

- Make a help screen (key "h").

- Fix unbalanced drawables (currently the graphics and text seem to
  prefer to hang around at the bottom of the window).

- Make a better icon/pixmap :)

  Update: I've been sent a pixmap but have not incorporated it yet
  since it'll probably necessitate my learning how to use libXpm. Some 
  time soon...

- The speed delay due to opening and reading files in /proc seems to
  be minimal on my 486/66. However the process does take up a fair
  amount of CPU when it's scanning /proc. Maybe I can find out some
  way of getting these values from the kernel directly.

- sum(RSS) for all procs works out to more than physical memory when
  memory is nearly or completely full. Leave this one for Linus to fix
  :-)

  Update: Apparently Linus is not to blame, it was my understanding of 
  the memory values which was faulty. I am not compensating for shared 
  memory (especially libraries) and hence the values which you see are 
  pretty approximate. Is there someplace on the web which discusses
  process memory usage vis-a-vis the values found in /proc/process-id?

- Get a decent color combination for the bars, labels and background.
  R G B is easy but not particularly beautiful. There's also a new
  pastel color scheme (define USE_PASTELS in the Makefile) though the
  contrast in the colors in that could be better.

- I have reports of gmemusage behaving erratically on systems with
  128Mb of RAM. I forgot to stock up on those this quarter, so any
  inputs will help. The problem is currently under investigation.

- SPARCLinux gmemusage doesn't seem to read the installed system RAM
  correctly. Does stat(/proc/kcore) on SPARCS return something
  different on SPARCS?