Design of register/memory viewers

[Vladimir Prus]

On Wednesday 31 August 2005 21:55, Gunther Piez wrote:

> > For register view, I have two alternatives:
> > 1. Create another window (near the "variables" view), that would display
> >    registers
> > 2. Show registers in the "variables" view -- add new top-level item, and
> >    make register children of that item.
>
> I would prefer the second way... You probably know you can add registers in
> the watch window via typing $eax or $rax, 

Yea, although KDevelop will show it as pointer, and if you even try to click 
on "+" near $eax things will stop working for me.

> but you have to retype it every 
> time you start the debugging frontend.
> Another point would be a configurable font for at least the watches, since
> the standard font may be to big for a lot of register/variables.

OTOH, you can close "locals" and "watches" items when you're debugging 
assembler code. 

> And if it comes to asm debugging, it would be nice to have configurable
> types for the registers, for example on x86 or amd64 a xmm register might
> hold a v4sf, a v2df or a v16qi or something. But ok, this is a nice to have
> :-)

This can come for free: xmm1 will have several subitems for possible content
types and each subitems will have proper number of children with values.
That will come almost for free.

> > For memory, I can think only about creating another window. It can have
> > "start/end" input boxes just like current memory viewer, or it can have
> > tabs, allowing to view several memory regions at the same time.
>
> If somebody wants to watch more than one memory region, wouldn't it be
> possible for him to use just another view?

If that's a tool window docked to the left side, then you can have only one. 

> More important in my eyes is a configurable type for a memory element. The
> obvious choice is a byte, shown in hexadecimal, but if it possible to
> diplay it in decimal or binary it would be nice. Also, the base type is
> often something different than a byte, and int or a long seems quite
> common. 

So, that would make 8bit/16bit/32bit/64bits size options and 
hex/binary/decimal as format.

> The optimum would let me use a type defined in my program and even 
> let me specify the stride and the amount per line...

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

> And yes, a configurable font size comes in handy when displayng huge
> amounts of data... :-)

Noted.

- Volodya


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