Problems of offset

[MSpagni]

Comparing a couple of binary files in byte-by-byte mode, the status bar, as you can see, says "Offset: 0 (0x".
No room for the whole string, I suppose.
Of course, if you scroll down, at 10000 the unit digit disappears, then, at 100000, the tenth digit dissapears and so on.

[psguru]

No room for the whole string, I suppose.

Exactly. Doesn't making the window wider "fix" the issue?

[MSpagni]

Ehm...
I don't remember if was Schumann or Schubert. In a piano sonata he wrote: "to be played with full strength".
And a few bars later: "stronger"...
As you can see in the screenshot, the window is already maximized!

[psguru]

Interesting. What is the screen resolution?

[MSpagni]

1280x1024, 120 DPI

[psguru]

Strange, I used even smaller screen and still can see more than your screenshot shows. Anyway, what is your suggestion? How should that status bar panes be sized?

[MSpagni]

Binary mode

Binary.jpg (10.65 KiB) Viewed 57106 times

Byte by Byte mode

ByteByByte.jpg (15.33 KiB) Viewed 57106 times

(Thinking aloud)
Why are the status bars different?
What does it mean the '\' in case of binary?
Why so much room for "Selection:"?
What about an option to show or hide the file date and time?

[psguru]

Why are the status bars different?

I'm not seeing it on my PC. What you call ByteByByto, it's the one with "Use fast byte-by-byte comparison" option enabled, right? If so, there are no differences in status bars based on this flag.

What does it mean the '\' in case of binary?

Not sure. Please make the window/pane bigger to see.

Why so much room for "Selection:"?

Because selection can be large?

What about an option to show or hide the file date and time?

We don't have any options for status bar panes, and unlikely to have in future.

[MSpagni]

there are no differences in status bars based on this flag.

...Except the differences you see in my screenshots in the space for the offset and, consequently, in that for the "Value".

What does it mean the '\' in case of binary?

Quite trivial, sorry: it's the left wing of the 'V' of "Value", not a backslash!

Because selection can be large?

And so does the offset.
And I'd say it's also much more probable to have a big offset than a big selection.

[psguru]

I'd like to have status bars perfect but I'm afraid I can't see a solution here, when there's not enough room for all panes. If we make the selection pane smaller, there will someone complaining that they can't see its value.

[MSpagni]

That's what we call the "short blanket" conundrum: which side you leave out?
I don't have any real solution to propose.
As a partial fix I can suggest removing the leading zeros (see below) and dynamically resize the status bar panes in a more effective way.

Clipboard01.jpg (4.69 KiB) Viewed 56745 times

You can also completely leave out the "Value" field when the cursor is in the hex part of the pane, since the hex value under the cursor is obvious.
And also, to be very picky, use the same status bar format for binary and byte-by-byte.

[psguru]

Sorry, I have to disagree with these.

As a partial fix I can suggest removing the leading zeros (see below) and dynamically resize the status bar panes in a more effective way.

0x... format is a way to show hex numbers (unless I misunderstood). Dynamically resizing status bar panes is already done when the main window is resized. Resizing panes based on the cursor position or selection change is too much, not only from the programing point but from the usability.

You can also completely leave out the "Value" field when the cursor is in the hex part of the pane, since the hex value under the cursor is obvious.

This implies dynamic rebuilding of status bar panes.

And also, to be very picky, use the same status bar format for binary and byte-by-byte.

There's no special handling of status bar panes based on the "Use fast byte-by-byte comparison" option. Are we talking about the same thing? Because this mode is still in binary comparison, and you make it sound as if "byte-by-byte" is not.

[MSpagni]

0x... format is a way to show hex numbers

Sure, but 0x0000000C is exactly the same as 0xC but the latter is by far more compact and, at least so long as the number can be printed in the available space, more meaningful than, say, "0x00".

Resizing panes based on the cursor position or selection change is too much, not only from the programing point but from the usability.

I can easily understand the programming point, but I don't see any problem of usability. (Just my opinion, of course.)

There's no special handling of status bar panes based on the "Use fast byte-by-byte comparison" option.

You already said this, but don't you see that the status bar are different between the two modes?
Look at my screenshots:

• in binary mode the offset part has room for "Offset: 69665 (0x00" and the selection part for "Selection: 1884<blank><blank><blank><blank><blank><blank>V" (almost ).
• in byte-by-byte mode the room for the offset part is reduced so that only "Offset: 725" can be shown, while the room for the selection part increased to contain "Selection: 0<blank><blank><blank><blank><blank><blank><blank><blank><blank><blank><blank><blank><blank><blank>Value: 03".

Don't tell me this is only an effect of the proportional font!

A possibility could be to use only one status pane for offset, selection and value instead of three and formatting the one string without all those blanks, so as to exploit all the space available as long as possible.

[JeremyNicoll]

You could also shrink unnecessarily long words.

Why "Offset:", bearing in mind that anyone using this sort of display will already know that Offset is the normal way to specify a location? Why not just use "At:"?

Why "Selection:" when what it seems to mean, is "Size:"? Or "Sz:" or even "L:" or "Q:" or "N:" for Length, Quantity or Number (of something)?

[psguru]

Let's first establish this: again, there's no special handling of status bar panes based on the "Use fast byte-by-byte comparison" option.

The screenshot on the right uses fast mode: compare the status bars.

Screenshot 2025-02-26 160432.jpg (1.07 MiB) Viewed 56080 times