[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display



> This could readilly enough be remedied by providing a command-line
> option, --clip-at=n, to tell xload to not try to display any load
> level above n.  More fancy solutions are possible.

closer inspection of the man page suggests this could be implemented as
an optional second value for -scale:

   -scale integer[,integer]
       This option controls the number of tick marks in the histogram,
       where one division represents one load average point.  If the
       load goes above the first number, xload shall create more
       divisions, but it shall never use fewer than this number.  The
       default is 1.  If the second number is supplied, xload shall not
       create more than this many divisions; if load goes above this
       value, the histogram shall be clipped.  The default is to always
       have enough divisions to display the highest load seen during the
       displayed time interval.

or similar.  I also notice that the man page says:

   -jumpscroll number of pixels
       The number of pixels to shift the graph to the left when the
       graph reaches the right edge of the window.  The default value is
       1/2 the width of the current window.  Smooth scrolling can be
       achieved by setting it to 1.

I do not pass this argument, but get smooth scrolling as if I were
setting it to 1.  I have never seen the graph shift to the right by half
the width of the window.  Given that I like the smooth scrolling effect,
I'd argue for changing the documentation to match the observed behaviour ;->

	Eddy.



Reply to: