Closed JeromeMartinez closed 2 months ago
This does not happen previously? 🤔 How does this happen when there are no changes to the menu bar...
Action to reproduce with latest main branch:
* Select light theme * drag and drop a file
Cannot reproduce on both 24.06 and self-build from local branch (current main+64-bit+WebView2 merged). Update: Cannot reproduce on https://mediaarea.net/download/snapshots/binary/mediainfo-gui/20240630-4/MediaInfo_GUI_24.06.20240630_Windows.exe also Update2: Cannot reproduce on high-DPI too
this is an example of why we are reluctant to change things, there are always some regressions to fix
I don't think this is caused by any of the recent changes. No changes made by me to the menu bar recently. The only change was replacing the icons with high-DPI support way back in the high-DPI patch-set but that should not cause issues too. If consider adding more items to sub-menus as a change to menu bar, that should not cause drawing issues to the main bar too.
https://github.com/MediaArea/MediaInfo/assets/77721854/0eca9b5b-5280-4d0e-811d-eca42a4f7ef0
On my machine: 20240627-2 OK 20240628-2 there is a start of not showing the bottom of the menu during drag and drop 20240630-2 menu disappears during drag and drop
(20240628-2:
)
So even if it is only on my machine, there is really a bad something which changed somewhere in the last days. After the release. Could you check the 2 last links on your machine?
I cannot reproduce with drag and drop. However, I can reproduce when taking screenshot with Snipping Tool but it immediately becomes normal as soon as the window regains focus. By testing the versions you provided, even 20240627-2 is missing bottom.
So I proceed to test with 24.04 and finally it happens on drag&drop and still happens on screenshot. It is bottom missing and screenshot is worse than drag&drop.
So now I have a suspect that is quite certain. That is the attempt to hide the tabs (again).
So the old version, before I changed anything, the tab bar was resized to 1px and pushed up. This likely caused the bottom few pixels to be missing and also caused some partly visible words on high-DPI which is the reason I changed the hiding method. New method is pushing whole thing up without resizing the tab bar. That explains why more is missing now when the glitch happens.
I have an idea. What if we move tabs to bottom then push it out of the window boundary. Since nothing is at the bottom, nothing should go wrong?
Since nothing is at the bottom, nothing should go wrong?
There is something at the bottom. Try with: Root_extra.zip
That is the attempt to hide the tabs (again).
OK, so it is linked to the other things in another ticket, when the menu shows additional items. So I think it is a need of refactor of the menu related algorithm, I am sure there is something to do for reducing the count of calls of such code which should remove the glitches.
I guess it was hacks on hacks with collateral damage hidden during years and now that there is a clean up of some other parts of the code it becomes visible :(. @cjee21 if you are motivated I let you do some refactoring of this part of the code, else I try to do it this evening.
Since nothing is at the bottom, nothing should go wrong?
There is something at the bottom. Try with: Root_extra.zip
How am I supposed to try with this? What should I do with the XML?
Never mind, I opened it with MediaInfo and see something.
Edit: That is at the bottom but still within the sheet area so should be safe. Let me do more tests including 200% DPI (because this always makes things that are supposed to be hidden become partially visible).
Alright. This issue is fixed perfectly on all DPIs.
But I discovered that the button does not look good at 200%.
But I discovered that the button does not look good at 200%.
The button at the bottom is not supposed to be so big!
But I discovered that the button does not look good at 200%.
The button at the bottom is not supposed to be so big!
Any idea where went wrong and why it is not scaling in the same way as other elements?
Alright. This issue is fixed perfectly on all DPIs.
Curious about how you fix it, waiting for the PR ☺️.
Any idea where went wrong and why it is not scaling in the same way as other elements?
No, IIRC it is just a button. The only one we have IIRC so not possible to compare.
No, IIRC it is just a button. The only one we have IIRC so not possible to compare.
The button next to the filename selector and the many buttons in Preferences window are different?
The button next to the filename selector and the many buttons in Preferences window are different?
They are not enlarged for following the windows size. Else I guess they are same.
Curious about how you fix it, waiting for the PR ☺️.
To sum up, the cause of this menu bar graphics glitch issue exists (partially missing) since at least 17 years ago due to https://github.com/MediaArea/MediaInfo/blob/10705513993a835078ec8927aaa8e40eccb8bcdf/Source/GUI/VCL/GUI_Main.cpp#L162 and is made worse (all missing) by the recent change to https://github.com/MediaArea/MediaInfo/blob/e918631c5f99eff9cf11fc9b89c8a9e3bbff69ba/Source/GUI/VCL/GUI_Main.cpp#L248 and will now be perfectly fixed by the linked PR.
I have scrutinized the borders at 200% DPI and they look pixel-perfect 😄
and will now be perfectly fixed by the linked PR.
You are starting to know the GUI code better than its author (who forgot everything about it 😅, it was so a long time ago).
The button at the bottom is not supposed to be so big!
Fixed. Also fixed the issue of buttons next to drop down selectors not being the same size on high-DPI which was mentioned the other day.
Screenshots on 200% DPI:
dev snapshot from latest master branch.
Action to reproduce with latest main branch:
The menu items disappear until there is a mouse over the items, as if there is a lack of refresh somewhere. It is totally fine with dark theme.
@cjee21 this is an example of why we are reluctant to change things, there are always some regressions to fix :(. But we still want the changes, just that we need to find out which one produced that.