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

2007-08-10 Thread Brice Goglin
Edward Welbourne wrote:
 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:

   

Unfortunately, most tiny X programs like this one usually don't get much
maintenance. So you should probably try to come with a patch if you
really want this to be implemented :/

Brice



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2007-08-10 Thread Edward Welbourne
 Unfortunately, most tiny X programs like this one usually don't get much
 maintenance. So you should probably try to come with a patch if you
 really want this to be implemented :/

Fair enough.  If I find the time ...

Eddy.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2007-07-12 Thread Edward Welbourne
Package: x11-apps
Version: 0.1
Severity: wishlist
File: /usr/bin/xload


The vertical scale of xload adjusts to accommodate the highest load level.
It has horizontal lines to indicate the vertical scale.

A high enough load shall cause these lines to be so closely spaced
that there is no space between them: the entire display is then white
(I have reverse video set, so the background is black and scale lines
are white) and I can no longer see the load varying, on account of the
lines.  Modern machines can endure quite immense loads, so this
problem can readilly arise (I routinely get it when running make -j -l
12, if some of the processes make first fires off do very vigorous
things once started).  The machine is happy, but xload becomes useless !

If the load has a transient spike, the vertical scale adapts to let
the spike's top be displayed: if the spike is high enough, xload
becomes useless until the spike has scrolled off the left hand end -
or until I kill it and start a fresh xload, losing all the data that
was on display for the prior four hours (yes, xload is almost the full
width of my screen).

Note that setting the foreground colour of xload doesn't help: the
grid lines are drawn on top of the load data, so would hide it.

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.

It may be sufficient simply to draw the load data on top of the scale
lines; then -foreground=red would suffice to make the load graph's
shape visible, even when the scale lines are so closely packed as to
form a featureless background (giving no indication of scale - other
than OMG that's high !).

If the vertical scale is huge enough that the horizontal lines use up
more than (say) half of the pixels available for vertical height (at
this point, it's possible - but getting hard - to read the display),
xload could drop the granularity of its vertical scale; only display
one in 10 of the horizontal lines, for example.  Naturally, this would
require some way to indicate that the scale has been adjusted;
e.g. the load-level difference between horizontal lines could be
displayed in the top left corner of the chart.  Of course, the value
of 10 (the base of the number system in use) could be controlled by a
command-line parameter; or it could just be hard-coded to ten or 0x10.

Alternatively, the horizontal lines could be dashed, with multiples of
10 using longer dashes (and multiples of 100 using longer ones yet).
The dashes for adjacent values should be staggered, so that they don't
simply from a solid vertical column (hiding data in the interval it
spans).

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages x11-apps depends on:
ii  cpp   4:4.1.1-15 The GNU C preprocessor (cpp)
ii  libc6 2.5-9+b1   GNU C Library: Shared libraries
ii  libfontconfig12.4.2-1.2  generic font configuration library
ii  libice6   1:1.0.3-2  X11 Inter-Client Exchange library
ii  libpng12-01.2.15~beta5-2 PNG library - runtime
ii  libsm62:1.0.3-1  X11 Session Management library
ii  libx11-6  2:1.0.3-7  X11 client-side library
ii  libxaw7   1:1.0.3-3  X11 Athena Widget library
ii  libxcursor1   1:1.1.8-2  X cursor management library
ii  libxext6  1:1.0.3-2  X11 miscellaneous extension librar
ii  libxft2   2.1.12-2   FreeType-based font drawing librar
ii  libxkbfile1   1:1.0.4-1  X11 keyboard file manipulation lib
ii  libxmu6   1:1.0.3-1  X11 miscellaneous utility library
ii  libxmuu1  1:1.0.3-1  X11 miscellaneous micro-utility li
ii  libxrender1   1:0.9.2-1  X Rendering Extension client libra
ii  libxt61:1.0.5-3  X11 toolkit intrinsics library
ii  x11-common1:7.2-5X Window System (X.Org) infrastruc

x11-apps recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2007-07-12 Thread Edward Welbourne
 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.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2007-07-12 Thread Julien Cristau
On Thu, Jul 12, 2007 at 15:04:11 +0200, Edward Welbourne wrote:

-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 ;-
 
See /etc/X11/app-defaults/XLoad, it has *JumpScroll: 1 which explains
the behaviour you observe ;)

Cheers,
Julien


signature.asc
Description: Digital signature