Move some classes from the main gui module.

[lukaszgo1]

Link to issue number:

Related to #11950 , #11951 and #11958

Summary of the issue:

Code layout in the gui module is sup optimal. This can easily cause cyclic imports for one such example see #11950
While the issue mentioned above has been resolved it makes sense to reorganize this part of the code to minimize likelihood of similar problems in the future.

Description of how this pull request fixes the issue:

• LauncherDialog, WelcomeDialog and AskAllowUsageStatsDialog were moved to the gui.startupDialogs module
• getDocFilePath has been moved into the new documentationUtils module as there is no logical connection between it and gui

Testing strategy:

Manual testing:

• Ensured that user guide, license file and change log can be opened both from binary copy and from sources.
• Ensured that LauncherDialog is shown and works as expected when starting from the launcher.
• Ensured that WelcomeDialog can be invoked from the help menu
• Ensured that dialog which asks about stats collection still works as expected.
• Ensured that context help works for all 3 moved dialogs and for a randomly chosen settings panel.

Known issues with pull request:

There are more places in the gui package which might benefit from the code reorganization.

Change log entry:

Section: Changes for developers:

• WelcomeDialog, LauncherDialog and AskAllowUsageStatsDialog are moved to the gui.startupDialogs
• getDocFilePath has been moved from gui to the documentationUtils module.

Code Review Checklist:

This checklist is a reminder of things commonly forgotten in a new PR.
Authors, please do a self-review and confirm you have considered the following items.
Mark items you have considered by checking them.
You can do this when editing the Pull request description with an x: [ ] becomes [x].
You can also check the checkboxes after the PR is created.

• Pull Request description is up to date.
• Unit tests.
• System (end to end) tests.
• Manual tests.
• User Documentation.
• Change log entry.
• Context sensitive help for GUI changes.

[lukaszgo1]

cc @feerrenrut

[lukaszgo1]

I've merged the latest master and fixed merge conflicts.

[seanbudd]

Thanks for this @lukaszgo1, left some minor feedback but otherwise looks good to me

[seanbudd]

Suggested change

	from gui.startupDialogs import WelcomeDialog
	WelcomeDialog.run()
	gui.startupDialogs.WelcomeDialog.run()

I think we are trying to avoid these imports that aren't at the top of file, or the most outer scope when this isn't possible. Since gui has already been imported at the top of doStartupDialogs, if you want to import WelcomeDialog directly, it would be preferable to add the from gui.startupDialogs import WelcomeDialog statement to the top of doStartupDialogs.

[lukaszgo1]

It is a matter of style obviously, however since WelcomeDialog is used only for users who haven't disabled it so a very small percentage isn't it wasteful to always import it rather than do it conditionally as it is done now?

[seanbudd]

yes, definitely a matter of preference. From a discussion with another developer these are fine as is. However in this case wouldn't there be no performance changes because the entire gui module has already been imported in the same scope?