Bug 419651

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.