Overhaul app launching, unit tests

[ferdnyc]

(Replacing #4114)

This PR, tested on both Linux and Windows, completely revamps the initial creation of the QApplication instance and the MainWindow class, as OpenShot is being started by launch.py (also significantly rewritten), all in the service of one central goal: completely divorce the application setup (which is done in OpenShotApp's __init__, same as always) from the interface startup, which now lives in a new OpenShotApp.gui() method. Calling that is optional, and the unit tests simply... don't.

When launching the unit tests (from tests/query_tests.py), the interface is never even started, and therefore (by implication) neither is the web backend. Which alleviates the problems caused by QtWebEngine not shutting down properly because it hasn't even had a chance to start yet before the unit tests are completed.

I've also moved all of that OpenGL setup stuff and other housekeeping out of the top of classes.app and put it in launch.py instead, so that it's truly done BEFORE creating the QApplication (or, OpenShotApp) instance. I've always been wary of the fact that we were effectively doing it "while" the instance was being created, not technically "before".

And having it in launch.py means the unit tests can also skip that stuff. It's now possible, in fact, to run the unit tests in a headless environment without needing xvfb, just by adding a -platform minimal or -platform offscreen on the command line for query_tests.py.

(The platform plugin has to be changed because Qt's default on Linux is xcb, which still expects an X display even if nothing makes use of it.) Edit: It seems from the Github Actions CI that offscreen still expects some sort of display output or server that isn't present. -platform minimal works great even in the... well... minimal CI container environments, though. Whoda thunk?

There were some other changes involved, like deferring any QMessageBox calls that previously occurred during OpenShotApp.__init__(). Now they're placed on a queue, and not shown until requested by launch.py (or automatically, if there are any outstanding when OpenShotApp.gui() is called.

Other changes

• I've completely removed classes.settings.get_settings(). Settings should now be requested from the app instance (because it holds the settings instance), using a path along the lines of get_app().get_settings(). There is also a convenience function get_settings() in classes.app, mirroring the old one in classes.settings, but you shouldn't use classes.app.get_settings() either. It just makes more sense to go through the application instance.

Next steps

GUI-free Model Classes

The next obvious evolutionary step, here, would be to move the data models out of MainWindow, and have them be both initialized and held by the OpenShotApp instance. There's no reason our data models should be dependent on a GUI being launched, and if they weren't then we could start writing unit tests for them, which would be a very good thing.

For that to happen, though, all of the hidden GUI dependencies in them have to be shaken out. That means no calls to get_app().window.anything anywhere in the models. Right now they contain way too many sneaky dependency inversions like this (from the files proxy model):

    def filterAcceptsRow(self, sourceRow, sourceParent):
        """Filter for text"""
        if get_app().window.actionFilesShowVideo.isChecked() \
                or get_app().window.actionFilesShowAudio.isChecked() \
                or get_app().window.actionFilesShowImage.isChecked() \
                or get_app().window.filesFilter.text():

The way that should work — both for model integrity and to be far more efficient — is to have the main window class connect the changed signal from the QActionGroup holding the selector buttons to a slot in the model class that stores the selected filter option as an instance variable, which defaults to no filtering.

That way, the model doesn't need to consult the GUI just to do its job, and if there isn't a GUI then the filtering will never be activated. (Though it still could be, programmatically, in the unit tests. All they'd have to do is simply connect signals to that slot and emit() them.) Properly isolated, the existence of an actual GUI should be completely irrelevant to the group-filtering features of the files model. It certainly shouldn't be an assumption baked into the model that crashes its code when the GUI isn't available.

[jonoomph]

LGTM! Nice work! 😀

[jonoomph]

@ferdnyc Is this one ready to merge?

[ferdnyc]

@jonoomph AFAICT, yes, but maybe you want to test the Mac build first just in case?

[jonoomph]

Sure, I can give it a quick look on Mac!

[jonoomph]

As far as I can tell, works fine on the Mac! Merge away!

[ferdnyc]

@jonoomph Merged! So that should be the end of the spurious unit test failures.

[ferdnyc]

@jonoomph

P.S> I'm about 2/3 of the way through this...

GUI-free Model Classes

The next obvious evolutionary step, here, would be to move the data models out of MainWindow, and have them be both initialized and held by the OpenShotApp instance. There's no reason our data models should be dependent on a GUI being launched, and if they weren't then we could start writing unit tests for them, which would be a very good thing.

For that to happen, though, all of the hidden GUI dependencies in them have to be shaken out. That means no calls to get_app().window.anything anywhere in the models. Right now they contain way too many sneaky dependency inversions like this (from the files proxy model):

    def filterAcceptsRow(self, sourceRow, sourceParent):
        """Filter for text"""
        if get_app().window.actionFilesShowVideo.isChecked() \
                or get_app().window.actionFilesShowAudio.isChecked() \
                or get_app().window.actionFilesShowImage.isChecked() \
                or get_app().window.filesFilter.text():

The way that should work — both for model integrity and to be far more efficient — is to have the main window class connect the changed signal from the QActionGroup holding the selector buttons to a slot in the model class that stores the selected filter option as an instance variable, which defaults to no filtering.

That way, the model doesn't need to consult the GUI just to do its job, and if there isn't a GUI then the filtering will never be activated. (Though it still could be, programmatically, in the unit tests. All they'd have to do is simply connect signals to that slot and emit() them.) Properly isolated, the existence of an actual GUI should be completely irrelevant to the group-filtering features of the files model. It certainly shouldn't be an assumption baked into the model that crashes its code when the GUI isn't available.

I just have about a solid afternoon's work left, fixing up all of the view classes. So, realistically, given the pace I've been managing lately... probably another week or two. (Especially now that a tenant moved out yesterday with zero notice, so the rest of this week is suddenly booked up with turning that apartment back around for the realtor.)