[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop
Subject:    Re: Design of register/memory viewers
From:       Gunther Piez <gpiez () web ! de>
Date:       2005-09-01 7:43:40
Message-ID: 200509010943.41281.gpiez () web ! de
[Download RAW message or body]

Am Donnerstag 01 September 2005 08:40 schrieb Vladimir Prus:

> Can you explain? The amount per line should ideally depend on window \
> width.

If you use a memory view, it's often because you want to watch some big \
array  (at least for me) which is to clumsy to handle in a watch window. If \
the  array has more than on dimension, lets say int[][16], the natural data \
 display width would be 16 ints, a not depending on the width of the \
window.  But if no value for the data width is given (the default), make it \
whatever  fits in the window.
Also it happens, that an array is sparsely filled. Maybe its an array of \
ints,  but the values in the array have only a range of 0-100. So watching \
an array  of bytes with every other three bytes left out would be \
sufficient and  conserve some space. Or you have an int[][16], of which \
only the values int[] [0..9] are used (Choosing powers of 2 as a sub index \
happens quite often for  perfomance reasons). I this case you want to show \
10 ints, and hide 6. Or an  array of a struct, which is 9 bytes long and 16 \
byte aligned for each  element.
One would need two more numbers to make it possible to configure this \
flexible  enough, one for the number of bytes to show and one for the \
number of bytes  to hide.
So for example, you could have a display width 64 bytes width, but only the \
 one byte seen and every other three bytes hidden. This would display 16 \
bytes  per line, eating up an amount of 48 chars width.

Gunther

-
to unsubscribe from this list send an email to \
kdevelop-request@kdevelop.org with the following body: unsubscribe \
»your-email-address«


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic