In a selectable QAbstractListView widget, the first click should select the item. A second click should then activate it. Until Plasma 5.18, this was the case. In Audacious, we have worked around this bug by installing a QProxyStyle which forcefully disables the single-click activation logic on the playlist widget. https://github.com/audacious-media-player/audacious-plugins/commit/bd1b29fbfe9d85bc3a99586044ce62d95f3f55fd This regression does not exist in other QStyles, such as the Adwaita style. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Alpine edge (kernel 5.4.30) KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1
This is the intended behaviour of the Breeze style. Bikeshedded to death in https://phabricator.kde.org/T8187, https://phabricator.kde.org/T7928, etc. This is also documented in the KDE HIG at https://hig.kde.org/components/editing/list.html. Single or double click activation is determined by a setting in the Workspace KCM (General Behaviour -> Click behavior). The fact that this is not more prominent is a known issue (https://phabricator.kde.org/T10273).
I understand that single-click activation in general is intended behaviour of the Breeze style. I do not believe that single-click activation on a selectable list is intended behaviour. That doesn't make any sense, because it makes selecting items impossible.
From the Qt docs. >void QAbstractItemView::activated(const QModelIndex &index) >This signal is emitted when the item specified by index is activated by the >user. How to activate items depends on the platform; e.g., by single- or >double-clicking the item, or by pressing the Return or Enter key when the item >is current. If client code does not handle very documented behaviour, it is unquestionably a client bug.
The client in question behaves appropriately under all platforms other than KDE Plasma 5.18, including KDE Plasma 5.16. Don't worry, we have already made a hotfix release for users who use Audacious that got broken by Plasma 5.18. As it stands, KDE Plasma 5.18 completely broke Audacious, in a way far more severe than GNOME ever did to us. As it also stands, any other client which depends on the activate signal to behave sanely in a situation where a listview is selectable is also broken by this: you can't select items without also activating them. The documentation also does not say that hooking activate means you will have lists that cannot be selected in a usable way under KDE Plasma 5.18. Not all Qt apps are KDE apps. Please don't break our apps.
>The documentation also does not say that hooking activate means you will have lists that cannot be selected. It literally does say that and has since 4.x. If you have suggestions on improving the documentation for Qt I will be happy to submit them to Qt. It is a common pitfall for application developers to fall into. Maybe I can propose a keyboardActivated signal, so those that don't want to follow the platform can connect to clicked and doubleClicked+keyboardActivated to do whatever they want to in an easy way.
Regarding going against the platform: I think single-click activation makes sense for navigational tasks, but it doesn't make sense for other tasks. For example, not only is this a problem in Audacious, but two different friends who use Amarok also said they find the single-click behaviour annoying there, since clicking on a song makes it play immediately when single-click mode is enabled. In an audio player, a common pattern is to select a bunch of tracks and enqueue them to a separate playlist or play queue. With the single-click behaviour, doing this is quite counter-intuitive. So, in Audacious, we attach a QProxyStyle to our subclassed audqt::TreeView widgets that suppresses the single-click activation for those widgets. I think, therefore, what makes most sense is to have a flag on the widgets that provides a hint as to what the purpose of the widget is. That seems to also be in line with how Qt provides other hints. Then you either hint the widgets where single-click activation is useful (like navigation), or you hint the widgets where single-click activation is counter-intuitive (like playlists). For something like a playlist, the single-click activation pattern doesn't make much sense, doesn't match any other popular platform (Audacious does target Mac, Windows, etc too), but as previously stated does seem useful for navigation. So, that is what I propose doing.