Clean up the logs

[krasko78]

Resolves: #32431

PR contains one commit per scenario:

1. When a navigation panel and its child navigation controls are created together as part of the creation of a control and its children, the componentComplete() method of AbstractNavigation calls componentComplete() on the associated accessible which then registers the accessible if not already registered. The problem is that the reg() method of AccessibilityController also registers the children of the accessibility without marking them as registered at this point. So when componentComplete() is called first for the navigation panel, this will register both its accessible as well as the child accessibles (see NavigationControl::setPanel - calls setAccessibleParent()) and then when componentComplete() is called for any of the NavigationControl-s, they will attempt to register their already registered accessible-s without knowing they had been registered already.

2. @mathesoncalum Do you think we need this warning? Why is it a problem if the version contains more than 3 parts? Let me know if you want to keep the warning and what other solution we should go with.

3., 4. and 5. Should be straight-forward.

6. @Eism This binding loop warning is back in AppMenuBar.qml where the width of the FlatButton is set. I think I fixed this some time ago and you and I talked about the TextMetrics. You mentioned that they were added to fix the shifting menu issue when the underlined letters appeared but that fix didn't work. So I assume we are OK with removing the width property and the TextMetrics?

7. This warning happens for the "add-slur" action because now there is a slur button in the note input toolbar itself as well as a menu item for this under the Add toolbar button -> Lines -> Slur. I am changing the code to handle multiple items per action.

8. These warning happen when building MS without the VST module. Also results in a glitchy VST menu under menu Diagnostics.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[Eism]

@krasko78 thank you! I agree with all points

@DmitryArefiev can you please do general accessibility testing? There should be no regressions with the master.
What do you think about point 6? Are there any differences with the master?

[krasko78]

@DmitryArefiev Hey! Number 6 is related to the width of the main menu items File, Edit, View, etc. So we need to make sure that the main menu continues to look and feel the same. One specific thing that I tested out myself is that the main menu items should start to disappear from the right side if the window's width is shrunk so that the score title clashes with the menu items. Things like that (anything that occurs to you). Many thanks!