MKVToolNix GUI - Properties Box - HEIGHT Bug

ISSUE: MKVToolNix GUI v79 Windows 11 22H2 x64 in 2160p display resolution is missing the option to resize the “properties” box for HEIGHT.

The option to resize for width is present and working. So, what happens here is without the ability to adjust the HEIGHT of this properties box, it causes the need to scroll the whole window up and down in order to see the top tab and bottom buttons of the window for it.

If the properties box was made a bit shorter in HEIGHT, that would resolve the issue.

Please don’t get confused, the inside of the properties box also scrolls, and that works fine, no issues. It’s just the properties box HEIGHT fills up more space than it should, forcing the need to scroll the whole window to see the top tabs (input, output, attachments) or bottom functions such as (start multiplexing button).

Is the properties box CSS, where it just needs a different settings to define the HEIGHT? How to adjust the HEIGHT of the properties box in the GUI?

If you look at the bottom of the GUI, you will see there is waste space, as there are two rows using the same words - destination file. The first row can be eliminated, the second is fine as it includes the location for it and buttons.

Eliminating the double wording, helps to remove the extra row, giving more room to see the bottom of the GUI window.

Without the ability to resize the HEIGHT of the properties box, the bottom view of the window is missing 3 rows! Just so you know. So the properties box should be reduce in height by 3 rows here.

This would greatly speed up production, without needing to scroll back and forth, up and down, just because the properties box is oversized without an adjustment for HEIGHT. I hope I was clear enough to explain, sorry for my English.

The whole properties box’s minimum height is determined by the minimum height of all the child elements, notably the ‘output’ tab. It’s not something I’m willing to spend any time on changing around.

You can save some vertical space by re-configuring the GUI’s layout. For example, you can move the tab headers to the left or right instead of the top or bottom. Additionally you can move the “destination file” controls from always being visible beneath the properties to be part of the ‘output’ tab.

Thank you for responding back.

If you re-configure the GUI to move the tab headers in a horizontal direction be left or right instead of the top or bottm, it doesn’t resolve the issue, even if you additionally move the “destination file” controls to the ‘output’ tab.

You wrote, “The whole properties box’s minimum height is determined bt the minimum height of all the child elements”, but when those child elements are all minimized with plenty of extra unused space the properties box doesn’t resize, doesn’t reduce, and continues to be oversized regardless of the child elements within it.

Additionally, the whole properties box already has the horzonal width resizing adjustment, only the vertical height resizing adjustment is missing to resolve the issue.

Surely, there must be an easy method to add the missing control to resize the height for the properties box in the GUI layout? Another thought is to just change the properties box setting that determines the properties height without a control. But you indicated you are not willing as the author to correct, fix or resolve the issue here, why not?

It would seem you have invested a lot of time for this project, it’s been around for a long time, and that you continue to build upon prior work, and yet for a layout issue like this, you would resign yourself from resolving something that isn’t actually difficult like more complex issues here.

It’s just seems stange to see something that is easy to resolve be avoided by the author. Why go to all the trouble of creating the MKVToolNix GUI only to let it remain broken, flawed with the bug issue?

Even the double word usage, where you see ‘destination file’ repeated twice, isn’t needed, and yet that too is impossible to correct, as you didn’t respond back for it as well.

This suggest there is some other reason not told here, as to why you are not interested in your own software project to resolve the issue. Perhaps, your just hoping someone else can carry on your work picking up where you left off?

I will just say, thank you very much for the work you already done, and did, which is why I had reported the issue, to help you improve your work for everyone else using your software tool.

If it’s so easy to solve, I’m sure you can come up with a solution yourself & provide a patch that implements it, especially as you care so much about it. I on the other hand simply don’t care. I’m fine with requiring a certain minimum available vertical space for everything to be visible.

Everything is NOT visible, and you know it, as I shared the screenshot, and given you the explaination for it. If you don’t CARE, that is your choice.

Here’s a screenshot clearly showing that everything is visible with a window height of around 782 pixels:

1 Like

@MKV, I too am having the same issue since I bought a new laptop with 1366 x 768 as the default resolution. Never used to be an issue with the old 720 x 480 (4:3) screens. Screen sizes have been changing since the Windows XP days and the developer just hasn’t kept up with the times. Sad, really, but I totally get what you are saying.