Bug 413827 - KActionMenu sticky/delayed wrong behavior
Summary: KActionMenu sticky/delayed wrong behavior
Status: CONFIRMED
Alias: None
Product: frameworks-kwidgetsaddons
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.63.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Christoph Feck
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-05 09:22 UTC by Simone Gaiarin
Modified: 2019-12-01 15:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simone Gaiarin 2019-11-05 09:22:56 UTC
SUMMARY

If I am not wrong it seems that there is a bit of mess with the combination of settings of KActionMenu and they do not reflect the documentation.


From the documentation:
"Sticky", means it's visible until a selection is made or the mouse is clicked elsewhere. This feature allows you to make a selection without having to press and hold down the mouse while making a selection."

Four cases:
delayed / sticky

true / true
Standard delayed button menu. Click and hold to show the menu. If the mouse is released the menu disappears. sticky is true but the behavior is the opposite of the one described in the doc. WRONG.

false / true
Standard instant button menu. Click and the menu is shown until clicking somewhere. sticky is true and the behavior is the one described in the doc. OK.

true / false
Clicking on the button nothing works (should be forbidden or change to a meaningful state automatically)

false / false
Instant menu activated when clicking on the arrow. Click and the menu is shown until clicking somewhere. sticky is false but the behavior is the opposite of the one described in the doc. WRONG.
Moreover this case is the save as the second one, besides the fact that the visual appearance of the button is different (and we changed the appearance changing flags related to the behavior, super weird).
Clicking on the button (not on the arrow) does nothing, which is weird again.


EXPECTED RESULT
To be discussed

SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux 
KDE Plasma Version: 5.17.1
KDE Frameworks Version: 5.63.0
Qt Version: 5.13.1
Kernel Version: 4.19.80-1-MANJARO
OS Type: 64-bit
Comment 1 David Hurka 2019-11-05 20:01:35 UTC
I also find this weird, thanks for opening the bug.

I think providing a setPopupMode(QToolButton::ToolButtonPopupMode) would be just fine.

From kactionmenu.cpp:
In private class definition:
>    bool m_delayed = true;
>    bool m_stickyMenu = true;

In createWidget():
>    if (delayed()) {
>        button->setPopupMode(QToolButton::DelayedPopup);
>    } else if (stickyMenu()) {
>        button->setPopupMode(QToolButton::InstantPopup);
>    } else {
>        button->setPopupMode(QToolButton::MenuButtonPopup);
>    }

In toggleactionmenu.cpp (D21971) I go the reverse way:
> if ( popupMode == QToolButton::DelayedPopup )
> {
>   setDelayed( true );
> }
> else if ( popupMode == QToolButton::InstantPopup )
> {
>   setDelayed( false );
>   setStickyMenu( true );
> }
> else
> {
>   setDelayed( false );
>   setStickyMenu( false );
> }
Comment 2 Simone Gaiarin 2019-11-06 19:43:53 UTC
Yes, setPopupMode seems the right solution (and deprecating setSticky and setDelayed).
Comment 3 Christoph Feck 2019-12-01 13:51:58 UTC
Anyone up for a review request? Also, do you think the behaviour change would be a bug fix, or should be delayed until KF6?
Comment 4 Simone Gaiarin 2019-12-01 15:09:14 UTC
If we go for the setPopupMode mehtod, we can issue a deprecation warning for the other two methods in KF5 and get rid of them completely in KF6. (I am no expert on how to deal with API modifications though)