26645: Undo/redo buttons' hovered state and of disabled controls

[krasko78]

Resolves: #26645
Partially resolves #26232: tooltips on disabled controls will appear when those are hovered.

Supersedes PR#26671 which became a mess after rebasing.

Key points:

1. Added && root.enabled to the condition for the "HOVERED" and "PRESSED" states.
2. Removed enabled: root.enabled from the MouseArea-s since it has side effects. See below.
3. For #26232 we want shortcuts on disabled controls to work again so I didn't add && root.enabled in the various onContainsMouseChanged handlers.

Disabling the MouseArea together with a button has side effects when the button is disabled upon its own click. This is the case with the Undo and Redo buttons when there are no more actions to undo/redo. In particular containsMouse and pressed of the MouseArea remain true when the button and its MouseArea get disabled. This means that the "HOVERED" state will remain active. This could be worked around by adding && mouseArea.enabled to the condition of the "HOVERED" state.

However, there is more: containsMouse will continue to be true even if the mouse then leaves the now disabled button. Let's say this is the Undo button and it becomes disabled on click since there are no more actions to undo. The user moves the mouse away from it and over the Redo button. containsMouse of the Undo button's MouseArea continues to be true since both the button and the MouseArea are now disabled and the MouseArea does not react to any mouse events any more. If the Redo button is now clicked, this will re-enable the Undo button and its MouseArea. The Undo button's "HOVERED" state will fire even though the mouse is hovering the Redo button.

The conclusion we (Casper and I) came to is we should not be disabling the MouseArea. Instead we should be checking root.Enabled where necessary. This also mkes tooltips on disabled controls appear again on hover: #26232.

The disabling of the MouseArea-s was done for #25697.

Commit 1 fixes the hover state specifically for the Undo/Redo buttons (this story).
Commit 2 takes care of the other controls.

I have tested what I could.
QA: #25697 will have to be retested.

TBH, I find it a bit clumsy having to check root.enabled every time but adding a new property to the MouseArea-s - something like isHovered: containsMouse && parent.enabled - isn't good enough either because I am sure everyone is used to the traditional properties of the MouseArea...

• 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)

[cbjeukendrup]

@krasko78 I see this PR is almost falling through the cracks. Would you mind giving it a rebase?

[krasko78]

@cbjeukendrup I rebased and resolved the conflict but let me take a look at the PR with fresh eyes before it gets reviewed.

[cbjeukendrup]

Alright, thanks very much! Let me know when it's ready.

[krasko78]

Associated issue 26645 no longer happens with Qt 6.9.1. Confirmed by Dima. Issue was closed. I am closing this PR as no longer needed. @cbjeukendrup FYI.