Created attachment 35716 [details]
Patch for single-click behavior

This is a quick patch to respect single click settings. It doesn't add the more advanced timered hover settings, but such an implementation should probably be made more general.

Note that the problem doesn't present itself when using the Oxygen style, because it sets a behavioral style hint for Qt. 

This also means my patch is misbehaving when combined with Oxygen style. What probably should be done, is stop using the activated() signal and instead emit an execute() signal like KListWidget does.

I'm not able to reproduce using current trunk: the icons on system settings follows the configuration. Exactly which KDE version are you using?

I am using KDE 4.3 branch last updated 29/7.

Note that single click works when using the Oxygen widget style, but auto-select hover doesn't.

When using widget styles supplied by Qt, single click doesn't work. This is because KStyle is setting the SH_IconView_ActivateOnSingleClick hint. The problem is the with this model of putting behavior in the QStyle means we can't rely on Qt to enforce KDE settings, we need to add the functionality in the KDE widget classes.

Bug confirmed using Plastique style.

Please update your patch to latest Trunk and submit it to kde-core-devel@kde.org.

@Rafael: is this something that needs to be handled in KCategorizedView or in System Settings itself?

Created attachment 37028 [details]
Patch for following single/double click actions

This patch applies the same solution Dolphin has for this issue.

Can I commit the attached patch ?

Please go ahead and commit the patch.

The patch is very simple, but has the weakness in that it doesn't switch style when settings are changed. 

A combination of this patch and my patch might work better. Change my patch to emit an new signal for instance "executed" and then connect from that instead of activated.

Created attachment 37052 [details]
Attached an improved patch as requested

Hi there. This patch takes into account in-runtime changes of settings.

Is this patch OK to commit ?

Patch is mostly ok. It would be best if the KGlobalSettings section wasn't duplicated. Maybe that area should just call settingsChanged( KGlobalSettings::SETTINGS_MOUSE )?

Otherwise patch may be committed.

Created attachment 37060 [details]
Updated patch

Ben, I think keeping that logic out with a proper name and calling it is a better solution than calling the slot with that very specific name.

Is this patch OK ?

Definitely makes more sense. Please note the you need to connect to the activated() signal as well to allow keyboard navigation.
Also, I don't think connectAllViews() needs to be in the d-pointer.

Otherwise patch is perfect.

SVN commit 1026068 by carewolf:

Use stylesheet to set activate-on-singleclick hint for non-KDE QStyles
BUG:201863


 M  +19 -0     kglobalsettings.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1026068

Hm, the commit sets an application global style sheet. I don't like this, as it affects performance of all widgets, and breaks applications that already set a stylesheet. Has this been discussed anywhere? Does this bug need to be fixed at all? To me, the only correct solution is to document that KDE settings are respected by KDE styles only. Other platform's styles even might have their own settings, and KDE should not enforce its settings, but respect platform settings.

That is how KDE applications has always worked. There might be a problem with other stylesheets, which would need to be merged.

If single-click only affects styles it would be an option for QStyles, and needs to be moved to the widget style configuration.

i fully second cristoph
(i just ran into this and lost som time in figuring out why i couldn't apply a stylesheet to an application)

Applying a global stylesheet to handle the click policy (for a subset of QStyles) is
a) sheer overhead
b) an inconsequent solution (as apps could either fail to successfully apply their sheets or remove this "patch" by successfully applying global sheets)
c) possibly triggering a behavioural break between KDE and Qt apps
d) simply a /bug/ if styles have host system relative settings on this (and KDE apps are used within a non KDE desktop environment)

so i really strongly vote for reverting this.

the proper fix (if required) for this would be for QStyles (i case they do not option this anyway or aren't strongly DE mimics) to either detect the KDE environment, read the setting and adjust the stylehint in this regard or simply provide a property/setter on this (though the latter is probably not what QStlyes were meant to be)

Thanks Thomas for being with me :) I was going to raise the discussion again, too, because I even got Qt 4.6 to crash when simply calling setStyle() in system settings.

This isn't the primary reason for not liking the patch, as Qt could be fixed. Thomas already wrote what other reasons there are, mainly that it overrides platform settings (e.g. people that use QWindowsVistaStyle would really like KDE to follow the settings from the Windows Control Panel) and it breaks applications that use their own style sheet, because KDE now overrides this.

The real fix would be to get a patch in for Qt's QCommonStyle. It could check if the application is running on KDE, and then read KDE's global setting. QStyles that do not have a native policy for that option would then respect KDE's setting. Qt is increasingly enhanced to support KDE settings for palettes, toolbar icon sizes, toolbar text positions, icon themes, button order, etc.

@Allen, I do not understand your comment "That is how KDE applications has always worked". Are you suggesting that KDE always set a global style sheet? I only see some style sheets for selected widgets.

I am reopening the bug, just to make others aware of the problem. If there can be no agreement to revert this patch here, I would like to discuss this on kde-devel-core.

In agreement with Thomas and Christoph. Please revert the stylesheet change, adding this to Qt is the correct way to handle it.

Ok, two or three more things i ran into
(short version: this /must/ be reverted)

a) QStyleSheetStyle operates on qApp->palette() /only/
as a consequence if a widget gets a custom palette all its children will continue to use the app wide palette rather than the custom one (leading to invisible text in doubt and given the vast amount of palette->setColor(QPalette::Window, Qt::transparent); -what is wrong by itself, but happens- probably some unexpected solid visuals (KFilePlacesView is a prominient example)

b) After this patch is applied, qApp->style() (and regularly non custom QWidget::style()s) will (::inherits("KStyle") == false) - even if the original style did (so any code checking for this will fail)
For similar reasons the painting of custom widgets might be impacted (e.g. the runtime style elements as currently used at least by KCapacityBar) will fail (for /every/ style as QStyleSheeetStyle simply does not support this feature)

Last, an "imho".
As I see the QStyle design, it's done to integrate Qt applications into the hosting system (though X11 has no default, but there's support for motif, cde, and Gnome - KDE is a special case here.
::setStyleSheet() then /can/ be used to pass the end user the ultimate opportunity to skin a specific application.

But using stylesheets to do anything but this (including the unfortunate usage of stylesheets to paint images onto dialogs) is plain abuse of this feature.
From my personal experience, applying a global stylesheet and /not/ handle all used UI elements by the stylesheet, regularly leeds to visual flaws (as e.g. many styles don't use the general focus indicator to indicate the focus of elements like buttons - but QStyleSheetStyle /does/)

It might be a convinient way but is likely to cause interferences.
While this might be a corner case for the dialog background images/watermarks it's really prominent on global stylesheets.

Okay, at least we agree that it is a setting that has to be applied globably? I used the stylesheet because it was the only way short of wrapping all QStyles in KStyles.

I have a few notes:
- I am considering adding a KApplication::addStylesheet so you can have multiple stylesheet and only remove per name, etc.
- We do a very bad job of supporting double-click. If we want double-click we should probably use it more limited like Windows does. Right now, every listView suddenly requires double-click which is unexpected for both KDE and Windows users. We could possibly decide to uses click() signal instead, because single-click activation would be expected on a double-click platform such as Windows too. This is the case with systemsettings, but also document list in Kate etc.

The correct signal to connect to is activated() otherwise then the keyboard is not used. The proper way to fix it would be to fix QStyle once more to use single click on tree views / list views.

The patch has been reverted. Not cc'ed here due to a typo in CCBUG.

I see two major roads
1. Fixing only KCategoryView
2. Fixing all QAbstractItemView

1. For the first, the existing patches were not acceptable because they didn't handle keyboard events. Another approach would be overloading mouseReleaseEvent or setting widget stylesheet.
2. I can only see wrapping all QStyles in KStyles or changing Qt itself

First off: thanks for reverting this =D

As for the solutions:
a) Neither "fixing" KCategoryView nor QAbstractItemView will really do the job - the click policy might be used on other classes as well.

The usage of metastyles* has one _major_ design flaw:
The app's click behaviour will depend on the used constructor (QApplication vs. KApplication) what is no way obvious to the user.
I.e.: some apps might use single click and some use double click - eww :-\

This is imho worse than some styles forcing a click policy on the user (what is at least a consistent experience)

So to me the only valid solution is to handle this in QCommonStyle or QStyle (what however does not prevent inheriting styles to hardcode a behaviour, that's in the scope of styles)

(This is now rather OT, but) to force a certain activation mode, i usually apply an eventFilter to the widget (if i don't need to inherit it anyway) and emit activated() on the event in question (MouseButtonPress) or blockSignals in case.
KDE ItemView variants or even QItemView could of course provide a convenient function like "::forceActivationMode()" or so...

*setStyleSheet() basically does this, but there's no point in using overheaded css parsing stuff for this - a simple metastyle that passes through all style functions and overrides this values /would/ do and has by far less traps

This should be proposed for fixing with Qt platform plugins.

This is implemented in qguiplatformplugin_kde starting with 4.4. When Qt detects that it is running in an KDE environment, it queries KDE's single-click setting in QCommonStyle using this plugin.

Some styles might still override that behavior (e.g. QWindowsStyle probably reads Windows Control Panel settings), but for most styles, the KDE setting is now respected.

This does not mean all applications follow automatically, only those that actually use activated() instead of clicked() or doubleClicked(), but this has to be fixed in individual applications.