Fix document mode on macOS

[proneon267]

Apps that specify both document_types and a main_window no longer display the "Document Selection" dialog on startup in macOS.

Fixes #2860

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

This looks like it's on the right track; a note inline about the specifics of the implementation.

[freakboy3742]

This looks like the right general idea, but:

1. It's the wrong place for the code. This should be part of the create_initial_window method.
2. This logic should only be triggered on macOS (or, more strictly, on platforms where CLOSE_ON_LAST_WINDOW=True). On other platforms (Windows, GTK), we need to open a default document, not invoke request_open.
3. There's also an interaction with command line handling. At present, Cocoa uses HANDLES_COMMAND_LINE to shortcut the _create_initial_window handling; I think this means that HANDLES_COMMAND_LINE should only used to shortcut the argv handling.

[proneon267]

I have modified create_initial_window() to correct the bug and added a new core test.

The linux-wayland focus related test failures are unrelated to this PR and cannot be reproduced on my local machine. I thought maybe they are related to document based apps, but testing on my local machine, there is no unexpected dialog being shown during the test that would disrupt the widget focus during the tests.

[freakboy3742]

The refactoring of create_initial_window was really close, but not quite there. There's two very distinct things happening in that method - handling the command line arguments; and ensuring that there is an open window. Your version combined the two; I've split them into two separate parts.

The Wayland test failure is a transient thing that has started in the last couple of days (#2871); we're still trying to work out what is going on there.

Thanks for the patch!

[proneon267]

Thanks for the quick response. Also, could you tell me why in the initial commit of the PR, the tests complained about asyncio.create_task(self.documents.request_open()) not being awaited. I had thought create_task didn't needed to be awaited.

[freakboy3742]

Thanks for the quick response. Also, could you tell me why in the initial commit of the PR, the tests complained about asyncio.create_task(self.documents.request_open()) not being awaited. I had thought create_task didn't needed to be awaited.

create_task does exactly what it says on the tin - it creates a task, and queues it for execution. The task still needs to be executed, however - and executing an async task is effectively "awaiting" the task.