Foldable regions aligning with column offsets

[sapphiwen]

Hi Maël,

Thank you very much! Yes I tried it and it was able to read my intel hex files
Would it be possible to align the start of line not always on the leftmost column, but according to the address offset at the top? Sometimes my linker would skip 4 bytes and the next data segment would start at an odd offset, I need to keep reminding my self when a data segment like this happens, that the leftmost byte of the column is not at 0 offset but some odd address, and the rest of the line becomes more difficult to read. I attached a screenshot of what I mean. Suggestion is to start the line of data at the 08 offset location instead of aligned to the left.

Capture.PNG (26.68 KiB) Viewed 397 times

[Maël]

Maybe sometime, but that would need significant changes.

One issue especially I am not sure how to solve is how to present several foldable regions in one line, as in your example. Where do you put the +/- icon, and how do you draw a folded region such that it doesn't take more space than a few bytes would take (a folded region is represented by the range of addresses it represent, a few bytes however take far less screen space). Imagine a region of one or 4 bytes, the folded region may take more space.

So several regions in one line seem problematic.

[Maël]

You could also have a foldable region just leave empty space on the left (still on a new line), such that the column offsets added to the line offset make sense again.

The following screenshot shows how it is done now:

SectionsAlignedAtLineStart.png (14.72 KiB) Viewed 392 times

And this how it could be done with column alignment, but a new line at the start of each new section, still:

SectionsWithColumnAlignment.png (14 KiB) Viewed 387 times

The issue is that the line offset would be repeated several times (the 00000000 appearing three times is not a mistake).

Is that what you thought of?

Besides the repeated line offset, the other UI/UX issues mentioned above should not be a problem for this solution. It still would require implementation effort, though, obviously.

[sapphiwen]

Yea I'm thinking something akin to the second picture you have, because for hex file analysis sometimes it is fairly important to be able to see there are gaps in memory sections. But the picture you showed also didn't actually have a gap between the memory ranges, so it would probably be better to merge that into 1 foldable region, even when the hex file itself split the data into multiple regions (optimization for next time saving?). But for real gaps it's great.

Here is what I came up with to deal with the issue of the same offset on first line:

Capture.PNG (16.96 KiB) Viewed 332 times

[Maël]

For undefined regions/gaps in memory, instead of a blank line like in your screenshot, you'd have a folded region showing the undefined offset range (see RAM editor), or when you unfold it, a sequence of question marks to denote undefined bytes.

I guess your last screenshot is not fully correct, since the line with 0000 0008 line offset would not make sense, when adding up with the column offset. You would have to write 0000 0000 so the sum with the column offset is correct.

Your notion here seems to be that the line offset gives the offset of the first byte in the line. But then it makes no sense in combination with the column offset. Look at the second byte at column offset 9. Combining 0000 0008 and 09 does not give a correct absolute offset.
So you would have to adapt the column offset for this line so the addition makes sense again.

Maybe you could instead write the line offset a bit lighter/faded out a bit, so that it's obvious it's a continuation of the previous line.

Yeah, something like that, similar to how line numbers are shown in source code editors that wrap a line. They usually omit the line number on the wrapped line part, and possibly add a line wrap indicator.

[Maël]

Here is a mock-up.

Line-Continuation-Unfolded.png (17.16 KiB) Viewed 318 times

Line-Continuation-Folded1.png (17.54 KiB) Viewed 318 times

Line-Continuation-Folded2.png (13.92 KiB) Viewed 318 times

The unfolded picture makes the most sense, and I like the line continuation (similar to line break, but there is no "carriage return").

In the folded cases this doesn't look as logical anymore, since the folded region will always start at the hex-column begin. So the line continuation is not as obvious anymore. Moving this gray rectangle to column offset 4 would overlap the start in the new line and it would also look odd to be place there, since it's no data, but rather line information (the region of offsets that were folded):

Line-Continuation-Folded3.png (17.47 KiB) Viewed 318 times

Finally, if the second line continues the first but extends over several lines afterwards (i.e., a multi-line region), the third line should have the line offset mentioned again, or it becomes confusing.

So I think the best is to keep the line offset as mentioned above (i.e., repeating 00000000 on each line), but additionally, add a line continuation icon.

[Maël]

Maybe something like this:

Line-Continuation-Folded4.png (17.66 KiB) Viewed 317 times

Or this variation:

Line-Continuation-Folded5.png (17.71 KiB) Viewed 315 times

[Maël]

So far I prefer Line-Continuation-Folded4.png, maybe with and added ... on the line end and a ... on the next line start. But that probably adds too much visual clutter.

The only really remaning issue, is that the folded region does not visually align column wise.

So this is my currently final mockup:

Line-Continuation-Folded6.png (17.65 KiB) Viewed 309 times