Dialogs add offset to their last remembered position

[roachcord3]

Hydrus version

v608

Qt major version

Qt 6

Operating system

macOS 15 "Sequoia" (Intel)

Install method

Running from source

Install and OS comments

Note: I skipped v607. When upgrading to v608, I also switched Python versions and started using this test version of PySide6. I was running on macOS 15 before, so the cause is either something in 607-608, or it's the Python or library version change. It's also worth noting that I tried PySide6 6.8.2.1 but it didn't help anything, the problem persists.

Bug description and reproduction

After upgrading to v608, dialogs that are set to remember their last position always open at a lower screen position each time. They have to be dragged up, whereupon subsequent openings make them droop again. While I wish I could say for certain how much the drop is in terms of pixels, it's definitely enough where tall dialogs (like the manage tags) one have their bottoms fall off the screen after just a few times. Changing the dialogs to not remember their last position works around the problem, but is inconvenient for its own reasons.

Log output

[hydrusnetwork]

Thank you for this report. I don't have a macOS machine to test with, so we may have to do a little back and forth here.

Please do this:

• tell manage_tags_dialog (which is the thumbnails version of the dialog) to remember its last position again, and then open and apply-close it once to establish a new position. Make sure it has some buffer space on the bottom of the screen so it can move without overlapping
• Go into the options dialog and write down its saved 'last position' coordinates.
• Open/apply-close it again.
• Go into the options dialog and check hows its saved coordinates have changed.
• For good measure, let's do the cycle one more time to see if it is the same coordinate-delta every save.
• You might like to do it with another window, let's say review_services, and see if it is the same delta.

And please let me know what you see. If we discover that every window is adding (3, 12) on every save cycle, that suggests I am screwing up my position calculation by forgetting to account for title bar height or something. I know macOS has some funny rules about menu bars and title frames--when you open up 'manage tags', do you get any weird flicker as it initialises? Does the 'manage tags for 1 file - hydrus 608' text appear on top of the window, or does it embed into a system program bar at the top of your screen? Does it start in one place and move to another? Could the vertical delta be exactly the height of your system top bar (forgive me I don't know what macOS call it)?

[roachcord3]

Ok, for the manage_tags_dialog, size (758, 914), set to remember its last size, the positions were:

1. (24, 105)
2. (24, 161)
3. (24, 217)
4. (24, 273)

So it is adding 56 to the Y coordinate each time. I tried again with a different initial position (reset its last position, opened it, dragged it up to the top of the desktop where the menubar is, and a bit to the right, then apply-closed it), here are the results:

1. (110, 25)
2. (110, 81)
3. (110, 137)

You get the idea.

As for review_services, size (963, 996), not set to remember its last size, the positions were:

1. (25, 77)
2. (25, 105)
3. (25, 133)

Looks like it's adding 28 each time to this one.

when you open up 'manage tags', do you get any weird flicker as it initialises?

Nope

Does the 'manage tags for 1 file - hydrus 608' text appear on top of the window, or does it embed into a system program bar at the top of your screen?

The top of the window, but it doesn't say the thing you say it should say. Here's a screenshot of what both look like.

Could the vertical delta be exactly the height of your system top bar (forgive me I don't know what macOS call it)?

No, we can see it's different for different dialogs, but even if it wasn't, the Y coordinate from my 2nd test with manage_tags_dialog where I dragged it up and to the right, its starting Y coordinate of 25 indicates that the menubar is likely 24 units tall. Neither 28 nor 56 are multiples of 24, though it is worth noting that 56 is a multiple of 28, I guess.

[hydrusnetwork]

Thanks, this is fantastic. I will investigate this next week and see what I can figure out. Let me know if it changes in v610!

[hydrusnetwork]

Hey, I got caught up in some other rewrites this week and did not have time to check this properly. Please delay until v611, sorry!