Thanks @Czaki for your work here! Seems like we can go with this approach. Then the only missing thing here would be to try to add a test for this but other than that this LGTM 👍

After last PySide6 problems I need find way to test it.

How to deal with

UserWarning: Existing QApplication <PySide6.QtCore.QCoreApplication(0x55e7bf91d090) at 0x7f4563b26b70> is not an instance of qapp_cls: <class 'PySide6.QtWidgets.QApplication'>

UserWarning: Existing QApplication <PySide6.QtCore.QCoreApplication(0x55e7bf91d090) at 0x7f4563b26b70> is not an instance of qapp_cls: <class 'PySide6.QtWidgets.QApplication'>

My guess is that that could come from using the qapp fixture maybe? Or where are you seeing that warning?

Also, for the test, maybe using a QTimer singleshot instead of a QThread to handle the dialog could help? Or maybe the thread code should run inside a while True block which breaks when an instance of QFileDialog is found and closed?

Also, for the test, maybe using a QTimer singleshot instead of a QThread

No. Timers are implemented in Qt as events put in the main queue event (for performance). Especially in documentation, there is:

On Windows, the dialog will spin a blocking modal event loop that will not dispatch any QTimers, and if parent is not nullptr then it will position the dialog just below the parent's title bar.

I have also observed problems with timers in such scenarios in the past. It happens that they are not triggered on CI when another event loop is started.

There is a check if the thread is closed before the end of the new test.

My guess is that that could come from using the qapp fixture maybe? Or where are you seeing that warning?

Yes but I do not know where it is created.

My guess is that that could come from using the qapp fixture maybe? Or where are you seeing that warning?

Yes but I do not know where it is created.

Seems like there is a fixture that is called qapp_cls. Maybe the warning is related with it? https://pytest-qt.readthedocs.io/en/latest/_modules/pytestqt/plugin.html#qapp_cls

It looks like source of all problems was lack of some libraries in system. It looks like it is possible to unskip more tests.

Are you think it is worth?

It looks like source of all problems was lack of some libraries in system. It looks like it is possible to unskip more tests.

Are you think it is worth?

Oh that's good to know! I think it would be great if we can unskip tests!

Oh that's good to know! I think it would be great if we can unskip tests!

done in #434

It is ready. I prefer to fix #434 first and then resolve conflicts.

Too many projects with black and ruff in pre-commit when there is no need to check formatting in base case as it will be auto fixed.

No worries. We're actually behind the times on that front but the thing is we have a lot of code to maintain and little time to do that sort of devops work.

Do you know some simple to set up GH actions to get started with Black and Ruff?

In napari, we activate pre-commit.ci tahat is free for OSS, automatically makes update commits and automatically create PR with the update of items in .pre-commit.yaml

Starting configuration could be two first entries from: https://github.com/napari/napari/blob/main/.pre-commit-config.yaml

Black configuration could be:

[tool.black]
target-version = ['py38', 'py39', 'py310']
line-length = 79
exclude = '''
(
  /(
      \.eggs
    | \.git
    | \.hg
    | \.mypy_cache
    | \.tox
    | \.venv
    | _build
    | buck-out
    | build
    | dist
    | examples
    | vendored
    | _vendor
  )/
  | napari/resources/qt.py
  | tools/minreq.py
)
'''

Our Ruff configuration is here:
https://github.com/napari/napari/blob/78b0f3f05a9eb7876f4875ddf01dbd03cfbe9f49/pyproject.toml#L56-L146

Another project that I maintain has this configuration:

https://github.com/4DNucleome/PartSeg/blob/aacc4284f73ee1b04e8aca6d86be0731fdac3a14/pyproject.toml#L34-L91

Both may be a good starting point requiring adjustment.