Title bar sometimes goes above top of screen #653
Comments
|
I suspect this is not related to DupeGuru. If it's not related to Windows itself, it could be a Qt bug? |
|
Well, Windows 10 is an unmitigated disaster in many respects, not the least of which is the UI, so it wouldn't surprise me if it's the problem, and in fact it's generally my first assumption for stuff like this. That said, dupeguru is the only program I've experienced this particular issue with, so it seems to be something specific to it. I'm not sure how many other programs, if any, I use that use Qt (there is/was something else, but I can't remember what), though I suspect not many, so it's quite possible it's a bug with that, which would explain why I don't see it with other programs. |
|
Need to investigate more. For reference, a solution to this problem might be worked on here. On Linux (X11) there is no such problem since windows can be move with meta key + mouse. But I may have noticed this issue happening. |
|
You can move a window in Windows with the keyboard as well, it just takes jumping through some hoops. You have to shift + right click the icon on the taskbar, click move, then push one of the arrow keys on the keyboard, after that the window will stick to your mouse so you can move it wherever |
|
Yeah, I know. Usually I do Alt+Space to open the window's menu and select move there. It didn't work in this case because that combo was assigned to another app, which I've now changed. At the time it didn't seem like a big deal since, as I said, I figured I could just close and reopen it. So aside from the main issue mentioned, the fact it says there are unsaved results yet they can't be used is another problem (perhaps I should create a separate issue for that, but I figured I'd wait to see if I'm just missing something). |
|
That appears to be different. That issue deals with the entire window being shown on a different screen, one that's not even present, which is something I experience a fair amount myself with other programs. From what I've read, it's because Windows can't differentiate between an active and a non-active display or something like that (typical POS Windows issue). IOW, an OS problem that, in order to avoid it, requires extra work on the part of individual programs to ensure they work properly. Go M$. Anyways, the fix for that likely wouldn't do anything for this problem. |
|
This is an issue across other QT based apps on windows, I think there is a way to prevent this from happening, just need to perform a similar check as in #525, but instead of moving the window resize it to be within the available space (moving could push the bottom off screen). |
|
I may be misunderstanding what you're suggesting, but that seems like it would be problematic. If it doesn't need to be resized, it could just end up making it smaller, which wouldn't be wanted. For example, if the window height is already only 30% of the screen height, and it's resized by 50 pixels or whatever, it would just make it so it's now ~28% of the screen height, which would be totally unnecessary and probably annoying, especially if it keeps getting smaller each time. Shouldn't it first check to see if there's room and, if so move it, if not, resize it? And even then, if it's resized, could it still end up partially off-screen, just smaller? The resize would have to be done specifically to bring the top down, not have the bottom come up. |
|
Part of the issue here is the fact that some times when this happens the window is already the full height of the display (or more) causing the title bar to be above the monitor, while the bottom of the window is at the bottom. So there are extra checks needed here, to resize if that is the case. If the window is already small enough to fit then it just needs to be moved. Currently the move just moves the window to the center of the nearest monitor if it is off-screen. I have looked at the code changes in #525 and have found a way to account for this better. I think I have this working, although I need to add some extra handling around maximized operation to help improve the user experience with that (opens maximized on the last monitor used). |
- Update both qt/directories_dialog.py and qt/result_window.py to have the same resizing on out of bounds. - Update moveToScreenCenter to do most of the checks needed - Add additional preference to help track maximized position of results window
Bug / issue Report
System Information:
Description
Twice now in the past few days I've had the results screen end up being placed with the title bar off-screen. The first time it happened when I clicked the show desktop button on the right edge of the taskbar, which minimized it (as well as everything else) and when I restored it, it was like that. I'm pretty sure it was maximized to begin with that time. Just now, it happened when I had it normal size (i.e. not maximized) and minimized it then, a few minutes later, restored it. So it doesn't seem to matter the state of the window to begin with, but minimizing then restoring it sometimes does it for some reason.
I ended up just closing the window, figuring I could just "reopen" it by clicking the "Load Results" button, but that apparently doesn't work as expected, since even though trying to run a new scan or close the program causes it to say there are unsaved results, you can't load them, and they don't show up in the File > Load Recent Results list, which is empty. So I had to redo the scan all because of the window being partially off-screen.
The text was updated successfully, but these errors were encountered: