I have a laptop (Thinkpad T15) with a 4k screen and a second 27" 4k screen attached to the laptop.
When I move the scrivener Window between the two monitor, it’s fonts (including menus) get enlarged when moved to the external screen and made smaller (even smaller than the original starting size) when moving back to the laptop screen. Also, the menus get misplaced, instead of opening up right underneath their titles. (screeen shots can be provided on request - I wasn’t able to attach them straight to this post)
Other applications seem to handle this more gracefully.(particularly the places, where the pulldown menus open up)
Has anyone else witnessed this - and knows how to “fix” this?
Strange that it does this between 4k displays, never thought it would be the case. 4k and 1080p, understandably. Be that as it may, do this:
Maximise the project.
Then select Win+Shift+Left or Right Arrow (depending on the direction of your external display) to move between screens.
It won’t work if you don’t maximise first, and dragging breaks the maximised window effect.
And no need to install third party apps that look like something dodgy from the 90s.
It appears it’s a limitation of the Qt framework on which Scrivener is developed for Windows, though I’ve never seen boo or baa to confirm this.
Obviously, you’ll get more real estate out of the 27” now, but the unsightly shrinking or over large effects will disappear.
Thank you - that indeed does help - albeit being very clunky to use. But since I use scrivener for longer periods, doing this once to move it removes a lot of the pain.
I’d consider reposting the problem to the Qt forums then, so that they might also shine a light on how to fix this in the first place.
For the moment, though, I’m happy that this seems to work.
The key takeaway there is that its an issue between Windoesn’t and the programming framework used under the hood by Scrivener. Using the windows key & arrow keys was the suggested workaround.
It’s not a common across Windows apps. M365 apps, many “b-class” apps don’t have the constraint. While Scaling and Resolution on different size monitors count, the resizing is relative to the original, not a near invisible miniaturised version if switching to a wider screen or an unusably large display when switching to a smaller screen.
It shouldn’t be necessary to adjust displays for the sake of an app. Maybe there’ll be feedback from the OP contacting Qt. Meantime, the workaround is a minor inconvenience, if at all.
Agreed. I was just responding to your comment “strange”. I’ve seen in a number of threads how Scrivener/QT has issues with windows moving across monitors with different physical or logical (due to Windows settings in scaling/resolution) monitor resolutions. So, unfortunately, it’s not that strange.
I found it strange, with me assuming 4k is 4k is 4k. Apparently not, as per the OP.
I understand monitors have recommended display settings. My 4k’s recommendation is 300%. That renders a size for someone in kindergarten. I use 225%. My 1080p external monitor is recommended for use at 100%. I use the setting. The monitor is more than ten years old.
Of course, the Win+Shift+relevant Arrow Key (with Window maximised for the switch) keeps things consistent between monitors. And it keeps the setting if you reduce the window’s size after switching. But switching again, requires maximising first.
there were different settings for scaling – though, when I set them to the same value (150%) on both, the problem still persisted, when moving windows across.
You can Read the Code of KDE/Kate, Kate use QT6, it have no Hi-DPI codes but works correctly on windows. QT6 has enable HiDPI Support by Default, so you can delete all the old Hi-DPI support codes and then it will work correctly.
The Scrivener Window Size Scaled correctly, but Window Content repaint with the previous monitor’s DPI. It seems that the code you wrote to adapt Hi-DPI for QT5 conflicts with QT6.
Thanks, our medium-range plan is to get the codebase updated to 6.8.x, which does include better support than the current base we are using, particularly for Win 11, I think (that’s where we started to see an uptick in these reports).
Shorter-term the next update probably won’t address this. It would be nice, but there are several tricky problems with integrating the 6.8 branch (really they extend back to 6.5 I believe) that need to be sorted as well, such as images in the editor not loading until you mouse over the area where they should appear, and font handling / rendering not quite working right.
So it is definitely something we are going to address, but it might be a little while yet. Thanks for the tip on maybe rolling back any compatibility code we might still have. I think most of it was removed in the jump to v3, but there might still be some.
I have two monitor, one use 100% scaling (96dpi), another use 150% scaling (144dpi).
When I move Main Window to 100% scaling (96dpi) monitor, it use 150% scaling (144dpi) and looks too big.
When I move Main WIndow to 150% scaling (144dpi) monitor, it use 100% scaling (96dpi) and looks too small.
It appears that when the window is moved to another screen, it reads the previous screen’s DPI (not the current), causing errors when redrawing the interface.
But QT6 has enabled cross-screen DPI switching support by default, requiring no manual coding logic. Could you please resolve this bug and release a new version as soon as possible within working days?
doesn’t this happen with other programs like browsers too. Isn’t the real issue is the monitors are too disparate in viewing interface. What programs do you have that automatically adjust in this situation?
No. Browsers and other apps, such as Word, can correctly handle repainting windows as they move between multiple screens, but Scrivener cannot. Scrivener always zooms out when it needs to be zoomed in and zooms in when it needs to be zoomed out.
It would be nice, but there are several tricky problems with integrating the 6.8 branch (really they extend back to 6.5 I believe) that need to be sorted as well, such as images in the editor not loading until you mouse over the area where they should appear, and font handling / rendering not quite working right.
