Save window position and dimensions. Improve Preferences Form. #903
Conversation
|
build with this PR. @cjee21 is the change proposal about how to compute window sizes is fine at high DPIs? PS: @regs01 please rebase, I just merged another PR and now it is conflicting, sorry about that, it is rare. |
I'm new to VCL so I just work on improving the existing codes. If there is a better and more proper way from someone more experienced in VCL then we should use that. I will test it later. We need to test on Windows 7 (to ensure no issues like previously) too and ideally it should be tested by someone with a multi-monitor, multi-DPI system. The existing implementation was not tested on this kind of set-up either so I don't know how it handles that. It seems now the default is to not remember window position and remember window size. We need to consider whether to keep old behaviour as default (set both defaults to not remember) or not. Also remember to use spaces for indents (it looks like tabs now). |
I think it is a good intermediate.
True. @regs01 please use spaces instead of tabs. |
Yes it's blank unless click on one of the items in the tree. Also it is entirely white with no distinction between the left, right and bottom sections. I don't know if that's a good idea. Also is it intended that the main window is re-spawned every time Preferences is closed? The issue reported by Klaus1189 is still there and now is triggered as soon as Preferences is opened. Seems to take very long to open Preferences too. |
With remember window size disabled it is acceptable for me on different DPIs but it is different size/ratio than what MediaInfo has been using for years so I don't know how others will react. With remember window size enabled, if user changes DPI after using MediaInfo at least once, it uses size for old DPI and window is too small (or maybe large). This may also cause issues for people using multi-monitors with different DPIs (I don't know how the behaviour is here since I no longer have multi-monitors). |
I am not shocked by the default and not so different so it is acceptable for me.
@regs01 is it possible to save a kind of DPI independent ratio rather than a pixel size? |
How default looks here: Acceptable for me but no idea about other more particular users. |
|
@cjee21 yours is not near from former version, ouch. too much height. I have that: Difference due to DPI somewhere? |
|
@regs01 in practice we have 2 topics, the save window pos/dim on one side and the default size on another side. IMO it would be better to split the PR in 2: the first one keeps the same method for computing the default size. when it is merged, you send a PR with the changes you suggest about the default size. |
Not DPI. that's the default on 100% (96DPI). It is because I'm using higher resolution display with more screen estate (>=1440 height). |
|
@JeromeMartinez Another major bug. When invoked from explorer context menu produces a window with no file open. This change is causing lots of effects besides remember window size and change Preferences look.
|
|
At least it does not seem to break Windows 7 compatibility. Note: We can remove delay load from user32 if we no longer need to get DPI manually. |
|
We should set a minimum size if we allow resizing Preferences window: and for main window too. |
|
Took a more detailed look at the changes in this PR. I agree with changing the window size code to use VCL ( I also like that the window size/position saving is planned to be implemented as an option and that window position is disabled by default. I think this should not be added: if (fpUnscaledMonitorHeight>=1440)
Height=900;as it is deemed "too much height" and may cause other users to complain although I can tolerate that
This should not be simply removed from FormShow without sufficient testing and other changes: //Refresh global
FormResize(NULL);
Refresh();These two functions have been triggered by FormShow long before I started contributing. There is a reason why it is there. @JeromeMartinez these are my opinions since you asked me for a review. As for the other changes, I am not so sure but think they require more testing and changes due to many side-effects/issues mentioned earlier. Of course, you make the decision on what is to be done (I'm just a user/contributor) :) |
Thanks :).
I guess that the best method here is to split this PR is 2 or more PRs with specific changes rather than all in one, too much difficult to review impacts. |
|
Maybe it is a good idea to make both window size and position saving disabled by default so that users used to existing behaviour will not be affected and especially with the DPI change causing unintended window size. That is why I try to keep the window size the same as before even on high-DPI displays after adding high-DPI support. Then users who want their own size can turn the setting on and resize the window to their liking and deal with resizing it again when changing DPI since the feature will be documented in changelog. If concerned about people not reading changelog and knowing the existence of the feature, maybe can make MediaInfo display changelog on first run after upgrade like what some apps do. |
I moved switching tab visibility before selecting active page.
I commented in the line computing Preferences form height. There is no need as VCL scales it automatically. It's enough to have fine looking height in design time. I see also new commits to chage lables height for Language and Output. There is also no need for that. They just needed to be aligned to baseline of comboboxes, as they were aligned to bottom of comboboxes. VCL take control of scaling.
Yeah, I used C++ Builder 11.3 Community Edition. On VirtualBox, so it wouldn't mess up with old lifetime Delphi 10.2 Starter license. Although i'm using Lazarus now. But I must say how bad C++ Builder code completion is. It's so slow and buggy. Delphi's one is a little better. Even CnPack can't help much of situation. But Lazarus is completely different level - works instantly and only showing items within the scope. It just doesn't have prediction, as Visual Studio, but in everything else Lazarus code completion is even better than VS.
I always use spaces, although RAD Studio seem to default tabs. There could be few, before I changed it. Probably CnPack also does it, i'll look up on it.
I have 4K with 150% myself. It's just uncommon if users want to change scale factor on a daily basis. It is also highly unlikely that a person with high DPI display would use Windows 7. I left Position off by default, as this could be matter of preference. But with dimensions users wouldn't notice difference, as they will keep having default size and location. But those using Text, Tree views and similar will be able to quickly address form height issue without going into Settings.
I'll look up on rebase.
I did for Height, as i didn't do scroll box. I can do for Width. It's 1-second operation.
#203
Cut off little bit less. I'll readd it. Although as I see at FormResize now, there is no need in most of it. All controls just need to be properly aligned. |
|
One more thing. If MediaInfo is closed while maximized, the next time it will start un-maximized but filling up the entire screen. This is not a problem for me and I have seen other apps behave like this but other users may find it annoying. I suggest if possible and not too difficult, make it remember if it is maximized or not and also the window dimensions saved should be for un-maximized so that user can restore their original un-maximized size. |
We can save the window size at 96DPI and scale it accordingly when we read/write the value. That should work. It may be rare for a user to change DPI but what if there are people who use laptop and dock it on a monitor with a different DPI every day? |
|
A lot better but it is still slower, as if something is called too many times (the language files maybe?). he dark mode is fine but in light mode it is super flat, some separation lines disappeared: This PR has too many topics in one shot, it would still be better to split it in several PRs, one per topic, e.g. a first PR could be a resizable pref window and only that, and we merge it after validation then do a next step e.g. save window preferences without touching the algorithm for the default size then touching the algorithm for the default size. |
|
Confirmed that invoking from CLI/context menu is still broken as I expected earlier after a quick look at the codes. @JeromeMartinez I don't feel like reviewing this anymore
|
You mean, when switching tabs? That's because ComboBoxes are filled every time tab is switched. I didn't touch it. It's an old behavior. A better option would be to fill them once at form creation. And when a language is added. |
|
Moving Link, if embeded video doesn't work in Firefox screen2gif-2024-07-04-1955.webm |
|
New build.
For the moment the only regression I still see is the lack of lines (they are there before this PR) in the light theme, also visible in the video, and it is not expected that theses lines change in a PR about main window position and re-sizable preference windows. |
|
I still can't get what slowness are you talking about? Is it one in the video? I didn't make a commit yet. But there is a video with partial fix. I'll finish later, when come home. |
If we're still talking about the Preferences window, here are the commits history: https://github.com/MediaArea/MediaInfo/commits/master/Source/GUI/VCL/GUI_Preferences.cpp Time taken to open Preferences window:
I don't see any statistically significant difference regarding Preferences window after my contributions as expected from the commits history. The slightly faster time might be due to 64-bit and considering that a new option was added by your team recently, the results look good. I don't know what happened but 1st version of this PR was bad. Now it can be considered okay. But if the faster speed is just due to now having 64-bit, then it is still no good. Take note that the above test results are likely not accurate to tens of ms (based on 30fps video & only run once) so hundred or so ms difference can be ignored.
I'm not sure which slowness he is talking about (if he is talking about the one in your video, it has been like that for years AFAIK) but the one I talk about in all my comments is time taken for the Preferences window to show up which was bad in 1st build of this PR but can be considered okay now for me. UPDATE: If you want to know the reason why Preferences window now takes longer to show up, the cause is as I had initially suspected and now confirmed with some tests. This takes 0~2ms on both 64-bit and 32-bit to execute: Page->Top=-(Page->TabHeight*1.15);
Page->Height=Page->Height+(Page->TabHeight*1.15);
Cancel->Top=Page->Top+Page->Height+(Cancel->Height*0.15);
OK->Top=Cancel->Top;
ClientHeight=OK->Top+(OK->Height*1.15);This takes ~310ms on 64-bit and ~530ms on 32-bit to execute: for (int cTabIndex = 0; cTabIndex <= Page->PageCount-1; cTabIndex++)
Page->Pages[cTabIndex]->TabVisible = False;I timed this using code so it is accurate. It also agrees with the difference found from the video recording method above. UPDATE2: This still not reverted to previous fix: |
Cherry picked to this branch |
Oh this, insignificant. Still it cannot take half a second. Mine isn't 5 GHz. And what's more it's VirtualBox. So it's slow, very slow. But once again - this (whole screen2gif-2024-07-05-0754.webm |
|
I made a commit here, so you measure it. However, moving |
|
Hi I've been waiting for this feature for a very long time. Apparently, there has been no progress since then. Can we find out what's holding things up? Thx in advance. |
|
There was no response back then, so switched to other projects. But need response on relevant questions (not that there are tabs, not spaces, as it can be fixed in a second). But i still maintain VM with CPPBuilder (as don't want to mess up old Delphi on my main system), so i can return to it on New Year holidays. |
|
@JeromeMartinez, it is time to address the elephant in the room. This Pull Request is the definitive proof that the lack of basic UX features in MediaInfo is not a technical limitation or a "priority" issue, but a deliberate choice to spite the user base. The request for a resizable window that remembers its position has been a top-tier grievance since 2007. Here, a contributor has done the heavy lifting, provided the code, and solved a 17-year-old problem for you. Yet, you let it sit here. Let’s be clear: by intentionally keeping the free GUI crippled and archaic—even when working patches are handed to you on a silver platter—you are simply holding user ergonomics for ransom. You are leveraging your functional monopoly to create a "frustration gap," forcing people toward your paid App Store versions by refusing to implement OS standards that have been universal for three decades. Using the "Open Source" label while acting like a cynical proprietary vendor who ignores the community is transparent. Rejecting or ignoring a working fix for a 17-year-old bug isn't "managing a backlog"; it is strategic stagnation and extortion. Stop pretending you don't have the resources. You have the code right here in front of you. The only thing missing is the professional integrity to stop treating your users with contempt. |
|
This PR would have been merged earlier if the contributor was willing to have a PR only for the remember window size and position feature. Most of the unresolved issues blocking this PR were due to the other changes made together in this PR. By the way @JeromeMartinez you can remove me as reviewer for this. I no longer use the VCL version or have C++ Builder installed. |
|
The poster above doesn't even know what he's talking about. There is no paid app store version for Windows and the one in Windows Store is outdated and even more lacking than the VCL one. If wanting to proof something, this PR is proof that VCL is a poor framework where even features like this need so much manual work and causes many side effects. C++Builder Community Edition seems to be basically abandoned by Embarcadero. There are no new updates for over a year despite 3 newer paid versions available and the current free version being so buggy. They do not even support Windows on ARM or properly integrate with Windows 11 design, resulting in user complain about lack of rounded corners in menus. Maybe it's time to switch to a better framework that requires less work for basic things and is easier to maintain as well as supporting newer OS and architectures along with being guaranteed to remain supported for free. Other open souce apps are moving from wxWidgets to Qt for example. |
|
@cjee21 this is a bit more complicated, both technical and also about how I plan to do in the future as a whole. |
It's not possible with GitHub. It had to be completely reset and then cherry picked line by line in diff into different branches. So first it had to be finished. And it mostly was finished. Although then there wouldn't to be much of need in those multiple requests.
VCL is by far more advanced and simpler than anything Qt can offer. It's just lack of experience with it that leads to all problems. But Qt is far more complicated. And what exactly and what is proving what? Reading from many files will be as equally slow in Qt. |
|
It takes more lines of code to do the same thing in VCL than it does in Qt. Dark mode in VCL is lacking aero titlebar on Windows 7, mica titlebar on Windows 11 and window shadows on all Windows versions. It respawns entire window when toggling dark mode. The menu bar's drop-down menu has no rounded corners on Windows 11, there is a user complain for that. The preferences window item has to be manually aligned taking much more time to add a single item compared to other frameworks. The items in preferences window does not auto resize when the preferences window is resized. The integration with IE or Edge WebView2 still glitches out sometimes with blank display for HTML view. VCL requires a custom compiler that even Embarcadero seems to have trouble keeping updated, it is still using very old Clang that does not support ARM64, no CFG, cannot compile code in parallel. How's that far more advanced. Since you are experienced in VCL, maybe you can fix some of the above. I am not the right person to be doing VCL work. One more thing to improve for MediaInfo VCL version that is not related to VCL vs Qt framework is that the VCL version GUI hangs with not responding when MediaInfo takes longer to parse files due to it being run on main UI thread. There's also user requests for ability to customize the font used. Let's not even talk about the buggy C++Builder IDE that has broken autocomplete and code lookup among other issues and annoyances or the quality of Embarcadero's documentation for the C++ APIs. |
Windows 7 doesn't have dark mode. And it doesn't matter since Qt6 doesn't support Windows 7 any longer.
Absolutely not. Especially if using Pascal. But even with C++ still VCL is far more simpler. And Qt6 doesn't have proper high DPI scaling. They ditching proper DPI scaling in favor of pixel ratio scaling, similar to browsers, which is unacceptable for applications.
Neither in Qt. It's up to Win32 style. This is 6.10.1 with Win32 style.
It's just a component property. It's equally simple in VLC/LCL/WF/Qt etc etc.
Well, yes. It doesn't support ARM64 as of yet. It's where Free Pascal/Lazarus/LCL beats them all, supporting x86, ARM, RISC-V, MIPS, LoongArch etc etc and any type of system - Windows, Linux, macOS, other BSDs etc etc - trully cross platform.
RefreshFilesList is a part of MediaInfo itself, not MediaInfoGUI. It's not using VCL. And Qt version is not using RefreshFilesList. Also it doesn't read content of locale files. It just using filenames. That's why it happens fast. It also doing it once at form creation. That's why you don't see UI lag. It's, again, just matter of implementations. You can do the same with VCL. It's also doesn't store locales in files on disk, instead reading them from resource. Although it makes it a little slower. Moving it to form creation was one of that change you didn't like.
There is no Edge in Windows 7. And VCL version is using TWebBrowser. Although there is TEdgeBrowser, at least in CppBuilder 12. But TWebBrowser/TCppWebBrowser are using SHDocVw.dll, which is Trident (Internet Explorer).
That could be fixed in a single click. VCL has better alignment capabilities than Qt. LCL is even more supperior, but no C++. And this was among fixes. |
|
I've reset my master and updated CppBuilder. In coming days i'll readd changes with multiple branches and multiple merge requests. |
Doesn't support (technically Windows 10 does not have dark mode for Win32 apps either) but users will still want dark mode and MediaInfo VCL does have dark mode on Windows 7 although it looks non-ideal. We can use older Qt to have a separate build for Windows 7 if needed but MediaInfo Qt is not yet deployed for Windows and will likely only be used to replace UWP one in Store so let's not talk about this.
Simplify it then. Maybe I am not good in VCL and implemented dark mode in non-ideal way. In Qt it takes less than 10 lines of CPP to control dark mode and it works out-of-the-box on Windows 11 with zero lines of code if just following system settings. Well adding conformance button to VCL and Qt each took around 40 lines of code so fair enough but adding new setting still feels faster and easier in Qt, maybe due to MediaInfo's VCL codebase not in ideal condition.
Whatever they did, at least it works fine with zero additional code unlike VCL which requires so many bugfixes previously.
Mica titlebar, window shadows, rounded menu drop-downs... 
I am not taking about the preferences window and this is not related to framework as I said. It is just something to improve in VCL version. There should be a progress bar or something while MediaInfoLib is opening files instead of freezing the entire UI.
You can move it now if it does not break anything. I am no longer touching the VCL codes anyway so do whatever you want.
There is Edge WebView on Windows 7 and MediaInfo's VCL GUI currently will use Edge WebView 2 whenever available. It has also been tested on Windows 7. Any way, whether IE or Edge, the HTML view just feels fragile. Will be great if can be made more reliable.
Okay. Go align it so that there is no longer need to manually shift items manually pixel by pixel when adding a new option in the future.
Great. Just take note that the official build farm is still using C++Builder 11 to maintain compatibility with Windows 7 (according to Jerome, the binary built with ver 12 does not work on Windows 7 out-of-the-box) so it should still be build-able with version 11. |
|
btw make sure all alignment is pixel-perfect on all DPI settings. If it is even off by 1 pixel, someone named Klaus1189 will create an issue report. |
It was already among fixes.
Community edition has limited time license. Mine run out. It's not possible to obtain RAD Studio 11 licenses anymore. But it doesn't matter much.
But custom drawn components and icons are not crisp. Especially on non-integer scales. Because there is no direct pixel access.
I don't see it in code.
But it won't be Win32 style. Essentially it comes down to matter of taste, but there is nothing wrong in prioritizing system style. I always use windowsvista theme with Qt apps. So it's still same lines of code to allow to select and switch it. Main menu of Qt version isn't nice, btw. At least light version. Just black outline instead of shadow. And way too rounded. And scaling has its bugs as well. Main menu isn't properly scaled. And tree view items aren't scaled.
Well, Qt version has progress bar implemented, but it's not VCL fault, that it's not implemented in VCL version. But there isn't much need for progress bar for 1 second. |
I thought you are very experienced with VCL. I wonder why you cannot see it.
All of Microsoft's new apps and OS UI uses WinUI3 which can be considered 'custom drawn' like Qt. There are no sharpness issue with both. Older Win32 apps are the ones lacking crispness. Isn't custom drawing direct pixel access? But I don't want to talk about this anymore. Does not matter here. Actually VCL styles are doing custom drawing and it seems to be needed to get dark theme with it so what's the point.
It's not too rounded. This is Microsoft's standard menu for Windows. I do not see scalling issues in MediaInfo Qt. On 100% and 150%, everything looks exactly identical except the DPI unlike the other GUI where buttons and alignment are different. Traditional Win32 apps no longer look native on Windows 11 or meet the design guidelines. Qt actually attempts to follow the latest Microsoft design guidelines on Windows 11. Doing so requires custom drawing like Microsoft's own WinUI3 framework. There are issues with Qt's menu shadows and the roundedness does not fully match Windows style but a fix has been committed for Qt 6.11 which should use Windows provided border and shadows for the menus instead of manually drawing.
MediaInfo Qt 6.11 
Try opening 10+ 1GB MPEG-TS files and watch the GUI hang. Also note that some users open thousands of files at once with MediaInfo GUI. There was such a user in one of the issues here that ran into some 32-bit bug. And like I alredy said, this is not framework problem. Just that it is something that can be improved in VCL version to prevent UI hangs. Just letting you know since you may want to do something about it since you are good at VCL coding. |
This is a problem with my code, I know, there is a lot to do on it, and at some point I'll refactor that. And this is a bit out of topic... |
I would be glad if you point me a place where that WebView2 declared and created. But so far I can only see TWebBrowser.
I do. And I pointed on them with screenshots. "Kind of works for me" is not an answer.
I tried 100 GB files. Under 1 second per file. A 1000 could be long, but, again, threading is implemented in MediaInfo itself, not in Qt GUI. It can be used with VCL GUI as well. It is, however, requires some extensive rework to switch to Core unit. But wouldn't be long to implement some of VCL's threading solutions.
Win32 is Win32. WinUI is WinUI. They both natively looking. One is for desktop (what is nowadays some call business UI), another is adaptive UI. Qt UI is that desktop UI. Qt has QML for adaptive UI. You using either of them. It doesn't go together when parts of interface have giant oversized touch oriented elements and other small desktop and mouse oriented elements.
But there is. Just because it's oversharing final image it doesn't means it sharp and DPI native.
No. With pixel ratio scaling pixel itself is scaled, so it's virtual. You can't draw a single pixel. At 200% minimum you can access is a group of 4 pixels. Basically saying it's raster scaling very same as System scaling. Just adds more sharpness and draws text after scaling. |
This is one thing that VCL does make easy. MediaInfo/Source/GUI/VCL/GUI_Main.dfm Line 586 in 8cf99f0
I do not see any issues with your screenshot. The scalling issues I talk about are how using different scalling results in different layouts/looks/alignments. If you mean Qt's menu design is not spaced properly, that's not scalling issue but how they chose to design it. They aim to follow Microsoft's fluent design guidelines for the new Windows 11 style but are still tweaking it.
But VCL's menu does not even look like Windows Device Manager's menu and that's why there is an issue created by someone here.
I'll just let AI answer:
and in normal use, the abstraction is helpful so that you do not need to manually calculate and scale everything. The underlying framework scales things before painting the raw pixels ensuring everything has the same look regardless of scale and remains sharp. They do custom drawing on the actual pixels not draw then scale by interpolation. Win32 apps like Device Manager are the ones using GDI scalling and are not as sharp. PS. btw frameworks like Qt, I mentioned that is requires less code which is true in some aspects. They have many built-in functions like handling temporary files or remembering window state and position. So they do not require 100 lines of code to manually do it. MediaInfo Qt already has remember window size and position implemented by @JeromeMartinez years ago but it took this long for VCL. By using such frameworks, more time can be spent working on other parts of MedaInfo. The buggy C++Builder IDE compared to Qt Creator and Visual Studio also means more time to write the same amount of code due to broken auto-complete and code look-up for example. The poor documentation by Embarcadero does not help too. One thing VCL helps more than Qt is integration with IE and Edge, whereas Qt requires self-implementation of Edge WebView if not using QML at the moment unless wanting to bundle Qt WebEngine. VCL's integration with IE and Edge does not feel very solid though (glitches and crashes seen before) or maybe that's due to how MediaInfo GUI uses it. Anyway, let's stop debating frameworks. We have said what we wanted and it's clear that we will not reach any conclusion. |
5 participants
Added optional ability to save window position and/or dimensions.
Also improved Preferences form a bit. Everything is aligned now. And it's resizeable now, which is more convenient.