Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test errors for Focus on X11/Arch with latest CPython/Qt/deps #568

Open
paulie-g opened this issue Jan 19, 2025 · 3 comments
Open

Test errors for Focus on X11/Arch with latest CPython/Qt/deps #568

paulie-g opened this issue Jan 19, 2025 · 3 comments

Comments

@paulie-g
Copy link

Getting errors for focus-related tests on an up-to-date Arch under X11 with latest cpython/qt/qtpy/etc. Tested under a clean openbox config, so oughtn't be WM shenanigans. Log attached. Happy to provide any info if requested.

fail.log

@frmdstryr
Copy link
Contributor

I get the same errors (even before the recent changes).

I think the test is broken on linux because the window is not popping up, but it works fine if the source saved to an example.

@frmdstryr
Copy link
Contributor

frmdstryr commented Jan 19, 2025

Adding qtbot.wait(100) to the end of wait_for_window_displayed makes it pass for me.

def wait_for_window_displayed(qtbot, window, timeout=1000):
    """Wait for a window to be displayed.

    This method should be called on already activated windows (the show method
    should have been called).

    """
    if not window.proxy_is_active or not window.proxy.widget:
        msg = 'Window must be activated before waiting for display'
        raise RuntimeError(msg)
    qtbot.wait_exposed(window.proxy.widget, timeout=timeout)
    qtbot.wait(100)

@paulie-g
Copy link
Author

I get the same errors (even before the recent changes).

Glad you were able to reproduce. I can confirm that the qtbot.wait works to get the tests to pass, even with a value of 25 (on my machine).

I suspected that it's just a timing issue, the reason I brought it up is that distro packages run your testsuite and fail to build on any errors. One response to that is "well, don't do that silly thing, not our problem". Obviously a comprehensive test suite is valuable for dev in terms of regression testing, and no one says everything has to pass on every platform and with every build option (which is why running a test suite meant for regression testing in a package check stage is braindead). However, expecting packaging practices to change is sadly isomorphous to tilting at windmills. Might I suggest, as a low priority matter, to provide a less extensive integration test suite validating basic functionality as a default instead? And obviously inserting a charitable delay to get the tests to pass for now so currently broken packages actually build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants