Mnt: Block qt6 6.11.0, 6.11.1 due to dock widget and resizing bugs

[TimMonko]

References and relevant issues

xref #9054

Zulip discussion: https://napari.zulipchat.com/#narrow/channel/215289-release/topic/0.2E7.2E1.20-.20pop.20out.20widget.20bug.20on.20Qt.206.2E11.2E1.20.28latest.29/with/602196289

Description

This blocks Qt 6.11.1 versions because of docking issues detailed in #9054. Carlos and I worked on this at today's community meeting. We blocked this Qt version for both pyside6 and pyqt6-qt6 (because pyqt6 is still just at 6.11.0) in pyproject.toml

Then we used the following:
tools/compile_constraints.sh pyside6
tools/compile_constraints.sh pyqt6-qt6

Update: I've opted to also block 6.11.0
I do think, in the case of critical functionality aka the GUI, we should probably err on the side of conservative. Especially because there's not like computational/speed benefits or somethign that we lose

Alternatively

1. Qt < 6.11 <- the absolute safest pin, but I really don't like upper pins, they seem to be actively working on it.
2. Qt !=6.11.0, !=6.11.1 also more conservative, and maybe the safe play. But in all my time debugging Fix floating widgets and use custom title bar in all cases #8898 and today while debugging 6.11.0 never caused issues, and is the reason I haven't adopted it (or an upper pin)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.51%. Comparing base (abe6827) to head (d0e56cc).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9052   +/-   ##
=======================================
  Coverage   93.50%   93.51%           
=======================================
  Files         710      710           
  Lines       66408    66408           
=======================================
+ Hits        62094    62100    +6     
+ Misses       4314     4308    -6     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[psobolewskiPhD]

You need to edit the version_denylist files as well, otherwise the bad versions will come back in constraints.

[TimMonko]

You need to edit the version_denylist files as well, otherwise the bad versions will come back in constraints.

I wonder if that is changed behavior? Because I ran the bash script (tools/compile_constraints.sh) to get these changes, which is what the constraints bot also does -- I'd presume the result would be the same. I will still push to the version_denylist though. Circling back to edit this now. :)

[psobolewskiPhD]

Also you didn't want to nuke 6.11.0 too? I think it's best since we know it has issues as well.

[TimMonko]

Also you didn't want to nuke 6.11.0 too? I think it's best since we know it has issues as well.

I was waffling back and forth. Ultimately that's what @carlosmariorr and I opted for. I'm certainly open to it -- can you clarify what known issues it has? As far as I have personally tested, 6.11.0 works for our current main. I know we've both seen the Qt6 Jira board and that does imply some bugs though. Ultimately, I'm conflicted on it 🤷

Also, in practicality, I ended up debugging constantly on 6.11.0 to try to figure out differences between it and 6.11.1 today, without finding any issues

[TimMonko]

version_denylist.txt does not need updated, see napari/docs#1043
The decision is still up to whether we want to block 6.11.0 in addition to 6.11.1 in pyproject.toml
@Czaki I'm ok with either (same to you too @psobolewskiPhD) this is just my "preference". Feel free to change this as needed.

[psobolewskiPhD]

Yup to you. I outlined the oracle reasoning in the zulip thread but the gist is:
6.11.0 is a .0 release that introduced multiple bugs.
6.11.1 fixed some, but others were unmasked (partially by the #8898 )
So the safest thing is to block both, pushing people back to a stable release from 6.10 which has been out for a long time.
But I am in general risk averse, so take it or leave it.

[TimMonko]

I've opted to also block 6.11.0
I do think, in the case of critical functionality aka the GUI, we should probably err on the side of conservative. Especially because there's not like computational/speed benefits or somethign that we lose