Feedback needed: Fit window to row option

Wishlists for new functionality and features.
Post Reply
T.BugReporter
Posts: 4
Joined: 14 Jun 2019 09:54

Feedback needed: Fit window to row option

Post by T.BugReporter » 15 Jun 2019 17:49

Currently, there is an option to change the bytes per row setting based on the window width, but I'd much rather have a setting that goes the other way, i.e. leaves the bytes per row setting alone and adjusts the window size to match instead. I have the main HxD window sized so that when the child window(s) are tiled horizontally, they exactly match the width of the data. It's annoying enough that newly opened child windows refuse to use the full main window width, but the fact that there's no easy way to compensate for this short of re-tiling all sub-windows makes this doubly annoying.

Maël
Site Admin
Posts: 1137
Joined: 12 Mar 2005 14:15

Re: Fit window to row option

Post by Maël » 16 Jun 2019 09:02

I have the main HxD window sized so that when the child window(s) are tiled horizontally, they exactly match the width of the data.
So, MDI child windows were tiled horizontally and they should resize automatically to fit the main window width, but never get smaller than necessary to completely show all data (hex and text) for the current BytesPerRow setting?

Or, should every MDI child have exactly the width necessary to fit the data (according to BytesPerRow), no matter how large the main window is?
How does tiling horizontally play into this? Should it just "stack" all the MDI childs horizontally, no matter if they fit or not?

The current implementation is just the classic way MDI-style applications work.

T.BugReporter
Posts: 4
Joined: 14 Jun 2019 09:54

Feedback: Fit window to row option

Post by T.BugReporter » 07 Jul 2019 09:41

This is my window just after opening the program:
0files.png
0files.png (45.4 KiB) Viewed 342 times
This is after opening two files:
2files.png
2files.png (84.93 KiB) Viewed 342 times
And this is what I'd like to get - without too much fiddling from the previous screenshot:
desired.png
desired.png (117.66 KiB) Viewed 342 times
Maël wrote:
16 Jun 2019 09:02
So, MDI child windows were tiled horizontally and they should resize automatically to fit the main window width, but never get smaller than necessary to completely show all data (hex and text) for the current BytesPerRow setting?

Or, should every MDI child have exactly the width necessary to fit the data (according to BytesPerRow), no matter how large the main window is?
I think either one would work for me.
Maël wrote:
16 Jun 2019 09:02
The current implementation is just the classic way MDI-style applications work.
I understand normal MDI behavior; I'd just like a checkoff in the options to override this - particularly when the user specifies more than one file in the same open dialog.
Maël wrote:
16 Jun 2019 09:02
How does tiling horizontally play into this? Should it just "stack" all the MDI childs horizontally, no matter if they fit or not?
Honestly, I hadn't fully thought that out. I suppose if this proposed option were checked, new files would be opened as if no other windows were present and the "Tile Horizontally" menu item were selected.

I hope this post clarifies my desires - altho I suspect it'll bring up more questions than answers. :oops:

Maël
Site Admin
Posts: 1137
Joined: 12 Mar 2005 14:15

Re: Feedback needed: Fit window to row option

Post by Maël » 07 Jul 2019 18:59

Thanks for your reply and the pictures!

And to explain my impression: often feature requests are not followed up on, even after being implemented, but noticeable frustration/disappointment from the user part is expressed while requesting. Given the effort necessary to implement/design things, it creates frustration in me as well (which I usually don't share and thought I should start to do).

And no worries about raising questions, they help.
T.BugReporter wrote:
07 Jul 2019 09:41
Maël wrote:
16 Jun 2019 09:02
So, MDI child windows were tiled horizontally and they should resize automatically to fit the main window width, but never get smaller than necessary to completely show all data (hex and text) for the current BytesPerRow setting?

Or, should every MDI child have exactly the width necessary to fit the data (according to BytesPerRow), no matter how large the main window is?
I think either one would work for me.
In more technical terms, this would mean it works like now, but instead of showing a scrollbar, each window would remain as large as necessary, to not need a horizontal scrollbar. So I could use the scrollbar computation code, to determine the necessary window width.

There would still be limits to this, as windows are limited by screen size, and BytesPerRow can cause larger "content" than would fit on a screen.
A possible name could be: "Fit to content width". Technically, it should be "Fit to content width (if possible)", but that would be too long and still not say what the conditions are.

I could compute the window size constraints based on BytesPerRow, as long as the "Fit to content width" option is enabled.
The already existing "Fit to window width" option would form a radio group with the "Fit to content width" option, so only one of them could be enabled at any time (or none of the two). In the options dialog there would also be a global "Fit to content width" option that applies to all windows.

Open question:
Now the only issue I can see that remains, would be with the upcoming UTF-8 support. It is not clear how large a window needs to be (to show the content without a scrollbar), before having rendered the relevant part of the file. Each line can have a different width, as characters don't have a fixed width anymore, and several bytes could just result in an average width character.

The only option I could see would be to assume the maximum text line width possible for the current ByterPerRow setting. That could mean wasted horizontal space / a lot of blank space.

Any other ideas?

T.BugReporter
Posts: 4
Joined: 14 Jun 2019 09:54

Re: Feedback needed: Fit window to row option

Post by T.BugReporter » 14 Jul 2019 05:35

Maël wrote:
07 Jul 2019 18:59
Given the effort necessary to implement/design things, it creates frustration in me as well (which I usually don't share and thought I should start to do).
Understandable - satisfying users is a hard job - even harder when you're not paid (or underpaid) for your efforts. My only concern was whether I in particular had done something to invoke your newfound honesty. :lol:
Maël wrote:
07 Jul 2019 18:59
There would still be limits to this, as windows are limited by screen size, and BytesPerRow can cause larger "content" than would fit on a screen.
Well, yeah, I wouldn't expect your program to make much of an effort to honor a ridiculous request like 1024 bytes per line.
Maël wrote:
07 Jul 2019 18:59
Open question:
Now the only issue I can see that remains, would be with the upcoming UTF-8 support. It is not clear how large a window needs to be (to show the content without a scrollbar), before having rendered the relevant part of the file. Each line can have a different width, as characters don't have a fixed width anymore, and several bytes could just result in an average width character.

The only option I could see would be to assume the maximum text line width possible for the current ByterPerRow setting. That could mean wasted horizontal space / a lot of blank space.

Any other ideas?
Sorry, i18n has always been a bit of an Achilles' heel for me. At least with CJK you can usually guarantee that characters are no more than double the fixed width Western font size, but with Arabic and others the width of otherwise identical glyphs can change their meanings. (Also, by the time these things started to be recognized as issues, I was mostly retired from the programming end of things.)

Allowing for the max also seems wasteful to me, and even detrimental to the use of the new function for the 90+% of people who don't need full UTF-8 support. (If I turned this on and found it always leaving the right 10% of my screen blank I'd probably consider it as annoying as the current situation, if not more so.)

Maël
Site Admin
Posts: 1137
Joined: 12 Mar 2005 14:15

Re: Feedback needed: Fit window to row option

Post by Maël » 14 Jul 2019 09:55

T.BugReporter wrote:
14 Jul 2019 05:35
Allowing for the max also seems wasteful to me, and even detrimental to the use of the new function for the 90+% of people who don't need full UTF-8 support. (If I turned this on and found it always leaving the right 10% of my screen blank I'd probably consider it as annoying as the current situation, if not more so.)
Well, most binary files will contain "random" data as seen from a text interpretation. So you'll likely see some "foreign" characters, even when you would not "need" them.

I don't intend to do some UTF-8 light or something like that. Maybe an option to limit the range of characters rendered, and replace those with blanks or a replacement character could be an idea, to keep the output more readable.
Possibly a character per group/range of characters.

The variable width text length will remain though, due to the multi-byte nature of UTF-8, also for CJK.

If you or anybody else has an idea, I am open to suggestions.

T.BugReporter
Posts: 4
Joined: 14 Jun 2019 09:54

Re: Fit window to row option

Post by T.BugReporter » 16 Jul 2019 04:49

Maël wrote:
14 Jul 2019 09:55
I don't intend to do some UTF-8 light or something like that.
Just to be clear, I wasn't suggesting skimping on the i18n. This is like many features, in that nobody ever needs 100% of what it provides, but which 3% is needed always varies from user to user.

Perhaps you can have some sort of option or option set -
"Which code range(s) are you most interested in for text?
[_]Western only
[_]CJK
[_]..."
Ranges that the user has not expressed interest in can be displayed as if 8bit coded, even if there's a valid interpretation in some other Unicode range. (This could also be important for users who lack fonts for certain glyph sets; I know I get frustrated trying to decipher those little boxes with hex digits inside, and in this case those boxes offer zero information that isn't already available.)

Post Reply