Fix TypeError: 'NoneType' object is not subscriptable in StartDownloadDialog.__init__()

[drew2a]

This PR addresses issue #7641 by introducing a new flag ui_started, which is utilized to ascertain the appropriate time to proceed with URI handling.

[kozlovsky]

I think the suggested fix can solve this specific issue. However, the implementation does not look entirely correct to me.

Currently, the tribler_started flag means that:

1. The Tribler Core process has already started, and
2. The EventRequestManager of the Tribler GUI process has already established a connection to the Core process events stream.

The name of the flag does not make it intuitive that these (and only these) two conditions are satisfied at the moment when the flag is currently set.

When the current PR moves the setting of the tribler_started flag to the beginning of the start_ui method, the meaning of the tribler_started flag is changed to the:

3. ... and settings were already received from the Trible Core

This PR change makes the meaning of the tribler_started flag even less clear. Now, as the flag is moved to the tribler_ui function, it suggests that the purpose of the flag is somehow related to the UI, and the code reader can interpret this flag as "the Tribler UI is started". But then it should be placed at the end of the start_ui method, as at the beginning of the method, the UI is not started yet.

Furthermore, this change could affect the previous code. We have a condition:

def on_core_connected(self, version):
    if self.tribler_started:
        self._logger.warning("Received duplicate Tribler Core connected event")
        return

    self._logger.info("Core connected")
    self.tribler_started = True
    self.tribler_version = version

    request_manager.get("settings", self.on_receive_settings, capture_errors=False)

but, after the PR's change, it becomes possible for this code to be executed twice because the line self.tribler_started = True is now executed at a much later stage. If we rename the flag to the tribler_core_connected to properly reflect its current meaning, it will become clear that the flag should be set in its current place.

I suggest to make the name of the flag less ambiguous. It is better to have several flags with precise semantics for each flag:

• tribler_core_started - the Core process is started
• tribler_core_connected - this is what the tribler_started flag means currently before the PR changes.
• settings_received - this new flag we should check to avoid the bug
• tribler_ui_starting - this is how a possible flag at the beginning of the start_ui method could be named
• tribler_ui_started - this is how a possible flag at the end of the start_ui method could be named

We don't need all these flags. However, it may be good to have most of them to reduce ambiguity. The minimal subset that we currently need is:

• tribler_core_connected - instead of the current tribler_started, renamed to avoid ambiguity.
• settings_received - a new flag that we can check in the handle_uri method to avoid the bug we are trying to fix in the current PR. But I can't preclude that actually, in the handle_uri method, we should actually check another new tribler_ui_started flag that could be set at the end of the start_ui method.

[kozlovsky]

Looks good! After this PR the logic is much clearer now.