Recent

Author Topic: Poll: Watches and DisplayFormat => How do you think data should be displayed  (Read 12791 times)

440bx

  • Hero Member
  • *****
  • Posts: 4202
Another thought about the formatting...

Currently in the Watches window, when a record is being watched, the address of the record is included in the output - which is very nice for those who are doing low level debugging.

It would also be very nice if the address did _not_ include all the leading zeroes.  Those leading zeroes waste space and don't bring anything to the table except making the value of the address harder to read.

Visually, this is what I'd like:
Code: Text  [Select][+][-]
  1. { CURRENT format                                                              }
  2.  
  3. InoutContext $000000000102F448^: (INSTRUCTION: $000000000102FAA8^: (); OPERANDS: $000000000102F788^: (); OPERAND: $000000000102F788^: (); RUNTIME_ADDRESS: 756604737385660416; USER_DATA: POINTER(nil);)
  4.  
  5. InoutContext $102F448^:          (INSTRUCTION: $102FAA8^:          (); OPERANDS: $102F788^:          (); OPERAND: $102F788^:          (); RUNTIME_ADDRESS: 756604737385660416; USER_DATA: POINTER(nil);)
  6.  
  7. { DESIRED format                                                              }
  8.  
  9. InoutContext $102F448^: (INSTRUCTION: $102FAA8^: (); OPERANDS: $102F788^: (); OPERAND: $102F788^: (); RUNTIME_ADDRESS: 756604737385660416; USER_DATA: POINTER(nil);)
  10.  
The second line is there only to show how much space all those zeroes waste.

It could be an on/off option, just in case someone likes to see all those zeroes. ;)


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
Currently in the Watches window, when a record is being watched, the address of the record is included in the output - which is very nice for those who are doing low level debugging.

It would also be very nice if the address did _not_ include all the leading zeroes.  Those leading zeroes waste space and don't bring anything to the table except making the value of the address harder to read.

That are probably pointer to record, or object-instances. flat nested records should show data IIRC. But that is beside the point.

Yes, that would be an option. Currently hex and bin show the full width of the data type => that can be useful to explicit show that those are zero (e.g.:set of enum), or to just know if one looks at a word, dword, or qword. But not to show them can be valid too.

Currently, I am racking my brain how to make the watch properties more user friendly. Especially the "all" page. Probably reduce "all" to a smaller set, and have the rest on dedicated pages only (there may be more pages too ...).
But also the repeated word "default" conveys too little info...

440bx

  • Hero Member
  • *****
  • Posts: 4202
Currently, I am racking my brain how to make the watch properties more user friendly. Especially the "all" page. Probably reduce "all" to a smaller set, and have the rest on dedicated pages only (there may be more pages too ...).
But also the repeated word "default" conveys too little info...
I'm using Lazarus v3.2... I didn't see an "all" page... did I miss it or is it a page that is only available in the trunk version ?
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
I'm using Lazarus v3.2... I didn't see an "all" page... did I miss it or is it a page that is only available in the trunk version ?

Trunk only. (lots of new switches for the display format)

440bx

  • Hero Member
  • *****
  • Posts: 4202
I updated one of the Lazarus trunk installations I had.

At this time and, as far as formatting goes, I'd like the formatting of the right hand pane (which opens with a little button on the toolbar)  to match the formatting of the left hand pane.

Currently, the formatting is different, it starts like it is on the left hand pane but eventually gets messed up (jumbled, hard to read.)

Attached is an example of the formatting mismatch "problem" (notice the different formatting and the jumbled data midway.)

Totally unrelated to formatting but, definitely important.  the little button that opens the right hand pane is right next to the "delete all" button and the "delete all" button doesn't give second chances, you click that button and all your watches are instantly gone.  This can be quite a bummer when watching a number of complex expressions that vanished because of clicking the wrong button.  It would be rather convenient if the "delete all" button prompted the user for "are you sure you want to delete all your watches ? (_no_ undoing that!)

Thanks :)

PS: I looked at the "all" page and, I can see it's not easy to streamline all those options.  If I eventually have an idea, I'll share it.

ETA:

Normally a "delete all" button is an icon that consists of a big _red_ X.   The current "delete all" icon can easily be confused with an "additional details" or whathaveyou icon including opening the right hand pane.  I would be rather pleased to see a big red X icon there instead of the little paintbrush (or whatever that thing is) to annihilate the watches.
« Last Edit: March 17, 2024, 04:29:28 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
I updated one of the Lazarus trunk installations I had.
At this time and, as far as formatting goes, I'd like the formatting of the right hand pane (which opens with a little button on the toolbar)  to match the formatting of the left hand pane.
Currently, the formatting is different, it starts like it is on the left hand pane but eventually gets messed up (jumbled, hard to read.)
That pane has been there for many versions....
It actually pre-dates the ability of expanding watches. So when a TForm watch was a single line, and you couldn't see any fields => that was a solution.
Now, it still can make a difference for a small(er) set of watches, where subtle formatting differences are helpful. (and for mem dumps, until they can expand too).


From a precursory look the "jumbling" happens due to word wrap.
Only the outer structure has a new line for each field. The nested structure form a long long line (and wraps).

Depending on the use-case I can see 2 options.
- Allow to disable word wrap (and have a horizontal scrollbar)
- Insert new lines (and then indent) for nested structures (up to some level of nesting...). That does space out the outer structure.

E.g. the latter is less preferable, if you have
Code: Pascal  [Select][+][-]
  1. MyData: record a,b,c,d,e: TPoint; end;
The TPoint will look a lot better if they are one line each.


At the moment this memo is not custom painted, that is the formatting of the text is not affected by the size of the memo. The formatter isn't told, there are N chars per line (and I am not sure, the font may not even be monospaced).
Though (the option of) a monospaced font, could allow for aligned formatting. (but that would probably only happen if/when wordwrap is off / when there is a horizontal scrollbar)

Quote
Totally unrelated to formatting but, definitely important.  the little button that opens the right hand pane is right next to the "delete all" button and the "delete all" button doesn't give second chances, you click that button and all your watches are instantly gone.  This can be quite a bummer when watching a number of complex expressions that vanished because of clicking the wrong button.  It would be rather convenient if the "delete all" button prompted the user for "are you sure you want to delete all your watches ? (_no_ undoing that!)
+1

Quote
Normally a "delete all" button is an icon that consists of a big _red_ X.   The current "delete all" icon can easily be confused with an "additional details" or whathaveyou icon including opening the right hand pane.  I would be rather pleased to see a big red X icon there instead of the little paintbrush (or whatever that thing is) to annihilate the watches.
The brush is used in various places.... But still, noted.

VisualLab

  • Sr. Member
  • ****
  • Posts: 355
Quote
Normally a "delete all" button is an icon that consists of a big _red_ X.   The current "delete all" icon can easily be confused with an "additional details" or whathaveyou icon including opening the right hand pane.  I would be rather pleased to see a big red X icon there instead of the little paintbrush (or whatever that thing is) to annihilate the watches.
The brush is used in various places.... But still, noted.

I am also in favor of changing the icon (glyph) from a brush (broom?) to a large red X. It is much more readable.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
Generally, I am in favour of changing the icon. However, a single X usually kills one item. For a list, there could be several X (the search result window has some stuff build on that, but very specialized).

There could be a brush/X combination....
Or like the "Close all" has pages with an X, the debug windows could hove some "item list" with an X.

Or, well, maybe check what else is used throughout the IDE. Before inventing something new...

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
The "delete all" icon has been changed. A confirm dialog was added. Both in 3.99

440bx

  • Hero Member
  • *****
  • Posts: 4202
The "delete all" icon has been changed. A confirm dialog was added. Both in 3.99
That's great... thank you :)  will have a look at the new trunk soon.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
Currently, I am racking my brain how to make the watch properties more user friendly. Especially the "all" page. Probably reduce "all" to a smaller set, and have the rest on dedicated pages only (there may be more pages too ...).

I am thinking more and more about dropdowns.

Then instead of many radios, each option would have a label and a dropdown.

The advantage of radios is (was) that its one-click. But with so many of them, that advantage is gone anyway, or isn't it?


440bx

  • Hero Member
  • *****
  • Posts: 4202
The advantage of radios is (was) that its one-click. But with so many of them, that advantage is gone anyway, or isn't it?
There is another advantage that I am quite fond of, which is, with the radio buttons the programmer gets to see all the available options without having to go through one drop down after another.  IOW, no "option-hunting" necessary.

Personally, in spite of the many radio buttons currently on the pages, I prefer that over drop downs.  Of course, other programmers may feel differently and probably should make their preference known here (whichever way they prefer.)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
The advantage of radios is (was) that its one-click. But with so many of them, that advantage is gone anyway, or isn't it?
There is another advantage that I am quite fond of, which is, with the radio buttons the programmer gets to see all the available options without having to go through one drop down after another.  IOW, no "option-hunting" necessary.

Personally, in spite of the many radio buttons currently on the pages, I prefer that over drop downs.  Of course, other programmers may feel differently and probably should make their preference known here (whichever way they prefer.)

Yes. I might go for

- all radio on the individual pages (only one page selected, not "all")
  though maybe some very few of the options would still get "hidden" in combo-boxes.
  E.g., the option to display on object as "address only" (which only will be of interest if you show an array of objects, and only want to compare the addresses).

- On the "All" page (or multi selections of pages) drop downs could be used (or again a mix of them).


About mixing... I wonder, some radios, and then a last radio wich activates a dropdown?
Code: Text  [Select][+][-]
  1. Base:   [O] Default    [O] Decimal   [O] Hex    [O] [[Dropdown]]
   




Then there are options with 3 states (default/on/off), like "Sign" = default / signed / unsigned
(Maybe ..., even options that are (default/on/off/only))

They could always be comboboxes?
Advantage, with the current layout of 4 columns, you can fit 2 such options into one row (each have a label and a drop-down).


For "Sign" default" is important, because it follows the type of the variable.

Which also means, if a user sets there global defaults for that, they currently can't go back to "automatic" in the watch-properties.

It could be a checkbox, with greyed state. But.... the "all" page already shows several values, and greyed therefore would be used for that (and also, eventually it should be able to edit several watches at once.
« Last Edit: March 22, 2024, 11:12:42 am by Martin_fr »

440bx

  • Hero Member
  • *****
  • Posts: 4202
Here are a few thoughts...

I like the "Current" because that is what applies to the expression being watched.   Usually, the other "stuff" isn't of interest (at least not immediate interest.)

Refer to the attachment for the following comments to make sense...

I don't think that the "Default" radio items are necessary.  I think that the default option should simply be selected, e.g, in the case of "Default (Deref)", I'd get rid of the "Default (Deref)" altogether and simply have the default state selected "Off"/"On"/"Only" (whichever applies.)  Aside from getting rid of clutter, it shows what the default option is.  Currently, it is unclear whether Default (Deref) means "Off", "On" or "Only".

On that note and, I could be wrong but, it seems to me that as far as "Address format" the default isn't "Typed" as the label suggest.  Playing with the thing left me with the impression that the default is "Address" not "Typed address".   Therefore if the label "Default (Typed)" was not there, there could not be any source of errors or user confusion.

At this stage, my suggestion is: get rid of the "Default" labels, I find they muddy the waters instead of making things clearer.

the second line (below Address format) is about the _value_ at the address and that's not clear.  I'd add a heading along the lines of "value at address" and make the Signed/Unsigned options appear only when "Decimal" is selected (I don't think those option make sense for the other options.)

There... my $0.02  hopefully, there is something useful in there for you.

Another thought...

As far as the non-current stuff... I'd be inclined to put that in a different window altogether where global defaults are selected.  IOW, I wouldn't have any options that are not applicable to whatever expression is being watched, e.g, if what's watched isn't a boolean variable then no "boolean" option anywhere in the window.

In the case of selecting formatting for record fields then, I would expect the user to double click on the specific record field and select whatever is available from the options that apply to the field's type.

As previously mentioned, the defaults for built-in types should be selected in a global settings window... something along the lines of... Tools->Options->Debugger->Display Format (but without the Default Labels) and instead of the default labels, on that window, I'd have the "number", "enum", "boolean", etc arranged vertically in the space currently used by the "Default" labels.

The more I think about it, the more I think that getting rid of the "Default" labels would make things clearer and eliminate clutter.

now... back to porting some C code... :)

ETA:

Added the forgotten attachment.




« Last Edit: March 22, 2024, 08:28:24 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9992
  • Debugger - SynEdit - and more
    • wiki
I like the "Current" because that is what applies to the expression being watched.   Usually, the other "stuff" isn't of interest (at least not immediate interest.)

But, "current" can only be selected once the data has been evaluated. Click "add new" and the IDE has no idea what your expression will return. Then it defaults to "all".... That is the main reason for "all".

Also if you watch a structure, then fields inside can have numbers, enums,..... => and then those others can be of interest.
And then you can multi-select  (hold shift and click more than one tab). So you can change enums and bool in one go. (Ok, that is not important, but doesn't harm)


Quote
I don't think that the "Default" radio items are necessary.  I think that the default option should simply be selected, e.g, in the case of "Default (Deref)", I'd get rid of the "Default (Deref)" altogether and simply have the default state selected "Off"/"On"/"Only" (whichever applies.)  Aside from getting rid of clutter, it shows what the default option is.  Currently, it is unclear whether Default (Deref) means "Off", "On" or "Only".
This actually depends on the option.

Default for "signed" is important. Because it isn't just signed or unsigned. The meaning of default changes, depending on the type of the data. ("Step into" and "i" may no longer be qword but int64 instead).
If the user explicitly set it to "unsigned" then the int64 will be converted.

If it would be set to unsigned, due to the global default, then once it is set, it is set => same checkbox. No difference to having been set by user.

Mind, that I have the IDE of allowing different defaults, depending on the typename. So if the debugger says  this is TMyNumber then that could changed the meaning of "default" to something different than it has for integer.
And that will get very complicated, if the default simple gets copied onto the current settings.

The same problem applies in the evaluate window. Here the expression is changed often. If the global setting were copied, then they must get copied each time the expression changes. But that would mean the user couldn't select a value that anymore and have it stick.


I do agree that for some settings (such as "deref") the "default" is irritating at first (especially because few will actually have there own default, and fewer several defaults).

One way would be to only show it (for those kind of options), if the default is something that can change.
Off course in that case, if you add the config for this, then all existing watches will be set explicitly to "not default" (but that may be very very minor).

---
About default not indicating what it is....

As I said, for signed it can't actually do that (or only if it has evaluated data, and then only for the current data, and that may then be misleading, because with the next "step into" the meaning of default can change).

The number-base had the same issue, but no longer has it. Originally pointers used that too, and pointers defaulted to hex, other numbers to decimal.

But, then as I said, the plan is, that the user can specify different defaults for different types (by typename). And then all "defaults" potentially don't know what they are.

But even now, where the user can only set one global default => The user can change that. And all watches an "default" will follow.

---
Though maybe there only needs to be one default for "base and sign". If the user selects a base they also must decide the sign. (and other future properties, such as lead zeros)

On the other hand (to make matters worse), for the "signed-ness" of numbers: If Default means to follow the global settings, and if the global settings are either "signed" or "unsigned", then how to force it bace to automatic.

Also in the global options, this should probably read "Automatic" rather than "Default".
However in the Project options, it is "default", since if the project options leave it on "default" then it follows the IDE global options.

https://en.wikipedia.org/wiki/The_Sorcerer%27s_Apprentice "The spirits that I summoned"

Quote
On that note and, I could be wrong but, it seems to me that as far as "Address format" the default isn't "Typed" as the label suggest.  Playing with the thing left me with the impression that the default is "Address" not "Typed address".   Therefore if the label "Default (Typed)" was not there, there could not be any source of errors or user confusion.
Ah, ok that needs to be improved. The "(Typed)" means "(Typed-ness of the address)" which can then be set to any of the options.  (Like the "Default(Sign)" for numbers). It's the Category for which "default" is selected. Not the meaning of default.

Quote
At this stage, my suggestion is: get rid of the "Default" labels, I find they muddy the waters instead of making things clearer.
They need at least to be different.

I thought about a checkbox at the start of each line. If it is not set, then no settings have been made.
(Like in the color editor in the options. The checkbox in front of "foreground" needs to be set, for the color to be chosen)

It could be set automatically as soon as a radio is picked. And if it is unchecked then all radios are cleared.

It be the same amount of clicks to do anything. Only the checkbox works reverse.
- unchecked = default
- checked = specific value selected by radio

----

Then I wonder, if it makes sense to introduce each group with a label.
- Base
- Sign
- Show Char
- Enum ?
....

But many are so obvious....

-----

Also something like
   [O] Default   [O] Address    [O] Typed Address

could be a checkbox
[X] Show address with typecast

And, if a default (aka, follow global options) is needed
[X] Override Global  [X] Show address with typecast

I'd like to have the "override global" to be a single column, with ideally no text.... But there is no way to make that self explaining. (It would need some header, and some indicator, that it is a special column...)

Improved naming => always welcome.

Quote
the second line (below Address format) is about the _value_ at the address and that's not clear. 
"numeric representation" may be a better word

And really, its just because people can store any data in "Items.Object" and stuff like that.
Yes, users can typecast. But not if they look at entries from the history list (currently they can't change the display format for that either, but that should eventually work)

Quote
I'd add a heading along the lines of "value at address" and make the Signed/Unsigned options appear only when "Decimal" is selected (I don't think those option make sense for the other options.)
If I change "Address format" into "Number format for Address".
That together with above change to the "typed" option.

Better?

Quote
There... my $0.02  hopefully, there is something useful in there for you.
Any feedback is always useful. I only have one head, only one mindset. That is a limiting factor ;) (really whatever evolution has thought about that, probably evolution didn't ask for feedback ;) )

Quote
As far as the non-current stuff... I'd be inclined to put that in a different window altogether where global defaults are selected.  IOW, I wouldn't have any options that are not applicable to whatever expression is being watched, e.g, if what's watched isn't a boolean variable then no "boolean" option anywhere in the window.
As, explained
Add new watch => no info on the result type yet

Quote
In the case of selecting formatting for record fields then, I would expect the user to double click on the specific record field and select whatever is available from the options that apply to the field's type.
Once it is expanded, then yes that is (will eventually be) an option.
In the Evaluate/Modify window it is not.

And also, the idea is, to have a toggle between "most outer value" and "values that are nested" => the structure "only address" currently makes almost no sense. But if you watch an array of TButton, then you may want the address of each button only. That allows you to see, if 2 entries refer to the same object.

So that may be limited to the global options....

Quote
As previously mentioned, the defaults for built-in types should be selected in a global settings window... something along the lines of... Tools->Options->Debugger->Display Format (but without the Default Labels)
and instead of the default labels, on that window, I'd have the "number", "enum", "boolean", etc arranged vertically in the space currently used by the "Default" labels.
They are already there. (yes the default labels, need to be replaced there.
(See also above, and reference to the same settings in the project options)


 

TinyPortal © 2005-2018