Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.95%. Comparing base (6b5aebe) to head (d66e9c2).
Report is 12 commits behind head on main.

@@           Coverage Diff           @@
##             main    #3814   +/-   ##
=======================================
  Coverage   88.95%   88.95%           
=======================================
  Files         256      256           
  Lines       14584    14584           
=======================================
  Hits        12973    12973           
  Misses       1611     1611           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Ah, good point. It does not do any of that. It just uses the last size exactly as it was. We could indeed clamp it by the screen size.

Interesting. For me it still works fine 🤔 I'll add some logging to help with debugging.

I've tested on my desktop machine which is 1920x1080, Kubuntu 24.10, and I don't get the regression for remembering window size that I did on my Framework. However, the "clamping" does not appear to work: if I resize a window to 1680x1050 when on 1080p then set my display resolution to 1440x900, it opens up a window that is larger than my screen resolution. Additionally, the logs do not provide the actual numbers they just say "Instance of Size" etc, but I'm not sure if that's intended or not on your end

(this is my desktop even though the username is 'frame')

Ugh, the logs do not print the actual values of Size and Rect in release mode, only in debug mode 🙄 I have to update that.

The clamping behavior works on my 1080p desktop but the clamping resolution ends up being the resolution of the entire screen so the GUI is cut off vertically. We should apply the better default size logic when clamping as well in my opinion

The logging revealed the reason why the GUI was not remembering the window size on my Framework laptop: for some reason, flutter thinks my laptop's resolution is half of what it actually is, so when I size it larger than half of the screen it clamps to half of the screen. It correctly remembers the screen size for sizes smaller than 1128x752. We could just have this as a known bug for the framework laptop, or put in unique code for when the screen size 1128x752 is detected.

Interesting! I see that in your second screenshot, the screen has a scaleFactor: 2.0, so I think we need to take that into account when doing the calculation! It may be some fancy HiDPI stuff.
Also, yes, I agree that if the last window size is too big for the current screen, we should just apply the default size instead of this clamping. That makes more sense.

Alright, I looked through the plugin code and I can confirm that scaleFactor is related to fancy HiDPI stuff. On most normal monitors, it is 1, but on HiDPI ones it can be more, often 2. I think that also explain why the screen size was behaving weirdly on macs, since I think they have HiDPI screens. Now I need to figure out if we need to divide or multiply by that number 😆

@levkropp, apparently on macos this does not seem to be an issue (at least in my case). My mac also has a scaleFactor of 2.0, but the returned screen size matches the one from my system settings. So perhaps this is a Linux only issue? Could you perhaps take over this PR and see if you can make it work on your scaleFactor 2.0 screen? I don't have one, so I can't test it 😅